EDuke32 (win64) crashes [SSSE3 is still a requirement]
Hello.
Context:
I was updating some of ports files (mostly all of them were from 2020), and when I got to NBlood, PCExhumed, etc... I saw that any of them worked anymore. At first I thought that the game files (that I was extracting from my GOG versions) were incorrect, but then I look up and with the old port files they worked normally.
Thinking a little bit, I remembered that all of those ports are based in eDuke32, so then I tested to update my EDuke32 too to the last version... and It doesn't worked either. So, to see what happens, I tried the debug version, and that version works just fine, so, I can't use it to debug it!. Also there is no message or error anywhere, It simply crashes.
What happens:
Files:
- I'm using the GOG's Duke3D Atomic Edition, which EDuke32 detects itself automatically from its GOG installation folder (D:\Juegos\GOG\Duke Nukem 3D).
- I'm downloading the port files from synthesis and extracting them with their filenames as name folders in my Desktop (It's located in _E:\Lukas ThyWalls\Escritorio_).
This doesn't work:
- Just start eduke32.exe of the last version (EDuke32 r10593-19c21b9ab, Built Jul 25 2024 17:37:48, GCC 13.0.0, 64-bit), it opens the start screen, detecting the game, keeping everything at default as it is.
- Click Start... and it crashes with no error (eduke32.log).
This works:
- If instead, I use the latest EDuke32 debug version (EDuke32 r10593-19c21b9ab, Built Jul 25 2024 17:35:43, GCC 13-posix, 64-bit), It just works fine and I can play normally (eduke32.debug.log).
- Info Added: Tested the latest 32-bit version: The normal version also works fine: eduke32.32bit.log
Details:
- I don't think the folder locations matters because my port folder normally is D:\Juegos\Ports\Build\eDuke32 and the normal version doesn't work there either (debug one does). But I don't assume anything.
- Other latest EDuke32 ports that I tested with the same result (crash) are: VoidSW (VoidSW.debug works), NBlood, PCExhumed, Rednukem (I didn't try any debug version of these three because I don't know If they do any, and also they are out of this topic here).
Information:
Bisecting:
- The last version what the normal 64-bit build works is 20221026-10165-a9c797dcb.
- The first 64-bit one that crashes is 20221225-10166-122aee012.
Specifications:
- Windows 10 Pro (22H2) x64
- CPU: AMD Athlon II X3 450 3x3.2 Ghz.
- Memory: 12 GB RAM.
- Graphics: GeForce GTX 750.
- Full specifications (from CPU-Z): Specifications.txt.
Additional info:
I'm not sure, and maybe the issue is something completely different so don't assume it, please, but a very very similar issue happened to me in this computer with other project: DOSBox-Staging.
In that case, updating the files like here, I found since a few versions the main ones crash at launch without any error, but, with the daily builds there instead the debug versions here, the "other" version worked just fine.
In the end, It was that my CPU lacks SSSE3 instruction set, and because one library (zlib-ng) in the those normal builds with are build in a way you need to specify the CPU target before hand, but in the daily builds it does a runtime check instead (It's explained there, I don't have enough knowledge to understand it fully but I get the concept). They were changing the build method already and that's why the daily builds worked, and now the latest main version also works in my computer.
The issue here (and there) to me, first, It's there is an error anywhere to look up the issue, and also I don't know where to look the specifications to see If at any moment my computer was outdated for that task. Second, If there is a requirement issue, why the daily (debug version in this case) works, but not the normal one? That adds a problem for testing as one build has issues that the other one not, when ideally should be identical for testing. And third, as I understand my computer is old and some projects can't keep up the back compatibility (I know some that already left it behind) and that's life, there should be some explanation somewhere, of why and what's the last version usable, but also knowing that EDuke32 stills does 32 bits builds... It's strange that I did not found any information anywhere (by the way, here I tested the 32 bit version... and it also works! added to the info above), so maybe It was an unexpected requirement that only a few people could detect. I don't know If it can be fixed in the normal version or I would need to stick to the debug version until they finally don't work anymore... but at least should be noted to be known.
Thanks in advance!