DDrawCompat架构深度解析：让经典游戏在Win11上满血复活的兼容层是怎么炼成的

DDrawCompat架构深度解析：让经典游戏在Win11上满血复活的兼容层是怎么炼成的

【免费下载链接】DDrawCompatDirectDraw and Direct3D 1-7 compatibility, performance and visual enhancements for Windows Vista, 7, 8, 10 and 11项目地址: https://gitcode.com/gh_mirrors/dd/DDrawCompat

你是否遇到过这样的场景：翻出十年前珍藏的《暗黑破坏神2》或《星际争霸》，兴冲冲装到Windows 11上，结果画面花屏、切屏黑屏、鼠标残影，甚至直接崩溃？问题不在游戏本身，而在于这些老游戏依赖的DirectDraw与Direct3D 1-7 API，早已被现代Windows系统"半抛弃"。DDrawCompat正是为填补这道技术断层而生的兼容层——一个不修改游戏二进制、仅靠DLL注入就能让经典游戏在现代系统上流畅运行的开源项目。

老游戏为什么"水土不服"

在Windows XP时代，游戏调用DirectDrawCreate创建表面、用Blt拷贝位图，一切顺畅自然。但进入Vista之后，微软用WDDM驱动模型取代了老旧的XP驱动模型，DirectDraw的硬件加速路径被大幅削弱：全屏独占模式名存实亡，调色板表面支持缺失，垂直同步行为诡异。更棘手的是，现代GPU驱动（包括Win10/Win11上的D3D9on12）对老API的"宽容度"越来越低。

玩家通常的救急方案是换系统、装虚拟机、或用社区魔改驱动，但各有各的坑。DDrawCompat选择了一条更优雅的路：把自己伪装成游戏目录里的ddraw.dll，在游戏加载时抢先接管所有DirectDraw调用，然后在幕后把它们翻译成现代驱动能理解的语言。

设计思路：一个会"偷梁换柱"的翻译官

把DDrawCompat想象成一位随身翻译官：游戏说的是"方言"（DirectDraw 1-7），现代驱动说的是"普通话"（WDDM/D3D）。翻译官不改变说话者的原意，只是在两者之间做实时转译。

整个架构的支点在于vtable钩子（vtable hook）机制。COM接口的每个方法都通过一张虚函数表（vtable）间接调用，DDrawCompat的做法是：在游戏调用DirectDrawCreate的瞬间，把返回对象整张vtable中的函数指针替换成自己的实现，同时保存原始指针。这样游戏每次调用都会被"截获"，经过兼容处理后再转发给原函数。

核心代码位于Common/VtableHookVisitor.h，这段模板代码是整个钩子系统的引擎：

template <typename Vtable, typename Lock> class VtableHookVisitor { public: VtableHookVisitor(const Vtable& vtable) : m_vtable(const_cast<Vtable&>(vtable)) {} template <auto memberPtr> void visit(const char* funcName) { if (m_vtable.*memberPtr) { // 把原始函数指针替换为我们的钩子 m_vtable.*memberPtr = &hookFunc<memberPtr>; } } private: template <auto memberPtr, typename Result, typename FirstParam, typename... Params> static Result STDMETHODCALLTYPE hookFunc(FirstParam firstParam, Params... params) { // 先记日志，再获取兼容实现并调用 constexpr auto compatFunc = getCompatFunc<memberPtr, Vtable>(); return LOG_RESULT(compatFunc(firstParam, params...)); } };

这段代码的精妙之处在于全部用模板在编译期完成。visit负责"换指针"，hookFunc是通用钩子壳：它先用日志宏记录调用参数，再通过getCompatFunc从CompatVtable中取出对应的兼容实现（如果没提供兼容实现，就回退调用原始函数）。一个模板同时服务于QueryInterface、Lock、Blt等几十个方法，避免了为每个API手写一遍转发逻辑。

模块拆解：三层防线如何协作

第一道防线：DDraw层的"老接口接盘"

DDraw/目录负责处理游戏看得见的DirectDraw接口。以CreateSurface为例（见DDraw/DirectDraw.cpp），它并不简单地透传，而是先判断表面类型：

• 如果是主表面（PrimarySurface），会转交给PrimarySurface::create走特殊的全屏/窗口化处理；
• 如果是调色板索引表面，会根据当前桌面色深和配置决定是否升级为纹理表面，让老旧的8位色游戏在现代GPU上还能正常上色。

这里的核心思想是"按表面用途分流"。游戏要的是一块普通离屏缓冲，还是需要与GDI协同的系统内存表面？不同用途对应不同的现代实现路径，分流逻辑把复杂度收拢在创建入口，后续的Lock/Blt操作就能走各自的优化通道。

第二道防线：D3dDdi层的"驱动直通车"

如果说DDraw层是前台客服，D3dDdi/目录就是后台的工程部门。Windows的图形驱动暴露的是D3DDDI（Direct3D Device Driver Interface），DDrawCompat直接钩住这条通道，绕过了Windows对老API的种种限制。看D3dDdi/Device.cpp中一个典型处理：

HRESULT Device::createPrivateResource(D3DDDIARG_CREATERESOURCE2& data) { const auto origFormat = data.Format; if (D3DDDIFMT_P8 == data.Format) // 8位调色板格式 { data.Format = D3DDDIFMT_L8; // 转换成亮度格式 if (!data.Flags.Texture) { data.Flags.Texture = 1; // 强制按纹理创建 } } HRESULT result = m_origVtable.pfnCreateResource2 ? m_origVtable.pfnCreateResource2(m_device, &data) : m_origVtable.pfnCreateResource(m_device, ...); data.Format = origFormat; // 恢复原始格式，欺骗调用方 return result; }

现代GPU根本不认识P8调色板格式，直接创建必然失败。这里的处理是"偷天换日"：创建时换成驱动支持的L8格式，创建完再把结构体里的格式改回去——游戏以为拿到了调色板表面，实际上背后是纹理，上色工作由DDrawCompat自己调度。这正是兼容层最典型的"两头骗"手法。

第三道防线：D3D9on12的"终极翻译"

在只有D3D12驱动的机器上，连D3D9都是模拟出来的。D3dDdi/Hooks.cpp里有一段格外硬核的代码：它钩住GetProcAddress和GetPrivateDDITable，把用户态驱动的OpenAdapter、KMTPresent等入口全部替换成自己的版本，甚至能识别出当前驱动是不是d3d9on12，从而在呈现（Present）时插入垂直同步、帧率限制等现代功能。至此，DDrawCompat实际上建立了一条"游戏 → DirectDraw → 自研逻辑 → 驱动DDI → 现代GPU"的完整链路。

配置与应用：拿到手怎么用

DDrawCompat采用INI文件配置，且支持"游戏可执行文件名.ini"这种按游戏定制的方式。一个典型的2D老游戏优化配置如下：

; 放在游戏目录，命名为 游戏名.ini 即可自动生效 [Graphics] SpriteDetection = on SpriteFilter = bilinear PalettizedTextures = on DisplayFilter = lanczos [Performance] FpsLimiter = 60 VSync = on CpuAffinity = performance_cores [Compatibility] GdiInterops = all SurfacePatches = aggressive

上手流程很简单：把项目构建出的ddraw.dll复制到游戏安装目录（游戏会优先加载同目录DLL），再按需放一份配置文件。遇到花屏先关DisplayFilter，遇到卡顿先查FpsLimiter，遇到切屏崩溃优先调GdiInterops——这是社区排查问题的三板斧。

性能与调试：怎么证明"变快了"

兼容层最大的顾虑是性能损耗。DDrawCompat的优化手段相当务实：VertexBufferMemoryType让顶点缓冲落在CPU写入最快的Upload堆；PresentDelay通过延迟呈现减少输入延迟；CpuAffinity把游戏线程钉在指定核心上。而调试侧，内置日志系统按Error/Warning/Info/Debug/Trace分级输出，配合CrashDump设置可以在崩溃时生成转储文件——当年排查"切屏黑屏"这类玄学问题，靠的就是这两件套。

构建与参与：从使用者到贡献者

构建需要Visual Studio 2022和Windows SDK，克隆仓库后直接打开DDrawCompat.sln编译即可：

git clone https://gitcode.com/gh_mirrors/dd/DDrawCompat

项目虽不接受Pull Request，但贡献方式同样实在：报告带复现步骤的bug、分享某款游戏的最佳配置、在不同显卡上做性能测试，都能帮助这个项目覆盖更多"疑难杂症"。

结语

回到开头那个场景：当老游戏在现代系统上重新亮起熟悉的画面，背后是vtable钩子的精确拦截、调色板格式的偷天换日、以及DDI层级的直连翻译。DDrawCompat的价值不止于技术——它用一套精密的兼容层，守住了数字时代的文化记忆，让技术演进不必以牺牲经典为代价。

【免费下载链接】DDrawCompatDirectDraw and Direct3D 1-7 compatibility, performance and visual enhancements for Windows Vista, 7, 8, 10 and 11项目地址: https://gitcode.com/gh_mirrors/dd/DDrawCompat