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

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

Blzut3 wrote: It wasn't really an option when Randi originally built FluidSynth, but build containers do isolate and partially alleviate the mess.
No, not really. Just having to use MinGW constitutes "mess" in my book - IMO Windows code that cannot be compiled with MSVC is broken.
Blzut3 wrote: 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.
Let's hope it's still in a state where a "git pull" from upstream will do. If it doesn't, I'd concur. You can do all the things Randi described without screwing with the code.
User avatar
randi
Site Admin
Posts: 7726
Joined: Wed Jul 09, 2003 10:30 pm

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by randi »

Okay, here's the repository. It's cleaned up some from what I did last month to try and isolate as many of the changes as possible out of the main FluidSynth code. The intent is that you should always be able to pull master from the original repository and rebase the native_win32 branch on top of it and have it work.

Rachael, while reworking this code, I found a mistake I made with one stub in the DLL I gave you earlier, so you should use this instead. I don't think it would have caused problems under any normal circumstances, though. Attached are new arm64 and x64 DLLs compiled from it. These are version 2.2.8 instead of whatever 1.1.x version I did before. The libfluidsynth64.dll is a drop-in replacement for the one shipping with GZDoom now. I'm quite astonished by how much smaller these are without any of the glib code statically linked in.

These DLLs were configured with "-Denable-static-msvcrt=on -Denable-dsound=off -Denable-wasapi=off -Denable-waveout=off -Denable-winmidi=off -Denable-network=off -Denable-aufile=off", so they can't output any audio directly, talk over the network, or receive MIDI events from MIDI devices, but they're perfectly suitable for ZMusic, since it doesn't need any of those features anyway. The static CRT is to keep up the tradition of not using the DLL version of the CRT.

I used vcpkg to get libsndfile support, so these DLLs also support SF3 soundfonts. However, vcpkg's libsndfile is named sndfile.dll, and GZDoom uses libsndfile-1.dll, so I used this genlib batch script to create a new import .lib from libsndfile-1.dll and overwrote the sndfile.lib installed by vcpkg so that the FluidSynth DLL would import from libsndfile-1.dll instead of sndfile.dll. (Yes, it's messy, but it worked well enough for my needs at the moment.)

Gentables is not working with cross-compilation. I don't know why and didn't feel like trying too hard to figure it out, so to do the arm64 compile, I temporarily commented out the end of src/CMakeLists.txt to not bother with it and copied the generated files over from the x64 build instead.
You do not have the required permissions to view the files attached to this post.
User avatar
Rachael
Admin
Posts: 12883
Joined: Tue Jan 13, 2004 1:31 pm
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Rachael »

Thank you - I will take a look tomorrow when I get a chance. I'll recompile a new GZDoom 4.8.2 and drop this .dll in to see how it works.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47973
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

randi wrote: I used vcpkg to get libsndfile support, so these DLLs also support SF3 soundfonts. However, vcpkg's libsndfile is named sndfile.dll, and GZDoom uses libsndfile-1.dll, so I used this genlib batch script to create a new import .lib from libsndfile-1.dll and overwrote the sndfile.lib installed by vcpkg so that the FluidSynth DLL would import from libsndfile-1.dll instead of sndfile.dll. (Yes, it's messy, but it worked well enough for my needs at the moment.)
I think it's better then to rename the DLL to use the canonical name of the parent project. I don't know when it happened but some time back they must have changed it to be more "Windows conformant".

Also, shouldn't this repo be on the ZDoom organization account?
User avatar
randi
Site Admin
Posts: 7726
Joined: Wed Jul 09, 2003 10:30 pm

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by randi »

Graf Zahl wrote:I think it's better then to rename the DLL to use the canonical name of the parent project. I don't know when it happened but some time back they must have changed it to be more "Windows conformant".
I don't know if that's an official libsndfile name for the DLL or a vcpkg name for it. I used vcpkg to find it because it required minimal modifications to the CMakeLists.txt to do so and because I already had vcpkg installed, but I don't know enough about the vcpkg ecosystem to know if it might have changed the DLL name itself.

FWIW, this also produced a libfluidsynth-3.dll before I renamed it.

I've also pushed an update that fixes a potential race condition when creating detached threads. These are only used by the fluidsynth command line program and not the library, so no new DLLs.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47973
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

The name of the last binary package was sndfile.dll as well, if I remember correctly. I had to rename the DLL before dropping it into my play folder.
User avatar
Rachael
Admin
Posts: 12883
Joined: Tue Jan 13, 2004 1:31 pm
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Rachael »

I am not really sure what the error means, but for what it's worth the sound does actually work - but only for Timidity++

This was tested with Windows 11 on UTM on my M1 Mac.

Code: Select all

Could not load fluidsynth.dll or libfluidsynth.dll

Unable to create FluidSynth MIDI device. Falling back to Timidity++
Spoiler: full log
Full compile
User avatar
randi
Site Admin
Posts: 7726
Joined: Wed Jul 09, 2003 10:30 pm

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by randi »

Rachael wrote:Could not load fluidsynth.dll or libfluidsynth.dll
That usually means there was a dependency problem, but it only needs libsndfile-1.dll and kernel32.dll, and you provide the former. Opening it in Dependencies doesn't show anything missing either, unless there's something missing in arm64's kernel32.dll compared to x64, but that seems unlikely.

I didn't do anything different to build this one compared to the first one I gave you, so I don't know what could be causing the problem. Maybe try snooping on it with Process Monitor? It's hard to say without real hardware in front of me.
Graf Zahl wrote:The name of the last binary package was sndfile.dll as well, if I remember correctly.
In that case, here's rebuilds linking against sndfile.dll instead of libsndfile-1.dll if you want to start using sndfile.dll instead. Rachael, this should also be drop-in compatible if you make a copy of libsndfile-1.dll and rename it sndfile.dll. It's worth a shot, at least.
You do not have the required permissions to view the files attached to this post.
User avatar
Rachael
Admin
Posts: 12883
Joined: Tue Jan 13, 2004 1:31 pm
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Rachael »

I used Dependency Walker (surprisingly it works with ARM64 compiles, but only if run on an ARM64 computer)

Here is a screenshot of the output

I had copies of all of the missing libraries, and dropped them in, and it works, but now the zip file is a mess.

Here is the compile as it is now

I still haven't tested it on real hardware yet (the GalaxyBook) but it works on the UTM Virtual Machine now, at least. I'm gonna build Raze and test it as well.

Built Raze and it works well.

Here is that
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47973
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

What libsndfile did you use? From the looks of it isn't a self-contained version but one that dynamically links everything it needs.
User avatar
Rachael
Admin
Posts: 12883
Joined: Tue Jan 13, 2004 1:31 pm
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Rachael »

It's one compiled from vcpkg. I cannot seem to compile a version that has all the needed dependencies pre-compiled in.
User avatar
randi
Site Admin
Posts: 7726
Joined: Wed Jul 09, 2003 10:30 pm

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by randi »

Using this custom triplet, which I named arm64-windows-mixed.cmake

Code: Select all

set(VCPKG_TARGET_ARCHITECTURE arm64)

set(VCPKG_CRT_LINKAGE static)

if (${PORT} MATCHES "libflac|libvorbis|opus|mp3lame|mpg123|libogg")
	set(VCPKG_LIBRARY_LINKAGE static)
else()
	set(VCPKG_LIBRARY_LINKAGE dynamic)
endif()
And running the command

Code: Select all

vcpkg install libsndfile:arm64-windows-mixed
gave me this DLL, which should be exactly what you're looking for.

It builds everything with static CRT linkage, libsndfile's dependences are built as static libraries, and everything else is built as a dynamic library.
You do not have the required permissions to view the files attached to this post.
User avatar
Rachael
Admin
Posts: 12883
Joined: Tue Jan 13, 2004 1:31 pm
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Rachael »

Thank you, once more! That greatly simplifies the distribution.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47973
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

Cool. Would this also be a solution for compiling libvpx in a form we can use? I'd really like to get rid of that library version from EDuke32.

One thing in general here: How should we handle adding binary lib files to the project? I'd rather not see them added to the main repo because it can inflate that quite quickly. One other thing I'd like to add is webp support, but that's also quite a large library file which had to be added twice then, too.
_mental_
 
 
Posts: 3771
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by _mental_ »

I would put all binary dependencies to an archive, and use a directory (added to .gitignore) to discover headers/libraries extracted from the given archive automatically. It's possible to automate downloading and extraction from such archive via CMake.

Return to “Game Engines”