GZDoom 4.9.0 for ARM64 Windows (experimental)

[Rachael]

Over the past couple of years I've been trying to get an ARM64 Windows port of GZDoom working, with mixed results. Of course you may be wondering - why would anyone even care? - Well - to put it simply - ARM64 is a long-term solution. I can't say for sure if it will ever topple x86, it certainly comes nowhere close to doing that now - but - ARM processors are way more power efficient, and heat efficient. They power phones, M1 Macs, "Smart" TV's, and numerous other portable devices, especially "smart" lights and anything that connects to your data-spying Alexa speakers - and even said Alexa speakers themselves. (But hey, verbal commands are cool, right? We're one step away from yelling "Tea! Earl Gray!" into a replicator) (okay ... maybe we have a ways to go yet, but you get my point)

Anyway - if you have ever gotten your hands on a Windows ARM laptop - a more recent Surface tablet, Samsung GalaxyBook, or the number of other Qualcomm-powered devices, you've probably noticed that GZDoom runs like absolute shit on those. There's a reason for that - it was never compiled natively for that processor, and Windows uses an emulation layer to translate the binary and dynamically recompile it for the processor to understand. Which is all well and good - but - nothing beats the real deal. So that's what this project is.

This is the ARM64 version of GZDoom - version 4.8.0 - for beta testing. Not all features work yet - notably the "stat" tickers may be problematic. But for the most part, things should work. I should note that it worked fine on UTM on my Mac - but it did have problems initializing the audio on my GalaxyBook. So - YMMV, and that is part of why I am putting this out into the wild. If you have a decent GPU but OpenGL is not working, the GPU may be missing its OpenGL drivers. Kind of bonkers, if you ask me - but there is a solution for that. The following link will open the Microsoft Store for the OpenGL/CL compatibility pack (it's just a translation layer for OpenGL 3.3 to translate it to DirectX 12): https://apps.microsoft.com/store/detail ... n-us&gl=US

The changes needed to make this compile were already implemented into the base GZDoom repository - so if you want to try and compile this yourself, no changes are needed. However, if you are cross-compiling from an x64/AMD64 platform, you will have to set the following CMake variables:

Code: Select all

FORCE_CROSSCOMPILE=TRUE                                                                   // this is part of the project
IMPORT_EXECUTABLES=c:\point\this\to\any\of\your\x86\build\folders\ImportFiles.cmake       // point this to any existing compile of GZDoom you have for x86/x64 processors, for tools like zipdir.exe

And without further ado, here's the actual download: https://github.com/ZDoom/gzdoom/release ... -arm64.zip

Enjoy. I hope somebody somewhere finds this useful.

[Graf Zahl]

Please check your libsndfile.dll. It looks like it was compiled with dynamic dependencies, but none of these are included.
OpenAL also uses the shared C runtime, unlike the rest of the package.

[Rachael]

Thank you I will take a look at these issues.

[Marisa the Magician]

Oh yeah, the stat stuff. PerfToSec and PerfToMillisec will have to be initialized differently in AARCH64 since the timer works at a different rate from the CPU. I think you can just straight up copy the code I used for Linux.

All that you'd have to do is hook this up right after the CPU speed is printed:

Code: Select all

#ifdef __aarch64__
	uint64_t frq;
	asm volatile("mrs %0, cntfrq_el0":"=r"(frq));
	PerfToSec = 1./frq;
	PerfToMillisec = PerfToSec*1000.;
#endif

[Graf Zahl]

That code most likely won't work as-is because of the inline assembly.

[Rachael]

I will test that code and see what happens. If it works I can slate it for 4.8.1.

At any rate, 4.8.0(a) posted - this has a new compile for OpenAL and libsndfile. (I think they're okay now?) However, fluidsynth is still broken, I don't know how to compile it like Randi did, or if it's even possible to compile it the same way for ARM. Annoyingly, fluidsynth is one of those projects that's still stuck with an autoconf system that is broken and likely hasn't been updated in a decade or more - and does not even work with Visual Studio's nmake system. I'm sure the project itself gets updates - but the build system it uses is an absolute nightmare.

Using vcpkg to do these is real tricky.

[Blzut3]

I don't know how to compile it like Randi did,

Sure you do, don't forget I built you guys a docker container for that: https://github.com/Blzut3/FluidsynthBuilder

That said I have no idea what the status for targeting ARM with MinGW is, so can't say it will be easy to adapt.

[Rachael]

I am not 100% sure but I my guess would be, maybe Clang can handle it? If it can the script would only have to be changed.

[randi]

I don't know how to compile it like Randi did,

Sure you do, don't forget I built you guys a docker container for that: https://github.com/Blzut3/FluidsynthBuilder.

But that's not how I did it. I made Visual Studio projects for Fluidsynth and its dependencies by hand. Some of the dependencies I swapped out for lighter-weight alternatives. I remember libintl being the most prominent one, since it was needed for building glib, even though Fluidsynth itself doesn't need it.

Fluidsynth's build system is CMake, so no autotools nonsense there. And without needing to worry about Windows XP support now, it's a lot easier to replace the glib uses in Fluidsynth with direct Win32 calls, since there are basically one-to-one replacements as of Vista, and not have to worry about the dependency hassle at all. That's what I did for my latest build for Rachael, and I'll work to get it on github too.

[Blzut3]

I'm actually surprised you went through that effort vs using cygwin, msys, or something like that. One everything is static linked it shouldn't matter much unless there's some issue with the cross compiled build that I'm not aware of. Either way I guess, but your way would definitely be easier to port to ARM.

[Graf Zahl]

The effort is very much appreciated. Actually, the FluidSynth backend somewhat awkwardly interfaces with ZMusic. All the other backends can hook directly into the sound font management and cache their sound font data. FluidSynth can not. It needs to reload the sound font data each time a new song is started and this can cause small delays and hiccups.

So if that solution is clean enough I'd actually try and integrate FluidSynth statically so that I can implement a sound font cache for it as well.

I'm actually surprised you went through that effort vs using cygwin, msys, or something like that.

It's better to have a one-time effort getting something that works than constantly having to deal with that mess of tools. TBH it annoys me endlessly that most of the lower tier ports still depend on some archaic build system that cannot be run easily on Windows.

[Rachael]

I meant to do this sooner - 4.8.0(b) posted - this version has a new fluidsynth provided by Randi. Still needs a bit of testing.

[MartinHowe]

I have no personal need for an ARM port, but well done to the devs for doing one; it looks like ARM will become more and more popular for non-phone applications in the future, so this is a good step

[Chris]

The effort is very much appreciated. Actually, the FluidSynth backend somewhat awkwardly interfaces with ZMusic. All the other backends can hook directly into the sound font management and cache their sound font data. FluidSynth can not.

Technically it can. I remember playing around with FluidSynth some time ago when trying to make a MIDI interface for OpenAL (a failed experiment that doesn't exist anymore), and I was able to get FluidSynth to use data buffered by OpenAL for the soundfont. However, I also remember it being somewhat annoy to do and not very well designed, so it's understandable that others would want to avoid it. Maybe the 2.x API has improved it, or maybe it's something you're willing to try anyway, but it's not something I've looked at lately.

EDIT:
Excuse the ugly code, it's pretty old and I hadn't yet switched to C++ even though I clearly wanted to:
https://github.com/kcat/openal-soft/blo ... uidsynth.c
Essentially, you can make a custom fluid_sfloader_t, which can provide custom fluid_sfont_ts, that can in turn provide custom fluid_preset_ts, that can then utilize custom fluid_sample_ts that reference pre-loaded sample data.

[Blzut3]

It's better to have a one-time effort getting something that works than constantly having to deal with that mess of tools. TBH it annoys me endlessly that most of the lower tier ports still depend on some archaic build system that cannot be run easily on Windows.

It wasn't really an option when Randi originally built FluidSynth, but build containers do isolate and partially alleviate the mess. So today I don't think either approach really has an advantage in terms of how much work it is to revisit later, if anything Randi's approach may be more work now since now you have a delta over upstream even if the effort is somewhat marginal. (This is of course ignoring the fact that Windows on ARM tool chains aren't readily available today, but this is likely a temporary issue.) Ultimately my surprise stemmed from the fact that I knew Randi used MinGW for certain things, thus probably already had msys installed and that seemed like it would have been the path of least resistance.

Of course, if one read the script I wrote one would notice there are no calls to autotools. Between 2010 and 2020 glib moved to meson as the build system which actually is modern competitor to CMake. Since I don't daily drive Windows I took the cross compile route for that script I made, but theoretically meson should have visual studio project generators and such just like CMake. Since I only used meson and CMake It's probably possible to build with upstream code bases without POSIX emulation layers today. Not to say it wouldn't be nice to have the source of Randi's port to native Win32 APIs.

I can't say for sure if it will ever topple x86, it certainly comes nowhere close to doing that now - but - ARM processors are way more power efficient, and heat efficient.

Using this quote to share a related article I happened across: https://chipsandcheese.com/2021/07/13/a ... nt-matter/ (It was linked from an interesting write up on AVX-512 and RPCS3.)

Of course what is objectively happening is we're moving towards a second era of ISA not really mattering to most people, which is definitely great for enabling more competition in the CPU space. Hopefully once the exclusivity period Qualcomm presumably has (pretty much confirmed from what I recall) with Windows on ARM is over more software will be available natively for ARM.