the old school way:

a statically allocated array of structs. each struct has an "active" field (boolean).

allocate: findfirst inactive, return index, use it.

deallocate: active=0;

there is one array for active entities, and a second for active projectiles.

very clean code. runs very fast.

runtime memory allocations are limited to local variables created on the stack, and perhaps one explicit malloc and free of a huge buffer for reading in the exe file and calculating a checkcsum.

The only thing I'm using object pools for are my particles. I have a list of 10,000 that I keep up with. I keep up with the nextParticleIndex and when I need a particle, I use that guy and advance the counter. I setup the particle with the appropriate position, color, rotation, etc. Each particle also has an Active flag and sets this to false after the particle's duration has elapsed.

I don't bother looking for the first inactive particle, I just keep using the next guy assuming he's completed. If I have 10,000 active particles and overwrite one, I don't think any of my players will notice. :)

For everything else, I just new up and delete as needed. I doubt it will ever be an issue. If it ever is, that's when I'll look into profiling where the problem is and optimizing it then.

- Eck

Question (C++ specific) to those using init methods in lieu of constructors: Why not use placement new/delete instead of methods that init your object?

In a lot of cases I don't actually call the init method, usually when I know required values are build in next code block thus avoiding unneeded constructor/method call and/or stack allocation for temp values to pass on to constructor/method. This could still be achieved with placement but then it becomes obfuscated and less obvious when reading true the code months later, so boils down to personal preference I guess. (Pod objects only, for objects with resources that require to be managed following RAII is a must in my mind and placement seems like a nice option.)