Incorrect rendering of some hires textures

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Incorrect rendering of some hires textures

Re: Incorrect rendering of some hires textures

by Graf Zahl » Sun Dec 22, 2019 5:39 am

I haven't looked into the original yet. Hires assets are a tricky matter.

Re: Incorrect rendering of some hires textures

by Player701 » Sun Dec 22, 2019 5:23 am

So, do I understand correctly that...:
  1. ...the issue originally reported by the OP (with the Heresiarch's death animation) is a mod bug, and is caused by the lack of the SPROFS lump?
  2. ...the second issue with the weapon sprites, found by me, is the side-effect of the texel-panning feature, and it has also ended up causing the second issue reported in this thread?
As far as I could understand, we were collecting levels because it's the maps that are primarily affected by this, am I right? Surely there's something that can be done about sprites and font graphics, isn't there?

Re: Incorrect rendering of some hires textures

by Graf Zahl » Fri Dec 20, 2019 4:02 am

You can sort the threads alphabetically, I'd go by that instead of maintaining a list elsewhere. Like, get everything starting with B from the Levels forum.

Re: Incorrect rendering of some hires textures

by Player701 » Fri Dec 20, 2019 3:40 am

Graf Zahl wrote:SPROFS is an engine feature that sets an alternative sprite offset which the hardware renderer uses
Ah, you should have said that last part (emphasis mine) when you first mentioned SPROFS. Now I understand. game_support.pk3 does have SPROFS lumps indeed, and offsets for SORCZ0 are specified there too. However, I couldn't find any mention of weapon sprites there. I guess it might be a consequence of this "design fuckup" that you're talking about.
Graf Zahl wrote:My biggest problem here is that I have no idea how widespread the dependency on that old un-feature is, because all the relevant mods are not on /idgames. I already checked /idgames and the number of mods that need more extensive checking is less than 20.
But the rest poses a major problem for me: The content is scattered across multiple sites on the internet, none of which allow batch downloading. So getting the content is prohibitively time consuming for me.
If I ever wanted to cut this Gordian Knot I need help to collect all this content, move it to a centralized storage space where I can do a batch download overnight and then run a checking tool on them to see which ones need closer investigation. Keep in mind that there's 5000 mod threads. Many are dead, lots are irrelevant but they all need checking. You can imagine how much work that is, can't you? ModDB is even worse because it doesn't have a decent search function, they only provide a Google search that isn't tuned to that site's special needs.

For a first evaluation I'd skip ModDB. All the relevant stuff hosted there is here on the forum anyway, and the few higher profile mods from there can be handled manually.
But to scan these 5000 threads and copy the content several helpers are needed, can you organize them? If we can get this off the ground I'd register a cloud account where all the mods can be uploaded to so that I can access them whenever something in the engine needs to be checked
Regarding your question: I really have no idea. I have no experience organizing such things. If it is necessary to check every mod available in the project forums, I'd probably start by making a list of threads somewhere in Google Docs so that people can visit them, download the mods, upload them to your cloud account, and then mark the threads that have been processed to reduce the amount of work for others. A forum API to query the list of threads along with their URLs would be immensely helpful for this task.

Re: Incorrect rendering of some hires textures

by Graf Zahl » Fri Dec 20, 2019 3:34 am

Thinking about it, I may just make a blog announcement asking for help, because this has been a constant issue, not being able to check the content not on /idgames.
Maybe we can get the usable content off the forum. I just scanned through the threads having a name starting with 'A' in the Levels subforum and it took 40 minutes to get all the relevant content - 16 files.

Re: Incorrect rendering of some hires textures

by Graf Zahl » Fri Dec 20, 2019 2:46 am

No. SPROFS is an engine feature that sets an alternative sprite offset which the hardware renderer uses instead of the one from the image itself. If you replace a sprite with such an offset, the offset will not transfer to the replacement because it's part of the image that's being replaced, depending on how you replace it.

TBH, I think the entire texture scaling feature set needs to be redone, it's essentially broken by design thanks to the worst design fuckup ZDoom ever committed - to allow texture panning in texel space instead of map space for hires textures as its default setting. Unfortunately this filters down to every little corner of the engine where textures are being used because the scaling cannot be hidden from texture placement calculation, as it should, that unfortunately also applies to sprites.

My biggest problem here is that I have no idea how widespread the dependency on that old un-feature is, because all the relevant mods are not on /idgames. I already checked /idgames and the number of mods that need more extensive checking is less than 20.
But the rest poses a major problem for me: The content is scattered across multiple sites on the internet, none of which allow batch downloading. So getting the content is prohibitively time consuming for me.
If I ever wanted to cut this Gordian Knot I need help to collect all this content, move it to a centralized storage space where I can do a batch download overnight and then run a checking tool on them to see which ones need closer investigation. Keep in mind that there's 5000 mod threads. Many are dead, lots are irrelevant but they all need checking. You can imagine how much work that is, can't you? ModDB is even worse because it doesn't have a decent search function, they only provide a Google search that isn't tuned to that site's special needs.

For a first evaluation I'd skip ModDB. All the relevant stuff hosted there is here on the forum anyway, and the few higher profile mods from there can be handled manually.
But to scan these 5000 threads and copy the content several helpers are needed, can you organize them? If we can get this off the ground I'd register a cloud account where all the mods can be uploaded to so that I can access them whenever something in the engine needs to be checked

Re: Incorrect rendering of some hires textures

by Player701 » Fri Dec 20, 2019 2:14 am

Graf Zahl wrote:This isn't a bug. This setting only affects Doomsday style hires packs, anything defined by proper means of the texture manager will not be affected.
I see. Maybe it should be renamed to avoid confusion?
Graf Zahl wrote:Concerning the offsets, what many makers of the texture packs tend to forget is a lump called SPROFS. This is used to fine tune offsets so that the cases where the automatic does not work can be handled. If you replace a sprite that's handled in here there must be a definition for the replacement because it won't be subjected to the "IWAD-only" filter anymore
Are you talking about weapon sprites? If offsets are the culprit, why is hardware rendering unaffected then?

Re: Incorrect rendering of some hires textures

by Graf Zahl » Fri Dec 20, 2019 1:48 am

Player701 wrote: And also, it looks like "Enable hires textures" has no effect at all - they are always enabled. This seems to be the case even in very old GZDoom versions. I am going to report it as a separate issue.

This isn't a bug. This setting only affects Doomsday style hires packs, anything defined by proper means of the texture manager will not be affected.
Concerning the offsets, what many makers of the texture packs tend to forget is a lump called SPROFS. This is used to fine tune offsets so that the cases where the automatic does not work can be handled. If you replace a sprite that's handled in here there must be a definition for the replacement because it won't be subjected to the "IWAD-only" filter anymore

Re: Incorrect rendering of some hires textures

by Player701 » Fri Dec 20, 2019 1:40 am

I have managed to reproduce this bug in GZDoom g4.3pre-532-g318da33e3. It looks like hi-res sprites are not affected by sprite clipping for some reason.

The offsets of the sprite SORCZ0 place it mostly below ground level. When switching from software to hardware rendering, the sprite can be seen to "jump" vertically to readjust its position to become visible. However, this doesn't happen if high resolution sprites are enabled.

I have attached an isolated test sample to this post to reproduce the bug more easily. No specific ini files are required for reproduction. Use the following steps to reproduce the bug:
  1. First, start GZDoom without the test WAD.
  2. Summon a Heresiarch and kill it.
  3. With the Heresiarch's corpse in view, go to "Options" -> "Set video mode".
  4. Switching "Render Mode" between "Hardware accelerated" and "Doom Software Renderer" will result in the sprite of the corpse changing its vertical position.
  5. Now start GZDoom with the test WAD.
  6. Repeat steps 2-3.
  7. Repeat step 4. Expected behavior: The sprite will be shifted vertically when changing from software to hardware rendering. Actual behavior: The sprite doesn't get shifted vertically.
In addition, hi-res sprites seem to suffer from certain other problems:
  • When the test WAD is in use, the whole Heresiarch's death animation is incorrectly shifted downwards (but sprite clipping still affects it in some way, as long as it hasn't reached the final sprite).
  • When using hexen_gz.pk3 provided by the OP, the hi-res weapon sprites are incorrectly shifted upwards in all rendering modes except "Hardware accelerated".
And also, it looks like "Enable hires textures" has no effect at all - they are always enabled. This seems to be the case even in very old GZDoom versions. I am going to report it as a separate issue.
Attachments
cliptest.wad
(20.03 KiB) Downloaded 86 times

Incorrect rendering of some hires textures

by theleo_ua » Mon Nov 25, 2019 5:39 pm

GZDoom 4.2.4 x64
Windows 7 Ultimate x64

Incorrect rendering of some hires textures: https://my.pcloud.com/publink/show?code ... 8eIH9tJc9V


Steps to reproduce:

1) Download and unpack test mod: https://my.pcloud.com/publink/show?code ... vjAjGn72fk

2) Copy GZDoom 4.2.4 x64 and hexen.wad to testmod folder

3) Launch TESTMOD.BAT
or
"gzdoom.exe -config gzdoom-testmod.ini -iwad hexen.wad -file _FILES\hexen_gz.pk3"

NOTE: it's important to use gzdoom-testmod.ini as config file

4) Start first map (hxvisit 01)

5) type "kill monsters" in console (and press enter)
6) type "god" in console (and press enter)
7) type "noclip" in console (and press enter)

8) go to exact posotion as on next screenshot: https://my.pcloud.com/publink/show?code ... 8eIH9tJc9V

9) type "summon heresiarch" in console (and press enter)
10) type "kill monsters" in console (and press enter)

11) remove console (press "~" key)

Expected result: heresiarch's corpse rendered above the ground (and fully visible): https://my.pcloud.com/publink/show?code ... brWbokqT1y

Actual result: heresiarch's corpse rendered below the ground (and partially invisible): https://my.pcloud.com/publink/show?code ... 8eIH9tJc9V


NOTE: If this is not GZDoom issue and issue of the mod (neural hexen texture pack), then plase tell me this in comments, so I will give this link (to respective comment) to the mod author as proof of "he will need to fix the mod"

NOTE 2: there is a small chance that this issue is related to this bug: viewtopic.php?f=2&t=66035

Top