[UPDATED] ZDoom32 2.8.6a (ZDoom is undead)

[drfrag]

As you know old versions no longer compile and run with VS 2017 and the v141 toolset so i've reported the previous crash as a bug in the C++ compiler. With the latest version (15.8.4) there's a new crash in p_setup.cpp at line 4091 (times[16].Clock();) so i reverted the previous hack in gl_setup.cpp.
The issue is supposed to be under investigation:
https://developercommunity.visualstudio ... ut-no.html

> zdoom.exe!P_SetupLevel(const char lumpname, int position) Line 4091 C++
zdoom.exe!G_DoLoadLevel(int position, bool autosave) Line 1007 C++
zdoom.exe!G_InitNew(const char mapname, bool bTitleLevel) Line 542 C++
zdoom.exe!G_DoNewGame() Line 367 C++
zdoom.exe!G_Ticker() Line 1073 C++
zdoom.exe!TryRunTics() Line 1946 C++
zdoom.exe!D_DoomLoop() Line 1016 C++
zdoom.exe!D_DoomMain() Line 2673 C++
zdoom.exe!DoMain(HINSTANCE hInstance) Line 1074 C++
zdoom.exe!WinMain(HINSTANCE__ hInstance, HINSTANCE_ nothing, char cmdline, int nCmdShow) Line 1329 C++

- times[16] {Counter=0 } cycle_t
Counter 0 _int64

Edit: this crash is gone. The other one was a result of optimizing with the fast floating point model.

[TDRR]

Hey drfrag, can you add support for my backport of The Adventures of Square? It can be identified by the lumps SQU-SWE1(.txt) and E2A1(no extension). (same as those used to recognize the unmodified version) and is named square186.pk3

It would be nice if you also put this in ZDoom LE.

The difference in speed for relatively old machines is incredible, in GZDoom the speed is basically unplayable in E2, and here it's running at around 20fps at worst, which is pretty playable, everything considered.

[drfrag]

I've uploaded a new version, it adds several bugfixes and NormalNx scaling.
https://github.com/drfrag666/gzdoom/rel ... 2.8.5b.zip

[ClessxAlghazanth]

Thanks very much for the hard work and keeping this brilliant project alive , drfrag ! To say the truth , I just registered here in order to thank you for ZDoom32 !

Being stuck on a near 10 year old pc for my gaming needs , I had no luck with GZDoom (including earlier versions) , it lagging like hell and having severe fps drops , especially while playing mods like BD and CD. I have searched forums , read a lot of threads , and the general consensus was GZDoom should be as fast as Zdoom in software mode and there was no point of using old ZDoom because GZDoom has everything Zdoom has plus OpenGL option and new features and bug fixes , right ? I have tried everything , using software mode , lowering the resolution , disabling all the fancy gfx options , none helped and the game lagged bad with both sw/ogl modes even on the original levels... I gave up and continued using ZDoom 2.8 for long time

And I accidentaly discovered ZDoom32 and gave it a try without expecting much...

Much to my surprise , the game runs smoother than it ever did for me , I can blaze through starterpack with ogl with almost no slowdown , even Project Brutality which gave me trouble and was borderline unplayable runs at a reasonable speed

I feel like I'm in Doom Heaven once again

Thanks very much for the great work and please keep it alive ! I'm pretty sure there are lots of people in similar situation and appreciating the effort !

(Sorry for the bad grammar , English is like my third language)

[TDRR]

drfrag, is it okay if i were to relicense this under the GPL? Obviously there's code to clean up (specifically, removing any BUILD engine code and defaulting to the OpenAL backend, and i think the OPL player also has to go, and probably the software renderer)

[Graf Zahl]

This fork predates all work on the software renderer to make it GPL compliant. So the only way to change the license is to make it hardware rendering only - which would defeat its purpose entriely.

[TDRR]

This fork predates all work on the software renderer to make it GPL compliant. So the only way to change the license is to make it hardware rendering only - which would defeat its purpose entriely.

I imagine that would be necessary. I think i could maybe try to backport a newer software renderer from GZD 3.0 but not sure how feasible that is (probably not much at all)

Even then, just having the more advanced GL 2.0 renderer at hand is good enough. It also runs in W98 but with the need for a GL 2.0 card i'm not sure how good that is.

[drfrag]

The internal compiler error with lambdas won't be fixed until VS 2019 so i've reverted that thing again.

drfrag, is it okay if i were to relicense this under the GPL?

You can't, it doesn't work like that. You'd need to refork the project with a different name. This is a maintenance late version of ZDoom, the software renderer is the default and the main one. I don't think you could even call it ZDoom somethingbwithout software, the 32 cames from the old 32 bit renderery by dpJudas BTW.
About naming GZDoom something i don't know but i would not do it without Graf's permission since it's not a release by GZ. The version running on 98 now is the one without the hardware renderer (older releases did but there were problems with MinGW).
Is really LZDoom that slower?

Thanks very much for the hard work and keeping this brilliant project alive , drfrag !

Thanks, i really appreciate it. However there's not much i can do to maintain this, the only thing i can think of would be full decorate support and there's not much interest. I can't do it right now anyway unless some people want to support the project (very unlikely). I mostly play with LZDoom now on an intel 11 year old laptop. BTW i know there's a crash with eviternity (probably something fixed later) and i'd like to do another release but i'm in a very bad situation now.

[TDRR]

The internal compiler error with lambdas won't be fixed until VS 2019 so i've reverted that thing again.

drfrag, is it okay if i were to relicense this under the GPL?

You can't, it doesn't work like that. You'd need to refork the project with a different name. This is a maintenance late version of ZDoom, the software renderer is the default and the main one. I don't think you could even call it ZDoom somethingwithout software, the 32 cames from the old 32 bit renderery b dpJudas BTW.
About naming GZDoom something i don't know but i would not do it without Graf's permission since it's not a release by GZ. The version running on 98 now is the one without the hardware renderer (older releases did but there were problems with MinGW).
Is really LZDoom that slower?

Not sure if i understood correctly, but just to not do anything wrong i'm just going to roll back to GZDoom 1.8.6 and continue working on that then.
If it's about the name, i could pretty much just call it something like: SUIDTE (Souped Up ID Tech 1 Engine) and remove all GPL-incompatible code. I'm actually considering on switching to ZDoom LE if it's a lot faster, but maybe the new features are more worthwhile than the speed.

Yes, LZDoom is that much slower, considering my target systems and me wanting to get every last bit of performance and graphics out of the GL 1.4 renderer (i even bundled the QEffectsGL wrapper with it, and yes, it's GPL)

[Rachael]

Thanks very much for the hard work and keeping this brilliant project alive , drfrag !

Thanks, i really appreciate it. However there's not much i can do to maintain this, the only thing i can think of would be full decorate support and there's not much interest. I can't do it right now anyway unless some people want to support the project (very unlikely). I mostly play with LZDoom now on an intel 11 year old laptop. BTW i know there's a crash with eviternity (probably something fixed later) and i'd like to do another release but i'm in a very bad situation now.

Thanks for the kind reply , drfrag ! This build really means so much to me.Playing Complex Doom / Project Brutality w/ various megawads without slowdown is like a miracle !

Like I mentioned before , being broke (thx to divorce and shtty job) and beint stuck on a older laptop for all gaming needs really sucks.Not that I'm much into recent games since I mostly play retro games and emulators for 8~16 bit systems , but Doom is my drug since childhood , both vanilla and with mods

Btw I wonder is it normal for GZDoom (3.7.2 32-bit) lag so much on both SW/HW rendering even with all graphical eye-candy stuff like anistropic filtering turned off and everything set for performance ? I even tried 640x480 resolution but still similar results.Especially in wads like Maps of Chaos , it becomes a slideshow halfway through. I thought GZDoom OGL rendered was more advanced and demanding , but even on SW mode not much different... I wonder if sth like a 'Optimized for performance" option can be added to new GZDoom , using the renderer? from ZDoom32 or something ? I'm not a tech-savvy person so I'm probably misinterpreting stuff so sorry about that

[Graf Zahl]

Btw I wonder is it normal for GZDoom (3.7.2 32-bit) lag so much on both SW/HW rendering even with all graphical eye-candy stuff like anistropic filtering turned off and everything set for performance ? I even tried 640x480 resolution but still similar results.Especially in wads like Maps of Chaos , it becomes a slideshow halfway through. I thought GZDoom OGL rendered was more advanced and demanding , but even on SW mode not much different... I wonder if sth like a 'Optimized for performance" option can be added to new GZDoom , using the renderer? from ZDoom32 or something ? I'm not a tech-savvy person so I'm probably misinterpreting stuff so sorry about that

What's your graphics hardware? And are you talking about the modern or the legacy build? Keep in mind that even the software renderer uses OpenGL to transfer the image to the screen, so if the bottleneck there is too severe it will also lag. Outdated graphics drivers may also be a cause for excessive lag.

[ClessxAlghazanth]

Btw I wonder is it normal for GZDoom (3.7.2 32-bit) lag so much on both SW/HW rendering even with all graphical eye-candy stuff like anistropic filtering turned off and everything set for performance ? I even tried 640x480 resolution but still similar results.Especially in wads like Maps of Chaos , it becomes a slideshow halfway through. I thought GZDoom OGL rendered was more advanced and demanding , but even on SW mode not much different... I wonder if sth like a 'Optimized for performance" option can be added to new GZDoom , using the renderer? from ZDoom32 or something ? I'm not a tech-savvy person so I'm probably misinterpreting stuff so sorry about that

What's your graphics hardware? And are you talking about the modern or the legacy build? Keep in mind that even the software renderer uses OpenGL to transfer the image to the screen, so if the bottleneck there is too severe it will also lag. Outdated graphics drivers may also be a cause for excessive lag.

I checked the control panel and it just says 'Mobile Intel (R) 4 Series Chipset Family'. And I'm using the Legacy build (32-Bit)
Oh , and I'm on Windows 7 32-Bit.I understand I have a old processor with a weak graphics card , but the way it starts kinda ok and gets slower and slower to the point of a slide-show even with the lowest settings is kinda intimidating.

ZDoom32 2.8.5 runs smooth almost all the time except a second of brief lag when I clear a room of monsters with a grenade
The only downside of it (for me) is the incompability with some newer mods like Trailblazer , Skulldash etc

[drfrag]

If it's about the name...

It is, just call it something else and say you forked from ZDoom32. I think calling it ZDoom something would be misleading without a software renderer. GZDoom something probably would be okay (there was a GZDoom-GPL). ZDoom GL already existed. Just be creative.

I checked the control panel

I guess you have intel gma 4500M and then it's the same as mine in my old laptop. That chip was extremely slow, ZDoom32 is much faster there. LZDoom is also slower. Resolution won't affect the minimum fps rate.
Older versions supported less features and modern versions are designed for more recent hardware.

[primavoltage]

drfrag, i have encountered a problem using Zdoom32 (GL Version), when i enable the Automap texture and when i access to the Automap menu, it crashes the port in the process while the Non-GL Version works smoothly without a problem...

and is there a possibility that this port can now had a full ZScript function support in the future update (if this port is not much dead even though its undead already)...

i use this port all the time and i like it using it cuz when i use GZDoom, LZDoom and QZDoom, it drops the framerate while playing especially when im running in D4T and Lt. Typhon due to its foggy and flame effects in the main background of the mod and drops its rate when playing levels with outdoor areas that shows the Sky textures like in the very first DOOM map level E1M1: Hangar so when i play DOOM while this ZDoom32 doesn't and the framerate goes above 60FPS so the performance was extremely smooth (drops when encountered a very vast number of particles and sprites)...

[drfrag]

Fixed, ZDoom32 is based on the old Truecolor ZDoom by dpJudas (the father of QDoom) and that bug was fixed much later by Rachael. After a few hours of investigation and debugging i've figured it myself but then i found her commit. It crashed inside DCanvas::FillSimplePoly due to a wrong function call becouse of a missing parameter (should have called OpenGLFrameBuffer::FillSimplePoly instead). Shitty.
I've added a few more things while i was at it. I'll do another release with the fix.

https://github.com/drfrag666/gzdoom/commits/gzdoom32

The port is pretty much dead, i considered adding full Decorate support but there was no interest. I could have merged an early ZScript but what for? You can't export things to ZScript when there's nothing to export. It's a very old codebase and only a few things could be ported back.
There are a few hacks in LZDoom already for the Fake Generic UI (tm) support .

What i should do is make LZDoom faster, but how? I know lights were clamped in the old GL renderer but i don't know what else. I theory controlling it with a cvar could increase performance. Easier said than done.