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

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!
User avatar
mjr4077au
Posts: 830
Joined: Sun Jun 16, 2019 9:17 pm
Graphics Processor: nVidia with Vulkan support
Location: Gosford NSW, Australia

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

Post by 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.
You do not have the required permissions to view the files attached to this post.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post by Graf Zahl »

Please provide a ready to use test case.
User avatar
mjr4077au
Posts: 830
Joined: Sun Jun 16, 2019 9:17 pm
Graphics Processor: nVidia with Vulkan support
Location: Gosford NSW, Australia

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

Post by mjr4077au »

Graf Zahl wrote: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.
You do not have the required permissions to view the files attached to this post.
User avatar
Rachael
Posts: 13794
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

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

Post by 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.
User avatar
mjr4077au
Posts: 830
Joined: Sun Jun 16, 2019 9:17 pm
Graphics Processor: nVidia with Vulkan support
Location: Gosford NSW, Australia

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

Post by mjr4077au »

Rachael wrote: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 :wink:. 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).
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post by Graf Zahl »

mjr4077au wrote:(which I'm sure is 'right' because it's doing it in some bullshit way).
Isn't it always with these old games...? :mrgreen:
User avatar
mjr4077au
Posts: 830
Joined: Sun Jun 16, 2019 9:17 pm
Graphics Processor: nVidia with Vulkan support
Location: Gosford NSW, Australia

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

Post by mjr4077au »

Graf Zahl wrote:
mjr4077au wrote:(which I'm sure is 'right' because it's doing it in some bullshit way).
Isn't it always with these old games...? :mrgreen:
With what you're working on for Build, I'm sure you've seen 5 years worth of bullshit in 5 months :wink:
User avatar
Rachael
Posts: 13794
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

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

Post by 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...
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post by 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
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

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

Post by 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.

Return to “Classic ("Carmack") Software Renderer Bugs”