Particles have now been subdivided into two types - sprite based particles and GL_POINT based particles. Gidrah and player explosions together accounted for nearly 1,000 sprites in sparks alone; that’s 4,000 vertices to process. Now they’re rendered using GL_POINTs, which is only 1,000 vertices and a corresponding 4x speedup in processing. Always trying to get those low-end systems performing acceptably. They don’t look quite as nice as the sprite based sparks but after a little while I didn’t notice any more.
Talking of which - we all noticed that no-one ever looks at the player’s ship. It’s so obvious of course that no-one has ever mentioned it - but you’re always looking at the target, not the avatar. It’s been the same since the very first Space Invaders of course - right after you’ve marvelled at the graphic for the first time you stop looking at it and worry about the things that are whizzing around the screen trying to kill you, and never really look at it again! (Just like riding motorbikes in London) We saw, for example, that the player’s ship in Mutant Storm is crap! But it doesn’t matter, because you don’t look at it!
Chaz didn’t manage to finish the cute purple blobs but he did do the Gunner, which is an angry, throbbing, slightly translucent red ball with spines. I’m going to make it smoke a bit while it chases you, and try to create a sizzling sound effect like frying bacon. The gunner is now faster than the player - you can’t outrun it - but it’s slower to accelerate, so it tends to shoot past you. I might stop it from shooting as it travels faster than bullets anyway.
We’ve started work on the new background for XAP as well to replace my naff circuit board patterns. There’s a bottom, repeating texture layer, which just scrolls away and never ends, and over the top of it, there’s a transparent layer drawn as a grid (indexed GL_TRIANGLES, if you’re interested). I’m a little worried about burning fill rate on older cards as this effectively means blitting the whole display and then blending the whole display as well as drawing all the sprites and points. We’ll have to see how it goes.
The top texture sees the return of the classic water rippling effect to perturb it. When I put some lighting on it it will wobble and ripple when things get blasted on it or res-in.
Technical Fact Time
Once upon a time using an indexed GL_TRIANGLE_STRIP was all the rage, and it was important that you figured out how to draw everything by stitching it together as a triangle strip, naively believing that this was the fastest way to do stuff in OpenGL (or D3D for that matter).
Since then of course I’ve sat and had a think about how drivers and hardware work when using indexed primitives.
And driver worth its salt will cache the last couple of vertex transformations it has done. This means if you are just drawing with GL_TRIANGLEs, and draw an adjacent triangle (eg. 1, 2, 3, 2, 3, 4) then only one vertex actually needs to be transformed. Furthermore, in these days of T&L and on-card vertex caches (I believe even the lowly TNT has a 3-vertex cache) it’s very likely that the transformed vertex won’t even need to be sent down the bus again. In other words, using GL_TRIANGLEs is, in general, no slower than using GL_TRIANGLE_STRIP. What’s more, because you’ve avoided the headache of trying to turn a bunch of discrete triangles into strips, you’ve probably made your overall code even faster. There’s only one downside, and that is you need a slightly larger indexing array.
There is of course a whole other thing about optimising triangle rendering order to maximise the use of on-card vertex caches (the GeForce range has a 16 vertex cache, which is, it turns out, almost the perfect size for nearly all geometry). But I’m drawing sprites, and they’re quads, and they’re not connected to each other anyway. So I’ll maybe talk about that another time
Cas