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.
[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!
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!
-
- 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
You do not have the required permissions to view the files attached to this post.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [4.3.0+] Sprite add-on + HQ resize mode compresses vert
Please provide a ready to use test case.
-
- 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
1. Download latest stable version of GZDoom (4.3.3 as of posted comment).Graf Zahl wrote:Please provide a ready to use test case.
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.
-
- Posts: 13792
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: [4.3.0+] Sprite add-on + HQ resize mode compresses vert
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.
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.
-
- 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
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).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.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [4.3.0+] Sprite add-on + HQ resize mode compresses vert
Isn't it always with these old games...?mjr4077au wrote:(which I'm sure is 'right' because it's doing it in some bullshit way).
-
- 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
With what you're working on for Build, I'm sure you've seen 5 years worth of bullshit in 5 monthsGraf Zahl wrote:Isn't it always with these old games...?mjr4077au wrote:(which I'm sure is 'right' because it's doing it in some bullshit way).
-
- Posts: 13792
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: [4.3.0+] Sprite add-on + HQ resize mode compresses vert
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...
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...
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [4.3.0+] Sprite add-on + HQ resize mode compresses vert
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.
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.
-
-
- Posts: 3134
- Joined: Sat May 28, 2016 1:01 pm
Re: [4.3.0+] Sprite add-on + HQ resize mode compresses vert
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.
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.