mirrors/papermc
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
papermc/Spigot-Server-Patches/0072-Optimize-isValidLocation-getType-and-getBlockData-fo.patch

211 lines
9.9 KiB
Diff
Raw Normal View History

Rebuild all patches using the new rebuild pattern
2020-05-06 09:48:49 +00:00
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
From: Aikar <aikar@aikar.co>
Date: Thu, 3 Mar 2016 02:07:55 -0600
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
Subject: [PATCH] Optimize isValidLocation, getType and getBlockData for
inlining
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
Hot methods, so reduce # of instructions for the method.
Move is valid location test to the BlockPosition class so that it can access local variables.
Replace all calls to the new place to the unnecessary forward.
Optimize getType and getBlockData to manually inline and optimize the calls
diff --git a/src/main/java/net/minecraft/server/BaseBlockPosition.java b/src/main/java/net/minecraft/server/BaseBlockPosition.java
Updated Upstream (Bukkit/CraftBukkit) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing My recent work on serialization is now in CraftBukkit so was able to drop the patch and Paper is now consistent with upstream. Bukkit Changes: e2699636 Move API notes to more obvious location CraftBukkit Changes: 1b2830a3 SPIGOT-4441: Fix serializing Components to and from Legacy
2020-06-02 03:15:47 +00:00
index 3f09c24e1cd1bba2809b70b1fa6e89773537d834..7b05bb9edcd059a134cef12cc9fea570217bc601 100644
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
--- a/src/main/java/net/minecraft/server/BaseBlockPosition.java
+++ b/src/main/java/net/minecraft/server/BaseBlockPosition.java
More progress
2019-12-11 02:43:21 +00:00
@@ -13,6 +13,14 @@ public class BaseBlockPosition implements Comparable<BaseBlockPosition> {
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
private final int b;
More progress
2019-12-11 02:43:21 +00:00
@Deprecated
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
private final int c;
+ // Paper start
+ public boolean isValidLocation() {
+ return a >= -30000000 && c >= -30000000 && a < 30000000 && c < 30000000 && b >= 0 && b < 256;
+ }
+ public boolean isInvalidYLocation() {
+ return b < 0 || b >= 256;
+ }
+ // Paper end
public BaseBlockPosition(int i, int j, int k) {
this.a = i;
diff --git a/src/main/java/net/minecraft/server/Chunk.java b/src/main/java/net/minecraft/server/Chunk.java
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
index b85e21202eb8bb9446989aa1d6889eed784762a4..671bcc763c78114f38d2b9b0320d7b168a756e21 100644
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
--- a/src/main/java/net/minecraft/server/Chunk.java
+++ b/src/main/java/net/minecraft/server/Chunk.java
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
@@ -307,12 +307,27 @@ public class Chunk implements IChunkAccess {
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
return this.sections;
}
- @Override
MC 1.14.1
2019-05-14 02:20:58 +00:00
+ // Paper start - Optimize getBlockData to reduce instructions
+ public final IBlockData getBlockData(BlockPosition pos) { return getBlockData(pos.getX(), pos.getY(), pos.getZ()); } // Paper
public IBlockData getType(BlockPosition blockposition) {
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
- int i = blockposition.getX();
- int j = blockposition.getY();
- int k = blockposition.getZ();
+ return this.getBlockData(blockposition.getX(), blockposition.getY(), blockposition.getZ());
+ }
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
+
+ public IBlockData getType(final int x, final int y, final int z) {
+ return getBlockData(x, y, z);
+ }
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
+ public final IBlockData getBlockData(final int x, final int y, final int z) {
+ // Method body / logic copied from below
+ final int i = y >> 4;
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
+ if (y < 0 || i >= this.sections.length || this.sections[i] == null || this.sections[i].nonEmptyBlockCount == 0) {
+ return Blocks.AIR.getBlockData();
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
+ }
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
+ // Inlined ChunkSection.getType() and DataPaletteBlock.a(int,int,int)
+ return this.sections[i].blockIds.a((y & 15) << 8 | (z & 15) << 4 | x & 15);
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
+ }
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
+ public IBlockData getBlockData_unused(int i, int j, int k) {
+ // Paper end
if (this.world.P() == WorldType.DEBUG_ALL_BLOCK_STATES) {
IBlockData iblockdata = null;
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
diff --git a/src/main/java/net/minecraft/server/ChunkEmpty.java b/src/main/java/net/minecraft/server/ChunkEmpty.java
index 82fdd3db6f698f8b77c8bbd1f17cb21980ecfeec..fd49438961451987bd102a85484be24b341d946b 100644
--- a/src/main/java/net/minecraft/server/ChunkEmpty.java
+++ b/src/main/java/net/minecraft/server/ChunkEmpty.java
@@ -7,7 +7,7 @@ import javax.annotation.Nullable;
public class ChunkEmpty extends Chunk {
- private static final BiomeBase[] b = (BiomeBase[]) SystemUtils.a((Object) (new BiomeBase[BiomeStorage.a]), (abiomebase) -> {
+ private static final BiomeBase[] b = (BiomeBase[]) SystemUtils.a((new BiomeBase[BiomeStorage.a]), (abiomebase) -> { // Paper - decompile error
Arrays.fill(abiomebase, Biomes.PLAINS);
});
@@ -15,6 +15,11 @@ public class ChunkEmpty extends Chunk {
super(world, chunkcoordintpair, new BiomeStorage(ChunkEmpty.b));
}
+ // Paper start
+ @Override public IBlockData getType(int x, int y, int z) {
+ return Blocks.VOID_AIR.getBlockData();
+ }
+ // Paper end
@Override
public IBlockData getType(BlockPosition blockposition) {
return Blocks.VOID_AIR.getBlockData();
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
diff --git a/src/main/java/net/minecraft/server/ChunkSection.java b/src/main/java/net/minecraft/server/ChunkSection.java
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
index 638b0e39798a3f75566fcf9ea48b81024e60b471..e72d1386feb59e4a4c27466da96ffd29222bea18 100644
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
--- a/src/main/java/net/minecraft/server/ChunkSection.java
+++ b/src/main/java/net/minecraft/server/ChunkSection.java
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
@@ -6,10 +6,10 @@ public class ChunkSection {
public static final DataPalette<IBlockData> GLOBAL_PALETTE = new DataPaletteGlobal<>(Block.REGISTRY_ID, Blocks.AIR.getBlockData());
private final int yPos;
- private short nonEmptyBlockCount;
+ short nonEmptyBlockCount; // Paper - package-private
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
private short tickingBlockCount;
private short e;
- private final DataPaletteBlock<IBlockData> blockIds;
More progress
2019-12-11 02:43:21 +00:00
+ final DataPaletteBlock<IBlockData> blockIds;
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
public ChunkSection(int i) {
this(i, (short) 0, (short) 0, (short) 0);
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
@@ -23,8 +23,8 @@ public class ChunkSection {
this.blockIds = new DataPaletteBlock<>(ChunkSection.GLOBAL_PALETTE, Block.REGISTRY_ID, GameProfileSerializer::d, GameProfileSerializer::a, Blocks.AIR.getBlockData());
}
- public IBlockData getType(int i, int j, int k) {
- return (IBlockData) this.blockIds.a(i, j, k);
+ public final IBlockData getType(int i, int j, int k) { // Paper
+ return this.blockIds.a(j << 8 | k << 4 | i); // Paper - inline
}
public Fluid b(int i, int j, int k) {
diff --git a/src/main/java/net/minecraft/server/DataPaletteBlock.java b/src/main/java/net/minecraft/server/DataPaletteBlock.java
index d5f5a51872dfabdbb828b6c20d61893aed2efec7..3586fe065f21fbf1e71b602c372a690ef603f377 100644
--- a/src/main/java/net/minecraft/server/DataPaletteBlock.java
+++ b/src/main/java/net/minecraft/server/DataPaletteBlock.java
@@ -125,7 +125,7 @@ public class DataPaletteBlock<T> implements DataPaletteExpandable<T> {
}
public T a(int i, int j, int k) {
- return this.a(b(i, j, k));
+ return this.a(j << 8 | k << 4 | i); // Paper - inline
}
protected T a(int i) {
diff --git a/src/main/java/net/minecraft/server/IChunkAccess.java b/src/main/java/net/minecraft/server/IChunkAccess.java
index 6f25c37658e8e4b31fec2d9e8b69616f073e0b30..2de4796946e79c5fc7a36a1e26cbcad7bca6e12a 100644
--- a/src/main/java/net/minecraft/server/IChunkAccess.java
+++ b/src/main/java/net/minecraft/server/IChunkAccess.java
@@ -13,6 +13,7 @@ import org.apache.logging.log4j.LogManager;
public interface IChunkAccess extends IBlockAccess, IStructureAccess {
+ IBlockData getType(final int x, final int y, final int z); // Paper
@Nullable
IBlockData setType(BlockPosition blockposition, IBlockData iblockdata, boolean flag);
diff --git a/src/main/java/net/minecraft/server/ProtoChunk.java b/src/main/java/net/minecraft/server/ProtoChunk.java
index 39339fa27551b06a9bfd8ea67b1ec8c66726f488..51a5b9cb36c4325df8d1434dcf28d27abefdfede 100644
--- a/src/main/java/net/minecraft/server/ProtoChunk.java
+++ b/src/main/java/net/minecraft/server/ProtoChunk.java
@@ -94,16 +94,18 @@ public class ProtoChunk implements IChunkAccess {
@Override
public IBlockData getType(BlockPosition blockposition) {
- int i = blockposition.getY();
-
- if (World.b(i)) {
+ return getType(blockposition.getX(), blockposition.getY(), blockposition.getZ());
+ }
+ // Paper start
+ public IBlockData getType(final int x, final int y, final int z) {
+ if (y < 0 || y >= 256) {
return Blocks.VOID_AIR.getBlockData();
} else {
- ChunkSection chunksection = this.getSections()[i >> 4];
-
- return ChunkSection.a(chunksection) ? Blocks.AIR.getBlockData() : chunksection.getType(blockposition.getX() & 15, i & 15, blockposition.getZ() & 15);
+ ChunkSection chunksection = this.getSections()[y >> 4];
+ return chunksection == Chunk.EMPTY_CHUNK_SECTION || chunksection.c() ? Blocks.AIR.getBlockData() : chunksection.getType(x & 15, y & 15, z & 15);
}
}
+ // Paper end
@Override
public Fluid getFluid(BlockPosition blockposition) {
diff --git a/src/main/java/net/minecraft/server/ProtoChunkExtension.java b/src/main/java/net/minecraft/server/ProtoChunkExtension.java
index 01bf28dc34dd69dbcee5f470cc71ec2fbb2fcc12..b740e82622e282bdf543a84a559af69dd5b8568c 100644
--- a/src/main/java/net/minecraft/server/ProtoChunkExtension.java
+++ b/src/main/java/net/minecraft/server/ProtoChunkExtension.java
@@ -26,6 +26,11 @@ public class ProtoChunkExtension extends ProtoChunk {
public IBlockData getType(BlockPosition blockposition) {
return this.a.getType(blockposition);
}
+ // Paper start
+ public final IBlockData getType(final int x, final int y, final int z) {
+ return this.a.getBlockData(x, y, z);
+ }
+ // Paper end
@Override
public Fluid getFluid(BlockPosition blockposition) {
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
diff --git a/src/main/java/net/minecraft/server/World.java b/src/main/java/net/minecraft/server/World.java
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 05:25:11 +00:00
index 7f1f0111373fa409e52894e59ac49d5278d0bd58..50c2c4b0dc6256d5fbc361ba9b89b4e17bef8acb 100644
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
--- a/src/main/java/net/minecraft/server/World.java
+++ b/src/main/java/net/minecraft/server/World.java
Workaround for some hacky environments that mess up things 2 people had issues where some plugin is doing some reallly insane NMS hackery that created invalid worlds, which caused some errors... Really don't understand what in the world they did, but putting in a dumb guard that shouldn't even be necessary to just not send the sound effect rather than erroring.
2020-05-24 02:27:37 +00:00
@@ -172,11 +172,11 @@ public abstract class World implements GeneratorAccess, AutoCloseable {
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
}
public static boolean isValidLocation(BlockPosition blockposition) {
MC 1.14.1
2019-05-14 02:20:58 +00:00
- return !isOutsideWorld(blockposition) && blockposition.getX() >= -30000000 && blockposition.getZ() >= -30000000 && blockposition.getX() < 30000000 && blockposition.getZ() < 30000000;
More progress
2019-12-11 02:43:21 +00:00
+ return blockposition.isValidLocation();
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
}
MC 1.14.1
2019-05-14 02:20:58 +00:00
public static boolean isOutsideWorld(BlockPosition blockposition) {
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
- return b(blockposition.getY());
More progress
2019-12-11 02:43:21 +00:00
+ return blockposition.isInvalidYLocation();
More 1.14 updates (#1995)
2019-04-27 03:05:36 +00:00
}
public static boolean b(int i) {
Reference in a new issue Copy permalink