MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002544Zandronum[All Projects] Bugpublic2015-12-10 20:132024-02-28 20:15
ReporterStrikerMan780 
Assigned ToTorr Samaho 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version3.0-beta 
Target Versionzdoom-syncFixed in Version3.1 
Summary0002544: Sector brightness of 256 breaks 3D Floor and Transfer lighting.
DescriptionIt seems if there's a light level > 255 in a 3D Floor or Transfer Brightness control/target sector, the lighting borks up completely and the sectors turn dark, as if their light level was 0.
Steps To ReproduceDownload and run the attached WAD. The sectors dotted around the map should be green and fullbright. The 3D floor should just be fullbright both above and underneath.

However, thanks to this bug, it seems that they are nearly pitch-black.
Additional Information
TagsNo tags attached.
Relationships
Attached Files? 256LightBug.wad (66,878) 2015-12-10 20:13
https://zandronum.com/tracker/file_download.php?file_id=1701&type=bug
? 256LightBugModels.pk3 (272,082) 2016-01-25 00:28
https://zandronum.com/tracker/file_download.php?file_id=1712&type=bug
png Screenshot (2879).png (706,911) 2020-06-02 03:46
https://zandronum.com/tracker/file_download.php?file_id=2601&type=bug
Issue History
Date ModifiedUsernameFieldChange
2015-12-10 20:13StrikerMan780New Issue
2015-12-10 20:13StrikerMan780File Added: 256LightBug.wad
2015-12-10 21:09DuskSummary[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:31Torr SamahoNote Added: 0013957
2015-12-10 21:50StrikerMan780Note Added: 0013958
2015-12-11 09:00EmpyreNote Added: 0013959
2015-12-11 09:07StrikerMan780Note Added: 0013960
2015-12-11 09:07StrikerMan780Note Edited: 0013960bug_revision_view_page.php?bugnote_id=13960#r8307
2015-12-11 23:41StrikerMan780Note Added: 0013964
2015-12-21 05:43StrikerMan780Note Added: 0014007
2015-12-21 05:53StrikerMan780Note Edited: 0014007bug_revision_view_page.php?bugnote_id=14007#r8333
2015-12-21 21:45StrikerMan780Note Added: 0014008
2015-12-21 21:47StrikerMan780Note Edited: 0014008bug_revision_view_page.php?bugnote_id=14008#r8337
2015-12-21 21:51StrikerMan780Note Edited: 0014008bug_revision_view_page.php?bugnote_id=14008#r8338
2015-12-21 21:55StrikerMan780Note Edited: 0013960bug_revision_view_page.php?bugnote_id=13960#r8339
2015-12-21 22:17StrikerMan780Note Added: 0014009
2015-12-22 19:21StrikerMan780Note Edited: 0014009bug_revision_view_page.php?bugnote_id=14009#r8353
2015-12-23 00:48StrikerMan780Note Edited: 0014008bug_revision_view_page.php?bugnote_id=14008#r8354
2015-12-24 13:11Edward-sanNote Added: 0014020
2015-12-24 13:13Edward-sanNote Edited: 0014020bug_revision_view_page.php?bugnote_id=14020#r8356
2016-01-21 15:29StrikerMan780Note Added: 0014146
2016-01-21 22:20DuskNote Added: 0014151
2016-01-22 11:06StrikerMan780Note Added: 0014154
2016-01-22 11:06StrikerMan780Note Edited: 0014154bug_revision_view_page.php?bugnote_id=14154#r8506
2016-01-22 11:08StrikerMan780Note Edited: 0014154bug_revision_view_page.php?bugnote_id=14154#r8507
2016-01-22 11:09StrikerMan780Note Edited: 0014154bug_revision_view_page.php?bugnote_id=14154#r8508
2016-01-24 21:13Torr SamahoNote Added: 0014190
2016-01-24 21:19Torr SamahoAssigned To => Torr Samaho
2016-01-24 21:19Torr SamahoStatusnew => assigned
2016-01-24 21:56cobaltStatusassigned => needs testing
2016-01-24 21:56cobaltTarget Version => 3.0
2016-01-24 21:56cobaltSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=8539#r8539
2016-01-24 21:56cobaltNote Added: 0014191
2016-01-24 22:54StrikerMan780Note Added: 0014194
2016-01-25 00:28StrikerMan780File Added: 256LightBugModels.pk3
2016-01-25 00:30StrikerMan780Note Added: 0014196
2016-01-25 00:30StrikerMan780Note Edited: 0014196bug_revision_view_page.php?bugnote_id=14196#r8543
2016-01-25 01:01StrikerMan780Note Added: 0014197
2016-02-01 18:51StrikerMan780Note Added: 0014287
2016-02-01 20:32Edward-sanNote Added: 0014289
2016-02-01 22:01Torr SamahoNote Added: 0014290
2016-12-08 02:00Ru5tK1ngNote Added: 0016435
2016-12-08 02:00Ru5tK1ngTarget Version3.0 => zdoom-sync
2016-12-08 02:00Ru5tK1ngSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=9966#r9966
2017-04-16 21:58CombinebobntNote Added: 0017161
2017-04-17 17:05StrikerMan780Note Added: 0017172
2020-06-02 03:46EpicTyphlosionFile Added: Screenshot (2879).png
2020-06-02 03:47EpicTyphlosionNote Added: 0021347
2024-02-28 20:15Ru5tK1ngNote Added: 0023097
2024-02-28 20:15Ru5tK1ngStatusneeds testing => resolved
2024-02-28 20:15Ru5tK1ngResolutionopen => fixed
2024-02-28 20:15Ru5tK1ngFixed in Version => 3.1

Notes
(0013957)
Torr Samaho   
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   
2015-12-10 21:50   
Yeah, seems fixed in the latest GZDoom.
(0013959)
Empyre   
2015-12-11 09:00   
Wait, is it possible to have brightness > 255? I thought the possible values were 0 - 255.
(0013960)
StrikerMan780   
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   
2015-12-11 23:41   
Keep in mind, this IS a regression too. Zandronum 2.0 doesn't exhibit this bug.
(0014007)
StrikerMan780   
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   
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   
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   
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   
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   
2016-01-21 22:20   
Stop being so goddamn pushy. Surely Torr will get to this when he has the time.
(0014154)
StrikerMan780   
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   
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   
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   
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   
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   
2016-01-25 01:01   
Happens in the latest GZDoom. Reported here:'http://forum.drdteam.org/viewtopic.php?f=24&t=6774 [^]'
(0014287)
StrikerMan780   
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   
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   
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   
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   
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   
2017-04-17 17:05   
You'd be correct. The 3D Model is supposed to be full bright, not black.
(0021347)
EpicTyphlosion   
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   
2024-02-28 20:15   
Closing based off comment ^