Is recycling necessary on smaller group of objects?

79 views
Skip to first unread message

MegaLeon

unread,
Oct 8, 2015, 5:06:48 AM10/8/15
to HaxeFlixel
I have got a mario-style platformer game where I load the level from a Tiled map along with its objects, and instantiate everything on state creation - probably around 40-80 objects between enemies and items.

Does it makes sense to call recycle() to do so? Wouldn't imagine it provides a huge boost in memory, maybe for those 10-20 objects which are created later in the game flow, such as bonuses coming out of blocks.

What's the consensus? Is it generally a good idea to use recycle() on any object that might appear more than once?

Cheers,
L

Andrei Regiani

unread,
Oct 8, 2015, 6:59:25 AM10/8/15
to HaxeFlixel
Are you actually using object pooling (recycle)? Check: http://haxeflixel.com/documentation/flxgroup/

Object pooling is always a good practice, and simple to implement with FlxGroup.

If your game is simple, I wouldn't care much, hardware nowadays is very poweful and Haxe has automatic garbage collection, just to check if you have serious memory leak you can enable debugger lime test neko -debug and press ~ to open the console and there you can see how much memory you're using, if it's always increasing a lot after switching levels then you have some memory leak, object pooling and setting all member variables to null on destroy() will help.

SruloArt

unread,
Oct 8, 2015, 4:28:23 PM10/8/15
to HaxeFlixel
* I generally agree with Andrei, but there are small caveats for working with pools, like possible stutters (GC), and a reduced amount of free memory (preallocation). This also takes more time of work because you must think about the proper min/max number of objects you're going to have in each level (or the game even), or else you'd get crashes (not enough objects), so sometimes it's just not worth the trouble.

* Luckily HaxeFlixel is already pointing you to some good GC/allocation practices, like allocating and destroying in big chunks (create and switchState) and allowing you to have several pools for several types of objects so there's way less memory fragmentation going on. Using pools properly would allow you to prevent out-of-memory crashes, which are hard to debug but are very common on many old mobile devices.


On Thursday, October 8, 2015 at 12:06:48 PM UTC+3, MegaLeon wrote:

MegaLeon

unread,
Oct 9, 2015, 10:54:12 AM10/9/15
to HaxeFlixel
That make sense. Game is quite simple so I can't really feel a difference in performance among the different user cases.

I think I will stick to regular allocation on create (when I load the level) and clearing groups on destroy, and keep recycling for recurring objects that appear after creation, such as particles and bullets.

Thanks guys!
Reply all
Reply to author
Forward
0 new messages