Absolute and Relative Controls

edited 2007 Jul 24 in Developers
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Beta 6, Engine, Games.</i>

There is something I am not understanding about your control system, Danij. How do you take into account that some devices are inherently positionless (like the mouse), where only the sum of the traveled distance is meaningful, while some are defined within an absolute range of valid positions (like a joystick)? To me these are two different types of axes, and have to be treated slightly differently.

In particular, while you can take an absolute axis's current position and treat it as the speed of change at the current time (say, for the "turn" control, the current position would directly translate to how fast you're turning — to figure out how much to turn, you would multiply this value with the amount of elapsed time), but with the mouse this is not possible. When you have the mouse bound to the "turn" control, you will instead receive the exact number of mickeys that you are supposed to turn, so they translate directly to an immediate change in the look direction, and in effect have the elapsed time embedded in them already.

In other words, the former method is the way absolute axis controls should be handled, while the latter is for the relative axis controls.

Also, from your code I've gathered that a toggle will override what's happening on the axis: for example, if I turn with the "Left" key while looking around with the mouse, the movements of the mouse would be ignored. I find this unacceptable. The correct way would be handle these in parallel, and sum up the resulting change in the look direction.

So, there are two issues here: 1) How does your control system handle absolute vs. relative controls? and 2) The overriding thing should go.

Comments

  • Actually, I didn't write that code.

    The code in question was ported directly from the old 1.8 experimental branch which I believe you (skyjake) wrote, so I had assumed you had already been through the whole design process.

    I had made similar observations while porting it... perhaps you could explain it to me :-)

    About summing axis controls: we need to be particularly carefull that we retain the old DOOM behavior which allows for the various control peculiarities which are a vital part of the feel of the game. For example, the various strafe run "stages" (more info can be read <a href="http://www.doom2.net/doom2/sr50.html">HERE</a&gt; and <a href="http://www.bluesnews.com/doomtips/">HERE</a>).
  • My memory fails me, I see. I had absolutely no recollection that I had written that code three years ago. :) That does not convince me as to its validity, though...

    At a minimum we need to be able to use multiple axes/toggles as input when considering the value of a particular control. For example, in case of the "turn" control, one should be able to bind the mouse X axis, the Left and Right keys, and the Joystick X axis all at the same time to the one control. And when it comes time to query the state of this control, the engine should provide the game with a single value, that is produced as the clamped sum of all the bound input axes and toggles.

    The current code needs some work to make this possible. Guess I'll be continuing my (much) earlier work, then.
Sign In or Register to comment.