2d particle system efficiency

Game Mechanics
#1

Howdy,

Just for a bit of fun, I’m thinking about making a very simple 2d particle system. It will essentially spit out different coloured pixels. However I have a few questions about the design for those of you who are more well-versed in computer science than me.

A lot, if not all of the examples I have found on the net treat each particle as an instance of a Particle class, which holds its own variables and has an update method. That’s all well and good, and makes sense, but wouldn’t having a method call for each particle in each run of the update loop introduce extra performance overhead?

I’m more inclined to hold all particle information within arrays, perhaps in a ParticleEmitter class. Then instead of calling update() on separate instances of Particle, it would just be a case of doing some basic operations on a few arrays.

So my question is, are my assumptions about the overhead of a method call correct, and would the difference in performance between the two designs be considerable or negligible??? (Keeping in mind there may be quite a few particles involved).

Cheers,
nerb.

#2

Even on android, the overhead of calling methods is negligible.

My bullet-hell game could pump 2k bullets easily on an 80mhz single core at 60fps.

Your main concern for embedded systems is usually how you design your container and limiting GC.

#3

You’ll probably get a better return on your development time by limiting GL calls than optimizing the java side.

#4

Great bit of advice, thanks relminator. Might go with the Particle class based system just for simplicity.

Cheers,
nerb.

#5

Oops I meant 800mhz.

#6

There goes running your shmup on my 486 :wink:

#7

Funny you should mention a 486 because I developed this shmup on a 486 dx 66mh compaq. :slight_smile:

You’ll need dos with ems to run this though:

www.rel.phatcode.net/index.php?action=contents&item=Frantic+Journey

#8

After playing around with different ways implementing particles, I’m compelled to offer up the idea of a GPU system.
When I first read about this, I began trying to guess how many animal sacrifices I would need to get this magic to work.
Turns out it wasn’t that bad at all. In many ways I found it easier.

The whole idea centers around ping-ponging between two Transform Feedback Buffers (I’ll call them TBO for short). TBOs are buffers you can draw into and from.
When you draw from one TBO to the other, you use a Shader to update particle information like position, velocity, age and so on. You also tell OpenGL to skip the rasterize step when you do this. Then all you really need to do is stuff this bad boy into a particle emitter class and tell it to draw when you want.

This ends up being extremely fast. When I compared it with my other particle systems, it was like a race between an Olympic Sprinter Vs. A Walmart Scooter Jockey (sans scooter).

You can use Geometry Shaders for updating, spawning and destroying particles, as well as using them for creating the billboards.