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.
Rendering bits got restructured and the SSE_MATTERS paths were not updated
to reflect that. A 32-bit build with clang subsequently complaints as the
files in question are not compiled with -mmmx.
During serialization, when map shutdown because of unknown class stored inside saved game may occur, level member is not assigned yet to already spawned thinkers
The message is always printed for any use of deprecated global variable
If such variable is accessed inside a deprecated function from a core script lump, the message is printed only when verbosity level is set to highest
https://forum.zdoom.org/viewtopic.php?t=64830
Script position is now initialized at the very beginning of decorate parsing process
Script position no longer contains uninitialized file name
https://forum.zdoom.org/viewtopic.php?t=64836
There was no read barrier inserted for AActor object while it's a subject of garbage collection
Pointer stored in TObjPtr<> was reinterpreted as void* because of vararg function
https://forum.zdoom.org/viewtopic.php?t=64771
The Romanian letters with comma below, the second Greek Sigma variant and a few special Cyrillic letters have replacements that should not result in rejection.
This turned out the smallest one on which a factor of 2 still works without cutting off texts but at least allows to use a larger menu display on this important laptop size.
* Fixes for Door_AnimatedClose
- Fixing that Door_AnimatedClose would be activated on an already closed door (playing the sound and the 1st frame of the animation)
- There was no check if the Door is already Animated when a tag was used with Door_AnimatedClose
* Removed doubled "door->StartClosing();".
Aside from using incorrect values this could crash the renderer if used in the very first rendering frame because the software renderer always operates on a copy.
Now it's no longer possible to manipulate TID hash from arbitrary location
For example, this prevents linking of destroyed object into the hash
TID member is still public but writing to it is limited to a few very specific cases like serialization and player traveling between levels
https://forum.zdoom.org/viewtopic.php?t=64476
