Monday, May 16, 2011

DirectQ Update - 16th May 2011

I've taken another pass through the whole timer and timer decoupling code, and now have a much better, more stable and more flexible solution. Instead of being hacked together based on a best-guess, this one is actually based on the proper documented way of doing this stuff, which is nice. There are still lots of subtleties with Quake's timing (I'll be mentioning one later) so it's still somewhat in the experimental/disabled-by-default bracket, but I can confidently say that I'm now at the stage where I can see it becoming the hard-coded enforced behaviour at some time in the future.

Particles have been worked over some more, and a lot of what I wrote about a coupla days back is now totally overturned. There is no longer any particle texture in the engine (and therefore no quality cvar to control it): instead it's entirely generated on the GPU which gives extremely high quality up-close but scales back beautifully when particles are further away. It's a mite slower in some circumstances but faster in others, and overall I think the quality tradeoff is well worth it.

The only thing relating to particles left on the CPU is now velocity and position updates; everything else is GPU-side.

Speaking of particles, that timer subtlety I mentioned rears it's ugly head here. It turns out that when running at a high framerate and connected to a remote server (or playing a demo) a lot more particles are being generated than when running at a lower framerate (which is the cause of a preformance problenm too). You can see this yourself by checking out the lava ball trail in the Start map at different values of host_maxfps. One solution is to use timer decoupling to scale back the rate at which particles are generated to a constant rate irrespective of framerate.

My proposed breaking change to the video code is likely going to be deferred for a while; I've reviewed the code and made a first attempt (which I very quickly reverted from), and it's quite obvious that the whole startup code is a mess that probably needs to be gutted and rewritten more than anything else. A huge part of the reason for that is that much of it dates back to my original D3D port and has been hacked around to make things work rather than being properly implemented.

All in all an interesting batch of updates.

1 comments:

Anonymous said...

Hi friends, download the latest version, but I find the sound options "Sample rating, for making the sound 44100 Hz, any idea on this, Greetings