QZDoom (WIP source port fork) (Old thread)

Truecolor ZDoom with extra features and some unofficial/beta GZDoom features.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Libs (Win)] [Repo] [Bugs&Suggestions]

Moderators: Rachael, dpJudas

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

QZDoom (WIP source port fork) (Old thread)

Post by Rachael » Sun Sep 25, 2016 7:06

qzdoom-logo.png
qzdoom-logo.png (63.88 KiB) Viewed 441 times
What is QZDoom?

QZDoom is a continuation of dpJudas's truecolor software rendering, merged with and forked from GZDoom.

Why merge with GZDoom?

Compatibility. It helps with the ever-growing wishlist of features for the port. If it runs on GZDoom, it runs on QZDoom, and hopefully QZDoom will eventually be able to "borrow" some of GZDoom's effects. It is also a goal that if this project is able to inherit enough of GZDoom's features, it will allow GZDoom itself to move forward further than would otherwise be possible since some users will no longer be held back by such a move. This is not intended to replace GZDoom, but rather, to exist alongside it, simply to offer an alternate renderer for development, testing, and playing.

Project Wishlist

These are features that are planned for QZDoom. Not all of them may make it in.
  • Bloom/tonemaps
  • "GL" Lights
  • "GL" Skyboxes
  • Model support (will be done in a similar manner to voxels, so it won't be as good as GZDoom's)
  • True freelook support
  • GZDoom's texture upscaling filters (HQNx, xBRZ, etc)
  • Floor decals
  • Flat&Wall sprites
Screenshots?

Why, yes, we do! But they're kind of basic...
Screenshot_Doom_20160925_012831.png
Screenshot_Doom_20160925_012831.png (582.98 KiB) Viewed 441 times
Screenshot_Doom_20160925_012813.png
Screenshot_Doom_20160925_012813.png (577.47 KiB) Viewed 441 times
Screenshot_Doom_20160925_012805.png
Screenshot_Doom_20160925_012805.png (460 KiB) Viewed 441 times
Screenshot_Doom_20160925_012741.png
Screenshot_Doom_20160925_012741.png (448.86 KiB) Viewed 441 times
Download
VERY IMPORTANT: This is currently considered alpha. More is planned for this project, though it may or may not all happen, depending on if I have the time. Don't expect everything to always work - there will be problems.

Home Page: http://qzdoom.drdteam.org/
Source: https://github.com/raa-eruanna/qzdoom
Builds: http://devbuilds.drdteam.org/qzdoom
Spoiler: old versions
Spoiler: Zen Sarcasm

User avatar
Tiger
Developer
Developer
Posts: 856
Joined: Thu Feb 25, 2010 3:44
Location: United States

Re: QZDoom (WIP source port fork)

Post by Tiger » Sun Sep 25, 2016 19:57

Eruanna wrote:
  • Bloom/tonemaps
  • "GL" Lights
  • "GL" Skyboxes
  • Model support (will be done in a similar manner to voxels, so it won't be as good as GZDoom's)
  • True freelook support
Doesn't GZDoom supports these already? If not, why can't they be merged into the parent project?
Nicholas "Tiger" Gautier

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

Re: QZDoom (WIP source port fork)

Post by Rachael » Sun Sep 25, 2016 20:07

Those points were in direct reference to the software renderer.

If you enable QZDoom's openGL renderer (which is basically just GZDoom) they're all still there. I will not butcher or disable the GZDoom renderer - it will always be there as an option, even if it is vestigial for the purposes of this project. The main purpose of merging GZDoom code was to take advantage of its parsers and structs and reuse them in the software renderer - without creating a big unmergeable and unmaintainable mess in the process.

GZDoom hasn't, and at this point, it's unsure if it ever will support a truecolor software renderer.

If you are using a GZDoom config with QZDoom, you will have to set the following variables in order to use the Truecolor renderer:

Code: Select all

swtruecolor true
vid_renderer 0
and restart.

After more features have been added, I may add a compatibility option that allows QZDoom to lie to older projects (your's included :P) about what renderer it is using, since mod authors putting up "This project uses OpenGL!" can be a bit annoying. ;)
Spoiler: Zen Sarcasm

User avatar
Tiger
Developer
Developer
Posts: 856
Joined: Thu Feb 25, 2010 3:44
Location: United States

Re: QZDoom (WIP source port fork)

Post by Tiger » Sun Sep 25, 2016 20:20

So this project - primarily focuses on improving the ZDoom renderer? About time! :P
Nicholas "Tiger" Gautier

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

Re: QZDoom (WIP source port fork)

Post by Rachael » Sun Sep 25, 2016 20:22

Yes, that's exactly what it does.
Spoiler: Zen Sarcasm

User avatar
Tiger
Developer
Developer
Posts: 856
Joined: Thu Feb 25, 2010 3:44
Location: United States

Re: QZDoom (WIP source port fork)

Post by Tiger » Mon Sep 26, 2016 5:36

Eruanna wrote:After more features have been added, I may add a compatibility option that allows QZDoom to lie to older projects (your's included :P) about what renderer it is using, since mod authors putting up "This project uses OpenGL!" can be a bit annoying. ;)
The biggest problem with the software renderer is the lacking of 3D Slopped Floors. Once and if that is tackled, then such warning messages could be looked at differently. Though, some implementations[1][2] in TGRDM3 and Shadowmaker will suffer greatly into the unknown realm of uncertainty. Perhaps if we had a GetPortName ACS function[3], I can work with that feature better by throwing some exceptions to the environment checks. I am not sure how I could budge on this; if the Software renderer falls through the crack by falsifying its state to circumvent the conditional statement check[4] - I fear that the game will just be too unplayable.
Nicholas "Tiger" Gautier

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

Re: QZDoom (WIP source port fork)

Post by Rachael » Mon Sep 26, 2016 8:56

Ah. 3d sloped floors is a toughie - when I went branch pruning I kept the 3d floors branches to see how it was done in those branches because there were multiple implementations before one was finally decided upon.
Spoiler: Zen Sarcasm

User avatar
Gez
Developer
Developer
Posts: 1393
Joined: Mon Oct 22, 2007 16:47

Re: QZDoom (WIP source port fork)

Post by Gez » Mon Sep 26, 2016 15:55

The 3dfloors2 and 3dfloors3 branches are unfinished attempts at improving on what is in the main codebase. 3dfloors2 is a dead end, 3dfloors3 is the one that ought to be better all around and allow slopes. However with all the reorganizations (portal stuff, floating point rewrite, etc.) they're probably impossible to merge. You'd have to compare them with the ZDoom codebase of their time and then basically rewrite them in the new codebase.

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

Re: QZDoom (WIP source port fork)

Post by Rachael » Mon Sep 26, 2016 18:44

That was exactly what I was hoping to do - learn from them, and see if the existing 3D Floors code could be improved upon.
Spoiler: Zen Sarcasm

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

Re: QZDoom (WIP source port fork)

Post by Rachael » Thu Sep 29, 2016 11:39

New version out. Heretic/Hexen skies now show.
Spoiler: Zen Sarcasm

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: QZDoom (WIP source port fork)

Post by dpJudas » Thu Sep 29, 2016 21:51

Very nice that you fixed the sky code. :)

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

Re: QZDoom (WIP source port fork)

Post by Rachael » Thu Sep 29, 2016 21:58

>_>

I am not sure why you disabled the non-tiling columns. When I put them back, though, I noticed another issue with Hexen's skies - on map11 - something I'll have to look into later. I was just happy to have skies back to start with. XD

Also, I don't know if you saw yet, I responded to your query on the ZDoom forum.
Spoiler: Zen Sarcasm

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: QZDoom (WIP source port fork)

Post by dpJudas » Thu Sep 29, 2016 23:14

The sky code is in such a bad shape that I considered it a victory to see the Doom sky at all. The sky really needs its own drawers. It should also allow the sky to look like the way it does in GZDoom. I really consider the sky rendering in ZDoom to be completely broken. :)

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

Re: QZDoom (WIP source port fork)

Post by Rachael » Thu Sep 29, 2016 23:22

I have been thinking about that, I remember how the Build engine did skies and was impressed with even that. (Shadow Warrior, not Duke Nukem 3D)

It should be relatively easy to do a tangent-reciprocal on each column based on its angle to determine the starting point for each sky, and stretch each column more based on that.

Otherwise - the trigonometric code I had planned for the skybox could also completely replace it, too, or just leave the old sky code for compatibility's sake but use a sphere-mapping system by default.
Spoiler: Zen Sarcasm

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: QZDoom (WIP source port fork)

Post by dpJudas » Thu Sep 29, 2016 23:55

Don't think I've ever played Shadow Warrior. How did the Build engine do its skies?

For QZDoom I was just thinking of using specialized drawers for it. The current sky looks so nasty because it tries to use wallscan+vline to draw the sky, which it can't really do without some really bad hacks. If it is changed to use its own drawer family, it will be much easier to have a setting that change what sampling method it uses, including maybe even the skybox thing you've been wanting.

I might attempt to clean this up a little bit after I'm done with my llvmcompiler branch. Oh and I also need to do some adjustments for the GZDoom SSAO PR. Got a little sidetracked there when toying with LLVM seemed more fun. :D

Locked

Return to “QZDoom”