Mostly. They are now const but only in graphics functions called from secondary Renderers. The primary (main thread) Renderer still allows graphics functions to mutate Simulation; this is required for correct in-PIPE rendering of custom elements.
By factoring element and other static-ish data out of Simulation and protecting basic graphical element properties (i.e. everything that contributes to graphics other than the Graphics callback) with an std::shared_mutex. This is taken exclusively (std::unique_lock) by the main thread when it changes these properties, and inclusively (std::shared_lock) by non-main-thread code that uses Renderer.
PMODE_SPARK does weird colour ops with alpha values larger than 255, so of course it looks odd with the new code that expects alpha to be at most 255. The solution is to do the work on the spot.
Other effects may also be affected by this new assumption.
This had been overlooked for a long time because intensity defaults to 1.0f and is seldom changed. The underlying issue is that an intensity value higher than 1.0f produces fire_alpha values above 255, which the new graphics code doesn't deal with properly. That said, that code works fine for every other case, so the solution is to add a special case for when fire_alpha is used.
This also fixes local save thumbnails being resized such that they are just short of filling the space they are supposed to.
Also fix textboxes drawing their borders in the wrong place.
Also replace a few rename calls with RenameFile calls. Old code doesn't expect rename to overwrite existing files without question, when it in fact can.
Some files have been using various fixed-size types (uint32_t etc.),
which are defined in stdint.h / cstdint, without including said header
file. While this code worked with GCC12 (likely a transitive include),
under GCC13 it fails to build due to "unknown type" errors.
Some operator[]s that know the size of the container they wrap like to assert(index >= 0 && index < size), which is bad for us because we sometimes use &container[size]. This is not undefined behaviour until that pointer is dereferenced, but certain operator[]s choose to ignore this fact and err on the side of caution. The solution is to use &container[0] + size instead of &container[size].
