QZDoom - Now merged into GZDoom!

[NecrumWarrior]

I don't really understand how this merge is supposed to work. How is it merging if QZDoom will still exist separately? Is it simply a mixing of features exclusive to QZDoom into GZDoom so they're on the same page? I am confuse.

[Graf Zahl]

58 minutes ago, NecrumWarrior said:

I don't really understand how this merge is supposed to work. How is it merging if QZDoom will still exist separately? Is it simply a mixing of features exclusive to QZDoom into GZDoom so they're on the same page? I am confuse.

The future of QZDoom as a separate port is entirely up to what experimental features are going to be tested next.

From a logistical standpoint this separation of engines makes no sense at all, the only reason it came to be was that otherwise the software rendering advancements could not have been finalized.

 

The current WIP GZDoom already contains all relevant stuff that had been developed for QZDoom, i.e. the true color SW renderer, the softpoly renderer and last but not least thw hardware accelerated OpenGL backend for the software renderer and they also have seen improvements since that merge. My guess is that short term, QZDoom may be used to implement and test some more experimental features, but long term it won't survive as a separate port.

 

Even the separation of GZDoom from ZDoom had always been for logistical reasons, with ZDoom's spotty release schedule and all. But since these reasons no longer come into play, a single unified engine makes more sense.

 

 

[Rachael]

QZDoom may have started out as "the true-color software port" for the ZDoom family, but it has always kept experimental features in the fold. For a long time, SSAO was QZDoom-exclusive, and for a short time the dynamic light shadowmaps were QZDoom-exclusive as well - all have been merged back into GZDoom at one point or another.

 

Sapration from GZDoom is not being done because I want to keep GZDoom from getting cool new features - it's done so that I can put whatever unstable features I want without messing up GZDoom, itself. Sometimes even minor changes and bugfixes that need testing go to QZDoom, first, before they are cherry-picked on top of GZDoom's master.

 

If someone comes along with a huge C++ project and submits a pull request to GZDoom, it most likely will go to QZDoom, instead, for a while, so that the bugs can be ironed out and it can be properly tested before it goes to GZDoom proper.

 

As for what Graf said - QZDoom has probably seen its final major release. I don't see any reason to continue releasing stable builds, at this point, because once something is declared stable enough it probably will be picked up by GZDoom eventually, anyway.

 

So - look forward to GZDoom 2.5.0 (or 3.0)! It will have QZDoom's renderer, plus fixes and improvements since 1.3.0. The QZDoom merge has never killed development of the software renderer - it's just done under the same roof as GZDoom, now.

[kb1]

Version "3.0" is fair for such a huge improvement. Great job!

[Michael92]

QZDoom is the only source port that crashes when Timidity ++ is enabled (not as external exe, but as switched MIDI synthesizer in Windows 7). After a few seconds of starting a map, sound suddenly turns off, then after 1 or 2 seconds I'm back at desktop w/o any notification about the crash. ZDoom and its other derivatives don't have this problem while this MIDI device is enabled. Has sound system been rewritten in QZDoom?

[Graf Zahl]

Yes, in fact there have been some changes to the native Windows MIDI code.

What version of QZDoom are you using, and does this happen in more recent versions of GZDoom as well?

We need to rule out some build error first so please run some test with GZDoom as well. All I can tell you is that Windows's MIDI interface is a horrible mess you only need to look at strangely to make it misbehave.

[Misty]

So,I've played Qzdoom 1.3.0 version in software mode while I tested (not mine) map and I noticed this thing. Also,some other maps sometimes do this thing too in software mode. Now,I'm not sure if my laptop does this or just nodes and other stuff doesn't build properly. Any thoughts? 

[Da Werecat]

This is typical software renderer behavior. Hardware renderer would crop the texture, but when mapping with software renderer in mind, one should be more careful.

[Misty]

I thought my old good laptop makes mess here. I guess I should switch again to hardware render to get everything work properly. 

[Graf Zahl]

If your map is for ZDoom compatible ports you can switch that off through MAPINFO by specifying 'clipmidtextures'.

 

[Misty]

Well,this map is not mine. I just tested it and saw this thing and thought that something is not right. I'll edit my reply that map thread and tell about this. 

[Michael92]

1 hour ago, Graf Zahl said:

Yes, in fact there have been some changes to the native Windows MIDI code.

What version of QZDoom are you using, and does this happen in more recent versions of GZDoom as well?

We need to rule out some build error first so please run some test with GZDoom as well. All I can tell you is that Windows's MIDI interface is a horrible mess you only need to look at strangely to make it misbehave.

This problem only applies to QZDoom, which is 1.3.0.1. The version of GZDoom I am using is 2.4.0 and it didn't occur in prior versions as well. I might try dev build 3.0 soon to see if this happen there as well.

[Graf Zahl]

QZDoom 1.3.0.1 should be the same code base as GZDoom 2.4.

Are you using 32 or 64 bit builds, or maybe different ones for each port?

 

I have heard in the past that some MIDI drivers appear to have problems with 64 bit, but couldn't verify this on my own system yet.

 

[Michael92]

All of these ZDoom derivatives I'm regularly using are 32-bit.

I've tested 32-bit and 64-bit versions of GZDoom's 3.0 dev build. While there's no problem in 32-bit, 64-bit can't indeed detect Timidity ++ Driver as the select Midi device. Workaround for this is external executable (I got it from Zdoom wikipedia as timidity4zdoom2.zip) which luckily runs fine. Actually... this applies same for QZDoom 1.3.0.1 - while it crashes when Timidity is enabled as selected Midi device in Windows, it runs fine with external program.

I wonder if this crash is caused not by the Timidity ++ itself, but by the particular soundfont I'm only using - GUS Pro Patches Lite v1.61 (ULTRASNDPPL161).

[Graf Zahl]

Hard to tell where it crashes when there's no message.

 

[Danfun64]

2 hours ago, Michael92 said:

64-bit can't indeed detect Timidity ++ Driver as the select Midi device.

Have you tried VirtualMidiSynth instead of Timidity ++? What about using external Fluidsynth as discussed here?

[Michael92]

I'd like to try it, but do these synthesizers handle separate patches (.pat), aside from .sf2 format? I can't remember which particularly, but I know there are some synthesizers which don't have this feature. I've got GUS Pro Patches Lite v1.61 in this shape only.

[Graf Zahl]

I'd suggest to avoid the Windows interface anyway. The internal synths normally work better, so Windows is only recommended if you do not have any patches or want to use a different synth than what ZDoom itself has to offer.

 

I've been using timidity.exe with EAWPats for nearly 10 years now, I don't think I'll ever switch to something else.

 

[BigDickBzzrak]

Hi, I've noticed that QZDoom (version 1.2.1, can't download 1.3.0 rn) doesn't render "superposed sectors" properly. In either the GL or the software renderer.

ZDoom 2.8.1, as well as Chocolate Doom, has no problems.

By superposed sectors I mean: https://doomwiki.org/wiki/Making_superposed_sectors

 

Demo wad: http://uploads.doomshack.org/superpo2.wad

(e1m1 slot)

[Graf Zahl]

I believe that comes from rebuilding the nodes, as the duplicate sector apparently gets completely tossed out.

Even in ZDoom 2.8.1 it won't get rendered if the textured automap is switched on. My guess would be the exploit is inherently incompatible with ZDBSP's GL node builder and in that case there's not much that can be done.

 

It also glitches quite badly in PrBoom's GL renderer.

 

 

 

[Rachael]

GZDoom 3.0.0 is now out, officially with the QZDoom merge. -> https://forum.zdoom.org/viewtopic.php?f=1&t=56132

[LuciferSam86]

4 hours ago, Rachael said:

GZDoom 3.0.0 is now out, officially with the QZDoom merge. -> https://forum.zdoom.org/viewtopic.php?f=1&t=56132

Good news, everyone!

 

Aside the merge with QZDoom (which is great), finally you removed FmodEx sound backend and added some zscript goodies.

 

Good job to everyone :)

[MTrop]

(RE: GZDoom 3.0.0)

 

Alright, I'm going to have to be that guy that pisses on the parade.

 

What is the point of the truecolor software renderer when the OpenGL renderer already exists and is infinitely more performant, even on the worst Intel Chipsets and especially at higher resolutions? Is it just for testing new features for the OpenGL pipeline?

 

I get entirely that the 8-bit software renderer was plagued with licensing issues and whatever, but it had behavior that the GL pipeline could never emulate, not to mention that you still had full control over color saturation vis-a-vis COLORMAP tricks, and fog didn't have the problem of always mixing with black-based sector brightness (since it still relied on generated COLORMAPs under the covers).

 

Is an entire rewrite of the 8-bit renderer planned? Is it gone for good?

 

[dpJudas]

The 8-bit renderer is still there. All you have to do is toggle truecolor mode off in the menus. It can even do new tricks now, such as show dynamic lights!

[StalkerZHS]

So I found an issue with GZDoom 3.0.0

[Michael92]

@MTrop

For me, a huge plus of this renderer is the ability to play WADs based on GZDoom in 320x200. Additionaly, one of the features of QZDoom is that dynamic lights can work in 8-bit software.

[fabian]

@Jon Do you think we could get this into Debian, now that it has been relicensed?

[42PercentHealth]

18 hours ago, MTrop said:

What is the point of the truecolor software renderer when the OpenGL renderer already exists and is infinitely more performant, even on the worst Intel Chipsets and especially at higher resolutions? Is it just for testing new features for the OpenGL pipeline?

The fact is, OpenGL only performs better with sufficient GPU support. My box, for one, has the cheapest GPU that money can probably not buy anymore. If I run a vanilla doom level with OpenGL rendering, it lags like nobody's business. But I can run a fairly detail-hefty map without OpenGL just fine.

[Death Egg]

Different strokes for different folks. I've personally always preferred how software looks over hardware, though without the filters openGL doesn't look that bad.

[Bauul]

On 4/30/2017 at 0:34 PM, MTrop said:

What is the point of the truecolor software renderer when the OpenGL renderer already exists and is infinitely more performant, even on the worst Intel Chipsets and especially at higher resolutions?

Lol, you're joking right?

 

My Intel i5-2520M crawls along in OpenGL mode at about 20 fps, but slays the software renderer at a locked 60 fps. True-color software rendering with dynamic lights has become my go-to Doom experience ever since its first QZDoom release.

 

On a more positive note, awesome news @Rachael!  Having GZDoom now successfully cover all rendering modes is a tremendous step forward.  A big cheers to you and the whole team!