QZDoom - Now merged into GZDoom!

[Rachael]

Glaice said:

So what's new in 1.2.2 compared to 1.2.1? Is it mostly carryover fixes from the GZDoom port branch?

Yes - it just trails GZDoom's point release which is why I didn't bother announcing it.

[Ex Inferis]

I'm pretty eager to try out this port but i keep getting an error message when i try to extract the download into my destination folder (64 bit version). Running Windows 7 on my system. Any clue as to what is going on/how to get past this?

[VGA]

Nazgul9 said:

I'm pretty eager to try out this port but i keep getting an error message when i try to extract the download into my destination folder (64 bit version). Running Windows 7 on my system. Any clue as to what is going on/how to get past this?

What kind of an error?

Anyway, I suggest installing Easy 7zip and using that to handle all archive formats.

[kb1]

Eruanna said:

There is some minor bit of discussion about them - and their performance - here.

The long and short of it is probably best from something dpJudas said in that thread:
As the poly renderer is a system that I have very little experience with, I am not able to manipulate the code as much as I would like to, least of all to be helpful to anyone - but I do have some ideas that I might try to implement to help with this issue that I can try to implement when I get more accustomed to it (such as possibly marking the currently active portal destination line/sector as some sort of a render skip when viewing it through the portal).

That being said - you can set "r_portal_recursions 1" in the console and it will speed up rendering quite a bit on portals. Not ideal - but it does demonstrate the issue that dpJudas mentioned to me.

You might want to check out the latest DelphiDoom. It's got an innovative polygon clipping algorithm currently being used for 3d floors. Apparently it prevents overdraw by doing proper clipping on the otherwise overlaid polys. Not sure if that will help your portal recursions, but, if you're doing actual polygon rendering, it might provide some chances for optimization.

[Mr.Rocket]

Hi,

This probably should have been asked in the Gzdoom or Qzdoom forum.
But just a quick question about brightmaps and transparent textures.
I'm currently working on a large texture project and there's a few textures in png format with a white background which holds transparency properties and my plan is to add a brightmap texture as the texture image art work has a couple lights in it that should light up.

That said, I'v added a brightmap and added my scripts etc in so said parts of the texture now light up, which is fine, however the background part of the texture tends to show up with a faint white translucent background.

---

This is how I received the original texture, but my more typical way of creating textures like this is in tga format, and simply adding an alpha channel.
But because I received the texture from 3rd party, it is my best intention not to make any modification to the original.

So question is, do png textures with transparent properties have any restrictions with brightmaps that I should know about? before continuing with png as its default format.

Opengl is the primary render of course as I'm doing brightmaps. But I should throw this out there, in software render the transparent background looks fine. But again in Opengl I have that white translucent background, which is the reason for my question.

Thanks!

[Graf Zahl]

Fully transparent pixels do not get affected by brightmaps because it's the main texture's alpha that's getting used.

[Mr.Rocket]

So then I gather that the original png texture has not a full alpha channel?

In software the texture background is indeed transparent, but in opengl the what should be transparent, shows up with a dim white translucent background, instead of transparent.

[Graf Zahl]

This sounds like the supposedly transparent parts have an alpha that's slightly above 0, in which case the brightmap gets applied.

[Mr.Rocket]

Ah, understood.
I'm just going to create a new version of the texture with new name in tga format so I can properly apply the alpha channel and go from there.

Thanks!

Edit:

Yep as said above, created a new version of said texture with a proper alpha and no problems with a transparent texture with brightmap added.
And here I thought it was a problem with png transparency along side a brightmap.

Being a png though I suppose it would always keep the properties and there was no visible way to change that, aside from what I had to do, new name, an actual alpha channel in tga format.


Thanks again, Cheers

[Linguica]

OK, this derail is over. No more flamewarring over compression formats, ffs.

[Mr.Rocket]

Aside from the somewhat important questions I had, that was, cough.. sort of the idea.
Cough.. hmm must be coming down with something. :)

Anyway, QZdoom!


Cheers

[Rachael]

Well - dpJudas has struck again.

In QZDoom's latest dev build, the bridge scene in Frozen Time is now playable in the software renderer (provided you have a decent enough processor).

[Linguica]

Nice, what sort of optimization did he do?

edit: oh dur right I should just check Github https://github.com/raa-eruanna/qzdoom/commit/4172d70d9564bbdf1a8ed0bfefddd3cd5e790f27

Make Frozen Time rendering 4 times faster by grouping draw segments in batches of 100 (old algorithm processed 32000 draw segs per sprite!)

[printz]

I'm playing QZDoom and I see different light fading compared to vanilla Doom:

QZDoom


Vanilla Doom 2


The frontmost trooper is too dark in QZDoom.

What's the meaning of 'Q'?

[Rachael]

Q was a letter before ZDoom that was not yet taken.

It coincides with a feature suggestion that was made in 2010 for a feature request that was [No]'d by Graf - which ironically enough, had very similar goals in mind except it was about merging in Quake's engine.

However, I was running out of "cool sounding letters" to use, so despite the fact that someone came up with it before (and it was a dead idea anyway) I decided to use that name.

[dpJudas]

printz said:

I'm playing QZDoom and I see different light fading compared to vanilla Doom:

I'm not too surprised that they don't fully match given there's the following statement in ZDoom (which defined the light values used in QZDoom):

/ Lighting.
//
// [RH] This has changed significantly from Doom, which used lookup
// tables based on 1/z for walls and z for flats and only recognized
// 16 discrete light levels. The terminology I use is borrowed from Build.

And this:

// Convert a light level into an unbounded colormap index (shade). Result is
// fixed point. Why the +12? I wish I knew, but experimentation indicates it
// is necessary in order to best reproduce Doom's original lighting.

Why this was changed from vanilla I have no idea. You'd have to ask Randi about that. Or maybe someone else on the forums knows - it is from before I did any work on this codebase.

There's also the detail that the palette version maps to the closest colormap level for a given light, while the true color version is able to use the exact level chosen. That could in some situations make things appear brighter or darker than in palette mode. I'm not sure if this explains it, but it could be checked by switching to palette mode (set swtruecolor cvar to false).

[Jon]

Do you guys have any plans regarding the licensing of QZDoom now ZDoom has stopped development? (I need to catch up generally with the people/projects/plans to move to GPL that existed prior to Randi's announcement and see what's going on with all the forks)

[Graf Zahl]

It still cannot be done without removing some functionality but it's on the list.

[Jon]

Graf Zahl said:

It still cannot be done without removing some functionality but it's on the list.

Thanks, I want to ask more about this so I'll open a new thread rather than hijack this one further :)

[Jon]

Using boom type 242 for palette changes seems to be broken. Is there another way to achieve the same thing in QZDoom at the moment (ideally that will be ignored/not break my PWAD in other ports), or is this on the TODO list to fix?

[Rachael]

First I will need an example map. Second, issues such as this need to be posted on the tracker because there's a high chance that I will forget about this issue before I have a chance to look at it. Thirdly, I am not even sure ZDoom supported it to begin with. If it did, then it will be a somewhat higher priority for this to be fixed but I can't make any promises.

[Jon]

Rachael said:

First I will need an example map. Second, issues such as this need to be posted on the tracker because there's a high chance that I will forget about this issue before I have a chance to look at it. Thirdly, I am not even sure ZDoom supported it to begin with. If it did, then it will be a somewhat higher priority for this to be fixed but I can't make any promises.

OK no problem. It's my old E1M1 from Freedoom, I'll build a test PWAD and open an issue. I'm 90% sure (but not certain - and will check) that ZDoom handled it. Edit: GZDoom handles it.

[Graf Zahl]

Rachael said:

Thirdly, I am not even sure ZDoom supported it to begin with. If it did, then it will be a somewhat higher priority for this to be fixed but I can't make any promises.

ZDoom has always properly supported this feature.

[Rachael]

Jon said:

OK no problem. It's my old E1M1 from Freedoom, I'll build a test PWAD and open an issue. I'm 90% sure (but not certain - and will check) that ZDoom handled it. Edit: GZDoom handles it.

How old is it? I just tried a pre-vanillification Freedoom (using ZDoom 2.8.1) and didn't notice any custom colormap sectors.

EDIT: Was finally able to find something. I downloaded FreeDoom 0.6.4 and discovered the problem. Will have to talk w/ Graf and dpJudas about the best way of fixing this.

[Rachael]

Final major 1.3.0 release before GZDoom takes in QZDoom as-is completely. QZDoom will still exist but now with different goals.

 

This is following GZDoom's 2.4.0 release.

• Updated to GZDoom 2.4.0
• LLVM dependency completely removed
• Dynamic Lights almost fully implemented in software renderer
• Shadowmaps for OpenGL

Download

• 64-bit Windows
• 32-bit Windows
• Mac OS X
• Ubuntu 64-bit
• Ubuntu 32-bit

Edited March 22, 2017 by Rachael : Yes, we have an apple! And Ubuntus, whatever we find those to be!

[LuciferSam86]

A new version of QZDoom and GZDoom? pretty neat :)

 

The work and the passion you are putting on those projects is pretty astounding (for you I mean Rachael, Graf and all the committers)

[Rachael]

Thank you. :)

 

Graf and dpJudas are doing most of the heavy lifting - but a lot of other contributors, including myself, and a few others who appear on the Github repo, contribute where-ever we can.

[DoomKnight1984]

I've completely switched to QZDoom, goodbye ZDoom. 

[PhillMcHogan]

What is QZDoom? Is it like GZDoom? What are the differences? Will it work with openGL version 1.1?

[ReFracture]

Thanks for all you do!