Namely, the ones caused by element numbers already invalid at the time of saving. This makes it impossible to intentionally have invalid element numbers in the low bits of properties listed in CarriesTypeIn, but these bits are considered to be under TPT's control anyway, so this is ok.
This would leave saves opened this way missing elements, but also not produce a warning in the preview, because by that time that preview is made, autorun.lua has been run.
Some people really don't like when an app immediately phones home the moment they open it. This of course means losing automatic notification and motds but oh well.
Broken since a38e1c48bbf0, where older saves were allowed to work off the legacy identity mapping of save numbers to element numbers. The problem was that this could leave even those element numbers mapped that were associated by the palette with unknown element identifiers. These elements would then fail to spawn but would not show up as missing in the save preview.
Still not perfect, see the TODO in the diff.
Like 5103db82887f, this addresses the upload issues experienced on windows, but this time with the official fix from libcurl developers; see the relevant tpt-libs commit.
Broken since 462460b6b3f0, where the break in the old code was thoughtlessly moved to the new code, the issue being that create_part failing doesn't necessarily mean that we're out of particle IDs. I don't think pasting is a hot enough operation for such optimizations to be necessary, so continue should be fine.
Broken since c645269c8625, where we started giving the renderer thread only the live part of Simulation::parts. Or at least intended to, but ended up copying whatever amount we should have copied the previous time around. The flickering was hard to notice because the number of particles rarely changes much between frames.
This should fix the long-standing issue of Create/ChangeType callbacks not being called in all cases when particles were created or changed type.
I'm eagerly awaiting reports of the horrendous crashes this will inevitably cause.
Broken since 02b679aec37f and extremely similar to 74386631e0b6, which makes sure that both LSI and GameView are alive when destroying Lua windows: in this case, they both need to be alive when destroying components attached to the main window. Also, the main window has to exist still.
AFTERSIMDRAW can be composited on the main thread on top of the frame that got rendered in parallel, so there is no reason to have it hinder SRT. This cannot be done with BEFORESIMDRAW, which is applied to the frame before the rest of the sim is rendered. If we had proper associative compositing with pre-multiplied alpha, it could be, but this doesn't really work well with the colour space we're using right now (sRGB, with u8 components).
Completely neglected to normalize the Rect's size. Somehow completely asymptomatic unless looking at the favourites menu if it's too long to fit on the screen, on MacOS. Yeah.
Another in the series of fixes for easily avoidable problems introduced in c2bb77721208 by my infinite wisdom >_>. The previous (and thankfully, first) commit in the series is 8cab4ab73819.
This fixes upload issues (mainly on windows, though I've found no reason why it wouldn't manifest elsewhere also) and enables querying display refresh rate when using xorg.
Floating point nonsense made the common case of draw cap = fps cap sometimes skip frames. This commit essentially duplicates the tick scheduling logic over to draw scheduling, with the exception that the draw schedule's "how much time to sleep" output goes nowhere; instead, we explicitly check whether we should be drawing a frame every tick.
One major downside of SRT is that a RenderableSimulation has to be copied between the main thread and the rendering thread, which may actually take more time than to render on the main thread. This commit reduces the impact of this copy by copying only the subset of RenderableSimulation::parts that actually matters.
In fact, even when it was drawn while unpaused, there would be two different gravity masks being swapped between, and only one of them was what the user wanted. However, there wasn't as much difference between them, because one was just one frame more out of date than the other, so this was hard to notice.
Broken since 6b5bbb177dd5, where I forgot that the gravity mask exists at all. The gravity mass input is thrown away every frame in Simulation, and so that commit applies to it well, but the gravity mask isn't.
C++11 standardizes the "nullptr" keyword, which replaces the
implementation-defined macro null pointer "NULL" or a hardcoded 0.
---------
Co-authored-by: Tamás Bálint Misius <lbphacker@gmail.com>
Meson generators seem to be a dying feature, evidenced by the fact that they have been in a state of isolation from the rest of the language for several years at this point:
- very few things accept generator outputs as inputs, not even generators themselves do
- unlike configured files, their outputs aren't guaranteed to be always synthesized, and yet they can't be passed as dependencies to other targets
- they accept strictly one input and can't depend on other files
This makes them really hard to work with in a context that would require either a project resource or a target. Custom targets don't have any of these shortcomings, so this commit migrates embedded files over to those. A real shame, considering that generators can be used anywhere and are generally less messy than custom targets.
Lists all GitHub contributors and moderators, alongside the original credits (which were moved from the intro text to here)
The UI itself is controlled with credits.json. This can be regenerated with resources/gencredits.py.
Broken since f52e04703731, where Renderer::DumpFrame was removed in favour of constructing VideoBuffers directly from pixel data, but Renderer::video's exact width wasn't taken into account. This was chosen to be WINDOW.X, rather than the intuitive RES.X, in order to enable blitting the sim framebuffer onto the window framebuffer with a single memcpy.
