Recently I've been experimenting a little more with Quake's timers. One of the primary reasons for this is that I recently bought a new machine to replace the old PC that had died on me, and I was interested in seeing how the old QueryPerformanceCounter problems fared on this. This is arising out of a dissatisfaction with timeGetTime having a resolution of 1 millisecond, mainly because Quake's default framerate (72) doesn't divide into 1000 evenly.
The end result was certainly interesting. With the first test I tried (the original release of DirectQ, back when I was calling it "D3DQuake") I got a really bizarre waltz, as timing speed seemed to see-saw back and forth alarmingly. Quickly switching it over to timeGetTime resolved this immediately, so obviously QPC is still a no-go area on at least one bang-up-to-date, 8-core 64-bit Windows 7 machine.
DirectQ itself uses timeGetTime, but it also contains (disabled) code allowing it to use QPC, so I enabled that and tested, with no ill-effects. Likewise the other engines I've tested that also use QPC worked fine. There's obviously something else at work there, but in the absence of fuller knowledge of what it was I'm inclined to say "steer away from QPC".
While I had the QPC code enabled in DirectQ I also played around a little with max framerates. DirectQ has historically limited it's max FPS to 500, because with an integer millisecond timer anything greater than 500 will round down to 1. So if you're running at even 501 FPS it will round down to 1 millisecond, and give you odd behaviour.
So I removed this cap, and things went totally haywire! The reason for this one was that there is code in Host_FilterTime (inherited from original ID Quake) to lower-bound frametimes to 0.001 seconds. When you're running at over 1,000 FPS this is obviously not a desirable thing to have.
In the end I saw a maximum speed of about 14,400 FPS under idealised conditions. That was fun. At that kind of speed you're obviously in no-man's land with Quake, and all bets are off so far as physics behaviour is concerned (all bets are also off so far as anything even remotely approaching accuracy of the FPS counter, by the way, because we're in frametime territory where even a minor rounding error will become significant).
Interestingly, I was also giving my server throttling code (from here) a bit of a shakedown in DirectQ, and even at a few thousand FPS it still managed to maintain correct physics in Quake, so it looks good and has passed an important test.
More on RMQ progress next time!
Saturday, September 11, 2010
More fun with timers
Posted by
mhquake
at
2:13 AM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment