I've been spending the evening deciphering the Sprite format (first time ever I'd really looked at this code), and unfortunately it's pretty ghastly. There seems to be a lot in there (animating frame groups) that's a hangover from the old days when Quake was intended to have more sprites in it (primarily to speed up alias model rendering - see Mike Abrash's papers for more info on this), but the unfortunate thing is that I just know that some mod out there will use it (I'd be surprised if Hipnotic didn't - it's pretty notorious for hacks like this), so I can't remove it to clean things up.
Frame interpolation doesn't seem to be so straightforward as I had hoped. I have an idea to count the frames in the original, then potentially fill in the gaps with the replacement and possibly blend between textures, but I have no guarantee of what the animation rate will be. I still haven't looked at the QC or Sprgen yet, so maybe some ideas will come from those.
I'm scrapping the plan of doubling size for external Sprite textures. It looks fine with some (explosions, lights) but bad with others (bubbles), so in the absence of consistency I'm just going with the basic size and leaving it as the responsibility of content creators (HA!) to ensure that replacements are correct.
Getting stuck into this is also bringing another issue to a head - proper BSP clipping for sprites. I was always going to hit this when I got round to torch flares anyway, but I might as well direct some thought to it now.
Sprites basically need to be drawn without depth testing to prevent them from poking into walls. The problem is that while there are some straightforward methods I can use - Hull checks or Traces - that will do the job, they only work with the World Model. Inline Brush Models also need to be checked. Turn off depth testing in an engine that does coronas, and have a look through the floor of the episode selection room in Start - you will see the coronas through the floor. They also only do the midpoint, whereas the whole bounding box really needs to be checked. Occlusion queries would be better, but they are slow (owing to having to do a read back), and I'm aiming my minimum specs for slightly lower than cards that can support them.
I have Mike Abrash's "z-sorted spans" code, so another idea would be to build a copy of the Z buffer in software (at a 320 x 240 resolution), and test against that, but I wonder how fast that would be. It doesn't seem to make sense to cut engine speed in half for the sake of a handful of lousy sprites.
I'll probably end up accepting Hull checks and Traces against the midpoint as the best of a bad lot, and extending the code to also support brush models.
Tuesday, February 12, 2008
Fun with Sprites
Posted by
mhquake
at
10:34 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment