QZDoom - ZDoom with True-Color (Version 1.3.0 released!)

Software projects like source ports (3DGE, Eternity, etc), launchers like ZDL, and other useful utilities belong in this forum.

NOTE: This is NOT a Q&A or troubleshooting forum! This is for active projects only! Please use the General or its subforums for such questions.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.

Re: QZDoom - ZDoom with True-Color (WIP)

Postby dpJudas » Mon Oct 03, 2016 8:15 pm

It was removed because I accidentally had merged it into the truecolor branch at the time. You're welcome to restore it if you want. Overall, I think my version looks better than what zdoom does, but both are visually wrong. The proper way to fix this is to rewrite the sky code entirely so you don't need the stretched skies.
dpJudas
 
Joined: 28 May 2016

Re: QZDoom - ZDoom with True-Color (WIP)

Postby Rachael » Mon Oct 03, 2016 8:42 pm

Done.

It's off by default, though, but I made a menu option for it.

In about 10 or so minutes, binaries will be available with this change in place - I've set my auto-compiler-uploader script to go ahead and do another run.
EDIT: They're up. I pulled 76 because the menu implementation was incomplete, but 77 has it.
User avatar
Rachael
 
Joined: 13 Jan 2004

Re: QZDoom - ZDoom with True-Color (WIP)

Postby Nash » Thu Oct 06, 2016 5:03 am

Are you taking Feature Suggestions? ;P

(not a request, just a "hey here's an idea, would be cool to eventually see it in my life time")

Any considerations for a true decal drawer for flats? As in, a real decal that behaves just like its wall counterpart (client-side, clipped at the edges of the surface, will spread itself across multiple (sloped) surfaces; the full works, basically).
User avatar
Nash
Nash Muhandes [Audio Engineer | Game Designer | Scripting]
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia

Re: QZDoom - ZDoom with True-Color (WIP)

Postby Rachael » Thu Oct 06, 2016 8:49 am

Better to make a topic in the QZDoom forum so it doesn't get lost in the shuffle. That being said, it might be doable, but I'd have to do more research on the flat drawers.
User avatar
Rachael
 
Joined: 13 Jan 2004

Re: QZDoom - ZDoom with True-Color (WIP)

Postby Rachael » Fri Oct 07, 2016 8:00 am

dpJudas worked some awesome magic again this morning and now sprites and masking walls are shown in truecolor. :shock:

This project is one step closer to its first official release! Nevertheless, a new build has been posted. Enjoy! :D
User avatar
Rachael
 
Joined: 13 Jan 2004

Re: QZDoom - ZDoom with True-Color (WIP)

Postby Edward-san » Fri Oct 07, 2016 12:42 pm

Hence, let us know about the performance improvements :D
Edward-san
Mathematics is the language with which God has written the universe. (Galilei)
 
Joined: 17 Oct 2009

Re: QZDoom - ZDoom with True-Color (WIP)

Postby dpJudas » Fri Oct 07, 2016 9:52 pm

E1M1 spawn point using 1920x1080:

New LLVM compiled drawers: 150 fps (6.6 ms)
Old MSVC drawers with SSE intrinsics: 168 fps (5.9 ms)

So the old code still wins. However, there is plenty of room for improvement in the LLVM version as I haven't tried to optimize at all yet. I'm not even sure if I got all the LLVM optimization passes up and running. :)

Edit: swapping two lines of code in the LLVM compilation just brought the LLVM version up to 162 fps! It will win soon enough! :D
dpJudas
 
Joined: 28 May 2016

Re: QZDoom - ZDoom with True-Color (WIP)

Postby KiLerZolika » Sat Oct 08, 2016 6:46 am

I don't really like ZDoom, because of it's outdated Palette that causes my textures look rubbish
Here's some screenies from my mod using QZDoom:

http://imgur.com/gallery/Ldp7e

There's also a game crashing bug, when I noclip into a sector and back, the game crashes, I will do a video of it
User avatar
KiLerZolika
I'm a beacon of knowledge, blazing out accross- BARK BARK
 
Joined: 14 Nov 2011
Location: Around weirdos, I'm the biggest weirdo among them

Re: QZDoom - ZDoom with True-Color (WIP)

Postby KiLerZolika » Sat Oct 08, 2016 7:03 am



This is how you crash this port with my mod
User avatar
KiLerZolika
I'm a beacon of knowledge, blazing out accross- BARK BARK
 
Joined: 14 Nov 2011
Location: Around weirdos, I'm the biggest weirdo among them

Re: QZDoom - ZDoom with True-Color (WIP)

Postby Ozymandias81 » Sun Oct 09, 2016 9:30 am

Added this new QZDoom port to my neverending folder for Doom!
Spoiler:


@Killerzolika
Did you ever tried to check if your issue is related to sounds though?
Just type "noise true" from console and do the same thing you did on the video until you reach that big door... Just wondering anyway.
User avatar
Ozymandias81
Doom is a State of Mind... Out of Control.
 
Joined: 04 Jul 2013
Location: Mount Olympus, Mars

Re: QZDoom - ZDoom with True-Color (WIP)

Postby KiLerZolika » Sun Oct 09, 2016 9:38 am

It isn't the sound that crashing the port
The crashing always happens If you fall from the door, and move to that wood thing next to the door, and go back to the door, and crash
I wonder, if the UDMF format or the rendering is the culprit here

Image
User avatar
KiLerZolika
I'm a beacon of knowledge, blazing out accross- BARK BARK
 
Joined: 14 Nov 2011
Location: Around weirdos, I'm the biggest weirdo among them

Re: QZDoom - ZDoom with True-Color (WIP)

Postby dpJudas » Sun Oct 09, 2016 10:12 am

It is the rendering. I have some other maps where I can consistently get it to crash. It happens since some recent changes to how the drawers work - hopefully I have a solution to it soon.
dpJudas
 
Joined: 28 May 2016

Re: QZDoom - ZDoom with True-Color (WIP)

Postby ZZYZX » Mon Oct 10, 2016 5:20 pm

Eruanna wrote:
  • True freelook support

I remember trying to pull a true 3D software renderer in ZDoom instead of deprecated/removed polymost: https://github.com/jewalky/zdoom/tree/polygon/src/r3d
The code is basically a class wrapper around original code of this ancient renderer written by some random Russian coder who actually knows maths.
It lagged like shit though. Like, complete shit. Especially with high subsector count, not sure what the cause was.
If anyone needs that, might as well try to take and optimize it further (currently it's not optimized at all, since I thought that 2fps for a not-that-complex map is waaaaay too low and abandoned the idea completely).

Although either way I don't know why would someone need a SOFTWARE renderer that has higher system requirements than an OpenGL renderer, which would inevitably happen if you were to implement true freelook aka true 3D.
User avatar
ZZYZX
Alien overlord, maybe
 
Joined: 14 Oct 2012
Location: Ukraine

Re: QZDoom - ZDoom with True-Color (WIP)

Postby Rachael » Mon Oct 10, 2016 5:43 pm

Ultimately, "true freelook" could be implemented in multiple ways, and my idea was initially to simply perspective warp the canvas and then reuse the column drawers to fill in the gaps that it creates on the screen, doing the same at extreme angles for another 180-degree canvas (>60 degrees up or down) and putting them together.

A polygonal method would work, also, and it is the method that GZDoom uses to render OpenGL. In fact, it is entirely possible to use GZDoom's existing vertex structures and overlay a simple software mode triangle drawer on top of it. But then it would no longer be the Doom renderer, it would just be the same system Quake uses to draw its software mode when it doesn't just output it to an OpenGL driver.

Either way, the method is often extremely overthought. It's pretty simple: Doom's 2D vertex system is trivially translated to multiple 3D vertexes. Sector heights and/or sloping parameters dictate the Y-points upon which the 3D vertexes will appear. If putting textured triangles on the screen required massive system requirements, Quake never would have existed until at least 2005 or so.

Each method I described has drawbacks: The perspective warp can be inaccurate, pixely, and slower depending on how the column drawers get abused. The polygonal method would render a lot of existing Doom maps incompatible which breaks one of the basic goals of actually keeping the software renderer as it is in the first place.

But right now, I am far more concerned with getting the bugs out of the system. There are some few critical crash points, as has been pointed out in some of the posts preceding this, and in my opinion it is far more important that those be fixed, than any work being done at all on a polygonal or warping free look system.
User avatar
Rachael
 
Joined: 13 Jan 2004

Re: QZDoom - ZDoom with True-Color (WIP)

Postby Rachael » Tue Oct 11, 2016 10:57 am

New build is up. This one uses an OpenGL canvas to hopefully later on be able to switch between hardware and software rendering on the fly, instead of closing QZDoom. If this is ported back to ZDoom, you'll be able to switch between renderers on GZDoom, as well. :)

--

By the way - QZDoom does include dpJudas's SSAO branch, and as far as I know it is currently up-to-date.

The reason I mention it is because I think it should be tested more widely, and feedback should be given here - with the hopes that someday it will be accepted into GZDoom.

In order to use it, you must do two things:

First, use the included GZDoom renderer. (Can be turned on by adding "+vid_renderer 1" from the command line - using "+vid_renderer 0" later on will turn it back off)

Second, you must actually enable it. (Console command: gl_ssao 1-3, or it's under Options->Display Options->OpenGL Options->Preferences->Ambient Occlusion Quality - or you can use gl_ssao 0 to turn it off)
User avatar
Rachael
 
Joined: 13 Jan 2004

PreviousNext

Return to Software and Ports

Who is online

Users browsing this forum: No registered users and 1 guest