In an average game, there are hundreds or maybe thousands of objects in the scene. Is it completely correct to allocate memory for all objects, including gun shots (bullets), dynamically via default new()?
Should I create any memory pool for dynamic allocation, or is there no need to bother with this? What if the target platform are mobile devices?
Is there a need for a memory manager in a mobile game, please? Thank you.
Language Used: C++; Currently developed under Windows, but planned to be ported later.
Answer
In an average game, there are hundreds or maybe thousands of obects in the scene. Is it completely correct to allocate memory for all objects, includiding gun shots(bullets), dynamically via default new()?
That really depends what you mean by "correct." If you take the term quite literally (and ignore any concept of correctness of the implied design) then yes, it is perfectly acceptable. Your program will compile and run fine.
It may perform sub-optimally, but it still may also perform well enough to be a shippable, fun game.
Should I create any memory pool for dynamic allocation, or is there no need to bother with this? What if the target platform are mobile devices?
Profile and see. In C++, for example, dynamically allocation on the heap is usually a "slow" operation (in that it involves walking through the heap looking for a block of appropriate size). In C#, it's usually an extremely fast operation because it involves little more than an increment. Different language implementations have different performance characteristics with respect to memory allocation, fragmentation upon release, et cetera.
Implementing a memory pooling system can certainly bring about performance gains -- and since mobile systems are usually underpowered relative to desktop systems, you may see more of a gain on a particular mobile platform than you would on a desktop. But again, you'd have to profile and see -- if, currently, your game is slow but memory allocation/release doesn't show up on the profiler as a hot spot, implementing infrastructure to optimize memory allocation and access probably won't get you much bang for your buck.
Is there a need for a memory manager in a mobile game, please? Thank you.
Again, profile and see. Is your game running fine now? Then you may not need to worry.
All of that cautionary-speak aside, using dynamic allocation for everything isn't strictly speaking necessary and so it can be advantageous to avoid it -- both because of the potential performance gains, and because allocating memory that you need to track and eventually release means you have to track and eventually release it, possibly complicating your code.
In particular, in your original example you cited "bullets," which tend to be something that get created and destroyed frequently -- because many games involve lots of bullets, and bullets move fast and thus reach the end of their lifetime quickly (and often violently!). So implementing a pool allocator for them and objects like them (such as particles in a particle system) can usually result in efficiency gains and would likely be the first place to start looking at using pool allocation.
I am unclear if you are considering a memory pool implementation to be distinct from a "memory manager" -- a memory pool is a relatively well-defined concept, so I can say with some certainty that they can be a benefit if you implement them. A "memory manager" is a bit more vague in terms of its responsibility, so I would have to say that whether or not one is required depends on what you think that "memory manager" would do.
For example if you consider a memory manager to be a thing that just intercepts calls to new/delete/free/malloc/whatever and provides diagnostics on how much memory you allocate, what you leak, et cetera -- then that can be a useful tool for the game while it's in development to help you debug leaks and tune your optimal memory pool sizes, and so on.
No comments:
Post a Comment