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.

App Update: Bluetooth Macro and Voice Input v2.1

A new version of the Bluetooth Macro app is available on Google Play

As much as I like gaming, one thing that irritates me is "Quick Time Event" button mashing game mechanism which requires the player to repeatedly bash a button usually in response to a cinematic event, for example:

Interrogation Scene - Metal Gear Solid

As protagonist Snake is interrogated, the player is required to mash a button to resist the electrocution.

Pooping - South Park: The Stick of Truth


A more immature example is mashing a button to poop.. it is South Park, after all.


So I've updated the Bluetooth Macro app to include a 'button mash' function.


Usage
The new functionality can be found by swiping left past the voice recognition section screen.

Enter the keys to send in the text-to-send box, and use the slider to set the frequency (The minimum is 1/sec, max 100/sec).

Note that while the app strives to keep these times as accurate as possible, there will be some limitations based on the hardware that you use.

Click start to begin 'mashing' the button - it will continue until you click stop.

Randomising time
A lot of third party game controllers can include a rapid-fire button that the player can simply hold down. Some games (such as MGS) could detect these (presumably because such a solution would send button presses at a predictable set interval, whereas a human player would have marginal inconsistencies in the spacing of the button presses.)

The randomise checkbox aims to overcome this by introducing a small variation between the keypress delays.


Support/Feedback
Unfortunately I'm not in a position to offer any kind of official support for this, so use entirely at your own risk. If you have any trouble with it, then feel free to get in touch, and I'll try to help as and when I can, but I make no guarantees!

Dual booting Fedora 27 and Windows 10

I recently built a new desktop PC.
My previous machine has been in use for nearly a decade, so it seemed like time, and I've been wanting to experiment with watercooled systems.
I wasn't planning on making a post of it, but there were a couple of unexpected issues I ran into that I felt were worth documenting for future reference.

Dual Booting

I usually dual-boot Fedora Linux and Windows.

Unfortunately this time round, that was not as straightforward as usual.
After quite some time of searching, I found the answers, but it was a lot more hassle than it should've been, so I'm writing up my experience here in the hope that it may help others who are trying to achieve a similar setup.
The TL;DR of the problem is that it only ever seemed to be able to find the Windows boot loader, or the Fedora one (When I've done this in the past, it would find the GRUB loader, which would detect the windows one and add it as an option in the boot list, but this time it was not detecting the windows loader.)

There were quite a few failed attempts, so I'm not including an entire history, but this is the setup that worked.

Firstly, I used parted from a Fedora live disk to format the SSD into 2 partitions (a 50-50 split), one ntfs partition, one ext4.
Then I rebooted and installed Windows 10 to the ntfs partition. The installer actually complained about a lack of space, so to fix that I ended up removing the ntfs partion and letting Windows create it's own in the free space (it ended up using it's 50% of the drive to create multiple partitions.).
Another reboot to Fedora 27 live, and worked through the anaconda installer, specifying that it use it's ext4 half of the drive. Again, it wanted to use that space to repartition in it's own way, which is fine.
The bit that appears to really matter is to ensure that Fedora creates a /boot/efi partition in the same place that Windows creates it's /boot/efi partition (see screenshot)

The "Unknown" partitions at the bottom are the ones created by the Windows installation.
The /boot/efi partition is sdb4, as is the Fedora-created one (highlighted).

I was concerned about them being the same partition and whether or not Fedora would overwrite what was already there, so I created a backup image of that partition onto the other storage disk in that machine before proceeding with the installation.
Then began the install.

Once complete, I rebooted, and the GRUB menu appeared, with the Windows option available.

Networking Issues

The motherboard that I have chosen is the ASUS Strix Z270F.
It has onboard ethernet, which worked absolutely fine out of the box on Fedora, but on the clean Windows 10 install, the LAN controller was not detected.
Again, there's lots of forum posts with people suggesting various solutions, none of which seemed to work for me.

For some reason, installing the LAN driver direct from the ASUS-supplied driver disc didn't work - it failed because it couldn't detect the hardware.
Even opening up the disk, navigating to the LAN folder and running the Intel setup application from there didn't work.

The only way I found it would work is opening up "This PC", going to properties, then Device Manager, and finding the hardware there (it will be under "Other devices" and have a yellow "!" marker to show it's not working)
Right-click on it and select Update Driver Software.
Then "Browse my computer for driver software", and navigate to the driver disk's LAN folder.
Windows then detects and installs it and it works fine.

I can't begin to guess why installing it that way works and the other ways don't, especially as it's the same driver, but whatever. It's fixed.


Spec

Motherboard	ASUS Strix Z270F
Processor	Intel i7 Kaby Lake 4.2Ghz
RAM	32GB DDR4 3200MHz Corsair Vengence LPX
Disks	500GB SSD, 4TB HDD
GPU	Gigabyte GTX 1050 Ti 4GB
Cooling	Corsair H55
OS	Fedora 27 & Windows 10 Dual Boot

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

LAN-party in a box, part 1

Part 1 - The Story So Far
 
The title’s pretty much self-explanatory. My colleague, Ray, and I were talking about “The good old days” of online gaming – before Call of Duty, when the dominant games were Unreal Tournament, Quake 3, Counterstrike and the like.

We were toying with the idea of trying to run a LAN game over the work network, but figured the bureaucratic headache that would cause wasn’t worth it.

Then I got to thinking about how to cram everything we’d need for a LAN game into a single portable box, and could easily be set-up, used and torn down again within a lunch hour.

The great thing about returning to older games is that the system requirements, that once required hi-end PCs will now run on pretty much any old commodity hardware. What once meant lugging around heavy, bulky desktops, separate monitors and keyboards, could be replaced with a modern, lightweight laptop.

Ray was bringing in his laptop, and I setup an old laptop for me to use.

I installed Fedora 25 from a live CD (no particular reason for this distro, other than I had a live CD for it to hand – I’m sure others will work fine) Installed WINE, and the game.

We also wanted to use a dedicated server, so I dug through my stack of old hardware to find something to use - and I setup the server using an old netbook.

The networking was provided by an old home router of mine, which supplied DHCP configuration, making the network a straightforward plug and play.

This whole setup was stuffed into a metal flight-case for taking into work, and worked well for a spot of lunchtime multi-player, but there were a few downsides:

• Cabling – lots of mains plugs and network cables.
• Size - it's quite a substantial amount of gear to lug around - the flight case measures 33x46x15 cm and is packed pretty full.
• Although UT runs quite well in WINE, there is definitely some latency. The server seems fine, but graphically on the client machine, it's noticeable
  

The original setup - the netbook in the background is the current server.

Obviously something needs to be done to address the shortcomings, so this will form the basis of my next project - it should be a nice mix of DIY (for the case) and tech (hardware, software config, networking etc).

Update: Part 2 is now here

Oak Desk with Embedded TV/Monitor part 2

This is a continuation of my build of an oak and glass desk with a 32" TV & computer built into it. The first part of the build is here.

Step 3: Routing the back to fit the TV

Even with the plastic bezel removed from around the front of the TV, there's still a metal frame supporting the screen, which can't be removed.

Just sitting the TV against the back of the desktop would leave a gap of 28mm between the glass and the screen, which is enough to look a bit weird.

I routed the back of the desk to allow the TV to be positioned closer to the glass. This meant removing another 10mm from the desktop thickness, leaving the 'ledge' that the glass sits of at 18mm.

Step 4: Creating the legs

It made sense to use the section that had been removed from the middle of the desktop for the legs. However, I didn't want to just use the flat board, as it would just look lazy and reminiscent of flat-pack furniture, even when cut into 4 for the legs.

I also needed to give consideration to the cabling for the screen, which led me to the idea of splitting the wood into 8 pieces, and pairing them together to create the four legs. This would allow for the cabling to be integrated, and give a more solid leg aesthetic which better suited the style I was aiming for.

The 8 leg parts, ready to pair up and join

The wood cut from the centre of the desk, cut to 8 pieces and joined by dowel and wood glue in pairs to create the four legs #DIY #woodworking #oak #doityourself #carpentry #woodwork #handmade

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

To allow for the cable to be run, before joining the last leg, I routed a groove in the joining sides. a hole was drilled through to the outer corner of the leg. This will be tidied up later to incorporate the hole in part of the design so it doesn't look too out of place.

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

Then the corners of the legs were shaped, and open mortises were cut to attach the desks skirt

A photo posted by Anthony (@darkmidnight_diy) on Aug 23, 2016 at 4:55am PDT

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

A photo posted by Anthony (@darkmidnight_diy) on Sep 2, 2016 at 4:43am PDT

With the legs done, I can move onto fitting the TV.

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.