GZDoom 4.9.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.
_mental_
 
 
Posts: 3819
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by _mental_ »

Regarding macOS, I continue to support this repo. It has everything to build a bundle with no external dependencies for both architectures. Prerequisites are the recent version of macOS (10.15+), and Xcode that handles x64/arm64 (12+).
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

How about moving that to the ZDoom organization as well, so that it is easier found by those who want to self-compile?
_mental_
 
 
Posts: 3819
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by _mental_ »

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

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

Could you add a bit more info to the usage section? It's a bit unclear what the parameters for --target and --source should contain.
It may also make sense to rewrite https://zdoom.org/wiki/Compile_ZDoom_on_Mac_OS_X to use this project. That page is totally outdated and IMO perfectly useless. It also seems to be a lot easier using your setup, so documenting it may be a good idea.
_mental_
 
 
Posts: 3819
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by _mental_ »

The mandatory switch is either --target or --source.
Run build.py without arguments. It will output the list of possible values to use with --target.
For --source, the value is a path to source code.

Pretty much the same is written at Usage section. I have no idea how to explain it better.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

'path to source' means path to main CMakeLists.txt?
_mental_
 
 
Posts: 3819
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by _mental_ »

No, it's a path to directory with source code, i.e. the root of Git repository with source code.
This argument is named --source because --source-path has a different meaning. It's a directory where source codes of all targets are stored.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

Ok, I'll try that the next time I am on my work Mac.

I'm still stuck building FluidSynth as a static library. What do I have to change there to build that instead of a DLL?
User avatar
mjr4077au
Posts: 830
Joined: Sun Jun 16, 2019 9:17 pm
Graphics Processor: nVidia with Vulkan support
Location: Gosford NSW, Australia

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by mjr4077au »

Graf Zahl wrote::thumb:

But you know that this will never *ever* work because as soon as we do such a thing they all come running, asking "How can we build with dynamic linking?" and we'd be back to square one.
We'd have to tell them in clearest terms that there is no support at all for self-built binaries.
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.
User avatar
randi
Site Admin
Posts: 7749
Joined: Wed Jul 09, 2003 10:30 pm

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by randi »

Graf Zahl wrote:I'm still stuck building FluidSynth as a static library. What do I have to change there to build that instead of a DLL?
Configure it with BUILD_SHARED_LIBS turned off.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
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:
Graf Zahl wrote::thumb:

But you know that this will never *ever* work because as soon as we do such a thing they all come running, asking "How can we build with dynamic linking?" and we'd be back to square one.
We'd have to tell them in clearest terms that there is no support at all for self-built binaries.
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.

If we link those libraries statically, there's nothing to unbundle as it's all in one file.
These Linux people are a lost cause, they really screw everything up they put their dirty fingers in. :(
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

FluidSynth compiles now, but there's one problem left. Whatever I set for SNDFILE_DIR, when I hit "generate" the entry gets cleared again and sndfile support is disabled. The CMake script is doing a lot of verification voodoo to see if the library is usable and this fails somehow.
_mental_
 
 
Posts: 3819
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by _mental_ »

Set SNDFILE_INCLUDE_DIR and SNDFILE_LIBRARY variables to directory with headers and .lib file correspondingly.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by Graf Zahl »

I only have SNDFILE_DIR, these two are not listed.
_mental_
 
 
Posts: 3819
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 4.8.0 for ARM64 Windows (experimental)

Post by _mental_ »

It appeared that FluidSynth uses pkg-config to find sndfile. I never tried to workaround it on Windows, and I don't have Windows PC at hand to play with it.

Return to “Game Engines”