Bindings Abound
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Beta 6, Engine.</i>
I have just committed our new bindings system (revision 4914). I ended up rewriting the whole thing from the ground up, including binding classes and the traditional command bindings. It's not yet quite done: some API functions and the console command interface are missing, for instance. However, it's already functional enough that a numeric player control named "turn" in the class "game" can be registered, and read by <tt>P_PlayerThinkLookAround()</tt>.
Furthermore, the debug code currently hard-coded in <tt>B_Init()</tt> defines three ways to turn the player: with the Left and Right keys, the mouse X axis and the joystick X axis. These can all be used independently of one another. The game calls <tt>P_GetControlState()</tt>, which combines all the bound devices to form the final turn values for the player. The speed of the turning does not yet conform to the standard Doom speed, but it has the requisite two-stage acceleration for the keys.
One cool new feature of the bindings system is state conditions. For example, you can bind Shift+Tilde or Ctrl+Shift+PgUp, or create a device binding that is only in effect if a specific joystick button is being held down.
What I've written conforms to the design on the <a href="http://dengine.net/dew/index.php?title=Player_controls">wiki page</a>.
I'll keep working on getting the rest of necessary functionality done.
Danij, you'll need to update the Win32 project files with the new <tt>b_*</tt> sources.
I have just committed our new bindings system (revision 4914). I ended up rewriting the whole thing from the ground up, including binding classes and the traditional command bindings. It's not yet quite done: some API functions and the console command interface are missing, for instance. However, it's already functional enough that a numeric player control named "turn" in the class "game" can be registered, and read by <tt>P_PlayerThinkLookAround()</tt>.
Furthermore, the debug code currently hard-coded in <tt>B_Init()</tt> defines three ways to turn the player: with the Left and Right keys, the mouse X axis and the joystick X axis. These can all be used independently of one another. The game calls <tt>P_GetControlState()</tt>, which combines all the bound devices to form the final turn values for the player. The speed of the turning does not yet conform to the standard Doom speed, but it has the requisite two-stage acceleration for the keys.
One cool new feature of the bindings system is state conditions. For example, you can bind Shift+Tilde or Ctrl+Shift+PgUp, or create a device binding that is only in effect if a specific joystick button is being held down.
What I've written conforms to the design on the <a href="http://dengine.net/dew/index.php?title=Player_controls">wiki page</a>.
I'll keep working on getting the rest of necessary functionality done.
Danij, you'll need to update the Win32 project files with the new <tt>b_*</tt> sources.
Comments
Do you plan to implement a binding class and ccmds for the controls currently in Con_Responder()?
I've updated the VC project files and vcbuild with the new source files, though I see I have some work to do on the DirectX-based input and the dedicated console still.
<blockquote>DirectX-based input</blockquote>Yeah, at least the data structures for retrieving input device state have changed quite a bit.
Instead of having this responder game-side, a ccmd could be used which puts Doomsday in a "wait for input" state (something akin to the busy mode) and passes the name of the logical control to be bound.
Whilst in this special state, events are NOT sent down the normal responder chain and are instead converted to their textual representation and then sent to something similar to B_BindControl() before then returning to normal state (unless of course it is the "abort event grabbing event").
I suggest that in order to be able to bind all possible combinations of keys plus control state modifiers; we require that the chosen combination be held for x seconds rather than reacting to the first event generated.
During this special "wait for input" state, if we used a similar mechanism to busy mode we could show some pretty graphics and status indicators to denote that we are waiting for the user (an indicator similar to the gear in style would be nice), held device+ key/axis names would be nifty too.
<ol>
<li>UI activates the "grab events in text format" mode. Instead of events progressing through the normal chain, they will be added in text format to a buffer.
<li>UI waits until buffered textual events are available.
<li>User accepts the offered binding.
</ol>
We shouldn't have some arbitrary time that the user must hold the keys (annoying...).
It seems to me that a GUI that would allow creating a binding of any imaginable possibility supported by the system cannot be done with a simple "grab" paradigm.
Maybe not all possible combinations could be supported via a "grab" paradigm but the most import paramater (the basic event templates) could be. After the grab a pop-up dialog could detail any extended paramaters available/required, which the user could adjust manually if need be (e.g. inverting axis binds).