MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000269Zandronum[All Projects] Bugpublic2011-01-27 14:032024-01-29 15:52
ReporterGez 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version98d 
Target VersionFixed in Version 
Summary0000269: HQnX transparency issue
DescriptionAs explained here, some transparent textures lose transparency with HQnX and the transparency detection system does not handle them. This can be seen with one particular texture of Epic 2. Interestingly, in Skulltag, the phenomenon seems to be a bit different from in GZDoom as it seems the level of brightness (or presence of dynamic lights, at least) on the other side of the linedef has an influence on whether or not the line is transparent. In GZDoom, they were consistently opaque, no matter what.

Here is a gallery of screenshots og the Ogdoad map from Epic 2, taken in Skulltag, and showing the faulty TBAR20 texture, sometimes opaque, sometimes transparent.

Tested mostly with HQ4X, but HQ2X and HQ3X did the same thing too.
Steps To ReproduceUse HQ4X and play MAP28: Ogdoad from Epic 2. Pay attention to the TBAR20 textures whenever they appear. The screenshots can help you find them.
Additional Information
TagsHQnX, OpenGL
Relationships
Attached Files? tbar_test.wad (24,473) 2011-01-28 02:30
/tracker/file_download.php?file_id=141&type=bug
Issue History
Date ModifiedUsernameFieldChange
2011-01-27 14:03GezNew Issue
2011-01-28 02:00Torr SamahoNote Added: 0000883
2011-01-28 02:01Torr SamahoStatusnew => feedback
2011-01-28 02:30unknownnaFile Added: tbar_test.wad
2011-01-28 06:46GezNote Added: 0000884
2011-01-28 06:46GezStatusfeedback => new
2011-01-28 12:30Torr SamahoNote Added: 0000885
2011-01-28 12:30Torr SamahoStatusnew => feedback
2011-01-29 05:00unknownnaNote Added: 0000890
2012-06-09 13:22Torr SamahoCategoryGeneral => Bug
2014-09-07 15:15DuskNote Added: 0010257
2015-06-06 23:44unknownnaSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=7287#r7287
2024-01-29 15:52Ru5tK1ngNote Added: 0023034
2024-01-29 15:52Ru5tK1ngStatusfeedback => resolved
2024-01-29 15:52Ru5tK1ngResolutionopen => fixed

Notes
(0000883)
Torr Samaho   
2011-01-28 02:00   
As already noted in the linked report, this seems to be a bug inside HQnX. I'm not familiar with the inner workings of the algorithm, but could have a look inside. Can somebody make a small example wad that shows the difference between TBAR20 and TBAR04?
(0000884)
Gez   
2011-01-28 06:46   
There is a strange interaction between this bug and dynamic lights. The presence of a dynamic light actor (even not one that is shining) will make the texture transparent if on the same side as the light. (This can be noticed by firing with the pistol on that test map. Use the automap cheat to view actors and you'll see that you leave a static dynamic light actor behind you.) Switch sides and shoot again, now it's the new side that's see-through and since the dynlight actor updated its position the old side no longer is.

You can also try summon objects like the redtorch on both sides and it'll work apparently flawlessly.
(0000885)
Torr Samaho   
2011-01-28 12:30   
Hmm, the presence of dynamic lights should have no influence on the data that the renderer passes to the HQnX algorithm, should it?
(0000890)
unknownna   
2011-01-29 05:00   
Gez is right. I also noticed this behavior while making the test map.
(0010257)
Dusk   
2014-09-07 15:15   
'https://github.com/coelckers/gzdoom/commit/e29fce6951c70e5c2036e6dfc4ccf0fe38f24f00 [^]'
(0023034)
Ru5tK1ng   
2024-01-29 15:52   
GZdoom fix was added in 3.x.