Project1

标题: 重写rm底层后，意识到rm真是各方面都落后 [打印本页]

---

作者: 闪电超重火炮    时间: 2025-10-25 01:42
标题: 重写rm底层后，意识到rm真是各方面都落后


我好像差不多一年没发帖了
很多人说，我上次地帖子更新了pixi就能带来性能提升？
是不是逻辑搞反了？
pixi版本会带来性能提升？重写底层就不是rm了？不会是想向众人说服自己的合法性吧？

我从23年10月就开始尝试使用pixi v7，到24年正式投入v7的使用
以前在我还没淡圈的时候，给钻头群也发过一个插件，使用后能立即使用pixi v7，无需额外修改任何代码
但是这并没有导致性能提升，反而因为要通过混合继承的方式过渡class的继承，导致性能下降，这部分的耗时远比正常的混合寄生要高

随后，在24年四月份搞了一个全面面向v7 的rmmz 工程，同时期诞生了mz优化插件，mv优化插件
那个时候的理解还是想法都不太成熟，无法为广大插件体系提供良好的兼容性
24年8月份的时候，彻底放弃v7，转而对我充满诱惑力的v8，因为v8 我从23年8月份开始alpha 0测试的时候就一直在反馈建议，和其中一个开发者聊的很好
v8的发展过程是曲折的，随着越来越多的人知道v8启用webgpu后，各种杂乱的声音都开始干扰正常的开发过程
从那之后v8就不断添加各种给小孩用的东西，越来越臃肿，越来越慢
我从8.10版本正式开始使用，到8.32版本开始不再跟随 仓库发布页的版本更新
删减多余的逻辑，优化和改进各种gpu接口
然后一边完全重写rm脚本
到今年六月份的时候，实际上已经完成了一个可以发布的版本
但我很不想就这么发布，总想着更进一步，更完善一步

随后又完成了对electron的打包，对android的调试，插入了一个我一直想搞的2d实时光照(使用法线，并能模拟八方旅人的深度光，这个其实在两年前就用pixi-light搞过一个版本，
但是那个写起来的代码太繁琐，处理起来也极其啰嗦，创建双倍数量的精灵和纹理内存已经够爆炸了)
在九月份的时候又折腾起了 GPU专用的压缩纹理， 是的，你没看错，是压缩纹理，理由是在浏览器进行性能测试时，通过降低20倍cpu频率，发现 普通图片的解码占了很大的耗时(我这里用到的createImageBitmap)而不是rm的Image元素
同时 gl.teximage2d 和webgpu的 copyExternalImageToTexture都很慢，即使我已经想办法让每个动画帧不超时
于是，我花时间已经完全支持适用于windows和android的压缩纹理类型

于是，你可以得知，我在这么长的时间里都在不断尝试突破 浏览器对h5渲染性能的上限
这里说一下，对于动态的精灵，我之前测试的结果是 10w的数量上限，还能保持60的满帧，但是超过11万会被浏览器限制cpu的频率而降帧(浏览器有单个网页的资源分配上限，你不能超过这个上限)，这点在我的群里我分享过
而同样的代码，在rm上，10w的动态精灵等于电竞水平

于是有人又要说了，啊你这只有性能没有功能啊
有的，兄弟，有的，战斗系统还是场景ui都完成了重置，将每个场景单独作为rm的插件，通过插件配置来实现自定义场景，也可以自己去修改代码，毕竟我把每个场景的流程分的很清楚，场景是有阶段的
关于窗口，每个窗口都可以自己定义，
战斗移植并优化了mv的yep战斗核心，状态核心，无论在手机还是电脑，无论你的动作序列怎么复杂，状态多少，都不会让单个帧的逻辑耗时超过5毫秒(所有的battler逻辑已被高度优化)
一个简单易用且高性能的弹道系统(限战斗)
引擎框架天生支持sv敌人，敌人等级设定
重写后的天气粒子系统(将天气粒子数量由每个天气等级10的数量提高到50)，你也可以自定义上千上万的粒子数量，完全没有问题~
根据灯光，天气特调的一个时间系统，周期性改变全局光，天气变化
根据天气，灯光，时间，以及开关，变量，而做的一个任务系统，完全自动化的任务条件/目标检测，任务可完成提示，任务重置，事件自动重置以及自动收尾(带一个实时的任务进度追踪窗口)
最近在写重装机兵框架，其他功能只能后面在拓展了

现在的框架已经完全可以在任何环境下运行，保持一个很低的堆内存占用(50mb以内)
工程虽好，但我并不打算分享给我不信任的人
目前仅有个别人在使用和测试，等到全面完善也差不多是我告别这个圈子的时候，因为我馋 native端的性能很久了
web上永远无法享受最先进的技术，也永远有着比别人更大的限制
另外我有点讨厌JavaScript了，不是说他不好用，而是他运行在一个受限的环境里，即使写的再漂亮，也依旧屈服在浏览器爸爸淫威之下
附上安卓上打包后的一帧画面(这是我在做的另一个游戏)

QQ图片20251025013831.jpg (124.06 KB, 下载次数: 109)

下载附件  保存到相册

2025-10-25 01:39 上传

QQ图片20251026192250.png (9.97 KB, 下载次数: 96)

下载附件  保存到相册

2025-10-26 19:30 上传

---

作者: 糜腥珊瑚态耄耋    时间: 2025-10-25 16:05


原始人~  启动~~！


我去你不用上班嘛
摸到禁忌知识的边缘不一定是好事

---

作者: 仇九    时间: 2025-10-25 23:21
大部分使用rm的制作者需要插件，而插件代表一个具体的功能，功能是和性能要平衡的，一个体系内插件或功能越多，性能必然随之越差，rm是这样，pixi也是这样。
rm对自己的定位是一个制作者不需要写脚本的软件，至少不需要自己从头实现一个复杂的功能。这种生态已经决定了它不是一个可以较好平衡性能和功能的引擎。

目的明确就行，把功能实现的乐趣已经很让人享受了。

---

作者: zijinxing    时间: 2025-10-25 23:31
这玩应本来就是给不会编程的人做游戏的，真会编程为啥要用rpg maker做游戏啊！

---

作者: 闪电超重火炮    时间: 2025-10-26 19:07

zijinxing 发表于 2025-10-25 23:31
这玩应本来就是给不会编程的人做游戏的，真会编程为啥要用rpg maker做游戏啊！ ...

我就知道会有人这么说

---

作者: 闪电超重火炮    时间: 2025-10-26 19:18

zijinxing 发表于 2025-10-25 23:31
这玩应本来就是给不会编程的人做游戏的，真会编程为啥要用rpg maker做游戏啊！ ...

那么没有工业革命人们也能活下去，为啥还要搞工业革命推动全球进步呢？

---

作者: 闪电超重火炮    时间: 2025-10-26 19:29

仇九 发表于 2025-10-25 23:21
大部分使用rm的制作者需要插件，而插件代表一个具体的功能，功能是和性能要平衡的，一个体系内插件或功能越 ...

功能和性能本来就是可以兼得的，何况对于2d本身而言，他根本不可能太过复杂，我也提到过了，降低cpu的帧耗时，避免帧超时就可以有效解决各种卡顿。
而渲染本身的耗时都是很小的，无论是什么版本的pixi，都是一样的，这个我不止一次强调过，pixi版本对性能几乎没有影响
不过之所以要大刀阔斧的重写，是因为受够了"大佬，你能不能兼容xxx插件"
这种事情极大的影响了进度的开发，看见不好的代码还要忍住不去吃一口，很难让人舒服

没人会说开发是一件简单的事情，我这个帖子仅仅是个总结
我并不打算和任何人任何框架进行竞争，这是我在这个圈子仅剩的几个帖子
我的目标很明确，游戏，框架完成，换其他语言和引擎
我和隔壁一个开发rgss runtime的人经常讨论性能上的事情，我非常羡慕他用c++能解放本机设备的潜力
我也只有在native端打不过它的性能
而web就是一个沙盒，每个dom页面能分配的资源是有限的

另外我也附上了我的github提交记录

---

作者: 清澈淌漾    时间: 2025-10-26 20:00
其实评价就是穿着巴卡尔毕业套刷卢克

---

作者: 闪电超重火炮    时间: 2025-10-26 20:25

清澈淌漾 发表于 2025-10-26 20:00
其实评价就是穿着巴卡尔毕业套刷卢克

这是一个避不开的话题，因为我即使不用rm编辑器，我自己的底层也能自成一派，我随时都可以换其他数据作为游戏数据，甚至还可以更轻量更简化，难道我搞h5就只是为了rm？

---

作者: 清澈淌漾    时间: 2025-10-27 10:56

闪电超重火炮 发表于 2025-10-26 20:25
这是一个避不开的话题，因为我即使不用rm编辑器，我自己的底层也能自成一派，我随时都可以换其他数据作为 ...

怎么说呢，游戏重要的是内容，某些类人说RM什么优化有问题云云的， 只是做不出内容的借口，跑别的软件也做不出来东西，你真端出来个“优化版”引擎，把各种问题端台面上，把这帮”独游人”做不出游戏的最后遮羞布拉下来，你觉得他们会谢谢你么

---

作者: 小怪兽奇奇侠    时间: 2025-10-27 16:54
看到你四年前第一个帖子还在学习rm怎么用，不料四年后的今天竟强到如此地步，我要采访一下这位先生，你是四年前已经编程很强了只是刚接触rm，还是在这四年间不断学习实践成为斗宗强者？

---

作者: zijinxing    时间: 2025-10-27 22:44

闪电超重火炮 发表于 2025-10-26 19:18
那么没有工业革命人们也能活下去，为啥还要搞工业革命推动全球进步呢？ ...

如果做工业革命也会从unity或虚幻引擎入手的，按你这么说现代战争，为啥不研究一把削铁如泥的刀，而是去研究导弹和卫星呢？

---

作者: 闪电超重火炮    时间: 2025-10-28 15:55

小怪兽奇奇侠 发表于 2025-10-27 16:54
看到你四年前第一个帖子还在学习rm怎么用，不料四年后的今天竟强到如此地步，我要采访一下这位先生，你是四 ...

自己开始搞插件是22年开始自学，23年开始搞体系，24年放弃兼容，25年完全重写底层和框架，库只用了一个我魔改的pixi和一个纹理压缩官方的wasm+js库，其他的全原生自己实现
在我还是萌新的时候总去打扰各位大佬，但是总有人会不回我或者说不耐烦的说，能不能自己去学啊
是啊，就被迫自己去学了
有时候不被人搞一下不知道自己几斤几两

---

作者: 闪电超重火炮    时间: 2025-10-28 15:56

zijinxing 发表于 2025-10-27 22:44
如果做工业革命也会从unity或虚幻引擎入手的，按你这么说现代战争，为啥不研究一把削铁如泥的刀，而是去 ...

那么请问，阁下的游戏一定很棒咯
不写代码不用插件？
事件管理器的事件系统不用编程？
数据库的计算公式不用eval？

---

作者: 闪电超重火炮    时间: 2025-10-28 16:00

清澈淌漾 发表于 2025-10-27 10:56
怎么说呢，游戏重要的是内容，某些类人说RM什么优化有问题云云的， 只是做不出内容的借口，跑别的软件也 ...

说的太棒了，一堆人都在说性能问题，我就是来反驳这个问题，隔壁rgss的Admenri也在不断探索性能上限和改造rm，都是不满落后的技术
没人会嫌弃性能高，尤其是广泛的”性能瓶颈“”换个设备吧“

---

作者: 清澈淌漾    时间: 2025-10-28 16:11

闪电超重火炮 发表于 2025-10-28 16:00
说的太棒了，一堆人都在说性能问题，我就是来反驳这个问题，隔壁rgss的Admenri也在不断探索性能上限和改 ...

每个千篇一律的前端库都说自己的性能是最强的，除了所谓性能还有上手难度 社区生态 和已经投产的项目数量。
现在想技术变现太难了，只有技术党才会为技术付费。
而且做游戏已经不是前几年程序加个美术就能上路嘎嘎赚米的时代了，除了搞生产力还得研究下生产关系。

---

作者: mamamiyas    时间: 2025-10-29 01:05


相比于性能落后，我觉得调度问题才是最灾难性的，，，，，rpg的代码是一点都不考虑资源复用和细致判断。举例关于存档的，进读档界面和在界面滑动的每一下都要读取全部的存档信息来渲染画面，且经常性的用refresh进行全元素重绘，吃资源拉满了。比如下面这rpg_managers.js的三段代码，进界面时要判断哪个是最新的存档来定位到该存档处方便玩家，然后首先latestSavefileId()就调用了loadGlobalInfo()一次读取存档信息，那么loadGlobalInfo()就首先循环了一遍最大存档数来读档（空的也读，官方默认是20个档位，那么默认的情况下就至少进行了20次读取加载），然后latestSavefileId 下面又根据globalInfo.length也就是长度进行循环，长度是20那么会循环20遍，每次循环都会执行isThisGameFile()，isThisGameFile()里面又会调用loadGlobalInfo()来读档。那么latestSavefileId()里的20次循环下来至少让loadGlobalInfo执行了20+20*20=420，读了420次档，，，，，性能都白白浪费了。这还只是进界面判断最新存档用的，然后每一次滑动会让另一个结构类似的函数检测存档情况来渲染界面然后就还是经典20+20*20以及每检测出一个存档的情况就refresh全刷新一次共刷新20次，这使得每次滑动界面都卡卡的，，，，，。关于缓存机制我是感觉不到一点，给loadGlobalInfo写了个if (this.GlobalInfoLoaded === 1 && this._globalInfoCache) {return this._globalInfoCache;}的缓存复用后进界面时间消耗直接从600多ms降到了200多ms，所以原本绝对没有缓存判断的，当然我的那个游戏是80个档位，堵塞情况明显会比官方的20的严重的。然后接着给刷新和加载函数加了些判断和异步以及其它的缓存后，又降到了现在的40ms左右。
可见优化方面的潜力是很大的，不然开发插件给的性能再强大都没用。
DataManager.latestSavefileId = function() {
        var globalInfo = this.loadGlobalInfo();
    var savefileId = 1;var timestamp = 0;
    if (globalInfo) {
        for (var i = 1; i < globalInfo.length; i++) {
            if (this.isThisGameFile(i) && globalInfo.timestamp > timestamp) {
                timestamp = globalInfo.timestamp;
                savefileId = i;}}}return savefileId;}
                               
DataManager.loadGlobalInfo = function() {
    var json;
    try {json = StorageManager.load(0);} catch (e) {
        console.error(e);return [];}
    if (json) {
        var globalInfo = JSON.parse(json);
        for (var i = 1; i <= this.maxSavefiles(); i++) {
            if (!StorageManager.exists(i)) {
                delete globalInfo;}}return globalInfo;}else {return [];}
                               
DataManager.isThisGameFile = function(savefileId) {
    var globalInfo = this.loadGlobalInfo();
    if (globalInfo && globalInfo[savefileId]) {
        if (StorageManager.isLocalMode()) {return true;
        } else {
            var savefile = globalInfo[savefileId];
            return (savefile.globalId === this._globalId &&
                    savefile.title === $dataSystem.gameTitle);}}else {return false;}}
        

---

作者: 闪电超重火炮    时间: 2025-11-2 13:47

清澈淌漾 发表于 2025-10-28 16:11
每个千篇一律的前端库都说自己的性能是最强的，除了所谓性能还有上手难度 社区生态 和已经投产的项目数量 ...

但是都不是，你要上手去改，只有自己吃透了改完了才能说自己是最强的，别人的代码是不可信任的，至少对我而言是这样的

---

作者: 闪电超重火炮    时间: 2025-11-2 13:48

mamamiyas 发表于 2025-10-29 01:05
相比于性能落后，我觉得调度问题才是最灾难性的，，，，，rpg的代码是一点都不考虑资源复用和细致判断。举 ...

我难道没有重写吗，存档逻辑全部重写了啊，更少的判断，更快的绘制，更小的存档体积，1kb！！！

---

作者: aaa9451    时间: 2025-11-20 14:04
那大佬，是否可以商业一下下呢？

---

作者: 闪电超重火炮    时间: 2025-11-21 03:02

aaa9451 发表于 2025-11-20 14:04
那大佬，是否可以商业一下下呢？

等我完善完是完全可以的，目前在搞一个拓展编辑器

---

欢迎光临 Project1 (https://rpg.blue/)

Powered by Discuz! X3.1