Hacking a Body Worn Camera To Run Doom! 

There are certain absolutes in life. We need to eat. We need to sleep. We need to get the game DOOM¹ running on every device with a display. Many people have succeeded with the first two steps, but the third step can be a little tricky. AXIS W120 Body Worn Camera features a display, buttons and motion sensors, everything you need to take your handheld gaming to the next level! 

What is DOOM, anyway? 

DOOM is a game about shooting hordes of demons in a 3D world to save the Earth, or something. It was released in 1993 and nowadays, it’s used as a challenge to make it run on all kinds of odd hardware. Time and time again, it’s been proven that the answer to the question “will it run DOOM?” is always “yes”. 

It’s important to know that engineers are often a lazy bunch. If we can take a shortcut, we take it. If we can automate something to save 5 seconds, we automate it. If we can avoid modifying 30+ year old C code, we avoid it. Here at Axis we’re also huge fans of open source. Combine all of this, and it’s only reasonable to find someone else who has already done most of the work and published it openly. This brings us to “doomgeneric“, a fork of a fork of a fork of the original DOOM! 

Doomgeneric does a lot of the heavy lifting for us, it runs the full game but it has no clue what hardware it runs on. To solve that, it exposes a couple of functions where we can write the “glue code” to interact with whatever hardware we have, in whatever way we please. It makes a lot of sense to start with getting something on the display first, so let’s see what we have to work with. 

Making the pixels shine 

AXIS W120 Body Worn Camera features a small display on the top, with the breathtaking resolution of 160×80. That might sound low, but it is surprisingly crisp with remarkably great colors. By default, it shows useful information to the wearer, such as recording status, remaining battery, wireless connection etc. This is all well and good if you intend to use the camera for its designated purpose, but we certainly don’t need any of that. Luckily, it exposes a framebuffer device that can be used to show anything we want on the display. 

Doomgeneric gives us a function that is called when a new frame is available in a buffer and is ready to be displayed. So, just copy that buffer to the framebuffer device and call it a day? Not quite. As you can see in the image below, it doesn’t really look great. The reason for this is that the DOOM buffer is in RGB888 format, meaning that it has 8 bits representing each primary color (red, green and blue). Our display, however, is in RGB565 format, meaning that it has 5 bits for red, 6 bits for green and 5 bits for blue. By cutting off the last bits of each channel and shifting them into place, we get accurate colors for our display. 

Making the pixels move 

Now we can see the DOOM menu in all its glory, but how do we interact with it? AXIS W120 Body Worn Camera features four buttons: the top button, the side button, the power button and the recording button. Unfortunately, they’re not aligned as a d-pad, clearly a miss by the mechanics department. But with some imagination we can make this work! The biggest button is the recording button on the front, so it’s only natural that it controls the most important action in the game: shooting bad guys. Moving forward seems natural to have on the top button. The side button and the power button are positioned on either side of the camera, so having them as left and right turn is intuitive. Just don’t turn to the right for too long, or the camera powers off… This is good enough to get something playable! 

Doomgeneric gives us yet another function, this one for handling input events. All keys on AXIS W120 Body Worn Camera expose themselves as standard Linux event keys, so it’s fairly trivial to hook up a key press on the camera to a corresponding key press in the game. Only problem is, unless you’ve done some serious finger skateboarding, it doesn’t take long for your fingers to get fatigued pressing the buttons on AXIS W120 Body Worn Camera. These buttons are not really meant to be pressed often, and they’re quite stiff in order to avoid accidental presses. That means you need quite some force to push them down, this is not good for extended play sessions while the boss is away, so how can we solve it? 

AXIS W120 Body Worn Camera features a bunch of sensors, most notably an IMU (a combination of an accelerometer and gyrometer) and a magnetometer, commonly known as a compass. These are used for detecting when the wearer falls or gets subjected to a major force, and to check which direction the wearer is facing, which can be useful for displaying on a map together with the GPS position. 

Now, the solution to our finger fatigue seems obvious. If the camera knows when we’re turning in real life, why should we push a bunch of stiff buttons to turn in the game? A bit of exercise never hurt anyone! A few lines of code later, and everything is working… well, poorly. It turns out it’s a bit tricky to translate a turn, measured in degrees, to a key press, which is measured in number of frames that the key is pressed. A bit of tweaking and we came up with this solution: whenever the user turns 3 degrees in real life, the game pushes down the corresponding direction button for 5 frames, then releases it. This makes movement a little sluggish, since a fast turn in real life still only translates to 5 frames of turning in the game. Ideally, one would find where the player rotation is set in the game, and set this to the camera rotation in real life to get a perfect mapping. But as mentioned earlier, if we can avoid modifying 30-year-old C code, we avoid it. My boss also thinks there are more important issues to focus on… 

Final words 

I normally work with firmware development for our cameras, with a focus on the Linux kernel and ensuring the hardware works as it should. It’s a mix of software and electronics, with a bit of higher-level software from time to time. This DOOM project is very similar to how we work on a daily basis: we know what the goal is and we have to figure out how to reach that goal given the limitations in our hardware, while always keeping ease of use in mind.

---

If you want to join us on projects like these and many other fun things we do, keep your eyes peeled for new job openings in our different firmware departments. It’s a lot of fun going from a spreadsheet of ideas to a fully fledged product in customers’ hands!