Zum Inhalt der Seite gehen


Quake ported to Arduino Nano Matter. [Using only 276kb RAM]

Nicola Wrachien with Silicon Labs created this fun handheld, porting Quake using the Arduino Nano Matter. For easy playing a custom controller shaped board was designed with joysticks and a screen.

https://next-hack.com/index.php/2024/09/22/quake-port-to-sparkfun-and-arduino-nano-matter-boards-using-only-276-kb-ram/

#quake #arduino #nano #diy #handheld #port #retro #gaming #art #maker #engineer #artist #media #programming #tech #news
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, like 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.
[ImageSource: Nicola Wrachien]

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.

<https://community.silabs.com/s/share/a5UVm000000Vi1ZMAS/quake-ported-to-arduino-nano-matter-and-sparkfun-thing-plus-matter-boards?language=en_US>

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.