Necessary to remove off-screen FlxSprite instances?

[ashes999]

Hi,

I'm making an infinite runner (infinite swimmer, but anyway) where I spawn enemies (subclasses of FlxSprite) on the right side of the screen, the player/camera scrolls right past them, and eventually they disappear.

Do I need to detect and remove entities that are off-screen (out of the camera view), or does HaxeFlixel deal with them in a way that makes this a non-issue?

I'm planning to release against the HTML5 and Android targets, if that matters.

[DleanJeans]

I think you gotta do that manually. HaxeFlixel only stops drawing off-screen FlxSprite.

[ashes999]

@DleanJeans said in Necessary to remove off-screen FlxSprite instances?:

I think you gotta do that manually. HaxeFlixel only stops drawing off-screen FlxSprite.

That's my question. Is this actually a performance/memory concern?

if I'm constantly adding new entities/enemies to a FlxGroup, does that also affect performance? It's probably a good idea to do this, even if HaxeFlixel only stops drawing (but doesn't stop processing?) entities.

Cheers,

[starry-abyss]

I believe the best way here is marking them exists=false when off-screen and using recycle(YourType) of FlxTypedGroup<YourType> to create new sprites. Just don't forget to reset all variables of sprites to default values after recycling them (only revive() is called automatically).

(I edited the answer, turns out the reset() isn't called on a recycled sprite)

[Kyatt]

I use getScreenPosition() for situations like that. On update, some sprites check their position, and if it's past certain boundaries, they'll get killed instantly.

if (getScreenPosition().x < -32 || getScreenPosition().x > FlxG.width + 32 || getScreenPosition().y > FlxG.height + 32)
kill();

[ashes999]

@starry-abyss said in Necessary to remove off-screen FlxSprite instances?:

I believe the best way here is marking them exists=false when off-screen and using recycle(YourType) [...].

I only have a couple of objects at any given time (and a couple on screen at any time), so I'm not really worried about the cost of creating brand new ones. Thanks for the suggestion.

@Kyatt said in Necessary to remove off-screen FlxSprite instances?:

I use getScreenPosition() for situations like that. On update, some sprites check their position, and if it's past certain boundaries, they'll get killed instantly.

Yeah, I was planning the same thing. It's a bit more than that (I have to use camera.scroll.x and camera.width etc.) but that's basically what I need to do.

[dean]

Hi @ashes999

You can use mySprite.isOnScreen()to check if an object is on the screen and it takes the camera in to account.

http://api.haxeflixel.com/flixel/FlxSprite.html#isOnScreen

[starry-abyss]

There is not only cost of creating new sprites, but also cost of storing them in memory. If you create 1000 sprites, you have 1000 sprites in memory. If you recycle 1000 sprites with 2 sprites at screen max, you have 2 sprites in memory.

[Gama11]

@starry-abyss Also, to add to that: off-screen sprites are not rendered, but they are still updated.

[ashes999]

@starry-abyss I'm not convinced that it's necessary for me, because I have very few entities and very short game loops; but anyway, it's worth learning how to do this the Right Way. Thanks for being insistent.

FYI, with destroying/recreating off-screen entities, I only have around 6-7 entities active at any time. Even on low-end Android phones, is this even worth optimizing by using recycle? Granted, it's not a lot of work to do so.

[starry-abyss]

In the original question you were doubting whether you should "remove entities that are off-screen". Yes, you should remove them from FlxGroup and also destroy them (Non-Recycle Way)

[ashes999]

@starry-abyss Sorry, you're right. I'll adopt recycle as you suggested. Thanks for the detailed feedback and discussion.

[ashes999]

@starry-abyss said in Necessary to remove off-screen FlxSprite instances?:

I believe the best way here is marking them exists=false when off-screen and using recycle(YourType) of FlxTypedGroup<YourType> to create new sprites. Just don't forget to reset all variables of sprites to default values after recycling them (reset() should be called automatically to reset velocity and stuff, but your own variables won't be reset).

I added an override for reset(x, y) that resets all the variables of the sprite. But something's strange; could you please tell me if this behaviour is unexpected?

In my class constructors, I call reset. This way, the construction code is common across the constructor and reset method.

For the first few objects, I can see HaxeFlixel calling reset. But after a handful of objects, even though objects are being recycled, HaxeFlixel isn't calling reset.

Is this how it's supposed to work? To work around this, I need to call reset myself; newly-constructed objects get reset called twice, but that seems to be a small price to pay.

[starry-abyss]

@ashes999 After looking at the flixel code, I admit I was mistaken. The reset() function isn't called, but revive() is, so you should override it and put your stuff there. Sorry for confusing the functions! I will edit my reply above!

[ashes999]

@starry-abyss no worries! I actually have never released anything on HaxeFlixel with non-trivial performance requirements. I'm really grateful for the time and energy you put into explaining it to me until I finally "get it." So, thanks again.

I'll probably get a chance to work on this later tonight. I'll move my code into revive and if (for some reason) it doesn't work, I'll report back in this thread.

Thanks!