Page 2 of 6

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Fri Jun 17, 2022 3:22 pm
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.

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Sun Jul 24, 2022 9:37 pm
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.

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Sun Jul 24, 2022 11:42 pm
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.

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Mon Jul 25, 2022 12:30 am
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?

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Mon Jul 25, 2022 5:39 pm
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.

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Mon Jul 25, 2022 11:42 pm
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.

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Tue Jul 26, 2022 4:25 pm
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

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Tue Jul 26, 2022 8:41 pm
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.

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Tue Jul 26, 2022 9:03 pm
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

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Tue Jul 26, 2022 11:42 pm
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.

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Wed Jul 27, 2022 12:03 am
by Rachael
It's one compiled from vcpkg. I cannot seem to compile a version that has all the needed dependencies pre-compiled in.

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Wed Jul 27, 2022 8:03 pm
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.

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Thu Jul 28, 2022 5:14 pm
by Rachael
Thank you, once more! That greatly simplifies the distribution.

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Fri Jul 29, 2022 12:23 am
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.

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Posted: Fri Jul 29, 2022 12:40 am
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.