When did people start switching from zdoom to gz?

[invictius]

As their default renderer? I really don't remember personally, and I have no idea when the hardware became good enough to make software mode obsolete for most wads designed with software in mind. I just recall being amazed by dynamic lights in 2000 (zdoomgl I think!) but it crawling on my voodoo 3.

[Rachael]

Actually - right around the time GZDoom launched, it was already a big hit. The main reason was because of the truecolor rendering that it offered over ZDoom's. At the time, it also supported numerous other features not present in the latest ZDoom, such as DECORATE enhancements (weapons were finally definable!), 3D floors, and skyboxes. Of course, there was always a certain group of people who just could not run it, more than there are today, but on the all and whole the majority of people always used GZDoom since it became available. I would say, however, that compared to now, fewer people stuck to the software renderer out of preference over necessity - whereas now among the few software renderer holdouts, that's exactly what they do.

And - one of the big features that it had over ZDoomGL, unfortunately but painfully obviously, was speed. I remember how pleasantly surprised I was when GZDoom outperformed all of the source ports Legacy, Doomsday, and ZDoomGL, which up to that point were the only OpenGL-compatible source ports I had used (and I was not impressed...). I had never heard of prBoom+ at that time, so I never knew that's where GZDoom came from.

[Nash]

If it's any indication, GZDoom is far way more popular today - whenever I see Doom videos posted in non-forum sites like Facebook, Youtube etc - the demographics of "casual gamers" - they're all running OpenGL.

Usually the "I can't run OpenGL" ones I only see on niche/enthusiast/classic forums. The average Joe gamer usually use Doomsday or GZDoom.

Just my observation

[Graf Zahl]

Actually - right around the time GZDoom launched, it was already a big hit. The main reason was because of the truecolor rendering that it offered over ZDoom's. At the time, it also supported numerous other features not present in the latest ZDoom, such as DECORATE enhancements (weapons were finally definable!), 3D floors, and skyboxes. Of course, there was always a certain group of people who just could not run it, more than there are today, but on the all and whole the majority of people always used GZDoom since it became available. I would say, however, that compared to now, fewer people stuck to the software renderer out of preference over necessity - whereas now among the few software renderer holdouts, that's exactly what they do.

That were the times of 2.0.96x where ZDoom was close to dying for the first time. The mere fact that some community members took it upon themselves to improve the engine really speaks volumes about the official state of things (the DECORATE refactor for weapons etc was posted in December 2004, 8 months before GZDoom.) I wonder what might have happened if this stuff hadn't been backported to ZDoom back then...

And - one of the big features that it had over ZDoomGL, unfortunately but painfully obviously, was speed. I remember how pleasantly surprised I was when GZDoom outperformed all of the source ports Legacy, Doomsday, and ZDoomGL, which up to that point were the only OpenGL-compatible source ports I had used (and I was not impressed...). I had never heard of prBoom+ at that time, so I never knew that's where GZDoom came from.

... and ultimately it's something I still find odd. I absolutely cannot determine what specific screwup made ZDoomGL's performance tank this badly. Granted, the renderer itself is 1.5-2x slower than GZDoom but that is merely optimization related and could be fixed. But ZDoomGL must do something that totally stalls the GPU.
But ultimately it was this performance problem combined with the complete lack of render hack support that made me turn GZDoom into a releaseable product.

Usually the "I can't run OpenGL" ones I only see on niche/enthusiast/classic forums.

And it's only a small fringe group even there. Get a sufficiently large group of people and it's inevitable to find some stubborn individual who thinks they are entitled to have modern software running on their dinosaur computer and wouldn't even consider upgrading their hardware.

I only feel sorry for those which are stuck with a laptop based on an older Intel chipset which cannot be upgraded but otherwise wouldn't be bad systems. Those really got screwed over by Intel big time.

[tsukiyomaru0]

A problem I see with GZDoom is that it is not very good with its Software Rendering. It's there, but is not as smooth as ZDoom or Zandronum's Software Rendering, this can be observed by running the Voxel_Test on GZDoom +Vid_Renderer 0, ZDoom and Zandronum +Vid_Renderer 0

Most noticeably: ZDoom and Zandronum runs the Voxel_Test well, with either no loss or no noticeable loss, but GZDoom runs at half of the frames when plenty of voxels are on screen in this case, becoming visibly choppy.

And it's not that they wouldn't even consider upgrading their hardware, some people are flat out bound to HELL by a fried graphics card, PCIe slot or BOTH.

I think GZDoom team should find why ZDoom handles Software Rendering better than GZDoom and implement it.

But I'll leave this here: I'm surprised at how far GZDoom team is going, and how fast too. Back then I wouldn't imagine GZDoom would ever have Software Rendering or even SUPPORT IT at all, but here we are, and I'm satisfied by their attempt.

[Xaser]

A problem I see with GZDoom is that it is not very good with its Software Rendering. It's there, but is not as smooth as ZDoom or Zandronum's Software Rendering

Unless you're referring to the recent releases that feature the 32-bit software renderer, I'd pin this on the placebo effect. GZDoom's 8-bit renderer has always been the same as ZDoom's.

[koverhbarc]

I've been suspecting that too, given my recent tests - GZDoom's (non-truecolor) software renderer does seem slower, but maybe this is _only_ on the new releases that also have the truecolor one, as in fact it should have been the same. It is possible, though, that the difference started much earlier with no one being aware of it or the cause, since for that long time ZDoom was developed in parallel for software-only players.

This is another reason I want to see if Zdoom 2.8.1 LE is going to be a supported branch; as its goal is to continue supporting older configurations (including non-accelerated graphics and Windows 9x) without giving up the gameplay features of 2.8.1 .

Andrew Usher

[dpJudas]

The software renderer in GZDoom is slower on very old hardware, but faster on more recent hardware. ZDoom used assembly and "4 column" drawers that were faster on old CPU architectures (10+ years), but slower newer CPU architectures. GZDoom also takes advantage of multiple CPU cores, when available.

In short: the choice was between making it run faster for 99% of the users, or faster for the remaining 1%.

ZDoom LE still uses the old assembly drawers, so if you have that old hardware I suggest you use that version. It is specifically meant for the needs of such old systems.

[Bashe]

I believe I switched to GZDoom on a full-time basis sometime in 2010. Before that, I actually had both versions but mostly played with regular ZDoom because I like software rendering more, but it eventually occurred to me that I don't really need to have two versions that can ostensibly do the same thing, so I stopped using regular ZDoom altogether.

[koverhbarc]

Thanks again to dpJudas for the explanation. I and the other posters had no idea; at which version of GZDoom was that change made, if you know? And the potential importance of LE is confirmed again.

[Graf Zahl]

And the potential importance of LE is confirmed again.

Keep in mind that the LE will probably never fully feature-update to the current WIP.
Some of the more recent software rendering features depend on the reworked renderer - not for speed but for some of the refactorings that have been done.
There also has never been a fully stable floating point version of the old renderer, many of the transitional bugs have only been fixed in the new multithreaded renderer.
So whatever happens, at some point you will be left behind if you stick to a 15 year old system.

[drfrag]

I don't think ZDoom LE is that important, i'm doing a new release one of this days since i've found a nasty bug introduced in the maint branch (last commit) so A_SpawnItem was broken. I've added the Heretic lava timing bugfix and a few wad compatibility fixes mainly for iwads.
For now i'm fixing the repository to be technically a real GZDoom branch and i'm attempting a merge with GZDoom 1.8.3 (another development branch) with OpenGL 1.2 support. But software would still be the default renderer. I've managed to compile GZDoom 1.8.3 with MinGW and gcc 2.6.1, it was easier than expected thanks to some Blzut3's patches. Now i'm resolving conflicts. If i manage to get this frankenstein working i'll probably drop win95 support and go back to fmod for sound while keeping the old release for win95.
I'm porting back some fixes but the codebase is diverging too much (the maint branch also didn't see the floatification) and about adding new features i see it very complicated.
I've been working secretly on a new big mod for Heretic hopefully to be released one of these days as well.

[koverhbarc]

I guess we'll have to wait some while longer, then, for LE to be really useful. Well, it's not urgent, anyway.

Doom's renderer was never meant to be floating point, but the more precise fixed point. When I wrote a demonstration renderer (which is apparently lost) in DJGPP (the only programming tool I've really ever been comfortable with) I used fixed point without a second thought - and truecolor, of course. It drew walls and flats and moved the camera around and that's as far as I think I got.

Andrew Usher

[dpJudas]

A problem I see with GZDoom is that it is not very good with its Software Rendering. It's there, but is not as smooth as ZDoom or Zandronum's Software Rendering, this can be observed by running the Voxel_Test on GZDoom +Vid_Renderer 0, ZDoom and Zandronum +Vid_Renderer 0

Most noticeably: ZDoom and Zandronum runs the Voxel_Test well, with either no loss or no noticeable loss, but GZDoom runs at half of the frames when plenty of voxels are on screen in this case, becoming visibly choppy.

I missed this part in my last reply. There might very well have been a speed regression when it comes to the voxel rendering compared to ZDoom. The code related to drawing them had to be adjusted in order to make the code GPL compatible, but I can try see if I can speed it up a little bit. No promises, though, as only Ken Silverman understands a certain key function in the whole thing.

Doom's renderer was never meant to be floating point, but the more precise fixed point.

16:16 fixed point is not more precise than 64 bit floating point. The way Doom uses 16:16 it isn't even more precise than 32 bit floats.

[Reactor]

Personally, I decided on GZDoom for several reasons. The first one is obviously the fact that GZDoom can handle flawlessly unpaletted PNG graphics, and believe you me, when I was making graphics for Tristania 3D, forcing beautiful textures to paletted vomit really brought my piss to a boil. Second is the MD3 support - there are many static objects, enemies and projectiles,which simply can't be sprites, as they'll look incredibly fugly. These features are highly important for us.