GZDoom 4.9.0 for ARM64 Windows (experimental)
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.
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.
-
- 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)
You mean the same way as you did for PrBoom+? I think that would be a lot better than what we have now - and we could even get rid of some of the source distributions. I'd really like to move to libjpeg-turbo entirely and forget about the stripped down source of that old JPEG library we have right now. Then it would also be a lot easier to add new depenencies.
-
-
- Posts: 3819
- Joined: Sun Aug 07, 2011 4:32 am
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
Yes, it can be similar to PrBoom+ dependencies. Alternative solution is to use a dedicated Git repository for this purpose to simplify tracking of changes, and to keep build scripts, instructions, etc.
-
- Posts: 13793
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
I think that is most ideal - the script can be set to do a shallow checkout of said repo (if it checks anything out at all, rather than just doing a simple download for the files it needs).
I think it is worth consideration that GZDoom and Raze could be set to download specific versions from there - not whatever happens to be "master" at the time - similar to how submodules worked - that way if any breaking changes are ever introduced, the correct file versions would be used. "Updates" can be introduced project-side simply by bumping the version hash string.
I think it is worth consideration that GZDoom and Raze could be set to download specific versions from there - not whatever happens to be "master" at the time - similar to how submodules worked - that way if any breaking changes are ever introduced, the correct file versions would be used. "Updates" can be introduced project-side simply by bumping the version hash string.
-
-
- Posts: 3819
- Joined: Sun Aug 07, 2011 4:32 am
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
I don't think that specific version is needed here. Such submodules-like thing has the same flaws as the corresponding Git feature.
Compilation can be verified via continuous integration, while work-in-progress changes can be committed to own branches, and they will be built by CI as well.
Compilation can be verified via continuous integration, while work-in-progress changes can be committed to own branches, and they will be built by CI as well.
-
- 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)
In addition, since these libraries are external, there is generally no pressing need for constant updates because most of the time they provide no benefits. One should assume that official releases of such libraries are in a working state, especially if they are not brand new.
I wouldn't consider updating such a library for example, if it had just been updated days before a new GZDoom release.
We only need serious consideration if some library does a breaking API change, but such things would generally disqualify a library for me because it's no longer future proof.
I wouldn't consider updating such a library for example, if it had just been updated days before a new GZDoom release.
We only need serious consideration if some library does a breaking API change, but such things would generally disqualify a library for me because it's no longer future proof.
-
- Posts: 13793
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
Well - I had always thought the key issue with submodules when we used it was not the branch versioning but the fact that they required so many extra steps to use.
-
- 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)
That is true - but the versioning is also rather fragile.
-
- Site Admin
- Posts: 7749
- Joined: Wed Jul 09, 2003 10:30 pm
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
Looks like it:Graf Zahl wrote: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.
Code: Select all
Directory: D:\src\vcpkg\installed\x64-windows-mixed\lib
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 7/27/2022 8:54 PM pkgconfig
-a--- 7/27/2022 8:45 PM 2445252 FLAC.lib
-a--- 7/27/2022 8:45 PM 898182 FLAC++.lib
-a--- 7/27/2022 8:42 PM 1574812 libmp3lame-static.lib
-a--- 7/27/2022 8:42 PM 279918 libmpghip-static.lib
-a--- 7/27/2022 8:42 PM 1841400 mpg123.lib
-a--- 7/27/2022 8:45 PM 114990 ogg.lib
-a--- 7/27/2022 8:42 PM 3869682 opus.lib
-a--- 7/27/2022 8:42 PM 415852 out123.lib
-a--- 7/27/2022 8:54 PM 9412 sndfile.lib
-a--- 7/27/2022 8:42 PM 645166 syn123.lib
-a--- 7/27/2022 8:45 PM 1821784 vorbis.lib
-a--- 7/27/2022 8:45 PM 890862 vorbisenc.lib
-a--- 7/27/2022 8:45 PM 164190 vorbisfile.lib
-a--- 7/29/2022 8:32 PM 11846880 vpx.lib
-a--- 7/29/2022 8:32 PM 520192 vpx.pdb
Directory: D:\src\vcpkg\installed\x64-windows-mixed\bin
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 7/27/2022 8:54 PM 2536448 sndfile.dll
-a--- 7/27/2022 8:54 PM 9711616 sndfile.pdb
Code: Select all
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE static)
if (${PORT} MATCHES "libsndfile")
set(VCPKG_LIBRARY_LINKAGE dynamic)
else()
set(VCPKG_LIBRARY_LINKAGE static)
endif()
-
- 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)
Or maybe we do everything static and have one EXE for all again.
-
-
- Posts: 3819
- Joined: Sun Aug 07, 2011 4:32 am
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
I wanted to propose this too.Graf Zahl wrote:Or maybe we do everything static and have one EXE for all again.
-
- 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)
The biggest problem here is, of course, what to do with ZMusic on Linux.
It has become very apparent that setting this up via CMake seems to be too much for many self-compilers.
We should also try to offload the entire library setup to a separate file, so that we do not have to maintain this separately for GZDoom and Raze, as both have the same dependencies, aside from ZMusic full vs. lite.
It has become very apparent that setting this up via CMake seems to be too much for many self-compilers.
We should also try to offload the entire library setup to a separate file, so that we do not have to maintain this separately for GZDoom and Raze, as both have the same dependencies, aside from ZMusic full vs. lite.
-
-
- Posts: 3819
- Joined: Sun Aug 07, 2011 4:32 am
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
I thought we are discussing Windows version only. macOS build is already 'everything static' except MoltenVK. Linux version will remain unchanged.
-
- Posts: 13793
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
Honestly I would prefer the Linux version to have everything built static too - then there wouldn't be a need for fancy appimages or flatpaks.
-
- 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)
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.
And what about macOS? Build setup there is screwed up enough that I never managed to produce a distributable binary myself.
And even so, there's still indirect dependencies we have no control over.
So, how do we progress from here?
-
- 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)
Here's what I built with vcpkg, this also covers two new libraries we're going to need: libwebp and libtheora. Webp looks like it is becoming a viable alternative to jpg, so if we go the external route it's an obvious thing to add.
Of the remaining stuff in the "libraries" folder,
asmjit is customized and cannot be rebuilt from upstream
discordrpc is better left alone.
gdtoa is not available, also not a size issue.
glslang can only be offloaded if we do it for all platforms, because this is something where we cannot afford any different versions to be used at all. I think we better, leave this in the source tree to have full control.
fluidsynth will have to be built from Randi's modified project - I haven't set that up yet.
Code: Select all
30.07.2022 10:06 284.770 bz2.lib
30.07.2022 10:05 850.916 FLAC++.lib
30.07.2022 10:05 2.349.690 FLAC.lib
30.07.2022 10:05 1.388.798 libmp3lame-static.lib
30.07.2022 10:05 263.936 libmpghip-static.lib
30.07.2022 10:05 1.682.132 mpg123.lib
30.07.2022 10:00 103.310 ogg.lib
30.07.2022 10:05 3.207.890 opus.lib
30.07.2022 10:05 400.596 out123.lib
30.07.2022 10:06 5.128.242 sndfile.lib
30.07.2022 10:05 580.706 syn123.lib
30.07.2022 10:00 1.134.728 theora.lib
30.07.2022 10:00 437.316 theoradec.lib
30.07.2022 10:00 938.110 theoraenc.lib
30.07.2022 10:16 3.749.290 turbojpeg.lib
30.07.2022 10:05 1.671.366 vorbis.lib
30.07.2022 10:05 877.932 vorbisenc.lib
30.07.2022 10:05 150.862 vorbisfile.lib
30.07.2022 10:04 10.162.878 vpx.lib
30.07.2022 10:04 520.192 vpx.pdb
30.07.2022 10:02 3.417.990 webp.lib
30.07.2022 10:02 1.519.190 webpdecoder.lib
30.07.2022 10:02 121.438 webpdemux.lib
30.07.2022 10:02 333.996 webpmux.lib
30.07.2022 10:02 429.326 zlib.lib
asmjit is customized and cannot be rebuilt from upstream
discordrpc is better left alone.
gdtoa is not available, also not a size issue.
glslang can only be offloaded if we do it for all platforms, because this is something where we cannot afford any different versions to be used at all. I think we better, leave this in the source tree to have full control.
fluidsynth will have to be built from Randi's modified project - I haven't set that up yet.