DirectQ 1.8.666b has a bottleneck that 1.8.666a didn't have. A week ago it wasn't there in 1.8.666b either, so it's obviously something that happened in that time. What could it possibly be?
The answer lies in the timer. Because Quake's timers use floating point they are subject to precision loss. For some time now DirectQ has used integers on a millisecond scale all the way through to avoid this precision loss, only converting back to floating point at the very last possible moment and only where it is needed (typically by the progs.dat). However, for 1.8.666b I had made the mistake of going back and switching all the timers back to floating point for the sake of "keeping the code clean".
BIG MISTAKE.
The primary cause of the problem seems to have been in the main loop, where I had two DWORD timers that I had switched back to FP. Reverting these to the way that they were resolves things to a large extent. Reverting elsewhere throughout the code fixes everything else up nicely, and we're back to enjoying super-high framerates. Double-checking before and after with FRAPS confirms it.
________________________
Because of all this my warning about 1.8.666b now holds doubly-true. It should be considered as not much more than a techdemo of fog in shaders, with 1.9 going to be the Real Thing.
Wednesday, October 13, 2010
A Nasty Bottleneck and it's Scandalous Secret Uncovered
Posted by
mhquake
at
12:55 AM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment