Building a Retro Linux Gaming Computer
Part 15: Square Cubed

By Hamish Paul Wilson
First published on 2022-03-07

Continued from Part 14: Return to Na Pali

Return to Index

John Carmack's generosity in releasing his older source code resulted in a proliferation of free first person shooters in the 2000s with almost all of them based on some variation of the Quake engine. This proved to be a boon to Linux gamers, but Dutch programmer Wouter van Oortmerssen rejected this path to forge Cube based in the same "just for fun" spirit with which Linus Torvalds first began work on the Linux kernel.

Unlike Torvalds though Cube was helped by Oortmerssen's deliberate rejection of the open source model, which often clashes with the auteur nature of independent game development. The source code is available under the zlib License for anyone to modify, but the distributed game itself is his own curated creation, with his singular vision proving to be what happens when you mix Doom, Quake, and Serious Sam in a blender.

In the end I had to use the oldest binaries still available from SourceForge, those contained in the cube_2002_10_20.zip archive, as every later packaged version of the game was built against libstdc++5 which is too new for my Red Hat Linux 7.3 installation. This places me in the curious position of being on the opposite end of the glibc 2.3 compatibility problem, as this is the main library which causes issues when running certain Loki Software games on newer systems.

I did try building the final Cube source code myself on Dianoga, but was not able to provide the ENet development libraries that Cube requires. The last released binaries do still run on my modern Arch Linux computer, although I had to modify the launch script or it would complain "Your processor does not have a supported Cube client" upon discovering I was starting the game under x86_64. Overriding the check resolved this, but it still suffers from a video memory leak.

While Cube never became the slickest game, this early version from 2002 is even rougher around the edges. I actually found the game easier to play after familiarizing myself more with the final release and then going back, as the monsters in their earlier incarnations do not telegraph their attacks as much and simply transform into meaty chunks when killed, not giving me as much feedback to aid in developing viable counters.

Only 3 monsters remaining

Toggling the built-in map editor

Single player consists of two modes, "SP" which plays like a standard first person shooter campaign where you progress through levels unlocking areas until all the monsters are killed, and "DMSP" which takes the form of a horde mode but with there still being a finite number of enemies to eliminate on a map. These work, but it is way too easy to end up with just one or two monsters left on a level, forcing you to scour the entire map again in search of them.

Limitations like this make "DMSP" more enjoyable than the "SP" mode, as the tighter formula of stock up, hold your ground, then hunt down the stragglers, rinse and repeat, plays more to the game's strengths with the chaotic gunplay and monster infighting. More remarkable than Cube itself is the engine that powers it, due to its advanced in-game level editing abilities but also the engine's conspicuous simplicity.

Levels are actually displayed using a 2D height map similar to that of the original Doom, having most of the same restraints such as no rooms over other rooms, but with Cube also supporting slopes and 3D modeled polygonal assets. The result is a delightful blend of both the old and the new, which along with all the map data being interpreted on the fly makes for an easy yet powerful creative tool for constructing levels or even entire new games.

The performance of the Cube engine was also quite acceptable, feeling fluid for me except for in the most intense situations even when using default settings. There were some graphical glitches, mostly along the seams of walls, floors, skyboxes, as well as the edges of water, and there were a few broken transparencies with projectile sprites. Overbright lighting also gets disabled, which is odd as the game documentation states that my video card should support it.

The flexibility of the engine resulted in a number of forks, the most notable being AssaultCube, a standalone tactical spin off which still sees active development. There is also the sequel Cube 2: Sauerbraten, which brings the same editing features of Cube to a full 3D game engine, and was last updated in 2020. Having put my Rage 128 Pro through its paces running three different OpenGL game engines on Linux, let us now try to exercise my Sound Blaster 16 instead.

Carrying on in Part 16: We Are All Doomed

Hamish Paul Wilson is a free software developer, game critic, amateur writer, cattle rancher, shepherd, and beekeeper living in rural Alberta, Canada. He is an advocate of both DRM free native Linux gaming and the free software movement alongside his other causes, and further information can be found at his icculus.org homepage where he lists everything he is currently involved in.

http://www.icculus.org/~hamish

Comments

You can use your Fediverse (including Mastodon, among many others) account to reply to this post. You can also follow my Mastodon to be notified when new parts of this series are released.

It appears that the video memory leak I was experiencing with the final release of Cube on Arch Linux may actually be due to a bug in the R600 Gallium3D driver. Switching from an older Radeon HD 4670 graphics card over to the newer Radeon RX 480 which uses the AMDgpu driver seems to have resolved the issue. In addition, I am no longer experiencing video memory leaks when playing Unreal Tournament 2004, or encountering a memory leak with Planescape: Torment: Enhanced Edition, although I am less certain that the latter problem was due to the same graphics driver bug.

Licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)