 |
Can you provide either a test map, or a gui file and brief instructions for repping it? |
 |
Okay, the attached archive contains a test map and files for a couple of demo overlays used in the map. |
|
|
Thanks v much |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
 |
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 :) |
 |
By the way, right now the "heatHaze" water in the middle of this test map is broken with non-standard RenderScale. That's with 2.10 almost released. |
 |
Duzenko's commit 9848 appears to have resolved the heatHaze issue |
- Anonymous
