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

Moderator: 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.

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

Postby Xane123 » Thu Apr 26, 2018 4:20 pm

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
Xane123
Mary's Magical Adventure Developer
 
Joined: 24 Nov 2015
Location: Martinsburg, WV
Discord: Xane123#3770

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

Postby Graf Zahl » Sat Nov 17, 2018 10:43 am

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 Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Graf Zahl » Sat Nov 17, 2018 12:21 pm

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


Return to Software Renderer Bugs

Who is online

Users browsing this forum: No registered users and 1 guest