Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
drfrag

ZDoom 2.1.8 Classic

Recommended Posts

 I've created a new repository for old versions (i forked the one by @AlexMax for the ancient no repo versions and combined it with his mirror of the old SVN repo). So in theory i can cherry-pick on top of ancient versions.

 Now i get the "DirectDraw returned no display modes" error on Win10 too and i know i can use an emulator (DXGL) but there are some problems.
 First i wanted to fix 2.0.98 but it didn't compile with modern VS, something about using friend with templates (looks really bad) and an internal compiler error. So wall of errors and even if it did compile i know there would be other problems (reported no gravity and graphics corruption with gcc...).
 Since ZDoom classic was not very good i've recreated it and done a 2.1.8 pirated version without my junk. For the 2.1.8 branch i've merged the preliminary D3D backend and works well, i applied some minor fixes and got rid of the Bison dependency too. I use NASM 0.9.

 I've done a release (from my 2.1.8 branch), it's a VS 2017 v141_xp build. I've named it 2.1.8 Classic.
 One more thing, besides the resurrect fixes i've ported the r_spritedistancecull CVAR by dpJudas as QOL enhancement and it brings massive performance improvements on some maps (up to 5x on planisphere 2, recommended value is 4000).

 TL;DR: This is an old ZDoom version from 2006 fixed to run on modern computers. For historical and preservation purposes, could be useful to run very old mods. Right now i'm playing with it to avoid loading Brutal Doom (i was hooked) and i can cheat less too.
https://github.com/drfrag666/zdoom-old/releases

 

https://github.com/drfrag666/zdoom-old

https://github.com/drfrag666/zdoom-old/commits/2.1.8

 

Share this post


Link to post
1 hour ago, drfrag said:

 I've created a new repository for old versions (i forked the one by @AlexMax for the ancient no repo versions and combined it with his mirror of the old SVN repo). So in theory i can cherry-pick on top of ancient versions.

 

I'm glad it was useful to you, but be warned that it might be incomplete.  I'm not sure if I got every version in there, especially versions that might have had Windows and Linux source distributions available.

 

1 hour ago, drfrag said:

 Now i get the "DirectDraw returned no display modes" error on Win10 too and i know i can use an emulator (DXGL) but there are some problems.

 

Strangely enough, at some point in the past I was able to get past that warning message if I used a Debug build.

 

Regardless, if you're serious about wanting to bring those old versions of ZDoom back to life, I highly recommend junking the DirectDraw code and using SDL2 to render.  I imagine getting a minimum viable rendering going wouldn't be too difficult, and you can start papering over the issues like resolution changing and palette switching as you go.

 

Share this post


Link to post

The list looks mostly complete.

I don't think i'll fix more versions but instead i'd add a simple D3D canvas (if that's the right term) like the one dpJudas made for SoftPoly and keep DDRAW for old machines. That (2.1.7) was the last non-modern version and was a milestone IMO.

If i wanted to do something completely different (and could) the last C version was 1.17c but those were unstable (crashed from time to time), that one should be easier to compile as it was not non standard C++. Odamex is already based on 1.22 and restored vanilla compatibility so that could be doable to create another retro port. Not that i'm going to do it. Those really ancient versions can be run with the emulator (DXGL) using the -noptc switch and then there was the vid_noptc cvar. Those used a shitty modified Prometheus truecolor library (but there wasn't a real truecolor mode). And those versions can't run modern Boom or limit-removing wads anyway, most of them contain errors. As a curiosity wide modes appear but they are not aspect corrected (as expected).

Share this post


Link to post

Would you consider doing 1.23b33?  There is only one modern continuation of it and it's closed source, and there are several maps that rely on the very strange physics of that port.

 

 

That video was taken from my own attempt at fixing up the port but I only got it working, I didn't get around to junking the DirectDraw code.  Odamex emulates some of the particulars, but not all of them.

Share this post


Link to post

I dunno. But what did you do? Why would you need to junk anything? Which compiler did you use?

Seems there are not too many changes and would be doable (tracking win32video). One thing i notice is that the 2.1.8 branch starts at the beginning of SVN but i created it after merging the repos. I guess i made a mistake and created it from the remote? No big deal anyway.

I've found there was an earlier attempt at adding a D3D8 backend but it was always disabled, it was introduced in 2.0.13 and removed in 2.0.49. Only randi knows if it ever worked i guess not well, merging that would be much easier.

Share this post


Link to post

Reporting that ZDoom Classic 2.1.8 works fine on Wine/Linux. Tested TNT, Heretic, Hexen and everything seems to be fine, fullscreen and windowed.

Spoiler

 

- Could not make MIDI music work for this one, both "midi mapper" and "midi port 0" do not work but it works for other games and Winamp. That is very minor though since I usually disable music anyway, unless I'm playing something for the first time.

For some reason the same thing happens with Doom Legacy and Chocolate/Crispy Doom, I can't make music work on these (it has glitches, midi instruments hold playback after game is closed) Maybe adding the LZdoom music portion of the code into these? (again, this is very minor... I'm just reporting what happens when using Wine...)

 

I've been using LZdoom for mods that don't work in Prboom, and I liked very much that now - for both of these - MIDI playback happens natively inside the app somehow, rather than depending on an outside Midi system-wide synthesizer like before, this avoids soooo many problems with Midi making noises, stuttering, crackling, etc.

The guy mentions message errors above, for Linux/Wine specifically there's thing thing that allowed me to finally play newer versions of Xzdoom, finding this terminal command to append while running Wine:

MESA_GL_VERSION_OVERRIDE=3.0 WINEPREFIX="/partition2/.wine" WINEARCH=win64 wine cmd

or

MESA_GL_VERSION_OVERRIDE=3.0 wine explorer

Before finding this, I would get the "Could not initialize opengl" error. The same command does NOT work for standard gZdoom for some reason.

Spoiler

(meme: because it's not true opengl code, don't tell anyone...)

Thanks for LZdoom once again, that one has been a life saver.

Any recommendations of era-appropriate mods from the time that will take full advantage of this port?

Share this post


Link to post
4 hours ago, drfrag said:

I dunno. But what did you do? Why would you need to junk anything? Which compiler did you use?

 

I would want to junk the DirectDraw stuff and replace it with platform-agnostic SDL.  But that's just me.

 

I used the most recent (at the time) Visual Studio compiler and GCC.  GCC was a special case because of the actor definition macros, which nearly drove me insane.  The actors were defined by a series of macros that tried to lay out a stream of bytes in memory in a specific arrangement.  I'm sure there was a performance reason to why it was done this way, but it made understanding what was going on kind of difficult.

 

There were actually two sets of Actor definition macros.  In Visual Studio, it was done by concatenating strings with numbers and such, like you would concatenate two strings (It might've been slightly different, it's been many years ago).  The GCC version, on the other hand, had this insane idea where it defined global variables in sequence - the idea being that if the global variables were laid out in memory next to each other, it would result in the desired byte sequence.  Of course, with modern compilers, this was not a safe assumption to make.

 

Figuring out what was actually going on was the hard part, fixing it was easy.  I simply got GCC working with the MSVC actor definition macros, but it did not like the concatenation of strings, so I had to replace ACTOR_MACRO("foobar") with ACTOR_MACRO('f' 'o' 'o' 'b' 'a' 'r'), which did work.
 

Anyway, I did not push this anyplace public, because I then had the realization that I could not take advantage of any GPL code from other doom ports, so i shelved it.

Share this post


Link to post
11 hours ago, AlexMax said:

Would you consider doing 1.23b33?  There is only one modern continuation of it and it's closed source, and there are several maps that rely on the very strange physics of that port.

 

 

Ugh...

There's really maps depending on it? I still remember the very first ZDoom bug I reported and it was the inverted thrust from explosions in it - made it totally unusable for me...

IMO anything between 1.22 and 2.0.48 should be considered transitional and buggy.

 

5 hours ago, AlexMax said:

I would want to junk the DirectDraw stuff and replace it with platform-agnostic SDL.  But that's just me.

 

While surely better than DDraw I'm really not too fond of SDL - the last time I dealt with it was Raze - and getting off SDL really made a huge difference to how it handles on Windows.

5 hours ago, AlexMax said:

There were actually two sets of Actor definition macros.  In Visual Studio, it was done by concatenating strings with numbers and such, like you would concatenate two strings (It might've been slightly different, it's been many years ago).  The GCC version, on the other hand, had this insane idea where it defined global variables in sequence - the idea being that if the global variables were laid out in memory next to each other, it would result in the desired byte sequence.  Of course, with modern compilers, this was not a safe assumption to make.

 

Oh yeah, bad memories of a past long gone. The actor definitions of these old ports were a nightmare - that's why I spent considerable effort in 2008 to export all of this to DECORATE and get rid of the mess.

 

Share this post


Link to post

 I could not even compile 2.0.98. For 2.1.7 there were serious issues due to a modern VS misoptimization of mscinlines.h. There is some asm there, it says "Build Engine & Tools". And that version was also pre decorate for monster definitions, must be different tough. So i can't use "kill spiderdemon", "kill spidermastermind" or "kill revenant" when there are "too many" but i actually prefer that, i only miss keys in the automap.

 Can't junk anything as then it would be a different thing, besides there is already D3D code in ZDoom.

 Regarding the different jump physics it was actually a bug with gravity and for those old versions you could easily end with a permanent fly mode depending on the compiler. The effect is properly emulated in Zandronum AFAIK as they investigated the issue and in their history they mention it was added, there isn't a proper 1.23 compatibility mode but several additional ZDoom compatibility flags. I don't think there are many maps affected most likely only a few, would be much easier adding a 1.23 compatibility mode than to fix that old version (porting the code from Zandro that is). Besides 1.23b33 runs with DXGL at least windowed (+fullscreen 0) with the emu default settings, but as 1.17 it can't load modern wads with errors (not only the maps also the textures).

@DwarfCleric Can't change, that version used fmod. I can't run anything on wine due to my old laptop graphics card i guess, not even Choco.

 Pretty sure there are some old mods running properly only on that version, someone mentioned it but i can't remember which ones, there are always old mods containing bugs and they break as checks become more strict or relying on engine bugs or undefined behaviour. You should use a modern version unless mods break.

 I personally play now with the classic version to prevent myself from loading BD and killing monsters with cheats.

Share this post


Link to post
7 minutes ago, drfrag said:

I personally play now with the classic version to prevent myself from loading BD and killing monsters with cheats.

 

So you play with the outdated version of ZDoom just to prevent yourself from loading BD? Why don't just "not" load BD when using modern GZDoom/LZDoom.

Share this post


Link to post
7 minutes ago, ReaperAA said:

So you play with the outdated version of ZDoom just to prevent yourself from loading BD? Why don't just "not" load BD when using modern GZDoom/LZDoom.

Welp, habitual gaming. Same case with me back in 2017-2018, when I couldn't play almost anything without Quakestyle (earlier ZX, later Unbounded).

Share this post


Link to post

Heh, easier said than done. I'm hooked. Also to prevent cheat abuse else i may end up killing half of the monsters with the kill command.

I would use RUDE but it's only limit removing (no Boom) and then since it's very close to vanilla there's the lowres, tutti-frutti...

I added a -nod2monsters switch to RUDE for a different twist and slaughter maps, i'm more of a classic Doom 1 player actually. It's cool.

A simple decorate mod does the same for ZDoom.

Share this post


Link to post
22 hours ago, AlexMax said:

Would you consider doing 1.23b33?  There is only one modern continuation of it and it's closed source, and there are several maps that rely on the very strange physics of that port.

 

<video of Destination Unknown MAP02>

 

That video was taken from my own attempt at fixing up the port but I only got it working, I didn't get around to junking the DirectDraw code.  Odamex emulates some of the particulars, but not all of them.

 

Wow, I was not expecting to see my very silly and experimental ZDaemon wad from 14 years ago pop up when I randomly clicked on this thread! I remember I was starting to play Skulltag as well shortly after finishing that project and when I tried to run that wad, all my jumppads suddenly didn't work - a bunch of them kept overshooting you, and MAP01/MAP02's chains of jumppads just broke completely. I had no idea why. I tried to 'fix' that as much as possible mostly by putting impassable lines to stop you from going past them into the void and then releasing a 'skulltag edition' version of it. I have no idea if it gained any sort of traction because I kind of forgot about it shortly afterward and moved on to other things. I'm happy to see that mystery finally explained - I think there were a few other physics differences when running the wad in Skulltag but they didn't matter as much. The other maps that came to mind when I thought about these sorts of jumppads are zdctfmp map17 and dbzone, but both of those generally have a lot more tolerance in their landing pads, whereas my maps had much more precise jumps.

 

Destination Unknown was fairly popular in the years after I made it but I don't think anyone really plays it anymore. I feel like that particular style of infinite-ammo infinite-lives slaughtermaps has long gone out of fashion, replaced by the multitude of complex/lca survival servers. Coopbuild and Drown in Blood were all the rage when I was starting out in online Doom and I made my project as a kind of spiritual successor to those. In fact I looked on ZDaemon just now and there aren't any servers running dest_unknown (though there's a couple coopbuild/dietest servers). On Zandronum though it seems that someone made a 'dest_unknown_zandro.pk3' which also aimed to make the original file more compatible. I don't personally know of any other wads that might be 'broken' by these physics. (edit: yes, I forgot about the various rocketjumping maps made for zdaemon)

I know this is all a little off-topic but you putting the video up suddenly brought back a load of memories from my first years in the Doom community. I am shedding a single nostalgic tear right now.

 

 

10 hours ago, Graf Zahl said:

Ugh...

There's really maps depending on it?

For my maps in particular it was just a case of 'Oh hey this game I'm into has some crazy things you can do with the physics, cool!' and so I did some silly stuff with it, not knowing that the physics were kind of broken and it wouldn't work properly in any other port. I seriously don't think anyone cares much about those maps today.

Edited by stewboy

Share this post


Link to post
10 hours ago, Graf Zahl said:

Ugh...

There's really maps depending on it? I still remember the very first ZDoom bug I reported and it was the inverted thrust from explosions in it - made it totally unusable for me...

IMO anything between 1.22 and 2.0.48 should be considered transitional and buggy. 

 

ZDaemon was based on 1.23b33 and never upgraded, so as long as that port is active, new maps have and will probably continue to come out that utilize 1.23b33 physics.

 

 

It also happens to be the only port based on that codebase that continues to be updated - Odamex is 1.22 with some choice backports and still can't run everything 1.23b33 is capable of.

 

9 minutes ago, stewboy said:

Destination Unknown was fairly popular in the years after I made it but I don't think anyone really plays it anymore.

Hey, good to see you.  I forgot how precisely I used Destination Unknown as a test-bed - I think I might have been investigating the possibility of a fix in Zandronum at the time.  Regardless of if anybody actively plays it online anymore, I just think it would be neat to have an open source port that could play these maps without modification.  Doubly so if it was capable of recording deterministic demos like most other Doom ports instead of client/server demos like ZD or Odamex.

Edited by AlexMax

Share this post


Link to post

And that OLD_ZDOOM_ZMOVEMENT (jump physics) flag didn't cut it but perhaps with the gravity change it will (don't apply double gravity).

The OLD_EXPLOSION_THRUST flag is also interesting (horizontal thrust). You can cheat with air control and no problem (default LIMITED_AIRMOVEMENT in Zandro).

These threads:

https://forum.zdoom.org/viewtopic.php?f=4&amp;t=35401

https://forum.zdoom.org/viewtopic.php?f=4&amp;t=48215

 

But definitely 1.23 physics were "unique" and fun. Randi was about to release a final version but changed her mind, i wonder why. :lol:

 

Share this post


Link to post
On 4/4/2020 at 11:29 PM, drfrag said:

Right now i'm playing with it to avoid loading Brutal Doom (i was hooked) and i can cheat less too.

Wow, that's very creative. I actually like that!

Share this post


Link to post
On 4/6/2020 at 11:07 AM, drfrag said:

 I can't run anything on wine due to my old laptop graphics card i guess, not even Choco.

 

Anything being said in the terminal? Can you play other 2D/3D games on Wine at all?

I just know that before finding out that command line right there I would simply get a blank screen in LZdoom, and I'm restricted to playing "Hardware" mode because "Software" mode simply closes without any warning. (while stock Zdoom works just fine...) I only use LZdoom for mods anyway.

 

Quote

Right now i'm playing with it to avoid loading Brutal Doom

I guess he's doing that because gzdoom doesn't have a convenient built-in launcher (like Prboom and Legacy do) so it's much quicker having a separate port for that rather than having to mess with command lines  e v e r y  s i n g l e  t i m e  p l e a s e  k i l l  m e

 

Screenshots:

Spoiler


PR_Launcher.png.129cbf194b309811d2f9ad8ba13bfedc.png

 

Legacy_Launcher.png.e4ccd1c20fc5ce93a2a09e3ee77f9ce5.png

 

Legacy_Launcher02.png.af593097b56ba885da7311caea958b89.png

 

(and this was done in 2003/2004, Windows XP was still a thing, remember that???   anyway, back on topic...)


 

 

Share this post


Link to post

Everything crashes, must be my OpenGL driver (1.3 only).

No, i can use drag and drop to launch BD (selecting the files i want in explorer first). But i can't run the classic ZDoom software renderer on my modern laptop fullscreen anyway, only Softpoly and the early version in classic. That's becouse it has a cheapo LCD display with a strong blueish tint and i use SunsetScreen (the older version not the one with the bitcoin miner heh) and it's not compatible, same for other tools. The GL renderer is okay.

 

For 1.23 i've tried to add several compat flags and it's true it can't be addressed in modern versions (and 2.7.1 itself is ancient now). Those were only a few specific ZDaemon MP maps besides 1.23b33 was solid but it could only run wads earlier than its release date (to some extent). 2.0.63a won't cut it for that map but almost.

Edited by drfrag

Share this post


Link to post

Update: Reporting that Zdoom Classic 2.1.8 is also accurate and can be used to play Hexen, same looks and behavior as Chocolate Hexen.

 

Also be noted that running Hexen in gzdoom variants there's no earthquake effect at the start of hub3, before the lights in the main hall are turned on. Minor visual detail but can take away from the experience. I recently finished Hexen using gzdoom and now I'm wondering what else did I miss. The difference in lighting alone makes me want to replay it with a proper port. Is the duty of any source code ports to make modifications like that? What's the purpose of removing original features when it doesn't add to the experience?

 

Update 2: Zdoom Classic 2.1.8 is also accurate for Doom map E2M6

 

edit... Update 3: switch to ZDoomLE to support gameplay mods like "hex_balance.pk3" Also looks accurate to Chocolate Doom.

 

Screenshots source ports comparison below:

Spoiler

More screenshots with more details also available on Imgur: https://imgur.com/user/hcueiwb47vndhs84

hexen_map27_chocolateHexen.png.0cce4da2314bf42256bc7e3d3fe399ae.png

 

hexen_map27_ZdoomClassic218.png.2fc9e3974cbb020300b20af4151b6183.png

 

hexen_map27_gzdoom.png.131353c6b1e38136ac556c215fccd415.png

gzdoom variants look somewhat accurate in Hexen with Dark lighting mode, but some visual features are missing

 

845465568_e2m6_ZdoomClassic2.1.8.png.a35c4804df037a22e38bac7ef7e33261.png

Zdoom Classic 2.1.8 looks accurate in E2M6

 

 

Edited by DwarfCleric

Share this post


Link to post

Quoting myself:
 

Quote

 

 The last version including the original ZDoom software renderer (with minor enhancements) is ZDoom32 (also has the original truecolor renderer by dpJudas). Later versions include a refactored and enhanced software renderer that should look the same or pretty much the same.

 That earthquake thing was a bug and was fixed long ago AFAIR, i think it works in ZDoom32 (probably i backported the fix).

 

 

Edited by drfrag

Share this post


Link to post
14 hours ago, drfrag said:

Quoting myself:

 

OK I made a lot of "discoveries" this week after finally jumping into it. And I'm glad I did because I can finally replay Hexen exactly how it was designed to look by the designers and not some borked clone-like "thing" just because it was more convenient.

 

There's only a small bit of confusion to made clear regarding the many forks made available out there.

Some other user just pointed me that there's a thing called ZDoom32 that it's an even more polished version of ZDoomLE, which not only allows recent mods to be loaded but also has features like "draw distance". I'm very interested in that!

(initially I thought I was using ZDoomLE, but when I extracted the ZIP the executable was called zdoom32... unless I made confusion when naming the folder initially...)

 

I just googled Zdoom32 but I can't seem to find download links for it. I mean, I can get to your Github page and all the forks' names are listed there, but I can't seem to find where to properly download them. And then I just found a thread from 2017 where you say Zdoom32 is discontinued and it seems like GZdoom32 took its place.

 

So, to end all confusion, what is the fork that allows me to load recent PK3 mods, has the low-spec optimizations like "draw distance" and is the more recent out all of these?

From what I could find and from all my personal tests I reached this conclusion:

LZdoom - a slight modification of gzdoom to allow older cards to initialize the game, no "performance optimizations" implemented in this one, it's simply intended for gzdoom to launch

ZDoom Classic - it's older and cannot load newer recent mods in pk3 format, accurate looks

ZDoomLE - now I don't know if I tested LE or 32, the executable is called zdoom32.exe and there's one called zdoom32_N.exe - this one allows to loading newer recent mods in pk3 format and still preserves the accurate looks

ZDoom32 - this one would be the most recently updated out all of them and can also load mods, with much more "low spec" optimizations included

 

Where can I find it? Which one is the more recent besides LZdoom?

Share this post


Link to post

So this proves that using different names is even worse and is confusing too.

It's not that complicated, i don't know where you downloaded the file from but all my releases are in https://github.com/drfrag666/gzdoom/releases

I know it's rather unusual that all the projects are hosted in the same repository under different branches. There's no such thing as ZDoom LE 2.8.5, the file is named ZDoom32.

I could have chosen to keep the same name but those were based on old ZDoom versions and i didn't.

To summarize LZDoom > ZDoom32 > ZDoom LE > ZDoom CL.

ZDoom Classic was released about the same time as ZDoom LE, it was based on ZDoom 2.1.4 becouse 2.1.7 crashed with the compiler i used back then for win95 compatibility. I was not happy with it so now i've done a re-release "based" on 2.1.7. Originally was intended to target 486 cpus but it was too slow.

Edit: 2.1.8 classic can run older mods in pk3 format, actually the zdoom wad itself is a pk3.

 ZDoom LE targets older hardware than ZDoom32 (but not as much as CL). I released ZDoom32 after LE and then LZDoom. LZDoom is based on GZDoom 3.3 but then i backported a major part of the later stuff on top of it. The render cull options are enabled by default so you don't need to worry about them (and those can be disabled of course and are present in LZDoom too).

 There's no such thing as GZDoom32. The N executable is a MinGW build and can run on win98, lacks an OpenGL renderer and uses assembler. The regular ZDoom32 exe is a VS 2017 build and requires SSE2 (NO ASM) so won't run on older cpus. You'll get better performance for 32 bit software with the latter.

LZDoom is slower (for me it's fine) becouse the engine became more complex.

The only one i actively maintain right now is LZDoom (besides the vintage/legacy build but without releases, i upload a devbuild from time to time). But there's a pending minor maintenance release for ZDoom32.

Now why should i change the LZDoom name for the next fork? I took all my code (minus the hacks needed for mod compatibility) and merged it with a more recent GZDoom version (it's rebased on top of it), still runs on Direct3D and has the classic interface so...

Do you think Graf should have changed the name to GZDoom GL3 after he dropped GL2 support? Or to IGZDoom (international) after adding the localization feature? Now that it's multithreaded how about MTGZDoom? Or why not IMTGZDoom GL3 and so on? I don't think so and changing the name would be more confusing IMO.

 

Edited by drfrag

Share this post


Link to post
24 minutes ago, drfrag said:

So this proves that using different names is even worse and is confusing too.

.... No, it isn't. What is confusing is releasing a new version that changes the scope of the original version, yet retains the same name. This is in a way applicable to this version of ZDoom Classic here, but seeing as you are thinking of doing a similar thing with LZDoom, i will have to keep bringing this up.
 

9 hours ago, DwarfCleric said:

So, to end all confusion, what is the fork that allows me to load recent PK3 mods, has the low-spec optimizations like "draw distance" and is the more recent out all of these?

From what I could find and from all my personal tests I reached this conclusion:

LZdoom - a slight modification of gzdoom to allow older cards to initialize the game, no "performance optimizations" implemented in this one, it's simply intended for gzdoom to launch

ZDoom Classic - it's older and cannot load newer recent mods in pk3 format, accurate looks

ZDoomLE - now I don't know if I tested LE or 32, the executable is called zdoom32.exe and there's one called zdoom32_N.exe - this one allows to loading newer recent mods in pk3 format and still preserves the accurate looks

ZDoom32 - this one would be the most recently updated out all of them and can also load mods, with much more "low spec" optimizations included

 

Where can I find it? Which one is the more recent besides LZdoom?

The way i put it, is to discern drfrag's legacy codework in rendering tiers. Granted, this does cover every base when it comes to differences, because not all forks are created equal, but i feel its the best way to visually discern the various in an easy way.

  • ZDoom32 has among other things a OpenGL 2.0 renderer, taken from GZDoom 1.9.1.
  • ZDoom LE has a OpenGL 1.2 renderer, taken from GZDoom 1.8.4. Graf did say that GZ never used OpenGL 1.2, but drfrag found out that the renderer works on this level of hardware.
  • ZDoom CL (The versions before this 2.1.8 Classic version) adds in an early Direct3D renderer that was barely documented in ZDoom versions 2.1.7 and 2.2 and adds a OpenGL 1.1 renderer, taken from GZDoom 1.0.17. It can also run on Windows 95.

Basically out of all dr.frag's legacy tiers in terms of GPU support i would use the following performance tiers for clarification because frag adds a lot of features inbetween the various versions:

  • LZDoom (OpenGL 2.0+ and above)
  • ZDoom32 (OpenGL 2.0)
  • ZDoom LE (OpenGL 1.2. I recall it also supports 1.4.)
  • ZDoom CL (OpenGL 1.1 and Direct3D)
24 minutes ago, drfrag said:

It's not that complicated,

The explanation that follows is not something i would consider ''not that complicated''. It may make sense for you, but not everyone is drfrag.
 

24 minutes ago, drfrag said:

Now why should i change the LZDoom name for the next fork? I took all my code (minus the hacks needed for mod compatibility) and merged it with a more recent GZDoom version (it's rebased on top of it), still runs on Direct3D and has the classic interface so...

If the scope of LZDoom changes (And considering you want to move it to Softpoly as a primary means of rendering) then you should make a distinction so people do not get confused.

See this earlier post from mine as to what possible pitfalls you may encounter.

Blzut3 suggested a nomenclature like LZDoom 1.x, LZDoom 2.x, and so forth, in this post.

24 minutes ago, drfrag said:

Do you think Graf should have changed the name to GZDoom GL3 after he dropped GL2 support? Or to IGZDoom (international) after adding the localization feature? Now that it's multithreaded how about MTGZDoom? Or why not IMTGZDoom GL3 and so on?

The difference with this is that Graf usually raised the numbering whenever a new OpenGL version became mandatory. Note that newer renderers were usually introduced prior, but Graf retained the older renderer support for some time before moving over fully.
 

24 minutes ago, drfrag said:

I don't think so and changing the name would be more confusing IMO.

Nothing you have put forward suggests that's the case. On the contrary, retaining the same name for a port that differs enough in scope from its original to warrant a new name or sub-name is vastly more confusing.

I mean, just read back your own explanation of the various ZDoom versions you maintain. The one you say is ''not that complicated''. It references a whole lot of variables to denote the differences, variables most users would not know about. There is no simplification nor summary to be found. Ideally, you would base the differences around a common denominator that you can expect users to understand quicker, such as API support. This is what i am using to discern the differences.

That does not mean it covers all bases, because not all ports carry the same improvements or features. This is why you need a common denominator in my eyes, something which an outsider can understand.

Share this post


Link to post

Weird, it's been 1 hour and I have not been notified about your reply, this forum gets weirder by the day, never seen anything like it...

 

Oh I got it now, thanks for clarifying. I did not suggest for you to change the name of LZdoom, did someone else say that? Anyway, I think the name is fine and at this point it's a fairly recognized brand, people are finding about it more and more, and I love how all of them compliment the excellent job you did, thanks again dude. Without all of this many of us would not be able to enjoy these newer mods.

 

So the final consensus is: first try LZdoom for the latest compatibility with mods and scripts and all that jazz... and have ZDoom32 on the side to still play mods with the vintage Software renderer looks (that bring more atmosphere to certain maps...)

People can download ZDoom32 here (the most updated version until now is v2.8.5c (GL 1.9.4) dated SEP 29 2019):

https://github.com/drfrag666/gzdoom/releases/download/2.8.5c/ZDoom32_2.8.5c.zip

And I'm also hosting a mirror here in case anything happens:

https://www.dropbox.com/sh/8m9wrub7k42p22z/AAC8-H3Avpn2qZ1Y9ef3xxV8a?dl=0

Pre-configured with WASD controls and "vanilla" looks, windowed, FPS capped, Hexen inventory controls, etc.

Share this post


Link to post
28 minutes ago, Redneckerz said:

No, it isn't. What is confusing is releasing a new version that changes the scope of the original version, yet retains the same name.

I don't think that's the issue, for me it seems like you are overanalyzing it. I was just asking which ports are the most updated, since it is not clear from the Github page which one came first.

The names are just fine, no need to change names. So the two main horses in the race are LZdoom and ZDoom32, these ones should be at the top of the list on the Github description and even better if provided with direct download links. That alone will make it easier to read.

 

It's enough that the guy puts this massive work out there. And let's be frank, he has to work hard on this because the others involved are doing a shitshow of a job alienating users from older GL versions.

I said this before: OpenGL code (when done properly, like all the other games out there...) is designed to be backwards compatible, that's the whole premise of OpenGL in the first place. When we look at projects like Darkplaces and Quakespasm, Yamagi Quake2, etc etc, we don't see issues like these, because they contain real OpenGL code, and not just a mishmash of GPU-model-specific workarounds.

The code in gzdoom is being developed to fit into the developer's GPU card, and not into the OpenGL standards themselves. That's why it suddenly didn't support 2.0 anymore. Frag doesn't have to take the beating for them. If anything, Frag just proved to everyone that making a portion of the code still compatible with 2.0 is possible (just like every other piece of software in the market) but people miss what's in front of their noses everytime. If people want to make Doom look like a different game, or don't want to do the entirety of their jobs, then simply pass the torch. Frag is not on the blame here. He is not the one closing down threads on the Zdoom forums from anyone asking for help with an error message that says "Could not initialize opengl"... Amidst all of this, why don't they work with the DirectX 9 standard? Wouldn't that make everything much easier and make it compatible across the board? OpenGL at this point is showing to be a convoluted language to work on.

 

edit:

I'm fine if LZdoom only gets monthly releases and ZDoom32 gets one major release every 6 months, no problem with that... Focus on LZdoom which is the main horse on the race.

Share this post


Link to post
15 minutes ago, DwarfCleric said:

I don't think that's the issue, for me it seems like you are overanalyzing it. I was just asking which ports are the most updated, since it is not clear from the Github page which one came first.

If you re-read my reply, you would find this is addressed towards drfrag. The addresation to your part consists of a simplified descriptor of the various ZDoom versions, based on your questions: ''So, to end all confusion, what is the fork that allows me to load recent PK3 mods, has the low-spec optimizations like "draw distance" and is the more recent out all of these?'' and ''Where can I find it? Which one is the more recent besides LZdoom?''

Quote

The names are just fine, no need to change names. So the two main horses in the race are LZdoom and ZDoom32, these ones should be at the top of the list on the Github description and even better if provided with direct download links. That alone will make it easier to read.

The thing is that LZDoom's next version (as i understood it) will change things rather significantly, but they retain the same name.

 

Quote

The code in gzdoom is being developed to fit into the developer's GPU card, and not into the OpenGL standards themselves. That's why it suddenly didn't support 2.0 anymore.

If you have any addresations towards @Graf Zahl, target him directly.
 

Quote

If anything, Frag just proved to everyone that making a portion of the code still compatible with 2.0 is possible (just like every other piece of software in the market)

I would love for Wolfenstein 2009 or Doom 2016 to be GL 2.0 compatible! But they don't.

Quote

Frag is not on the blame here. He is not the one closing down threads on the Zdoom forums from anyone asking for help with an error message that says "Could not initialize opengl"

Please keep such unrelated meta-critique out of this thread.

 

....Why am i so reminded of your previous attempt at doing this lambasting/chastizing. Please keep that out of here.

EDIT to respond to your recent additions:

15 minutes ago, DwarfCleric said:

Amidst all of this, why don't they work with the DirectX 9 standard? Wouldn't that make everything much easier and make it compatible across the board? OpenGL at this point is showing to be a convoluted language to work on.

Due to the way the Doom renderer works, along with DX9 not being an open API (and an outdated one, at that), you will find that most accelerated source ports target OpenGL, such as GLDoom, Legacy, Doomsday, Risen3D.

There are a few D3D ports out there, but they are practically non existent due to their non-portability towards other OS'es or other platforms in general (Linux does not have an direct DX equivalent, for instance).

Edited by Redneckerz : Later addition by Cleric.

Share this post


Link to post

OK, so let me volunteer to take off some of the weight off the guy's back. I'm writing the description for the Github page now and if others think it reads nice it gets used, so you don't have to put even more work into this, for people to not even donate when you needed the most. (if my currency was dollars or euros I would be able to donate, but until them I'm even worse in that aspect of the whole circus we live in... 5 bucks for me mean almost an entire day of labor... I didn't design the rules of the game...)

 

Here it goes... I think this would be a dummy-safe description...

 

LZdoom - the most updated in terms of compatibility with mods, try this one first if you were not able to load gzdoom in your machine

(insert download link here...)

ZDoom32 - the second most updated, this one allows you to play most of the recent mods while using the old school renderer. This is recommended for all the original games and older maps (Hexen, Heretic, Doom1, Doom2, TNT, Plutonia)

(insert download link here...)

ZDoomLE - targets older hardware than ZDoom32 (but not as much as Classic) OpenGL 1.4 compatible

(link optional...)

ZDoomClassic - for even older hardware and compatible with Windows 95/98 (example: older laptops that don't allow upgrades and such)

(link optional...)

 

Spoiler

It's kind of a shame that we even have to do this, kids these days have brains that can't seem to understand how to run a game without single-clicking the Steam button, things got weird...

 

Share this post


Link to post
7 minutes ago, Redneckerz said:

The thing is that LZDoom's next version (as i understood it) will change things rather significantly

LZdoom doesn't have a defined "scope" as you are implying. As far as I comprehend, the single purpose of LZdoom is for everyone that can't load the stock gzdoom app to use LZdoom instead and enjoy the latest mods. It doesn't matter how much changes under the hood. That's not an issue at all.

 

If you want to make these super long replies with multi quotes and all, do it for me, but don't do these for Drfrag, don't force him to read through all that jazz, the guy already gave enough for us. No need to quote every single sentence he wrote. Give the guy a break.

Share this post


Link to post

It's not worth trying to clarify this anymore considering i no longer develop those source ports, unless i want to backport some feature or fix some important bug.

From my GitHub:
 

Quote

 

Some ZDoom based legacy ports with lower system requirements for Windows 9x or later and older hardware. Some branches are mostly discontinued from now on (JUL 10 2018).

  • g3.3mgw branch: A maintenance branch of GZDoom 3.3 compiling with MinGW and running on older non SSE2 cpus while keeping the DDRAW and D3D backends for compatibility. Old 3.4 legacy build, now LZDoom.
  • legacy branch: Official GZDoom 3.5 legacy build for GL 2 hardware.
  • gzdoom32 branch: ZDoom32 is a fork of truecolor ZDoom by dpJudas and Rachael and ZDoom 2.9pre (https://github.com/rheit/zdoom). It's a merge of dpJudas old truecolor branch (SEP 08 2016) and ZDoom master as of DEC 03 2016. Later merged with the GZDoom g1.x branch (APR 24 2016). Runs on Windows 98.
  • glzdoom32 branch: A merge of ZDoom32 with a later GZDoom master (roughly 2.2) from NOV 17 2016 with later fixes.
  • zdoom32 branch: Original ZDoom32 branch without the GL renderer.
  • gzdoomle branch: ZDoom LE (Legacy Edition) is a fork of the ZDoom 2.8.1 maintenance branch (https://github.com/rheit/zdoom/tree/maint) for Windows 98 and old machines. Later merged with GZDoom as of AUG 18 2013, runs on GL 1.2 hardware.
  • zdoomle branch: Old ZDoom LE branch with OpenAL for win95 (released from the ZDOOM-LE repo).
  • zdoomcl branch ZDoom CLASSIC is a fork of ZDoom 2.1.4 for Windows 9x and pentium machines. Later merged with GZDoom 1.0.17 with later fixes and additions.

 

About that early Direct3D renderer/backend it was not that special, randi referred the D3D backend as renderer in the documentation. It's a WIP version of the same thing, later before 2.2 she added more complex shaders and the 2D UI part was drawn in truecolor. You know D3D also supports 2D acceleration right?

It looks different (the same as DirectDraw) and works on modern machines. It's the same in 2.1.8.

Then did i say ZDoom LE already supported GL3 and probably higher? The software sector light mode requires GL3 and was already there and even earlier.

But for me which exact GL version each one requires is not THAT important.

BTW why have you tagged Graf? Do you think he's interested in reading that rant? That's the same old thing as always.

@DwarfCleric You're wrong here. Even when Graf is not really interested in legacy support he was kind enough to add that shaderless legacy render path, he could just have dropped GL2 entirely many years ago. Then he created the legacy/vintage build and sure i was the one maintaining it after that but never considered it my own project. So i see no reasons to complain.

 Besides it's been explained many times now, that's not how it works. The GL2 renderer compromised performance on modern hardware and clearly let's say it was not that great. It was removed in order to add Vulkan support among other things, and Vulkan brings important performance improvements on some modern cards.

Then there are other performance improvements in the modern renderer not possible maintaining that old junk, let's face it not many people are still on GL2 fortunately. Besides those crappy intel integrated cards were partially implemented in software and were very slow (and then there were the crappy drivers).

 Even yourself are complaining about the poor lighting. But GZDoom and LZDoom still have the Carmack software renderer. Is there really a difference comparing that one with ZDoom? ZDoom32 also has a GL renderer and if you use that it will look the same as an old GZDoom.

Edited by drfrag

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×