加速碰撞是一个专注于优化服务端实体碰撞逻辑的模组。它利用 FFM (Foreign Function & Memory) API/JNI 接管实体 AABB 碰撞检测，将高密集计算压力转移至 C++ 原生库，从而显著提升服务器性能。 该项目由加速碰撞提供支持。
本模组目前为实验性质，实体挤压表现与原版不完全一致。请务必在做好存档备份的前提下谨慎使用。如果在意原版特性还原程度，请切换至Java Vanilla后端
官方交流群：1023713677
- 实体碰撞性能提升：通过将底层的碰撞逻辑交由 C++ 处理，打破 Java 在处理海量实体碰撞时的性能瓶颈。在测试条件下（同一区块数千实体），TPS 提升可达数十倍。
- 算法优化：引入效率更高的碰撞算法，避免了原版 O(N^2) 复杂度的实体遍历，降低 CPU 负担。
- 阈值触发：只有当局部实体密度达到设定阈值时才会使用 C++ 加速算法，保证常规游戏场景下的稳定与原版体验。
- 多端支持：同时包含Windows/Linux/MacOS的运行库，未来版本将支持arm64
- 动态后端选择机制: 同时包含多个后端并自动选择当前可以应用且效率最高的后端
| 后端 | 实现说明 | 要求 | 性能 (预期) | 状态 |
|---|---|---|---|---|
| GPU | 使用 GPU 算法加速碰撞 | 需图形硬件支持 | 最高 | 可用 |
| FFM | 使用 FFM API 与 C++ 层进行通信 | 需要使用 JDK 21或以上的Java版本启动游戏 | 非常高 | 可用 |
| JNI | 使用 JNI 与 C++ 层进行通信 | 无 | 非常高 | 可用 |
| Java SIMD | 使用加速碰撞的 Java VectorAPI 算法 | 需添加启动参数 | 高 | 可用 |
| Java | 使用加速碰撞的 Java 原生算法 | 无 | 良好 | 可用 |
| Java Vanilla | 在原版的实体遍历下直接修改实体碰撞筛选逻辑（原版特性还原程度最高） | 无 | 偏差 | 可用 |
| Vanilla | 原版的碰撞逻辑 | 无 | 最差 | - |
如果需要手动切换后端，请在游戏启动时添加参数-Dacceleratedrecoiling.backend=后端名称
- 64位操作系统：本机库 (
.dll/.so) 仅支持 64 位环境。 - Leaves 端：启动参数中必须包含
-Dleavesclip.enable.mixin=true。
首次启动时，模组会自动在根目录释放本机库文件，并生成 acceleratedRecoiling.json 配置文件。
默认配置及说明：
{
"enableEntityCollision": true, // 是否启用实体挤压优化
"enableEntityGetterOptimization": true, // 启用EntityGetter接口优化(暂时无效)
"maxCollision": 32, // 单个实体最大碰撞交互数
"gridSize": 1, // 算法网格大小
"densityWindow": 4, // 密度平滑窗口
"densityThreshold": 16 // 触发加速碰撞的周围实体密度阈值
}注：若开启后性能不升反降，请尝试调低 densityThreshold。
如果CPU占用过高，请调低maxThreads
Q: 为什么游戏崩溃或无法启动？
A: 请按以下步骤排查：
- 确认已正确安装 Java 17+
- 若使用 Leaves 服务端，确保启动参数包含
-Dleavesclip.enable.mixin=true。 - 如果更新过模组，尝试删除根目录或
.minecraft下的acceleratedRecoilingLib.dll与acceleratedRecoiling.json，然后重启游戏让其重新生成。
Q: 开启后实体挤压表现和原版一样吗？
A: 不完全一致。本模组目前为实验性质，改变了底层计算逻辑，因此挤压表现会与原版有差异。请务必在使用前做好存档备份。
Q: 会影响生电特性吗？
A: 目前没有找到因加速碰撞而失效的红石机器，但推测可能会影响与实体挤压有关的红石机器，请务必在使用前做好存档备份。
Q: 为什么开启模组后，服务器性能反而下降了？
A: 可能是周围实体密度未达到触发优化的条件，因此同时走了原版和加速碰撞的两条路径。请尝试打开配置文件，适当调低 densityThreshold 的数值。或尝试调低maxThreads。
Q: 会不会和某些模组不兼容？
A: 完全不会，根据我们目前的测试，加速碰撞与 ATM9 整合包完全兼容
同时兼容
- Lithium
- FlatCollision
- RuOK
- Create
- Valkyrien-Skies-2
等多个大型模组。如果发现有不兼容的模组，请在本仓库提交Issue。
Q: FFM 是Java 21的预览功能，我是否应该使用Java 21+启动游戏？
A: 如果你的游戏版本是1.21.1以上，那么是的，但这是1.21.1版本本身需要Java 21来运行。
如果你的游戏是1.20.1，那么不需要，加速碰撞v0.10.0-alpha-1.20.1以上的版本同时支持最新版JDK到Java 17之间的任意JDK版本。
（* 注: 1.20.1 的最低可运行 Java 即为 Java 17 *）
测试环境: i5-12600KF | 32GB RAM | RTX 3060 Ti | Leaves 1.21.8 | GraalVM JDK 21
测试一：TPS 变化 (同一区块 2x2 空间内生成实体)
| 实体数量 | Leaves + 加速碰撞 | 原版 Leaves | 提升倍率 |
|---|---|---|---|
| 2,048 | 20.0 TPS (16 MSPT) | 3.0 TPS | 20.8x |
| 4,096 | 20.0 TPS (27 MSPT) | 0.5 TPS | 74x |
| 16,384 | 8.6 TPS (115 MSPT) | - | - |
| 32,768 | 4.3 TPS (230 MSPT) | - | - |
测试二：BroadPhase 耗时 (纯 C++ 端处理性能)
| 实体数量 | MS / Frame (每帧耗时) | 等效 FPS |
|---|---|---|
| 10,000 | 0.2 ms | 5000 |
| 50,000 | 1.1 ms | 909 |
| 100,000 | 2.5 ms | 400 |
| 400,000 | 21.3 ms | 46 |
项目通过 Gradle 调用 MSVC 和 WSL 进行双端跨平台编译 (生成 .dll 和 .so)，建议在装有 WSL 的 Windows 10/11 环境下操作。
1. 环境准备
- 安装 JDK 21。(必须)
- 克隆本仓库
2. 构建 在项目根目录运行以下命令：
gradlew jar
gradlew build编译产物 (包含双端动态库的 Jar) 将生成在 build/libs/ 目录下。
如果你喜欢 加速碰撞 (Accelerated Recoiling)，欢迎来 这里 请wiyuka吃一顿带鱼哦 owo
本项目基于 MIT 协议 开源。 特别感谢以下开发者对本项目的核心思路与代码移植提供的巨大帮助：
- Argon4W: 原始构思与核心思路。
- fireboy637: Architectury API 移植方案的核心代码。
- hydropuse: JDK 22 兼容方案的核心代码。
- wellcoming: Docker Ubuntu镜像解决方案。
- grayawa: Linux 上的构建问题修复
- TomatoPuddin: 跨平台构建(Windows/Linux/MacOS/Android) 与 C++ 层的重构