Music. Coding. Gaming. Life.

The problem with mice in Descent

Posted Wednesday, May 6th, 2015 7:07:00 am
Descent was an awesome series. Hell, it still IS an awesome series. Six degrees of freedom, claustrophobic tunnels, murderous robots... what's not to love about this game?

The fact that it was made in 1995 for one. Originally written for MS-DOS, Descent was designed to run on computers that didn't know what a Pentium was. It ran great on those computers, but as computer processing power increased, it started to become obvious that the game was not written to scale well.

At first, the homing missile became impossible to dodge. Written to work fine at 30 frames per second, the homing missile began to turn faster and faster as that 30 became 60, 60 became 100, and 100 became 200. Fortunately, this bug has been fixed and has made playing Descent quite bearable.

However, recently, a new bug reared its ugly head involving mouse play. Descent plays at a constant 200 frames per second, assuming you don't have vsync on, or have otherwise limited the frame rate. The average mouse in Windows is only polled at the rate of 125 times per second. So, your graphics card is getting more frames per second than Windows is getting mouse positions. How does this cause problems in Descent?

One of the quirks about Descent is that, unlike traditional first person shooters, you are not allowed to just 180 your ship in an instant. The Pyro has a maximum turn rate, and is hard-limited in the code, throwing out extra movements that are made beyond the maximum allowed. This means that you can whip your mouse around the mousepad, and you won't move very much.

The turn rate for the mouse, however, is determined per frame. So, what'll happen is you'll move the mouse, say, an inch, within 2 frames. You only need to move it, say, a quarter of an inch to reach maximum turn speed. At the end of the first frame, the first quarter of an inch is processed and the next quarter of an inch is thrown out. Same thing for the second frame, the next quarter of an inch is processed and the final quarter of an inch is thrown out.

However, let's say in the first frame, your mouse didn't get polled at all. At the end of the first frame, Descent - and Windows for that matter - think you haven't moved the mouse. Your Pyro does not move at all. In the second frame, the mouse is polled and sees you moved an entire inch. The first quarter of an inch is processed, and the other three quarters are thrown out. All that movement for nothing!

Having a fellow pilot suffer greatly because of these issues, I decided to dive into the source code and develop a fix. Now what happens is that you turn on the Mouse Overrun Buffer setting, and then instead of throwing out the extra movements of your mouse, it is stored in a buffer, with anywhere between 1/16 of a second and a full second of movement stored, depending on how high you decide to set your buffer. Then, in the next frame, anything already in your buffer is added to whatever mouse movement was detected that frame, and that is used to determine how much your pyro moves, storing any excess back into the buffer again.

You can find this code in a pull request for DXX-Retro, a source port of Descent dedicated to the competitive community. If you own the original game, you can find downloads for DXX-Retro at the Descent Rangers download page.

And if you don't, go get it! Classic first-person shooter action.

Comments

Loading...
roncli.com Media Player