QZDoom - Now merged into GZDoom!

[Blastfrog]

That worked out fine, thanks. :)

In the meantime...



The HUD is not taken as a part of the screenshot, and it seems that too many sprites causes problems.

And yes, 428x220 is a very odd resolution to be using, I'll admit. :P

[dpJudas]

Hmm, that screenshot shows one of the drawers are causing read access violations. Probably one of the sprites causing it, somehow.

About the missing HUD, the poly renderer is marked as experimental for a reason. :)

[Blastfrog]

Either I'm really bad at this (which admittedly, I am), or something's broken. I get this when I try to compile the latest version as of this post:

'dc_destheight': is not a member of 'swrenderer'

[dpJudas]

Which compiler/platform are you building it on? It is compiling here with Visual Studio 2015/Windows and clang/macOS. What file and line number are you getting the error?

[Blastfrog]

VS 2015 on Windows 7. r_thread.h on line 103.

[dpJudas]

Ah, you're doing a debug build. Fixed the compile error.

[Blastfrog]

I've got a couple of renderer requests, dunno how trivial or nontrivial they are, but they seem simple enough to me (with my limited knowledge of programming, anyhow).

1. If the resolution is not a multiple of 8 in either direction, center the buffer instead of aligning it to the upper left corner. This way, the cells will be cut off evenly from the sides, rather than showing the full cells on the top and left sides and leaving the bottom and right sides with tiny slices of the cells.

2. Grab light levels from position 3,3 (lower right corner of upper left quadrant) within the cell instead of 0,0. The intention here is that it's closer to the center of the cell, and would make lighting less uneven depending on the angle you're viewing a surface at.

_____


One thing I'm curious about is how much slower would it be to calculate the light level of every pixel in the cell? I realize that you'd be doing it 64 times instead of once, but are the light calculations quick enough to not make a notable difference?

[dpJudas]

The plan is to calculate the light level per pixel. What it is doing now was just a quick and simple way to get the light roughly right.

About the 8x8 blocks themselves, they will always start in the corner of the buffer. This is for memory alignment reasons where it is important that they remain 16-byte aligned for optimal performance. At some point I'm probably going to force the pitch of the buffer to always be a multiple of 16 or 64 to ensure perfect alignment with a cache line.

Overall, though, you shouldn't ever be able to see where the blocks are. Once the light issue is fixed hopefully you won't be. :)

[Rachael]

Another release is imminent. I've thrown up some release candidates. If nothing major gets reported within the next day or two, these will be promoted to official releases.

q1.1.0 rc1 32-bit
q1.1.0 rc1 64-bit

Notable changes:

• Updated to the very last ZDoom/GZDoom commit before the ZScript merge.
• Lots of stability improvements with the drawer code.
• LLVM code is now compiled directly into the executable rather than at startup. This results in smaller executable sizes, as well as faster startups. The LLVM code is compiled to a Pentium 4 target. If your processor is not compatible, QZDoom will not start. (Not that it ever did before anyway :P)

With this, obviously, it means QZDoom's master branch will now operate from ZDoom's ZScript base.

[Blastfrog]

I notice that portals run extremely poorly in the poly renderer. I have no idea how it's handling them, but I assume that it's rendering the different layers as separate scenes altogether? If that's the case, could there be an option for faster but less flexible portal rendering? I was thinking something like rendering it all as one scene, with the disadvantage that it would make non-euclidean intersections visible in each others' layers, but the advantage that it's done in one pass instead of a whole new pass for every layer.

If it works nothing like that, please disregard my silly suggestion. However, portals are vital to my existing (and future) map designs, so if there's any way to get acceptable performance out of them, I'd appreciate it immensely.

[Rachael]

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:

The main thing making the portal stuff so incomplete is that it doesn't properly restrict what is viewable by a portal. A side effect of that is it often tries to draw half the world, plummeting the frame rate. It also doesn't properly track if a portal has already been seen, often causing it to recursively draw them over and over again until reaching the recursion limit.

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.

[Breeder]

Amazing work!

[programlover]

I have heard that this source port has multithreading support so I tested it with Gzdoom and brutal doom v20b also with holy hell map 4 and it still lags this source port is still not optimized for multithreading support with brutal doom slaughter other that I still love this source port it's awesome!!!

anything new about this source port that I should now about thanks!

[Gez]

The multithreading in QZDoom only concerns the rendering; the game logic is still single-threaded. Whenever there are a lot of actors, it's not rendering that is the bottleneck, it's the game logic.


(The way the Doom engine works, it's not feasible to multithread game logic. If you did, you'd either make demos and multiplayer impossible, or you'd need so much overhead to keep things in sync across the threads that you'd lose the speed advantage of multithreading.)

[Jitan2]

programlover said:

I have heard that this source port has multithreading support so I tested it with Gzdoom and brutal doom v20b also with holy hell map 4 and it still lags this source port is still not optimized for multithreading support with brutal doom slaughter other that I still love this source port it's awesome!!!

anything new about this source port that I should now about thanks!

Are you by any chance a fake programmer that created doom multi core that does not works.

Also does this port accept code that graf zhal might not accept ?

[Rachael]

Jitan2 said:

Also does this port accept code that graf zhal might not accept ?

I am almost as conservative as Graf Zahl about accepting code (though probably not as conservative as he is) - so it really depends on the request. However, being a 3rd generation port (having two direct downstream parents) - I am more willing to experiment and try things. A lot of the decision for approval also comes from whether dpJudas wants the code merged in or not, as well.

Like Graf Zahl, I will take code based on merit and maintainability. If it's clean, commented, and if there is any notable demand for it, you should not have trouble getting it posted. If the code has significant issues, however, or introduces a lot of bugs, I may ask you to clean it up before it gets merged (or even revert the merge if it is already in). There is also a chance it may get upstreamed into a parent port, as well, if it gets accepted.

Also, if the code contains any significant overhaul of any major systems, it may sit in queue longer than short and simple submissions - or may not be accepted at all, if it affects the parent code more than it does QZDoom's own set of code.

[programlover]

Jitan2 No I am not I did not even know about this guy why is this doom community hate him and why does the doom community also don't want doom multi-core source port I don't know why they hate him this is some new news to me I work a full shift and I just got some time lately but confirm this. Thanks.

[Gez]

programlover said:

why does the doom community also don't want doom multi-core source port

I told you why.

Gez said:

The way the Doom engine works, it's not feasible to multithread game logic.

[Rachael]

Nearly forgot to post here. QZDoom 1.2.0 is out. This version integrates GZDoom 2.3.0. Here's a list of changes (most from GZDoom):

• First version with official ZScript support.
  
• Proper rendering processing of large actors
  
• Improved IWAD picker, allowing to choose the active renderer, or autoloading lights and brightmaps.
  
• Multithreaded software rendering
  
• Some improvements to the console
  
• Fixed the pitch issues that were warned about for 2.2.0.
  
• (OpenGL only) Screen space ambient occlusion (SSAO) for the OpenGL renderer, written by dpJudas
  
• (OpenGL only) UDMF-configurable fog density per sector
  
• (OpenGL only) Glowing flats settable through UDMF
  
• (OpenGL only) Proper dynamic light definitions for Freedoom.
  
• (QZDoom only) Software renderer is now compiled into the executable directly. This shortens startup times.
  
• (QZDoom only) First official version that runs on Windows XP. Note that XP is still not officially supported.

Happy new year!

[Spectre01]

Cool. If I downloaded the q1.1.0 rc1 64-bit release from December 6 am I missing anything important from the latest update?

[Rachael]

q1.1.0 does not have ZScript or any of GZDoom's enhancements since its addition.

[Rachael]

Version 1.2.1 released.

This release includes fixes to bring it in line with GZDoom 2.3.1.

Fixes brought in from GZDoom: (list from Graf Zahl's post)

• Dehacked strings were cut off at the end
  
• corrected a few cases where dynamic lights were not correctly set up
  
• default lights for Doom and Heretic are now properly attenuated.
  
• fixed a few issues with the ZScript compiler
  
• fixed potential crash with Doom's boss brain
  
• fixed state validation problem with Dehacked modifications.
  
• fixed a crash with multiplayer games
  
• fixed a few more cases where player sprites became momentarily visible during a portal transition.
  
• made particle translucency calculations more precise

Additional (QZDoom only) fix:

• Fixed a memory allocation error in the software renderer that was causing frame rates to tank.

[Spectre01]

I noticed version q1.2.0 seemed to remove the xBRZ resize mode, which is by far the best one IMO. Is it back in 1.2.1? I'm happy with using the older test version otherwise.

Edit: Changed to 1.2.0.

[Graf Zahl]

That was never removed. Are you sure you just didn't overlook it?

[Spectre01]

I just double-checked 1.2.0 and I'm only seeing Scalex and HQX resize. :S

[Rachael]

This is indeed very strange. You are right that the modes are gone, but the real mystery is why. I checked menudef.zz and there's nothing that says why it should be gone.

[boris]

Just tried it out for the first time, and I can only set resolutions up to 1024x768. Is that normal?

[Rachael]

That's not normal. Have you tried setting "+use_d3d false" on the command line?

[boris]

The problem was that the "aspect ratio" option in the "set video mode" menu was set to "all". Looks like only a finite number of options will be shown and the higher resolutions just drop off at the end. Setting the "aspect ratio" to something like "16:9" shows the desired modes.

[Reisal]

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