Terrain culling is only updated when the camera position or rotation changes.
For omnidirectional rendering, we don't change the camera directly though, we
rotate way earlier so we can consistently get before any other effects. As a
result, the terrain frustum culling wasn't updated between render passes
resulting in missing terrain.
This was largely masked by the fact that we used to call GameRenderer.onResize
every pass (even when the size hadn't changed) but fixing that made this issue
become apparent.
Instead of setting the the values via accessor and calling the handler directly.
This allows mods like ResolutionControl+ to properly resize its internal
framebuffers as well.
The only thing we care about is the framebuffer size, cause that will differ
between game and progress gui rendering. The window size will be the same (real)
size for both.
This makes it work more like regular 360 mode and is generally more compatible
because it doesn't require the frustum culling workarounds which the GPU
solution needs.
In particular, this fixes frustum culling with newer sodium versions (which no
longer use the vanilla intersection checking method) and fixes the clouds on
modern Iris (which seems to be using a different shader program for clouds).
9c5dec8 Fix writing of empty chunk load packet on 1.8.x (fixes#636)
3d8573f Fix writing of respawn packet on 1.8.x
39a85f7 Fix exception when cache file has invalid gzip header (fixes#535)
Fixes an issue where the world border would move at normal speed when speeding up or slowing down the replay, and also at an incorrect speed when rendering the replay, causing it to get out of sync with the rest of the world.
Co-authored-by: Jonas Herzig <me@johni0702.de>
Should be more compatible with mods which replace the entire renderHand
method (thereby making our mixin non-applicable), at least as long as these mods
check `renderHand` as well (Iris explicitly does).
This will become important once #638 is fixed.
This fixes the rotation of already existing entities that just got sent to the
client. Those get spawned with their rotation, which we didn't capture. This
commit fixes that by initializing our tracked rotation to NaN and returning the
original rotation until the tracked one is initialized (we do it this way rather
than initializing during the spawn packet handling because there are many spawn
packets, especially with modded, and we cannot possibly inject into all of
them).
This does not fix the rotation of newly placed entities (cause they seem to get
spawned with 0/0 and then get teleported to their correct rotation). The
previous commit fixed that case by capturing the rotation from the teleport
packet.
This fixes the rotation of newly placed entities (cause they seem to get spawned
with 0/0 and then get teleported to their correct rotation, which we didn't
capture).
This does not fix the rotation of already existing entities that just got sent
to the client, those already get spawned with their rotation, which we don't yet
capture. The following commit fixes that.
By updating the shadow plugin used in ReplayStudio.
java.lang.IncompatibleClassChangeError: Inconsistent constant pool data in classfile for class com/replaymod/replaystudio/lib/viaversion/libs/kyori/adventure/text/Component. Method 'boolean lambda$static$0(com.replaymod.replaystudio.lib.viaversion.libs.kyori.adventure.text.Component, com.replaymod.replaystudio.lib.viaversion.libs.kyori.adventure.text.Component)' at index 1064 is CONSTANT_MethodRef and should be CONSTANT_InterfaceMethodRef
