How’d you go about making a particle system?
Make a thousand particle objects, that are painted seperately?
^How would you do that? Manually? A loop is impossible…
Am I overlooking something? How do you do it? 
[quote=“Masochist,post:1,topic:35605”]
Why?
There’s not really any magic to particle systems, it’s just a load of coordinate, velocity, and lifetime/colour/whatever data that you loop through to update and paint.
The thing not to do is have an object per particle to encapsulate this data - you’ll waste enormous amounts of memory on object overhead and it probably wont be cache-friendly. Instead, pack the data for loads of particles into a few float arrays. For instance:
float[] particles = new float[]{px1, py1, vx1, vy1, px2, py2, vx2, vy2, ...};
// move particles
for( int i = 0; i < particles.length; i+=4 )
{
particles[ i ] += particles[ i+2 ] * timeDelta;
particles[ i+1 ] += particles[ i+3 ] * timeDelta;
}
An example:
http://code.google.com/p/skorpios/source/browse/trunk/#trunk/skorpios-common/src/com/esotericsoftware/skorpios/opengl/particles
See Emitter and PointEmitter for the simplest example. Note the numbers are fixed point.
Also, if you’re using OpenGL, it helps to have particles sorted by texture, otherwise you’re doing a whole lot of wasteful texture binding.
That usually only works well for sprites. Particles often have translucent textures, which means you have to depth-sort them.
This is a true statement. Instead you just put all your particles into a single giant texture atlas.
Also, they don’t have to be truly sorted. If your willing to have minor defects (i.e. very unlikely to be noticed), they can be simply be “mostly” sorted. There’s also order independent transparency techniques.
why do to depth-sort?
I set the deepbuffer to readonly that should have the same effect or?
When blending, order matters.
I still dont understand that. Do you know an example?
Lets say you have two particles that are overlapping. One particle is red and the other is blue. Their ideal colors would then be (1, 0, 0) and (0, 0, 1). At a pixel where they’re overlapping, they both have a transparency of .9
A common way of blending particles is additive blending:
final_color = alpha * color + (1 - alpha) * old_color
If the red particle is drawn first, the final color is:
.9 * (0, 0, 1) + .1 * (.9 * (1, 0, 0) + .1 * (0, 0, 0)) = (.09, 0, .9)
When the blue particle is draw first, the final color is:
.9 * (1, 0, 0) + .1 * (.9 * (0, 0, 1) + .1 * (0, 0, 0)) = (.9, 0, .09)
Now, if the red particle is drawn first but has a nearer z level than the blue, you want to render the (.9, 0, .09) color but if you don’t do depth sorting, you could display the (.09, 0, .9) color instead. This is clearly wrong and can look weird when the perspective transform clearly tells the user that the blue is farther away but the colors claim the blue is nearer.
thx for the example. Now i understand the problem 
I still not sure if i need depth-sort because the particles often have similar colors and i see no obvious faults in my examples. Do you use depth-sort in your particle engine?
I rarely depth sort my particles.
All of our particles are depth sorted. In fact all of our sprites are. It barely takes the blink of an eye compared to everything else going on.
Cas