ZDoom64 - A last hurrah for classic ZDoom (2.9pre)

[Redneckerz]

Not to be confused with ZDoom 64 which is Doom 64 ported over to an ancient ZDoom build (2.1.5) with an illegal Doom2.wad. This is just something nice.

Introduction:
ZDoom 2.8.1 was released in 2016. Afterwards, GZDoom went its own path, ZDoom 2.8.1 becoming a rather fixed port for speedrunners alike.

Being an early 2016 release, ZDoom saw continued development until December 2016, when ZDoom activity went over to GZDoom.

Serial porter Gibbon, who one may know from his rather excellent service to provide several source ports additional releases to Linux/FreeBSD and Mac Intel/Mac M1 and also has a host of ports of his own, took the latest master of ZDoom (December 2016, 2.9pre), and made a 64 bit build out of it with a few fixes, enough to be stable. In game called Gibbon's 64-bit Build, it is called ZDoom64.

A last hurrah to the classic ZDoom, for multiple platforms, compiled with Visual Studio 22 preview in 64 bit.

I have been testing it so far and its pretty darn good. Its nothing too fancy, but its a good post-2.8.1 build, not targeting the latest in features, but providing a stable release.

Features:

• 64 bit build
• Based off ZDoom 2.9pre (December 29, 2016) as opposed to ZDoom 2.8.1 (February 22, 2016)
• Compiled with VS2022
• Minor fixes to get Mac build rocking again

Details:

Just a modern 64bit build of ZDOOM, untouched except for needed compilation errors that I fixed.

I am not maintaining this or developing this, just providing updated, modern binaries for 64bit systems, similar to what I do for NBlood.

The binaries are under the name 'zdoom64' to differentiate it from the mainline deprecated version.

All builds use SDL2 by default and you must use the midi synthesizer in sound settings for music
- Mac Build: Fluidsynth but no vorbis, ogg, portmidi etc.. (It does have OpenAL too).
- FreeBSD 13: (Same as linux but with fluidsynth)
- Linux Build: No fluidsynth, vorbis, ogg, portmidi etc.. but is compiled with OpenAL (for sound).
- Windows Build: No fluidsynth, vorbis, ogg, portmidi etc.. but is compiled with OpenAL. Use the MS midi Synthesizer in sound settings for music.

Links:

• Windows, Linux, FreeBSD, Mac OS Intel 64 bit: https://github.com/atsb/zdoom/releases/tag/Gibbon

[drfrag]

At first i thought it had something to do with Doom64 lighting but then i remembered it was a 64 bit build. It must be better than ZDoom32 since 64 is more than 32. xD
I don't see any fix to make it stable, just the Mac build fix.

[Redneckerz]

At first i thought it had something to do with Doom64 lighting but then i remembered it was a 64 bit build. It must be better than ZDoom32 since 64 is more than 32. xD
I don't see any fix to make it stable, just the Mac build fix.

Yeah it was originally called just ZDoom but that didn't really cover it so i proposed a name change - And then found there was already such a project with very similar namings, lol.

All i can tell from personal experience is that it feels just like ZDoom 2.8.1 in stability and so far plays everything 2.8.1 did. I am not sure if demo's desync, however.

The multiple platform support is ofcourse quite a plus.

[Nash]

Quite an interesting relic. It seems to support a very early version of ZScript, and the software renderer runs fairly well at 1080p.

[Graf Zahl]

I'd very strongly suggest to go back to the last commit not containing ZScript. Those final commits can not be considered a stable code base!

[drfrag]

That was what i remembered, rather it being bleeding edge. But then they'd need the chainsaw fix at least.

[Redneckerz]

I'd very strongly suggest to go back to the last commit not containing ZScript. Those final commits can not be considered a stable code base!

For the record, what was the last commit on that? Or can we just assume its 2.8.1, based on wiki data?

That was what i remembered, rather it being bleeding edge. But then they'd need the chainsaw fix at least.

The chainsaw fix is implemented according to Gibbon.

[Rachael]

I think that version had broken mirrors, too, if I remember right.

[drfrag]

Having a quick look there was an unitialized variable in the xlat parser, and that was very serious but it affected only 64 bit builds.
Even without ZScript that master had massive changes such as floatification, new savegame code... it's very different from 2.8. Now i remember GZDoom 2.2 was released a bit earlier.
The chainsaw fix was applied in the ZScript branch.

[Rachael]

I hate to sound like a naysayer but this seems to be a project borne more out of nostalgia and rose-tinted goggles than actual usefulness.

Unfortunately I think ZDoom 2.8.1 is going to remain the last truly useful ZDoom version. The 2.9pre branch had too many problems that were not fixed until the total migration to GZDoom took place. You can backport a lot of things from GZDoom to ZDoom 2.8.1 or 2.9pre, but ultimately I think that starting from a solid base would be better.

The biggest problem with 2.9pre is this branch is right in the middle of the migration to floatifying the game renderer and the game sim. A lot of changes that were made to facilitate this were as yet untested and unfixed when ZDoom was abandoned. ZScript issues notwithstanding, on top of that.

However I could be wrong - if you can get all the early post-mortem fixes from GZDoom to 2.9pre this may actually prove to be a solid ZDoom version, and probably worthy of a post-mortem 2.9.0 release. I think it's going to take a lot of testing though - there were a lot of bugs back then.

[Nash]

Yeah, upon further playing, more cracks are revealed. The commit this is based on really isn't solid, at all...

As Rachael said, a better thing to do, if one is inclined to "modernize" ZDoom 2.8.1 is actually start with 2.8.1 and manually backport only what's needed (on top of the x64 compiler fixes or whatever).

This is like making a "release" out of WIP code. :D

[drfrag]

That's what i said, ZDoom32 is solid but i think i probably missed something there too, now i'll have to check.
The main issue is that ZScript was not still a thing in GZDoom 2.2 (it had a 64 bit build already BTW) and ZDoom was discontinued right after the merge, that code was tested and fixed later (even now there could be still some bugs related to actor definitions, i remember that recent minotaur slam thing). Besides that ZDoom32 has hundreds of later fixes. This would require some work.
Edit: older ZDoom versions no longer compile thanks to that shitty Build code, you'd need a workaround. Besides there's ZDoom LE, probably it no longer compiles either i'm not sure. So been there, done that.

[Graf Zahl]

Well, like I said: Better use the last ZScript-free commit that's available. Anything afterward is broken due to incomplete code.
That aside, there's really not much here that's useful. You'd be far, far better off with GZDoom 2.3 because that's when the WIP code became sufficiently stable.
That aside, the only reason for doing such a thing would be some compulsive completism. As a modding platform this is pretty much irrelevant and as a port for regular playing it has nothing to offer.

[Redneckerz]

I hate to sound like a naysayer but this seems to be a project borne more out of nostalgia and rose-tinted goggles than actual usefulness.

Perhaps it is at the wrong footing, but the core of the idea is to keep ZDoom 2.8.1 and just make it available for more platforms, make it 64 bit, and perhaps some small QoL features in a similar manner like ReBoom. Maybe it needs a different name sake, but that's the general gist given that 2.8.1 is being used in sectors it originally was not intended to be.

As Rachael said, a better thing to do, if one is inclined to "modernize" ZDoom 2.8.1 is actually start with 2.8.1 and manually backport only what's needed (on top of the x64 compiler fixes or whatever).

Its probably for the better, unless Gibbon is that ambitious and just goes hamm. I can't say. With a rising track record, who knows.

Well, like I said: Better use the last ZScript-free commit that's available.

Like stated previously, what's that commit?

As a modding platform this is pretty much irrelevant and as a port for regular playing it has nothing to offer.

We can say that about a lot of ports these days I agree that its outlines should be clear.

[Graf Zahl]

IMO this is still utterly useless and sends all the wrong signals to potential users. ZDoom was abandoned right in the middle of very big changes and that final commit holds zero intrinsic value.
Most of these ports you mention actually have a point. That point may be very specific and not quite compelling but it still exists.
This here is just a dead end.

And calling it 'ZDoom whatever' is questionable as well. After Randi stopped working on it we deliberately chose to retire the 'ZDoom' name for new releases.
I know we won't be able to stop you with this, but let me very clearly state that probably noobody here will endorse this endeavour.