Builds newer than nblood_win32_20211015-12587 incompatible with XP

[vogonsorg]

No description provided.

[tmyqlfpir]

It is possible to retain WinXP compatibility without much tweaking. I'm currently maintaining XP compatibility with this fork here by compiling with SDL1 and using zernel32. The changes should be compatible with eduke32 upstream, but I have not confirmed.

[vogonsorg]

Oh, wow! an SDL1 nblood fork! Nice.

Gerwin at vogons was able to compile a working XP version of eduke32 for XP with some code changes so likely the same could be done for nblood assuming that the issues were the same of course
https://www.vogons.org/viewtopic.php?p=1105085#p1105085

[vogonsorg]

nblood_win32_20211015-12587.zip
nblood_win64_20211015-12587.zip
nblood_win32_debug_20211015-12587.zip
nblood_win64_debug_20211015-12587.zip

[tmyqlfpir]

Gerwin at vogons was able to compile a working XP version of eduke32 for XP with some code changes so likely the same could be done for nblood assuming that the issues were the same of course https://www.vogons.org/viewtopic.php?p=1105085#p1105085

I actually checked after the fact, and they did some similar changes. What I found was a lot of the issues coming from mimalloc, which use some Vista only functions. The game runs fine without it, and completes the internal 9 hour demo validation check.

It wouldn't be too hard to even have automated builds, see here for example https://github.com/clipmove/NotBlood/blob/master/.github/workflows/build.yml https://github.com/clipmove/NotBlood/blob/master/.github/workflows/publish.yml

[Gerwin2k]

hey,
Please read the folded quote, in my vogons post from Wed 28-9-2022. Which is also the readme for the download.
There I wrote that minicoro is actually the bigger issue. mimalloc is easy in comparison. If not, then please explain.

Also there is a more debatable aspect to it, which I mentioned at the end. That is the performance. On some systems the performance is now just sad. eDuke32 is now at home on modern hardware with modern OS, and a mismatch for anything else. It is an Ion Fury engine now. For anything retro-oriented it may be a better choice to use or fork early 2018 eDuke32. Though, then you miss out on all the good parts of the 2018-2022 Ion Fury-aimed changes.

[tmyqlfpir]

NotBlood WinXP is able to be compiled with minicoro, but as it doesn't use OpenGL it may not encounter the problems you faced. I don't see the problem as such, as I only intend the XP build to be a drop in replacement for users who are still clinging onto VDMSound and running Blood.

That said, it would be nice to get OpenGL working with XP, but from the brief tests they were not stable. Perhaps if this repo is able to, I'd happily carry over the changes to my fork.

[Gerwin2k]

Yes minicoro can be build without complaints, the incompatibility only surfaces at runtime: "Failed to create context" IIRC. It wants to start an additional CPU thread for rendering with NT6 API calls, OpenGL specific it seems.

[tmyqlfpir]

I see - it would have to be rewritten with something that uses the same minicoro calls, or to replace all code that utilize minicoro with something else that has XP compatibility.

[Gerwin2k]

I back-ported it to the state it had before the minicoro additions, manually.

Worth mentioning: Building a eDuke32 without OpenGL, as in "USE_OPENGL := 0" in the makefile, indeed avoids OpenGL related runtime issues. But building it with OpenGL and then selecting Classic/Software rendering will use OpenGL for some tasks (for speed AFAIK), and that may give undesirable requirements.

[tmyqlfpir]

Yes, it uses OpenGL for some speed improvements and compatibility for switching between software/hardware rendering methods. IIRC this is mostly used for viewport and other boilerplate related functionality. Comparing a regular 32-bit build with the SLD1/Software only build loses about a 4th of performance. Not a big deal but still something to note.