[4.3.0+] Sprite add-on + HQ resize mode compresses vert size

[mjr4077au]

Historically, having HQ resize options had no impact/were disabled when using an external upscale pack, such as the the 2x Neural Upscale pack.

Starting with 4.3.0+ using the Carmack renderer combined with HQ resize options, sprites compress from the bottom up by the multiplier set in the menu as per the attached screenshots. The hardware renderer is not impacted. This problem occurs in the latest nightly from DRD Team, and also did not exist in 4.2.4 or older.

I utilise such a configuration to apply a slight 2x upscale on other games such as Hexen, Heretic, Freedoom etc that I do not have such a pack for.

[Graf Zahl]

Please provide a ready to use test case.

[mjr4077au]

Please provide a ready to use test case.

1. Download latest stable version of GZDoom (4.3.3 as of posted comment).
2. Download a texture and sprite upscale pack (I'm using Neural Upscale 1.0 from here).
3. Run game with fresh config with any wad compatible with your nominated upscale pack (I'm using doom2.wad) and configure the following:
3a. Software Renderer.
3b. HQ resize using any method (I'm using xBR).
3c. HQ resize by any multiplier (I'm using 2x).
3d. Enable HQ resize for sprites.
4. Play game and observe sprites being vertically compressed from the bottom up by the multiplier used when resizing.
5. Close game, download 4.2.4 and extract over the top of 4.3.3.
6. Play again with texture pack and same settings, and observe the issue does not occur.

The attached config is a fresh config set to use the software renderer with HQ upscaling. Just name it appropriately, run doom2.wad with the upscale pack I've suggested and the issue should be immediately apparent.

[Rachael]

I'm going to be completely honest here:

The software renderer is a mess with the current texture resize code. It's piled on hacks getting it to work - and it really needs to detect the proper sizes of the textures rather than trying to guess it based on the user's settings. I really don't know what options are available to invoke from the texture manager to detect the size variations but I know that what it's using is definitely not good enough.

[mjr4077au]

I'm going to be completely honest here:

The software renderer is a mess with the current texture resize code. It's piled on hacks getting it to work - and it really needs to detect the proper sizes of the textures rather than trying to guess it based on the user's settings. I really don't know what options are available to invoke from the texture manager to detect the size variations but I know that what it's using is definitely not good enough.

I know the software renderer doesn't get a lot of love so it's OK if it sits here for a bit, it's not the end of the world . I should get over the software renderer and move on, but I love the classic look and it's still the only renderer to get the sprites right (which I'm sure is 'right' because it's doing it in some bullshit way).

[Graf Zahl]

(which I'm sure is 'right' because it's doing it in some bullshit way).

Isn't it always with these old games...?

[mjr4077au]

(which I'm sure is 'right' because it's doing it in some bullshit way).

Isn't it always with these old games...?

With what you're working on for Build, I'm sure you've seen 5 years worth of bullshit in 5 months

[Rachael]

Well - if coding practices were followed more often there'd be far less problems. Anything that defines a certain static behavior and gets copy-pasted without using a function is generally a hack. Anything that uses a higher (or even global) state without somehow defining it locally is messy. And variable reuse is a definite cardinal sin, no matter the perceived memory savings, except in cases where the use of said variable is entirely ephemeral (like for the duration of a loop, for instance). Properly name your variables, too, not just "A" or "B". (I'm looking at you, BASIC programmers! That includes a certain engine developer...)

In the software renderer - I admit it's a hack - but I did code in some static (and sometimes copy-pasted) behavior definitions. It really needs to get the true texture size and scaling, instead, and it needs to use the texture manager to get that info. I just haven't had time to figure out how to coax the texture manager into giving me the information that I need.

We sometimes like to criticize a certain Doom programmer for his use of global variables with the software renderer, but for all his flaws he was still a decade ahead of what others who followed in his footsteps did, instead...

[Graf Zahl]

Doom's renderer did what was necessary. Without C++ and workable classes it had to use global variables. The renderer had to work on a global state, whether that is a set of global variables or a real object.

Where things get hairy is when global variables get used to pass parameters around. While working on the Polymost renderer in Build I ran into this several times that data was copied to global variables to avoid passing it around between functions and these variables no longer contained the info that was expected to be there.

[dpJudas]

It is worth mentioning that passing parameters globally does have a performance improvement, especially on older compilers and with old calling conventions (*). Even today, if you pass enough state around its much better to have a struct pointer you pass around. That struct is effectively what is the global data in the old engines.

Where it really falls apart is when lesser disciplined developers show up and realize they can "listen in on the conversation" between other code by peeking at the global variables - perhaps even modifying them. And it goes completely to hell when it is someone like Silverman that labels the global variables only in abbreviations.

*) As long as you move them into local variables if you're going to run a tight loop where they need to be promoted to registers.