Tonight's game on OpenPOWER: Doom64EX and Doom64EX-Plus

We haven't done one of these in awhile because it's been a bad, busy summer. I won't bore you with my personal life; there's obvious catharsis when you can unwind mowing down hordes of hell after a long day at the office. Rather than the same old Doom, though (which was the mistake they made with Nintendo 64 Quake), Midway Games made an actual sequel to Doom on the Nintendo 64 using an enhanced engine supporting more advanced level geometry and lighting effects. Monster sprites were higher resolution, sounds were updated and the music changed from Bobby Prince's synthetic metaloid to deeply unsettling ambient by Aubrey Hodges. Plus, all new levels and a new weapon! And that was Doom 64.

Well, N64 decompilations and re-creations have really come into their own, and you can play Doom 64 on your desktop computer too with Doom64EX (done by the same guy who did Strife) or the updated Doom64EX-Plus which instead supports the Nightdive Studios 2020 remaster (Steam link provided for your convenience; I'm not affiliated and I don't get a cut). [UPDATE: Also on GoG.com.] Both releases have improved mouse and keyboard controls and support oodles of resolutions including widescreen.

However, unlike most of the re-creations we've talked about before, there's no getting around it: if you're not playing the remaster you'll need an N64 ROM. And that's all I'm going to say about that. If you have the N64 cartridge and a dump of it, play Doom64EX (it can't play the remaster); if you bought the remaster and have the data files, play EX-Plus (it can't play the original).

Anyhoo, if you want to build the original Doom64EX, it (at least with gcc on Fedora 38) has a glitch where you can't walk backwards. This took a little while to figure out but fortunately is easily fixed, and is already part of Doom64EX-Plus.

diff --git a/src/engine/doom_main/d_ticcmd.h b/src/engine/doom_main/d_ticcmd.h
index 2352bb2..1eef4bc 100644
--- a/src/engine/doom_main/d_ticcmd.h
+++ b/src/engine/doom_main/d_ticcmd.h
@@ -30,18 +30,18 @@
 #pragma interface
 #endif
 
 // The data sampled per tick (single player)
 // and transmitted to other peers (multiplayer).
 // Mainly movements/button commands per game tick,
 // plus a checksum for internal state consistency.
 typedef struct {
-    char    forwardmove;    // *2048 for move
-    char    sidemove;    // *2048 for move
+    signed char    forwardmove;    // *2048 for move
+    signed char    sidemove;    // *2048 for move
     short    angleturn;    // <<16 for angle delta
     short    pitch;
     byte    consistency;    // checks for net game
     byte    chatchar;
     byte    buttons;
     byte    buttons2;
 } ticcmd_t;

For classic Doom 64 EX, to compile you'll need CMake, SDL2, SDL2_net, zlib and libpng, which odds are you have already. I also recommend building using your system FluidSynth instead of the vendored FluidSynth-lite, so mkdir build; cd build; cmake -DENABLE_SYSTEM_FLUIDSYNTH=ON ..; make -j24 # or whatever to build. Finally, generate the WAD data from the totally legally acquired N64 ROM you have with ./doom64ex -wadgen [path], which will digest the ROM and automatically start the game. (For future starts you can just run ./doom64ex directly and it will use the cached WAD.)

For the updated Doom64EX-Plus, cd src/engine && ./build.sh to build; you don't need CMake. Then put the remaster game data in the same directory or /usr/local/share/doom64ex-plus or /usr/share/games/doom64ex-plus, and start the game with ./DOOM64EX-Plus.

Either way, you have a feeling it wasn't meant to be touched.

Tonight's game on OpenPOWER: Shadow Warrior

Well, it's been awhile since we expanded our games library, so let's go back to our regular fast food diet of FPSes and select one from the Build side of the house this time: Shadow Warrior. Build games have a reputation starting with Duke Nukem 3D (a game for another day) and that reputation is well-deserved, so let's get this out of the way: if you found these games iffy in the 1990s, rest assured they've aged badly, because you'll find the content level positively radioactive now between the adult humor, graphic violence and (this game in particular) incredibly inappropriate cultural stereotypes. Stop reading this article now and look at some of our other game builds.

On the other hand, Shadow Warrior was probably the most technically superior of the Build games (with the possible exception of Monolith's Blood): more sophisticated sector effects, coloured lighting, true transparency (including water, though used sparingly to avoid spoilers and performance issues), fog and clouds, larger levels, room-over-room effects and the part I liked the most (and was curiously missing from the classic Mac OS port by MacPlay-Westlake Interactive), voxel-based objects that were truly 3D. All of these features plus OpenGL have made it to JonoF's Shadow Warrior Port (JFSW), using Ken Silverman's Build and Polymost engines (more info).

JFSW builds pretty much out of the box with SDL 2; just type make (or make -j24 or such to exercise your other cores), then copy the .GRP group file from either the 3DRealms shareware install or a registered or retail version to ~/.jfsw (I used my MacPlay CD and named it swmac.grp). Shadow Warrior used redbook audio for the retail version, so for music, rip the tracks and save them as track02.ogg (intro) to track14.ogg ("Lo Wang Raps") in the same directory. Then go to where you've built JFSW and start the game with ./sw, and a configuration window will appear to select your resolution. Note that while widescreen resolutions are supported (and look good), the game still uses 4:3 assets, so things like Lo Wang's sword will be cut off.

A note on resolutions and colour depth: 8bpp modes are rendered 100% in software, which is very fast even on Blackbirds with just BMC graphics, and works beautifully on virtually any system. If you select a 24bpp mode, the game will try to use OpenGL. On my system this caused a freeze (actually an infinite loop, once I stepped through it in a debugger) whenever it attempts to render reflections in a mirror. This appears to be related to non-POT texture support which virtually every card anybody would be running probably supports properly. If you get the same freeze, kill the game and edit jfbuild/src/polymost.c. On line 4903 or thereabouts you'll see if ((method & METH_POW2XSPLIT) && (tsizx != xx)) which if you change to if (0) will get around the code that glitches. I can't tell if this is specific to my card, to OpenPOWER or to gcc, and it doesn't happen in software mode, which plays 100% fine all the way to the end including nuking Zilla himself.

Don't mess with Lo Wang.

Tonight's game on OpenPOWER: ZGloom

We've done some DOS games recently, so for a change of pace let's do an Amiga one. Gloom was a pretty unabashed Doom knockoff using an Wolfenstein-type engine with some map geometry enhancements and transparency and palette effects. I actually have it on my A4000T and it's a bit blocky but plays pretty well with AGA and an '060. You know the drill: marine type guy shoots up other malicious marines, and, um, skinheads, and robots, and then ends up in a Gothic tomb as you do besieged by monsters and ghosts, and then goes to hell, takes the fight to the demons and kills a big dragon to save civilization. Just another day at the office! Its creators made it freely distributable and open-sourced the engine, allowing reimplementations to be made; probably the most developed of these is ZGloom. ZGloom isn't a perfect port — it's missing the title screens, the font and HUD are different, and there are various bugs ranging from trivial to moderate — but it has all the interstitials for what little story there is, has music and sound effects, plays well and does so at high resolution, and has configurable controls with X-axis mouselook. Also, because it's software-rendered, OpenPOWER systems with just the BMC framebuffer can play just fine (it has a multithreaded renderer to take advantage of all those shiny cores we've got). There's no save feature, but ZGloom simply gives you infinite lives, so just keep grinding away with impunity — and while you only have one weapon at a time, you can power it up, so grab all the bouncing orbs you can get for a real supercharge. Doors and switches are triggered by just walking into them, and baby bottles (!) give you health. There are other useful powerups you can find ...

I should also note for the squeamish that Gloom infamously came in "Messy" (temporary gibs) and "Meaty" (permanent gibs) modes, and this port seems to entirely play in "Meaty" mode, which means enemies explode and litter the ground with an alarmingly fast accumulation of body parts. On the original Amiga this would have brought lower-specced systems to their 16-bit knees, but this is a POWER9, so we can have all the fragmented torsos we want. (I have intentionally not shown this in the screenshot.) Don't say I didn't warn you.

Building it from source is straightforward; Fedora 36 has SDL2, SDL2_mixer and libxmp. Before you type make (or make -j24), however, edit the Makefile and add -O3 -mcpu=power9 to the CXXFLAGS. Then download this ZIP of the game resources, unzip it, and copy or symlink the ZGloom binary inside the resulting directory. While you can jump to any level from the main menu, game settings (graphics, keys, etc.) are controlled from the in-game menu after you actually start one.

Now things get serious!

Tonight's game on OpenPOWER: Duke Nukem II

No, not that Duke Nukem game — I mean the platformer. Before the Build engine wrought PG-13 destruction upon the City of the Angels, which also builds and runs on OpenPOWER, Apogee introduced the world's most egotistical alien exterminator in two episodes of heavily armed hopping around. The first installment in 1991 was poor even among PC games of the time, especially considering the far superior (and also Apogee-published) Commander Keen that came out the year before. But the second episode in 1993 had better graphics, better animation, better music, even a rip-roaring VGA cinematic if you had the hardware:

(Always wear your eyes and ears during target practice, kids!) It generally plays fine in DOSBox, but where's the fun in that? RigelEngine is a re-creation of DN2 that plays like the original DOS game mostly faithfully — pedantic quibbles shortly — along with various enhancements such as widescreen support, shown here in the screenshot.

RigelEngine builds out of the box on Fedora 35 and 36, though it has a rather surprising amount of vendored 3rd-party libraries and additionally requires OpenGL, SDL and SDL_mixer. Make sure to clone it with submodules enabled (e.g., git clone --recursive), then mkdir build ; cd build ; cmake .. ; make.

You'll also need a copy of the game, either the shareware first episode (1MB ZIP) or the full game (which I have, as an early DN3D purchaser). Apogee-3D Realms titles have moved from GOG, our usual drug dealer, to ZOOM Platform. Put the NUKEM2.* files into a directory and point the RigelEngine binary at it, or it will present a basic file picker when you start and then remember those settings.

As a clean room re-creation of the game, the additional features are simply incorporated into the game's regular settings menu (i.e., no specific command line options are used to enable them). Widescreen works just dandy with the exception of the radar and inventory frames which can sometimes blend in with the display a little too well; otherwise, I highly recommend it. On the other hand, the smooth scrolling feature — while being as smooth as advertised — makes playing the game feel a little like I've been stoned, uh, not that I would know anything about that, offisher (too used to those rapid 8-pixel and 4-pixel parallax moves). Also, while I'm being an ungrateful whiner, the introductory VGA cinematic is also not quite right compared to DN2 on my real Am5x86/133 DOS tower: there's an extra pause in the transition between "NEO LA: THE FUTURE" and Duke in the shooting range, and his firing rate in the first scene is too quick (it's fine when you're looking at the target). I know, I know, right? Uncanny valley!

Note that RigelEngine doesn't play the original Duke Nukem (this does), nor Cosmo's Adventure, which uses code descended but different from DN2 (this does).

This is too easy!

Tonight's game on OpenPOWER: Death Rally

Let's go for another shooter, but this time a top-down one. Essentially a murderous Super Sprint, Finnish developer Remedy's first game was the exuberantly zippy Death Rally, a decidedly socially hostile top-down racer with machine guns, bombs, spikes, sabotage, splattable spectators and cold hard cash. You can pick up missions for extra money (assassinations, drug running, the usual) or just exterminate your competition for a big bonus and plow the proceeds into a better chassis, a faster engine and better tires and armour. Apogee picked it up and added Duke Nukem for extra competition along with Remedy's cadre of obviously named parody racers (just try to guess who Bogus Bill is).

While Death Rally plays well in DOSBox, and even got an official freeware Windows port, there was never a Mac version (I had to play it on my beat-up old 486) and it was never open-sourced. A few attempts have been made to decompile it but the best of these is dRally, which is 64-bit compatible and compiles out of the box (just make -j24 or as you like for your number of cores) with SDL2 on Fedora 35. The old IPX multiplayer mode isn't supported but everything else mostly works.

Once it's compiled, you'll need a copy of the game assets, of course. I have the GT Interactive retail CD; I have not tried to extract it from the Steam version, 3D Realms no longer sells it directly, and I can't find it on GoG, so let's assume you've got a disc too. For that, just copy over all the *.BPA files (make sure they remain uppercase!) and the CINEM subdirectory from the CD. Create a file called CDROM.INI that simply has one line, ./CINEM (to tell it where the movies are). Start the game in that directory (I made a directory called assets that has everything in it and just symlinked ../drally_linux for convenience).

There are two bugs I ran across, neither serious. The DOS game alternates between 640x480 and a letterboxed (in SDL) 320x200 mode; the former is used for menus and the latter for videos and actual gameplay. On my Talos II in Fedora 35 with a WX7100 there's a lot of garbage in the letterboxed area which can be improved, though not completely eliminated, with this patch. Also, at least with my GT retail copy, if you let the game sit at the menu too long it will eventually go through its brag screens and crash when it hits one that doesn't seem to be in the archive. This patch wallpapers the problem.

Otherwise, I've been gunning down other cars all afternoon, and I haven't had to fire up DOSBox to do it. Get ready to go!

Tonight's game on OpenPOWER: Aleph One and the Marathon series

I had mentioned in the article on SheepSforza, our OpenPOWER port of classic MacOS emulator SheepShaver, that the famous Mac shooter Marathon and its sequels run fine under emulation. Marathon, the first big product from Bungie who went on to create Halo, was a 2.5D game with texture mapping, lighting, sprites and sectors like Doom, but did Doom better by having room-over-room levels (using a portal renderer and polygon tags), free look, a complex plot told through in-game terminals, and a more sophisticated physics model including low-gravity and vacuum environments. Marathon 2: Durandal introduced a more advanced engine with fluid environments you could swim in (often not to your benefit) and larger, more expansive outdoor levels; this version of the engine was licensed for a couple other titles like the bizarre messianic shooter ZPC, and used with minor changes in the third installment, Marathon Infinity. For my money M2 was the best of the series: the original Marathon was understandably a little underdeveloped, and Infinity's convoluted time-shifting plot was very hard to wrap your head around, but M2 had just enough story complexity to be interesting and a bit more varied gameplay to keep you engaged through the tougher parts.

Also like Doom, Bungie eventually released the source code, in this case to Marathon 2 which was the only version of the engine to run anywhere other than the Mac. Marathon Infinity was also later released in source form, and both games became the nucleus of a modern reimplementation, Aleph One. But again, Bungie did Doom better: they also released all three games' assets for free too, so you don't need to hunt down a CD to play it legally. I happen to own a copy (bought new back in the day) of the Mac Action Sack, but this is even better — especially because I don't remember where the canvas bag went.

Aleph One runs all three official installments, plus a number of total conversions, hobby scenarios and even a port of the Wolfenstein-esque Pathways into Darkness, Bungie's banner 3D game prior to Marathon and arguably in the same universe. (It was also one of the first games to run native on the then-new Power Macintosh, so it's special to us here in OpenPOWER land.) Strangely, one game it doesn't run is ZPC, which is a bummer because it's truly one of a kind. However, I think Marathon 2 is (again) the best Aleph One game as it has the fullest selection of high-resolution textures from the Xbox Live Arcade remaster; the other two games don't look nearly as good.

For this brief tutorial we'll assume you're playing M2 (the process with the others is similar). Download game assets and unzip them to ~/.alephone/Scenarios/Marathon2 (such that you see all the .???A files, Music.ogg, etc. in that directory). Put any plugins (the high-resolution assets are plugins) into ~/.alephone/Scenarios/Marathon2/Plugins (I unzipped them also, but strictly speaking this isn't necessary if you have all the requisite libraries when you build the actual game binary).

Now build the game engine. The Github build instructions work out of the box for Fedora 35 on my Talos II (and presumably should work for Ubuntu), and other distros should be similar. However, I built Aleph One with CFLAGS="-O3 -mcpu=power9 -flto" CXXFLAGS="-O3 -mcpu=power9 -flto" ./configure to give it a little extra juice, and then make -j24 (or as your number of cores permit). To start the game, assuming you have the Github in ~/src/alephone, ~/src/alephone/Source_Files/alephone ~/.alephone/Scenarios/Marathon2 will transport you to Lh'owon. I recommend turning on all the graphics options under Preferences (the screenshot here has hi-res textures for everything along with lighting bloom); with the Raptor BTO WX7100, the game runs like butter, so take advantage of it. In particular, make sure the frame rate is unlimited and filter and antialias all the things if you have a GPU. On the other hand, with an AST2500-only OpenPOWER system, set the rendering mode to Software instead of OpenGL and you'll get a decent (classic) experience, though you may wish to not use the hi-res version for speed purposes.

The only good BOB's a dead BOB.

Tonight's game on OpenPOWER: Space Cadet Pinball

I've always loved pinball even though in league play I was always pretty much bang-up average. My first experience was with a Williams Pin-Bot at the local roller rink (I can't rollerskate either) and I was hooked. In Floodgap Orbiting HQ we have a Williams Star Trek: The Next Generation which I'm doing a long-playing LED upgrade on and a Stern Sopranos.

Computer pinball, however, has been a mixed bag, largely because of the simulation fidelity necessary for good play. Nowadays you have Pinball Arcade on mobile devices and Visual Pinball on Windows, but for years the physics never really exceeded what you got in Bill Budge's 1982 Pinball Construction Set and table features were even more limited. The mid 1990s introduced probably the first generation of computer pinball games that actually played vaguely like real pinball and some real pinball tables were even ported (I played a credible if low-res version of Bally's Eight Ball Deluxe on my Mac).

Of these, one of the best known was Maxis' Full Tilt Pinball in one of its tables' incarnation as 3D Pinball for Windows - Space Cadet, included first with Windows Plus! for Windows 95 and then with every version of Windows afterwards (including NT 4 and Windows 2000) through Windows XP inclusive. This version was a port of the original Space Cadet table written in cross-platform C and had a slightly different ruleset. I enjoyed this version on my father's AT&T Pentium 75; later I got Full Tilt Pinball for Mac, which was a dual-version disc with Windows.

Apparently I'm not the only one that liked it because the 3D Pinball version was eventually decompiled and rewritten. This redux not only plays authentically with the assets from the Windows Plus! version, but can use the higher-res versions with Full Tilt, though the ruleset is still from the Plus! game. It uses SDL and can scale to larger screen sizes and faster frame rates.

Compilation on Fedora 34 on this Talos II was straightforward. With development headers installed for SDL2 and SDL_mixer, grab the tree (do this from tip, not version 1.1), mkdir build, cd build, cmake .. and make. Copy the resources from the game — for Full Tilt this is pretty much CADET.DAT and the SOUND folder, but for the Plus! version copy everything in the same folder as PINBALL.EXE — into the build directory (if you're using the Full Tilt version as I did, you may need to loop-mount the disc to get the Windows XA session to show up) and start with ./SpaceCadetPinball.

For best results, under Options make sure Music is checked (you'll need something that plays MIDI files), under Options, Table Resolution make sure Use Maximum Resolution is checked (if you use the Full Tilt assets, you get 1024x768, and you can enlarge the window for sizes even larger), and under Options, Graphics make sure Uncapped UPS is checked so you get all the frames.

Good luck, Cadet.

Tonight's game on OpenPOWER: System Shock Enhanced Edition

Yeah, I know we're doing a lot of FPSes in this series. It's what I tend to play, so deal. Tonight we'll be playing System Shock, the classic hacker-shooter (seems appropriate), courtesy of Shockolate, which adds higher resolutions, better controls, mouselook and OpenGL support. Our drug dealers at GoG, who don't pay us a cent for this kind of shameless plug and really ought to, make the game files easily available as System Shock Enhanced Edition. However, you can also use the DOS or Windows 95 CD-ROM; I tested with both. (I'll talk about the Macintosh release in a moment.)

Shockolate requires CMake and SDL2, and FluidSynth is strongly advised. Don't let Shockolate build with its bundled versions: edit CMakeLists.txt and change all "BUNDLED" libraries to "ON" (don't forget the quote marks). Once set, building should work out of the box (tested on Fedora 34):

mkdir build
cd build
cmake ..
make -j24 # or as you like
cd ..
ln -s build/systemshock systemshock

(The last command is to make running the binary a little more convenient.)

Now we need to provide the resources. For FluidSynth, you'll need a soundfont (I used the default that comes with Fedora's package). If you have the DOS/Windows CD-ROM, insert it now. We will assume it is mounted at /run/media/censored/EA.

mkdir res
cd res
ln -s /usr/share/soundfonts/default.sf2 default.sf2
cp -R /run/media/censored/EA/hd/data .
cp -R /run/media/censored/EA/hd/sound .
chmod -R +w . # if copying from CD makes things read only
cd data
rm -f intro.res
rm -f objprop.dat
cp /run/media/censored/EA/cdrom/data/* .
cd ../..

Then start the game with ./systemshock. The resolutions and choice of renderer (software or OpenGL) are set from the in-gameplay menu (press ESC). Shockolate also implements WASD motion (as well as the classic arrow keys) and F to toggle mouselook. Note that OpenGL is somewhat darker than software mode. It's not clear if this is actually a bug.

Playing System Shock Enhanced Edition in Shockolate is just a more convenient way to get the DOS assets since Shockolate just uses those and not any of the patches (more about this in a second); gameplay and features are the same. Also, GoG only distributes it as a Windows installer and the file structure is a bit different. Use innoextract to break the installer EXE apart into a separate directory and delete everything but sshock.kpf, which is a cloaked ZIP archive containing the game assets. In your Shockolate source directory (note that this also creates res/, so if you did the steps above delete it first),

mkdir ssee
cd ssee
unzip /path/to/sshock.kpf
cd ..
mkdir res
mv ssee/res/pc/hd/data res
cp ssee/res/pc/cdrom/data/* res/data/
mv ssee/res/pc/hd/sound res
rm -rf ssee # if you want
ln -s /usr/share/soundfonts/default.sf2 res/default.sf2

Then start the game with ./systemshock.

Oddly, although Shockolate was based on the (IMHO) superior Power Mac release, it doesn't seem to properly support its higher-resolution assets (SSEE does and includes a converted set, but the source for that — unlike Strife — isn't currently available). I actually own this version also. One rather unique reason to own it is because the cutscenes and audio files are all playable in QuickTime, so if you don't feel like slogging through the entire game you can just listen to the audio logs or go straight to the ending using a Mac emulator. However, you need to do a little song and dance to mount the HFS volume on Linux (as root):

losetup /dev/loop0 /dev/sr0 # or where your drive is
partx -av /dev/loop0

This will respond with something like

partition: none, disk: /dev/loop0, lower: 0, upper: 0
/dev/loop0: partition table type 'mac' detected
range recount: max partno=2, lower=0, upper=0
/dev/loop0: partition #1 added
/dev/loop0: partition #2 added

and you should see it mount in your desktop environment (note that many applications won't understand the resource fork). Do losetup -D before ejecting the physical disc. As a parenthetical note, since SSEE is presumably derived from the GPL-released Mac source code, you would think it, too, would be GPL. But I'm uncertain of the exact history there.

Salt the fries.

Tonight's game on OpenPOWER: Blake Stone Aliens of Gold

Everything is awful, so now that we've rescued a Blackbird let's go shoot more aliens. One of the more entertaining games based on id's Wolfenstein 3D engine was Apogee's Blake Stone: Aliens of Gold from 1993, developed by yet another set of apparent refugees from Softdisk, but that's another story for another day. It kept the basic formula but added subtle lighting effects and ceiling and floor textures, along with more varied environments, lots of (cartoony but fun to shoot) monsters, and a very helpful automap.

Ordinarily this wouldn't be worth a mention; that's what we have DOSBox for (see our article on adding an OpenPOWER JIT to DOSBox). Despite the fact that DOSBox does support this game, however, I do actually own a retail copy of Blake Stone from back in the day and it runs like dried snot even with a JIT.

Fortunately, the source code to Blake Stone was released back in the day as well after it was long believed to be lost, and an excellent SDL/OpenGL port called BStone is available which adds many graphical improvements, mouse look (well, side to side, anyway), and 16:9 modes as demonstrated in the screenshot. It also supports the IMHO inferior sequel, Planet Strike.

To start saving mankind, you can play the shareware version, but it's more fun to play with a retail copy (mine is the 1994 FormGen release, but the one you can still buy from Apogee will work), or extract the game assets from the DOSBox-based GOG installer. The CD or 3D Realms downloads are easiest to work with, as you can just copy the contents into a folder.

Clone the BStone Github project. You will need CMake and SDL 2.0.4 (or better) development headers and libraries. The CMake build recipe assumes that your SDL has a static libSDL2main.a library, which apparently the ones from Fedora, Slackware and possibly others don't, which may require modifying the SDL CMake component that comes with it (I had to). Then mkdir build, cd build and cmake .. to kick it off.

Once built you can start the game either from the directory where your Blake Stone files are (I have cd ~/stuff/dosbox/BSTONE && ~/src/bstone/build/src/bstone), or pass bstone the --data_dir option with a path (if it fails to detect the correct game, try passing --aog, --aog_sw or --ps). If you don't have OpenAL-capable hardware, disable OpenAL sound from the in-game configuration menu, or you may get random crashes during play. Don't shoot the informants.

Tonight's game on OpenPOWER: The Original Strife Veteran's Edition

I'm a big fan of Strife, famously the last game to use id Software's Doom 3-D engine, and a nice hybrid of light RPG and heavy action. The engine might have been old and the plot was more shooting than Shakespeare, but hey: the voice in your ear is named Blackbird. You can't beat that!

I actually do own a retail copy of Strife from back in the day for MS-DOS; I bought it new and played it on the 486 I still keep around for such things. It plays just fine in Chocolate Doom on this POWER9, but I later heard about Strife: Veteran Edition on GOG.com that fixed minor bugs with better music and improved graphics, and even threw in some extra enhancements and achievements, but still kept the plot, voice acting and character art. It had a Linux version, but clearly one for x86. But that's not a problem when you have the source code.

The source code builds largely uneventfully as long as you have the prerequisites (Fedora 33 and I did not test on big-endian). In particular, it will want cmake, SDL2, libogg, libtheora, libvorbis, zlib, libpng and OpenGL. However, it tries to link against libSD2_main which is no longer necessary; after you've run cmake and make, it will fail with No rule to make target 'SDL2_MAIN_LIBRARY-NOTFOUND'. To get around this, edit (in the build directory where you ran cmake) ./CMakeFiles/strife-ve.dir/link.txt and remove SDL2_MAIN_LIBRARY-NOTFOUND from the single long line link command, then edit ./CMakeFiles/strife-ve.dir/build.make and just delete the line strife-ve: SDL2_MAIN_LIBRARY-NOTFOUND. Run make again and it will link.

Since it built, I decided to spend $10 and try to extract the game assets from the GOG pack. GOG gives this to you as a behemoth 400 megabyte "shell script" which is really a wrapper for a ZIP archive with a MojoSetup installer. Irritatingly the installer is all just binaries, but you can feed it to unzip and it will break it apart. If we list the contents of the file, it will conveniently ignore the header and go right for the ZIP archive, and the money is in data/noarch/game. Thus, do unzip ./the_original_strife_veteran_edition_1_1_1_43197.sh data/noarch/game/'*' and the assets will be extracted to data/noarch/game.

If you want, you can just move the files in game/ (maintain the tree under it, don't flatten it) in with the POWER9 binary of strife-ve, but if you don't want all the x86 binary crap you don't need, a quick find . -name '*.so.*' -print | xargs rm and rm strife-ve before you copy it over should remove the bulk of it. Conveniently, the GOG assets also include the original DOS version (in DOS/) and all the relevant WADs so you can also run it in Chocolate Doom or our OpenPOWER-JIT DOSBox, and another copy of the source code just in case you lose it. Anyway, with everything moved, if you run ./strife-ve it should then just work.

Don't keep the Front waiting.