GZDoom 4.8.0 for ARM64 Windows (experimental)

Game Engines like EDGE, LZDoom, QZDoom, ECWolf, and others, go in this forum
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine are perfectly acceptable here too.

Please read the full rules for more details.

GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Rachael » Wed Jun 08, 2022 10:43 pm

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 allExpand view
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://forum.drdteam.org/viewforum.php?f=283

Enjoy. I hope somebody somewhere finds this useful.
User avatar
Rachael
^ walking stack of unfinished projects ^
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Graf Zahl » Thu Jun 09, 2022 12:58 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Rachael » Thu Jun 09, 2022 1:05 am

Thank you I will take a look at these issues.
User avatar
Rachael
^ walking stack of unfinished projects ^
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Marisa the Magician » Thu Jun 09, 2022 2:33 am

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 allExpand view
#ifdef __aarch64__
   uint64_t frq;
   asm volatile("mrs %0, cntfrq_el0":"=r"(frq));
   PerfToSec = 1./frq;
   PerfToMillisec = PerfToSec*1000.;
#endif
User avatar
Marisa the Magician
ZScript Crimester
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: Marisa the Magician#1666
Twitch ID: MarisaDOOM
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Graf Zahl » Thu Jun 09, 2022 2:41 am

That code most likely won't work as-is because of the inline assembly.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Rachael » Thu Jun 09, 2022 12:15 pm

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.
User avatar
Rachael
^ walking stack of unfinished projects ^
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Blzut3 » Fri Jun 10, 2022 2:54 am

Rachael wrote: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.
Blzut3
Pronounced: B-l-zut
 
 
 
Joined: 24 Nov 2004
Github ID: Blzut3
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Rachael » Fri Jun 10, 2022 8:46 am

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.
User avatar
Rachael
^ walking stack of unfinished projects ^
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby randi » Thu Jun 16, 2022 11:33 pm

Blzut3 wrote:
Rachael wrote: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. 8-) 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.
User avatar
randi
Site Admin
 
Joined: 09 Jul 2003

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Blzut3 » Thu Jun 16, 2022 11:48 pm

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.
Blzut3
Pronounced: B-l-zut
 
 
 
Joined: 24 Nov 2004
Github ID: Blzut3
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Graf Zahl » Fri Jun 17, 2022 12:45 am

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.

Blzut3 wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Rachael » Fri Jun 17, 2022 4:54 am

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.
User avatar
Rachael
^ walking stack of unfinished projects ^
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby MartinHowe » Fri Jun 17, 2022 6:58 am

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 :thumb:
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Chris » Fri Jun 17, 2022 9:55 am

Graf Zahl wrote: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.
User avatar
Chris
 
Joined: 17 Jul 2003
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Postby Blzut3 » Fri Jun 17, 2022 3:05 pm

Graf Zahl wrote: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.

Rachael wrote: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.
Blzut3
Pronounced: B-l-zut
 
 
 
Joined: 24 Nov 2004
Github ID: Blzut3
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Next

Return to Game Engines

Who is online

Users browsing this forum: No registered users and 1 guest