OpenSource/PaperMC
OpenSource/PaperMC
1
0
Fork 0
mirror of https://github.com/PaperMC/Paper.git synced 2024-11-25 00:30:25 +01:00
Code Issues Projects Releases Packages Wiki Activity
PaperMC/Spigot-Server-Patches/0378-Optimize-Light-Recalculations.patch

69 lines
3.2 KiB
Diff
Raw Normal View History

Fix NPE when setting a player's spectator target (#1596) Fix NPE when setting a player's spectator target
2018-10-21 21:27:53 +02:00
From 1b68fda5180070010d05a20a1c0b8b2fc820f6b9 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 NPE when setting a player's spectator target (#1596) Fix NPE when setting a player's spectator target
2018-10-21 21:27:53 +02:00
index cb998887..027f9863 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
Fix NPE when setting a player's spectator target (#1596) Fix NPE when setting a player's spectator target
2018-10-21 21:27:53 +02:00
index bbcedb8f..540d237c 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
Improvements to Logging Warnings/Dupe Entities - Resolves #1544 1) Removed "Regen" mode of Dupe UUID resolver, forced safe. Some servers who updated before we had safe mode added still had this value. There's really no reason to keep this mode, as we've seen that vanilla triggers this often and 99.9999999% of cases will be an actual duplicate that needs to be deleted. 2) Made Vanilla Debug messages about dupe UUIDs and dupe uuid resolve messages only show up if the debug.entities flag is on. This will stop server owners from panicing from seeing these logs, and stop opening bug reports on this, only for us to tell you "don't worry about it". 3) Avoid adding entities to world that are already added to world. This can be triggered by anything that causes an entity to be added to the world during the chunk load process, such as chunk conversions. Issue #1544 was a case of this. 4) Removed debug warning about ExpiringMap. Nothing more I know to do about this anyways. We recover from it, stop warning to reduce noise of issues to us.
2018-10-07 20:58:53 +02:00
@@ -589,8 +589,9 @@ public abstract class World implements IEntityAccess, GeneratorAccess, IIBlockAc
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
}
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
}
}
Improvements to Logging Warnings/Dupe Entities - Resolves #1544 1) Removed "Regen" mode of Dupe UUID resolver, forced safe. Some servers who updated before we had safe mode added still had this value. There's really no reason to keep this mode, as we've seen that vanilla triggers this often and 99.9999999% of cases will be an actual duplicate that needs to be deleted. 2) Made Vanilla Debug messages about dupe UUIDs and dupe uuid resolve messages only show up if the debug.entities flag is on. This will stop server owners from panicing from seeing these logs, and stop opening bug reports on this, only for us to tell you "don't worry about it". 3) Avoid adding entities to world that are already added to world. This can be triggered by anything that causes an entity to be added to the world during the chunk load process, such as chunk conversions. Issue #1544 was a case of this. 4) Removed debug warning about ExpiringMap. Nothing more I know to do about this anyways. We recover from it, stop warning to reduce noise of issues to us.
2018-10-07 20:58:53 +02:00
@@ -2294,6 +2295,11 @@ public abstract class World implements IEntityAccess, GeneratorAccess, IIBlockAc
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
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
--
Fix Light Bugs - Fixes #1542 Applied a "Only run this when the blocks are different" to a place, that apparently must be called even with the same block but different other data I guess. This was causing oddness with light data.
2018-10-09 02:27:13 +02:00
2.19.1
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
Reference in a new issue Copy permalink