GZDoom 1.8.10 - Light royally bugged if sector light > 255

[StrikerMan780]

Lighting is royally bugged in GZDoom if a sector's light is over 255 and there's a transfer brightness tag or 3D Floor in the sector.

Details here: http://zandronum.com/tracker/view.php?id=2544

[Graf Zahl]

In case you haven't noticed: Development on the 1.8 branch has been stopped.

[StrikerMan780]

No comment about how it might be fixed? Not even a hint or explanation as to what's truly going on? Nothing helpful whatsoever? It's a rather serious visual bug, and In case you haven't noticed, there's still a ton of people who use 1.8 since 2.1 is unusable for them (despite their system having been more than adequate before), and Zandronum 3.0 beta uses 1.8, and probably will never upgrade to the 2.1 branch for the very reason I stated, and more (such as the inevitable community split).

[edward850]

(despite their system having been more than adequate before)

Being behind not one but two legacy hardware APIs is not "more than adequate" for anything released in 2015.

[StrikerMan780]

Except we're not dealing with something released in 2015. We're talking about something that's had the same general performance and feature set for several years, and ran at stable FPS on such hardware until the sudden change in requirement for GZDoom 2.1. I still have some older rigs sitting around with OpenGL 2.1-capable cards that run everything very well on 1.8. (And I haven't seen anything in 2.1 yet that warrants the sudden jump in OpenGL version other than minor performance gains.)

[wildweasel]

This isn't really a ZDoom problem.

[StrikerMan780]

This isn't really a ZDoom problem.

It's the only place I can reach right now. I'm having difficulties connecting and signing in on the DRDTeam forum at the moment.

[edward850]

Except we're not dealing with something released in 2015. We're talking about something that's had the same general performance and feature set for several years, and ran at stable FPS on such hardware until the sudden change in requirement for GZDoom 2.1. I still have some older rigs sitting around with OpenGL 2.1-capable cards that run everything very well on 1.8.

This has been argued until people have been blue in the face. Thing is, Doom isn't even made for OpenGL*, and thus there is no such standard for how to do a GL interface for it. As such, the rules should be whatever is the sanest, fastest option to accommodate the growing complexity of maps. VBOs are the fastest option going forward, so the pipeline was changed to accommodate that. As it is presently the present as of right now, that indeed made it possible to use a modern API that exists currently as of the current time we are in.

*This complaint only really works if ZDoom suddenly removed its software renderer. That hasn't happened.

[Gez]

You just need to add some clamping in the code that sets the light for extra floors.

Thing is, Doom isn't even made for OpenGL*

Doom itself, no. Some Doom mods, however, do require OpenGL. Go on, play ZanZan in software. Or Paranoid. Or GeneTech. Heck even some mods that technically work (because they're not relying on OpenGL-only effects like models, dynamic lights, sloped 3D floors, etc.) may still end up looking ugly in software (Threshold of Pain, PSX TC).

[Graf Zahl]

@Strikerman:

If you want to keep the old code, find someone who maintains it. I won't do it and that's the end of the story. The reason I removed GL2.x compatibility is not because it was too slow but because the code just became too cumbersome, the entire fixed function render path for these old cards has become a huge clusterfuck that constantly got in the way of a clean implementation, mostly because the shader syntax was changed for GL 3.x and all the good features were not available on the older one.

It's really not my problem that a significant portion of Doom players is sitting on hopelessly outdated computers - any non-Intel hardware not supporting at least GL 3.3 has long been declared 'legacy' and driver support stopped. I also do not have a machine on which I can ensure that this code keeps working because it's not possible to selectively disable the new features on modern hardware. You always get the better implementation silently.
(And any older Intel hardware is so bad it shouldn't even be mentioned here...)

[edward850]

Doom itself, no. Some Doom mods, however, do require OpenGL.

The resources maybe, but the engine is what's relevant here.

[Graf Zahl]

Stop splitting hairs. It's annoying when you start this. One more post of this kind and I'll lock this.

[StrikerMan780]

All I want to know at this point is what's actually happening, and if my guesses are correct as to why this is occurring. That way either I, or one of the Zandronum developers could implement a fix on their own.

Namely:

Doesn't happen in Software mode, seems the OpenGL renderer isn't properly clamping the values, so it wraps back to 0.

and

One commit that seems related to the bug is this: https://github.com/coelckers/gzdoom/com ... 76e7ff11fd

However, that only fixed sprites turning black when on 3D Floors of brightness > 255. That fix should already be in Zan, since it's based on 1.8.6, be that as it may, it still left sector lighting out of the question, which is still messed up. It's fixed in GZDoom 2.1."

[_mental_]

The issue was fixed by this commit. It can be cherry-picked as is for GZDoom 1.x.

[Graf Zahl]

Note: If someone wants to do some maintenance on the 1.8 branch, send me a PM with your Github account and I'll give access.