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.
By tying the lifetimes of the vote request and the queued vote to the online save info. Broken since c73fa1bcdde3, where the vote request was made non-blocking. TODO: Let the user know that their vote may not have gone through if the vote request gets destroyed abnormally.
Displacing the swapped-out particle by the difference between the integer positions (derived from the float position via rounding) of the particles would sometimes cause the floats in Particle to switch to a lower precision range, and this would overflow them such that the integer position would change by an amount different from what was intended (exactly the difference between the integer positions of the particles). Such switches between precision ranges can only happen when a sufficiently big positive number is added to a positive float near the positive end of its current precision range. Swapping displacements are usually small, so this problem mostly manifested near the positive end of precision ranges, that is, near powers of 2.
Informally, for illustrative purposes, consider the float position (either x or y, doesn't matter) 511.49995, fairly close to the positive end of the precision range [256, 512), and the swap displacement +1: these yield the position 512.49995. Assume that this is not be representable, and that the two nearest representable values are 512.4998 and 512.5. 512.49995 is closer to 512.5, so that's what it gets rounded to. But oops, 511 = round(511.49995) + 1 != round(512.5) = 513, so we're now overwriting the wrong pmap entry.
Reproduce with
sim.paused(true)
sim.clearSim()
local brmt = sim.partCreate(-1, 128, 100, elem.DEFAULT_PT_BRMT)
local dust = sim.partCreate(-1, 127, 101, elem.DEFAULT_PT_DUST)
sim.createBox(125, 98, 130, 103, elem.DEFAULT_PT_DMND)
sim.partProperty(dust, "x", 127.49999)
sim.frameRender(2)
The BRMT and the DUST should swap places; instead, without the fix, the DUST gets stacked under a DMND.
This commit fixes this problem by moving the swapped-out particle exactly where the moving particle is.
Non-custom here means any built-in tool but also the ElementTool associated with elements, including custom ones. So, describing the tools this commit affects as "built-in tools" wouldn't quite be correct. It was even possible to cause crashes by freeing such tools.
Also fix crashes when attempting to access non-custom tools as if they were custom tools. The incorrect assumption was that GameModel::GetToolIndex succeeding means that LuaScriptInterface::customTools has an entry for the tool, but this is only guaranteed for custom tools.
This considerably speeds up linking of release binaries with msvc when testing locally, when LTO is of no concern.
Also properly override b_lto and b_vscrt in all cases for all targets, never leaving them to take default values.
Gravity has been possible to save since 7e9d9686dda4, but the gravity process's definition of when there is work to be done wasn't adjusted accordingly. Thus, when the user manually changed the gravity force (the output of the gravity process) by e.g. pasting over it, it would stay, not quite broken, but very much out of place.
The definition of when there is work to be done is more or less "when the input to the gravity process has changed"; this is about to be extended to cover some other situations by the next commit.
In the vast majority of cases (i.e. when Gravity::Exchange is indirectly called from BeforeSim), the input is cleared to zeros anyway, so it's less work in Exchange to actually just exchange the old input with the new one than to copy the new one into the old one.
Also make gravity functions private in Simulation.
Aka episode 29743 of game mvc being a joke: Happens since 74386631e0b6, where GameModel started being destroyed after GameView. The problem is that GameModel assumes that GameView is still alive and tells it to stop rendering the simulation on another thread, and expects it to acknowledge this request.
This fixes two kinds of crashes: the one where the value passed is not possible to convert at all to the type of value expected (e.g. expect unsigned integer, get point), and also when it is possible, because the difference is only in signedness (e.g. expect unsigned integer, get signed integer). Both cases crash since 8552aafbceb7, where the handling of the former case got removed and accidentally never got added back, and the handling of the latter changed from converting everything to strings and working from there to converting directly between floats and numbers, disregarding signedness.
Broken since 02b679aec37f, where GameView started popping everything above itself before popping itself. The problem was that LSI would get destroyed before GameView did this, but popping Lua windows needed LSI to be alive still.
Broken since 00ec4e0754d1, when the Perform callback was added. It's a bad idea to pop return values that never got pushed because the function that was supposed to push them threw an error.
Broken since 06e28367266e, which added LuaSmartRef. That it had absolutely not followed the rule of five at all didn't use to be a problem because it had only ever been in vectors that got resized only once throughout the lifetime of the program >_>
This is intended to support selection-time configuration the way PROP and the custom life tools do it. Indeed, they now use the infrastructure this commit adds to implement their own configuration actions.
