[GZDoom] HUD scaling, Textures, Translations

[Kate]

When a sprite is defined with TEXTURES and used as an inventory graphic on the HUD, the scaling goes out of whack. Ex:


My screen resolution is 1440x900, the status bar is using fullscreenoffsets, and the SBARINFO resolution is unchanged (320x200).

It's very clearly visible that the right graphic is smaller than the left one, even though they both technically should be the exact same size.
Both of these items look like this in TEXTURES (for the left, and right HUD sprites respectively):

Code: Select all

GRAPHIC INVMAXPO, 16, 22
{
    OFFSET -9, -8
    PATCH MPTNA0, 0, 0
    {
        Translation "160:167=90:111", "112:127=[0,0,255]:[0,0,2]"
    }
}

GRAPHIC INVRESTO, 16, 22
{
    OFFSET -9, -8
    PATCH MPTNA0, 0, 0 {}
} 

MPTNA0 is a sprite defined in the SPRITES/ folder in the 7-zip file of my project, and used as such in-game.

Obviously, the only one that sets the left one, which looks correct, apart from the right one, which does not, is the translation, and here's the odd part: If I add “Translation "1=1"” to the second graphic as a dummy, it *does* show up properly.

UPDATE: I found this CAN be reliably recreated with the above method just fine. However, this appears to be a bug with GZDoom's OpenGL mode, which is why I couldn't recreate it in ZDoom.

[Kate]

Re:
On IRC with a discussion with Zippy, we found that it's the empty brackets in the second definition that's causing the sprite to be parsed incorrectly. Removing them causes it to appear properly.

Hope that helps.

[Graf Zahl]

I can't see any difference in parsing behavior with the '{}' and without it. Can you create a test WAD that definitely causes problems so that I can check the actual difference between the created textures in a debugger?

[Zippy]

I think there has to be something more than just the braces. I created what would be a bare minimum case duplicating the above TEXTURES code and couldn't get the problem to display (in ZDoom 2.5.0) in either HudMessage graphics or as inventory icons. No idea what it could be though... something in the actual image file or previous TEXTURES definitions?

It's going to be up to Pink Silver to produce a scaled down demonstration case carved out of her mod... I'm just not sure how to build one from scratch at this point.

[Graf Zahl]

That was the same problem I had. This is why you should add a test WAD to reproduce the problem with your reports. It makes things a lot easier - especially if your assumption about what precisely is wrong is not correct.

[Kate]

Unfortunately it doesn't look like it's going to be that easy - even with the exact configuration I had before, it seems I can no longer produce the symptoms; the bug literally just disappeared on its' own with no traces left of it under completely random circumstances and now it refuses to happen again.

It appears to be one of those one-time mystery bugs. Ugh.

[NeuralStunner]

I hate those kind the most.

[Kate]

Hi. I'd just like to let you know that this bug is still valid, and happens with GZDoom in OpenGL.

Here's a test wad to screw around with. Let me warn you however, this appears to be affected by the loaded textures, so this will not have a noticeable effect straight off if any, there will probably need to be additional textures loaded, which is telling me the texture loader is accessing the wrong memory address when looking up scaling for patches without the brackets there. Hopefully this will help narrow down the problem.

[wildweasel]

Moved back to Bugs to ensure it gets seen...

[Graf Zahl]

I can't see any problems here. You need to post something that reproduces the problem for sure with a good chance of being reproducable. Otherwise I can't do anything about it. For me both textures are identical data structures.

[Kate]

Bumping since Pokémon Doom was released and the Full Restore graphic tends to have this problem quite often so hopefully it'll help.

[randi]

I'm trying to clear out the Bugs forum some, so this goes to Closed Bugs, since it is allegedly GZDoom-only.

[Graf Zahl]

I can just repeat what I said last time: Not reproducable for me. What hardware did this happen on?

[Kate]

Intel GMA 950 originally, but now I have a GeForce GT 430 and it still happens, so I don't think it might be something linked to the video hardware. Unfortunately it seems to happen at random with different scaling every time, so it might be one of those incredibly difficult to trace memory issues.

[Graf Zahl]

I only wanted to rule out that it's related to non-power-of-two textures. Those are being handled quite differently internally if the hardware doesn't support them. But if it happens on a Geforce that can't be the case.