IWAD wasn't detected properly, and wrong texture can be picked as a hires replacement (e.g., SLADRIP1 from Ultimate Doom instead of TNT)
https://forum.zdoom.org/viewtopic.php?t=64915
Old graphics, like mine (Intel Sandybridge Mobile, GL 3.0 Mesa) do not support this, therefore most of the time RFL_SHADER_STORAGE_BUFFER wasn't unset (I found no consequence of this on my machine, but better safe than sorry).
Found out by Valgrind. (patch by edward-san)
This had two different flags that were checked totally inconsistently, and one was not even saved.
Moved everything into a few subfunctions so that these checks do not have to be scattered all over the code.
# Conflicts:
# src/actorinlines.h
# src/decallib.cpp
# src/g_levellocals.h
# src/hwrenderer/scene/hw_sprites.cpp
# src/p_mobj.cpp
# src/p_saveg.cpp
# src/p_user.cpp
# src/polyrenderer/scene/poly_particle.cpp
# src/scripting/vmthunks.cpp
# src/swrenderer/things/r_particle.cpp
# wadsrc/static/zscript/actors/player/player.zs
# wadsrc/static/zscript/base.zs
# Conflicts:
# src/g_levellocals.h
# src/hwrenderer/scene/hw_sprites.cpp
# wadsrc/static/zscript/base.txt
This also removes the gl_attachedlights CVAR because with the new management this doesn't really work anymore.
# Conflicts:
# src/gl/system/gl_cvars.h
# wadsrc/static/menudef.txt
Since these can be changed on the placed light actor they have to be read from there, so this is now a pointer in FDynamicLight, just like the other properties that can be user-changed.
Also did some cleanup on the interface so that external code doesn't need to dereference the lightflags pointer but can use utility functions for all flags.
# Conflicts:
# src/hwrenderer/dynlights/hw_dynlightdata.cpp
# src/swrenderer/line/r_walldraw.cpp
# Conflicts:
# src/g_level.cpp
# src/gl/compatibility/gl_20.cpp
This should be less of a drag on the playsim than having each light a separate actor. A quick check with ZDCMP2 showed that the light processing time was reduced to 1/3rd from 0.5 ms to 0.17 ms per tic.
It's also one native actor class less.
# Conflicts:
# src/g_shared/a_dynlight.cpp
# src/g_shared/a_dynlight.h
# src/hwrenderer/dynlights/hw_dynlightdata.cpp
# src/hwrenderer/dynlights/hw_dynlightdata.h
# src/hwrenderer/scene/hw_renderhacks.cpp
# src/namedef.h
# src/scripting/thingdef_data.cpp
# src/swrenderer/line/r_walldraw.cpp
# Conflicts:
# src/d_main.cpp
# src/g_levellocals.h
# src/g_shared/a_dynlight.cpp
# src/g_shared/a_dynlight.h
# src/gl/dynlights/gl_dynlight.h
# src/gl/dynlights/gl_dynlight1.cpp
# src/gl/scene/gl_spritelight.cpp
# src/gl/scene/gl_walls.cpp
# src/hwrenderer/dynlights/hw_shadowmap.cpp
# src/hwrenderer/dynlights/hw_shadowmap.h
# src/hwrenderer/scene/hw_flats.cpp
# src/p_setup.cpp
This did no longer sort sprites in the same position reliably since the feature to render sprites which only partially are inside a sector was added.
With this, sprites in the same position are no longer guaranteed to be added to the render list in sequence.
Fixed by adding an 'order' field to AActor which gets incremented with each spawned actor and reset when a new level is started.
The software renderer will also need a variation of this fix but its data no longer has access to the defining actor when being sorted, so a bit more work is needed here.
# Conflicts:
# src/hwrenderer/scene/hw_drawlist.cpp
# src/hwrenderer/scene/hw_sprites.cpp
These always come from open-sector render hacks where the renderer tries to fill in some gaps
# Conflicts:
# src/hwrenderer/scene/hw_walls.cpp
# Conflicts:
# src/gl/scene/gl_walls_draw.cpp
The easiest part was the type checks which could be changed to the name variant with a global search and replace.
# Conflicts:
# src/hwrenderer/scene/hw_sprites.cpp
# Conflicts:
# src/hwrenderer/scene/hw_sprites.cpp
Both need the bMasked flag, or some code will think that the texture is not fully opaque if no holes were found.
# Conflicts:
# src/gl/textures/gl_material.h
# src/textures/texture.cpp
This reuses the FTexCoordInfo class the hardware renderer had been using to calculate wall texture offsetting.
The software renderers still need this sorted out to bring them in line with the rest of the code, though, but they do not have this code sufficiently well organized to make this a straightforward task.
# Conflicts:
# src/hwrenderer/textures/hw_material.cpp
# src/textures/textures.h
* Colors can npw be defined per sidedef, not only per sector.
* Gradients can be selectively disabled or vertically flipped per wall tier.
* Gradients can be clamped to their respective tier, i.e top and bottom of the tier, not the front sector defines where it starts.
The per-wall colors are implemented for hardware and softpoly renderer only, but not for the classic software renderer, because its code is far too scattered to do this efficiently.
# Conflicts:
# src/hwrenderer/scene/hw_renderstate.h
# src/hwrenderer/scene/hw_walls.cpp
# Conflicts:
# src/gl/scene/gl_walls_draw.cpp
Until now this wasn't doable because these could have come from hw_FakeFlat which only were local copies on the stack.
With the recent change these faked sectors live long enough so that they can be passed around here.
# Conflicts:
# src/hwrenderer/scene/hw_decal.cpp
# src/hwrenderer/scene/hw_walls.cpp
# Conflicts:
# src/gl/scene/gl_wall.h
# src/gl/scene/gl_walls.cpp
# src/gl/scene/gl_walls_draw.cpp
# src/hwrenderer/scene/hw_decal.cpp
An exception is made for the sprite drawer which needs to call this in the worker thread on some occasions for as-yet unprocessed sectors.
This case may not alter the cache to avoid having to add thread synchronization to it.
The main reason for this change is that pointers to such manipulated sectors can now be considered static in the renderer.
Due to them being short lived local buffers it was not possible to carry them along with the render data for information retrieval.
# Conflicts:
# src/gl/renderer/gl_renderer.cpp
# src/hwrenderer/scene/hw_bsp.cpp
# src/hwrenderer/scene/hw_drawinfo.h
# src/hwrenderer/scene/hw_drawlist.cpp
# src/hwrenderer/scene/hw_fakeflat.cpp
# src/hwrenderer/scene/hw_renderhacks.cpp
# Conflicts:
# src/gl/renderer/gl_renderer.cpp
# src/gl/renderer/gl_renderer.h
# src/gl/scene/gl_bsp.cpp
# src/gl/scene/gl_drawinfo.cpp
# src/gl/scene/gl_fakeflat.cpp
# src/gl/scene/gl_renderhacks.cpp
# src/gl/scene/gl_scene.cpp
# src/hwrenderer/scene/hw_drawinfo.h
# src/hwrenderer/scene/hw_drawlist.cpp
# src/hwrenderer/scene/hw_fakeflat.h
# src/hwrenderer/scene/hw_sprites.cpp
# src/hwrenderer/scene/hw_weapon.cpp
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
