A new Nintendo 64 shooter uses 31 of its 32 megabytes for sound and music

Nearly the entire cartridge is sound. Dominic Szablewski’s Xibalba 64 leaves about one megabyte of a 32 MB ROM for everything that isn’t its music and sound effects, according to his making-of. That gives the monsters a substantial playlist while the rest of the game shares the sliver of cartridge space left beside it.

The developer’s account describes a new shooter published as a physical cartridge with packaging and a manual. It began with Impact, his old JavaScript engine for two-dimensional games, which he had already rewritten in C. A Nintendo 64 game supplied a reason for that earlier project to exist.

The apparent mismatch between a 2D engine and a first-person shooter has a concrete answer. “Since the game has no elevation, it can be mostly treated as 2D,” Szablewski writes. Physics, movement and shooting can work on the flat map even while the renderer presents the world in three dimensions.

That design choice keeps the game from having to solve a whole set of vertical problems. A world can look spatial without allowing the player to occupy different floors at the same map position. Keeping movement on one plane leaves the existing engine’s collision and physics machinery useful even when the renderer presents walls and enemies in three dimensions.

The N64 still brings its own chores. Szablewski describes just 4 KB of texture memory and painfully expensive texture uploads. His renderer groups triangles sharing a texture, reducing unnecessary swaps. Finding enough room for the game is one problem; feeding graphics through the machine efficiently is another.

He uses Libdragon for the platform layer and Tiny3D for rendering support. The existing engine retained its other backends, allowing game logic to be tested away from the console. A level compiler also turns editor JSON into binary data before the game runs, removing parsing work that had added roughly 100 milliseconds of loading.

The development setup is refreshingly tangible. His Nintendo 64 sat beside the PC with a flash cartridge connected over USB, while a cheap capture card put its video in a desktop window. Iterating meant compiling, sending the ROM and pressing the console’s reset button. The cartridge connection made a new build easy to send while the console’s own reset button remained part of the development routine at the desk.

Real hardware remained necessary because the slow memory bandwidth didn’t behave like the emulator. Szablewski describes a more accurate emulator as valuable, then points out the limit it couldn’t settle for him. A convincing picture on a PC wasn’t enough to establish how fast the original machine would move it.

The maker reports stable 60 FPS in the main game, with four-player split-screen sometimes dropping below that. Sound and music account for about 31 MB of the ROM using the compression format described in his post. Those performance claims therefore include an explicit split-screen exception, and the ROM allocation explains how much space was available for the rest of the game.

A new cartridge can therefore spend almost all its storage on audio while graphics performance depends on tiny, repeated transfers somewhere else. Storage capacity and rendering bandwidth are separate constraints; four simultaneous viewpoints still leave an unresolved performance compromise.

The cartridge is mostly the soundtrack.