For one, we have already switched to RGBA some time ago, so the name was
technically incorrect already.
But the main reason is that we'll want to use them for depth maps as well (and
potentially maybe even for HDR images if that's possible with canvas?).
Previously you'd access the render queue from the render settings screen which
was arguably the wrong way around (e.g. you weren't able to access the queue
when your current keyframes were incorrect even if you only wanted to render
those in the queue).
Now the render button opens the queue which can open a new settings popup. To
save people who don't need the queue from always having to go through it, the
queue will immediately open a new settings popup if does not yet have any jobs.
Basically the result of the Delombok function, except we use IntelliJ's equals,
hashCode and toString and don't re-organize imports (cause that breaks the
preprocessor) and a bunch of manual cleanup was necessary (and half the classes
weren't even converted).
The fetching of the ticks variable was accidentally moved to before the timer
update while updating to 1.16, this caused the interpolation to be off by one
tick each frame in which the timer advances to the next tick.
Similar to 3fedc22 in effect and cause. However tasks are executed, they just
cannot be submitted pre-1.14 because MC would continuously hold the lock on the
scheduledTasks queue for the entire renderVideo call.
This used to be more of an issue in the past but `displaySizeChanged` has gotten
pretty cheap by now and not updating it will basically make the rendering GUI
useless once you resize even once.
This intentionally breaks the mixin in a development environment but makes the
compiled jar work in a live environment (which is probably more useful given the
primary version is 1.15 now).
The task queue is executed by MC each frame, not just each tick, so we should do
so as well. Most async actions also rely on it to re-synchronize with the
rendering thread, e.g. skins won't load if we never poll the task queue.
This was caused by us setting `needsTerrainUpdate` to false during the shadow
pass in order to break out of the ForceChunkLoading loop (cause OF doesn't
update chunks during the shadow pass). However, this inadvertently caused the
chunk updates to be skipped during the normal pass as well if there didn't
happen to be another reasons for updating.
To fix this, we simply move the shadow pass check into the ForceChunkLoading
mixin and skip the entire loop during the shadow pass.
Jonas Herzig