BME-170 Groundcover transparency fix#93
BME-170 Groundcover transparency fix#93maddie-j wants to merge 13 commits intoLordFokas:mc-1.18.2-v0.8.0-overhaulfrom
Conversation
Small fixes: BME-143 ctrl + f, BME-186 minimap coords fix, BME-190 update mods list
Version bump only: v0.5.20-beta
Pulling in improvements made to v0.5 after fork
| if (processedBlock.totalColor <= 0) { | ||
| continue; | ||
| } | ||
|
|
There was a problem hiding this comment.
This inequality was causing issues when the alpha value caused the signed int that represented the colour to have a negative sign. Will explain more further down where the appropriate fix is.
| // Fallback 1: get block tint | ||
| if(color == 0) { | ||
| color = blockColors.getColor(state, level, blockPos, 0); | ||
| } | ||
|
|
||
| // Fallback 2: get block map color | ||
| if(color <= 0) { | ||
| MaterialColor mapColor = state.getMapColor(level, blockPos); | ||
| if(mapColor != MaterialColor.NONE) { | ||
| color = mapColor.col; | ||
| // Fallback 2: get block map color | ||
| // These magic numbers are dependent on blockColors.getColor's return value specifically | ||
| if(color == 0 || color == -1) { | ||
| MaterialColor mapColor = state.getMapColor(level, blockPos); | ||
| if(mapColor != MaterialColor.NONE) { | ||
| color = mapColor.col; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Because the colour is stored in an int, and ints in Java are always signed, a colour with an alpha value that turned the int representation negative would accidentally get caught up in this conditional.
As -1 is a "magic number" being returned from getMapColor to show "not found", can check for it explicitly (plus a complete transparency that gets represented as 0) so valid values that happen to have a negative representation when presented as an int aren't accidentally caught in the crossfire.
This is also why "Fallback 2" is being explicitly moved inside the same if block as "Fallback 1". It uses the magic numbers returned by "Fallback 1", so should only apply in that instance. Any values that don't fall into the "Fallback 1" condition are treated as valid.
| * These blocks don't return accurate colours using the other methods, | ||
| * so unfortunately need to set a colour manually | ||
| */ | ||
| protected static int handleSpecialCases(BlockState state) { |
There was a problem hiding this comment.
No need for this special cases logic now we're getting values from textures instead of MapColors!
| g += (255 * pixel[2] * alpha); | ||
| b += (255 * pixel[1] * alpha); | ||
| total++; | ||
| total += alpha; |
There was a problem hiding this comment.
This change required so the numbers don't get thrown off later when alpha != 1
| TransparencyState.isAtLeastAsTransparentAs( | ||
| blockComposition.getTransparencyState(), | ||
| TransparencyState.SEMI_TRANSPARENT | ||
| TransparencyState.SLIGHTLY_TRANSPARENT |
There was a problem hiding this comment.
Just a namechange of this enum value, since SEMI_TRANSPARENT has grown to be way more opaque since originally defined and I need to differentiate it from the new, middle HALF_TRANSPARENT enum value with an opacity set to exactly 0.5.
| if (BlazeMapConfig.CLIENT.clientFeatures.displayCoords.get()) { | ||
| Vec3 pos = Helpers.getPlayer().position(); | ||
| String coords = String.format("[ %d | %d | %d ]", (int) pos.x, (int) pos.y, (int) pos.z); | ||
| BlockPos pos = Helpers.getPlayer().blockPosition(); | ||
| String coords = String.format("[ %d | %d | %d ]", pos.getX(), pos.getY(), pos.getZ()); |
There was a problem hiding this comment.
This change is the change that fixes the coordinates from being half a block off. Brought over from the v0.5 branch.
| if(key == GLFW.GLFW_KEY_F && Screen.hasControlDown() && search.isVisible() && !search.isFocused()) { | ||
| this.setFocused(search); | ||
| search.setFocus(true); | ||
| return true; | ||
| } | ||
|
|
There was a problem hiding this comment.
This change is the change that allows ctrl + F to focus the search bar. This was brought over from the v0.5 branch.
Considering there isn't a search bar right now in the v0.8 branch, this currently does nothing. But I'd already picked it across, and it doesn't break anything AFAICT, so assuming Me From The Past was making sense.
There was a problem hiding this comment.
Just realised I've got a merge conflict here. Given the reimplementation is quite different and seems to be incomplete, will just remove this change for now and will have to put in a ticket to reimplement later
|
|
||
| add(PROBLEM, ModIDs.OPTIFINE); | ||
| add(PROBLEM, ModIDs.CHUNKPREGEN); | ||
| add(PROBLEM, ModIDs.FANCY_MENU); |
There was a problem hiding this comment.
Final unrelated commit. Picked across from the v0.5 branch.
We'd confirmed that ChunkPregen was no longer an issue, but that Fancy Menu was. So out with the old, in with the new!
| private static final Set<TagKey<Block>> quiteTransparentBlockTags = initialiseTransparentBlockSet(true); | ||
| // TODO: See if I need to make these threadsafe datastructures | ||
| private static final SortedSet<TransparencyMapping> transparentBlockTypes = initialiseTransparentBlocks(); | ||
| private static final SortedSet<TransparencyMapping> transparentFluidTypes = initialiseTransparentFluids(); |
There was a problem hiding this comment.
I completely refactored how transparency mappings are stored to make it a lot better. Now, you give a block identifier, you give its TransparencyState, and you give a priority, and those values are used to let you query how transparent a block is.
It's probably more useful to read these changes "side-by-side" in the GitHub editor because there's just not much of the original code for the mappings left.
…to BME-170-fix-foliage-transparency
2 participants
Doing some fixes following the change in colour sourcing to texture files, mainly revolving around how that change interacts with transparency + non-solid blocks like flowers.
A before and after from the standard testing area. Note that the "before" is from the current main branch, which is now several changes ahead from where I started my changes:
There are still some things surrounding the transparency and shadows that I want to heavily refactor to fix, as outlined in the Discord, especially to help with the dire performance cost of collection over oceans. But this was enough of an improvement that I wanted to get this out before it stayed unpushed on my local for another year...
Note: There are a few bugfix commits it looks like I cherry picked over from the original 1.18.2 branch back before I left things off. They need to be fixed anyways, and I'm not changing the history of this branch to break them off into their own PRs! Will leave a comment to point them out as necessary.