Z-fighting between flat texture and stencil at long distances was occurring, showing up as a "shimmer" at a long distance from the camera. Just increasing the vertical shift of flat texture.
Addressing this bug: https://github.com/ZDoom/gzdoom/issues/3246
* Feature-complete isometric mode fork.
* Dithered transparency condition tweaks.
* Dithered transparency for non-corpse monsters only (and missiles).
* SpectatorCamera vertical shift.
* Including math.h in hw_sprites.cpp to keep visual studio happy (it couldn't find M_SQRT2 definition).
* Defining MY_SQRT2 in hw_sprites.cpp to keep visual studio happy (it couldn't find M_SQRT2 definition).
* Defining MY_SQRT2 in r_utility.cpp also to keep visual studio happy.
* retrigger checks
* Have correct sprite angle-frame face the camera with orthographic projection enabled.
* Dithered Transparency now works properly on 3D floors. Moved that dither-trans flag setting code within hw_bsp.cpp to handle double-processing of linedefs. Added helper functions to FRenderViewpoint class 'bool IsOrtho()' and 'bool IsAllowedOoB()' to clean up checks everywhere in the code.
* Fixed indents. Added bbox property to subsector struct and use it instead of BSP nodes and Clippers (creating a bbox around viewpoint and checking for overlap) in orthographic mode when no fog of war is active. Turns out to be much faster. Though you need really big maps (Winter's Fury MAP01) to see a difference in fps.
* Non-linux checks don't like uint. Changed to unsigned int.
* Small change of a float to camera.zs. Ignore for testing. Should make no difference.
* Update actor.h to remain mergeable
RF2_NOMIPMAP was introduced, so I had to displace RF_ISOMETRICSPRITES to next bit.
- `DontLightOthers`: Acts as the inverse of `DontLightSelf`, where it won't light actors that aren't the owner.
- `DontLightMap`: The light doesn't affect the map.
* made the portal state global, outside the framebuffer, because it is pure logic state without dependencies on the backend.
* took the setup functions out of FDynLightData - there is no need to have them as members and they age game dependent.
All decisions were done deep inside the texture creation code, leaving zero options to the higher level code for controlling the feature.
Changed this so that the option to upscale must be passed as a parameter to FRenderState::SetMaterial and extended all needed variables to manage the added texture variants.
Still not solved: Material layers need explicit control, not only for scaling but also for filtering.
It makes little sense exposing every minute detail of this through UDMF.
Setting it up that way is far too complicated. Using virtual textures that map to a real texture plus a colorization record should be far easier to use by mappers.
This also doesn't piggyback on the Doom64 color feature anymore and is completely separate, despite some redundancies.
This is still missing the texture definition part, though.
