GPL transition complete.

Posted by on at 18:15
(59) Comments
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.

Deprecating Inventory.DrawPowerup

Posted by on at 15:08
(16) Comments
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.

GZDoom + QZDoom Old Releases

Posted by on at 14:59
(11) Comments
... have now been uploaded to

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!

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. :)

The importance of simple examples in bug reports

Posted by on at 15:59
(7) Comments
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:

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 allExpand 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!

"Why not just take over ZDoom?"

Posted by on at 11:35
(0) Comments
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.

"last official build" in bug reports

Posted by on at 15:24
(2) Comments
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.

About the feature sets of devbuilds and release schedules

Posted by on at 05:46
(24) Comments
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.

ZScript and its impact on SBARINFO

Posted by on at 11:35
(59) Comments
I think that many modders have come to value the power of SBARINFO, but as I had to find out, it comes at a steep price.

SBARINFO is one of the largest subsystems in ZDoom with 150kb source code size - just for the status bar.
It is also a subsystem that requires broad access to the internal game state - state that is about to be gradually transitioned entirely to the scripting side to make it more configurable.

Under these circumstances, SBARINFO will inevitably turn out into a major roadblock, if it won't get sorted out.
This also means that from this point forward I will neither consider any SBARINFO related feature suggestion nor accept any SBARINFO related code submission because any further complication will make things worse.
I think it'd be in everybody's best interest if this was deprecated, all the existing widgets scriptified and then a more flexible scripting framework implemented that ultimately can also be used to run SBARINFO scripts.
I'm sorry if that may cause short term inconveniences but I have to look at the long term roadmap here and when doing this, SBARINFO doesn't really look that great, especially if it gets further expanded.

New Bug Tracking System Installed (Defunct)

Posted by on at 15:23
(88) Comments
If you've come to the ZDoom Forums to report a bug for either GZDoom or QZDoom, you might have noticed that the Bugs and Feature Suggestions forums are now missing. Shock! Actually, they're not missing, but they are currently tucked away into a little niche at the bottom of the forum, as they are in the process of being phased out.

That's because we have a new bug tracker! Eruanna and Graf Zahl have been working together to install MantisBT on the ZDoom website, a purpose-built bug tracker with all kinds of helpful features to make reporting, assigning, handling, and categorizing bugs much smoother than it has traditionally been.

The new ZDoom Bug Tracker can be found here, or by following the [Bugs & Suggestions] link that is currently anchored beneath the ZDoom News forum.

Please report any issues with the bug tracker...using the bug tracker, or by sending a PM to Eruanna.

(Edit by Eruanna: If you have any further issues, suggestions, or requests, please put them on the tracker if possible under the "" project - it would be very helpful, thanks!)

(Another edit by Eruanna):
Xaser wrote:Can we add a note somewhere in the OP (or, better yet, on the tracker itself) warning users that they can't edit issues after they post them? That's a really weird Mantis thing that's gonna trip people up.

This issue is being tracked here: