The proof is in the scrolling
During my early school years, I came across all sorts of computers. First the C64, then the earliest IBM PC, the XT with the DOS operating system and a horrible monochrome screen. The equally horrid 4-color CGA version came a bit later with some memorable games like Prince of Persia, Grand Prix Circuit, Commander Keen, or Defender of the Crown. These machines were not solely made for gaming, which clearly showed in their performance. The games for these systems were a lot of fun, and we played with them for endless hours but they always had low-quality graphics and wonky animations due to the hardware limitations. Plus, the interfaces of these games consisted of loud bulky keyboards, fragile joysticks, and even worse mouse pointers with the dust collecting rubber balls. Compared to the C64 games, they were a step back in quality.
A pivotal moment that is forever engraved as a core memory happened when I was introduced to the Nintendo Entertainment System, or as everyone calls it: the NES. I sat down to play with it during a visit to some family friends, and the cartridge that was inside was Zelda II: The Adventure of Link. All my previous moments with computer games went out the window as I witnessed the capabilities of a hardware specifically designed for gaming and nothing else. It felt like I hadn’t played with electronic games before. It might seem futile to compare a computer system to a video game console, as they were made for different purposes, but I can’t help but draw a comparison. Both were released around the same time, (C64 1982 / NES 1983), and both had similar resolutions (C64 320x200pixels and the NES 256x240pixels) but there were major distinctions. Even though, on paper, the C64 was superior in most of the specs, 2 key factors made a world of difference. One was the smooth scrolling of the NES’ thanks to its dedicated graphic hardware. It was a revelation to see smooth animation on the screen, even though it was restricted to some parts of the game via sprites, usually the avatar of the player or other important elements.
The other game changer was the gaming interface, the gamepad. It was a breath of fresh air after years of destroying one-button joysticks and pounding the direction keys and the spacebars of unergonomic PC keyboards for hours. The D-pad and the 2 buttons on the blocky NES controller opened up the world for new gaming experiences that were previously unimaginable. Nintendo has paved the way for innovation ever since with its unique approach to gaming and has never shied away from experimenting. If anyone wants to dive deeper into the history of NES a comprehensive video is available: NES history or a more nostalgic ride.
The devil is in the details
There is something inherently fascinating about finally holding in your hands the creation you worked on for so long. A simple idea is manifested in the physical realm through endless hours, days, weeks, and months of thinking, sculpting, and iterating [over and over again. Nothing beats this feeling.
The first dozen 3D prints were ready and the hard part had just begun. Now that the parts were fitted mechanically inside the housing, (which was quite a feat on its own) it was time to put it to work and make it communicate with a computer. I’m not in any way an expert in electrical engineering so I can’t give any in-depth technical details but a friend of ours, Andrew is, and he made it happen over a few months. We used custom parts, except for the thumbstick mini-joystick components. Those are equipped with potentiometers, which tend to wear out, but since these were prototypes, it wasn’t much of a concern. For the other sensors, we used hall effect magnetic sensors, simply because they were easier to install.
Adding extra analog axes to a controller was a real challenge. The form had to be as small as possible, but because there were far more moving parts compared to a traditional gamepad, the space inside the housing was very restricted. And this wouldn’t be enough of a challenge something was always acting up. The sensors’ signals were too noisy, the cables got pinched by a mechanical part, and sometimes the solder points on the PCBs failed because of the constant movement of the wires. We managed to tackle most of the problems and it was time to make it communicate with the PC. This is where we hit a really big obstacle. Windows uses Xinput and DirectInput for gamepads (and other peripheral communication), and they both have limits on analog inputs. DirectInput has an 8 analog input limit and Xinput has 4. None of these were sufficient for us and unfortunately, we didn’t have the resources to write a custom driver API for the controller. Our controller had 11 analog inputs (3×3 directional axes and 2 triggers) and 2 digital buttons, so we had to come up with a solution. To make it work, we split the signals into two parts, so Windows recognized it as two controllers. It wasn’t ideal but was a necessary workaround. Because both controllers had the same ID numbers and names, identifying them during troubleshooting was challenging. Additionally, the analog and digital inputs were assigned inconsistently between the controllers. This became a pain when we worked on demo games using Unreal Engine. I’m not sure whether this issue arose from a technical restriction or a programming error, but despite these hurdles, we managed to make it work. The controllers were finally communicating with the computer, and now it was time to put them to the test.
*The original idea was to have a solution against ‘buttonitis’ as every new iteration of gaming controllers has more and more buttons which makes gaming harder and there are only 5 fingers on each hand there’s a cap on how many can be used and activated at once.
Stay tuned…
