0002544: Sector brightness of 256 breaks 3D Floor and Transfer lighting.

(0013957)
Torr Samaho (administrator)
2015-12-10 21:31

I'm pretty sure that this is a GZDoom 1.8.6 bug that is fixed in the latest GZDoom version. Can you confirm this?

(0013958)
StrikerMan780 (reporter)
2015-12-10 21:50

Yeah, seems fixed in the latest GZDoom.

(0013959)
Empyre (reporter)
2015-12-11 09:00

Wait, is it possible to have brightness > 255? I thought the possible values were 0 - 255.

(0013960)
StrikerMan780 (reporter)
2015-12-11 09:07
edited on: 2015-12-21 21:55

0-256 are valid in (G)ZDoom. Have been for years. Hell, it's valid in Vanilla as well, see:'https://www.doomworld.com/vb/eternity/39584-prboom-and-zdoom-incorrectly-display-light-level-255/ [^]'

(0013964)
StrikerMan780 (reporter)
2015-12-11 23:41

Keep in mind, this IS a regression too. Zandronum 2.0 doesn't exhibit this bug.

(0014007)
StrikerMan780 (reporter)
2015-12-21 05:43
edited on: 2015-12-21 05:53

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

It's fixed in GZDoom 2.0, but messed up still in 1.8.10.

(0014008)
StrikerMan780 (reporter)
2015-12-21 21:45
edited on: 2015-12-23 00:48

'http://puu.sh/m40Rj/28eaa9f9d4.png [^]'
'http://puu.sh/m415Z/3f08d2c9cf.png [^]'

I got a ton of screenshots of the bug happening all over the place. It's rather serious.

One commit that seems related to the bug is this:'https://github.com/coelckers/gzdoom/commit/62fd6c8e7456bb0152881b8b35ba3f76e7ff11fd [^]'

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.

(0014009)
StrikerMan780 (reporter)
2015-12-21 22:17
edited on: 2015-12-22 19:21

Welp, in typical and not at all unexpected fashion I got nothing of use out of reporting it on the ZDoom forums:'http://forum.zdoom.org/viewtopic.php?f=7&t=50195 [^]'

EDIT: Guess that means the bug needs to be fixed here, or Zan needs to be upgraded further to GZDoom 2.1... which, I imagine might split things a lot.

(0014020)
Edward-san (developer)
2015-12-24 13:11
edited on: 2015-12-24 13:13

As mentioned in the zdoom thread, it's fixed with'https://github.com/coelckers/gzdoom/commit/baa775b31c59cdc8a3216a0e366706febc3032ec [^]' , which is in the 2.x branch.

(0014146)
StrikerMan780 (reporter)
2016-01-21 15:29

'http://puu.sh/mE8LY/b39f60b8fa.png [^]'
'http://puu.sh/mE8Pn/54e96bb571.png [^]'

You'd think something like this would be getting more attention, especially something so serious and yet so simple to fix.

(0014151)
Dusk (developer)
2016-01-21 22:20

Stop being so goddamn pushy. Surely Torr will get to this when he has the time.

(0014154)
StrikerMan780 (reporter)
2016-01-22 11:06
edited on: 2016-01-22 11:09

Ever tried watching a video you were anxiously waiting for on an extremely slow net connection? Where for every minute of video, there's 10 minutes of buffering time?

Modding (and testing) for Zandronum is kind of like that right now. For every week of progress, there's at least 10 weeks waiting for something important to get taken care of in the port before any more progress can be made on the part of the modder or tester. The stop-and-go nature gets really tiresome, especially in special cases like this where it wouldn't take more than a few seconds of anyone's time to solve so things could move on.

(Also, shouldn't there be much less worry, about conflicts (if any worry at all) now that there's the Zandronum Sync branch too?)

Anyhow. I'll wait a little longer. While it is a nasty visual issue that will affect a lot of recently made maps, it doesn't crash the game. I've just been holding off on testing runs because I want everyone to focus on testing serious online bugs and I don't want the headache of always explaining the lighting issue to all the inevitable obsessive complainers who won't pay attention to anything else. That, and not being able to see jack shit in some maps does have a legitimate impact, and less of a petty/personal reason.

(0014190)
Torr Samaho (administrator)
2016-01-24 21:13

Quote from StrikerMan780
You'd think something like this would be getting more attention, especially something so serious and yet so simple to fix.

Apparently, not everybody thinks that it's so serious.

Anyway, I backported the fix.

(0014191)
cobalt (updater)
2016-01-24 21:56

Issue addressed by commit 1749f30b2539: - fixed: Light level must be clamped before accessing the distfogtable.
Committed by Christoph Oelckers on Wednesday 31 December 1969 23:59:57

Changes in files:

src/gl/renderer/gl_lightdata.cpp | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

(0014194)
StrikerMan780 (reporter)
2016-01-24 22:54

Thanks.

Almost there, there's still one issue left.

Seems 3D models still remain dark.'http://puu.sh/mImpz/0db7ad2def.png [^]'

(0014196)
StrikerMan780 (reporter)
2016-01-25 00:30
edited on: 2016-01-25 00:30

Attached a test PK3 demonstrating the bug with Models sitting on or below 3D Floors. Only seems to happen in some cases... But I managed to reproduce it here. The monitor on the desk in the back of the room to the left of the spawn shows up as being pitch black, rather than being lit properly.

(0014197)
StrikerMan780 (reporter)
2016-01-25 01:01

Happens in the latest GZDoom. Reported here:'http://forum.drdteam.org/viewtopic.php?f=24&t=6774 [^]'

(0014287)
StrikerMan780 (reporter)
2016-02-01 18:51

The issue has been fixed in these commits:

'https://github.com/coelckers/gzdoom/commit/1ad310e69ba6a63a62359ee4a1644313c0ed35d3 [^]'

'https://github.com/coelckers/gzdoom/commit/2c55dcca27155882221f68f8f101dd0a1d652c1b [^]'

(0014289)
Edward-san (developer)
2016-02-01 20:32

As Graf said in the gzdoom thread, these commits can't be merged as is because of gzdoom 2.x-exclusive changes, unless there's someone who manages to find a hack which could work with our code base...

(0014290)
Torr Samaho (administrator)
2016-02-01 22:01

Let's see if Alexey Lysiuk transfers these to the g1.8 branch.

If you don't mind using the GZDoom 2.x renderer, I merged all changes into our zdoom-sync branch.

(0016435)
Ru5tK1ng (updater)
2016-12-08 02:00

Since it doesn't seem anyone will transfer the fixes, I'll change this ticket's target to zdoom-sync.

(0017161)
Combinebobnt (reporter)
2017-04-16 21:58

tested with r170416-0710

the 3d floors thing looked right in opengl and software

the model wad in opengl showed a pitch black computer model. this probably isn't rigth

(0017172)
StrikerMan780 (reporter)
2017-04-17 17:05

You'd be correct. The 3D Model is supposed to be full bright, not black.

(0021347)
EpicTyphlosion (reporter)
2020-06-02 03:47

This appears to be resolved in 3.0.1, see the attached image.

Since this is the only other bug in the zdoom-sync roadmap section, I would highly suggest this report be changed to resolved or closed.

(0023097)
Ru5tK1ng (updater)
2024-02-28 20:15

Closing based off comment ^

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	Hypnotoad StrikerMan780 Combinebobnt EpicTyphlosion
Opponents:	Razgriz

Notes
(0013957) Torr Samaho (administrator) 2015-12-10 21:31	I'm pretty sure that this is a GZDoom 1.8.6 bug that is fixed in the latest GZDoom version. Can you confirm this?

(0013958) StrikerMan780 (reporter) 2015-12-10 21:50	Yeah, seems fixed in the latest GZDoom.

(0013959) Empyre (reporter) 2015-12-11 09:00	Wait, is it possible to have brightness > 255? I thought the possible values were 0 - 255.

(0013960) StrikerMan780 (reporter) 2015-12-11 09:07 edited on: 2015-12-21 21:55	0-256 are valid in (G)ZDoom. Have been for years. Hell, it's valid in Vanilla as well, see:'https://www.doomworld.com/vb/eternity/39584-prboom-and-zdoom-incorrectly-display-light-level-255/ [^]'

(0013964) StrikerMan780 (reporter) 2015-12-11 23:41	Keep in mind, this IS a regression too. Zandronum 2.0 doesn't exhibit this bug.

(0014007) StrikerMan780 (reporter) 2015-12-21 05:43 edited on: 2015-12-21 05:53	Doesn't happen in Software mode, seems the OpenGL renderer isn't properly clamping the values, so it wraps back to 0. It's fixed in GZDoom 2.0, but messed up still in 1.8.10.

(0014008) StrikerMan780 (reporter) 2015-12-21 21:45 edited on: 2015-12-23 00:48	'http://puu.sh/m40Rj/28eaa9f9d4.png [^]' 'http://puu.sh/m415Z/3f08d2c9cf.png [^]' I got a ton of screenshots of the bug happening all over the place. It's rather serious. One commit that seems related to the bug is this:'https://github.com/coelckers/gzdoom/commit/62fd6c8e7456bb0152881b8b35ba3f76e7ff11fd [^]' 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.

(0014009) StrikerMan780 (reporter) 2015-12-21 22:17 edited on: 2015-12-22 19:21	Welp, in typical and not at all unexpected fashion I got nothing of use out of reporting it on the ZDoom forums:'http://forum.zdoom.org/viewtopic.php?f=7&t=50195 [^]' EDIT: Guess that means the bug needs to be fixed here, or Zan needs to be upgraded further to GZDoom 2.1... which, I imagine might split things a lot.

(0014020) Edward-san (developer) 2015-12-24 13:11 edited on: 2015-12-24 13:13	As mentioned in the zdoom thread, it's fixed with'https://github.com/coelckers/gzdoom/commit/baa775b31c59cdc8a3216a0e366706febc3032ec [^]' , which is in the 2.x branch.

(0014146) StrikerMan780 (reporter) 2016-01-21 15:29	'http://puu.sh/mE8LY/b39f60b8fa.png [^]' 'http://puu.sh/mE8Pn/54e96bb571.png [^]' You'd think something like this would be getting more attention, especially something so serious and yet so simple to fix.

(0014151) Dusk (developer) 2016-01-21 22:20	Stop being so goddamn pushy. Surely Torr will get to this when he has the time.

(0014154) StrikerMan780 (reporter) 2016-01-22 11:06 edited on: 2016-01-22 11:09	Ever tried watching a video you were anxiously waiting for on an extremely slow net connection? Where for every minute of video, there's 10 minutes of buffering time? Modding (and testing) for Zandronum is kind of like that right now. For every week of progress, there's at least 10 weeks waiting for something important to get taken care of in the port before any more progress can be made on the part of the modder or tester. The stop-and-go nature gets really tiresome, especially in special cases like this where it wouldn't take more than a few seconds of anyone's time to solve so things could move on. (Also, shouldn't there be much less worry, about conflicts (if any worry at all) now that there's the Zandronum Sync branch too?) Anyhow. I'll wait a little longer. While it is a nasty visual issue that will affect a lot of recently made maps, it doesn't crash the game. I've just been holding off on testing runs because I want everyone to focus on testing serious online bugs and I don't want the headache of always explaining the lighting issue to all the inevitable obsessive complainers who won't pay attention to anything else. That, and not being able to see jack shit in some maps does have a legitimate impact, and less of a petty/personal reason.

(0014190) Torr Samaho (administrator) 2016-01-24 21:13	Quote from StrikerMan780 You'd think something like this would be getting more attention, especially something so serious and yet so simple to fix. Apparently, not everybody thinks that it's so serious. Anyway, I backported the fix.

(0014191) cobalt (updater) 2016-01-24 21:56	Issue addressed by commit 1749f30b2539: - fixed: Light level must be clamped before accessing the distfogtable. Committed by Christoph Oelckers on Wednesday 31 December 1969 23:59:57 Changes in files: src/gl/renderer/gl_lightdata.cpp \| 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

(0014194) StrikerMan780 (reporter) 2016-01-24 22:54	Thanks. Almost there, there's still one issue left. Seems 3D models still remain dark.'http://puu.sh/mImpz/0db7ad2def.png [^]'

(0014196) StrikerMan780 (reporter) 2016-01-25 00:30 edited on: 2016-01-25 00:30	Attached a test PK3 demonstrating the bug with Models sitting on or below 3D Floors. Only seems to happen in some cases... But I managed to reproduce it here. The monitor on the desk in the back of the room to the left of the spawn shows up as being pitch black, rather than being lit properly.

(0014197) StrikerMan780 (reporter) 2016-01-25 01:01	Happens in the latest GZDoom. Reported here:'http://forum.drdteam.org/viewtopic.php?f=24&t=6774 [^]'

(0014287) StrikerMan780 (reporter) 2016-02-01 18:51	The issue has been fixed in these commits: 'https://github.com/coelckers/gzdoom/commit/1ad310e69ba6a63a62359ee4a1644313c0ed35d3 [^]' 'https://github.com/coelckers/gzdoom/commit/2c55dcca27155882221f68f8f101dd0a1d652c1b [^]'

(0014289) Edward-san (developer) 2016-02-01 20:32	As Graf said in the gzdoom thread, these commits can't be merged as is because of gzdoom 2.x-exclusive changes, unless there's someone who manages to find a hack which could work with our code base...

(0014290) Torr Samaho (administrator) 2016-02-01 22:01	Let's see if Alexey Lysiuk transfers these to the g1.8 branch. If you don't mind using the GZDoom 2.x renderer, I merged all changes into our zdoom-sync branch.

(0016435) Ru5tK1ng (updater) 2016-12-08 02:00	Since it doesn't seem anyone will transfer the fixes, I'll change this ticket's target to zdoom-sync.

(0017161) Combinebobnt (reporter) 2017-04-16 21:58	tested with r170416-0710 the 3d floors thing looked right in opengl and software the model wad in opengl showed a pitch black computer model. this probably isn't rigth

(0017172) StrikerMan780 (reporter) 2017-04-17 17:05	You'd be correct. The 3D Model is supposed to be full bright, not black.

(0021347) EpicTyphlosion (reporter) 2020-06-02 03:47	This appears to be resolved in 3.0.1, see the attached image. Since this is the only other bug in the zdoom-sync roadmap section, I would highly suggest this report be changed to resolved or closed.

(0023097) Ru5tK1ng (updater) 2024-02-28 20:15	Closing based off comment ^

Issue History
Date Modified	Username	Field	Change
2015-12-10 20:13	StrikerMan780	New Issue
2015-12-10 20:13	StrikerMan780	File Added: 256LightBug.wad
2015-12-10 21:09	Dusk	Summary	[3.0 beta] Sector brightness of 256 breaks 3D Floor and Transfer lighting. => Sector brightness of 256 breaks 3D Floor and Transfer lighting.
2015-12-10 21:31	Torr Samaho	Note Added: 0013957
2015-12-10 21:50	StrikerMan780	Note Added: 0013958
2015-12-11 09:00	Empyre	Note Added: 0013959
2015-12-11 09:07	StrikerMan780	Note Added: 0013960
2015-12-11 09:07	StrikerMan780	Note Edited: 0013960	View Revisions
2015-12-11 23:41	StrikerMan780	Note Added: 0013964
2015-12-21 05:43	StrikerMan780	Note Added: 0014007
2015-12-21 05:53	StrikerMan780	Note Edited: 0014007	View Revisions
2015-12-21 21:45	StrikerMan780	Note Added: 0014008
2015-12-21 21:47	StrikerMan780	Note Edited: 0014008	View Revisions
2015-12-21 21:51	StrikerMan780	Note Edited: 0014008	View Revisions
2015-12-21 21:55	StrikerMan780	Note Edited: 0013960	View Revisions
2015-12-21 22:17	StrikerMan780	Note Added: 0014009
2015-12-22 19:21	StrikerMan780	Note Edited: 0014009	View Revisions
2015-12-23 00:48	StrikerMan780	Note Edited: 0014008	View Revisions
2015-12-24 13:11	Edward-san	Note Added: 0014020
2015-12-24 13:13	Edward-san	Note Edited: 0014020	View Revisions
2016-01-21 15:29	StrikerMan780	Note Added: 0014146
2016-01-21 22:20	Dusk	Note Added: 0014151
2016-01-22 11:06	StrikerMan780	Note Added: 0014154
2016-01-22 11:06	StrikerMan780	Note Edited: 0014154	View Revisions
2016-01-22 11:08	StrikerMan780	Note Edited: 0014154	View Revisions
2016-01-22 11:09	StrikerMan780	Note Edited: 0014154	View Revisions
2016-01-24 21:13	Torr Samaho	Note Added: 0014190
2016-01-24 21:19	Torr Samaho	Assigned To	=> Torr Samaho
2016-01-24 21:19	Torr Samaho	Status	new => assigned
2016-01-24 21:56	cobalt	Status	assigned => needs testing
2016-01-24 21:56	cobalt	Target Version	=> 3.0
2016-01-24 21:56	cobalt	Steps to Reproduce Updated	View Revisions
2016-01-24 21:56	cobalt	Note Added: 0014191
2016-01-24 22:54	StrikerMan780	Note Added: 0014194
2016-01-25 00:28	StrikerMan780	File Added: 256LightBugModels.pk3
2016-01-25 00:30	StrikerMan780	Note Added: 0014196
2016-01-25 00:30	StrikerMan780	Note Edited: 0014196	View Revisions
2016-01-25 01:01	StrikerMan780	Note Added: 0014197
2016-02-01 18:51	StrikerMan780	Note Added: 0014287
2016-02-01 20:32	Edward-san	Note Added: 0014289
2016-02-01 22:01	Torr Samaho	Note Added: 0014290
2016-12-08 02:00	Ru5tK1ng	Note Added: 0016435
2016-12-08 02:00	Ru5tK1ng	Target Version	3.0 => zdoom-sync
2016-12-08 02:00	Ru5tK1ng	Steps to Reproduce Updated	View Revisions
2017-04-16 21:58	Combinebobnt	Note Added: 0017161
2017-04-17 17:05	StrikerMan780	Note Added: 0017172
2020-06-02 03:46	EpicTyphlosion	File Added: Screenshot (2879).png
2020-06-02 03:47	EpicTyphlosion	Note Added: 0021347
2024-02-28 20:15	Ru5tK1ng	Note Added: 0023097
2024-02-28 20:15	Ru5tK1ng	Status	needs testing => resolved
2024-02-28 20:15	Ru5tK1ng	Resolution	open => fixed
2024-02-28 20:15	Ru5tK1ng	Fixed in Version	=> 3.1

Relationships