URGE 2026 Plan

[Admenri]

这里记录一下今年要干的事：

1. 渲染部分
   虽然目前这套渲染器功能很多样，但是因为代码量过于庞大已经阻碍了项目的整体整合，
   尤其是为了网页端和安卓端现在仍要支持 OpenGL。
   虽然年初时测试 WebGPU 的性能非常烂，但毕竟他是浏览器上能运行的唯一现代API，
   经过激烈的思想斗争，还是决定将渲染后端迁移到 WebGPU，并在native端使用自己实现的 WebGPU 库：
   https://github.com/Admenri/vkgfx
   目前由于时间原因暂时暂停自制后端开发，先使用wgpu-native做为过渡：
   https://github.com/gfx-rs/wgpu-native

2. 脚本部分
   Ruby 4.0 已推出，但性能仍然不及YJIT，更比不上其他jit的脚本语言，
   为了跨平台，目前在考虑添加 CRuby 及 MRuby 两套脚本绑定。
   如果后期时间充裕，会考虑自己实现一套 Ruby 的语言运行时。

3. 对象架构
   既有架构为纯虚函数集合类（接口类）+实现类（xxxImpl）的组合，
   这套接口由于无法继承父类导致函数成员冗余，URGE26将会考虑以下形式：

• idl接口描述+直接编写Impl类，此方案由于没有接口类会导致core层的依赖与ruby层直接接触，有可能导致符号冲突
• 继续维持接口类纯虚函数模式，但是引入父类继承，此方案需要将类声明为虚继承，性能有损耗

4. 实体架构
   由于用户对画面的需要，传统RGSS的Viewport-Sprite的容器-对象架构已经很难满足一些画面特效要求，
   先将渲染实体改为Godot式的节点模式，即Viewport=World，引入Camera，引入3D的Transform
   当然，为了兼容RGSS的API设计，还需要在脚本层编写兼容转换来将2D的渲染操作映射到3D世界中。

5. 源码架构
   在既有源码中，Ruby层的胶水代码全部使用纯Python生成，重写后可考虑使用jinja2的模版引擎来更加方便的生成Ruby层胶水代码

6. IO架构
   既有一套基于ZIP的加密包读取源码，由于ZIP的特性，加密后的文件依然可以显示文件名，因此需要开发一种新的快速加密封装格式