More updating #18
Open
More updating #18
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
Also fixes some issues in ThinGL where extensions weren't being used.
#628) Both the TRANSLUCENT and TRIPWIRE render layers are rendered with translucency, however Sodium treats the TRIPWIRE render layer as if it were opaque for the purposes of determining whether chunks should be sorted back to front or front to back.
The slider thumb in the slider control previously could render outside of the slider area when the value of the slider was outside of its maximum range. While this shouldn't happen during normal use, it could occur if the game options file was manually edited, which is common in speedrunning when the player wants maximum brightness. Instead of having the slider thumb render outside of the slider area when situations like this occur, we can limit its position to be within the minimum and maximum values of the slider.
Previously, when adjusting a value using the slider control, the range of the mouse was shortened by 4 pixels on each side. This meant that if the mouse was four pixels inside from the left of the slider, the value would incorrectly set as the minimum. This offset has been removed to make the positioning of the slider control and the set value the same, preventing "drift" of the slider thumb.
Previously, control elements kept their fields when modified options were undone. This caused issues when changing a control element and pressing "Undo," because fields such as the slider position of the slider control or the current index of the cycle control were not reset. To solve these issues, the control elements that need to be reset on undo now implement a reset interface, which allows them to reset these fields.
Removes the resettable interface, because we can update the values through existing methods in each control instead. Co-authored-by: Yao Chung Hu <[email protected]>
The current and modified option values in the Sodium options need to be compared to see if the value is changed or not. Previously, this was done using the == operator. However, since the current and modified options are wrapper types, it will compare them as references, making them inequal when their values are the same. This issue does not happen in a majority of the Sodium options, since Java may cache the objects as values. To solve this issue, the current and modified options can be compared using equals(), which will compare by value instead.
Previously, button widgets that were not visible could be clicked on, since only the enabled state of the button was considered if action should be taken or not. To fix this issue, button widgets will also consider their own visibility state when taking action after a click.
Previously, the rendering of rectangles and quads in the Sodium GUI was defined using integers. This restricted the position of widgets to each in-game pixel, meaning using a scaled GUI scale would cause the rendered position to be incorrect in some scenarios. For example, a user on a HiDPI display using a GUI scale of 8 would not see the brightness slider thumb move when setting it from 0 to 1, because it must be aligned to every in-game pixel (in this scenario, each in-game pixel is 8 real pixels on the display, because of a GUI scale of 8). To solve this, the rendering of rectangles and quads now uses doubles to define position, allowing for greater positioning precision when needed.
This is one of my messier commits, but it's late and trying to break this up is too much work. - Fixed some occlusion culling problems caused by the chunk building step not always updating a position vector, resulting in the occlusion data having data set for the previous block position when an air block is encountered. - Split world slicing into two stages to enable faster render task creation. This introduces a lot of changes, but primarily means the main render thread can simply focus on copying memory to a new thread without needing to unpack it immediately. - Fixed a problem where vertex lighting was reading from the client world object directly instead of our copied slice, resulting in horrible performance and thread safety problems.
# Conflicts: # src/main/java/me/jellysquid/mods/sodium/client/gui/SodiumGameOptions.java
Several mods (primarily LambdaBetterGrass) require extra context in chunk rendering, that isn't provided by the 18x18x18 (5832 blocks) chunk section copy that Sodium makes. This change increases it to 20x20x20 (8000 blocks), which matches vanilla - so all mods should expect to have this radius of context for rendering. Unfortunately, as more blocks are being copied, this will impact chunk building performance very slightly, though much better than my original 48x48x48 change. Other methods for increasing this radius without affecting performance (as this is very hot code) may be worth exploring, though it may not be worth the additional complexity. The change has been tested in my Sodium fork, though the performance implications have not been directly measured.
Merges #672 Co-authored-by: FionaTheMortal <[email protected]>
Not sure what Git is doing here.
(this has been bugging me for a long while)
…n copyBufferSubData
Allows for F3 hotkeys to work, since they don't go through our video settings screen. This is kind of a hack, but it's what vanilla does anyways.
Helps to improve performance on AMD/NVIDIA GPUs
|
building this makes immersive portals complain about incompatible sodium, which is sad |
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.
No description provided.