Welcome to the ZDoom Forums!

From the creators of <insert long list of ZDoom derived forks here> now comes ZZDoom, the last hurrah for classic ZDoom part II.
But why oh why are you doing this you may ask, well this is my response to that ZDoom64 thing. I didn't like it and somehow they pushed me to do this.
Like a spanish proberb says "we were only a few and the grandma gave birth".
I named it ZZDoom becouse it came after ZDoom. Yeah it's a fankenstein build, i reconstructed ZDoom with pieces from GZDoom, ZDoom32 and LZDoom. Well if it has FMod and the original software renderer it must be ZDoom.
Now how did i do it? I mostly recycled my work in other ports. I forked GZDoom 2.4.0 so it's based on maint2.4 then i removed the GL renderer (i compared with the ZDoom master) and cherry-picked stuff from maint_3.0, ZDoom32 and LZDoom. It should be solid in theory and to me it's cool. It mainly has bugfixes and a few minor features, the branch is 500 commits ahead maint2.4. I hope i didn't mess up things but this would need testing. I don't know much about licenses but it should be okay, i reverted the LPGL change since that applied to the GL renderer (comparing with ZDoom master). The rest is the same as in GZDoom 2.4.0. GZDoom 2.2.0 had serious bugs, 2.3 and 2.4 had a broken software renderer (wrong lighting for sprites, that renderradious thing). So to me this has some value for nostalgia reasons or "completeness", of course it's better to just use a later GZDoom. But hey they released ZDoom64 so i had to do it.

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 XP required (VS 2017 64 and 32 bit builds). Now added a v141_xp build.
+ 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

Edit: wenas, i've added a win XP build to the release and it seems to work well.

drfrag wrote:From the creators of <insert long list of ZDoom derived forks here> now comes ZZDoom, the last hurrah for classic ZDoom part II.
But why oh why are you doing this you may ask, well this is my response to that ZDoom64 thing. I didn't like it and somehow they pushed me to do this.

Never would i have thought that an incomplete try out (ZDoom64 basically being 2.9pre as is with all the debug stuff in) would encourage you to do this. So what we have here is once again a rather interesting port with your own takes.

For what it is worth, Gibbon, who build ZDoom64, went back to the drawing table and is now working on an actual follow up on ZDoom64. A slimlined build of ZDoom 2.8.1. Where your port is basically an awesome Definitive edition, his would be a Slimline version.

I think both serve their place. Yours just also throws in a little extra

drfrag wrote: So to me this has some value for nostalgia reasons or "completeness", of course it's better to just use a later GZDoom. But hey they released ZDoom64 so i had to do it. Some highlights:

So, if i read this correctly, this is:
- The definitive ZDoom (2.9pre)
- Takes nuts and bolts from LZDoom, ZDoom32, and GZDoom 2.4
- Removes the OpenGL renderer from GZDoom 2.4
- A ton of fixes along the way
- Includes DEHEXTRA/UMAPINFO support
- Includes proper ZScript support
- Software rendering baby!

Is the above correct? Because, you know... my ZDoom contract has a clausule that whenever drfrag makes a new port, ill have to add that (with love!) to the wiki.

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

No releases for now but i uploaded a couple of devbuilds:
https://devbuilds.drdteam.org/zdoom32/

Since i offered up to Gibbon to test out his fork, i also like to offer the same thing to you. Would these devbuilds suffice for that, or could i kindly (Raises hands) apply for a release build?

I think this would even be worthwhile to put up to the frontpage, because as you say, it is one last hurrah for ZDoom 2.8.1, and with your status as LZDoom/GZDoom Vintag developer, there is some official seal of approval here.

Careful!
You cannot swap out licenses like this unless you have double and triple checked if everything is fine. But it's clearly not! This still contains LGPL v3 code from some of the MIDI backends so you are still partially bound by it and need to include it.

That's why i asked. The README mentioned the GL renderer, i'll revert the change inmediately.

Redneckerz wrote: Would these devbuilds suffice for that, or could i kindly (Raises hands) apply for a release build?

Thanks. This time i don't want to do a release until i'm sure there are no regressions. I think it's a bit early to add it to the Wiki but i appreciate your interest.
Any testing is good, i think TDRR is testing mods. I remember how buggy the first ZDoom32 releases were, and even now while doing this i've found more bugs.
For now it seems it's working pretty well but sometimes it's hard to know if a patch it's applicable or not and there's risk of breaking stuff. This time i'm in maintenance mode BTW so no weird stuff. xD
You're very welcome to trying it and give feedback of course.
About doing an official release i don't think that's a good idea, sure 2.8.1 had bugs but it was a solid release. We would need randi's approval and this is a frankenstein build not something out of regular ZDoom development. I don't see a strong need for it. Besides after all it's still an ancient version, even with a whole year worth of changes.
it's unfortunate that ZDoom was left in a broken state tough.
BTW there's no support for the Unity releases, becouse of the widescreen graphics and the wide status bar.
Edit: i see Gibbon has released his fork.
Edit2: i'm not sure this compiles on Mac, i cannot test it. I've compiled it on Win and Linux.

drfrag wrote:

Redneckerz wrote: Would these devbuilds suffice for that, or could i kindly (Raises hands) apply for a release build?

Thanks. This time i don't want to do a release until i'm sure there are no regressions. I think it's a bit early to add it to the Wiki but i appreciate your interest.
Any testing is good, i think TDRR is testing mods. I remember how buggy the first ZDoom32 releases were, and even now while doing this i've found more bugs.
For now it seems it's working pretty well but sometimes it's hard to know if a patch it's applicable or not and there's risk of breaking stuff. This time i'm in maintenance mode BTW so no weird stuff. xD

Your call boss Ofcourse, when you feel comfortable enough for a release build is the time when ill start adding it to the wiki.
What i could do is test ZZDoom out with the same WADsets RZDoom was tested with - These mapsets target different limits of the codebase, so if ZZDoom can manage these comfortably, you have a pretty safe bet that 99.99% of ZDoom stuff will function the same. Besides, even ZDoom 1.22 still works on Win10 machines - The crufty core can deal with a few beatings

Ill be on holiday in a week or two, so i then have plenty of time to extensively test this out. I like that it presents an answer to a What if scenario where ZDoom 2.8.1 kept on being developed. It differs in this from RZDoom, which is far more conservative and tuned for performance.

drfrag wrote: You're very welcome to trying it and give feedback of course.
About doing an official release i don't think that's a good idea, sure 2.8.1 had bugs but it was a solid release. We would need randi's approval and this is a frankenstein build not something out of regular ZDoom development. I don't see a strong need for it. Besides after all it's still an ancient version, even with a whole year worth of changes.
it's unfortunate that ZDoom was left in a broken state tough.

Then it should be treated the same as your other forks - Release builds, non-official.
Be as it may, through the brokenness that is ZDoom64 spawned two capable offsprings to carry the ZDoom torch forward. So, if between now and 2 weeks a release build occurs, ill be on that, else ill test with the latest devbuild that drdteam provides.

Good stuff, drfrag!

Thanks. I uploaded a couple of more devbuilds and updated the OP. I plan to do a release this week if everything goes well. I haven't found any problems and @TDRR hasn't reported anything wrong. I doubt anyone else is testing this though.

drfrag wrote:Thanks. I uploaded a couple of more devbuilds and updated the OP. I plan to do a release this week if everything goes well. I haven't found any problems and @TDRR hasn't reported anything wrong. I doubt anyone else is testing this though.

I am not surprised TDRR is testing this . Would love to see a full on release

I can do some tests tomorrow with the latest dev build. I have a few WADS in mind, but some questions:
* I reckon the current build marks the return of the GL renderer as previous posts seemed to indicate?
* What WAD's would you suggest i should test ZZDoom with? Like i said, i know a few obvious ones and i could also use a few from the GZDoom benchmark pile, but what are your ideas?

Let me know,

Redneckerz wrote:I reckon the current build marks the return of the GL renderer as previous posts seemed to indicate?

Of course not, i reverted the license change.
About wads no idea, mods compatible with GZDoom 2.4.0 and older should run. Of course those using models won't be playable.

drfrag wrote:

Redneckerz wrote:I reckon the current build marks the return of the GL renderer as previous posts seemed to indicate?

Of course not, i reverted the license change.
About wads no idea, mods compatible with GZDoom 2.4.0 and older should run. Of course those using models won't be playable.

So general any non-GL demo compatible with GZDoom 2.4.0 and ZDoom 2.8.1. Got it. I may just look at Gibbon's testings and see how ZZDoom fares on them
Then ill make due with some tests tonight. Ill let you know by PM

Why are you talking about demo compatibility? With that many changes it cannot be demo or network compatible with anything, same can be said for any ZDoom version.
It should run mods targeting GZDoom 2.4.0 and lower plus some more mainly targeting non ZDoom derived engines for instance Eviternity (with -nozscript).
A couple of notes: the original software renderer is very slow with masked textures. And this version still uses the ATAGs in the VM, the performance impact should be low though, i could have removed them but it was a major change.

drfrag wrote:Why are you talking about demo compatibility? With that many changes it cannot be demo or network compatible with anything, same can be said for any ZDoom version.
It should run mods targeting GZDoom 2.4.0 and lower plus some more mainly targeting non ZDoom derived engines for instance Eviternity (with -nozscript).
A couple of notes: the original software renderer is very slow with masked textures. And this version still uses the ATAGs in the VM, the performance impact should be low though, i could have removed them but it was a major change.

Yeah whoops i mean any non-GL wad. early morning.

I have a good sample list to work for and ill test tomorrow

I've just uploaded a new devbuild with a change i was not sure about, that radius attack that may inflict damage twice fix.

drfrag wrote:I've just uploaded a new devbuild with a change i was not sure about, that radius attack that may inflict damage twice fix.

Thanks for this. Downloaded and will sample later today. I got a good list that will test various aspects of ZDoom, from old to new.

It's up. Thanks @TDRR and @Redneckrz for testing.

https://github.com/drfrag666/zdoom32/releases

I uploaded it last night. I've also updated ZDoom32 with some things from ZZDoom and other stuff.