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

[bakpakin]

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.

[Dr. Peeps]

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?

[bakpakin]

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.

[Dr. Peeps]

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.

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.

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]

@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]

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]

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.

[Marty]

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.

[pgimeno]

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.

[Marty]

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.