Posts

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.

Firefox 116 on POWER


Firefox 116 is out with user interface improvements (notably a sidebar switcher), faster HTTP/2 uploads, and some initial UI rework for changes to how recently closed tabs are handled. On the developer side, the Audio Output Devices API lets you redirect browser audio output to a permitted device without having to change it globally, plus directional attributes for certain HTML form elements for those of you using a right-to-left language system.

This release needs new patches. First, for the long-playing bug 1775202, either put --disable-webrtc in your .mozconfig if you don't need WebRTC, or tweak third_party/libwebrtc/moz.build with this updated patch. The browser otherwise builds and works with an updated PGO-LTO patch and the .mozconfigs from Firefox 105.

Firefox 115 on POWER


Firefox 115 is out, which is also the new Extended Support Release base. A nice feature on Linux is a middle click on the new tab button will open a new tab with whatever URL is on the clipboard (on the other hand, middle click on an existing tab closes it, so the interface is a wee bit muddled here); a more questionable feature is a Mozilla-controlled extension blocklist by domain. There are also additional updates to the Web platform.

The good news about building is that the fix for bug 1838584 landed on Fx115, so you won't need that patch to build like we did for Fx114. Apart from that, you'll just need to deal with bug 1775202 as usual, either by putting --disable-webrtc in your .mozconfig if you don't need WebRTC, or patching third_party/libwebrtc/moz.build with this patch. The browser otherwise builds and works with the PGO-LTO patch for Firefox 110 and the .mozconfigs from Firefox 105.

Linux 6.4


While we wait to see what Red Hat's new source code policy does to RHEL rebuilds like RockyLinux and Alma Linux downstream, Linux 6.4 came out this week. Aside from things like new hardware support, filesystem improvements (such as a small performance win for ext4) and more Rust code, and the removal of the old SLOB memory allocator, there's not a lot here on the Power ISA side this time around except for the removal of various older evaluation boards. Expect to see it in Fedora and more leading edge distributions shortly.

Firefox 114 on POWER


Firefox 114 is released. The biggest update in my humble opinion is that (assuming you're running Linux) you can now use FIDO2/WebAuthn authenticators over USB, and virtually all of them should "just work" with OpenPOWER hardware. I'm going to try this out and report back but cursorily looking at the source code I don't see any reason why it would be incompatible. If you bought your POWER9 for security purposes, or even if you just like being secure-adjacent, here's another advance to take advantage of. A more nebulous new feature in 114 is support for WebTransport, which adds low-latency datagram-grade server communication and should facilitate more interactive applications but will probably just be another way for sites to spy on you. Oh well! This initial cut requires HTTP/3 but HTTP/2 support is coming.

Fx114 will not build out of the box. First, as usual you'll need to deal with bug 1775202, either by putting --disable-webrtc in your .mozconfig if you don't need WebRTC, or patching third_party/libwebrtc/moz.build. Unfortunately the patches in that bug no longer serve, so here's the diff on mine, which builds the browser I'm typing in now.

Second, there's a regression in the profiler which breaks linking, filed as bug 1838584 and also present in Firefox 115 currently, apparently a regression from bug 1824465. The provided patch in the bug fixes the issue but unless this lands on beta you'll need this patch again for Fx115.

The browser otherwise builds and works with the PGO-LTO patch for Firefox 110 and the .mozconfigs from Firefox 105.

Also, I might take the opportunity to make a performance reminder: if you have a lot of threads available (on this dual-8 Talos II, I have 64 because SMT-4), you can modestly increase dom.ipc.processCount and get better throughput. I use 12. Increase this pref with care, because you'll need memory to match (I have 64GB), and other kinds of content processes may not count against that cap: with that setting, ps auxww | grep firefox | grep -c contentproc currently gives me a count of 31. Be sure to uncheck "Use recommended performance settings" in Firefox's preferences before changing this count in about:config. about:processes can give you a better idea of what content processes exist and what they're doing.

SDL2 VMX bugfix


Another hat tip to Jeremy Rand, who got a fix landed for issues with VMX endianness with blitting inside the SDL library. We all care about SDL, since many games rely on it (and quite a few other things), and the issue was a real performance problem with ppc64le as at least some distros dealt with the issue by disabling it on little-endian (big-endian Power is unaffected). The patch is also faster because it moves the vector permute out of the loop, which is also the correct fix for the bug. The issue goes back all the way to the original SDL; the patch has landed on the legacy SDL 1.2.x as well as the next release of SDL 2.x, expected to be 2.28.

Jeremy added, "My patch was reviewed promptly, and it's obvious that SDL actually cares about properly supporting diverse arches, even if they don't personally use them." Amen to that.