src/gl/scene/gl_sprite.cpp:685:34: warning: '&&' within '||' [-Wlogical-op-parentheses]
src/polyrenderer/scene/poly_sprite.cpp:297:34: warning: '&&' within '||' [-Wlogical-op-parentheses]
src/swrenderer/scene/r_opaque_pass.cpp:975:35: warning: '&&' within '||' [-Wlogical-op-parentheses]
src/sound/mididevices/music_timiditypp_mididevice.cpp:548:30: warning: comparison of integers of different signs: 'int' and 'size_t' (aka 'unsigned long') [-Wsign-compare]
It now works the following way:
(0) - Force off (ZDoom defaults)
(1) - Force on (Doom defaults)
(2) - Auto off (Prefer ZDoom defaults - if DEHACKED is detected with no ZSCRIPT it will turn on) (default)
(3) - Auto on (Prefer Doom defaults - if DECORATE is detected with no ZSCRIPT it will turn off)
From the look of it the scale was changed in the software renderer several years back but the hardware renderer never got adjusted for it.
This also adds a bit of compensation to round particles so that they get rendered a bit larger than square ones.
- consolidated the code to calculate a sprite's display angle for all 3 renderers.
As it turned out, they all differed in their feature support because they had always been updated independently by different people.
This has increasingly become an obstacle with the hardware renderer, so now the values are being stored as plain data in the sector, with the software renderer getting the actual color tables when needed. While this is a bit slower than storing the pregenerated colormap, in realistic situations the added time is mostly negligible in the microseconds range.
Removing this made me realize that calling the renderers' FakeFlat functions from the automap is inherently unsafe with the recent refactorings because there is absolutely no guarantee that the data may actually still be defined when the automap is being drawn.
So the best approach here is to give the automap its own FakeFlat function that runs independently of render data and assumptions of data preservation. This one can also be a lot simpler because it only needs the floor, not the ceiling info.
Most of those which still rely on ZDoom's own definition should be gone, unfortunately the code in files that include Windows headers is a gigantic mess with DWORDs being longs there intead of ints, so this needs to be done with care. DWORD should only remain where the Windows type is actually wanted.
This can only be used if the entirety of the game code is aware and dealing with this properly. However, that isn't the case so the amount of glitches this causes far exceeds the number of desired interpolations.
