Optimize the performance of block detection and light source judgment in Minecraft Forge 1.19.2

This article aims to provide strategies for optimizing the block detection and light source judgment logic around the player during the development of the Minecraft Forge 1.19.2 module. In view of the performance problems caused by repeatedly obtaining block status and brightness information in common codes, we will discuss how to improve the readability, maintainability and CPU efficiency of the code by introducing local variables, clearly separating logical judgments, and using data structures to simplify the code.

In the development of Minecraft Forge modules, developers often encounter performance bottlenecks, especially when dealing with the logic of blocks around the player. A typical scenario is to traverse blocks within a certain radius and judge based on their type or brightness. If not handled properly, such operations may overload the CPU and affect the smoothness of the game.

1. Common patterns of inefficient block detection

A common inefficiency pattern when detecting blocks around the player is to repeatedly call the world.getBlockState() and world.getMaxLocalRawBrightness() methods. Consider the following simplified code snippet, which demonstrates this repetitive problem:

 // Assume that in a loop, currentPos represents (x sx, y sy, z sz)
if (world.getBlockState(currentPos).getBlock() == Blocks.TORCH
    || world.getBlockState(currentPos).getBlock() == Blocks.WALL_TORCH
    || world.getBlockState(currentPos).getBlock() == Blocks.FIRE
    || (world.getBlockState(currentPos).getBlock() == Blocks.CAMPFIRE && world.getMaxLocalRawBrightness(currentPos) == 15)
    // ... more similar duplicate judgments) {
    //Execute related logic}

There are the following main problems with this implementation:

• Repeated method calls: For the same BlockPos, world.getBlockState() and world.getMaxLocalRawBrightness() are called multiple times, causing unnecessary calculation overhead.
• Poor readability: lengthy if conditional statements are difficult to understand and maintain.
• Potential logic errors: The precedence of the && and || operators can lead to unexpected logical consequences, especially in the absence of parentheses to clarify precedence.

2. Optimization Strategy 1: Introduce local variables to improve efficiency and readability

The most direct and effective optimization method is to introduce local variables to store the results of repeated calls. This not only reduces the number of method calls, but also greatly improves the readability of the code.

 // Assume that in a loop, you need to detect the block BlockPos at the (x sx, y sy, z sz) position currentPos = new BlockPos(x sx, y sy, z sz); // Only create the BlockPos object once BlockState blockState = world.getBlockState(currentPos); // Get the BlockState only once
Block block = blockState.getBlock(); // Get Block only once
int lightLevel = world.getMaxLocalRawBrightness(currentPos); // Get the brightness level only once if (block == Blocks.TORCH
    || block == Blocks.WALL_TORCH
    || block == Blocks.FIRE
    || (block == Blocks.CAMPFIRE && lightLevel == 15) // Use local variable lightLevel
    || block == Blocks.LANTERN
    || block == Blocks.LAVA
    || block == Blocks.LAVA_CAULDRON
    || (block == Blocks.FURNACE && lightLevel == 13) // Use local variable lightLevel
) {
    //Execute related logic}

advantage:

• Significant performance improvement: Repeated calls to world.getBlockState() and world.getMaxLocalRawBrightness() are avoided, thereby reducing the load on the CPU.
• Improved readability: The code becomes more concise and clear, making it easier to understand and debug.
• Reduce maintenance costs: When you need to modify the judgment conditions, you only need to focus on local variables instead of re-parsing complex expressions.

3. Optimization Strategy 2: Separate block type and brightness level judgment logic

The original code mixed block type checks and brightness level checks together, which could lead to confusing or inaccurate logic. Clearly separating these two types of judgment logic can make the code more robust and easier to manage.

3.1 Clear judgment goals

Before writing code, first clarify your goals:

• Are you looking for a specific type of light block (e.g. torch, furnace)?
• Are you looking for any tile locations where the brightness reaches a certain threshold ?
• Do you need a specific block type and meet certain brightness conditions ?

3.2 Examples of independent judgment

• Only determine block types: If your goal is to identify a specific set of block types, regardless of their brightness, you can use Set to store the target blocks, making the judgment logic more concise and efficient.

   import net.minecraft.world.level.block.Block;
  import net.minecraft.world.level.block.Blocks;
  import java.util.Set;
  import java.util.HashSet;
  
  // Initialize once when the class is loaded to avoid repeatedly creating private static final Set<block> TARGET_LIGHT_BLOCK_TYPES = new HashSet(Set.of(
      Blocks.TORCH, Blocks.WALL_TORCH, Blocks.FIRE, Blocks.LANTERN,
      Blocks.LAVA, Blocks.LAVA_CAULDRON
      // Note: CAMPFIRE and FURNACE may not be suitable to be placed directly into this Set due to brightness conditions.
  ));
  
  // In the loop, assume that block has been obtained through local variables if (TARGET_LIGHT_BLOCK_TYPES.contains(block)) {
      // Handle these specific types of light blocks}</block>

  The advantage of using Set is that it provides an average search time complexity of O(1), which has more scalability and performance advantages than lengthy || chains.

• Only determine the brightness level: If you only care about whether the ambient light intensity at a certain location reaches a certain threshold, you can ignore the block type completely.

   // In the loop, assume that lightLevel has been obtained through local variables if (lightLevel >= 13) { // Set the appropriate brightness threshold according to needs // Process the area where the brightness reaches the standard}

• Combination judgment (exact match): When a specific block type and a specific brightness condition need to be met at the same time, parentheses must be used to clarify the logical priority to ensure the accuracy of the judgment.

   // In the loop, assume that block and lightLevel have been obtained through local variables if (block == Blocks.TORCH
      || block == Blocks.WALL_TORCH
      || block == Blocks.FIRE
      || (block == Blocks.CAMPFIRE && lightLevel == 15) // Use parentheses to specify the brightness condition of CAMPFIRE || block == Blocks.LANTERN
      || block == Blocks.LAVA
      || block == Blocks.LAVA_CAULDRON
      || (block == Blocks.FURNACE && lightLevel == 13) // Use parentheses to clarify the brightness condition of FURNACE) {
      //Execute related logic}

  This structure clearly expresses the intent of each condition and avoids potential errors caused by operator precedence.

4. Performance considerations and advanced suggestions

• Avoid excessive iteration: iterating over all the tiles in a large range is itself a CPU-intensive operation. When designing your mod logic, you should keep the search radius as small as possible, or perform such traversals only when necessary. For very large scales, consider more advanced spatial data structures or asynchronous processing.
• The difference between BlockState.getLightEmission() and Level.getMaxLocalRawBrightness():
  • BlockState.getLightEmission(): Returns the light intensity that the block itself can emit (for example, torches are usually 14, lava is 15). This value is an inherent property of the block.
  • Level.getMaxLocalRawBrightness(): Returns the maximum original brightness level of the environment at the BlockPos position, which takes into account the combined influence of sky light, the block's own light, and other nearby light sources. Choose the appropriate method based on your specific needs. If your goal is to identify any block that emits light , it might be more general to combine BlockState.getLightEmission() > 0 with Set. If your goal is to detect the ambient lighting intensity at a certain location , then getMaxLocalRawBrightness() is the right choice. In the original question, the two intentions are mixed, so it's important to understand their difference.
• Use Predicate or auxiliary methods: For more complex judgment logic, you can consider creating Predicate or independent auxiliary methods to encapsulate the judgment logic and further improve the modularity and readability of the code.

5. Summary

Optimizing the block detection logic in the Minecraft Forge module is a key step in improving performance and code quality. You can significantly improve your mod's efficiency and maintainability by adopting the following strategies:

1. Introduce local variables: avoid repeatedly obtaining BlockPos, BlockState, Block and brightness level, and reduce unnecessary calculation overhead.
2. Clear separation of logic: Depending on whether to judge block type, brightness level, or a combination of the two, clearly design the judgment conditions, and use parentheses to ensure correct logic.
3. Utilize data structures: For situations where you only need to check the block type, using Set can simplify the code and improve search efficiency.

Always remember that code clarity and performance optimization are integral considerations in mod development. Through careful optimization, it can provide players with a smoother and more stable gaming experience.

The above is the detailed content of Optimize the performance of block detection and light source judgment in Minecraft Forge 1.19.2. For more information, please follow other related articles on the PHP Chinese website!