QZDoom - Now merged into GZDoom!

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.

Share this post


Link to post
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.

 

 

1 person likes this

Share this post


Link to post

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.

1 person likes this

Share this post


Link to post

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

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post

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? 

Screenshot_Doom_20170417_161535.png

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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

 

Share this post


Link to post

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. 

Share this post


Link to post
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.

Edited by Michael92

Posted (edited)

Share this post


Link to post

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.

 

Share this post


Link to post

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

Share this post


Link to post

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

 

Share this post


Link to post
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?

Share this post


Link to post

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.

Share this post


Link to post

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.

 

Share this post


Link to post

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.

 

 

 

1 person likes this

Share this post


Link to post
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 :)

Edited by LuciferSam86

Posted (edited)

Share this post


Link to post

(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?

 

Edited by MTrop

Posted (edited)

Share this post


Link to post

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!

5 people like this

Share this post


Link to post

@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.

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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!

Edited by Bauul
2 people like this

Posted (edited)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now