qf/quakeforge
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/quakeforge synced 2024-11-26 14:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
quakeforge/include/QF/input/imt.h

146 lines
4.2 KiB
C
Raw Normal View History

[input] Make a start on the new binding system Input Mapping Tables are still at the core as they are a good concept, however they include both axis and button mappings, and the size is not hard-coded, but dependent on the known devices. Not much actually works yet (nq segfaults when a key is pressed).
2021-11-03 10:02:39 +00:00
/*
imt.h
Input Mapping Table management
Copyright (C) 2001 Zephaniah E. Hull <warp@babylon.d2dc.net>
Copyright (C) 2021 Bill Currie <bill@taniwha.org>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to:
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307, USA
*/
#ifndef __QF_input_imt_h
#define __QF_input_imt_h
[dox] Fix up some doxygen issues I found a few doxygen related patches in my git stash and while testing them, found a few doc issues.
2022-04-12 12:01:41 +00:00
/** \defgroup input_imt Input Mapping Tables
\ingroup input
*/
///@{
[input] Make a start on the new binding system Input Mapping Tables are still at the core as they are a good concept, however they include both axis and button mappings, and the size is not hard-coded, but dependent on the known devices. Not much actually works yet (nq segfaults when a key is pressed).
2021-11-03 10:02:39 +00:00
#ifndef __QFCC__
#include "QF/darray.h"
[console] Hook up new input system This has smashed the keydest handling for many things, and bindings, but seems to be a good start with the new input system: the console in qw-client-x11 is usable (keyboard-only). The button and axis values have been removed from the knum_t enum as mouse events are separate from key events, and other button and axis inputs will be handled separately. keys.c has been disabled in the build as it is obsolute (thus much of the breakage).
2021-11-08 02:20:04 +00:00
#include "QF/qtypes.h"
[input] Make a start on the new binding system Input Mapping Tables are still at the core as they are a good concept, however they include both axis and button mappings, and the size is not hard-coded, but dependent on the known devices. Not much actually works yet (nq segfaults when a key is pressed).
2021-11-03 10:02:39 +00:00
#include "QF/input/binding.h"
/** Input Mapping Table
*/
typedef struct imt_s {
struct imt_s *next; ///< list of tables attached to key_dest
struct imt_s *chain; ///< fallback table if input not bound
const char *name; ///< for user interaction
int written;
struct DARRAY_TYPE (in_axisbinding_t *) axis_bindings;
struct DARRAY_TYPE (in_buttonbinding_t *) button_bindings;
} imt_t;
[input] Create an automatic imt switcher An imt switcher automatically changes the context's active imt based on a user specified list of binary inputs. The inputs may be either buttons (indicated as +button) or cvars (bare name). For buttons, the pressed/not pressed state is used, and cvars are interpreted as ints being 0 or not 0. The order of the inputs determines the bit number of the input, with the first input being bit 0, second bit 1, third bit 2 etc. A default imt is given so large switchers do not need to be fully configured (the default imt is written to all states). A context can have any number of switchers attached. The switchers can wind up fighting over the active imt, but this seems to be something for the "user" (eg, configuration system) to sort out rather than the switcher code enforcing anything. As a result of the inputs being treated as bits, a switcher with N inputs will have 2**N states, thus there's a maximum of 16 inputs for now as 65536 states is a lot of configuration. Using a switcher, setting up a standard strafe/mouse look configuration is fairly easy. imt_create key_game imt_mod imt_create key_game imt_mod_strafe imt_mod imt_create key_game imt_mod_freelook imt_create key_game imt_mod_lookstrafe imt_mod_freelook imt_switcher_create mouse key_game imt_mod_strafe +strafe lookstrafe +mlook freelook imt_switcher 0 imt_mod 2 imt_mod 4 imt_mod_freelook 8 imt_mod_freelook 12 imt_mod_freelook imt_switcher 6 imt_mod_lookstrafe 10 imt_mod_lookstrafe 14 imt_mod_lookstrafe in_bind imt_mod mouse axis 0 move.yaw in_bind imt_mod mouse axis 1 move.forward in_bind imt_mod_strafe mouse axis 0 move.side in_bind imt_mod_lookstrafe mouse axis 0 move.side in_bind imt_mod_freelook mouse axis 1 move.pitch This takes advantage of imt chaining and the default imt for the switcher (there are 8 states that use imt_mod_strafe). The switcher name must be unique across all contexts, and every imt used in a switcher must be in the switcher's context.
2021-11-25 09:01:07 +00:00
typedef enum {
imti_button,
imti_cvar,
} imt_input_type;
typedef struct imt_input_s {
imt_input_type type;
union {
struct in_button_s *button;
struct cvar_s *cvar;
};
} imt_input_t;
typedef struct imt_switcher_s {
struct imt_switcher_s *next;
const char *name;
int num_inputs;
imt_input_t *inputs; // one per input
imt_t **imts; // 2**(num_inputs)
struct in_context_s *context;
} imt_switcher_t;
[input] Make a start on the new binding system Input Mapping Tables are still at the core as they are a good concept, however they include both axis and button mappings, and the size is not hard-coded, but dependent on the known devices. Not much actually works yet (nq segfaults when a key is pressed).
2021-11-03 10:02:39 +00:00
typedef struct in_context_s {
[input] Implement several binding commands in_bind is only partially implemented (waiting on imt), but device listing, device naming, and input identification are working. The event handling system made for a fairly clean implementation for input identification thanks to the focused event handling.
2021-11-08 06:38:26 +00:00
const char *name;
[input] Make a start on the new binding system Input Mapping Tables are still at the core as they are a good concept, however they include both axis and button mappings, and the size is not hard-coded, but dependent on the known devices. Not much actually works yet (nq segfaults when a key is pressed).
2021-11-03 10:02:39 +00:00
imt_t *imts;
imt_t **imt_tail;
imt_t *active_imt;
imt_t *default_imt;
[input] Create an automatic imt switcher An imt switcher automatically changes the context's active imt based on a user specified list of binary inputs. The inputs may be either buttons (indicated as +button) or cvars (bare name). For buttons, the pressed/not pressed state is used, and cvars are interpreted as ints being 0 or not 0. The order of the inputs determines the bit number of the input, with the first input being bit 0, second bit 1, third bit 2 etc. A default imt is given so large switchers do not need to be fully configured (the default imt is written to all states). A context can have any number of switchers attached. The switchers can wind up fighting over the active imt, but this seems to be something for the "user" (eg, configuration system) to sort out rather than the switcher code enforcing anything. As a result of the inputs being treated as bits, a switcher with N inputs will have 2**N states, thus there's a maximum of 16 inputs for now as 65536 states is a lot of configuration. Using a switcher, setting up a standard strafe/mouse look configuration is fairly easy. imt_create key_game imt_mod imt_create key_game imt_mod_strafe imt_mod imt_create key_game imt_mod_freelook imt_create key_game imt_mod_lookstrafe imt_mod_freelook imt_switcher_create mouse key_game imt_mod_strafe +strafe lookstrafe +mlook freelook imt_switcher 0 imt_mod 2 imt_mod 4 imt_mod_freelook 8 imt_mod_freelook 12 imt_mod_freelook imt_switcher 6 imt_mod_lookstrafe 10 imt_mod_lookstrafe 14 imt_mod_lookstrafe in_bind imt_mod mouse axis 0 move.yaw in_bind imt_mod mouse axis 1 move.forward in_bind imt_mod_strafe mouse axis 0 move.side in_bind imt_mod_lookstrafe mouse axis 0 move.side in_bind imt_mod_freelook mouse axis 1 move.pitch This takes advantage of imt chaining and the default imt for the switcher (there are 8 states that use imt_mod_strafe). The switcher name must be unique across all contexts, and every imt used in a switcher must be in the switcher's context.
2021-11-25 09:01:07 +00:00
imt_switcher_t *switchers;
imt_switcher_t **switcher_tail;
[console] Hook up new input system This has smashed the keydest handling for many things, and bindings, but seems to be a good start with the new input system: the console in qw-client-x11 is usable (keyboard-only). The button and axis values have been removed from the knum_t enum as mouse events are separate from key events, and other button and axis inputs will be handled separately. keys.c has been disabled in the build as it is obsolute (thus much of the breakage).
2021-11-08 02:20:04 +00:00
struct cbuf_s *cbuf;
[input] Make a start on the new binding system Input Mapping Tables are still at the core as they are a good concept, however they include both axis and button mappings, and the size is not hard-coded, but dependent on the known devices. Not much actually works yet (nq segfaults when a key is pressed).
2021-11-03 10:02:39 +00:00
} in_context_t;
[input] Clean up imt.h a little Unnecessary enum removed, and the imt block struct moved to imt.c (doesn't need to be public). Also, remove device name from the imt block (and thus the parameter to the functions) as it turns out not to be needed.
2021-11-09 13:23:57 +00:00
int IMT_GetAxisBlock (int num_axes);
int IMT_GetButtonBlock (int num_buttons);
[input] Implement several binding commands in_bind is only partially implemented (waiting on imt), but device listing, device naming, and input identification are working. The event handling system made for a fairly clean implementation for input identification thanks to the focused event handling.
2021-11-08 06:38:26 +00:00
int IMT_CreateContext (const char *name);
Fix some optimization warnings
2021-11-11 06:43:07 +00:00
int IMT_GetContext (void) __attribute__ ((pure));
[console] Hook up new input system This has smashed the keydest handling for many things, and bindings, but seems to be a good start with the new input system: the console in qw-client-x11 is usable (keyboard-only). The button and axis values have been removed from the knum_t enum as mouse events are separate from key events, and other button and axis inputs will be handled separately. keys.c has been disabled in the build as it is obsolute (thus much of the breakage).
2021-11-08 02:20:04 +00:00
void IMT_SetContext (int ctx);
void IMT_SetContextCbuf (int ctx, struct cbuf_s *cbuf);
[input] Move some IMT documentation And update to reflect some of the changed concepts (context vs keydest)
2021-11-27 03:01:07 +00:00
/** Find an Input Mapping Table by name.
Searches through all contexts for the named imt. The search is case
insensitive.
Fix some doxygen warnings
2021-12-25 02:17:33 +00:00
\param name The name of the imt to find. Case insensitive.
[input] Move some IMT documentation And update to reflect some of the changed concepts (context vs keydest)
2021-11-27 03:01:07 +00:00
\return The named imt, or null if not found.
*/
[input] Fix incorrect placement of pure attribute Should be on the prototype, not definition (for public functions).
2021-11-14 01:10:39 +00:00
imt_t *IMT_FindIMT (const char *name) __attribute__ ((pure));
[input] Create an automatic imt switcher An imt switcher automatically changes the context's active imt based on a user specified list of binary inputs. The inputs may be either buttons (indicated as +button) or cvars (bare name). For buttons, the pressed/not pressed state is used, and cvars are interpreted as ints being 0 or not 0. The order of the inputs determines the bit number of the input, with the first input being bit 0, second bit 1, third bit 2 etc. A default imt is given so large switchers do not need to be fully configured (the default imt is written to all states). A context can have any number of switchers attached. The switchers can wind up fighting over the active imt, but this seems to be something for the "user" (eg, configuration system) to sort out rather than the switcher code enforcing anything. As a result of the inputs being treated as bits, a switcher with N inputs will have 2**N states, thus there's a maximum of 16 inputs for now as 65536 states is a lot of configuration. Using a switcher, setting up a standard strafe/mouse look configuration is fairly easy. imt_create key_game imt_mod imt_create key_game imt_mod_strafe imt_mod imt_create key_game imt_mod_freelook imt_create key_game imt_mod_lookstrafe imt_mod_freelook imt_switcher_create mouse key_game imt_mod_strafe +strafe lookstrafe +mlook freelook imt_switcher 0 imt_mod 2 imt_mod 4 imt_mod_freelook 8 imt_mod_freelook 12 imt_mod_freelook imt_switcher 6 imt_mod_lookstrafe 10 imt_mod_lookstrafe 14 imt_mod_lookstrafe in_bind imt_mod mouse axis 0 move.yaw in_bind imt_mod mouse axis 1 move.forward in_bind imt_mod_strafe mouse axis 0 move.side in_bind imt_mod_lookstrafe mouse axis 0 move.side in_bind imt_mod_freelook mouse axis 1 move.pitch This takes advantage of imt chaining and the default imt for the switcher (there are 8 states that use imt_mod_strafe). The switcher name must be unique across all contexts, and every imt used in a switcher must be in the switcher's context.
2021-11-25 09:01:07 +00:00
imt_switcher_t *IMT_FindSwitcher (const char *name) __attribute__ ((pure));
[input] Move some IMT documentation And update to reflect some of the changed concepts (context vs keydest)
2021-11-27 03:01:07 +00:00
/** Create a new imt and attach it to the specified context.
The name of the new imt must be unique (case insensitive) across all
contexts. This is to simplify the in_bind command.
If \a chain_imt_name is not null, then it species the fallback imt for when
the input is not bound in the new imt. It must be an already existing imt
in the specified context. This is to prevent loops and other weird
behavior.
\param context The context to which the new imt will be attached.
\param imt_name The name for the new imt. Must be unique (case
insensitive).
\param chain_imt_name The name of the fallback imt if not null. Must
already exist on the specified context.
*/
[input] Make a start on the new binding system Input Mapping Tables are still at the core as they are a good concept, however they include both axis and button mappings, and the size is not hard-coded, but dependent on the known devices. Not much actually works yet (nq segfaults when a key is pressed).
2021-11-03 10:02:39 +00:00
int IMT_CreateIMT (int context, const char *imt_name,
const char *chain_imt_name);
[input] Create an automatic imt switcher An imt switcher automatically changes the context's active imt based on a user specified list of binary inputs. The inputs may be either buttons (indicated as +button) or cvars (bare name). For buttons, the pressed/not pressed state is used, and cvars are interpreted as ints being 0 or not 0. The order of the inputs determines the bit number of the input, with the first input being bit 0, second bit 1, third bit 2 etc. A default imt is given so large switchers do not need to be fully configured (the default imt is written to all states). A context can have any number of switchers attached. The switchers can wind up fighting over the active imt, but this seems to be something for the "user" (eg, configuration system) to sort out rather than the switcher code enforcing anything. As a result of the inputs being treated as bits, a switcher with N inputs will have 2**N states, thus there's a maximum of 16 inputs for now as 65536 states is a lot of configuration. Using a switcher, setting up a standard strafe/mouse look configuration is fairly easy. imt_create key_game imt_mod imt_create key_game imt_mod_strafe imt_mod imt_create key_game imt_mod_freelook imt_create key_game imt_mod_lookstrafe imt_mod_freelook imt_switcher_create mouse key_game imt_mod_strafe +strafe lookstrafe +mlook freelook imt_switcher 0 imt_mod 2 imt_mod 4 imt_mod_freelook 8 imt_mod_freelook 12 imt_mod_freelook imt_switcher 6 imt_mod_lookstrafe 10 imt_mod_lookstrafe 14 imt_mod_lookstrafe in_bind imt_mod mouse axis 0 move.yaw in_bind imt_mod mouse axis 1 move.forward in_bind imt_mod_strafe mouse axis 0 move.side in_bind imt_mod_lookstrafe mouse axis 0 move.side in_bind imt_mod_freelook mouse axis 1 move.pitch This takes advantage of imt chaining and the default imt for the switcher (there are 8 states that use imt_mod_strafe). The switcher name must be unique across all contexts, and every imt used in a switcher must be in the switcher's context.
2021-11-25 09:01:07 +00:00
int IMT_CreateSwitcher (const char *switcher_name,
int context, imt_t *default_imt,
int num_inputs, const char **input_names);
[input] Implement axis binding Each axis binding has its own recipe (meaning the same input axis can be interpreted differently for each binding) Recipes are specified with field=value pairs after the axis name. Valid fields are minzone, maxzone, deadzone, curve and scale, with deadzone doubling as a balanced/unbalanced flag. The default recipe has no zones, is balanced, and curve and scale are 1.
2021-11-11 06:51:47 +00:00
void IMT_BindAxis (imt_t *imt, int axis_num, in_axis_t *axis,
const in_recipe_t *recipe);
[input] Implement imt creation, binding, etc Much testing is needed, but the bulk of imt management is implemented. Axis bindings are not properly implemented yet, though.
2021-11-08 07:54:52 +00:00
void IMT_BindButton (imt_t *imt, int button, const char *binding);
[console] Hook up new input system This has smashed the keydest handling for many things, and bindings, but seems to be a good start with the new input system: the console in qw-client-x11 is usable (keyboard-only). The button and axis values have been removed from the knum_t enum as mouse events are separate from key events, and other button and axis inputs will be handled separately. keys.c has been disabled in the build as it is obsolute (thus much of the breakage).
2021-11-08 02:20:04 +00:00
qboolean IMT_ProcessAxis (int axis, int value);
qboolean IMT_ProcessButton (int button, int state);
[input] Implement imt creation, binding, etc Much testing is needed, but the bulk of imt management is implemented. Axis bindings are not properly implemented yet, though.
2021-11-08 07:54:52 +00:00
void IMT_Init (void);
[input] Plug a pile of memory leaks While most were "harmless" in that they were held pointers at shutdown, a few bugs were exposed in the imt code.
2022-05-12 10:01:45 +00:00
void IMT_Shutdown (void);
[input] Save/load config to/from plist configs While the console command line is quite good for setting everything up, the devices being bound do need to be present when the commands are executed (due to needing extra data provided by the devices). Thus property lists that store the extra data (button and axis counts, device names/ids, connection names, etc) seems to be the best solution.
2021-11-14 01:17:05 +00:00
struct plitem_s;
void IMT_SaveConfig (struct plitem_s *config);
void IMT_SaveAxisConfig (struct plitem_s *axes, int axis_ind, int dev_axis);
void IMT_SaveButtonConfig (struct plitem_s *buttons, int button_ind,
int dev_button);
void IMT_LoadConfig (struct plitem_s *config);
[input] Make a start on the new binding system Input Mapping Tables are still at the core as they are a good concept, however they include both axis and button mappings, and the size is not hard-coded, but dependent on the known devices. Not much actually works yet (nq segfaults when a key is pressed).
2021-11-03 10:02:39 +00:00
#endif
[dox] Fix up some doxygen issues I found a few doxygen related patches in my git stash and while testing them, found a few doc issues.
2022-04-12 12:01:41 +00:00
///@}
[input] Make a start on the new binding system Input Mapping Tables are still at the core as they are a good concept, however they include both axis and button mappings, and the size is not hard-coded, but dependent on the known devices. Not much actually works yet (nq segfaults when a key is pressed).
2021-11-03 10:02:39 +00:00
#endif//__QF_input_imt_h
Reference in a new issue Copy permalink