Hi everyone!
This is my first cart, and it's a particle cloud simulation. A simple one with grid optimization.
Also I noticed that PICO-8 doesn't completely remove an element from tables when you do something like table[key] = nil. To solve this I had to implement timed table clears, otherwise the app would just crash from running out of memory. Is it a bug or intended behavior?
Update
Yep, this is actually a bug and here is the minimal setup to reproduce it.
Also, I found a better way to work around this issue. Instead of doing a full grid clear from time to time, it is better to clear 200 random cells each frame.
Not entirely sure, but doing del(table, table[key]) might work better than setting directly to nil.
Nope, as far as I know del and deli work primarily with array-like tables. Anyway, I tried to use them and the result was the same :(
I'm getting so much pleasure from your cart. It truly has a amazing soothing effect on me.
i was thinking about your problem and i think this could be a decent solution (im not sure if this is what you had already but i couldnt find the code that could be deleting the particles)
table2 = {}
for k,v in pairs(table) do
if v ~= nil then
table2[k] = v
end |
basically "table2" is "table" but without keys that have their value set to nil
nice particles demo!
setting a nil is definitely gc’ing the table.
are you sure the element id is correct?
(say iterating before and after setting an entry to nil)?
why do you handle grid rows and columns differently when a particle moves??
what if a particle moves and changes both row and column?
@freds72 thank you!
The problem is that setting table key to nil does not remove the key-pair key=nil. If something previously was there before nil it would be GC'ed, but not the pair itself I guess. If you toggle the stats you can clearly see that memory grows and then drops when I manually recreate the tables.
"why do you handle grid rows and columns differently when a particle moves?" slightly different complexity. When a particle moves from one cell to another inside of the same row, I don't need to do extra steps to detect the next row, just next cell inside of the same row. BUT it is a VERY small optimization(if it is actually xD) and can be skipped I guess.
"what if a particle moves and changes both row and column?" then it will fall into new row case and will be assigned to the new cell automatically.
Hi nickname with numbers(that I cannot mention via @ for some reason)
So, first of all pairs() do not iterate over nil values so there is no need to check for them.
Second of all, I tried this approach during development and here is the catch: now during reset there are TWO grids that consume memory and (as it turned out) copy is less performant(don't know why tho)
all my games are heavily using non-orderered tables, I can assure that nils are cleared up.
@freds72 but do they frequently update the keys on the level that you would notice? The grid consist of 64x64 cells and their keys are updated every frame. The grid management was the first mechanic I implemented and tested so keys are actually deleted when particles leave cells, so this is most likely not a problem with particle management.
I suppose that the nil pairs actually persist inside of tables, but normally their size is not noticeable.
@freds72 yoooo very impressive! 3D Pico-8 games are the best!
But is it like 4096 tables updated with 550 unique elements each frame?
Well, maybe it's a skill issue or a bug, but I could not find better solution than timed full table reset
[Please log in to post a comment]
