[r850 and before] Texture manager can't find SKIN faces

[MartinHowe]

Please refer to this thread, for which Graf provided a temporary fix by reverting the change; I have also experienced crashes when using SKINs and SBARINFO at the same time.

The underlying cause is that the texture manager includes a search algorithm at line 105 of texturemanager.cpp and this fails to find a graphic if it is a face image provided by a skin. In the case of SBARINFO, DrawMugShot calls the texture manager, which cannot find the status face in the texure collection and returns a null pointer -- which gets returned into the "face" variable at line 1244 of sbarinfo_display.cpp and the rest of the mugshot code duly tries to dereference

This problem does NOT occur if the skin is not in force and the DOOM2 IWAD STFs are thus used.

To reproduce:
1) Download this SKIN wad.
2) Download this SBARINFO wad.
3) Start ZDoom without the HUD wad, and set the player to use the CUTMANMIKE skin then quit ZDoom.
4) Start ZDoom again but with the HUD wad.
5) Result = access violation in GetScaledWidth() on line 817 of r_defs.h

I don't know the heck about the internals of the texture manager, so sorry Graf/Randy - this one's your baby

[Graf Zahl]

No, this one's Blzut's baby.

The Doom status bar does find the face textures because it explicitly looks for them (See FDoomStatusBar::SetFace.) But from what I gathered from the SBARINFO code it doesn't set the texture namespace for this case properly.

And BTW, the fix in the other thread is not temporary. The code should have never been removed and was the direct cause of the face not working anymore.

[MartinHowe]

You mean the "usetype" argument should be the skin's namespace (presumably 0 is ns_global, which is why it works for STF)?

[Graf Zahl]

No. The textures for skin faces don't exist normally - they have to be created when used for the first time. That's where FTextureManager::AddPatch comes into play. It gets passed a WAD namespace identifier which is retrieved from the skin.

[Blzut3]

I'm posting here to say that I have read this and will get to fixing it as soon as possible. However, as soon as possible might not be until Thursday or later.

[MartinHowe]

OK, I have found a fix for the STF thing - basically all skin faces are entered into the image list with their own namespaces during the statusbar display initialisation; I'll post a cleaned-up diff of this later. Cuttys CUT status face works with a fullscreen weasel HUD, yee-haa!

Now I have to find out why it crashes in drawswitchableimage

EDIT: Posted STF fix diff. Still have to find out why drawswitchableimage crashes zdoom!

[Graf Zahl]

Added the diff.

Bug left open for the crash.

[MartinHowe]

In case Blutz3 is reading this, I have narrowed down the drawswitchableimage crash - it happens when you do not possess the corresponding weapon. Commenting out all but 1 and 2 works, because you start with fist and pistol. Uncommenting 3 crashes, but if you do +give supershotgun on the command-line starting zdoom, it doesn't crash. I shall investigate further -- when I have the time...

[MartinHowe]

OK, the problem is that 'Weasel is using "" instead of "nullimage" when he wants no image displayed. This either means changing the parser to treat "" as equivalent to "nullimage", which is kinda consistent with the rest of ZDoom, or else documenting in the Wiki that "" isn't acceptable and rejecting an empty string as an error.

Opinions?

EDIT:

I patched sbarinfo_parser.cpp line 1077 of my working copy
from if((stricmp(patchname, "nullimage") == 0) to if ((stricmp(patchname, "nullimage") == 0) || (patchname[0]==0))
for the moment, but should it be allowed, that's the question...

[wildweasel]

I think that "" should be accepted in addition to "nullimage" to draw nothing - since it's already got a precedent (in Decorate, something like Inventory.Icon "" would clear an existing inventory icon for an item that inherits from another, etc).

[Graf Zahl]

"" should always be a placeholder for 'nothing'.

[MartinHowe]

That's what I thought.

Graf, please would you apply the informal patch I gave above and close this thread? It's all that's needed for this problem. Of course, when Mancubus is back up (so that it can be committed) it is anybody's guess

[Blzut3]

Yeah, nullimage is a carry over from before I switched to the token parser.

[randi]

Done. I trust this is all fixed now?

[MartinHowe]

Well unless Blutz3 has anything to add -- well then it's fixed all right - just have a look at this Feature Suggestions thread (especially the last screenshot, taken with DOOM style weaponry in a rather un-Doom-like map )