More work got done..."yesterday", and by "yesterday" I mean Sunday night. My sleep schedule is such that the mapping of my "logical days" to actual 24 hour periods is sometimes...uh...shaky.
Anyhow, we actually managed to get some cool features in, although our game doesn't -look- that different. On David's side, he got environment mapping working so our player blob has nice reflections (ooooh). And the blob physics are better now. Also, we're now using libvorbis ourselves to decode the music ogg files rather than having SDL_mixer stream it for us. This'll let us do cool FFT stuff on the music stream (ahead of time, when needed) before passing it off to SDL_mixer to be played...we're planning to use said FFT data to generate the terrain/backgrounds.
On my side, I got random note generation working (wasn't actually that hard at all). More impressively, I also made the length of the enemy bullet rhythms variable as a parameter in the MIDI annotations. =And=, you can also specify the time it takes for the player blob to bounce up and down. It gets even cooler too--you can have the up bounce and down bounce take different amounts of time, =and= you can even change the bounce times, and the enemy bullet rhythm durations in midsong via control changes! And it all works, and stays in sync with the music like it's supposed to. Whoo! I also made some major optimizations to a few of the Song class in translating between time and beats and whatnot, so that they weren't super-stupid sluggy O(n^2) operations. There's still some stuff in there that's not really that efficient, but I don't think it's really worth it to optimize those. Amdahl's Law, blahblahblah yeah.
I also tried to wrestle with particle rendering...our particles are currently being rendered with point sprites. Which is all efficient and everything, but the problem is that plain point sprites aren't scaled with distance from the camera, so they don't exactly look right. We originally tried to use the built-in distance attenuation, but the parameters for that seemed pretty finicky and I'm not at all confident that we could get those to scale things correctly. Our second attempt involved modifying gl_PointSize in the vertex shader by dividing by w, but somehow that just slowed performance down a lot. In any case, the other problem with point sprites is that they're not quite as dependable--you can't know what the maximum pointsize is for a given implementation, for example.
So it's best to use quads...but billboarding a quad for each particle is actually kind of non-trivial, as you have to make sure that it faces the camera. And there's also the issue of how to specify the vertices efficiently, because you only have one set of vertices/colors/etc but you actually want 4, with a different offset for each...so yeah, that question is still sort of up in the air.
No comments:
Post a Comment