Devyn Lehrman's Input System: RELEASE (Windows)

Download the Input System by clicking here

Notes:

100% Modular
- This package does not rely on any namespaces, code, or #includes from our class.
Windows-only
- This package works on x86 AND x64 configurations.
- This can VERY EASILY be extended to other systems by writing a HandleEvent function for other configurations (e.g. Mac, Linux).
Keyboard-specific
- While Mouse1, Mouse2, and Mouse3 are accessible by VK, Mouse movement is not currently supported.
Can be extended for Multiple Keyboards
- If you are able to discern which Keyboard a Windows Event originates from, you can use multiple c_KeyboardData objects to store separate histories, enabling support of local co-op on separate keyboards.

input demo.mp4

Video Project 3.mp4

What it Does

Tells you what Keys the user has pressed/released.
Stores a history of Keyup/Keydown information
- The number of frames stored is defined by the user
Processes Keypresses as Windows Events, so you never lose or miss them
- The application will not received Keyup/Keydown information when the application is not focused.
Stores if a Key is currently held, and how many frames it is/was held for.
Records if a single key's Keypress Event has occurred more than three times per frame as a "suspicious keypress rate"
- This would flag some very basic macros.
Allows the user to very easily build and check for a "Keypress Sequence"
- This uses the Key History to see if keys were pressed in-order.
- Consider Sequences like the Konami Code, fighting game inputs, or ordered key combinations.
- Sequence control - very easily Allow or Disallow overlapping sequences, give certain sequences higher priority, and adjust the difficulty of certain Input sequences.
- Naturally supports "Charge Inputs" and "Negative Edge" inputs.

How to Install the Input System

Include this

Make sure your Project references it

Type this in your Windows Event Callback

Supply your own KeyboardData object for "m_keyboardData" (of Type c_KeyboardData).

"i_winEventMessage" is my name for the UINT that my Windows Event Callback takes as a parameter.

More info on Windows Event Callback loop (and the related parameters) here: https://learn.microsoft.com/en-us/windows/win32/winmsg/using-messages-and-message-queues

===================================================================================================

Note: If you are using the EAE6320 Engine, this is the Callback that your Application probably uses (iApplication.win.cpp)

Done!

(type "using namespace BISin" in your file for even easier use)

To Subscribe to Keys (listen for their changes) or add them to Sequences, use their VK codes.

https://learn.microsoft.com/en-us/windows/win32/inputdev/virtual-key-codes

Code Sample: Quick-start

Initializing KeyboardData and Listening to Keys

Make a Set, so UpdateKeyboardData can tell you which keys have changed.

In your main Game Loop / Update Loop, call UpdateKeyboardData

Two easy ways to check for Input Data

How to process this data, and what it means:

Using Key Sequences

Initializing a Sequence, adding Keys to a Sequence, and setting "leeway frames."

Checking if a Sequence has been Input:

Simple!

Making your Sequences more lenient (don't enforce that prior keys need to be released)

Scan this QR Code to Visit this Site

How I used what I learned from this course

This course helped me substantially in understanding how to plan a system, how to separate concerns, how to keep code clean, and how to create a user-friendly interface. It was also great C++ practice.

As a result, I am very proud of how this project turned out. I feel that my interface is very easy to use, I believe that my system is quite powerful (albeit restricted to keyboard), and I am confident that it is very easy to add features or extend to other platforms.

What I learned from this Project

Through research, I learned a lot about the different ways inputs have been processed on Windows machines - both currently, as well as methods and libraries which were used in the past. Much of this is described in my previous write-ups for this project.

I also learned about how Windows fires Keyboard events - via signal interrupts. I learned about the process chain for processing Windows Events, and I understand much better now how certain Keyboard features, like half-keypresses, require drivers and potentially other provided software in order to successfully transmit such information to the computer.

I'm proud of how this turned out. Although I'm already a "lab monster" in Fighting Games and have prior experience modding them, I learned even more about how certain games process inputs.
For example, I used Tekken 8's Input Display as a way of seeing how many frames I was holding a key down (it turns out, pressing a key and releasing it exactly one-frame-after-another is quite hard).
As another example, I used Guilty Gear: Strive as a reference for whether or not I should drop repeated inputs in the middle of a sequence (e.g.: If, during a half-circle-back input, the user presses Down twice, does the input still work? The answer was yes! So my system does too.
Finally, I referenced Street Fighter for how input sequences layer with each other. Ryu's Dragon Punch (Shoryuken) is a Forward-Down-Forward input, but his Super is a Down-Forward-Down-Forward. A commonly-taught input trick is to do Forward-Down-Forward-Down-Forward to do Shoryuken and then cancel it into Super, as opposed to doing Forward-Down-Forward AND THEN Down-Forward-Down-Forward.

I also got some validation in that most Fighting Games don't have great support for keyboard inputs. Hey, maybe I'll get to fix that one day.

Page updated

Google Sites

Report abuse