Treadmill Videogame Controller part 2

View this post on Instagram

A post shared by Anthony (@darkmidnight_diy)

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.

Treadmill Videogame Controller

Like a lot of people, I spend a lot of time trying to balance the need for exercise and fitness with the desire to sit on the couch and play video games.

So I figured why not combine the two.

To start with I picked up a treadmill – this one is a manual treadmill as I want its movement to be dictated by my running, not by some electric motor.

There is a small control panel on the treadmill which provides some statistics. It is completely optional and not required to use the treadmill. It gets it’s power from a separate battery supply.

Although this is not particularly useful to me, it does indicate there is some type of encoder in the treadmill assembly to measure these values. Before even taking the treadmill part I can surmise that this is most likely either a magnet and reed switch assembly, a hall effect sensor, or a rotary encoder.

Once I got the treadmill, I could see a simple 2-wire lead from the base of the unit through to the control panel, connected with a 3.5mm jack.

I breadboarded a small breakout so that I could connect the oscilloscope and see what kind of signal was being passed.

This revealed that there’s 2.5v being sent down the line (tip of jack is positive), and that the signal would transition between high and low as the treadmill was used, and the frequency would increase as the speed increases.

In it’s most basic form, if we can translate those state transitions to key presses, that should work.

There was however a whole lot of noise in the signal which seemed to be caused by resonance in the treadmill frame, as there would be severe jumps simply by my touching it.

Initial Implementation

An initial attempt to use an Arduino and have the signal trigger interrupts wasn’t successful due to the noise, and filtering attempts became quickly time consuming.

The requirement for the filtering and the requirement for it to be an input device led me to a MakeyMakey development board.

This board is advertised as an educational toy, that allows users to turn anything into a key. In order to do this it provides a significant amount of signal processing and filtering. So in other words, exactly what I’m looking for.

This means that very little is required on the software side, as the Makey Makey presents inputs to the computer the same as a keyboard would, and applications generally will not notice any difference.

By simply connecting a crocodile clip from the tip of the 3.5mm jack to an ‘key’ on the Makey Makey, and connecting the body of the jack to the ground of it, that is already enough to get some response. Every pulse sent by the treadmill gets interpreted as a key press and release by the Makey Makey.

Problems

The only problem with that is with the treadmill in normal operation, the pulses (and therefore keypresses) are so quick that they do not translate real world movement into equivalent in-game movement.

With the treadmill running, the red marks show the time that the key is pressed. The two ‘bursts’ of movement on the treadmill appear as a total of 14 short keypresses.

 

Instead, either the rapid tap causes the character to barely move, or if the treadmill stops when the signal is high, the character runs at full speed without needing any further movement on the treadmill.

 

The treadmill stopped when the signal is high – making it look like the key is held down indefinitely, even though the user is not running

 

What I want to do is to bring the game input more “in step” (ha) with the movement of the treadmill, so that the same two bursts of treadmill movement would look more like the following:

 

The two bursts of activity are represented as two longer keypresses, as if the key were held down for the time the treadmill is moving

To do this, I forked the source repository of the Makey Makey project, and made some edits.

The changes are mostly in the updateInputStates function, and focus on the ‘right’ key on the Makey Makey, as I will be using a side-scroller game to test.

Demo

To demonstrate what this change does, below are two screenshots which represent a few seconds of continuous running on the treadmill.
The first is with the treadmill connected to the “Up” key, which is unaffected by the code changes. The input is shown as repeated press and release events.
The second is with the treadmill connected to the “Right” key, which is the one that I have changed.
The impact is shown any as press events, up until the point that the treadmill stops. This is the same as if the key were held down.

The test code is based on KeyEventDemo – the only change is that I removed the KeyTyped event as it is not relevant to this exercise.

Implementation 

Unfortunately there is no way of determining the treadmills direction of travel as it was obviously not designed for that, but in a game I may want to change direction.

What I have done is a workaround for now is I have made the same change for the left key as I did for the right and have wired the treadmill to the Makey Makey like so:

This means by simply flicking the switch I can change direction. In a subsequent moment of inspiration I swapped the switch for a pair of reed switches and a magnet attached to one of the cross-fit handlebars that are on the treadmill - allowing for the direction to be controlled with the left lever.

I have also wired a simple momentary switch to the space key to allow my character to jump.

For now this whole contraption is held together by screw terminals and crocodile clips as it is only a prototype and is a platform I want to expand on in future.

The Game

For this initial experiment I wanted to use a game where input is limited, as a proof of concept.

To keep with the theme of running and speed Sonic the Hedgehog seemed like a suitable choice.

I will be running this on a PC with a Sega Genesis/Mega Drive emulator.

Please note the various copyright and legal complexities around the use of emulators and ROMs - the short version is that you should not use ROMs of games you don't own.

I actually own two copies of the game - an original Mega Drive cartridge, and a PC version as part of the "Sega Mega Collection Plus". It's just that the Mega Drive emulated ROM is easier to interface with.

The end result:

 

Fast forwarding boring parts of games

It's becoming more common in gaming, particularly with mobile and free-to-play games, for an action or activity to be limited by real-world time, usually in order to provide a 'nudge' to players to nag them into purchasing loot-boxes or other pay-to-win premium extras.

Moral arguments about the ethics of pay-to-win and loot boxes aside, I find this really annoying. These days, the amount of time that I have available for gaming is ever lower, and arguably, time is the most valuable and scarce resource for everyone - after all, we only have get a certain amount, and can't buy more.

So while I was waiting for some in-game nonsense to finish, I started thinking about how feasible it would be to create a fast-forward for these types of activities in-game.

Yeah, I know, there's a certain irony in getting annoyed at having my time wasted and then spending a good deal of time trying to work around it - but sometimes once I get an idea in my head, I have to see it through.

The game I'm using for this demo is Fallout Shelter. I'm well aware that there are already plenty of documented save file hacks for this game, similar to the Saints Row 3 one that I did a while ago.

However, that's not the approach that I want to take here. I still want to play the game, more-or-less as intended. I just don't want to be kept waiting.

A quick experiment by changing the time on the system the game is running on, shows it to be quite tolerant of the time changes, the screen briefly blacking out while the game mechanics catch up.

The first thing to do is to disable NTP (automatic system time synchronization).

In Windows, this can be done by right-clicking on the time in the task bar, selecting "Adjust date/time", and then setting "Set time automatically" to Off. This will stop the system resetting the clock back to the correct time. Just remember to turn it back on when you're done playing.

To do the time adjustment, I'm using AutoHotKey. AutoHotKey (AHK) is an incredibly versatile scripting language for Windows systems, allowing commands and key macros to be bound, system-wide, to keyboard shortcuts.

The idea is to create a global hot key on the system that I can trigger without leaving the game, whenever I want to speed things up by a certain amount.

As the game is mostly touch/mouse controlled, I've bound the macro to the modifier and arrow keys.

* Ctrl-Shift-Right advances time by 1 minute
* Ctrl-Shift-Left advances time by 15 minutes
* Ctrl-Shift-Down advances time by 30 minutes
* Ctrl-Shift-Up advances time by 1 hour

The script is available on GitHub.

Limitations

The script needs to be run as administrator, as elevated privileges are needed to change the system time. There are ways that this can be avoided, but they require more system changes, so for the purposes of this, it's easier to just right-click and select "Run as Administrator".

The script is pretty basic, and operates simply by adding the numbers - so it's not smart enough to cross hour-thresholds - ie. if you advance by a minute at 11.59, it will attempt (and fail) to set the time to 11.60 - but this is simply overcome by, well, waiting a minute.

Editing game saves with a Hex Editor

If it wasn't for videogames, I'd probably never have got into the career path I have, and a lot of that also comes from my other habit of taking stuff apart to see how it works.

Back in the days of the original Playstation, I had one of these Xplorer cheat cartridges.

This allowed the use of game cheats that weren't necessarily part of the actual game code.

In addition, the cartridge allowed the user to create new codes, by essentially searching for values in an existing game.

My understanding of it is that it effectively was a memory scanner, that would find values in the systems RAM, and allowed values to be rewritten (constantly rewriting the memory location of the health variable to read 100% would effectively be an infinite health cheat, for example).

Similar application shave been released for PC games, but to be honest, they went to involve running unchecked code and tend to have an air of shadiness about them.

Plus they tend to just be a very directed tool for a specific game title, so blinding running one might help you out with a game, but you're not getting anything useful from it.

This project is to demonstrate that similar results can be produced using standard tools, which have uses beyond games, so while cheating at the game won't make you any good at the game, you might instead learn something that is useful in the real world.

Tools
The tool being used is a Hex Editor (wikipedia). I'm using GHex, but the most commonly known editor is WinHex for windows.

Process

There are several approaches that can be taken, there are some who will painstakingly sit and work out the whole format of the file.

While this is probably the most technically sound approach, it's incredibly time consuming and laborious, particularly if you're only looking to change one or two values.

Another approach is to load a game, make a note of some key values in the game you'd like to amend - ammo, health, cash, etc. The more unique the value, then in theory the easier it will be to find in the file.

For this example we're using Saints Row 3, and in particular we're looking at ammo.

Note that there the process does involve a certain amount of trial and error, so for conciseness I'm not going to cover all of the missteps along the way, just what I did right. Of course it goes without saying making backups of the save before editing is worth doing just in case.

These are the ammo balances of the save I'm using:

The first thing to do is to convert some of these values to hexadecimal so that we know what to look for in the hex editor.

So starting with 265 - this converts to 109 in hex, or in the notation used with most hex editors, this will appear as "01 09", so use the find function in the hex editor to look for all instances of that. There are two likely outcomes, either:

• You'll find multiple instances, so the next step becomes figuring out which one is the one you want to change.
  
• You'll find nothing. In which case the endian ordering of the file could be an issue - this refers to the order in which the bytes are used to create the actual number. In layman's terms, you can think of it as reading from left-to-right or right-to-left. Simply reverse the order of the bytes above - e.g. "01 09" becomes "09 01" and search for that. If you continue to find nothing, it could well be there's some additional encoding or perhaps simple encryption on the file. There's ways around that but it's a bit of of scope for this project - I might do a follow up post later dealing with those things.
  

As it happened, with the pistol ammo amount I lucked out, there was only the one instance.:

The bytes representing the pistol ammo highlighted in red (click to enlarge)

So, let's change these two bytes to FF (the largest 2-character hexadecimal value - like 99 is in decimal), reload the game, and see what happens.

The pistol ammo is now 65535
(which is the decimal equivalent of hex value FFFF)

So, where to go from here? We can repeat the above exercise with the other values to find them, but we can help to deduce the whereabouts by adding some logic to what we already know - in this instance, we're looking for ammo values, we've found one, and we can reason that it's quite likely that these values will be grouped together.

For example, the SMG ammo value (70 00) was found nearby

The 2 values (pistol value in blue, SMG value in red). Click to enlarge.

From there we can deduce further - The pistol value starts at byte 19104. The SMG value starts at 19132 - 28 bytes apart.

So what if we look forward another 28 bytes at 19160? We find "30 00" - decimal value 48, the value of shotgun ammo. And again, another 28 bytes later we get hex "77 00" - decimal 119, the rifle ammo.

The other ammo values. Click to enlarge

So lets test it and change all of those to "FF FF"
So did it work?

Yes.

SR3 save file 'cheat flag'
Although it's not really in the spirit of this post, if you're here to just cheat at this one particular game, there's a byte in the save file that identifies if cheats were used in the game. It's the byte at 0x000000C8. You can play with cheats, then just change this flag to zero and it'll be as if you hadn't.


A final note on using cheats in games
Using cheats in games is obviously a polarising subject. I am very much opposed to using cheats in multiplayer games where doing so will affect the experience of others.
I am also generally opposed to using them in single player games - whether they're keycodes put in deliberately by the games developers or third party tools that you've just downloaded and ran.
In my opinion you should at least do a playthrough 'as the developers intended', however, they can be a good way of extending the re-playability of the game and getting more life out of your purchase afterwards, and by instead using techniques that I've covered in this post, you can learn and practise techniques that can be useful in the real world, and in my opinion the benefits of that outweigh the drawbacks.

LAN-party in a box, part 3

Part 3: The software side

• Part 1
• Part 2

Finally got round to tidying up the code. There's the arduino sketch which powers the lights, and a java application that runs in the background on the server, reads the server logs and will produce the serial commands that are sent to the arduino.

It uses the RXTX serial library, and the code itself is available on GitHub at https://github.com/darkmidnight/UnrealLANBox

There's still room for plenty of improvement, like getting the lights to flash when a flag has been taken.

I also put together a video showing the build process and a demo of it in action, see below

LAN-party in a box part 2

Part 2 - A new case

• Part 1

When thinking of a new case for the LAN box, I wanted to ensure it was easy to setup, and as portable as possible. As portable typically means 'small', it was necessary to consider the heat that would be generated by the computer when it was in use.

I purchased this ammo box from the local army surplus years ago, and it's only been used for storage, but it fits the bill nicely, it's fairly small in relation to the flight case I'd used before, has a handle for portability, and being metal should help dissipate the servers heat during use.

On top of all that, being an ammo tin, it fits the military/industrial aesthetic of Unreal well, but I wanted to do something to set it apart.

While I was planning this project, we were joking during our weekly games that we needed some kind of trophy that each weeks winner could keep on their desk, so I was looking at options for that, and I was toying with the idea of creating the iconic Unreal logo in brass, to create a shield-type trophy.

Then I figured we could combine the two ideas.


To start with I printed the logo to fit the 20x20cm brass that I ordered, and stuck the logo to the sheet to use as a template.

My original intent was to cut the brass on the bandsaw, but after a bit of testing, it was incredibly slow, and I found it easier to start by drilling around the logo, and then use a Dremel to cut out the shape by joining the holes together. From there it was just a case of grinding and filing down the edges.

The same process was used to cut a hole in the side of the ammo box for the window to be mounted, though as the metal was quite a bit thicker, I used an angle grinder for grinding down the edges.

The brass was glued and sandwiched between two sheets of clear acrylic, and mounted into the hole.

A post shared by Anthony (@darkmidnight_diy) on Jun 27, 2017 at 5:39am PDT

The original netbook that I used was too wide to fit the box, but I found another that just about fit - although I had to remove the screen, the battery, and pretty much anything else I could get away with ditching.

The next step was to add a band of WS2812 LEDs on the inside of the case, around the window, so that the logo could be backlit. To control them I used an Arduino Pro Micro, which I can in turn from the netbooks serial port. All the code will be covered in part 3.

A post shared by Anthony (@darkmidnight_diy) on Jul 24, 2017 at 7:55am PDT

Update: Part 3 available here

Oak Desk with Embedded TV/Monitor

I've been after a new desk for a while, but never really been able to find one that fits the right combination of size, style and budget.

So I decided to build one myself, taking inspiration from a few videogames, where desks with built-in screens are commonplace:

In Splinter Cell: Blacklist (2013), the 'SMI' as it was known, was interactive and and provided a means of displaying menu systems to the player.

More recently, in Doom (2016), the desk is merely part of the scenery.

The plan
As much as I like the look of the tables in the games, I decided to go with a more traditional look.

The TV (red) will be sunk into the table, with the electronics hidden by the apron (grey) part.	When the glass (blue) is added, it will line up with the table surface, creating a flush finish.
The underside - I envisage a frame, possibly a re-purposed wall mount (yellow/gray), supporting the TV. The pink block indicates where I will mount the computer.

I started with a block of oak kitchen counter top. The aim was to put the TV into the desk, then protect it with a glass worktop sunk into the wood.

Step 1: Routing the ledge for the glass

A photo posted by Anthony (@darkmidnight_diy) on Aug 3, 2016 at 3:12pm PDT

The counter-top is 38mm thick, and has substantial weight to it. The plan was to route 10mm deep into it so that the glass would sit flush with the rest of the wood.

The glass was centered on the table and marked up. I'd only be routing the ledge, I'd be cutting the middle part out entirely, to make room for the screen, so it didn't make sense to rout all that.


I also left the corners - once the middle was removed I'd use a forstner drill to do those, to ensure a nice round corner.


Step 2: Cutting out the middle

A photo posted by Anthony (@darkmidnight_diy) on Aug 7, 2016 at 10:01am PDT

It would be a shame to waste the large chunk of wood from the middle, so I thought I'd use it to create the legs which meant I had to remove it intact.

I did this by using a circular saw to plunge-cut on each side, using the routed ledge as a guide, then using a jigsaw to finish the cuts on each side, allowing the middle to drop out (which of course had to be controlled, leaving it unsupported would likely have caused the wood to split when the majority of support was gone).


With the middle removed, I could finish the corners of the ledge using the forstner drill.

After a lot of planing and sanding, the glass finally fit. #woodworking #DIY A photo posted by Anthony (@darkmidnight_diy) on Aug 9, 2016 at 5:12am PDT

The next steps are to build the legs and mount the TV.

Analog pedal to USB keyboard

A lot of my electronics junk box consists of old videogame peripherals, which are often tricky to re-purpose because of proprietary connectors, peripherals, etc.

These pedals, for example, connect to a Playstation steering wheel by a fairly normal 9-pin serial connector, but the wiring isn't standard. Even if it were, most modern PCs no longer have serial ports, so a serial to USB adapter would be needed, and a software solution to make the input useful.

What I'm really after is a drop-in system, that can provide input as if it were a regular keyboard or mouse. The easy way out would be to use a microcontroller to emulate one of those devices, but I want to avoid throwing one at every problem, so I'm going to opt for only using discrete components and a scavenged keyboard PCB.

I'm going to re-purpose this keyboard PCB from the phone scanner project that I did a while ago.

The pedals themselves are essentially just a couple of potentiometers, so in it's simplest form, the contacts for a key could be wired to the pedal. This would mean that as the pedal is pressed, it will reach a point where the resistance is low enough for the signal to pass, however this is quite a simplistic option.


It also seems a shame not to make some use of the fine control of the analog input, so what I have in mind is a two-stage trigger type system - so that a light press of the pedal completes one key, and a complete press sends a second key. For example, a light press could be 'Ctrl', and the full press 'X', to create a pedal for the standard Cut shortcut.

So what's needed is to find a way to create a threshold for when to close the keyboard circuit and trigger the buttons. In order to so this, we can use a low battery circuit, such as the one shown here.

Rather than wait for the power to drop though, we will be using the pedals' potentiometer in place of R4 in the diagram. As the voltage will remain the same, using the pedal to change the low voltage level will change the sensitivity of the circuit, so that when pressed, the LED is triggered. We will also replace the LED in that circuit with an optocoupler, connected to the keyboard matrix for the key that we want.

To create the second stage of the trigger, another copy of the circuit is created, but using a higher value resistor in place of R3, and sharing the same R4 (the pedal). This one will trigger when the pedal is pressed further.

The circuit, with a test potentiometer in place (the upside-down PCB just contains some screw terminals for attaching the potentiometer - see right) Each pair of leads on the left go to the respective terminals on the keyboard PCB (below)

The screw terminal on the underside (on a separate PCB as I scavenged it from the junk box)

The keyboard PCB. The old IDE cable is there to make it easier to patch together the key matrices - In the picture above the leads from the pedal circuit board are connected.

Finally, power is added to the pedals from the keyboards USB connector - see left. This is sufficient to power both the keyboard and the pedal circuit


I have currently only done this for the right-hand pedal, but the same process could just as easily be done for the left (perhaps for other modifier keys - one shift, one ctrl etc).


A test of the pedal in various applications showed it to work, and has proved its usefulness for tedious key combinations in games (such as toggle run/slide etc)