Monday, October 11, 2010

Of Particles and Sprites

I've just been having some fun with particles in D3D vertex buffers. I've already done this code in OpenGL for RMQ, so once again it was a case of porting it to the other API. I've aleady made my comparisons of the 2 APIs in the past, so it's enough to say that the D3D version is a lot nicer, has fewer lines, and is much clearer overall.

There are a number of interesting options in D3D for doing particles. I had tried point sprites in the older versions of DirectQ, and they worked well enough, but word is that they're no longer guaranteed to be hardware accelerated on newer GPUs (at least in D3D). Interestingly enough, they don't suffer from the same problems as OpenGL point sprites do.

There's also a rather nice ID3DXSprite interface that automatically handles the necessary states, batching, etc for you. Neat. I did get this working but ultimately - while it was nice - it wasn't flexible enough for Quake's particle requirements and had to go. I'll be considering it as an option for the 2D interface stuff though.

After that we get into silly territory; running them entirely on the GPU. There are practical benefits to this, but I'm of the opinion that they would show their worth in a more complex particle system than Quake's. That's the odd thing about Quake - it can be so primitive sometimes that you really struggle to get modern stuff working well with it. It's still fun though.

There is a certain amount of calculation that could definitely be moved GPU side however; I'm thinking of the whole scale/up vector/right vector thing. But overall I believe that GPUs are more suitable for drawing polygons and stuff like that.

Geometry shaders are right out in D3D9. As a move to D3D11 is looking more and more unlikely, this is something that probably won't stand a chance of happening. I did write a particle geometry shader in OpenGL for RMQ, but once again Quake particles stress on fillrate more than on vertexes or shader ops, so there was no benefit to it and I removed it.

So it looks as though vertex buffers are the way to go, using the same setup as for MDLs: 2 vertex buffers, one dynamic (for position and colour) and one static (for texcoords), and one index buffer.

____________________

I'll probably put DirectQ 1.8.666b out tomorrow. At this point in time I just need to get it off my back so that I can start moving forward with other stuff again. I'm also conscious that I've been neglecting RMQ a little while doing these experiments, but the change has been good for me and I have been learning quite a bit.

You'll need to be aware that 1.8.666b has lost some speed by comparison to earlier versions. I'm not too certain where or how that happened, and right now I just want shot of the thing so I'm not putting much effort into bugfixing it. All the signs are that 1.9 will go like a proverbial rocket, and my focus is on what's coming up rather than what's gone before.

I guess the advice then is to use 1.8.666a unless you're specifically affected by one of the bugs that 1.8.666b fixes, or unless you want to see the fog.

0 comments: