Hello, welcome to the forums. Your comparison works for me. I've converted your snippet to a whole program by adding a line before and a few lines after your code, like this: local Block = {} function Block:update(t,state,dt) -- check adjacencies and update self.merge -- v (self) for i = 1, #t do lo...

See also viewtopic.php?t=93667

Its interesting that at doesnt crash at least. And that's my point: there comes a point where the garbage generation rate equals the garbage collection rate, and past that point, memory stops growing. The problem is the number of objects generated at that point, and the space occupied by each. The ...

It takes a few minutes on my 4gb system. And top doesnt properly show it, i can not explain the behaviour but this code will crash all my systems veryfiying that this code does in fact not release its memory. I left it running for over an hour, and the love executable didn't reach 8 GB according to...

Regardless of what people want to call this, it does sound problematic as you have to explicitly call collectgarbage() before the program crashes, which isn't obvious if you expect the garbage collector kicking in on its own after a while. Not really. Just adding a line before newFont, like the fol...

Even if your entire program is just Font = love.graphics.newFont( 12) Font = love.graphics.newFont( 21) In my book thats a memory leak, those two lines cause a memory leak. Because it fits the definiton of "not freeing unused data". And thats the whole thing, this line, it fits so it is. ...

This is the very definition of a memory leak. And of course its not anymore if you call garbage collect, i mean.... thats the point. What are you trying to say here? A memory leak consists of memory that is never released. The difference with what I'm saying is that garbage collection would eventua...

Practical example for a memory leak: Have a textbox, have it have a zoom in/out function. We reload our font with Font = love.graphics.newFont( zoom) _Font_ is overwriten each time so logically we would assume the old font data is discardet as it is no longer referenced. This is not the case becaus...

Here's a PoC of the love.physics approach. Lots of magic numbers everywhere as I fine-tuned the parameters by trial-and-error, sorry.

As I feared, love.physics doesn't do bouncing too well, and balls sometimes stick to the cushions if they are very slow, even when setting restitution to 1.

It's quite uncommon to have a memory leak when you're not using FFI. The most common cause of memory usage growth is not a memory leak; it's allocating objects and then disposing of them without releasing them, as Lua won't bother to garbage-collect them early because it doesn't "see" that...