Collecting all mods from the Projects forum .- Help needed

[Enjay]

Understood, thank you.

[Graf Zahl]

So, after having looked through half of /idgames I can say with certainty that absolutely NOBODY seems to be aware of the issue this is about, all the mods that have WorldPanning set had some input from either Enjay or me. Everybody else just happily hacked away and tweaked the offsets until they fit and nobody bothered with the robustness workarounds I added.

Which convinces me even more that something needs to be done here, the more mods exist that rely on this the harder it is to use hires packs because they essentially require this hack to be gone. The one good thing is that none of the mods using hires textures with texel panning seems to use them on scrolling linedefs, otherwise we'd have a problem two magnitudes larger.

So far I'm at 85 maps that require a compatibility setting - but I was overly cautious and probably added more than really needed. The number is still small enough.

[Graf Zahl]

Hm, well, I fear this won't work out. The broken stuff is in nearly every GZDoom mod from the last 5 or 6 years, I cannot add a compatibility option for all those maps.
Checking the WAD files on /idgames yielded 150 maps, which was manageable, but checking the PK3s doubled that and I'm not sure if I missed some due to the messy packages.
And let's not even start with the stuff not hosted on /idgames, With that the number of affected files literally exploded.


So I think with this feature a dead end is reached. It's broken by design yet its use is so widespread that nothing can be done about it anymore. Which means that certain bugs simply cannot be fixed.

[Player701]

I guess there is no more need to collect mods now, then? Or is there?

[Graf Zahl]

No, not really. This went the way I feared and it's not good because we are stuck with the broken code forever.

The stuff in the Levels forum alone was enough to give a clear picture and I guess the TCs will make things even worse.

[Tormentor667]

What exactly is broken and why is this a problem?

[Player701]

No, not really. This went the way I feared and it's not good because we are stuck with the broken code forever.

The stuff in the Levels forum alone was enough to give a clear picture and I guess the TCs will make things even worse.

I see. Anyway, I'm glad I could be of help.

[Graf Zahl]

What exactly is broken and why is this a problem?

It's about "worldpanning" for scaled textures not being the default. Thanks to that harebrained decision from 15 years ago to allow per-texel panning for scaled textures and make that the default, when it was discovered that the problem existed in the first place (caused by doing it in the wrong place for the software renderer) we are now saddled with a situation where the texture calculation code cannot be rid of detailed knowledge of the texture's true size. And that little bit of information needs to filter down to places where it causes serious issues. If the true texture size could just be hidden from the renderer entirely things would be a lot easier to handle.

Unfortunately it turned out that absolutely nobody, except a handful of mods that can be counted on the fingers of one hand, ever used this setting on their scaled textures, meaning that most modern GZDoom mods depend on the stuff I wanted to remove. It's simply far too much to turn back the clock.

[Tormentor667]

Even though I do not understand all of it, it's a bit clearer for me now - so thanks for the explanation. Couldn't be some kind of special case added that works in a way that checks for the file date of a mod? For example if there are a lot of old mods, you check for their timestamp (no idea which one makes sense though) and according to that one, different codes in the engine get executed so GZDoom handles old mods different than new ones? (I guess this makes absolutely no sense, but I am interested in understanding why such mechanics aren't working)

[Graf Zahl]

Define "old mod" in a way the engine can understand. File date won't do because all that's needed to screw it is to open the mod and replace some piece of music, for example.
I already added a global switch in MAPINFO to disable the old code, but I cannot force people to use it (and most simply don't.)

But even then, as long as the old code needs to be present I cannot clean up this mess. If I could make 100% sure that this isn't used in combination with scrollers I could at least move the entire pile of garbage to the map loader, but verifying THAT is an endeavour that's simply unmanageable. In the maps I checked I didn't find a single one that was scrolling texel-panned hi-res textures but that's merely observation, not proof.

[Rachael]

I was actually aware of the worldpanning feature for quite a while now, and was very surprised when I found out that it wasn't default. At least when this thread was made, now I know why.

[Enjay]

I too was very surprised that it wasn't the default the very first time that I used the feature. I had made hi-res versions of the Doom crate textures, tested them on map E2M2 and noticed that the offsets were wrong in several places.

I'm not even sure if the "world panning" flag was even available at that point but I do remember posting that the way things were working made it practically impossible to make a drop-in hi-res texture pack (I don't think other hi-res options were available at the time). I also remember Jack Vermeulen's counter argument was that using per-texel panning allowed far more control and was therefore far more useful.

And so it remained the default.


To be fair, I've even used the default myself. Occasionally, if I thought I had a texture where fine control might be useful, I have not set the "world panning" flag. I set "world panning" for most textures, but I haven't on a handful.

[Graf Zahl]

I also remember Jack Vermeulen's counter argument was that using per-texel panning allowed far more control and was therefore far more useful.

This guy is also responsible for another feature that ultimately proved to be detrimental: auto-scaling flats. He also advocated for the TX_ /Textures namespace to take on the sizes of previous textures with the same name - where I was ultimately able to stop the nonsense and offloaded that part to its own namespace - HI_/Hires.

I don't want to think about how messy things would have been if that had become the default...

[Enjay]

I forget the details, but I remember that he wasn't particularly keen on the TX-style textures feature at all for a while.

[Graf Zahl]

Of course not. He constantly acted against everything that would have meant more work for his editor.