Wednesday, March 23, 2011

DirectQ Update - 23rd March 2011

Been fine-tuning the timers and framerate decoupling quite a bit, which is really a matter of ensuring that everything is working off the correct timer, which circumstances to use which timers in, that all subsytems have their time and frametime correctly isolated, and that any assumptions I may have made are valid.

Interesting things are coming out of this exercise.

Some of the client-side subsystems need to run off the server-side timer. In particular I'm talking about stuff like particle updates and the old view.c stuff. These are heavily framerate dependent, and running off the (potentially) faster client-side timer causes problems for them.

In timedemo mode the client time is advancing faster than the client timer, so it needs lots of special handling.

For stuff like sound updates it makes sense to run them off the slower timer. You don't need to update your sound buffers 250 or more times per second; 72 is plenty, thanks. There's a good performance improvement in this too.

If a game isn't currently active you can just drop back to the slower timer, irrespective of the value of host_maxfps.

For multiplayer games reverting everything back to the original way seems to make sense.

I'll probably ship a release sometime later on this week or early next week with an experimental first cut of this in, but it will be disabled by default and you'll need to opt-in. host_decoupletimers 1 will be what you need, and as it's an experimental first cut you shouldn't be too upset if things don't work 100% right.

On the input front I've been pondering some on pitch drifting. This is an old relic of the days of keyboard looking, and of having to hold down a "look" key, and is the means why which your view automatically re-centers over time. I'd really love to take a knife to this code, but I suspect that there may still be valid cases where it's useful to have (I'm thinking joysticks and controllers) so for now I'll just disable it completely if we're mouselooking. Of course this should happen automatically anyway, but with everything potentially running at different framerates it just seems to make more sense to handle it more explicitly.

More later.

1 comments:

Ezerhordren said...

I wonder how nobody talked about the imput bit in your updates, I was trying to see if I could bind mouselook or kblook to the analog stick on my joypad, (im using 3 different controllers, PSone, xbox360 and genius usb one) to play quake oldstyle, this kind of shooters can be played really fine with joysticks, but it would be better if we could use one of the analog sticks to look around or to aim... that would be sweet! Btw, it was ling time since I used DirectQ (was having fun with gamemaker) and the new release is the shit!! my old notebook can run Q1 at the best resolution with all effects to the max at 60fps (intel 945 here)

thanks for all the work on the engine, it's amazing!