ZZDoom 2.9.0

[drfrag]

This is the TLDR version for more information visit: https://forum.zdoom.org/viewtopic.php?f=231&t=74039

ZZDoom is a reconstruction of ZDoom i've done based on GZDoom 2.4.0 without the GL renderer. I fixed the software renderer (wrong lighting for sprites) and backported a ton of later bugfixes plus some minor QOL features.

 

Some highlights:

• + ZScript 2.4.0 (optional with the -nozscript parameter to run eviternity and other wads targeting Boom).
• + ACS stack protection and unsafe execution context.
• + Fixed: a render radius of 0 did not restrict rendering to the source sector.
• + Uses always the D3D shader for gamma so don't enable it on ancient machines.
• + New wide low resolution modes obtained quadruplicating 1280x720, 1280x768 and 1360x768.
• + UMAPINFO and DEHEXTRA support.
• + Free space margin for automap.
• + win_borderless for fake fullscreen in Windows.
• + Master volume setting.
• + Fixed sound limiting not working properly.
• + Raise SNDSEQ limit to 4096 sequences.
• + DF_INSTANT_REACTION DM flag to fix fast monsters.
• + DF2_NO_COOP_THING_SPAWN DM flag to prevent spawning MP things in coop.
• + Some extra CVARS: "sv_damagefactor*, am_unexploredsecretcolor, am_showkeys_always, nocheats, chat_self, d3d_nogammaramp.
• + Added +FRIGHTENING flag.
• + Major optimization on carry scroller code.
• + Lots of bugfixes.
• + Vista or later required (VS 2017 64 and 32 bit builds).
• + Not intended for old hardware.
• + No weird stuff this time.

 

The source is here:
https://github.com/drfrag666/zdoom32/tree/master
https://github.com/drfrag666/zdoom32/tree/2.9_work

Release:
https://github.com/drfrag666/zdoom32/releases/tag/2.9.0

 

While i was at it i've also updated ZDoom32 to 2.8.6a.

https://github.com/drfrag666/zdoom32/releases/tag/2.8.6a

[Redneckerz]

49 minutes ago, drfrag said:

This is the TLDR version for more information visit: https://forum.zdoom.org/viewtopic.php?f=231&t=74039

ZZDoom is a reconstruction of ZDoom i've done based on GZDoom 2.4.0 without the GL renderer. I fixed the software renderer (wrong lighting for sprites) and backported a ton of later bugfixes plus some minor QOL features.

 

Some highlights:

• + ZScript 2.4.0 (optional with the -nozscript parameter to run eviternity and other wads targeting Boom).
• + ACS stack protection and unsafe execution context.
• + Fixed: a render radius of 0 did not restrict rendering to the source sector.
• + Uses always the D3D shader for gamma so don't enable it on ancient machines.
• + New wide low resolution modes obtained quadruplicating 1280x720, 1280x768 and 1360x768.
• + UMAPINFO and DEHEXTRA support.
• + Free space margin for automap.
• + win_borderless for fake fullscreen in Windows.
• + Master volume setting.
• + Fixed sound limiting not working properly.
• + Raise SNDSEQ limit to 4096 sequences.
• + DF_INSTANT_REACTION DM flag to fix fast monsters.
• + DF2_NO_COOP_THING_SPAWN DM flag to prevent spawning MP things in coop.
• + Some extra CVARS: "sv_damagefactor*, am_unexploredsecretcolor, am_showkeys_always, nocheats, chat_self, d3d_nogammaramp.
• + Added +FRIGHTENING flag.
• + Major optimization on carry scroller code.
• + Lots of bugfixes.
• + Vista or later required (VS 2017 64 and 32 bit builds).
• + Not intended for old hardware.
• + No weird stuff this time.

 

The source is here:
https://github.com/drfrag666/zdoom32/tree/master
https://github.com/drfrag666/zdoom32/tree/2.9_work

Release:
https://github.com/drfrag666/zdoom32/releases/tag/2.9.0

 

While i was at it i've also updated ZDoom32 to 2.8.6a.

https://github.com/drfrag666/zdoom32/releases/tag/2.8.6a

Absolutely wonderful drfrag. It was a joy playtesting this.

 

Also thanks to @TDRRfor playtesting this aswell!

 

A few extensions for other readers:

So, what's the difference between this and @Gibbon's RZDoom?

Although both look the same on the offset, ZZ and RZ do not target the same audience.

 

ZZDoom:

• Evolutionary approach: Focuses on establishing what a future ZDoom would have looked like if development continued post 2.8.1
• Not directly based off 2.8.1, but a post-2.8.1 build
• ZScript support
• Support for new standards: UMAPINFO/DEHEXTRA
• Runs Eviternity properly
• Bugfixed release, compatible with GZDoom 2.4  but without the GL rendering

RZDoom:

• Conservative approach; focuses on slimlining ZDoom 2.8.1's codebase and keeping it up to date with today's hardware whilst changing nothing to the rendering systems
• Multiplatform support
• Only small QoL features (Extra gibbing)
• Runs Lilith.pk3 properly

As one can tell both ports target different audiences: ZZDoom is ZDoom modernized, RZDoom is legacy ZDoom updated for today.

 

Congratulations with this, drfrag! Ill make ZZDoom a mainstay in the next year.

[BigBoy91]

Looks promising!

[HackNeyed]

This look cool but please, please tell me it stands for Zed Zee Doom

 

Nevermind

[Gibbon]

Congrats DrFrag!

 

Though you have apparently broken support for macOS (ARM64) since you kept the old i386/x86_86 assembler (on Mac, CMake does not let you choose NOASM).

 

You also use the broken version of libdumb (resampler.c) for ARM.  Though you can take that from RZDoom.  You might want to mention you only target Windows / it isn't cross-platform.

 

I don't really game on Windows so I won't try it, but congrats on the release anyway!

[drfrag]

Thanks, it also compiles on linux. It should compile on intel macos unless there's a bad merge or something else (there was a missing include on linux) but like i said i could not test it. I don't think GZDoom 2.4 compiled on ARM macs, i think that was fixed recently.

[Gibbon]

Yeah it does, but Intel Macs are partially deprecated hardware, it's on borrowed time.  The easiest fix is to either wrap all assembler with #ifndef __APPLE__ && __arm64__ which would just use the extern C stuff (as well as fixing your version of dumb).  Or better yet, remove the assembler altogether, since if you read it, it really doesn't provide any benefits on today's hardware unless you're targeting computers that are 8+ years old.

[ducon]

You should tell the OS supported in the archive.

In Debian Sid, I needed to install libgtk-3-dev and its dependencies (libatk-bridge2.0-dev libatk1.0-dev libatspi2.0-dev libblkid-dev libcairo2-dev libdatrie-dev libdbus-1-dev libegl1-mesa-dev libepoxy-dev libfribidi-dev libgdk-pixbuf-2.0-dev libglib2.0-dev libglib2.0-dev-bin libgraphite2-dev libgtk-3-dev libharfbuzz-dev libharfbuzz-gobject0 libmount-dev libpango1.0-dev libpcre16-3 libpcre2-dev libpcre2-posix3 libpcre3-dev libpcre32-3 libselinux1-dev libsepol-dev libthai-dev libwayland-bin libwayland-dev libxcb-render0-dev libxcb-shm0-dev libxkbcommon-dev pango1.0-tools wayland-protocols).

But:

CMake Deprecation Warning at src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find SDL2 (missing: SDL2_LIBRARY SDL2_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  FindSDL2.cmake:179 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  src/CMakeLists.txt:239 (find_package)

 

[SilverMiner]

On 12/26/2021 at 2:40 PM, drfrag said:

DEHEXTRA support.

Mmm, cool. Maybe :)

I don't like the smoothiness of weapon swaying. I'd like it to look as rough as Zdoom 2.8.1 has

EDIT:

Now with this cool port I gonna try what I can do with ZScript hehe

Edited December 27, 2021 by SilverMiner

[Gibbon]

2 hours ago, ducon said:

You should tell the OS supported in the archive.

In Debian Sid, I needed to install libgtk-3-dev and its dependencies (libatk-bridge2.0-dev libatk1.0-dev libatspi2.0-dev libblkid-dev libcairo2-dev libdatrie-dev libdbus-1-dev libegl1-mesa-dev libepoxy-dev libfribidi-dev libgdk-pixbuf-2.0-dev libglib2.0-dev libglib2.0-dev-bin libgraphite2-dev libgtk-3-dev libharfbuzz-dev libharfbuzz-gobject0 libmount-dev libpango1.0-dev libpcre16-3 libpcre2-dev libpcre2-posix3 libpcre3-dev libpcre32-3 libselinux1-dev libsepol-dev libthai-dev libwayland-bin libwayland-dev libxcb-render0-dev libxcb-shm0-dev libxkbcommon-dev pango1.0-tools wayland-protocols).

But:

CMake Deprecation Warning at src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find SDL2 (missing: SDL2_LIBRARY SDL2_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  FindSDL2.cmake:179 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  src/CMakeLists.txt:239 (find_package)

 

You want:

https://packages.debian.org/sid/libsdl2-dev

 

Also, wow, that CMake version needs updating for sure.

[ducon]

Yes, and fmod too:

-- Looking for FMOD_System_GetDriverCaps in /usr/local/lib/libfmodex-4.22.06.so
-- Looking for FMOD_System_GetDriverCaps in /usr/local/lib/libfmodex-4.22.06.so - found
-- Configuring incomplete, errors occurred!

If SDL is used and required, why not using its sound libraries instead of fmod?

[drfrag]

Actually i bumped the CMake version requirement in LZDoom and that broke compilation so i had to do other changes. Here there's no CI. Besides what will happen in the future? Will it stop working?

ZDoom used FMOD so same here, OpenAL-soft also worked back then so you could compile without FMOD.

[Gibbon]

4 hours ago, drfrag said:

Actually i bumped the CMake version requirement in LZDoom and that broke compilation so i had to do other changes. Here there's no CI. Besides what will happen in the future? Will it stop working?

ZDoom used FMOD so same here, OpenAL-soft also worked back then so you could compile without FMOD.

I bumped RZDoom to 3.15.  You just have to fix the CMakefile and fix compilation.  Took about 15 minutes.  You could probably take those updates and retroactively apply them to ZZ.  I think we're fairly compatible like that.

Edited December 27, 2021 by Gibbon

[Mr Nobody]

Thanks a lot for share this fantastic port, works smooth and looks great. Performance is very good tested with gigantic maps with thousands of demons. It isn't bloated with ton extra options and performs very well. Very appreaciated the implementation of win_borderless option.

 

I'm glad to see that ZDoom continues to be loved after its discontinuation, so yeah, thanks for all the hard work!

[Redneckerz]

Update:

Although graciously too late, i kept my word and now ZZDoom is on the DoomWiki (and ZDoomWiki too)

 

As this port includes niceties like DEHEXTRA and UMAPINFO support, those respective pages have also been updated to include ZZDoom.

[EpicTyphlosion]

So I take it ZDoom32 is dead?

 

Also, why is Vista of all OSes the minimum? Doesn't VS 2017 still have the XP compatibility package?

Edited May 6, 2022 by EpicTyphlosion

[Gibbon]

7 hours ago, EpicTyphlosion said:

So I take it ZDoom32 is dead?

 

Also, why is Vista of all OSes the minimum? Doesn't VS 2017 still have the XP compatibility package?

I'm pretty sure 2017 was the last to support it.  I didn't see it in any of the recent community versions for the last few years.  Maybe it was in 2019 but I skipped that and went right to 2022.

 

A big issue for this, is that, even if you 'can' build for XP, debugging XP-specific problems without having an XP machine yourself, for a developer, would be a pain in the rear end.

[Graf Zahl]

5 hours ago, Gibbon said:

I'm pretty sure 2017 was the last to support it.

 

Correct. 2019 dropped the XP toolset (which was also when GZDoom dropped XP.) Technically you could still install an older version but you'd get no compiler upgrades.

 

13 hours ago, EpicTyphlosion said:

Also, why is Vista of all OSes the minimum? Doesn't VS 2017 still have the XP compatibility package?

 

The main reason for this is that Windows got some major behind the scenes upgrades between XP and Vista that modern code relies upon. To make these things work on XP some clumsy workarounds in the C runtime would be needed. As an example, several multithreading synchronization objects that are exposed in modern C++ simply do not exist on Windows XP, which would make supporting both a lot more complicated.

A few things like this were enough to require a separate compiler toolset and since the overall numbers of XP users is getting close to 0% there is no good reason anymore to provide support for it - which gets compounded by 32 bit support getting ever more pointless in general as well.

 

Some hard numbers: The GZDoom survey of 2019 showed 0.12% of users on XP - in absolute numbers this was 41 users out of >30000 reports.

[Redneckerz]

On 5/6/2022 at 2:36 AM, EpicTyphlosion said:

So I take it ZDoom32 is dead?

Had an update 2.8.6a at around the same time ZZDoom was released.

[rampancy]

tl/dr if anyone could clarify for me what release i need for 98 and how to enable gl thatd be fantastic.

 

noob questions...

 

i read through the changelog and the readme on github, but im still stuck.

 

zdoom32 286a, how to enable gl renderer? i see the two execs, i read somewhere that one supports sse2 and one does not, which is which? and are the ones on github win98 compatible? i ask bc zdoom32.exe (non n) only runs if i use kernelex in xp mode. i recently got a win98 laptop (pentium m, geforce go 7800) and its a trip going 30 years into the past plus all the shit that wasnt around back then (kernelex, himem, unofficial service packs, etc).

 

[DosFreak]

Still testing a few oddballs before I upload builds to vogonsorg on github so people don't have to go hunting (drfrag is the exception there) but here you go:

https://www.vogons.org/viewtopic.php?p=1071341#p1071341

 

For 9x for zdoom ports can use the following (kernelex can enable you to use later builds, this list is for vanilla 9x):

95 gzdoom 1.1.04
95 zdoom-old/zdoom CL v2.1.4a
95-NT4 zdoom v2.4.0
95-98-ME-NT4 zdoom LE v2.8.1f
98-ME zdoom 2.8.1
98-ME gzdoom 1.8.00
98-ME zdoom-old/zdoom CL v2.1.8 
98-ME zdaemon11019_win32_bin
98-ME zdoom LE 2.8.3a
98-ME-NT4 zdoom32 v2.8.6

 

For the above I don't currently have them sorted via render type, never really seen an issue with using software instead of OGL or D3D for Doom.

 

It's been awhile since I tested compatibility with kernelex the last vers I tried are (some good candidates to test would be the XP compatible builds from the link above):

Chocolate Doom 20210726

Crispy Doom 20210725

prboom+ 2.5.1.7um

Rude 3.1.0pre

Woof! 6.2.0

 

https://www.vogons.org/viewtopic.php?p=685378#p685378

Quote

I've changed the executables and their names in the package (for compatibility). Now there's a full version (VS 2015 build) with the GL renderer requiring SSE2 and without ASM for SAFESEH running on XP and later and a N version without the GL renderer and with ASM for old non SSE2 cpus. That one still runs on win98.

Edited May 19, 2022 by DosFreak : Changes

[Deathbringer2]

Sorry for somewhat of a bump, but is there any chance of support for DEHEXTRA's "Dropped item" being added? Currently it is ignored.

[Professor Hastig]

Before bumping an old project thread for a feature request you should really check if the project is still active.

 

This one has been dormant for well over a year and most likely won't get resurrected anymore.

 

[Deathbringer2]

Well it's still the "newest" software Zdoom.

 

Fiiiine, I'll fiddle with GZDoom's configuration until it looks like 2001 never ended!