[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!

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

Postby mjr4077au » Sat Feb 01, 2020 11:37 pm

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.
Attachments
spriteissue_hardware.jpg
spriteissue_software.jpg
mjr4077au
Global Moderator
 
Joined: 17 Jun 2019
Github ID: mjr4077au
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: nVidia with Vulkan support

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

Postby Graf Zahl » Sun Feb 02, 2020 12:57 am

Please provide a ready to use test case.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby mjr4077au » Sun Feb 02, 2020 1:49 am

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.
Attachments
gzdoom-mjr40.ini
(15.42 KiB) Downloaded 12 times
mjr4077au
Global Moderator
 
Joined: 17 Jun 2019
Github ID: mjr4077au
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: nVidia with Vulkan support

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

Postby Rachael » Sun Feb 02, 2020 6:09 am

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
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby mjr4077au » Sun Feb 02, 2020 6:23 am

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).
mjr4077au
Global Moderator
 
Joined: 17 Jun 2019
Github ID: mjr4077au
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: nVidia with Vulkan support

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

Postby Graf Zahl » Sun Feb 02, 2020 6:41 am

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
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby mjr4077au » Sun Feb 02, 2020 7:09 am

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:
mjr4077au
Global Moderator
 
Joined: 17 Jun 2019
Github ID: mjr4077au
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: nVidia with Vulkan support

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

Postby Rachael » Sun Feb 02, 2020 8:28 am

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
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby Graf Zahl » Sun Feb 02, 2020 8:39 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby dpJudas » Sun Feb 02, 2020 8:57 am

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.
dpJudas
 
 
 
Joined: 28 May 2016


Return to Classic ("Carmack") Software Renderer Bugs

Who is online

Users browsing this forum: No registered users and 1 guest