View Issue Details

IDProjectCategoryView StatusLast Update
0004214The Dark ModGUIpublic07.11.2015 08:22
ReporterVanishedOne Assigned ToSteveL  
PrioritynormalSeveritynormalReproducibilityalways
Status resolvedResolutionfixed 
Product VersionTDM 2.03 
Target VersionTDM 2.04Fixed in VersionTDM 2.04 
Summary0004214: Underwater GUI overlay drawn over lightgem
DescriptionUnderwater GUI overlays are drawn over the lightgem: this is pretty noticeable if the GUI is guis\underwater\water_sea_01.gui

While this can look quite pretty, it means the overlay affects the apparent brightness of the lightgem. A really dark overlay could even make it hard/impossible to see, e.g. in a tunnel vision effect like this:

windowDef Desktop {
    rect 0, 0, 640, 480
    nocursor 1
               background "textures/darkmod/decals/dirt/stain08"
}
Additional InformationAlso, when I've tried making an overlay using a background material with a vertex/fragment program stage it's removed the gem entirely. For example, with this as a background:

textures/water_source/water_overlay
{
    qer_editorimage textures/glass/glass1
    nonsolid
    {
        vertexProgram colorProcess.vfp
        vertexParm 0 1
        vertexParm 1 0.4
        fragmentProgram colorProcess.vfp
        fragmentMap 0 _currentRender
    }
}

The inventory GUI is unaffected.
TagsNo tags attached.

Relationships

related to 0004084 new Rendercrop -> viewport isn't right 

Activities

SteveL

SteveL

13.09.2015 20:43

reporter   ~0007767

Can you provide either a test map, or a gui file and brief instructions for repping it?
VanishedOne

VanishedOne

13.09.2015 23:29

reporter  

wet.zip (6,097 bytes)
VanishedOne

VanishedOne

13.09.2015 23:31

reporter   ~0007769

Okay, the attached archive contains a test map and files for a couple of demo overlays used in the map.
SteveL

SteveL

14.09.2015 16:19

reporter   ~0007774

Thanks v much
SteveL

SteveL

30.09.2015 19:55

reporter   ~0007821

Last edited: 30.09.2015 20:04

Looks like we have a draw order problem. The inventory always draws last, over the gui overlay, which is good. The player weapon draws before the water overlay, which is also good because it's an object in the 3d world rather than a HUD element. But the lightgem is being drawn before the overlays as you describe, and it's being overdrawn by them.

The heat haze overlay in your middle pool is completely screwed up on my 16:9 monitor. There's a different reason for that, unrelated to the lightgem problem. Let me know if you need it fixing.

I'm not sure whether the lightgem is handled as a 2d HUD element or as an object in the 3d world that travels in front of the player's view. Hopefully an overlay. I'll go find out.

Edit: It's an overlay. Need to search out how the draw order is determined.

VanishedOne

VanishedOne

30.09.2015 20:56

reporter   ~0007822

Cheers. I'd like to fix the heat haze overlay/understand how to avoid making overlays that break for other people, but I'm not using it in any current project so it's not urgent.
SteveL

SteveL

30.09.2015 21:08

reporter   ~0007824

I haven't investigated your heat-haze pool, but I think the problem is specific to using the _currentRender virtual texture underwater. So you're not likely to come across it using any other texture. I already have an open tracker for what I think is the same problem, which I'll link to this one for when I get to it.
SteveL

SteveL

30.09.2015 22:00

reporter   ~0007825

Tested underwater in the seawater pool with fire arrows out and spyglass in the inventory, the gui draw list goes in this order:

_scratch (2 surfaces, probably the blurry doublevision effect we use underwater)
air bar
health bar
light gem (x3 surfaces / draws)
firearrow icon
some text in a "stone" font (x5)
the seawater overlay
spyglass icon
some more "stone" text (x4)
the console

Confirmed: the water draws over the fiere arrow icon and the health/air bars too, but not the spyglass icon. Also, it draws over the text around the weapon icon but not the word "Spyglass", which must be the "stone font" text above.

I'm still not sure what if anything determines the order.
SteveL

SteveL

30.09.2015 22:17

reporter   ~0007826

The order is determined by the "layer" index in class COverlaySys. Looks like it's not being used correctly for the seawater, which should be a world item that sits behind the HUD elements.

Explanation of the sorting system is in OverlaySys.h

I'll pick this up at the weekend when back from my work trip.
SteveL

SteveL

02.10.2015 19:05

reporter   ~0007829

Last edited: 03.10.2015 15:27

COverlaySys defines the layers for overlays as:

    LAYER_UNDERWATER = 0, // Draw the underwater overlay first
    LAYER_MAIN_HUD = 1,
    LAYER_INVENTORY = 2,
    LAYER_OBJECTIVES = 12,
    LAYER_WAITUNTILREADY = 13

where a higher number should be drawn later. The underwater overlay has correct layer 0. But tdm_hud.gui also has layer 0, which means it can be drawn before the water overlay that's also on layer 0. When the HUD gets created in idPlayer::Spawn, the correct layer 1 is requested. Somehow that layer is ending up as zero.

SteveL

SteveL

02.10.2015 19:07

reporter   ~0007830

The error is in idPlayer::Spawn:

if ( m_overlays.createOverlay( 0, LAYER_MAIN_HUD ) >= OVERLAYS_MIN_HANDLE )

The parameters to createOverlay are the wrong way round! The definition is:

int COverlaySys::createOverlay( int layer, int handle )

So the player main HUD is being put on layer 0 and is requesting a specific handle of 1. The list of overlays gets cleared just beforehand, so requesting a specific handle isn't causing clashes with other gui overlays.
SteveL

SteveL

02.10.2015 19:39

reporter   ~0007831

This bug got introduced way back in 2007 in revision 971. Hard to believe it never got called out in the meantime. But for most water overlays, the effect is quite subtle so it's not a nuisance.

Fixed at rev 6547: game/Player.cpp

Also checked other calls to createOverlay for copy+paste errors. There's only 1 and it's ok.
tels

tels

07.11.2015 08:22

reporter   ~0007887

Actually, the code in revision 971 that got replaced already has the bug with setting the layer to 0, it just used a different specific layer ID. So the bug has been there for an even longer time - probably in the original source as well :)

Issue History

Date Modified Username Field Change
11.09.2015 20:54 VanishedOne New Issue
13.09.2015 20:43 SteveL Note Added: 0007767
13.09.2015 23:29 VanishedOne File Added: wet.zip
13.09.2015 23:31 VanishedOne Note Added: 0007769
14.09.2015 16:19 SteveL Note Added: 0007774
14.09.2015 16:19 SteveL Assigned To => SteveL
14.09.2015 16:19 SteveL Status new => assigned
30.09.2015 19:55 SteveL Note Added: 0007821
30.09.2015 19:55 SteveL Target Version => TDM 2.04
30.09.2015 20:04 SteveL Note Edited: 0007821
30.09.2015 20:56 VanishedOne Note Added: 0007822
30.09.2015 21:08 SteveL Note Added: 0007824
30.09.2015 21:09 SteveL Relationship added related to 0004084
30.09.2015 22:00 SteveL Note Added: 0007825
30.09.2015 22:17 SteveL Note Added: 0007826
02.10.2015 19:05 SteveL Note Added: 0007829
02.10.2015 19:07 SteveL Note Added: 0007830
02.10.2015 19:39 SteveL Note Added: 0007831
02.10.2015 19:39 SteveL Status assigned => resolved
02.10.2015 19:39 SteveL Fixed in Version => TDM 2.04
02.10.2015 19:39 SteveL Resolution open => fixed
03.10.2015 15:27 SteveL Note Edited: 0007829
07.11.2015 08:22 tels Note Added: 0007887