本帖最后由 craftkuro 于 2020-12-10 01:56 编辑
上一篇：能源系统设计
- 和上一篇文章一样，本文的大部分内容为原创。但由于掺杂的内容过多，我也不太清楚这些内容究竟是原创，借鉴，还是引用。我会尽量做好标注。
- 同样，使用CC BY-NC-SA许可证。欢迎转载，但请遵守许可证。若您受本文启发而有了新的划时代设计，也不妨将本文加入参考文献中。
- 致在遥远的未来阅读本帖的你：请注意本帖最初作于2019年9-11月，其中包含的内容可能在某个时候发生改变。在套用经验前请先验证概念。
- 本文的所有内容均关于1.12.2。对于其他版本，有的可套用，有的不可套用，请自行判断，并根据实际情况来决定是否采纳。
- 这篇文我鸽了好几个月了，也重写了好几遍，现在一想到就头疼。就这样了，各位将就看吧。要写好这样的主题我还要需要更多知识。MC作为一个闭源的游戏，其实在游戏本身上折腾的空间并不算充足，我们最应该做的还是改进装置设计以改善性能。
目录
1. 在可能的情况下使用optifine，和使用它了解性能状况（客户端）
2. 合理调整JVM参数（服务器&客户端）
3. 选择合适的渲染距离（客户端）
4. 缓解瞬间卡顿：减少区块加载/更新的数量和耗时（客户端）
5. 减少视野范围内的方块实体数量（客户端）
6. 减少世界物品交互（服务器&客户端）
7. 使用开销更小的生产流程（服务器）
8. 减少AI的使用（服务器）
9. 克制装饰使用（客户端）（仅限科技玩家）
10. 眼不见为净（客户端）
1. 在可能的情况下使用optifine，和使用它了解性能状况（客户端）
虽然这个模组的许可证蛋疼，兼容性有点问题，但是在5帧和50帧的区别之下，这些都不是根本问题。因此，对于低配机器，强烈建议在任何可能的情况下安装。
由于前面提到的许可证问题，国外的整合通常不包含此模组，导致第一次玩的时候基本不能操作（我一般在3-5fps）。国内的整合似乎不太关心这个，不少都自带了。
什么？ Fastcraft? Betterfps? VanillaFix? 太弱了，那些只能让fps从5变成15。
如果你想玩的服务器有反作弊，我不清楚安装额外的模组是否会影响游戏。
- 我安装了optifine，如果遇到问题怎么办？
若出现白屏黑屏等现象，那么需要检查你是否安装了其他大量使用不那么常规的渲染方式的模组（特别点名the betweenlands），然后看相关说明来禁用相关配置或者optifine
若崩溃，emmmmmm，这就麻烦大了，调查兼容性问题，砍模组，改配置，或者放弃optifine——大多数情况下意味着这个整合包在你换电脑之前没法玩了。
- 我安装了optifine，但是帧数为什么没怎么明显提升？
默认情况下optifine和原版区别不大，但它提供了很多有意思的选项。本文主旨是尽可能提高帧数，那么画质什么的都得先缓缓了。
以下是用鼠标点点就能完成的极限帧数配置（以1.12.2_HD_U_E3为例）：
选项>视频设置
图像品质：流畅
渲染距离：看你显卡和内存。和服务器使用的渲染距离。一般6-8即可。
平滑光照：最小
最大帧率：无限制（真的，因为适用于本文的电脑一般帧数也上不去，限制没必要。当平时帧数都超过100的时候，就有必要限制一下了）
平滑光照级别：看个人爱好。我一般用100%
视角摇晃：看个人爱好。我一般关。
界面尺寸：自动，或看个人需求。
启用顶点缓冲器（VBO）：开。一定要开。
亮度：看个人爱好。我一般用明亮。
攻击指示器：看个人爱好
动态光源：关闭或者流畅看个人需求。低配机器不建议用高品质。
动态视场：看个人爱好。
光影：关
品质>
Mipmap级别：默认或者4。除非遇到问题，不建议关闭。
多级纹理（mipmap）类型：邻近。如果显卡稍微给力点可以考虑更高的级别。
各向异性过滤：关。如果显卡很弱，驱动里的设置也要注意一下。
抗锯齿：关。尤其是显卡弱的，还开抗锯齿简直是开玩笑。
其他几项其实性能影响不大。更好的草地雪地什么的看个人偏好。
细节>
云：关
云高度：云都关了，这一项也无所谓了。
树：智能。树叶开这个之后画质其实和高品质差不多呢。性能影响在大多数情况下较小。
雨雪：关。这个是关键，下雨很影响帧率。如果下雨会让机器损坏，那么得先整好房顶再摆机器。
天空，星星，日月：看需求。能开就开吧，不开的话太硬核了。而且性能影响也不大。
显示披风：关。没啥卵用的样子…还多消耗本就不充裕的gpu时间。
迷雾：关
迷雾起始位置：都关了，这项设置也无所谓。
半透明方块：默认
晕影：流畅。这个玩意还挺影响帧数的。
持有物信息显示，掉落物，实体阴影，替选方块，沼泽颜色，平滑生物群系：能开就开，性能影响不大。
性能>
平滑FPS：强烈建议关闭。它在我用过的所有测试中都只会降低帧数。虽然确实是平滑了。
快速渲染：强烈建议开启。但开启它可能会导致一些图像缺陷。当你遇到黑色的太阳等异变的时候，关闭它即可解决问题。
快速运算：开。注意它和betterfps里的“优化算法”只能选一个开启。
区块更新：1。尤其是当cpu性能不足的时候。
区域渲染：请在自己的游戏里测试。我的所有经验里这一项开和关没有明显区别。
智能动态材质：开。虽然在下文里会关闭所有动画，但开启这一项会节约几毫秒的cpu时间。
平滑世界，动态更新，缓慢区块加载：仅适用于本地，但建议开启。虽然效果不太明显，但未发现有副作用。
动画>
点全部关闭就行了。尤其是地形动画（比如ae的me控制器的动画就是由它控制），千万别开。这才是optifine目前没有找到替代品的功能。
其他>
这部分基本上就是看个人需求来开。
我一般只开快速调试信息（或者按alt+F3）和显示fps。
关于快速调试信息的图（lagometer）怎么读：
首先打开方式是alt+F3（同时适用于高版本原版和optifine），如果你在optifine的选项里设置了此项开启，则只需按F3。
打开之后调试界面左下角会有个区域不断出现彩色的竖直条条，和一些横线。每一个条条在大多数情况下都代表一帧，其高度表示在此帧（或gc）上花费的时间（就是所谓的帧生成时间）。两个横线自然就是表示60帧的16.7 ms，和30帧的33.3ms了。
用这个工具我们可以很方便地了解帧生成时间状况，并以此辅助性能调试。
原版的条条里的颜色只与该帧耗时有关，低于30fps的是红色。
Optifine里的条条每一个都可能由多种颜色组成。具体颜色的含义，在选项里的相关位置的注释里有，除了白色。从个人经验来看，白色包含渲染实体（含方块实体）和等待垂直同步或帧率限制（如果开了）的时间，以及我不知道的部分内容。
下图：某模组较少的测试包，但忘记装optifine
下图：我的某自组包，单人全新世界，动画全开（条条突破屏幕范围了！）和全关的帧数差距。
2. 合理调整JVM参数（服务器&客户端）
我也是一知半解……所以，就不解释为什么了，直接给我正在使用的一行效果聊胜于无的参数:
仅在java 8 (hotspot) 上的forge server测试，并通过。
- java -server -Xms4G -Xmx4G -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=100 -XX:+DisableExplicitGC -XX:TargetSurvivorRatio=90 -XX:G1NewSizePercent=50 -XX:G1MaxNewSizePercent=80 -XX:G1MixedGCLiveThresholdPercent=35 -XX:+AlwaysPreTouch -XX:+ParallelRefProcEnabled -jar forge-xxxxxxxxxxxxxxxxxxxx.jar nogui
注意这一行千万别傻乎乎地往启动器里填(不用于客户端），看不懂的就当我没写。其实我也不完全明白这些参数的全部含义。
使用这些参数启动，jvm会吃掉你给的所有内存，因此请按照硬件允许的情况进行分配。
在windows机器上，一定要加nogui。没加的话，因为原版mc服务器gui窗口的存在，性能会出现非常严重的问题。我也不知道为什么。
参考资料：https://aikar.co/2018/07/02/tuning-the-jvm-g1gc-garbage-collector-flags-for-minecraft/
对于客户端，HMCL加的默认参数用着还行，我也没什么好的方法来解决gc卡顿的问题——只能换个更好的处理器了。Journeymap在相当程度上会引起此类卡顿，但这个模组暂时没有较好的替代品。
玩的过程中发现的一个规律是，游戏内动态的内容越多，GC发生得越频繁。因此，减少动画、粒子、光照变化、区块更新，均可在一定程度上改善此方面性能。
减少区块更新的部分做法，将在下文提及。
除此之外，我们还可以换其他的jvm。建议尝试一下openj9，但它和部分模组存在一定程度的兼容性问题，故仅推荐用于2019年及以后出的forge和模组的1.12.2+版本。Openj9默认似乎不带openjfx，故你可能还要装一个平时用的来自oracle的jre来开hmcl，或者换个不需要javafx的启动器。
目前来看openj9 8u212版本对于玩mc来说比较稳定。（注意文章发布日期！）
虽然openj9的内存占用显著低于hotspot，但帧数方面我没有感受到明显差距。也许是我的机器上u或者卡太弱了。
3. 选择合适的渲染距离（客户端）
前文在optifine的设置中提到了尽可能提升fps的视频设置，但它们仅是我的建议，不一定适用于所有机器和游戏状况。
特别需要注意的是渲染距离。较远的距离下，视野里渲染的区块数量会快速增加，从而降低fps（受GPU性能限制为主）；但是，若设置过小的距离（比如2-3），对于较大的，面积可达7x7或更多区块的基地来说，移动过程中客户端会不断进行区块加载/卸载的操作，而基地中安装有大量机器和装置的区块，加载起来耗时可达外围自然生成区块的数十倍，这段时间里，cpu会耗费大量时间在这些操作上（嗯，100%）并且频繁出现GC卡顿从而使帧数从60+降到5-10。
具体选择多大的渲染距离，需要根据自己的基地尺寸，CPU/GPU哪个性能较强等因素不断尝试，以找到能够获得最佳体验的数值。
其他的视频设置项目，通常不需要考虑如此多的内容，简单尝试提供的选项即可。
4. 缓解瞬间卡顿：减少区块加载/更新的数量和耗时（客户端）
在optifine的快速调试信息（lagometer）中，与区块加载/更新的有至少3个条目：预定可执行（蓝），区块加载（紫），区块更新（红）。
如图
前两个（蓝，紫）是真的没想出办法解决（除了加钱换u）。
关于最后一个区块更新，一般是在区块里摆放/破坏方块时出现。
当一个区块里有太多东西（导线机器等）时，摆放/破坏方块并进行区块更新的代价就会很高，在复杂的设计里可高达1/10秒以上。
因此，为了缓解这个问题，我们需要：
· 将每个区块的内容弄得更加简单——这意味着，将机器尽可能分开，而不是堆在一个区块内。基地应当水平展开，而不是在少数几个区块内垂直分层。
· 一个区块内不要铺设太多ME/EIO线缆。这是刚才图里情景得出的结论。
· 减少不必要的方块放置/破坏操作。
· 将农业等运作时会产生大量区块更新的功能区放在其他的维度/远离工厂的地方。
· 避免让机器轮询信息和改变输出的间隔太短。（比如前一篇中提到的比较器，原版的轮询间隔可低至一个红石刻，而每一次轮询都可能改变输出，因此在部分情况下会造成较多的区块更新）
5. 减少视野范围内的方块实体数量（客户端）
方块实体的概念参考MC wiki。
如何看视野中有多少方块实体呢？最简单的方法(如果装有optifine)就是打开视频设置>其他>显示FPS，在左上角会有个E:X+Y 的数值，第一个数字(X)是实体数量，第二个数字(Y)是方块实体数量。
如果没装optifine的话……我就不知道怎么看了。
然而事情并没有那么简单。
按照方块实体的定义，为什么我的各个模组机器明明就是方块实体，也就在眼前，但为什么数字是0呢？
由于optifine并没有文档，也不开源，我只能用假说来解释这种状况：
（警告！未经证实的假说）
方块实体在服务端全部参与ticking，但在客户端只有部分进行更新和渲染——于是，对于正在运行的机器的材质和亮度变化，只需简单更改数据值就可进行。当玩家打开机器的GUI时再传输与方块实体相关的数据即可。AE的线缆，大部分种类的管道，似乎也适用于这种状况。
然而ender io的管道是个例外。每一个方块的导管束（conduit bundle）都是一个方块实体。
于是我们将方块实体分为两类，一种是同时在客户端和服务端存在，并在客户端展示的方块实体；另一种是仅在服务端存在，而不在客户端展示的方块实体。
（假说部分结束）
同时，由于MC的某种设计，方块实体是在世界之上单独渲染的，于是数量越多，就需要额外更多的时间来绘制一帧——自然地，在低配机器上就会有明显的帧数差距。高配从300掉到150可能关系不大，但60-30可是大问题。
如图，相对于刚才的87fps，在同一服务器中其他人没考虑这些而建造的基地前，帧数就完全不是一个水平了。（绘制调试界面的开销暂时忽略，关掉有45-50帧）
为了创造精彩的游戏体验，方块实体是不可或缺的。我们能做的就是尽可能选择不在客户端展示的方块实体，以及尽可能选择占用资源较少的那些。
这里特别提出一点：原版的箱子，每一个都在客户端占用额外的client thread时间！几十个箱子可以占到6-7%的时间。这个时间拿来干啥不好，偏要渲染箱子。因此建议中后期要尽量少用原版箱子，虽然它可能是兼容性最好的存储方块了。Iron Chest模组的箱子，或其他在客户端展示的物品容器也算。
对于快速调试信息中的tick耗时过高问题，一个解决的有效方法就是减少可见的方块实体数量。
6. 减少世界物品交互（服务器&客户端）
不知道为什么，与这种特性有关的装置的性能都不甚理想。
包括原版的漏斗，漏斗矿车，各种模组的仿原版漏斗， immersiveengineering的各种相关物品，ender io的虚空箱子，等等。
这个部分没什么说的，修改生产流程，尽可能减少与世界物品的交互。
——顺便也减少了实体的数量。一举两得。
7. 使用开销更小的生产流程（服务器）
部分机器由于其独特的工作原理，在闲置和工作的时候会消耗额外的计算资源，举例如下：
Ender io的合金炉，当输入侧有物品但没有合适的配方来烧炼时，它会不停地在所有的配方中搜索，并尝试寻找合适的配方进行处理（是不是有原版工作台的既视感），这带来了闲置时不必要的计算资源消耗。
Ender io 的sag磨粉机，由于其产物的输出有个概率，在工作时对此需要额外的处理。当用这种磨粉机组成大规模处理阵列时，cpu会花相当的时间在掷骰子上，而大幅影响tps。
（在某大佬制作的200+机器阵列上，sag磨粉机花掉了约30%的server thread时间）
虽然它的产率很诱人……
这种时候就应该考虑更换其他模组的类似机器。（虽然eio机器功能强大）
相对而言，TE的红石炉和磨粉机的工作原理就简单得多。在另一个服务器上，512个机器x50%平均负载只花了约5%的server thread时间。
8. 减少AI的使用（服务器）
用人话说就是少养动物少刷怪。
原版的动物，不用说，每一只消耗的资源都差不多赶得上最复杂的机器。
刷出实体的刷怪装置也类似（强力推荐woot）。
村民所在的地方不建议长期加载，毕竟也蛮吃资源——建议将工厂等区块持续加载的地方与附近村庄保持合理距离。
渲染这些实体也需要额外的时间，当不需要与这些动物和村民打交道的时候，还是离它们远点好。
9. 克制装饰使用（客户端）（仅限科技玩家）
唉，其实我这整个系列都是关于硬核科技的……至于建筑和休闲玩家，看看就好，值得借鉴的经验可能有限。
制作微雕方块的multipart模组，各种家具和台灯，装饰画，地图，常常有复杂的外形，又往往是方块实体。这类物品多了之后通常会大幅降低客户端帧数。
是让世界变得美观，还是让世界变得流畅，见仁见智。
10. 眼不见为净（客户端）
把所有不想看到的东西，都扔到看不到的地方，就可以了！没有了方块实体，没有了区块更新，没有了流水，没有了动物，只有天、地和你。
终极的解决方案。
帧数+++。
当然，对于服务器的负载问题这只是掩耳盗铃。
如何实践这些经验，使得我的基地在后期也和前期同样流畅？
请看下回：兼顾性能和产能的基地设计
本系列的更多内容
由于内容过多，鸽着是不可避免的了。写完后我会更新帖子里链接。
篇一 能源系统设计
篇三 基地设计
篇四 模块仓库
| 
EU：1
RF：10136
Vis：13
Mana：1
AE：2143
鄂公网安备 42030302000264号 [ ]