0

I am making a libGDX (Android) game for which I'll have 90 ParticleEffects playing simultaneously. These may however be of about 25 different types (e.g.: water, fire, ...), which would potentially mean that 2250 effects are pooled in 25 different pools. I estimate that I need about 20 new effects per second.

Now I have 3 possibilities to implement this:

  1. Pooling, with a potential size of 2250, while I only need to show 90 at a time. --> memory overhead
  2. Keep a list of 90 effects and dispose() / create() them at a frequency of 20 times per second. --> computationally expensive
  3. Pooling, but now dispose() effects which probably are not needed in the next ~10 seconds, which would require them to be recreated once they are needed. This way, the size would reduce to about 300-500. --> less memory overhead than (1), but potentially the same computational requirement as (2) at times.

Q: Is there any way to say which possibility is the `better' option in terms of lowest computational cost / memory overhead? Which is equivalent to asking: How efficient is pooling ParticleEffects?

Thanks in advance.

  • I think the answer of your question also depends on the fact that you're going to make an android-game. Older android-versions that don't use ART at the moment, but Dalvik, somehow have a problem with garbage-collecting, so the basic answer would be to keep the effects in pools, or lists. You might consider a way that doesn't have too many/complex computations. Aslong for example textures take much more of the shared-RAM than just some effects, there shouldn't be a big problem of pooling them. – TheWhiteLlama Jul 25 '14 at 10:22
  • With that many particles running, devices that are actually capable of running your app will have no trouble at all with the memory requirements. Disposing that much stuff at a time would create noticeable stutter. – Tenfour04 Jul 25 '14 at 12:30
  • I misread the question. Only 90 particles at a time? That should run fine on anything, but still, no Android device will have trouble with 2250 ParticleEffect objects. That's probably less than 1MB. – Tenfour04 Jul 25 '14 at 12:49
  • There will be 90 ParticleEffects (may become less if Android has trouble with it) consisting of ~20 particles each -> 1800 particles. To improve performance I can reduce this by a factor of ~5: 300ish particles. I hope most Android devices can handle that, and I'll test that once I got my ParticleEffects in-place. – Kevin van As Jul 25 '14 at 18:31
  • Thanks for your answers. I'll go for pooling for now; And later optimise my object management after developing some heuristics on what ParticleEffects my game needs at what time. I.e., predicting the requirement of certain effects in the near-future. – Kevin van As Jul 25 '14 at 18:38

0 Answers0