SteamWar/Paper-Old
Archiviert
13
0
Fork 0
Code Issues Pull-Requests Projekte Releases Wiki Aktivität
Dieses Repository wurde am 2024-12-25 archiviert. Du kannst Dateien ansehen und es klonen, aber nicht pushen oder Issues/Pull-Requests öffnen.
438ee3f487
Paper-Old/Spigot-Server-Patches/0378-Optimize-Light-Recalculations.patch

78 Zeilen
4.0 KiB
Diff
Originalformat Normale Ansicht Verlauf

Fix many light bugs by removing recheckGaps change Fixes #1539 Fixes #1483
2018-10-06 06:56:20 +02:00
From dbce8545b454b4c8cbc4cb3d5e6d31eb400edce1 Mon Sep 17 00:00:00 2001
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
From: Aikar <aikar@aikar.co>
Date: Fri, 28 Sep 2018 20:46:29 -0400
Subject: [PATCH] Optimize Light Recalculations
The server triggers light recalculations even if the new block
is the same as the old block. At this time, BlockData Properties
do not impact light calculations.
So the only way light should change, is if the block itself
changes from 1 block to another.
Optimize some light chunk access light calculations repeatedly looks up the same chunk while going down on the Y access. Pass the chunk to it to skip many round trips to the map lookup process. while the gains arent as big since we have last access cache, it should hopefully avoid many callstacks of depth and improve inlining, as well as avoids entering a synchronized code block. The avoiding of entering synchronized section is the main goal here.
2018-10-03 03:55:30 +02:00
Also optimizes to not repeatedly look up the same chunk for
light lookups.
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
diff --git a/src/main/java/net/minecraft/server/Chunk.java b/src/main/java/net/minecraft/server/Chunk.java
Fix many light bugs by removing recheckGaps change Fixes #1539 Fixes #1483
2018-10-06 06:56:20 +02:00
index 33d52447be..c6b002bb6b 100644
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
--- a/src/main/java/net/minecraft/server/Chunk.java
+++ b/src/main/java/net/minecraft/server/Chunk.java
Fix many light bugs by removing recheckGaps change Fixes #1539 Fixes #1483
2018-10-06 06:56:20 +02:00
@@ -347,7 +347,7 @@ public class Chunk implements IChunkAccess {
Optimize some light chunk access light calculations repeatedly looks up the same chunk while going down on the Y access. Pass the chunk to it to skip many round trips to the map lookup process. while the gains arent as big since we have last access cache, it should hopefully avoid many callstacks of depth and improve inlining, as well as avoids entering a synchronized code block. The avoiding of entering synchronized section is the main goal here.
2018-10-03 03:55:30 +02:00
private void a(int i, int j, int k, int l) {
if (l > k && this.areNeighborsLoaded(1)) { // Paper
for (int i1 = k; i1 < l; ++i1) {
- this.world.c(EnumSkyBlock.SKY, new BlockPosition(i, i1, j));
+ this.world.updateBrightness(EnumSkyBlock.SKY, new BlockPosition(i, i1, j), this); // Paper
}
this.x = true;
Fix many light bugs by removing recheckGaps change Fixes #1539 Fixes #1483
2018-10-06 06:56:20 +02:00
@@ -578,7 +578,7 @@ public class Chunk implements IChunkAccess {
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
} else {
if (flag1) {
this.initLighting();
- } else {
Remove Water optimization from the Light Optimizations case was found where it could cause light to become incorrect But we still get to optimize out any same block updates which reduces light operations
2018-09-29 04:37:43 +02:00
+ } else if (block != block1) { // Paper - Optimize light recalculations
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
this.runOrQueueLightUpdate(() -> { // Paper - Queue light update
int i1 = iblockdata.b(this.world, blockposition);
int j1 = iblockdata1.b(this.world, blockposition);
diff --git a/src/main/java/net/minecraft/server/World.java b/src/main/java/net/minecraft/server/World.java
Optimize some light chunk access light calculations repeatedly looks up the same chunk while going down on the Y access. Pass the chunk to it to skip many round trips to the map lookup process. while the gains arent as big since we have last access cache, it should hopefully avoid many callstacks of depth and improve inlining, as well as avoids entering a synchronized code block. The avoiding of entering synchronized section is the main goal here.
2018-10-03 03:55:30 +02:00
index 13f69f1b82..4179ba7cd8 100644
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
--- a/src/main/java/net/minecraft/server/World.java
+++ b/src/main/java/net/minecraft/server/World.java
@@ -444,7 +444,7 @@ public abstract class World implements IEntityAccess, GeneratorAccess, IIBlockAc
} else {
IBlockData iblockdata2 = this.getType(blockposition);
- if (iblockdata2.b(this, blockposition) != iblockdata1.b(this, blockposition) || iblockdata2.e() != iblockdata1.e()) {
Remove Water optimization from the Light Optimizations case was found where it could cause light to become incorrect But we still get to optimize out any same block updates which reduces light operations
2018-09-29 04:37:43 +02:00
+ if (iblockdata.getBlock() != iblockdata2.getBlock() && iblockdata2.b(this, blockposition) != iblockdata1.b(this, blockposition) || iblockdata2.e() != iblockdata1.e()) { // Paper - optimize light recalculations
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
this.methodProfiler.a("checkLight");
chunk.runOrQueueLightUpdate(() -> this.r(blockposition)); // Paper - Queue light update
this.methodProfiler.e();
Optimize some light chunk access light calculations repeatedly looks up the same chunk while going down on the Y access. Pass the chunk to it to skip many round trips to the map lookup process. while the gains arent as big since we have last access cache, it should hopefully avoid many callstacks of depth and improve inlining, as well as avoids entering a synchronized code block. The avoiding of entering synchronized section is the main goal here.
2018-10-03 03:55:30 +02:00
@@ -588,8 +588,9 @@ public abstract class World implements IEntityAccess, GeneratorAccess, IIBlockAc
}
if (this.worldProvider.g()) {
- for (i1 = k; i1 <= l; ++i1) {
- this.c(EnumSkyBlock.SKY, new BlockPosition(i, i1, j));
+ Chunk chunk = getChunkIfLoaded(i >> 4, j >> 4); // Paper
+ for (i1 = k; chunk != null && i1 <= l; ++i1) { // Paper
+ this.updateBrightness(EnumSkyBlock.SKY, new BlockPosition(i, i1, j), chunk); // Paper
}
}
@@ -2293,6 +2294,11 @@ public abstract class World implements IEntityAccess, GeneratorAccess, IIBlockAc
public boolean c(EnumSkyBlock enumskyblock, BlockPosition blockposition) {
// CraftBukkit start - Use neighbor cache instead of looking up
Chunk chunk = this.getChunkIfLoaded(blockposition.getX() >> 4, blockposition.getZ() >> 4);
+ // Paper start - optimize light updates where chunk is known
+ return updateBrightness(enumskyblock, blockposition, chunk);
+ }
+ public boolean updateBrightness(EnumSkyBlock enumskyblock, BlockPosition blockposition, Chunk chunk) {
+ // Paper end
if (chunk == null || !chunk.areNeighborsLoaded(1) /*!this.areChunksLoaded(blockposition, 17, false)*/) {
// CraftBukkit end
return false;
Optimize Light Recalculations The server triggers light recalculations even if the new block is the same as the old block. At this time, BlockData Properties do not impact light calculations. So the only way light should change, is if the block itself changes from 1 block to another. Additionally, as of 1.13, water now only blocks 1 light level instead of 3, meaning that light level decreasing is the same as air. This means, transitions between water and air also do not need to recalculate light, which saves a TON of updates caused by fluids flowing.
2018-09-29 03:30:03 +02:00
--
2.19.0
In neuem Issue referenzieren Permalink kopieren