This partially reverts "- don't let the video scale let the screen end up with a client size less than 320x200, which may cause undefined behavior and trigger asserts in debug builds."
Although this doesn't look as good as the PCF version it is a lot less calculation intensive and therefore more suitable for weaker hardware.
It also tends to bleed through walls a lot less.
(refactored patch by Graf)
Legacy used some strange blending formula to calculate its colormaps for colored 3D floor lighting, this is not available in the software lighting mode, so for these the engine has to temporarily revert to light mode 2 to render them correctly.
# Conflicts:
# src/gl/compatibility/gl_20.cpp
# src/gl/renderer/gl_lightdata.cpp
# src/gl/renderer/gl_renderstate.h
# src/gl/scene/gl_sprite.cpp
# src/hwrenderer/scene/hw_weapon.cpp
# src/hwrenderer/utility/hw_lighting.cpp
# src/hwrenderer/utility/hw_lighting.h
# src/v_2ddrawer.cpp
- split gl_postprocessshader.h in two so that the hardware independent part can be used by GLDEFS without pulling in all of OpenGL.
# Conflicts:
# src/CMakeLists.txt
# src/gl/dynlights/gl_glow.cpp
# src/gl/renderer/gl_postprocess.cpp
# src/gl/textures/gl_texture.cpp
This was already disabled for GL 4.4 and lower but also needs to be done for Intel's GL 4.5 drivers.
Unlike before this is now exclusive to the light buffer, the shadowmap feature is not affected anymore, although that should be impossible to use anyway on all affected hardware due to lack of computing power.
# Conflicts:
# src/gl/shaders/gl_shader.cpp
# src/gl_load/gl_interface.cpp
Due to the way nested portals work this will block rendering of the nested cap entriely and cause some visual glitches when looking straight up or down in such a sector.
# Conflicts:
# src/gl/scene/gl_portal.cpp
Thanks to OpenGL's messed up state system this didn't cause some clear failure but just reused the last bound buffer instead which may not have had a matching size.
(cherry picked from commit 2c86c4e942)
This gets exclusively used by portal borders which means that for walls the setting is irrelevant but for flats it is needed to cover the portal surface so that translucent parts of the outer scene do not bleed through.
(cherry picked from commit d0aacd3ba8)
# Conflicts:
# src/gl/scene/gl_scene.cpp
- remove gl_ prefix for model functions that are no longer GL specific
(cherry picked from commit 31abe3df7e)
# Conflicts:
# src/gl/models/gl_models.h
# src/gl/scene/gl_scene.cpp
# src/hwrenderer/scene/hw_sprites.cpp
# src/hwrenderer/scene/hw_weapon.cpp
# src/hwrenderer/textures/hw_precache.cpp
- precalculate if a sector's floor and ceiling plane overlap. This avoids rechecking this for each single call of hw_FakeFlat.
- vertices must be marked dirty every time they change after map setup. That means that ChangePlaneTexZ must do this as well, because it cannot rely on interpolation taking care of it.
- Having a 'dirty' argument for SetPlaneTexZ's ZScript version makes no sense. If the value changes from the script side the vertices must always be marked to be recalculated.
(cherry picked from commit 9bdb0f2e49)
This was all over the place, with half of it using the function and half doing incomplete checks on the underlying variables.
Also did some optimization on the IGNOREHEIGHTSEC flag: Putting it on the destination sector instead of the model sector makes the check even simpler and allows to precalculate the effect of 3D floors on the heightsec, which previously had to be run on every call and made the function too complex for inlining.
(cherry picked from commit f49c6cbde2)
# Conflicts:
# src/gl/renderer/gl_renderer.cpp
# src/hwrenderer/scene/hw_sprites.cpp
* only call hw_CheckViewArea if the result is not known yet.
* check the map up front if it even contains heightsecs. This allows to shortcut the above check entirely for maps without sector transfers and will allow further optimizations.
(cherry picked from commit 3c49804c6c)
# Conflicts:
# src/gl/scene/gl_bsp.cpp
# src/gl/scene/gl_fakeflat.cpp
# src/hwrenderer/scene/hw_fakeflat.h
This was done mainly to reduce the amount of occurences of the word FTexture but it immediately helped detect two small and mostly harmless bugs that were found due to the stricter type checks.
These cannot be done with the regular textures so there needs to be an option to create more than one native texture per FTexture. For completeness' sake there is also the option now to create a paletted version of a texture if the regular one is true color. This fixes a long standing problem that translations were not applied to non-paletted textures.
The old logic used a translation table that does not work with color images, it was designed to handle 8 bit grayscale images.
So now, it creates a true color buffer and then turns it into a texture with R,G,B = 255 and the alpha channel set to the grayscale value.
This was also the reason why crosshairs made from 32 bit PNGs did not show correctly.
Now it is no longer necessary to provide specially set up textures for rendering shaded decals, they can use any PNG texture now that contains a proper red channel.
Handling of the alPh chunk has been removed as a result as it in no longer needed.
Until now each subclass of FTexture had to implement the entire span generation itself, presumably so that a few classes can use simpler structures.
This does not work if a texture can have more than one pixel buffer as is needed for alpha textures.
Even though it means that some classes will allocate more data now, it's the only way to do it properly.
In addition this removes a significant amount of mostly redundant code from the texture classes.
- added alpha texture processing to all converted classes
As of now this is not active and not tested.
Note that as part of the conversion even those textures that were working as alphatextures will not look correct until the higher level code gets adjusted.
