重写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了，不是说他不好用，而是他运行在一个受限的环境里，即使写的再漂亮，也依旧屈服在浏览器爸爸淫威之下
附上安卓上打包后的一帧画面(这是我在做的另一个游戏)

糜腥珊瑚态耄耋

原始人~  启动~~！