I built the first pass of the KeypressInfo struct. It is a bitfield which counts up to three up presses and three down presses, as well as whether or not the key is held. Because it’s greater than 5 bits, I can’t store two of these in a single variable - this seemed pretty inconvenient to me, but this was a good starting point for testing out the details of how my most important structure would work.

I then tested out a hashset for subscribed keycodes, as a modification for my original keypress test. Because my plan is to give users of the interface the ability to subscribe only to the keys they want info for, helping to reduce processing and memory overheads. My last addition in this phase was ignoring the WM_KeyDown messages that occur as a result of keys being held down. Because I already store the held-down state, I’ve decided that I don’t want to process this message. 

The three wasted bits annoyed me enough that I changed the structure to store two KeypressData bitfields. My system will always enforce an even number of Frames stored in its history.

In order to maintain the information I wanted to store, I made a new structure for it. Instead of a per-frame storage, this stores whether or not the key is currently held down, and how many frames the key has been held down for. That variable will preserve the last hold duration - this allows me to replicate the common behavior of Charge moves in Fighting Games.

I made this 15 bits so that there should be more than enough frames of button-holding recorded for almost all use cases. 

The final chess piece, so to speak.

This class represents the primary object that the user will interface with. It allocates enough memory for the Key History buffer according to the User’s request, and allows an easy way to access the pertinent stored data.