It would be nice to have a built-in way to support combos.

For example press A then B to trigger an action. Perhaps with a timeout option before it's too late to press B.

Ideally, the combo would happen behind the scene and the API could look like this:

var A = new KeyboardCondition(Keys.A);
var B = new KeyboardCondition(Keys.B);

var combo = new ComboCondition(A, B);
combo.Timeout(100);

if (combo.Triggered()) {
   // Do action.
}

Some work has been started with the static scroll and pointer API:

if (MouseCondition.Scrolled()) {
    someValue += MouseCondition.ScrollDelta;
}

if (MouseCondition.PointerMoved()) {
    someValue += MouseCondition.PointerDelta;
}

Perhaps it could be worth it to abstract this into a condition with an out parameter so that it can be used in a non static manner:

if (condition(out int delta)) {
    someValue += delta;
}

if (condition(out Vector2 delta)) {
    someValue += delta;
}

Or something similar.

Eventually, this could be used to map analog joystick values, triggers, etc.

Sometimes it's nice to be able to press a key, have a Pressed() event happen, wait X milliseconds, then have Held() trigger every Y milliseconds.

In some cases, some keys shouldn't trigger Pressed or Released. For example: CTRL + A.

If we're currently holding A, then pressing CTRL shouldn't trigger a CTRL + A press.

ICondition SelectAll =
    new AllCondition(
        new KeyboardCondition(Keys.LeftControl),
        new KeyboardCondition(Keys.A)
    );

In a select all CTRL is a modifier. A new class could be created handle that case:

ICondition SelectAll =
    new AllCondition(
        new Modifier(
            new KeyboardCondition(Keys.LeftControl)
        ),
        new KeyboardCondition(Keys.A)
    );

Modifier would always return false for Pressed and Released.

Note: There might be an edge case to think about. What happens if a user is currently pressing A then presses CTRL, Should that trigger Held and HeldOnly for CTRL + A? It might make some code harder to write on the user side.

Hey,
nice project!
I would to ask If you support key presses there are pressed at the same time, not only with modifiers, with all keys and if possible with mouse and keyboard combos.
This would be very great.

All the best,

Keybind on Alt + Enter to toggle fullscreen.
In a menu, keybind on Enter to select an option.

If a player is currently in a menu, and wants to toggle fullscreen, we need to make sure that the menu option is not accidentally selected.

Put a keybind on Control + A and another keybind on Control + Shift + A. Only one should trigger at a time.

The current way to handle this is to use AddNot with a value of Shift on the first so that it doesn't trigger. This works when keybinds are hardcoded, but makes it much harder to allow players to choose their own keybinds.

In some cases though, it's fine for a single key to trigger more than one keybind. For example, Shift + A and Shift + B. Both use Shift but both can trigger at the same time on the same frame.

When calling InputHelper.UpdateSetup() in the Update loop the following error occurs:

System.TypeLoadException: 'Could not resolve type with token 0100002f from typeref (expected class
'Microsoft.Xna.Framework.TextInputEventArgs' in assembly 'MonoGame.Framework,
Version=3.6.0.1625, Culture=neutral, PublicKeyToken=null')'

This may be something to do with me using the dev build of Monogame?

Source: "Apos.Input"
Stack trace:

at Apos.Input.InputHelper.UpdateSetup () [0x00007] in <629851f313ea4d45b2c99b7328c4a965>:0
at SubterfugeFrontend.Shared.SubterfugeApp.Update (Microsoft.Xna.Framework.GameTime gameTime) [0x00039] in C:\\Users\\Quinn\\source\\repos\\SubterfugeRemake.Shared\\SubterfugeRemake.Shared\\SubterfugeCore.cs:148 
at Microsoft.Xna.Framework.Game.DoUpdate (Microsoft.Xna.Framework.GameTime gameTime) [0x00019] in <f7e5a330f53241e8971ee913edeccb27>:0
at Microsoft.Xna.Framework.Game.Tick () [0x00103] in <f7e5a330f53241e8971ee913edeccb27>:0 
at Microsoft.Xna.Framework.AndroidGameWindow.OnUpdateFrame (System.Object sender, Microsoft.Xna.Framework.MonoGameAndroidGameView+FrameEventArgs frameEventArgs) [0x00041] in <f7e5a330f53241e8971ee913edeccb27>:0 
at Microsoft.Xna.Framework.MonoGameAndroidGameView.UpdateFrameInternal (Microsoft.Xna.Framework.MonoGameAndroidGameView+FrameEventArgs e) [0x0000f] in <f7e5a330f53241e8971ee913edeccb27>:0 
at Microsoft.Xna.Framework.MonoGameAndroidGameView.UpdateAndRenderFrame () [0x00058] in <f7e5a330f53241e8971ee913edeccb27>:0 
at Microsoft.Xna.Framework.MonoGameAndroidGameView.processStateRunning (System.Threading.CancellationToken token) [0x0005b] in <f7e5a330f53241e8971ee913edeccb27>:0 
at Microsoft.Xna.Framework.MonoGameAndroidGameView.RunIteration (System.Threading.CancellationToken token) [0x000e0] in <f7e5a330f53241e8971ee913edeccb27>:0 
at Microsoft.Xna.Framework.MonoGameAndroidGameView+<>c__DisplayClasse.<WorkerThreadFrameDispatcher>b__c (System.Object s) [0x00017] in <f7e5a330f53241e8971ee913edeccb27>:0 
at Android.App.SyncContext+<>c__DisplayClass3_0.<Send>b__0 () [0x00000] in <b62c3fba3fe848f3bb323dbe33464223>:0 
at Java.Lang.Thread+RunnableImplementor.Run () [0x00008] in <b62c3fba3fe848f3bb323dbe33464223>:0 
at Java.Lang.IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this) [0x00009] in <b62c3fba3fe848f3bb323dbe33464223>:0 
at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.18(intptr,intptr)

It could be done through the InputHelper.Setup and InputHelper.UpdateSetup by passing a config for gamepads?

Would be nice to be able to have separate settings for each gamepad.

Perhaps an InputHelper.ThumbStickDeadzone array the same size as the amount of gamepads. And each deadzone can be set separately.

The current way to use the scroll wheel looks like this:

int scrollDelta = InputHelper.NewMouse.ScrollWheelValue - InputHelper.OldMouse.ScrollWheelValue;
if (scrollDelta != 0) {
    // Do something with the delta.
}

It would be nice to provide an abstraction over this pattern. It would also be nice to be able to use this in the context of the tracking system.

Possible API:

if (MouseCondition.Scrolled()) {
    // MouseCondition.ScrollDelta
}

Right now, the library uses words like composite and set. In reality, a composite is equivalent to the logical operator or and the set is equivalent to the logical operator and.

ConditionComposite and ConditionSet could be rename to ConditionOr and ConditionAnd.

Also, there are two ways to create a condition:

var toggleFullScreen = new ConditionComposite();
toggleFullscreen.AddSet(Keys.Enter).AddNeed(Keys.LeftAlt);
toggleFullscreen.AddSet(Keys.Enter).AddNeed(Keys.RightAlt);

and

var toggleFullScreen  =
    new ConditionComposite(
        new ConditionSet(
            new ConditionKeyboard(Keys.Enter),
            new ConditionKeyboard(Keys.LeftAlt)),
        new ConditionSet(
            new ConditionKeyboard(Keys.Enter),
            new ConditionKeyboard(Keys.RightAlt))
    );

I think it would be better to remove the first one. That would let me store conditions in an array instead of a list internally. The second syntax also scales better to create complex trees like:

var toggleFullScreen  =
    new ConditionSet(
        new ConditionKeyboard(Keys.Enter),
        new ConditionComposite(
            new ConditionKeyboard(Keys.LeftAlt),
            new ConditionKeyboard(Keys.RightAlt)
        ),
    );

No need to force always starting from ConditionComposite.

Right now, non static MouseCondition checks only happen when the game is active (using IsActive).

It appears that the first click on a window happens when the game is still inactive. This means that a Pressed check might not trigger while the HeldOnly can trigger. That can mess up HeldOnly conditions that rely on Pressed having fired first.

When a key is held and the game loses focus (IsActive becomes false), it's possible for the player to let go of that key. When that happens the Released() condition doesn't fire. It might be useful to consider the focus loss to be the same as letting go of the key.