Welcome to the ZDoom Forums!

I never rollback any new version so fast!

GZDoom 4.6

Spoiler:

---

GZDoom 4.7

Spoiler:

---

Sarcasm aside, what's going on?

Logan MTM wrote:I never rollback any new version so fast!

Sarcasm aside, what's going on? :shock:

Does this glitch happen with the modern backends (OpenGL or Vulkan), or GLES?

Logan MTM wrote:Sarcasm aside, what's going on?

Hard to tell. Can you post a bug report in the bugs forum and include a minimal example with it (e.g. just a small room with this model in it)?

Well, it seems like in the first run the Render Mode option were set as "undefined". I changed to OpenGL and everything back to normal!
However, "undefined" is supposed to happen?

Graf Zahl wrote:BTW, here's something interesting: Of all the 34 reports so far, not a single one is for hardware not capable of Vulkan, and the only one for 32 bit was my own test call...

I fear it means I wasn't able to send my survey results properly

That aside , it may be just my imagination , but with 4.7 using gles renderer , performance with mods like Guncaster and Final Doomer (Whitemareguy's weapons can be resource heavy ) seem even slightly better than 4.6 . I wonder if it is because of all the various small fixes & improvements involved

Just asking out of curiosity , what are some realistic goals for additions/improvements to the gles renderer in the near future (or for the next stable release) ?

I have read that postprocessing would not be feasible in recent days

I understand the direction GZDoom will be heading in the future is Vulkan , but for ogl renderer , how much of a gap will be between normal ogl and gles ?

Sorry for not being able to express myself properly (not a native English speaker)

Best regards and thanks again for this great release

Oh for the KDIZD bit, is that specifically for the swimming part of the map it fixes?

ClessxAlghazanth wrote:I understand the direction GZDoom will be heading in the future is Vulkan , but for ogl renderer , how much of a gap will be between normal ogl and gles ?

Trying to reimplement features from the OpenGL renderer on GLES might be counterintuitive given that the target for GLES is lower end hardware

Logan MTM wrote:Well, it seems like in the first run the Render Mode option were set as "undefined". I changed to OpenGL and everything back to normal!
However, "undefined" is supposed to happen?

That is strange that the renderer was set to "undefined". That shouldn't happen.

Anyway, the reason I asked which renderer you used earlier confirms my suspicion: this is a GLES-only bug. Because someone reported the exact issue on Discord concerning broken model normals in the GLES renderer. An actual bug report on that will be made later, once I confirmed a few other things (and actually have the time to prepare the testing material)

Nash wrote:

Logan MTM wrote:Well, it seems like in the first run the Render Mode option were set as "undefined". I changed to OpenGL and everything back to normal!
However, "undefined" is supposed to happen?

That is strange that the renderer was set to "undefined". That shouldn't happen.

Anyway, the reason I asked which renderer you used earlier confirms my suspicion: this is a GLES-only bug. Because someone reported the exact issue on Discord concerning broken model normals in the GLES renderer. An actual bug report on that will be made later, once I confirmed a few other things (and actually have the time to prepare the testing material)

Thanks Nash, I made a new bug here which I think is related: viewtopic.php?f=363&t=73417

There was a 'TODO' in the code which as usual, never actually got TO DONE.

emile_b wrote: Thanks Nash, I made a new bug here which I think is related: viewtopic.php?f=363&t=73417

There was a 'TODO' in the code which as usual, never actually got TO DONE.

Thanks so much, sorry I didn't get to it sooner. I'll try to post a simple runnable example in that thread when I get the chance...

Is there any chance that post processing, PBR, etc. will ever be added back? I've got a few projects where it's pretty essential and they look really wrong without it (one of them even had a PBR-based puzzle involving shining light at a certain angle to reveal a hidden message).

You have to accept that those last < 10% of the user base will not be able to access all features mean for modern (fast) hardware.
There's a reason after all why I am constantly checking which kind of support is still needed.

Right now we're in a rather schizophrenic situation with this: 90% of the user base is on modern systems that can run the engine without any effort - but the last remaining 10% have ancient (as in more than 10 years old and underpowered even back then!) systems where compromises have to be made, that includes disabling a few processing intensive features, for some even disabling some standard features like software light mode - this is simply too costly for first generation GL 3 hardware.

The whole point of the GLES renderer is to cut down on features so that it actually runs faster. You start adding everything back and it becomes slow again and it kind of defeats the purpose of being a scaled down renderer... :P

(on top of what Graf said - for said ancient machines, the engine is already not running fast enough even without bells and whistles!)

Would it be possible to make post processing and all that still exist in the other renderers, or make them optional in some way?

No. Postprocessing is also used for better rendition of standard features. Disabling it on modern hardware would only complicate the renderer. Enabling it on GLES or Softpoly is out. Softpoly needs a software implementation for everything and GLES needs to run fast.