Sunday, October 17, 2010

A Decision To Be Made

Previous versions of DirectQ had an FPS lock of 500 FPS in regular game play (it was unlocked in timedemos), but I removed it for 1.8.666b.

I'm thinking of putting it back in. You see, I'm working on separating the timers in the various components, so that the renderer - for example - can run independently of the client and the server, and at it's own speed. This brings some serious problems to light that didn't really exist before, most particularly that things start behaving a little oddly when you exceed 500 FPS, and they behave really oddly when you exceed 1000 FPS.

What kind of things? Well, above 1000 FPS, and because DirectQ uses an integer timer (it's rock-solid and completely immune to accumulated floating point precision errors) we're getting frametimes of 0 most of the time. This means that anything that's time-dependent in the engine (which is pretty much everything) won't actually happen! The biggest culprit so far is the console. Above 1000 FPS it won't come down at all during gameplay! I suspect that there are more, but I haven't seen them yet.

Above 500 FPS we're in a situation where integer division comes into play. Say you're running at 501 FPS; because of integer division, that means that frames get a time of only 1 millisecond, whereas they should be nearer to two. It's not as pronounced as when you're above 1000 FPS, but it still does lead to some jerkiness.

The proposed FPS lock is going to be 250 FPS. At this point integer division is not going to be such a dramatic thing as the differences between points become smaller.

We're clearly in a trade-off situation here. The choice is between a floating point-happy timer that has humungous problems of it's own (accumulated precision loss, based on an unreliable source that may change during gameplay) or an integer timer that has these problems I've just described. I lean towards favouring keeping the timings rock-solid and adding code to prevent the integer timer problems from happening (i.e. an FPS lock). With the floating point timer it's completely out of my control.

Of course, if I can find another solution that doesn't require the FPS lock I'll do it for sure. I already have some ideas for that, but I can't promise anything.

This is going to start becoming a problem for all clients as GPUs get faster, especially in Quake where people like to run at uber-elite FPS, so everyone's going to face this at some time or another.

2 comments:

=peg= said...

Locking fps at 250 sounds reasonable enough to me, I lock my fps at 250 anyway, so.. ;)

Andy said...

I agree with =peg=; 250fps is very much quite reasonable.