gzdoom: update to version 4.10.0.

[SpidFightFR]

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture, (x64-GlibC)

Additional notes for the PR:

• Remade the i686 patch as it was broken after updating.
• Removed the sdl patch as it's already applied in the gzdoom repo ( see sdlglvideo.cpp )
• Removed the vsed lines post-patch as gitinfo.cpp has been removed since release 4.9.0, also removed the leftover variable "tagdate".
• Added libvpx-devel as a make dependency as it doesn't build otherwise.

[SpidFightFR]

So the i686 patch doesn't seem to work. If anyone has a suggestion, feel free to bring one !

[classabbyamp]

--- a/srcpkgs/gzdoom/template
+++ b/srcpkgs/gzdoom/template
@@ -21,6 +21,7 @@ nocross=yes
 CXXFLAGS=-std=gnu++11
 
 if [ "$XBPS_TARGET_LIBC" = musl ]; then
+       CFLAGS="-D_7ZIP_AFFINITY_DISABLE"
        makedepends+=" musl-fts-devel libexecinfo-devel"
 fi

should fix musl

[classabbyamp]

-case "$XBPS_TARGET_MACHINE" in
-	i686*) configure_args+=" -DSSE_MATTERS=true" ;;
-esac
-

this should fix the current error on i686, but it seems that they no longer want to support i686:

../src/common/engine/i_interface.cpp:8:29: error: static assertion failed: 32 builds are not supported

[Jjp137]

but it seems that they no longer want to support i686

Yeah, as someone casually following the Doom community, that has been the plan for some time. I usually just watch this repo occasionally from afar since I started trying out Void Linux on my laptop, but as a GZDoom user (albeit in another distro), I saw this PR and I wanted to give some more context.

In particular, see this commit and the comments below it: ZDoom/gzdoom@8c244f6

A few years ago, there was a thread about 32-bit support here in which many users think that 32-bit is dead: https://forum.zdoom.org/viewtopic.php?p=1134388

Thus, if one uses a 32-bit build of GZDoom and problems happen, they should not expect support from upstream. The hardware requirements for GZDoom have always been steadily increasing throughout the years (one notable example is dropping OpenGL 2.1 support many years ago), and this is just another example of it.