Texture lookup rules for walls in Build
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Texture lookup rules for walls in Build
The only 'go' here is to retain the shader hack. To keep the backend code identical with GZDoom it will be added with a conditional #define so GZDoom can just ignore it - it has no use in Doom engine games, after all.
- Phredreeke
- Posts: 295
- Joined: Tue Apr 10, 2018 8:14 am
Re: Texture lookup rules for walls in Build
Well there are two choices
- Hack the hardware renderer to match classic.
- Let the hardware renderer wrap properly, and fix offsets in each map instead.
The first is much more manageable. But from what I can tell, EDuke32 went with a third option.
- Hack the hardware renderer to match classic, but disable the hack if later map version is detected (in which case the software renderer is fixed instead)
- Hack the hardware renderer to match classic.
- Let the hardware renderer wrap properly, and fix offsets in each map instead.
The first is much more manageable. But from what I can tell, EDuke32 went with a third option.
- Hack the hardware renderer to match classic, but disable the hack if later map version is detected (in which case the software renderer is fixed instead)
- mjr4077au
- Posts: 829
- Joined: Sun Jun 16, 2019 9:17 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Gosford NSW, Australia
- Contact:
Re: Texture lookup rules for walls in Build
From an inexperienced viewpoint, the second option sounds best. I imagine Maphacks could be used for this, similar to how Quakespasm ships a pak file that has offsets to correct z-fighting in the stock maps.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Texture lookup rules for walls in Build
I'd do the same as EDuke - preserve the behavior for classic maps but fix it for any new map format that doesn't need to preserve old bugs and add a flag to some definition file to allow specifying which behavior a map needs. That has generally always been the approach taken by ZDoom for things that aren't isolated edge cases.
2 is definitely unmanageable. It surely is the cleanest for the engine but requires active intervention for each map and there's simply too many of them.
2 is definitely unmanageable. It surely is the cleanest for the engine but requires active intervention for each map and there's simply too many of them.