Texture scaling inconsistencies with software renderers

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.

Texture scaling inconsistencies with software renderers

Postby Talon1024 » Wed Nov 21, 2018 10:02 am

While I was working on this pull request for SLADE, I noticed that when I looked at levels ingame, I noticed some slight inconsistencies between the appearance of vertically scaled textures in SLADE's 3D view, GZDoom's OpenGL renderer, and GZDoom's software renderers.

Here is a demo.
Talon1024
 
 
 
Joined: 27 Jun 2016

Re: Texture scaling inconsistencies with software renderers

Postby Graf Zahl » Wed Nov 21, 2018 10:25 am

If you refer to the 'scale' property on the sidedef in UDMF, yes, that does have problems in the software renderer. Unfortunately the code is not in a state where it can be fixed easily.
Truth be told, thanks to the mess ZDoom made out of texture panning for scaled textures, this entire thing is probably not fixable anymore because there is no way to make it behave consistently and not break existing projects.

Actually I think that we really need a new UDMF namespace where this stuff is defined in a way that such inconsistencies cannot happen anymore and an offset is an offset is an offset, no matter where it comes from.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture scaling inconsistencies with software renderers

Postby Talon1024 » Wed Nov 21, 2018 1:18 pm

Yes, I'm referring to the "scale" sidedef properties. However, to me, it's the software renderers that are scaling and mapping the textures correctly. As for the fact that changing the code might break existing projects, I was thinking that another compatibility flag could be added in order to let players or modders decide whether or not to use the broken texture scaling.
Talon1024
 
 
 
Joined: 27 Jun 2016

Re: Texture scaling inconsistencies with software renderers

Postby Graf Zahl » Wed Nov 21, 2018 3:03 pm

Like I said, the entire thing is totally messed up. What is right and what is wrong is merely a matter of interpretation. The main problem here is that I have no idea what to do with it because I have no idea how widespread this field has been used - the main problem being that the downloads are far too scattered across different hosting services with no chance of automating it. The discepancy between renderers has been there since its inception, rendering it effectively useless as an editing feature, but sadly the first report about this is less than 6 months old, so this broken feature has been in the wild for 9 years.
The underlying cause for this mess is that initially ZDoom had panned scaled textures based on texels, instead of map units, because that resulted from how the software renderer works. Doing proper panning in the software renderer requires deliberate adjustment by the scaling factor.
Logically this was discovered very shortly after it was implemented - but the solution was not to fix it, but to add - you guess it - a flag in the texture definition. And it defaults to the useless value because that is older. So now we are facing a problem that is virtually unsolvable, unless some truly radical measures are implemented that eliminate the underlying problem. As long as this weird scaling option can happen, the entire texture panning math becomes so complicated that further problems in the future are inevitable.

I was thinking about a new UDMF namespace to make this and a few other things well-defined once and for all, then deprecate the old namespace, so that in the future there's less problems. Regarding compatibility flags, my main issue with those is that mappers do not set them. They happily map for their own settings, release their project and let their users sort it out. So this has to be some global flag in the map itself, not the map's metadata from MAPINFO.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture scaling inconsistencies with software renderers

Postby Enjay » Wed Nov 21, 2018 4:15 pm

I remember all this happening at the outset. For further information...

The initial hi-res texture implementation happened and it was initially assumed that the texel offsetting would be wanted/most desirable because it allows very fine adjustment of the texture position on the line (i.e. moving it less than one world unit). One of the first things I did was to try and make some drop-in hi-res replacements for the stock Doom textures. Immediately, I could see that it wasn't working as I expected. It very quickly became apparent that using texel offsets meant that hi-res textures could not be used as drop-in replacements for existing textures because any original textures that had been offset in a map would only be shifted by however many texels the offset number was at and not how many world-unit pixels. I think that this is probably an example of the implementation making assumptions about what mappers were likely to want, and getting it wrong.

Some way had to be created to allow drop-in replacements and also, many mappers expressed a need/desire for world-unit rather than texel offsetting even in non replacement textures. It's my recollection that the issue happened very soon after the initial release of hi-res textures and I certainly remember debating the pros and cons of it at the time. As I recall, Jack Vermeulen of DeePsea was very keen on the texel offsetting and he had been one of the people involved in pushing for the inclusion of big/hi-res textures (there was an ongoing political situation between him and Randy relating to big textures long afterwards that I'm not even going to try to poke with a very long barge pole).

Anyway, as already stated, it was decided to add a flag to the texture definition so that any individual texture could be set to either texel (default) or world-unit offset and it would be possible to have both in the same WAD. Again, as I recall it, there was spare capacity in the id TEXTURE1 lump to allow this flag to be stored. And, as Graf said, the default was the texel offset because it was older. However, I really don't recall it being that much older and I personally think a wiser decision would have been to reverse the decision so that the more useful world-units were the default. There wouldn't have been that many mods affected at the time.

It's also worth remembering that, at the time, editing was in a much more primitive state. There was no UDMF, no TEXTURES lump, no auto-hi res support and being able to use a big graphic on a wall at all was very new (I don't think it had even become possible to put any graphic on any surface yet, so if you were putting something on a wall, it needed to be included in the TEXTURE1 lump). I guess adding a flag to TEXTURE1 seemed like a neat way to use the resources available at the time.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: Texture scaling inconsistencies with software renderers

Postby Graf Zahl » Wed Nov 21, 2018 4:30 pm

Correct, but like many decisions of that time it ultimately became some heavy baggage causing more problems than it's worth.
Long term thinking wasn't in the picture in those dark ages...
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to OpenGL Renderer Bugs

Who is online

Users browsing this forum: No registered users and 1 guest