[Library] tiny-ecs - Fast Simple Entity Component System

Showcase your libraries, tools and other projects that help your fellow love users.
User avatar
bakpakin
Party member
Posts: 114
Joined: Sun Mar 15, 2015 9:29 am
Location: Boston

Re: [Library] tiny-ecs - Fast Simple Entity Component System

Post by bakpakin » Fri Apr 06, 2018 12:59 pm

This is the book keeping I mentioned. Sorted systems have an onModify method that sorts the system. The system is only sorted when entities are added or removed. This is why should one still call world.update once per frame no matter what.
((_((_CRAYOLA_((_((_> GitHub <_((_((_CRAYOLA_((_(()

User avatar
Dr. Peeps
Citizen
Posts: 57
Joined: Sat May 28, 2016 12:57 am
Location: British Columbia, Canada

Re: [Library] tiny-ecs - Fast Simple Entity Component System

Post by Dr. Peeps » Fri Apr 06, 2018 4:54 pm

bakpakin wrote:
Fri Apr 06, 2018 12:59 pm
This is the book keeping I mentioned. Sorted systems have an onModify method that sorts the system. The system is only sorted when entities are added or removed. This is why should one still call world.update once per frame no matter what.
It is. I should have mentioned: world:update(dt) is still being called every love:update(), in both cases. Does it matter that I'm calling it in love:update() and updating my system in love:draw() (after)?

BTW no entities are added or removed after the initial setup. All the entities exist, they just aren't being processed in order unless that system is active = true.

EDIT: A quick look though your source code and it looks like everything for world updates is wrapped in "if system.active" checks, so maybe inactive systems never have their "book keeping" done?

User avatar
bakpakin
Party member
Posts: 114
Joined: Sun Mar 15, 2015 9:29 am
Location: Boston

Re: [Library] tiny-ecs - Fast Simple Entity Component System

Post by bakpakin » Sat Apr 07, 2018 4:48 pm

Yes It does seem like that. In any case, I would recommend against relying on this behavior. I’m guessing your use case is that you have some rendering systems, and some logic systems, and you want to update the drawing systems in love.draw, and the rendering systems in love.update.

You can pass a filter to world.update which will select the systems to update. The filter works much like an entity filter but on systems instead. This is probably what you want to update drawing systems in love.draw, and logic systems in love.update. You can see the demos for an example of this.
((_((_CRAYOLA_((_((_> GitHub <_((_((_CRAYOLA_((_(()

User avatar
Dr. Peeps
Citizen
Posts: 57
Joined: Sat May 28, 2016 12:57 am
Location: British Columbia, Canada

Re: [Library] tiny-ecs - Fast Simple Entity Component System

Post by Dr. Peeps » Sat Apr 07, 2018 5:36 pm

bakpakin wrote:
Sat Apr 07, 2018 4:48 pm
Yes It does seem like that. In any case, I would recommend against relying on this behavior.
OK. So you mean calling system:update() on inactive systems probably isn't supported.
bakpakin wrote:
Sat Apr 07, 2018 4:48 pm
I’m guessing your use case is that you have some rendering systems, and some logic systems, and you want to update the drawing systems in love.draw, and the rendering systems in love.update.
Yes, this is what I'm doing, but different sets of rendering systems are called in each gamestate.
bakpakin wrote:
Sat Apr 07, 2018 4:48 pm
You can pass a filter to world.update which will select the systems to update. The filter works much like an entity filter but on systems instead. This is probably what you want to update drawing systems in love.draw, and logic systems in love.update.
I was doing exactly that, and it worked well. As more sets of systems were added to different gamestates though, things got a bit complicated, filter-wise - so I thought I'd just call each system:update() where needed.

I can go back to using filters though. And maybe it's easier in my case to just set active = false for all the systems I don't want to run! Thanks for the help.

ryanzec
Prole
Posts: 11
Joined: Sat May 05, 2018 3:37 pm

Re: [Library] tiny-ecs - Fast Simple Entity Component System

Post by ryanzec » Fri May 11, 2018 10:01 pm

@bakpakin

So I was looking into ECS for a game I am trying to prototype and was wondering how performant tiny.ecs would be for my game.

For my game, I am going to be rendering a lot of sprites (20k - 30K) however probably about 90 - 95%% of those can be grouped into 2-3 sprite batches and don't need to be updated on every frame so that seems good.

My concern more lies with that I can going to want to have a lot of entities in the game. It is an open world turn based survival roguelike (can't think of any other buzz words to put in there :)) that is going to have a seemingly "infinite world" which could contain 10 's to 100's of thousands of entities. Obviously I can't load and simulate that many entities at once (not on the average computer at least), my naive plan from someone who has not built a game of this scope before is:
  • split the world into small chucks (maybe something like 16x16) that will store all the data related for that chuck (map data, entities, etc.)
  • only load X number of chunks that surround the player (maybe something like 7x7 or 9x9 with the players location being the center chunk)
  • as the player moves, I will load and unload chunks that become in scope and out of scope along with loading and unloading entities related to those chunks in the ECS system
Now most of the entities should have relatively simple logic that needs to be simulated, only a subset (maybe 100 at most 99% of the time) will need more complex things (the most complex things being a* path finding).

Do you think that is something the ECS in Lua can handle in general or more specifically tiny.ecs? Maybe I am thinking too grand for using a higher level language (or ECS) and maybe I need to dig into C++ to be able to get the features I want with the performance I need.

ryanzec
Prole
Posts: 11
Joined: Sat May 05, 2018 3:37 pm

Re: [Library] tiny-ecs - Fast Simple Entity Component System

Post by ryanzec » Sat May 12, 2018 1:46 am

Another that I have noticed is that, in the examples `world:update()` is called in `love.update` and `love.draw` doesn't that means all the logic for the entities is being executed twice which seem highly inefficient. Am I understanding this correct or am I missing something?

bobbyjones
Party member
Posts: 693
Joined: Sat Apr 26, 2014 7:46 pm

Re: [Library] tiny-ecs - Fast Simple Entity Component System

Post by bobbyjones » Sat May 12, 2018 2:40 am

ryanzec wrote:
Sat May 12, 2018 1:46 am
Another that I have noticed is that, in the examples `world:update()` is called in `love.update` and `love.draw` doesn't that means all the logic for the entities is being executed twice which seem highly inefficient. Am I understanding this correct or am I missing something?
He stated that you can set a filter for systems. So in the update call back you will filter for only update systems and in draw only filter for draw systems.

User avatar
modiX
Citizen
Posts: 86
Joined: Mon Dec 04, 2017 1:47 am
Location: Germany

Re: [Library] tiny-ecs - Fast Simple Entity Component System

Post by modiX » Sun Jun 03, 2018 3:44 pm

I found a memory leak in this library: Calling world:remove seems to not clear the memory of the associated object or parts of it as kept alive, I have no idea why this is happening, yet.

Here is a sample:

Code: Select all

tiny = require("lib.tiny")

function love.load(args)
	world = tiny.world()
end

function love.update(dt)
	local test = { data = "lrjgnjsrdnflseknfkjrsgnsrkjfnleadokmskingvkdrjnfseöofnkjsebfksrlnfkljrbvkhsefbksejbfksl" }
	world:add(test)
	world:remove(test)
	world:update(dt)
end

function love.draw()
	love.graphics.print(tostring(collectgarbage("count")), 50, 50)
end
Let it run for a minute or two, it will free up constantly, but it will go higher and highe, eventually. In my larger game this is very problematic, Megabytes getting stacked up for each state I enter.

If you remove

Code: Select all

world:add(test)
the issue is gone. Then, it will not go above 550 bytes memory at me. So, tiny-ecs's remove call seems not to free all pointers of the table, entirely, or anything else is not cleared. So maybe it's the table, maybe it's something else inside of tiny-ecs.

Tested with love 0.10.2, should appear in 11.1, too.

EDIT: Okay, Tjakka found the issue. It seems to free up the memory when I call update BEFORE remove. Idk if this should be fixed. Usually added objects shouldn't be removed on the same frame again, in any case.
Attachments
memorytest.love
(82.04 KiB) Downloaded 16 times
Visual Studio Code TemplateRichLÖVE Mobile (AdMob+UnityAds)Add me on Discord

───▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄───
───█▒▒░░░░░░░░░▒▒█───
────█░░░░░░░░░█────
▄▄──█░░░▀█▀░░░█──▄▄
█░░█▀▄░░░░░░░▄▀█░░█

User avatar
pgimeno
Party member
Posts: 1263
Joined: Sun Oct 18, 2015 2:58 pm

Re: [Library] tiny-ecs - Fast Simple Entity Component System

Post by pgimeno » Sun Jun 03, 2018 8:11 pm

I can't reproduce with 11.1. It reaches 630 something and it never reaches the 640 barrier. Then it goes all the way down to ~320. With 0.10.2 I get a similar result, but it never reaches 580. That's after a ~5 minutes run.

I think this is related to LuaJIT garbage collection, not to the lib.

Edit: Adding collectgarbage("step", 3) makes the memory stay in the 270 range all the time in 11.1.
Thrust II Reloaded - GifLoad for Löve - GSpöt GUI - My NotABug.org repositories
The Microsoft Github repositories I had have been closed after the acquisition announcement and will be removed in the near future.

User avatar
modiX
Citizen
Posts: 86
Joined: Mon Dec 04, 2017 1:47 am
Location: Germany

Re: [Library] tiny-ecs - Fast Simple Entity Component System

Post by modiX » Fri Jun 08, 2018 1:26 pm

pgimeno wrote:
Sun Jun 03, 2018 8:11 pm
I can't reproduce with 11.1. It reaches 630 something and it never reaches the 640 barrier. Then it goes all the way down to ~320. With 0.10.2 I get a similar result, but it never reaches 580. That's after a ~5 minutes run.

I think this is related to LuaJIT garbage collection, not to the lib.

Edit: Adding collectgarbage("step", 3) makes the memory stay in the 270 range all the time in 11.1.
collectgarbage("step", 3) doesn't work for me.

I could avoid all the trouble by making sure that my entities exist at least for one game loop before I despawn them again. But this is a trap. My spawner system was spawning some things my out-of-screen-despawn-system was despawning again, thus leading to a memory leak, because the update of the world wasn't called in between.

I don't know why you cannot reproduce the issue.
Visual Studio Code TemplateRichLÖVE Mobile (AdMob+UnityAds)Add me on Discord

───▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄───
───█▒▒░░░░░░░░░▒▒█───
────█░░░░░░░░░█────
▄▄──█░░░▀█▀░░░█──▄▄
█░░█▀▄░░░░░░░▄▀█░░█

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 5 guests