Quake In 276 KB Of RAM

Porting the original DOOM to various pieces of esoteric hardware is a rite of passage in some software circles. But in the modern world, we can get better performance than the 386 processor required to run the 1993 shooter for the cost of a dinner at a nice restaurant — with plenty of other embedded systems blowing these original minimum system requirements out of the water.

For a much tougher challenge, a group from Silicon Labs decided to port DOOM‘s successor, Quake, to the Arduino Nano Matter Board platform instead even though this platform has some pretty significant limitations for a game as advanced as Quake.

To begin work on the memory problem, the group began with a port of Quake originally designed for Windows, allowing them to use a modern Windows machine to whittle down the memory usage before moving over to hardware. They do have a flash memory module available as well, but there’s a speed penalty with this type of memory. To improve speed they did what any true gamer would do with their system: overclock the processor. This got them to around 10 frames per second, which is playable, but not particularly enjoyable. The further optimizations to improve the FPS required a much deeper dive which included generating lookup tables instead of relying on computation, optimizing some of the original C programming, coding some functions in assembly, and only refreshing certain sections of the screen when needed.

On a technical level, Quake was a dramatic improvement over DOOM, allowing for things like real-time 3D rendering, polygonal models instead of sprites, and much more intricate level design. As a result, ports of this game tend to rely on much more powerful processors than DOOM ports and this team shows real mastery of their hardware to pull off a build with a system with these limitations. Other Quake ports we’ve seen like this one running on an iPod Classic require a similar level of knowledge of the code and the ability to use assembly language to make optimizations.

Thanks to [Nicola] for the tip!

ZX Spectrum Gets A 3D FPS Engine

The Sony PlayStation and Nintendo 64 are well-known for bringing 3D gaming into the mainstream in a way that preceding consoles just couldn’t. The ZX Spectrum, on the other hand, is known for text adventures and barebones graphics. However, it now has a rudimentary version of a Quake-like engine, as demonstrated by [Modern ZX-Retro Gaming].

As you might expect, the basic ZX Spectrum that sat in front of your dodgy old TV in the 1980s isn’t really up to the task of running a full 3D game. The engine runs at a fairly jerky frame rate on a 3.5 MHz ZX Spectrum, with purely monochrome graphics. However, the game can run more smoothly on 7, 14, and 28MHz ZX Spectrum compatibles. As with many such projects, most of the video you’ll see is of the game running in emulators. Impressively, the game features sound effects, three weapons, and a standard WASD control layout as per modern FPS games.

If you’re wondering about the confusing visuals, there’s a simple explanation. Yes, the UI and weapons are straight out of Doom. However, the game is running on a true 3D engine, with 3D enemies, not sprites. It’s inspired by the full 3D engine pioneered by Quake, hence the designation.

Files are available for those wishing to try it out at home. We do see a fair bit of the ZX Spectrum around these parts. Video after the break.

Continue reading “ZX Spectrum Gets A 3D FPS Engine”

Quake 2 Ported To Apple Watch

DOOM always seems to spontaneously appear on any new device the day it’s released. From printers to industrial robots to pregnancy tests, it always makes its way on anything with an integrated circuit and a screen. But that’s not the only 90s video game with a cult following and and ability to run on hardware never intended for gaming. The early Quake games are still remarkably popular, and the second installment of this series was recently brought to the Apple Watch thanks to [ByteOverlord].

Building this classic for the Apple Watch requires using the original Quake files and some work with Xcode to get a package together that will run on the wrist-bound computer. There are a few other minimum system requirements to meet as well, but with all of that out of the way the latest release runs fairly well on this small watch. The controls have been significantly modified to use the Apple’s touch screen and digital crown instead of any peripherals, and as a result it’s not likely you’d win any matches if it was possible to cross-play with PC users with a setup like this, but it’s definitely playable although still missing a few features compared to the PC version.

This actually isn’t the first Quake game to be ported to the Apple Watch, either. The first version of Quake ran on this device thanks to [MyOwnClone]’s efforts a little over a year ago. It’s also not the first time we’ve seen Quake running on unusual Apple hardware, either. Take a look at this project which uses one of the early iPods to play this game, along with the scroll wheel for a one-of-a-kind controller.

Thanks to [Joni] for the tip!

Adding Portals To Quake

For those who have played Quake extensively, adding portals seems unnecessary, as teleporters are already a core part of the game mechanics. What [Matthew Earl] accomplishes is more of the Portal style of portal by rendering what is on the other side of the portal with a seamless teleportation transition.

Of course, Quake is an old game with a software renderer. Just throwing another camera into the scene, rendering to another texture, and then mapping that texture to the scene isn’t an option. Quake uses an edge rasterizer and generates spans along scanlines that track where edges intersect the current scanline. Rather than making expensive per-pixel comparisons, [Matt] stashes the portal spans and renders them in a second render, so even with multiple portals, only a single screen’s worth of pixels are rendered.

However, this technique has no near clipping plane, which means objects can appear in the portal that don’t make any sense as they are in front of the portal’s viewpoint. Luckily, Quake has an ingenious method for polygon occlusion: the BSP. While [Matt] is manually checking polygons, the BSP is the perfect tool for bisecting a room along a plane. It’s an incredible hack, and we’re excited to see Quake expand into a puzzle game. [Matt] dives into greater detail on how the software renderer works in another video that’s well worth a watch.

Perhaps the most incredible aspect of this technique is that it could run on original hardware. If you want to bring a little more Quake to life, why not get the Quake light flicker in your house? Video after the break.

Continue reading “Adding Portals To Quake”

Bringing The Quake Flicker To Life With A Hacked Light

If you ever feel a pang of shame because you’ve been reusing the same snippets of code in your projects for years, don’t. Even the big names do it, as evidenced by the fact that code written to govern flickering lights back in 1996 for Quake is still being used in AAA titles like 2020’s Half-Life: Alyx. In honor of this iconic example of digital buck-passing, [Rodrigo Feliciano] thought he’d port the code in question over to the Arduino and recreate the effect in real-life.

Since the Quake engine has been released under the GPLv2, it’s easy to pull up the relevant section of the code to see how the lighting was configured. Interestingly, lighting patterns were implemented as strings, where the letters from a to z referenced how bright the light should appear. So for example, a strobe light that goes between minimum and maximum brightness would be written as “aaaaaaaazzzzzzzz”, while a flickering light could be represented with the string nmonqnmomnmomomno“.

An emergency light provided the LEDs and enclosure.

This ended up being very easy to implement on the Arduino in just a few lines, as [Rodrigo] simply had to assign each letter in the string a numerical value between 0 and 255 using map, and then use the resulting number to set the LED brightness with analogWrite.

With the code written, [Rodrigo] then had to put the hardware together. He stripped down a basic emergency light to get an array of white LEDs and a handy enclosure. He also wired up a simple transistor circuit on a scrap of perfboard so the Arduino Pro Mini could control all the LEDs from a single GPIO pin. Combined with a long USB cable to power it, and he’s got a perfect desk accessory for late-night gaming sessions.

In the video below you can see the final result, which [Rodrigo] has even synced up to footage from the classic 1996 shooter. The light makes for an interesting conversation piece, but we think the logical next step is to work this technique into an ambilight-like system to really make it feel like you’re wandering down those dimly lit corridors.

Continue reading “Bringing The Quake Flicker To Life With A Hacked Light”

Porting Quake To An IPod Classic Is No Easy Task

We didn’t think we’d see another hack involving the aging iPod Classic here on Hackaday again, yet [Franklin Wei] surprises us with a brand new port of Quake for the sixth-generation iPod released some thirteen years ago. Is Quake the new 90s FPS that’ll get put into every device hackers can get their hands on?

The port works on top of RockBox, a custom firmware for the iPod and other portable media players. This isn’t the first game on the device. A source port of Doom has been available for years. [Franklin] decided to use Simple DirectMedia Layer (SDL) to make his job easier. That doesn’t mean this was an easy task though, as [Franklin] describes very interesting bugs that kept him from finishing his work for about two years.

The first problem was that the GCC compiler he was using was apparently not optimizing time-critical sound mixing routines. [Franklin] decided enough was enough and dug into ARM assembly to re-write those parts of the code by hand. He managed to squeeze out a speed increase of about 60%. Even better, he ran into a prime example of a bug that would get triggered by a very specific sound sample length running through his code. Thankfully, with all of that sorted, the port is now released and we can all enjoy cramping our hands around tiny screens to frag some low-poly monsters.

If you need to repair your sixth-generation iPod before you can do that though, no need to worry since they seem to not be so hard to service by yourself. And if the battery life and disk space aren’t quite what they used to be, there’s also the option to bulk it up for winter. Check out the Quake port in action after the break.

Continue reading “Porting Quake To An IPod Classic Is No Easy Task”

Peering Inside The GPU Black Box

Researchers at Binghamton University have built their own graphics processor unit (GPU) that can be flashed into an FGPA. While “graphics” is in the name, this GPU design aims to provide a general-purpose computing peripheral, a GPGPU testbed. Of course, that doesn’t mean that you can’t play Quake (slowly) on it.

The Binghamton crew’s design is not only open, but easily modifiable. It’s a GPGPU where you not only know what’s going on inside the silicon, but also have open-source drivers and interfaces. As Prof. [Timothy Miller] says,

 It was bad for the open-source community that GPU manufacturers had all decided to keep their chip specifications secret. That prevented open source developers from writing software that could utilize that hardware. With contributions from the ‘open hardware’ community, we can incorporate more creative ideas and produce an increasingly better tool.

That’s where you come in. [Jeff Bush], a member of the team, has a great blog with a detailed walk-through of a known GPU design. All of the Verilog and C++ code is up on [Jeff]’s GitHub, including documentation.

If you’re interested in the deep magic that goes on inside GPUs, here’s a great way to peek inside the black box.