Since building the treadmill project late last year, I did actually manage to complete a full run through of the original Sonic the Hedgehog.
Along the way I found a few snags and issues with the treadmill:
Direction switch/lever
I soon found that the reed switch control from the cross trainer levers was problematic because there was a lack of tactile feedback to know when the lever was in the correct position for changing direction.
Therefore, I replaced it with a regular switch where normally open connected the ‘right’ key and the normally closed connected to the left key. Using a metal angle bracket I was able to mount it to the frame so that the switch is closed when the lever is fully forward, and open in any other position.
This means that when moving right I just need to keep the lever fully forward, and to change direction I just have to move it from that position.
Although I kept them in place for the duration of the Sonic play-through, I’ve since removed the cross trainer levers, as they do not provide any real benefit over a regular button.
Jump button
The large plastic button that I was using as a jump key broke (it was from a cheap “noise-maker” type toy, and the PCB literally snapped), so that was also replaced with a basic switch. I plan to change this up for something better in the future, but at the time I just wanted to go for a run.
Quick save and quick load
I found, particularly on the more platform/puzzle sections of the game, it became necessary to make use of the quick save and quick load features of the emulator, so I added an external quick load button to the treadmills handlebar.
A better button system
All of the above can be distilled to a single point - that the button inputs were not good enough.
Although I started the project with the intention of minimising the number of regular button presses, it seems inevitable that there will always be some required.
Configuring the controls
In order to play other games I would need to make some additional adjustments for different control schemes. This would mean altering the firmware and re-uploading every single time I changed the game, which seemed needlessly convoluted.
There were two main reasons for using the Makey Makey. The first was to take advantage of its noise filtering features, and the second was its ability to act as a keyboard.
The noise filtering is the real selling point of using it, but there are other ways to obtain its input and then turn into keyboard input. So I adapted the firmware so that instead of sending keyboard input it would appear to the connected computer as a serial port. On each cycle it would send one byte, with each bit representing the button state (i.e. pressed or released) of each of the buttons.
This would allow a data transfer rate fast enough to handle pretty much any input I can throw at it.
The source code for this can be found at Github.
The software
The software will be an ongoing development project so I’m not going to be sharing it at the moment.
On the computer side, an application will continuously read the serial import, and then translate it into appropriate keyboard events via udev, thereby sending whatever that keyboard input is to ever application is active and in focus on the computer – in the case of this project that will be a game.
For this iteration of the treadmill I’m going to be using the acclaimed indie game Super Meat Boy – as it has a small range of inputs (left, right, sprint and jump) but adds a couple of extra bits of complexity for me to expand on with the treadmill.
Once the serial connection is established, a thread runs constantly, reading the latest byte from the Makey Makey.
It compares the byte to the previously read byte. If a bit that wasn’t previously set is now set, then a corresponding function is called in a secondary thread, which is the input thread.
The input thread maintains a count of “presses” from the treadmill rotations, which increases with each press as well as decreasing with the passing of the specified time interval (the “decay”).
If the count is positive then the first key (the direction) is pressed.
If the count is positive and greater than the defined sprint threshold then the sprint (shift) key is also pressed.
For the jump key, the serial thread will always report the state of the relevant bit to the input thread.
This compares a pair of booleans (jumping and lastJump) – which determines whether the jump (space) key should be pressed or released. It is done this way because Super Meat Boy differentiates between small and large jumps based upon the duration of the key press.
