On Week 18/2012
Last week preparations for the stable 1.9.8 continued.
Even though Doomsday can render the view at any refresh rate, player controls still operate according to the original 35 Hz internal timing. This ensures that the feel of the controls remains true to the original experience. Mouse move events, however, may occur at any time. This means that extra care needs to be taken so that mouse movement is accurately replicated at the 35 Hz time frame, when the mouse is actually sampling its motion at a much higher frequency.
Because we presently don't allow Doomsday to directly modify player view angles (that is the responsibility of the game's "player thinker") it means mouse move events go through the same pipeline as any other input, and is applied to the player view angles at 35 Hz. This means that mouse motion suffers from temporal jittering, because a varying number of move events is applied during each 35 Hz tick. So far we've been applying a simple filter to the amount of motion to address this problem. However, refactoring of the input subsystem during the 1.9 Betas broke this filtering method.
A new filtering mechanism for mouse input was introduced in build 490. It uses the same 3D movement filter that the multiplayer client uses for interpolating the motion of remote players, and it correctly reproduces the original motion of the mouse. The only drawback is a slight bit of extra latency, because the filter needs to know the mouse position 1/35 seconds in the future before it can start interpolating the position towards it. (Setting input-sharp-lateprocessing to 0 will reduce the latency somewhat.)
The cvar input-toggle-sharp was replaced with input-sharp, as the "sharp" 35 Hz tick processing was extended to apply to mouse axis (and joystick hat) events in addition to keys/button events. It should be noted that mouse motion jittering will occur with "input-sharp 0", as in that mode input events are processed immediately after being received rather than on the next 35 Hz tick.
Another focus area last week was frame update timing. We were experiencing frame skipping with vsync enabled even though the system is capable of running at a much higher frame rate. I fine-tuned the frame updates so that in fullscreen mode, the most accurate timing is applied (with or without vsync). In windowed mode, frame rates may still miss the target as Doomsday does not try to hog the entire system's resources for itself.
I also added buttons in the Control Panel for toggling Vsync and full-scene antialiasing. Clicking on these is equivalent to changing the values of vid-vsync and vid-fsaa.
I want to release the stable 1.9.8 this week, meaning most likely on Sunday. We will spend the week working on fixing as many of the lesser defects as possible and doing some QA. If you've encountered an urgent bug, please let us know in the Candidate Testing thread.
Even though Doomsday can render the view at any refresh rate, player controls still operate according to the original 35 Hz internal timing. This ensures that the feel of the controls remains true to the original experience. Mouse move events, however, may occur at any time. This means that extra care needs to be taken so that mouse movement is accurately replicated at the 35 Hz time frame, when the mouse is actually sampling its motion at a much higher frequency.
Because we presently don't allow Doomsday to directly modify player view angles (that is the responsibility of the game's "player thinker") it means mouse move events go through the same pipeline as any other input, and is applied to the player view angles at 35 Hz. This means that mouse motion suffers from temporal jittering, because a varying number of move events is applied during each 35 Hz tick. So far we've been applying a simple filter to the amount of motion to address this problem. However, refactoring of the input subsystem during the 1.9 Betas broke this filtering method.
A new filtering mechanism for mouse input was introduced in build 490. It uses the same 3D movement filter that the multiplayer client uses for interpolating the motion of remote players, and it correctly reproduces the original motion of the mouse. The only drawback is a slight bit of extra latency, because the filter needs to know the mouse position 1/35 seconds in the future before it can start interpolating the position towards it. (Setting input-sharp-lateprocessing to 0 will reduce the latency somewhat.)
The cvar input-toggle-sharp was replaced with input-sharp, as the "sharp" 35 Hz tick processing was extended to apply to mouse axis (and joystick hat) events in addition to keys/button events. It should be noted that mouse motion jittering will occur with "input-sharp 0", as in that mode input events are processed immediately after being received rather than on the next 35 Hz tick.
Another focus area last week was frame update timing. We were experiencing frame skipping with vsync enabled even though the system is capable of running at a much higher frame rate. I fine-tuned the frame updates so that in fullscreen mode, the most accurate timing is applied (with or without vsync). In windowed mode, frame rates may still miss the target as Doomsday does not try to hog the entire system's resources for itself.
I also added buttons in the Control Panel for toggling Vsync and full-scene antialiasing. Clicking on these is equivalent to changing the values of vid-vsync and vid-fsaa.
I want to release the stable 1.9.8 this week, meaning most likely on Sunday. We will spend the week working on fixing as many of the lesser defects as possible and doing some QA. If you've encountered an urgent bug, please let us know in the Candidate Testing thread.