A simple question: Is sprite:remove() sufficient to destroy the sprite and free up memory?

An example:

A gun is firing bullets. When the gun fires a bullet, in the "firebullet" function, I create a "local newSprite = Bullet()".

I'm not interesting in recording a reference to the bullet. It's off on its own to do its own thing.

At some point, the bullet will collide with something, or go off-screen. At that point, it will call self:remove()

Is that enough for me to not worry about memory tidiness etc.?

Can I live worry free (about memory usage) even after hundreds of bullets have been fired?

Thanks.

Sprite->remove() takes the sprite out of the display-list. Probably playdate->sprite->free(LCDSprite *sprite); is what you need. I say "probably" because the doco is very light.

Ref: Inside Playdate with C

Maybe there's some further removal steps needed before calling free()?

I re-use bullet sprites, taking them off-screen and de-collide them. That seems to work OK.

Generally with embedded programming you either allocate once, or just use static variables without allocation. So reallocation didn't seem appropriate.

I'm not familiar with the free() function. It doesn't seem to appear in the SDK documentation.

I think that remove() might do the trick, because by removing the sprite from the display list, and not having previously recorded the sprite to a lasting variable, it should in theory make it garbage for the garbage collector.

But I'd like confirmation.

In Lua, calling self:remove() is enough to destroy the sprite, as long as there are no other references to the sprite object. In your case, it sounds like the Bullet is a local variable that does not have a reference outside of the scope of the function, so it will be marked as garbage as soon as it is removed from the display list.

Depending on the amount of bullets you are creating, it might be better to have a cache of bullets and re-use them instead of destroying and creating new ones. This is because garbage collection does take a toll on performance sometimes, especially if there are a ton of objects being destroyed.

Also keep in mind that the simulator has a Malloc Log that will let you see if there is memory leaking. You can view the "Map" section and check "Automatically Refresh" to see the memory allocation in real-time.

I'm trying to avoid doing the 'reusing a sprite pool' thing, because of reasons.

I didn't know about the memory log thing. That's very useful, thanks.