[g3.4pre-295-g10b869ba11]Hi-res midtex collision is way off

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

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 Reply
User avatar
Xane123
Posts: 165
Joined: Tue Nov 24, 2015 1:58 pm
Graphics Processor: nVidia (Modern GZDoom)
Location: Inwood, WV
Contact:

[g3.4pre-295-g10b869ba11]Hi-res midtex collision is way off

Post by Xane123 »

I was testing my game and found myself hitting invisible collision above lights way below me, which had transparent mid-textures floating around them to fake glass. These had walkable mid-textures enabled, but this bug went away after I removed that flag from the linedefs, but this only started happening after I made the texture hi-res using the HiRes folder in my PK3.

I made a WAD for Doom II that demonstrates this bug; When the map starts, run and jump forward and you'll land on invisible collision that doesn't match where the metal textures below you are placed. Fall off the invisible collision and you'll land on metal textures that aren't hi-res, which are there just to prove this only affects textures that have a HiRes override. I didn't put this in OpenGL renderer bugs because the collision being this out of position is a bug that affects all of the renderers and the collision should be at the same places the SILVER texture is.

This bug's appearance varies between renderers, too; In the OpenGL renderer, the hi-res texture is placed where the collision should be, but in the software renderer it's placed visually where the wrong collision is. In the SoftPoly renderer, the texture isn't rendered at all, leaving just the collision. Here's videos of the three renderer types:


Here's the map that demonstrates this bug. (If the limit here is still 256KB, I know this wouldn't fit here.)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [g3.4pre-295-g10b869ba11]Hi-res midtex collision is way

Post by Graf Zahl »

I finally had a chance to look.

Here's the irony: The only thing in here that is correct is what appears to be wrong, i.e. the collision area of the scaled texture and how the software renderer places it.

I simply cannot fix this issue because something else will break if I do. The sidedef texture scaling factor is totally broken, it is impossible to get consistent results when using it, because its interpretation depends on a certain texture property - and this property does not get set for unscaled textures! Which results in all offsetting calculations for textures that only get scaled with the sidedef property being off.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [g3.4pre-295-g10b869ba11]Hi-res midtex collision is way

Post by Graf Zahl »

I changed it so that it now uses the hardware renderer's coordinate calculation, so that this is at least correct. Fortunately the hardware renderer already had this stuff in a small utility class so it was contained in one place and, most importantly, reusable.

The problem with the two software renderers is, as usual, that they never consolidated such things into subfunctions or helper classes, so the offset calculations are scattered all over the code and nearly impossible to clean up. Ideally they should use the same utility class for consistency reasons but I have my doubts that it will ever happen... :?

But this entire episode showed me again what a gigantic clusterfuck the texture system is. This is in desperate need of getting completely rewritten.
Post Reply

Return to “Closed Bugs [GZDoom]”