Blog

This is in response to BoA adding some postprocessing shaders and making the mod incompatible with current GZDoom.

QZDoom may add features GZDoom does not have, like currently the postprocessing shaders.

If you want to use such features in your mod you always have to be careful! QZDoom calls itself experimental for good reasons. Even if those features may look interesting, there is no guarantee that they may get integrated into GZDoom's mainline, and even less guarantee that they get integrated in exactly the same way as written. It may later be decided that those features may require some changes to work better for both technical and usability reasons.

Unless I have given a clear comment about any such feature they must be considered unstable or incomplete. In the case of those shaders I haven't even reviewed the code yet so I cannot tell how they will be handled.

If you decide to release a mod with such a feature it may easily end up compatible only with the single QZDoom version it was developed against because if GZDoom alters the feature, so will most likely all future QZDooms as well.

It seems to be semi-common practice to replace the engine's main options menu.
As of today this feature is blocked - user mods will not be able to replace the main options menu anymore. Instead a warning will be printed to the console and the menu override be discarded.

The reason this was done is that this menu contains critical settings that must always be accessible. Since the options menu and its submenus expose engine features to the user interface they obviously can change at any time a new feature gets added. This sometimes can result in the addition of a new submenu and the addition or removal of new entries. Any user mod overriding this will be locked to the version of this menu of the time of its making, resulting in false bug reports and usability issues.

As such I deemed it necessary to ensure that the internal menu always gets used. If you absolutely feel you need an option menu for your mod, there's two options:

1. Use 'AddOptionMenu' to add to the end of it.
2. Use a separate 'Game Options' menu accessible from the main menu. This is actually the preferred way to do it because it separates game from engine options more cleanly.

There have been some discussions lately on the forum about how difficult it is to run GZDoom on old hardware.

You might think - "Doom is an old game. All I ever need is Doom." That's fine. Doom can run on old systems. But not GZDoom. The point of GZDoom is to run Doom on modern hardware, using modern rendering techniques that are more efficient on modern computers. It turns out that in many cases, the techniques that are best suited for modern computers are ill suited for, or even entirely incompatible with, old hardware. And inversely, optimizations that made sense on old computers can be counter-productive on modern hardware.

"But I shouldn't need a computer that runs Crysis 5 just to run Doom!" - and you'd be right. If you want to just play Doom on a system that could run the original, "vanilla" engine, then you can still do so and just play Doom with its original engine. If you want, however, to play modern GZDoom mods that push the Doom engine far beyond its original limits while enabling all sorts of effects that the original doom.exe never offered, then you have to realize that your old computer cannot do that. It cannot do that with GZDoom, just like it cannot do that with the original doom.exe. One important thing that needs to be remembered here is that the entire level setup of Doom is extremely hostile towards how modern graphics hardware works. Modern hardware can work best with large meshes that are being processed with a single draw call. Doom is the complete opposite of that: It is rare that a single draw call contains more than 10 vertices but there can be tens of thousands of them on modern and very detailed levels. This will lead to even seemingly 'primitive looking' data requiring more processing time than modern games which have been optimized for the hardware. That is part of why GZDoom can be slower than some of those newer games.

The vast majority of users who use GZDoom nowadays have computers that are at least capable of running games from the ~2012 era (i.e. capable of supporting OpenGL 4.x), and some possibly even newer than that. It would be a disservice to keep catering to users that use systems which are much older than that. Not to mention, it creates a whole lot of code bloat and makes the source tree much bigger than it needs to be. In some cases, keeping support for old hardware in can even make it impossible to implement features for newer hardware because the necessary approaches are mutually incompatible.

Basically what it comes down to is this: Doom is a 1993 game. If you want to run Doom on your 1993 system - by all means, go right ahead. But don't expect a source port that is being coded for modern computers to keep running on that same 1993 system. Times change, people get rid of those old systems, and they want something new. That's what GZDoom is.

Keep in mind that basically all hardware being manufactured in the last 5 years will be capable of running GZDoom with all effects enabled - performance issues nonwithstanding. It will also be capable of running with all non-postprocessing effects enabled on all non-integrated graphics hardware from the last 10 years and on a basic setting for even older systems. The software renderer with the Direct3D backend contains support for hardware up to 14 years of age.

So when we say things like "DirectDraw" is deprecated - that literally means, DirectDraw is going to be removed from the code base soon. If you do not have at least semi-decent pixel shader capable graphics card from 2003 or later, you will have to either keep using an older version of GZDoom, or perhaps look into ZDoom-LE ("Legacy Edition"), which is made specifically for outdated hardware but which, obviously, does not offer the more modern features that you will find in recent versions of GZDoom.

Here are some examples of some enhancements that were made to benefit modern computers, but unfortunately, could not be done likewise for older computers:

• TrueColor renderer was created for hardware-accelerated back-ends, not DirectDraw, where it likely would have run very poorly on modern systems.
• OpenGL 1.x support was dropped during GZDoom's 1.8.x series, and inherently kept out during the later 2.x series, due to severe maintenance overhead in the source code. Several features GZDoom depends on are only available on GL 2.x hardware and working around them is not easy.
• Features get dropped on OpenGL 2.x hardware, for the same reasons. It should also be considered that most effects that were previously done on 2.x hardware but have been dropped require texture duplication because without shader access they cannot be manipulated at real time. An example for this would be the invulnerability effect that has been replaced in both Doom and Heretic with a less faithful but far less resource intensive workaround. On GL 3.x hardware the proper effect can be done with the original texture and a special shader.
• In order to use C++ version 11, which increased source code readability and flexibility, support for Visual Studio 2005 had to be dropped. As a result, Windows 9x is no longer officially supported.
• SSE2-supporting CPU's are now required, because the true-color renderer runs very poorly without it and making the code compatible with older hardware would have involved some serious maintenance headache for a very small number of old systems.
• Assembly instructions were removed from the software renderer because the implementation details of this code made it impossible to use with multithreaded rendering. In general the performance advantage over C++ code compiled with a modern C++ compiler was very slim at best and negative at worst. The downside, of course, is, that on old single-core systems the non-assembly implementation will be slower.
• The "optimized" column rendering, which took advantage of a quirk in older CPU's that provided more efficient memory access, had been removed, again for source code readability - it more than doubled the size of the render code - but the main reason was that it provided no advantage whatsoever anymore on modern hardware - in fact it was slower or at best the same performance as the "unoptimized" version on any machine less than 10 years old it got tested on.

As of now GZDoom is licensed under the GPL.

Over the last 3 days I rewrote the last piece of code, the middle layer of the OPL player to be free of MusLib. This was achieved by picking equivalent code and data structures from Chocolate Doom.

In order to complete the license transition the FMod sound backend also had to be removed. As of now OpenAL is the only remaining option for sound playback.
I have been using the OpenAL backend exclusively for the last few months and so far it hasn't shown any problems, so I am relatively confident that this won't pose a stabilty issue.

Note that no license headers in the source have been changed yet, this will be done over the next few days.

As my work on the status bar code progresses, this function turns out to be somewhat of an obstacle, because it completely hands over control to the actual powerup, of how the powerup's HUD icon gets drawn. Needless to say, this is not good, because it totally prevents new status bars from handling this part differently. The present approach also has other problems that are better dealt with a drawer that is under full control by the status bar

So, as of now, please consider this function deprecated. Unlike other deprecations, this one will render the function inoperable, because there is no way to keep it working while at the same time add a new function that merely queries the item for an appropriate icon to display, which then will be handled under full control by the status bar itself.

I am sorry that this function had to be in the exported interface but this was needed to continue work - only now the time has come to fix this design flaw.

Another part that needs to be considered deprecated is the DrawTexture constant DTA_HUDRules, which is directly related to the same issue. The problem here is simple: None of the low level HUD code is capable of handling arbitrary HUD scales, it's either 320x200 upscaled or completely unscaled (and on high resolutions far too small) graphics. DTA_HUDRules was the main reason why this was basically unfixable, but the newly written status bar drawers, along with the SBARINFO drawers, will be far more easily changed than trying to handle it in the rendering backend.

If you use this draw mode constant, please change your code, because it will not adjust once the HUD scaling gets reworked.

... have now been uploaded to ZDoom.org.

I tried to make this as complete as I could, but there's obviously some files missing. If you have any files, please let me know! Thank you!

https://zdoom.org/files/gzdoom

https://zdoom.org/files/qzdoom

I tried to keep things consistent. The more recent source archives came straight from Github (and I don't see any reason why not to keep those, too, so there they are).

The purpose of this is purely historical interest. They are not meant for normal day-to-day use. (It may also help some folks track down bugs, too...)

The existing ZDoom files are still there, as well.

Big thanks to jengelh (aka Hirogen2) who maintained a Sourceforge repository that I nabbed from for a few of the files, and to NeoHippo and Graf Zahl who contributed the bulk of the rest.

Big thanks to jengelh (aka Hirogen2) who maintained a Sourceforge repository that I nabbed from for a few of the files, and to NeoHippo and Graf Zahl who contributed the bulk of the rest.

Today I want to touch on a topic that I don't think is stressed enough in this community: And it applies, in reality, to every project, not just Doom-related ones, and certainly not just GZDoom and its relatives regarding bug reports: Examples.

A lot of times, someone will post a bug report, which doesn't have a lot of info in it, and is pretty much the equivalent of "hurr hurr it duzint wurk!" These bugs are extremely difficult to solve, and the chances of it even being looked at are far less when you make it more difficult for it to be investigated.

While it is our goal to solve every bug we can, not leaving us with enough information about it is hugely problematic.

Another issue that seems to happen a lot is very complex mods are given as examples, requiring a huge download (and sometimes even a click-maze of advertisements to get through). This not only increases the amount of time required for us to acquire said mod in order to investigate it, but it greatly increases the difficulty of fixing the issue because of the amount of effort required to actually play the mod to get the issue to occur.

Two things really get in the way of fixing a mod: Startup time (with bigger mods) and time taken to reproduce the bug. The reason why this is such a huge issue is because we're not wholly unlike modders, ourselves - except our work requires us to restart GZDoom repeatedly because there is no way to make "live" changes to the running game. To make matters worse, sometimes we have to use debug builds, which are less than half the speed of the builds everyone else uses (that we distribute, both as releases and as devbuilds) - so complex mods are completely out of the question because it literally *is* unplayable for us, not to mention a nightmare to load. Repeatedly.

Here is an example of a GOOD bug report:
viewtopic.php?f=7&t=51976

The example is simple. It is nothing more than a square room that plainly shows the problem. There is no jumping through hoops to get it, it's simple to acquire, simple to run, and the problem shows immediately upon entering the map. This is ideal - and it should take you no more than a few minutes to construct. It doesn't have to be pretty - feel free to use the default textures. We won't judge your mapping skills on it. We'd really like to see more reports like these.

Here is an example of a BAD bug report:

1. Load up WolfenDoom: Blade of Agony with a recent GZDoom build.
2. Go to INTERMAP. Optionally, play through some of the missions until Marlene Dietrich appears.
3. Save your game.
4. Re-load your saved game.
5. The time of day and/or weather may change, or Marlene Dietrich and her audience will vanish.

There are a number of problems with this: First off, this is a huge mod, requiring a significant download in order to investigate. Secondly, it requires us to actually play missions - with an unknown length of time, which is *NOT* good when we have to restart the game over and over again, especially in a Debug build! The worst part is, it's difficult to know just by something random like a change in weather whether we solved the bug or not. I really do not want to see examples like these because they really hinder our ability to investigate them. (The original author was kind enough to whip up a more simplified example - thanks for that, and sorry to use your report as an example, but it is just one of many that are problematic)

Another problem with this is the instructions state "recent GZDoom build." If we aren't able to solve the bug immediately, then what happens is "recent" becomes highly ambiguous - to the point where we discard the bug report because we don't know what version to use. (In fact, it may have already been solved by then) Look in your GZDoom-username.ini file on the top line - it has the following:

Code: Select all • Expand view

# This file was generated by GZDoom g2.4pre-693-g4a87a59 on Sat Mar 11 02:18:13 2017

Use that line to get the game's version number. If you don't know what part we want, just paste the whole line. It's okay! We know what to look for, there.

What it really comes down to is - we're not clairvoyant, and we need YOUR help in order to be able to help YOU! Keep it simple, make it so that we can restart the game over and over again right into the problem until it is solved. That will help HUGELY when we try and fix the bug.

If you do need to provide a big mod, however (and the problem is not feasible in a smaller one), giving console commands (such as player coordinates) or a savegame that warps right to the issue is helpful, also.

Thank you!

Since Graf and company are going to maintain the ZDoom sites; why not take over the project. Hate to see ZDoom itself die out, would be nice to see the three ports merge to one ... [and become] the new official ZDoom as a single port.

This keeps getting brought up, so I figured we, as developers, should respond to this officially and more visibly.

That is not our project to do that with. If Randi wanted that to happen she would have voiced her support of it by now. As it is, the ZDoom repository stands essentially abandoned, pretty much in the same state that it was when Graf first decided to stop pushing to it.

We know Randi has her reasons, but she has not told us, so it's better to just let this issue die. Everyone has a lot of feelings about ZDoom - and I am not an exception to this - I'd love to see that, too.

But GZDoom, also, means a lot to many of us, and Graf is still maintaining that and keeping it alive and kicking.

I know this post won't stop people from asking, but at least now the issue is officially addressed.

I think this needs to be put in a visible place:

I have received several bug reports recently which mentioned the "last official build" without ever mentioning which one that is.
At least one report was referring to ZDoom 2.8.1!

I have to ask everybody, if you can reproduce an issue only after a specific build, please post the actual number of that build!
This is an area where misunderstandings can cause justified reports to get closed or send developers onto a wild goose chase because they look in the wrong place for the problem.

Thank you.

Due to the spotty release schedule it has become common practice to base ZDoom projects on devbuilds, essentially taking for granted that once a feature was in it was final.

I don't think I need to emphasize that many times this caused problems because the engine got stuck with features that got prematurely exposed and could not be removed again.
So I think it is time to actually define an official policy about this.

I do not plan to continue the ZDoom release schedule. My personal idea of this is to do more frequent releases, at least two minor revisions each year with point releases to address bugs in-between. I already did so with 2.3.1 and 2.3.2, both of these releases are based on 2.3.0 and only contain the actual bugfixes since the first release but not the newly added features.

For the master branch the devbuilds are based on this means that it may switch between two different development styles - feature implementation and release preparation. The current state is clearly feature implementation, and the nature of this means that I may decide on short notice that some code needs to be disabled or removed. I will announce once I switch to release preparation.

While it should be perfectly fine to develop a new project based on devbuilds, anyone doing so has to be prepared to make a change to their project, should such a breaking change happen in the engine. What should be avoided is to release a project to the public which requires a devbuild to run. In that case you should better wait until the next release, even if you have to wait for a few months with the release then. I can not and will not address problems that come from releasing a devbuild-based project if it breaks between its release and the next official version. Doing so would make it impossible to undo things that later turn out to be a hindrance to engine development.