It turned out to be quite easy after all. It's been possible to substantially accelerate the subdivided rendering, so you should be able to start with a gl_subdivide_size of 24 and still get reasonably decent performance. One key factor about this engine is that heavy surface tesselation does NOT have as huge a performance impact as before. It takes a short while to drop one's paranoia about this, but it's seriously liberating to realise that you can now run just about anything far more efficiently (sometimes up to 7 times as fast) than before.
I'm taking a short break from the renderer to work on DirectQ's timers. Standard Win/GL Quake used QueryPerformanceFrequency and QueryPerformanceCounter which - while incredibly accurate - were somewhat responsible for uneven timings here and there. ID moved to timeBeginPeriod and timeGetTime for QuakeWorld and retained them in QuakeII, and I had moved to the same for DirectQ 1.7, but only in the Sys_FloatTime function. This gave a timer with integer millisecond accuracy and was rock-solid at that point, but was slightly subject to FPU drift as times went along the chain and rounding errors accumulated.
My motivation for this at the time was to enable me to drop the D3DCREATE_FPUPRESERVE flag from my video initialization, which was otherwise required to preserve the accuracy of Quake's timers (otherwise things would go really screwy and we'd slow down to half speed over the course of a few minutes).
For 1.8 I'll be using DWORD millisecond values all the way through the chain up the final parts where unfortunately it will need to be converted to floating point. This will totally preserve the timer accuracy as much as possible and should give a nice end result.
One side-effect of this is that DirectQ will now be subject to the same old timer wraparound bug as Windows 95 and 98 were, where we'll go into "undefined behaviour" territory if DirectQ is running at precisely the moment when the system it's on ticks over from 47.something days uptime. It will only happen at precisely that moment, and afterwards everything will settle back down.
I might do an experimental setup to reproduce this situation and see what I can do to work around it, but I wouldn't anticipate that too many people will be affected by it.
Friday, January 8, 2010
Non-HLSL Water Warp is Done
Posted by
mhquake
at
1:34 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment