[GAMES] Ultimate Doom with all enhancements on crispy-doom client

[tle]

There are countless of Doom1 clients on the net but only one that really strike the balance between the classic gameplay and modern QoL is the crispy-doom.

Crispy doom is based on Chocolate Doom with enhancments:

* Large screen resolution with different ratio aspect
* Jump / Free look mouse movement (just like modern FPS)
* Lots and lots of QoL options

The client can be compiled successfully for ppc64le without additional changes.

FYI The Ultimate DOOM Wad could be found on archive.org

[Hasturtium]

these are some other ports I’ve had luck with:

- Woof is an effort to modernize and bring the venerable old MBF (Marine’s Best Friend, by Lee Killough) forward to the present day. It supports a number of compatibility levels, from vanilla Doom through various post-Boom incarnations, and it’s software-only so it will play nice with the AST onboard video. Mouse support isn’t the most responsive but it’s a good port.

- DSDA-Doom is a fork of PRBOOM+ meant for speedrunners, but it’s enjoyably flexible. OPL2 emulation isn’t great but Fluidsynth sounds nice, it supports software and OpenGL rendering at arbitrary resolutions, and screams along at 4K on an RX 6600. This is my go-to right now.

- GZDoom is the gold standard at large, but I’ve run into numerous scenarios where performance is underwhelming. Some big adventurous WADs like the tail end of Eviternity absolutely tank in the hardware renderer; whether OpenGL or Vulkan is used, performance dips down below 20 fps and shows low core usage. Software rendering fares a bit better but the lack of SIMD optimizations hurts. A while back I thought about using ClassicHasClass’s advice to insert intrinsic translation through gcc’s headers, but the port has a complicated CMake config (probably because it pulls in a half-dozen other libraries to enable all its functionality), and I never figured out where to insert a directive to the compiler to try it out.

That’s as far as I’ve gotten with kicking Doom source port tires on Power9 so far. Suggestions are welcome.

[ClassicHasClass]

I like GZDoom for the 3D stereo support (I have a 3D-capable IPS secondary display), but I usually play Chocolate Doom, myself.

[Hasturtium]

I like GZDoom for the 3D stereo support (I have a 3D-capable IPS secondary display), but I usually play Chocolate Doom, myself.

GZDoom performance on ppc64le is still lacking relative to comparable x86land, at least in Fedora 37. In software mode I'd chalk most of that up to a lack of SIMD optimization, and I’ve taken on a new job that's taken away a chunk of the tinker time I'd use to navigate its build system and figure out where to insert -mcpu=power9 -DNO_WARN_X86_INTRINSICS for the compiler. Hardware rendering absolutely chugs in big maps, though, and between what appears to be poor thread load in the Vulkan renderer and recent ZDoom forum drama, it's put me off of troubleshooting much when DSDA-Doom does everything I need right now.

[Hasturtium]

Update: I am not really a programmer but did manage to crack the nut of inserting optimizations into GZDoom's byzantine build system. Follow the directions at this page, finish the initial build, and then navigate to ~/gzdoom_build/gzdoom/build/CMakeCache.txt (or wherever you're keeping the source code). Open that file, navigate to the line (possibly line 68):

Code: [Select]

//Flags used by the CXX compiler during RELEASE builds. The following line is, by default:

Code: [Select]

CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG Change it to:

Code: [Select]

CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG -mcpu=power9 -DNO_WARN_X86_INTRINSICS
Repeat this for the line (possibly line 94):

Code: [Select]

//Flags used by the C compiler during RELEASE builds.changing the subsequent line to:

Code: [Select]

CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG -mcpu=power9 -DNO_WARN_X86_INTRINSICS
Re-run the build instructions, which will overwrite the old executable with the improved one. This doesn't do anything about periodic performance issues for demanding wads using hardware rendering, but software rendering is much nicer!

Edit: In thinking about this since I have a sinking feeling that CMake is performing an early test to determine SIMD compatibility that Power9 isn’t passing, as there are versions of a number of software routines that are in individual files with and without SSE2 optimizations. It is also smart enough to determine ppc64 as a build environment, though this is tied to prior PPC Mac support… more investigation is under way, though -mcpu=power9 is already a big improvement. More info to follow.

[ClassicHasClass]

Nice work.