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: 48040
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

Randi should know, I think. I have no idea either how to set this up.
User avatar
Rachael
Admin
Posts: 12956
Joined: Tue Jan 13, 2004 1:31 pm
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Preferred Pronouns: She/Her

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Rachael »

mjr4077au wrote:While the Raze package I maintain in Arch Linux's AUR maintains the repository-included libraries, some distros are going to the effort to unbundle these so system libraries are used.

Could we have it so distro-provided builds of GZDoom and Raze are supported, just so long as they're built to our specification, with our tested and mandated libraries? I don't know of any distros that will repackage someone else's binaries, especially when there is source availalble.
Distros can do what they want - the source is there. But when people using these distros start having problems - particularly with the libraries - then we may have to recommend they use our binaries instead.

I don't see any reason to block distros from doing things the way they want to do them. I was just expressing my opinion that I think it would be hugely beneficial that if we're going to have mega-static executables for Windows, we should do it for all platforms, it greatly simplifies distribution.

For Mac having MoltenVK separate is not a huge deal since it's ultimately part of the App bundle anyway and no one really grabs files out of that unless they need to open the .pk3's in Slade or any other map editor. I think it might still be advantages to having it linked statically though.

While we're on that note, I think it's a bit of a misleading to label it "Vulkan" on Mac since all it does is tie to the Metal backend anyhow. Yes - the coding and functions are the same since we use a wrapper, but ultimately the API commands being emitted by the application will end up being Metal.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48040
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

For Mac it doesn't really matter if the app bundle contains a single executable or several dylibs. The bundle is a static inseparable package that's being signed as a unit.

For Linux we have to make clear, though, that alternative compiles other people create and deviate from our own setup come without any tech support. Not that I'd ever expect things to change here.
User avatar
randi
Site Admin
Posts: 7728
Joined: Wed Jul 09, 2003 10:30 pm

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by randi »

_mental_ wrote:It appeared that FluidSynth uses pkg-config to find sndfile.
Yes, but I hacked in support for it to find that library with vcpkg if you're compiling for Windows.
Graf Zahl wrote:The CMake script is doing a lot of verification voodoo to see if the library is usable and this fails somehow.
a) Is the CMake toolchain file set for vcpkg? If you opened it as a Folder Project in VS 2022, VS will do that for you. Otherwise, you need to specify it on the command-line -DCMAKE_TOOLCHAIN_FILE=[path to vcpkg]/scripts/buildsystems/vcpkg.cmake (I think you only need that the first time you generate.)
b) VCPKG_TARGET_TRIPLET needs to be set to your desired triplet so it doesn't default to <arch>-windows. Since you want everything to be static, you can use the triplet x64-windows-static and not need to mess around with a custom triplet at all.

I also had to delete the cache and reconfigure to keep it from trying to use the DLL version of libsndfile I last linked against, but it worked for me:

Code: Select all

    Directory: D:\src\fluidsynth\out\build\x64-Release\src

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           7/30/2022  5:21 PM        1652958 libfluidsynth.lib
Well, maybe "worked" is a little too strong a word, because it also compiled libsndfile into it instead of leaving it external.

Edit: Nevermind. I forgot it would be larger than the corresponding DLL because the static library has all that extra metadata that the DLL doesn't. It looks like it doesn't actually have libsndfile compiled in.
User avatar
mjr4077au
Posts: 720
Joined: Sun Jun 16, 2019 9:17 pm
Discord: mjr4077au#1027
Github ID: mjr4077au
Graphics Processor: nVidia with Vulkan support
Location: Gosford NSW, Australia

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by mjr4077au »

Rachael wrote:Distros can do what they want - the source is there. But when people using these distros start having problems - particularly with the libraries - then we may have to recommend they use our binaries instead.

I don't see any reason to block distros from doing things the way they want to do them. I was just expressing my opinion that I think it would be hugely beneficial that if we're going to have mega-static executables for Windows, we should do it for all platforms, it greatly simplifies distribution.
All I meant here is that a binary built by a distro that's built the way we would build the binary should be equally supported. If they want to go off track like openSUSE has, then they're free to do so without support if they have esoteric bugs etc
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48040
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:
_mental_ wrote:It appeared that FluidSynth uses pkg-config to find sndfile.
Yes, but I hacked in support for it to find that library with vcpkg if you're compiling for Windows.
Graf Zahl wrote:The CMake script is doing a lot of verification voodoo to see if the library is usable and this fails somehow.
a) Is the CMake toolchain file set for vcpkg? If you opened it as a Folder Project in VS 2022, VS will do that for you. Otherwise, you need to specify it on the command-line -DCMAKE_TOOLCHAIN_FILE=[path to vcpkg]/scripts/buildsystems/vcpkg.cmake (I think you only need that the first time you generate.)
b) VCPKG_TARGET_TRIPLET needs to be set to your desired triplet so it doesn't default to <arch>-windows. Since you want everything to be static, you can use the triplet x64-windows-static and not need to mess around with a custom triplet at all.
Wow, that's really complicated. I guess it would all be a lot easier if it didn't have that stupid glib dependency by default. Have you tried to PR your changes to upstream? If it was there by default, I guess things would be easier as we could use vcpkg's compiled .lib file directly.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48040
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

mjr4077au wrote:All I meant here is that a binary built by a distro that's built the way we would build the binary should be equally supported. If they want to go off track like openSUSE has, then they're free to do so without support if they have esoteric bugs etc
It's not really that easy. Even if it is all built the same way, some of these libraries are so highly configurable that nothing can be taken for granted and making an error when setting it all up is very easy. We'd have to provide the files ourselves as a binary package.
But knowing how those Linux types tick they will just ignore it and build against their globally,installed variants instead.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48040
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

I had to do this

Code: Select all

#if LIBSNDFILE_SUPPORT
#include <sndfile.h>
#elif __has_include("sndfile.h")
#undef LIBSNDFILE_SUPPORT
#define LIBSNDFILE_SUPPORT 1
#include "sndfile.h"
#pragma message("sndfile support active.")
#endif
to persuade FluidSynth to compile with sndfile support. But it still doesn't work right as it insists on linking against the shared CRT instead of the static one - the option in the project simply seems to be ignored.
At this point I think the only option to get this into a state where we can handle this mess is to directly include the needed parts into ZMusic - that'd also help with the compatibility issues in the past with API/ABI breaks between versions. We do not need the latest and greatest here, but something that *just* works.

I also had a quick look at libinstpatch, but that seems to be a lost cause, it seems to utterly depend on glib - although DLS support on Windows would have been nice.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48040
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

Mostly done. On Windows it compiles and works now with FluidSynth being inside the ZMusic source tree.
Linux/macOS still needs work - it depends on whether we want to reference glib how much.

In case glib is fine, the library detection needs to be updated, but if we don't and instead use a wrapper similar to Windows, the glibstubs file needs to be redone here.
User avatar
randi
Site Admin
Posts: 7728
Joined: Wed Jul 09, 2003 10:30 pm

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by randi »

Graf Zahl wrote:Wow, that's really complicated.
? (A) is needed to use vcpkg with any CMake project, and (B) is just another configure option.
Graf Zahl wrote:I guess it would all be a lot easier if it didn't have that stupid glib dependency by default. Have you tried to PR your changes to upstream?
Removing the glib dependency for Windows has been proposed several times over the years, and it always gets shot down. They're not interested unless it's something that can replace glib on all the platforms they currently support. And now they're using glib for LADSPA as well as threading, so that complicates matters further. I consider a PR a lost cause. The most recent attempt by someone was just last year.
Graf Zahl wrote:I had to do this
Just to be sure, did you delete all your generated CMake files to be sure nothing was held over from your previous attempts? I have no trouble getting it to find whatever vcpkg-built triplet version I want as long as I start fresh when changing the triplet.
Graf Zahl wrote: But it still doesn't work right as it insists on linking against the shared CRT instead of the static one
It definitely works when building the DLL, so I don't know why the static library would be different. :(
Graf Zahl wrote:Linux/macOS still needs work - it depends on whether we want to reference glib how much.
glib is basically a system library on Linux.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48040
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

The problem with that vcpkg toolchain file is that it can only be done via command line, so it configures everything outside the GUI and I end up with even more work - so I avoid doing stuff like that.

I had an hour-long fight against the project - even including it in ZMusic required a lot of editing of the messy project. But since we cannot use the original repo available in vcpkg due to the glib mess I'd rather do it in a way that eliminates the mess once and for all. FluidSynth has already broken both ABI and API in the past and the general attitude seems to make it likely to happen again, so we're better off with our own copy inside ZMusic - with this we can even make the needed changes to support embedded sound fonts in the future. Win-win.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48040
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

Hm, I need some help with glib. When trying find_package( glib ) on my MacBook CMake throws an error, claiming not to know it. So how do I set that up?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48040
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

Got it sorted out. Parts of the FluidSynth CMake project did not mix with how ZMusic had set up things, and stuff had different names for some reason.

One big oroblem less, I'd say, now that we have this code under our own control. Gotta make some token changes to keep the Linux maintainers from reverting to the system-installed versions, though.
User avatar
Phredreeke
Posts: 243
Joined: Tue Apr 10, 2018 8:14 am
Discord: phredreeke#6500

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Phredreeke »

Rachael wrote:While we're on that note, I think it's a bit of a misleading to label it "Vulkan" on Mac since all it does is tie to the Metal backend anyhow. Yes - the coding and functions are the same since we use a wrapper, but ultimately the API commands being emitted by the application will end up being Metal.
Are you suggesting renaming the Vulkan backend on Mac builds? (though with the other backends going away in 5.0 maybe there's no point in making the distinction anyway)

Anyway, since this topic is about GZDoom on ARM64 Windows, I'm gonna ask about something that has been on my mind for a while now, how is the GPU support on this platform?
User avatar
Rachael
Admin
Posts: 12956
Joined: Tue Jan 13, 2004 1:31 pm
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Preferred Pronouns: She/Her

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Rachael »

Yeah we should probably either just call it Metal, or just call it by the wrapper name MoltenVK. Since Vulkan does not actually exist on the MacOS platform.

Just my thoughts, though, I might be the crazy one. lol

Return to “Game Engines”