我在给一个20年前的闭源游戏引擎（官方只提供32位bin）做图形升级，目前的进度是用现代渲染方法重写了整个渲染管线，从OpenGL 1.1升级到了OpenGL 4.4 Core Profile，并且在逆向出来的引擎中接入了RHI用D3D12/VK复刻了OpenGL 4.4 Core Profile版本的渲染管线：
A、闭源的官方游戏引擎(官方的32位game bin) → hook 引擎自己的绘制流程 → 自己重新手搓一套渲染管线 → OpenGL 4.4 Core Profile
B、逆向版本的引擎(自己编译的64位game bin) → 自己重新手搓一套渲染管线 → RHI → D3D12/VK
我的最终目标是给这个垃圾引擎接入路径追踪管线+超分，但是考察了一下发现NV和AMD根本不给32位（WOW64）进程提供DLSS/FSR支持，并且DXR与Vulkan的raytracing extension在32位进程下也没有expose。至于32位进程动不动OOM，renderdoc抓帧各种爆炸那都是小问题了。
老黄那边倒是有一个NVIDIAGameWorks/dxvk-remix（前RTX-Remix）有类似的功能，不过它是接管D3D7/D3D8调用然后转发给64位进程再用Vulkan自己渲染，并不支持接管OpenGL，并且完全没有后续可能会支持OpenGL的迹象。
如果我把闭源的官方32位game bin杀了，走自己的64位逆向版本的话，会有一个很难解决的问题：64位的engine bin没法支持闭源的32位的mod bin，也就是说我要支持哪个mod，就必须把这个mod的client/server源码全部逆向出来才能用。
如果走官方32位game bin的话，会涉及渲染调用转发的问题，我得自己造一套跟dxvk-remix差不多的东西，把渲染调用全部转发到64位进程里，这个工作量感觉也不小。
题外话：我为什么说这个引擎垃圾呢？因为各种内存泄露、越界写入、越界访问、纸糊验证+ACE（在允许玩家自定义上传的assets里随便改几个字节能把所有加载了这个assets的引擎炸穿）、UB满天飞，甚至有视觉效果依赖越界访问bug的，把越界访问修了会导致视觉效果变化，看过codebase能不骂一句的是这个 
1 个帖子 - 1 位参与者