《鬼谷八荒》从程序优化的角度理性分析一波卡的原因——显卡不是锅
1.首先可以确定的是，显卡的好坏并没有什么影响。鬼谷八荒是二维游戏，所有图元都不涉及到3d渲染，不存在三角面片过多导致渲染变慢，纹理材质光照环境等等统统不涉及，理论上20年前的电脑配置都能支撑这种画质，手机的算力当然更是没有问题。大家应该知道前端时间优化了水剑，不那么卡了，可整个游戏的效果没什么变化，说明显卡根本不是硬伤。举例来说，一个1千万三角面片的城市级三维游戏场景，只要动态加载得当，即便算上纹理，占用显存不过2个G，60帧渲染不是事儿。鬼谷八荒显然没有达到显卡性能的门槛上限，差得远呢。
2.图元的数量也不是什么问题。现在大家吐槽卡的，都是发现一旦弹道变多，召唤物变多，就会卡顿，直到幻灯片状态。可是，这个图元数量根本不是问题。做过雪特效、云雾特效的同学知道，粒子系统即便上升到百万级，仍然对于整个渲染不构成太大压力，一般渲染引擎渲染个极光特效都随随便便。以鬼谷八荒的弹道数量，不超过1万，凭什么卡呢？
3.CPU运算速度更不是事儿。现在的cpu，动辄每秒上一次浮点计算，鬼谷八荒每秒按60帧算，每帧能发生多少事情？战斗过程那堆特效能占用cpu多少算力？连动态规划求解最短路径都比这费时。
综上所述，上述这些因素都不构成卡顿的根本原因。实际上，造成卡顿的绝大部分时间开销，并不在cpu和gpu，而是在内存！我们知道，计算机的逐级优化加速体系中，内存是瓶颈。从硬盘加载数据到内存是非常慢的，从内存把数据上传到GPU也很慢，通过总线传给计算单元（GPU）也很慢。所以减少内存的分配、释放、复制才是优化的核心。
时之界王神凯茵：看不懂，但是觉得很厉害！ 发布于 2022-05-30 03:27:42
醉淡伊人：看的半懂不懂，，，有些还能勉强理解，有些这是啥？不过大佬牛，逼 发布于 2022-05-29 20:02:52
动漫之忆：因为今年的diy乱象，我用一台12年前的电脑靠了不起，鬼谷，太吾生生坚持了几个月了，除了东西弄太多会卡以外，其他的完全没感觉会卡 发布于 2022-05-29 17:05:32
jxl9999：我就这么说吧，我六根16g内存条总共96g内存，i9的9980xe，3090水神，我玩的纯水，四灵共生的时候冰天眼或者冰刺触发蛟龙就会卡，打陨幽谷场地爆炸多了也会卡 发布于 2022-05-29 14:45:02
Hawk的怒吼：原来如此 我说我怎么一点也不卡 但看显卡计算平均帧数却不高的样子 发布于 2022-05-29 14:29:52
love玉雪飞花：说复杂也不复杂，但是修改起来……我看了看朋友的秃头……嗯…… 发布于 2022-05-29 14:26:22
love玉雪飞花：有这时间水帖还不如去应聘，到时候名留青史也不一定 发布于 2022-05-29 14:25:32
不懂到底在想啥：喜欢这种技术讨论贴，如果张三看了对优化游戏减少卡顿有帮助就太好了，给题主点赞 发布于 2022-05-29 14:12:32
冰舞胧煌：加载有点慢这个有感觉。话说你们说的鬼谷战斗卡是指什么？我刮痧时状态全部拉满也没觉得不流畅啊。电脑也是五六年前的入门级游戏本。
对了，非要说卡的话，前段时间天热，不开空调的话，电脑发热严重，键盘烫手指的时候，会卡…… 发布于 2022-05-29 14:06:12
xiongyuanxy：很荣幸得到了张三的认可，不过昨天写的有点乱，很多问题没有细看就发言，错误百出。
这里更正一下。
1.我又重新看了存档文件，确实是二进制缓存文件，应该是调用了steam封装好的数据读写接口，这里我理解可能有误了。这部分可以忽略我的意见，做点异步加载优化和数据结构优化就好了。
2*使用的是Unity作为渲染引擎。鉴于Unity的封装了很多底层功能，而我提到的离屏渲染、帧缓存、纹理分层概念是OpenGL的。鉴于我对Unity并不熟悉，这些技术是否仍然可用，我并不确定。另外Unity的编程语言是C#，那就不必过多考虑指针问题。资源的分配和释放回收机制也应该是游戏引擎内置封装好的，也不必大改。另外，由于游戏大量使用了Unity的独立模块，比如衣服，瓦片地图，AR，声音，纹理等等等等，所以这部分基础功能并不好改。修改引擎的工作量是巨大的，小宝的身体重要，没必要这么大动干戈。
3.Unity支持苹果、安卓等跨平台应用，且有成熟的框架，为了方便以后游戏移植到更多的平台，这个选择很好，也没必要碰内核。长远角度讲这对游戏发展是好事。
总结下可以参考的修改游戏机制：
1.战斗结算优化，尽量少用触发式的异步时钟和队列式的堆叠计算。不妨建立一个全局的战斗结算器，使用同步时钟，以帧或毫秒为单位，定期计算全部伤害，并绘制动画。这个技术优化可以参考暗黑三，场面上有几百怪物，4个玩家，大量技能以及地面特效，但是仍然不卡。暗黑3通过同步时钟，把伤害与特效进行了累加与合并，减少了绘制量。
2.人物立绘和头像根据分辨率建立金字塔分级。这个我觉的可以有，因为根据分辨率不同选择不同大小的图像金字塔技术几乎所有的引擎都必须支持这个功能。至少打开主城的人物列表，那几百个小头像渲染应该没什么压力。当然如果加载npc数据仍然是性能瓶颈，那就提前后台加载，不必要每次打开界面重新生成npc列表。
3.音频管理，采用同步时钟能合并大量的触发，自然也就减少了音频播放，还可以继续优化。特效的音频应该分档分类，按优先级进行混音，场面过于混乱的时候，减少低优先级音频的播放，比如火焰闷烧、斧头旋转等。技能音效可以考虑根据攻速分档选择不同的音频播放，而不是每投射一次就播放一次，参考暗黑3猎人的速射扫射等技能。
4.善用异步加载和分批绘制。永远加载最优先的元素进行绘制，保证用户体验流畅。比如最常用的地图传送功能，先绘制地图背景，再绘制宗门和城镇方便传送，最后绘制好友仇人图标，因为npc加载可能是性能瓶颈。
5.善用预加载和缓存。无论什么引擎，你总是可以提前渲染好需要的元素，等你用的时候再叠加到当前屏幕，这部分内容没必要等到用户真用的时候再临时绘制。每次绘制完成后，如果确定用户下次还会用，就没有必要提前释放掉，可以留到退出场景时候统一释放。战斗动画，大小地图，人物立绘等都是可以缓存的。本质上还是空间换时间的优化策略。
6.索引优化，把一部分最可能用到的npc数据索引拷贝到额外的空间，优先查找索引，找不到再查询总表。查询总表的操作尽量提供给月结这种批处理的任务，减少内存查询时间。 发布于 2022-05-29 13:59:52
Takedasean：搞优化—费时费力不赚钱
做英版—
鬼谷工作室是个小工作室，为了宗门版本忙得焦头烂额。结果在这种情况下这小工作室居然还能同时推出个工作量需求并不小的英文版本。确实令人惊讶。
张三之前说不想战斗规模搞太大怕玩家显卡冒烟，我是不信张三是真的不懂游戏卡并不是显卡的祸的。就算他真不懂，随便问一下手下的程序员或其它专业人士就明白了。所以他为什么还要这样说？就是说个笑话敷衍一下罢了。
很多时候，他们是懂的。一个程序员要是连O(n)和O(n^2）哪个更有效率都看不出来那也只能建议转行了。
这次不声不响出了英文版，很多东西都清楚了。
之前我奇怪过他们的游戏开发策划，以为他们分不清主次。现在看起来，他们分得非常清楚。
不过工作室能赚钱，并不是坏事。只是在“游戏优化”这一进度上，不能指望太多太快了。 发布于 2022-05-29 12:05:42
无情寒月：
隔壁群星的CPU0梗么 发布于 2022-05-29 11:13:22
564273869：虽然看不懂，但是感觉很在理 发布于 2022-05-29 11:08:02
大学里面有66：建议发邮件给官方 发布于 2022-05-29 11:03:52
夜雨傾听：我虽然看不懂，但我大为震撼 发布于 2022-05-29 10:48:02
是头菜：之前的水剑，特别是用骤天剑的时候，像我玩3d网游千人团战一样卡成幻灯片。宗门战开了之后，真的担心不知会卡成什么样，希望题主的贴子有助于改善玩家的游戏体验。题主辛苦了。 发布于 2022-05-29 10:41:42
a13824482576：看不懂的我居然看完了，厉害 发布于 2022-05-29 10:40:32
xiongyuanxy：优化音频，善用混音。当然，这个技术可能已经在用了，这方面我是外行，只是建议。
我们知道，鬼谷八荒的出招，每个动作都有自己的配音，你打的越快，音频播放越快。比方说清风剑，每剑都有biubiubiu，biu快了就成机关枪突突突了。等对象多了，弹道多了，音频也会占用很多资源。应该把音频也理解为一种游戏资源，也是从磁盘加载，内存合成，输出到音频设备。理解他的性能瓶颈很重要。频繁地播放、暂停音频效率低下，该合并的就合并。还是以暗黑3举例，猎人的扫射，无论你攻速多快，听起来都是跌宕起伏，不存在突突突的问题。暴雪早就有攻速分档的机制，建议鬼谷八荒也引入，对于不同的攻速分为几档，根据档位加入不同的音频就好了。这样做，玩家仍然能感受到自己攻击速度变快了，却不会觉得声音很吵。
再说混音，玩水间的人都知道，打起boss来，那声音叫一个乱，剑的弹道声音，器灵的攻击，水分身爆炸，boss技能，人物出招的大喊。。。卡起来根本听不清。实际上，当场面混乱的时候，很多声音就可以关掉了，或者做成混音。比如，放神通骤天剑的时候，其他弹道声音应该尽可能静默，这才叫神通么。音频太多的时候，无关紧要的声音可以不放，比如烈火凤的烈焰燃烧，场面混乱时候就播放那一声鸟叫就好了。
音乐应该有主次之分，张弛有度，不然会让人觉得很累。 发布于 2022-05-29 10:39:02
q644509272：还有一个任务方面的问题，现在的任务不断的提醒玩家提升境界，我觉得要求玩家提升境界的任务不应该存在，这会让玩家去追求境界而忽略了体验游戏的内容，很多策划设计的小情节玩家根本不想看，只想快点提升境界，拉低了玩家的体验。 发布于 2022-05-29 10:36:12
xiongyuanxy：善用快照、图片分级、分辨率调节。
再集中吐槽一波主城。一旦遇到拍卖会和升仙大会，点开主城人物列表，瞬间卡到爆。几百个npc齐聚一堂，本来是热热闹闹的好事儿，怎么就卡了呢？早起版本的时候，人物还是一起绘制，主城卡到死。现在优化了，至少加入了逐个绘制，至少第一页不卡了，后面几页慢慢刷新。然而，这效率之低下仍然让人不寒而栗。
我们知道，图像是可以根据分辨率分级的，这个技术叫做MipMap或ripmap，俗称金字塔压缩。每个图片，理论上只需要额外开辟多一倍的存储空间，就可以存储成不同大小的分级。鬼谷八荒的人物立绘显然需要这个机制。主城的那些人头像那么小，没必要都用最高分辨率进行绘制，那种未经过插值的高分辨率图像渲染又慢又有下采样锯齿，远不如用小分辨率的图像渲染效果好。
再有，每次点开主城，主城都需要重新渲染，这不浪费么？一次渲染之后保存整个渲染结果到一个大的图片纹理就好了，称为快照。只要人员没发生变更，就可以一直复用，跟滚动条浏览图片一样。发生人员变更的时候，再重新渲染快照。当然，人物变更是以方格为单位的，不涉及阴影、环境光。那你也可以给每个人物方格建立快照，每次发生变化，只需要变更那个人所在的方格快照。这样就不需要每次都重新绘制了。为什么快照速度快？因为快照是存在于内存中的连续图像数据，比从磁盘加载高清立绘要快几千倍。理论上讲，渲染几百万个人物头像都不应该卡顿，不然百度图片、谷歌图片这些网站都没法用了。用户点开人物之后，再加载高清立绘，甚至动画立绘都没问题。 发布于 2022-05-29 10:36:02
q644509272：从用户角度出发，我感觉应该取消月末结算，改成玩家行动时触发NPC行动，像模拟人生3那样，读条非常影响游戏体验，尤其是月末结算间隔的时间很短，割裂感非常严重，第一代解决不了的话一样第二代可以先解决了读条的问题，读条不应该存在。 发布于 2022-05-29 10:35:42
xiongyuanxy：当然，对小游戏公司来讲，可能不一定能招到数据库工程师，甚至都不一定能使用数据库，哪怕是MongoDB这种轻量级数据库。这个要求有点高。但是退而求其次，在游戏一开始的时候就想好一个合理高效的数据存储方式，是非常重要的，是对整个架构的掌控能力体现。不要等到后期游戏内容爆炸了再考虑优化，应该从一开始就想到问题。如果不用数据库和关系索引，能不能优化呢？当然可以。有很多的小技巧。
我们知道，炼气阶段过月很快，读档飞快，而悟道就慢，为什么？因为悟道的活动npc多了，技能多了，法宝多了，地图之间穿来穿去。以图网络的复杂度来说，是N的阶乘形式的复杂度扩展。可以想象开了登仙和天元山后，会更慢。怎么办呢？事实上，做系统开发的人都知道，这种消息队列式的请求响应机制是非常慢的。每个npc独立处理自己的事情，处理完后发布消息，给所有有关系的关联npc，这种消息机制就是灾难。不信，你打开游戏里的邮件列表看看，发生了多少事儿？
实际上，玩家只关心发生的事情，而不关心到底是谁发生了事情。绝大部分与玩家没有交集的npc是死是活没有任何影响。那么优化就可以从这方面进行。
1.改消息机制为资源分配机制。反正玩家的精力是有限的，比如最多观看10条月末消息，那你只需要计算这10条消息的事件就好了，至多扩大到与我们角色存在2跳关联内的npc。其他的npc，没必要计算他们干了什么。游戏建立一个分发ai，每个月把一堆功法、材料、钱根据规则发到他们包里就行了。杀人ai，结缘ai以此类推，每个月按名额概率、规则、把这些事儿分配给随机NPC，分到的人计算合理性，没分到的就不管了。这样的话，每个npc都能并行处理，不存在顺序处理的逻辑瓶颈，就能快很多。
2.少用多态和继承。继承多态对于面向对象的编程人员来说易于理解，但是对于关心效率的人来说就是就是性能灾难。一个npc，继承出仇人、友人、妻子、道侣、师傅、天骄、心魔等等等多态，每个类型操作、方法、属性都不一样。这些多态实际上都是用指针的方式存储的离散数据，寻址代价昂贵，还是图网络问题。而且，bug满天飞，内存泄露严重，空指针崩溃频发，开发维护代价极高。其实完全没必要，有些东西，从多态改为父类的一个属性就或变量就行了。把复杂的成员方法写成共有的全局方法，方便并行。
3.改离散的读写操作为集中读写操作。利用平时空闲时间，开辟独立的线程，提前加载需要用的数据，不要等到月末算力紧张时候再准备数据。这就跟明知道期末考试还要临时抱佛脚一样。 发布于 2022-05-29 10:30:52
忧伤的小芹菜11：顶上去，虽然看不懂，但是字多肯定有道理 发布于 2022-05-29 10:27:22
xiongyuanxy：再来谈谈大家都在吐槽的过月慢问题。为什么每个月末，大家等的花都谢了，世界计算还那么慢，甚至有时候还卡死？那每个月末，npc都干了些什么，让月末总结如此龟速？
通过查看npc的历史记录，我们发现npc每个月跟玩家一样要做很多事情，打怪，练技能，跑路，送礼。。。这些难道不耗时间么？怎么优化呢？举两个简单的例子就明白了。
以经典的回合制游戏来说，英雄无敌3和英雄无敌5，很多人都玩过。英雄无敌3每回合解算超快，英雄无敌5超慢，几分钟小意思，有时候半个小时都有可能。为什么？我们知道，英雄无敌5的解算过程中，每个npc活动都是顺序执行的，甚至动画都不带省略的，如果你开上帝视角，能实际看到他们在干什么。所以如果某些npc如果脚力很高，跑的很快，反复进出地图，就非常慢。你只能慢慢等着。后来英雄无敌5的资料片就优化了很多，你看不到的区域，npc动画不渲染了，就快很多。但是事件仍然解算的很慢。
鬼谷八荒也有这个问题，那么多npc，挨个拜访，送礼，就很慢。慢在哪里？这跟渲染完全无关了，完全是系统的事儿。我们做如下分析：
1.数据的读写和解析。我猜想，鬼谷八荒采用的应该是类似MongoDB那种无键值的非关系数据库，根据存档文件的结构来看，很可能是基于JSON数据的树状存储结构，甚至都不一定使用了数据库，至少没有提示安装这部分的软件。那么鬼谷八荒的人物数据就不存在检索优化的可能性。实际上可能是这样的，所有npc作为一个人物对象类包含各种属性，双向关系指针乱七八糟，每次找朋友、敌人、师傅等等都要用指针查找目标npc的类，然后加载目标npc的属性。就像你看到你的人际关系网络一样，看上去很漂亮，实际上效率极其低下。
这种图网络关系是最乱的，类似早期的社交网络。试想一下，你的老婆的仇人的道侣的师傅打死了你徒弟的兄弟的义母，该不该通知你？中间跳跃了几个数据块？设计了几次多态类型转换？我们知道，内存寻址过程中，什么最慢？跨块寻址最慢。每次跨块寻址，都要装载目标内存区域，创建释放都要开销，你用完之后就扔了，操作系统一头懵逼。这就跟你进银行一块钱一块钱存钱一样，还用的是不同的货币！
怎么优化呢？既然人物关系这么复杂，可以建关系数据库，建立索引表。比如，所有npc都用id进行标识，建立仇人表，亲友表，师父表，道侣表等等。。。全部的关系都用键值-索引调用关系，存储在不同的表中。这么做有什么好处？现代数据库理论告诉我们，这种冗余存储的索引表速度远远快于图网络遍历，因为整个索引表存储的数据类型高度一致，键值索引采用哈希算法可以达到实时读取，更难能可贵的是支持多线程并行访问，整个关系表加载后永驻内存，不涉及任何内存替换。举个例子来说，10000个npc，采用12个线程分别处理他们的琐事，大家共享整个数据库关系索引，即便是原子操作也能毫秒内完成。大家分别读取关系索引，把写操作按队列输出到事件队列，由事件处理程序统一完成写入操作，做到读写分开，大大加快处理速度。现在大型的电商类应用支持上亿并发都是小意思，处理修仙这点小事还不是轻松愉快。 发布于 2022-05-29 10:27:12
xiongyuanxy：再来谈谈伪随机优化和巧用离屏渲染。以玩家吐槽最卡的几个流派举例。
以神通为例，水剑玩家最爱用的神通，骤天剑和万神剑，特别卡。风神通没旋风不卡，旋风多了就卡。其他神通，比如雷神通，木神通，刀神通从来不卡。火神通烈火凤卡，神火核就不卡。冰天眼四灵共生也卡，爆灵雨就不卡。为什么？
原因很简单，图元变多了，每个独立对象计算碰撞、弹道、伤害、状态，然后单独绘制，逐层绘制叠加，自然就卡。我们再来说说怎么优化。
以万神剑和骤天剑为例。如果是真随机，每次每根剑独立计算落点弹道伤害，独立绘制，就非常卡。但是如果你把它看做一个整体，比如采用一个固定的随机种子，提前算好所有弹道，通过离屏渲染整个动画的方式，就毫无压力。对玩家来讲，每个万神剑的小飞剑到底是从哪个角度飞出很重要么？骤天剑谜一般的落点每次都固定，有影响么？当然了，有些人会较真，说每次战况都不一样，提前渲染好的动画临时播放怎么能做到不违和呢？很简单。比如，你万神剑每次释放的朝向不一样，那么剑神那个雕像只需要渲染左右两个老爷爷就行了。那堆剑，提前渲染好动画，做成带alpha通道的半透明，根据实战朝向，做个旋转变换就行了。这个技术很多游戏都在用。比如，暗黑3，猎人射出去的剑从来都不严格指向目标，而明显是几个固定的动画模板之一，有时候横着飞也没人管，没人吐槽说效果不好啊。再比如说，你说游戏中有碰撞啊，碰到物体之后，飞剑的弹道要消失啊，提前渲染好的动画怎么做到这点呢？可以额外增加一个蒙版啊，碰到物体后，把蒙版区域的透明度降低，让弹道不显示就好了，而不是真正消失。
为什么整体渲染能够比分别渲染快很多呢？这要从并行优化的结构来讲。比如，一块屏幕大小的画布，面积固定。你一笔笔画上去，每一笔都要花费时间。而且，实际上内存处理也不会允许你局部更新，你没画一笔都是对整个内存进行读取复制，再局部修改，再写回到目标缓冲区，比如GPU。你还可以提前把整个动画提前画好，成为一个动画。这个动画由于是连续的数据，上传下载都很快。现在的cpu、内存、gpu对于同类型的连续数据传输都有并行优化，即使不采用多线程也会快很多。这就好比拷贝2个G的电影到U盘上，远比拷贝2个G的文件要快得多，而且把文件压缩成一个压缩包拷贝也快得多，就是因为连续性带来的并行处理速度优化。 发布于 2022-05-29 10:22:52
107072623：小宝:大佬你杀了我吧，我真不会 发布于 2022-05-29 10:20:12
武子木：有点专业，看不太懂 发布于 2022-05-29 10:19:02
zzb86756：S/L拍卖行感觉最明显，搞个几十次内存占用就翻了很多倍了 发布于 2022-05-29 10:16:12
XWX309：主要不知道释放技能时，是否都是新创建对象使用的，如果是这算法自然是卡顿的重要原因之一。 发布于 2022-05-29 10:13:42
谭言笑：别人的buff/dubuff，代码、层数、时间，每一类占12字节；鬼谷的，代码、层数、时间，每一层占12字节；1个单位身上10层就要占用120字节，还没有算其他单位身上的。每一层计数都住单间占用内存，魔兽都没这么玩的。 发布于 2022-05-29 10:13:12
xiongyuanxy：2*过程中战斗变卡，这个原因很多，但我认为最主要的还是因为图像元素在绘制过程中出现的问题。比如，我猜测，鬼谷八荒应该使用了类似图元工厂的机制，每次释放技能的时候，都对每个弹道元素创建了一个图元对象，由工厂负责生成一个副本，单独计算该弹道的触发效果、命中、伤害、状态等等诸多因素。证据就是跟踪类技能总不打空，总能找到自己的目标。火系的aoe地火术，能够做到在扩散过程中同时击杀当前的怪物和刷新出来的新怪物。这么做当然游戏体验很好，但是一旦弹道和技能变多，那么逻辑关系以及绘制代价都是线性增长的，所以水剑就卡死了。
其实，这么做完全没必要。把每个技能的弹道都看成独立对象的做法太浪费了，而且这种逻辑判断是单线程顺序执行的，跟排队似的，必须一个一个算，当然慢了！参考暴雪是怎么优化暗黑3的，把1帧或几帧内所有的伤害叠加，最后给你看个总数，至于这个伤害是一个技能打出来的还是100个弹道打出来的，重要么？玩家只需要知道自己伤害变高的趋势就行了，具体每个弹道打多少不重要。比如月影剑，在不暴击的情况下，一叠伤害（1333,1333,1333,1333）和爆一个伤害（1333*4）显示效果上一样，但是效率上完全不一样。渲染4个数字是四个独立的渲染子程序，还是串行。考虑到透明度、遮挡层次、运动模型等等，更是效率上几何级别的延缓。
再说召唤物，每个召唤物、右方单位出来后都有自己的一套时钟，buff，冷却，弹道，绘制全部都独立计算，这得多少个渲染片段才能完成？实际上可以生成一个同步时钟，每隔几帧负责计算所有召唤物和单位的所有行动，然后同步绘制。对于玩家来说，每隔蘑菇参差不齐地爆炸和6帧之内一起爆炸，差别很大么？但是效率确差别非常大。
最后说图元绘制，所有的图元都在同一个战斗场景（内存）上统一计算位置、渲染参数等信息，再上传到gpu进行图元的半透明叠加，这个非常耗时。首先半透明就非常耗时，每次渲染都需要重新使用之前的绘制结果进行叠加运算，把GPU并行绘制的优势全浪费了，变成了从后往前渲染。这相当于把跑车的发动机拆开来一个一个齿轮地转。
理论上讲，没必要半透明的就不要半透明；非要半透明的，可以通过离屏渲染提前绘制好，保存在GPU中，需要时候调出来，不要等到人物使用技能了再绘制。战斗没卡打你就可以提前把器灵、大招神通等特效绘制好，利用空闲的等待时间做后台渲染。甚至更极端一点，把这些特效利用任务逛地图和聊天的时间逐步绘制好，不要等到开打了再临时调用。这是减轻内存和gpu传输延迟的重要手段，尽量避免数据在这两个区域之间传递，最好提前存好。 发布于 2022-05-29 10:12:32
xiongyuanxy：举例子来说：
1.读取存档速度慢，那是因为从磁盘读取数据太慢。而是，我们观察鬼谷八荒的存档可以发现，文件大小不过几十MB，这么小的文件，为何读取这么慢呢？很简单，因为这些文件都是文本结构存储的，根本没有转化成为二进制数据文件。程序读取存档后，首先要从文本数据结构中把各种参数解析出来，再创建各式各样的面向对象类结构进行封装，经过一堆折腾之后再根据这些参数生成游戏里面的各种元素，实在是太慢了。实际上，大量已经生成好的数据块，根本不需要保存成文本，可以直接把内存数据整块保存成同类型的二进制文件，再整块加载，对于几个G的数据，通常一两秒就可以加载完，如果是SSD，更是忽略不计。减少内存里面创建多态的开销非常重要。
举例来说，一个地图，你可以存储哪个坐标有哪个宗门，哪些元素，哪个npc。npc又有复杂的一个整表记录他们的技能，关系，事件等等。然而这些数据解析完成后在内存中会成为一个完整的块。你保存游戏的时候，还要拆散成这么离散的逻辑关系，就太费事了。直接把整个内存块压缩成一个二进制数据文件，整体保存，就快很多。 发布于 2022-05-29 10:09:22
更多《鬼谷八荒》从程序优化的角度理性分析一波卡的原因——显卡不是锅相关问题
问题：《鬼谷八荒》从程序优化的角度理性分析一波卡的原因——显卡不是锅
回答：有什么难的，一心我都初见过，唯一卡我的就是雾隐贵人了打了半年才过 详情 >
问题：《nba2kol》下一波陈列室多久出啊，会出谁，理性分析一波
回答：事务官还有用用刺客，加将领忠诚的。 详情 >
问题：《逆战》改规则先不说，我们理性分析一波
回答：我入坑不久，目前装了100多个MOD~第一个装的就是AI事务官变脑瘫啥都不干。 详情 >
问题：《鬼谷八荒》这垃圾优化…心态终于崩了
回答：好耶 大佬新年好 详情 >
问题：《鬼谷八荒》哪位大佬能帮忙分析一下，为啥所有的互动都被拒绝（包括邀约
回答：对面有双刀还有屁精车手操不被砍炸就见了鬼 详情 >