Author Topic: Thoughts on never really killing objects  (Read 1029 times)


  • Contributor
  • ****
  • Posts: 378
  • Karma: +0/-0
  • Initials
    • View Profile
    • Initials Blog. Code and other things.
Thoughts on never really killing objects
« on: Fri, Oct 15, 2010 »
Hi everyone,

I'm making a SHMUP, and I'd like to know your thoughts on Flixel's way of "recycling" sprites.

I understand why you'd want to do it this way. At the beginning create everything you need, and recycle them, bringing them onto screen when you need them, and moving them away or setting exist to false when you don't.

My problem is that I prefer to generate random enemies on the fly. I would much to have them flushed from memory when they are killed and generate more when I need them.

My reason is that I have to create everything up front, and then keep track of everything. Whereas I'd prefer to just create and destroy as I please, randomly generating enemies.

I guess the path I'm headed is going to be create everything up front, then generate a random enemy based on which ones are not being used.

Is that an option in FlashPunk. I don't really want to switch, after having invested a lot of time into Flixel.

Initials: Super Lemonade Factory, Super Lemonade Factory Part Two, Above The Clouds, Revvolvver, Four Chambers of the Human Heart


  • Active Member
  • ***
  • Posts: 159
  • Karma: +0/-0
  • Herper of Derps
    • View Profile
Re: Thoughts on never really killing objects
« Reply #1 on: Fri, Oct 15, 2010 »
The technique of object pooling is useful not only to keep memory usage down, but also to prevent the automatic garbage collector from running, which can impact performance: If it's running often and doing a lot of cleaning, you can have a low framerate and a lot of stuttering. If you're creating and destroying a lot of objects throughout a game session, it's definitely worth the effort to employ an object pooling system. You don't actually have to create them all up front, but you should recycle them once created.