Merge Upstream #96
Merged
Merge Upstream #96
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Documentation fix for rednet.broadcast
See #1061, closes #1064. Nobody ever seems to implement this correctly (though it's better than 1.12, at least we've not seen any crashes), and this isn't a fight I care enough about fighting any more.
Closes #1072
A little shorter and more explicit than constructing the Vector3d manually. Fixes an issue where sounds were centered on the bottom left of speakers, not the middle (see cc-tweaked#85).
"Instead, it is a standard program, which its API into the programs that it launches." becomes "Instead, it is a standard program, which injects its API into the programs that it launches."
Moved to illuaminate itself
Just a precursor to doing any work on it.
- Move all RenderType instances into a common class. Cherry-picked from 41fa95b: - Render GL_QUADS instead of GL_TRIANGLES. - Remove any "immediate mode" methods from FWFR. Most use-cases can be replaced with the global MultiBufferSource and a proper RenderType (which we weren't using correctly before!). Only the GUI code (WidgetTerminal) needs to use the immediate mode. - Pre-convert palette colours to bytes, storing both the coloured and greyscale versions as a byte array. Cherry-picked from 3eb601e: - Pass lightmap variables around the various renderers. Fixes #919 for 1.16!
The VBO renderer needs to generate a buffer with two quads for each cell, and then transfer it to the GPU. For large monitors, generating this buffer can get quite slow. Most of the issues come from IVertexBuilder (VertexConsumer under MojMap) having a lot of overhead. By emitting a ByteBuffer directly (and doing so with Unsafe to avoid bounds checks), we can improve performance 10 fold, going from 3fps/300ms for 120 monitors to 111fps/9ms. See 41fa95b and #1065 for some more context and other exploratory work. The key thing to note is we _need_ a separate version of FWFR for emitting to a ByteBuffer, as introducing polymorphism to it comes with a significant performance hit.
This takes a non-trivial amount of time on the render thread[^1], so worth doing. I don't actually think the allocation is the heavy thing here - VisualVM says it's toWorldPos being slow. I'm not sure why - possibly just all the block property lookups? [^2] [^1]: To be clear, this is with 120 monitors and no other block entities with custom renderers. so not really representative. [^2]: I wish I could provide a narrower range, but it varies so much between me restarting the game. Makes it impossible to benchmark anything!
Like #455, this sets our uniforms via a UBO rather than having separate ones for each value. There are a couple of small differences: - Have a UBO for each monitor, rather than sharing one and rewriting it every monitor. This means we only need to update the buffer when the monitor changes. - Use std140 rather than the default layout. This means we don't have to care about location/stride in the buffer. Also like #455, this doesn't actually seem to result in any performance improvements for me. However, it does make it a bit easier to handle a large number of uniforms. Also cleans up the generation of the main monitor texture buffer: - Move buffer generation into a separate method - just ensures that it shows up separately in profilers. - Explicitly pass the position when setting bytes, rather than incrementing the internal one. This saves some memory reads/writes (I thought Java optimised them out, evidently not!). Saves a few fps when updating. - Use DSA when possible. Unclear if it helps at all, but nice to do :).
- For TBOs, we now pass cursor position, colour and blink state as variables to the shader, and use them to overlay the cursor texture in the right place. As we no longer need to render the cursor, we can skip the depth buffer, meaning we have to do one fewer upload+draw cycle. - For VBOs, we bake the cursor into the main VBO, and switch between rendering n and n+1 quads. We still need the depth blocker, but can save one upload+draw cycle when the cursor is visible. This saves significant time on the TBO renderer - somewhere between 4 and 7ms/frame, which bumps us up from 35 to 47fps on my test world (480 full-sized monitors, changing every tick). [Taken on 1.18, but should be similar on 1.16]
Historically I've been reluctant to do this as people might be running Optifine for performance rather than shaders, and the VBO renderer was significantly slower when monitors were changing. With the recent performance optimisations, the difference isn't as bad. Given how many people ask/complain about the TBO renderer and shaders, I think it's worth doing this, even if it's not as granular as I'd like. Also changes how we do the monitor backend check. We now only check for compatibility if BEST is selected - if there's an override, we assume the user knows what they're doing (a bold assumption, if I may say so myself).
This /significantly/ improves performance of the VBO renderer (3fps to 80fps with 120 constantly changing monitors) and offers some minor FPS improvements to the TBO renderer. This also makes the 1.16 rendering code a little more consistent with the 1.18 code, cleaning it up a little in the process. Closes #1065 - this is a backport of those changes for 1.16. I will merge these changes into 1.18, as with everything else (oh boy, that'll be fun). Please note this is only tested on my machine right now - any help testing on other CPU/GPU configurations is much appreciated.
I was right: I did not enjoy this.
GlStateManager.glDeleteBuffers clears a buffer before deleting it on Linux - I assume otherwise there's memory leaks on some drivers? - which clobbers BufferUploader's cache. Roll our own version which resets the cache when needed. Also always reset the cache when deleting/creating a DirectVertexBuffer.
I hate doing this, but I have too many merges in progress to rebase.
- Bump Forge version to latest RB. - Generate an 8-bit audio stream again, as we no longer need to be compatible with MC's existing streams. No functionality changes, just mildly less hacky.
> Modulo any game-breaking bugs [...] this will be the last CC: Tweaked > release. Terrible performance is game-breaking right? Or am I just petty?
Fixes printouts being drawn slightly offset to the left in all cases, noticeable mainly when in item frames.
This allows us to sync the position to the entity immediately, rather than the sound jumping about. Someone has set up rick-rolling pocket computers (<3 to whoever did this), and the lag on them irritates me enough to fix this. Fixes #1074
toad-dev
force-pushed
the
patch/merge-upstream
branch
from
3b090cf to
353e1d4
Compare
SquidDev
requested changes
May 5, 2022
src/main/java/dan200/computercraft/shared/peripheral/speaker/SpeakerPosition.java
Show resolved
Hide resolved
toad-dev
force-pushed
the
patch/merge-upstream
branch
from
353e1d4 to
8a3ea6b
Compare
SquidDev
approved these changes
May 7, 2022
|
safe to merge now? |
|
Yes, it's ready. |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Squid did some wizardry to make monitor rendering even faster, and made moving speaker sounds more fluid.