Controls Mechanism in 1.9.x
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Engine, Games, jDoom, jHeretic, jHexen, Mac OS X, Unix/Linux, Windows.</i>
As I'm sure you have noticed the in-game control mechanism is currently not working. This is because I have begun porting the engine-side management for controls and device axes from the old 1.8.0 experimental branch.
<strong>Status of this work:</strong>
The code for managing the device axes themselves (in dd_input.c) is not final. The new code for device axis delta smoothing created by skyjake needs to be re-implemented in a generic way so that it works for ALL axis controls and not just mouse X/Y.
I have implemented a simple ccmd "setaxis" which can be used for configuring the paramaters of axis controls. This is a temporary solution and will be replaced/augmented with a UI based solution in the Doomsday Control Panel.
We have a new interface which allows the game to register all controls it requires for user input into the engine at start up. This interface along with bindclass registration mechanism should offer all the features needed to descript the various control systems required in the game.
The way input events are passed around the engine has not changed too much, though the event_t structure is now only used game-side. Engine-side, we use a new structure called ddevent_t which contains ALL the information available about the event in addition to required meta such as the device the event is coming from. Each time the position value of a device axis changes; a ddevent_t is generated and sent down the responder chain.
The intergration of the engine-side device axes into the console bindings mechanism has been completed and new console commands have been added to facilitate their management. This includes the collecting of device axis events in the bindings responder. The bindings mechanism has also been enhanced with support for multiple local players. This means that all ccmds used for binding managment can now have a "/#" suffix to the control descriptor to specify the player number to affect. If a suffix is omitted, then default to player #0.
The management of the bindings themselves works pretty much identically as it did previously. Bindings for both events and axes are written to the game-specific config at engine shutdown and read again during init. There is a small issue with this; due to the configs being parsed before the input devices are enumerated a kludge is used where instead of binding an axis directly, the task is deferred by using the In X ccmd (where x is a number of seconds).
<strong>What needs to be done:</strong>
The old game-side menus for managing control bindings have been completely removed, as have the game-side controls affecting device axes (such as sensitivity and axis disabling). These need to be replaced with an engine-side UI for managing the control and axis bindings.
Ticcmd generation does not appear to be working correctly currently. There is a noticeable lag in non-axis based controls (the good news is, we are already generating rebound packets).
Formating of ticcmd_t needs to be extendable to allow supported games to add additional controls.
The control command syntax needs to be looked at. Currently we have a destinction for ++/+/---/- modifiers for axes which is quite complicated. I think it would be preferable to use the same modifiers as used for the impulses.
Player profiles need to be considered. These are vital for a unified client-server setup in singleplayer.
As I'm sure you have noticed the in-game control mechanism is currently not working. This is because I have begun porting the engine-side management for controls and device axes from the old 1.8.0 experimental branch.
<strong>Status of this work:</strong>
The code for managing the device axes themselves (in dd_input.c) is not final. The new code for device axis delta smoothing created by skyjake needs to be re-implemented in a generic way so that it works for ALL axis controls and not just mouse X/Y.
I have implemented a simple ccmd "setaxis" which can be used for configuring the paramaters of axis controls. This is a temporary solution and will be replaced/augmented with a UI based solution in the Doomsday Control Panel.
We have a new interface which allows the game to register all controls it requires for user input into the engine at start up. This interface along with bindclass registration mechanism should offer all the features needed to descript the various control systems required in the game.
The way input events are passed around the engine has not changed too much, though the event_t structure is now only used game-side. Engine-side, we use a new structure called ddevent_t which contains ALL the information available about the event in addition to required meta such as the device the event is coming from. Each time the position value of a device axis changes; a ddevent_t is generated and sent down the responder chain.
The intergration of the engine-side device axes into the console bindings mechanism has been completed and new console commands have been added to facilitate their management. This includes the collecting of device axis events in the bindings responder. The bindings mechanism has also been enhanced with support for multiple local players. This means that all ccmds used for binding managment can now have a "/#" suffix to the control descriptor to specify the player number to affect. If a suffix is omitted, then default to player #0.
The management of the bindings themselves works pretty much identically as it did previously. Bindings for both events and axes are written to the game-specific config at engine shutdown and read again during init. There is a small issue with this; due to the configs being parsed before the input devices are enumerated a kludge is used where instead of binding an axis directly, the task is deferred by using the In X ccmd (where x is a number of seconds).
<strong>What needs to be done:</strong>
The old game-side menus for managing control bindings have been completely removed, as have the game-side controls affecting device axes (such as sensitivity and axis disabling). These need to be replaced with an engine-side UI for managing the control and axis bindings.
Ticcmd generation does not appear to be working correctly currently. There is a noticeable lag in non-axis based controls (the good news is, we are already generating rebound packets).
Formating of ticcmd_t needs to be extendable to allow supported games to add additional controls.
The control command syntax needs to be looked at. Currently we have a destinction for ++/+/---/- modifiers for axes which is quite complicated. I think it would be preferable to use the same modifiers as used for the impulses.
Player profiles need to be considered. These are vital for a unified client-server setup in singleplayer.
Comments
Another thing is that all the bindings need to be automatically saved to (game).cfg when exiting. Is that working as previously?
The cvars affecting player settings are currently hard-wired to work only player 0. In order to support multiple local players this means that they, as well as the player specific control bindings need to be collected together into a player config of some description.
So, we can have a bindings .cfg file where there is:
<pre>
activeplayer 0
bind ...
bind ...
bind ..
activeplayer 1
bind ..
bind ..
etc.
</pre>
Now that I think of it, we already have the concept of a "consoleplayer", which is the current player being controlled by the local console. Wouldn't it be enough if we just changed the consoleplayer whenever necessary? There should already by a "setcon" command existing (IIRC).
bind .../2 (would bind the control JUST for player #2)
The only remaining subsystems game-side which need updating for multiple local players is cfg management and HUD displays (but I've got a local development branch where I've resolved the later).
The ticcmd data packet send over the network should be somehow generated dynamically out of the registered controls (from controls.cfg), with a bunch of fields with an integer ID, and a list of impulse IDs.
It would have been yes but I decided to bite the bullet and implement it fully for each bind command. To make clear; that particular job is completed.
<blockquote>Hold on, I’m actually thinking we shouldn’t be sending ticcmds over the network at all…</blockquote>
Please explain.