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

[dpJudas]

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.

[Rachael]

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.

[Nash]

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

[Rachael]

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.

[Rachael]

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

This project is one step closer to its first official release! Nevertheless, a new build has been posted. Enjoy!

[Edward-san]

Hence, let us know about the performance improvements

[dpJudas]

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!

[Kizoky]

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

[Kizoky]

This is how you crash this port with my mod

[Ozymandias81]

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

---

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

[Kizoky]

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

[dpJudas]

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.

[ZZYZX]

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

[Rachael]

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.

[Rachael]

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)