The end of ZDoom

Graf: Both points sounds reasonable. Thanks for clearing that up :)

Unwarranted personal discussion split out and deleted.

ZDoom, you will be remembered!!! I'll probably keep using it, as I mostly play wads compatible with vanilla Doom. Also it's my first source port and I only replace it with GZDoom for some mods.

What's the difference between GZDoom and ZDoom? I use GZDoom.

Jonko said:

What's the difference between GZDoom and ZDoom? I use GZDoom.

GZDoom:

• Has an OpenGL renderer (though you can still use the software one if you prefer)
• Is still being developed

Really. This is a bad thread title.
ZDoom isn't DEAD dead. It's just been reborn. The original ZDoom was old, and failing. It died, and from the ashes, it was reborn as QZDoom!

QuirkyKirk said:

Really. This is a bad thread title.
ZDoom isn't DEAD dead. It's just been reborn. The original ZDoom was old, and failing. It died, and from the ashes, it was reborn as QZDoom!

LONG LIVE THE NEW FLESH!

QZDoom is pretty awesome, but eventually its going to be part of GZDoom as I have read here.

Lord_Kane said:

QZDoom is pretty awesome, but eventually its going to be part of GZDoom as I have read here.

Thanks!

Yes, I think the plan is to merge most, if not all, of QZDoom back into GZDoom once certain conclusions have been made. Basically QZDoom contains the following in the nightly builds that needs further evaluation and tweaking:

1. A refactored software renderer (still not entirely completed).
2. A drawergen tool meant to ease the way drawer functions are written (uses LLVM to generate code).
3. OpenGL hardware acceleration on Linux (vid_hw2d) for the software renderer.

While all three are pretty stable in QZDoom master, they also present some risk that needs to be evaluated before getting moved upstream.

For example, it turns out the LLVM dependency causes a lot of trouble on Linux, as some of the main distributions there are shipping broken packages. It may be that the drawergen tool needs to drop this dependency to make everyone happy.

dpJudas said:

It may be that the drawergen tool needs to drop this dependency to make everyone happy.

As I pointed out elsewhere already, it should be enough if the developers can run this tool.

Since this is such a volatile thing my previous suggestion stands:

- separate it into an isolated Github repo.
- let it generate object files for all known supported platforms.
- only include these object files with the main repo and link to them as needed.

Then any normal people have something that just works, and leaves the mess to those who either need to or want to bother with it.

That would work for me, although I'd still keep the tool inside the main repo as it is not very big - just detach its CMakeLists.txt from the main build.

What worries me is how many output files we would need for such a setup. The object file generated is about 3 MB in size. There's also the possibility for it to output an asm file instead, maybe that will reduce the amount of files needed. In any case, I'll try toy a bit more with this a little later.

dpJudas said:

The object file generated is about 3 MB in size.

We're going to need one for each platform. I guess the minimum is 7:

- Windows, Linux and Mac x86 and x64
- Linux ARM
- maybe Mac PPC, if you want to support that, I guess this can revert to 8 bit only as it's an ancient legacy platform.

Any more depends on how many features you want to selectively enable.

I was the one who originally suggested that the Drawergen tool be a part of QZDoom and its building process, although I suppose separating it does have some logic and certainly would make it easier to build on Linux ARM (which - forgive me for saying, but LLVM is a colossal clusterfuck on that platform right now, thanks to Ubuntu).

The main logic for this was - you change one part of the source code, be it compiled by LLVM or by your native compiler, you see the effect of the change immediately. To me, I only see this as being immensely helpful for someone who wants to actually modify the code. Separating the code into building steps only complicates things, and as mentioned would also require storing the .obj files in the repository for every platform - something that itself in my view violates the "open source" creed.

The problems with LLVM as dpJudas has said are not trivial, but going forward I am not really sure what would be the most ideal solution going forward. The drawers still need to be optimized, but at the same time it would be nice to cut LLVM out completely.

The rationale behind including LLVM in the main CMakeLists.txt was based on the assumption that Linux users would type 'apt-get install llvm-dev', the Mac developers 'brew install llvm-dev' and the Windows developers would download a llvm-binaries.zip and extract it into the source directory. That worked as planned for only two out of three. :(

To be perfectly honest, the search logic in CMakeLists.txt could probably be improved to locate the LLVM libraries even for a broken LLVM installation (by not relying on the cmake module from the LLVM project - like the Win32 version doesn't). But it seems there are no active Linux developers around to do this, so I'm going for a solution that makes it more realistic to manage this from Windows. Like the solution Graf is talking about, or just drop truecolor support from the Linux builds entirely if LLVM isn't located.

Eruanna said:

Separating the code into building steps only complicates things, and as mentioned would also require storing the .obj files in the repository for every platform - something that itself in my view violates the "open source" creed.

Very much so. This half-baked solution just screams of an overly-complicated nobody-actually-understands-the-architecture software that is totally unmaintainable. It also actively harms packaging and porting efforts.

chungy said:

This half-baked solution just screams of an overly-complicated nobody-actually-understands-the-architecture software that is totally unmaintainable.

Thank you for the kind words. So what method would you have used to write 115 different drawer functions for the most time critical loop in all of Doom?

Remember, if you use the usual high level solutions (subfunctions, branching, interfaces and templates) then you started playing a dangerous game of testing just how good your compiler really is. In the most time critical function in the program.

I believe my response was about including pre-built object files in a repository. Code generation is good.

Spectre01 said:

QZDoom master race reporting in! I think it's fine if there's one port that provides both software and GL options for players.

QZDoom always crashes for me, which sucks. It's probably because It's a beta version.

"The end of ZDoom" sounds like the name of an epic late-game level. Go make one! For ZDoom.

printz said:

"The end of ZDoom" sounds like the name of an epic late-game level. Go make one! For ZDoom.

Maybe someone could make a zdoom megawad with as many maps as the years of Zdoom. 19?
And as the maps progress, so do the features of the map, corresponding to the year the feature was introduced. So the maps start simple and later maps gradually have slopes, portals, decorate etc.

Very sad to see this happen. ZDoom was one of the best source ports out there.

riderr3 said:

I remember "death" of Edge source port. Some other people bring the development under another name and so on. Open source can bring endless life if people interested.

Alas, the death of Edge was also the end of its community to a degree, I know a few stayed to carry Edge on, but its hay day had been and gone.

The difference thou is that instead of 30/40 hardcore fans, Zdoom fans always seem very fanatical and number over 9000. The community wont go anywhere and its ports etc will fly the flag high for years to come.

Eventually it might find itself relegated due to lack of features but probably not for a while.

All the best Randi!

I wouldn't call ZDoom folks "fanatical", really. It just comes down to port of preference - and at the moment it is the most flexible and has the best editor support. Once that changes, I expect people will flock away from ZDoom to whatever seeks to replace it.

Liberation said:

Alas, the death of Edge was also the end of its community to a degree, I know a few stayed to carry Edge on, but its hay day had been and gone.

No, I don't think the community ever died. There are still people involved with 3DGE that I remember seeing around over a decade ago. It doesn't matter what size the community is. What really matters here is that aside from ZDoom, Eternity, and Doomsday, 3DGE is also incredibly extensive for modding support, versus others who just support the common ACS or DeHacked. I believe that it's always been our golden goose, so to speak.

Fixing all of these bugs and seeing more progress has actually increased the port usage, and spikes interest. Even though the community at the 3DGE forums is of a small number (which actually is in greater numbers at the sister thread at ZDoom.org), we still see many visitors and lurkers (especially at the 3DGE Wiki) who look at the modding and help sections.

As long as someone believes in it, whether it is just me or a handful of people, the port will live on. Shit, the only reason I didn't just continue using the name EDGE was because I was already working on it before EDGE formally died. If I would have known, I would have just kept the name and called it a day. Oh well, 3DGE is EDGE no matter how it's painted. ^_^

ixfd64 said:

Very sad to see this happen. ZDoom was one of the best source ports out there.

Yeah, I guess I'll be even more cemented on the prboom+ side of things in the future :(

I do a lot of Dooming on my laptop, which is a refurbished Sandy Bridge ThinkPad with the Intel HD3000 integrated graphics and running Debian Stretch; most games work pretty handy with it, but I'm finding that GZDoom runs like a slug on it, with a very noticeable pause before even bringing up the game (you're left hanging for several seconds on just the window border ...).

So QZDoom looks like a nice idea, but while it compiles and starts up OK, without the horrible slowness that GZDoom is giving, every time I try to do pretty much, well, anything from the main menu, I get a segmentation fault. Options? The moment I try to access the options menu, BOOM SIGSEGV. Trying to start the game fares a little better, but after picking an episode and difficulty ... BOOM SIGSEGV. :(

Meanwhile ... Classic ZDoom runs just ducky, but it looks like that's that for that branch *sigh*

Amarande said:

So QZDoom looks like a nice idea, but while it compiles and starts up OK, without the horrible slowness that GZDoom is giving, every time I try to do pretty much, well, anything from the main menu, I get a segmentation fault. Options? The moment I try to access the options menu, BOOM SIGSEGV. Trying to start the game fares a little better, but after picking an episode and difficulty ... BOOM SIGSEGV. :(

That sounds... odd. I just cloned the qzdoom repository, compiled it, started it up, and both the options menu and the game ran fine on my Debian jessie system, which has an AMD integrated-graphics chip from 2011. Sounds like launching it from a debugger so you can at least find out where it's crashing might be in order.

Amarande said:

but I'm finding that GZDoom runs like a slug on it, with a very noticeable pause before even bringing up the game

How does it run if you start witb '-glversion 2'?
Does it even start up with OpenGL 3.0?

Coraline said:

As long as someone believes in it, whether it is just me or a handful of people, the port will live on. Shit, the only reason I didn't just continue using the name EDGE was because I was already working on it before EDGE formally died. If I would have known, I would have just kept the name and called it a day. Oh well, 3DGE is EDGE no matter how it's painted. ^_^

Back when I first started working on my game, I was considering using 3DGE to develop it for. I ended up going with GZDoom because of how much more familiar I am with ZDoom-ism and because of how big the ZDoom community is. I'm still keeping a close eye on 3DGE though! I think graphically speaking it might be the best looking Doom port I've seen so far.

Since Graf Zahl is now the de facto developer of Zdoom (now GZ) based ports will there be more features added to GZDoom that wouldn't have otherwise been added before the end of Zdoom?

Graf Zahl said:

Uh, people have been making OGL maps for GZDoom for the last 10 years...

Believe it or not, I've been lurking around this website since it began. Or very shortly afterwards. My Uncle, who worked for Lockheed Martin used to MOD stuff for Doom. I'm fairly sure he helped get Doom running on Linux. I don't have any proof of this. I just know he was pretty l33t and it sounds right based on stuff that he talked about. HaX0r stuff I was and still am ignorant to. He lived with my Grandma while he went to school for advanced mathematics. Unfortunately, he was killed in a motorcycle accident in 2008. My grandma quite literally would know of ZDoom, but I'm sure she wouldn't know of GZDoom. Simply out of the loop. I wasn't sure when GZDoom started for sure, but 10 years makes a lot of sense based on the history I've seen so far (Idgames Archive). I played a very limited amount of DOS Doom. My love of Doom was nourished around November, 1999 when I moved to live with my Grandmother and James (my Uncle) who was only 5/6 years older than me. We played lots of ZDoom on LAN. Lots. For me ZDoom will always hold special place in my heart. I appreciate everything that GZDoom offers, but I almost wish I could still call it ZDoom. I'm sure there's a long convoluded history that I'm not privy of, but through my Weltanschauung ZDoom is the - for a lack of a better word - crowned jewel of Doom - even though I like GZDoom better. I'll admit I'm very ignorant on this topic.

Well that sure is a touching story.

I, too, wish it could continue in the ZDoom name, GL renderer and all. Any time I've brought it up with Randi, though, I was met with silence.