简介：这是一份用 C++ 编写的 Direct3D 钩子源码，主要解决游戏中透视功能的实现问题。程序通过拦截 D3D 渲染的关键函数，在运行时修改视图矩阵或投影矩阵，从而获得类似透视的视觉效果；适合具备一定 C++ 与图形学基础、正学习游戏逆向或图形编程的开发者。压缩包共 71 个文件，约 67.5MB，内含 C++ 源码与头文件、Visual Studio 工程文件、调试符号文件以及编译生成的可执行文件和动态库，打开即可查看完整项目结构。目前已有 310 人学习或下载。透过源码可以认识钩子拦截的基本方法，理解 D3D 渲染管线和矩阵变换原理，并掌握编写自定义钩子函数、计算新矩阵、解除钩子的完整流程；作为一套可直接运行的 C++ 示例，对游戏辅助或安全研究也有较高的参考价值。
1. 这份 D3DHook 源码解决什么问题：先看懂再决定要不要下
网上聊 D3D Hook 的帖子不少，但多数只有几十行 vtable 替换片段，没有完整工程。我拿到 D3DHOOK.zip 时，第一反应是它比碎片代码多了一套完整的 VS 解决方案：一个宿主 exe 加一个 game.dll，从设备创建到 EndScene 挂勾全链路由源码串起来，能编译、能调试，不是纸面讨论。这份源码的核心是用 C++ 实现对 Direct3D 9 渲染过程的 API Hook，在拦截点修改视图矩阵与投影矩阵，进而实现对画面的透视效果修改。适合两类人：一类是做游戏图形研究或逆向工程的开发者，想在自研渲染器或单机测试环境里验证 Hook 思路；另一类是把 D3D 当能力拓展的 C++ 程序员，想看看一个带资源的 Dialog 工程怎么与 DLL 协作。下文从工程结构、Hook 原理、矩阵改动到常见翻车点逐步拆解，尽量让熟悉 C++ 但没碰过 D3D 的人也能照着复现。
2. 为什么 D3D Hook 都绕不开设备对象：vtable 与渲染管线的对应关系
2.1 Direct3D 9 的渲染主循环与设备虚函数表
Direct3D 9 是 COM 组件体系。游戏启动时调用 Direct3DCreate9 拿到 IDirect3D9 工厂接口，再调用 CreateDevice 拿到 IDirect3DDevice9 设备接口。从这一刻起，所有渲染操作——清屏、设置顶点格式、绘制图元、呈交换页——全都是 IDirect3DDevice9 的成员方法。对 Hook 来说，设备接口是所有渲染路径的必经关卡，Clear、BeginScene、EndScene、Present、DrawIndexedPrimitive 全部集中在这个接口上。
每个设备实例内存布局的第一个 DWORD 都是虚函数表指针，也就是 vtable。这个 vtable 是公开且稳定的，按 COM 接口头文件的顺序排列：index 17 是 Present，index 42 是 EndScene。常见做法是直接读取*(DWORD**)ppDevice拿到表地址，然后替换表里的函数指针。这比在函数入口处做字节级 inline patch 简单得多，不需要处理指令长度对齐，也不依赖具体 CPU 指令，代码的可移植性更好。
要注意 vtable 索引在不同 SDK 版本里并不是绝对不变。Direct3D 9 从 2002 年发布到现在，头文件里的方法顺序基本冻结，所以 17 和 42 这两个索引在实践里非常稳定。但 D3D10、D3D11、D3D12 的设备接口结构完全不同，D3DHOOK 这种写法不能直接平移过去。拿到一份 Hook 源码，第一件事就是确认它针对哪个 D3D 版本，别用 D3D9 的经验硬套 D3D11 游戏。
2.2 API Hook 与 VTable Hook：两条路线怎么选
Hook 的落地方式大致分两派。一派叫 API Hook，直接拦截系统 API 或 COM 接口方法，游戏调用到某个函数时先走你的代码；另一派叫 VTable Hook，改写 C++ 对象的虚函数表条目，让对象调用方法时跳到你的函数。D3D 设备本身就是 COM 对象，所以这两个概念在 D3D 场景里实际是重叠的——改写 IDirect3DDevice9 的 vtable 既是 API Hook 也是 VTable Hook。这份源码选的路线，本质上是在 COM 接口层做拦截。
为什么不选 inline hook 那种更底层的做法？因为 D3D9 设备的 vtable 替代表只有一个风险点：必须保证替换前后函数签名完全一致，否则参数错位会导致程序崩溃。而 inline hook 要在函数开头写入跳转指令，遇到锁定页面或自校验代码就是一场灾难。D3DHOOK 走 vtable 替换，换来的是代码稳定和编译期类型安全，代价是拿不到原函数内部细节。如果你想知道游戏每帧传了哪些顶点数据，仅靠替换 vtable 是不够的，还需要配合 WRP 包裹函数去读参数。
从工程角度看，vtable 替换还有一个隐藏优势：它可以做成懒加载。不需要在 DllMain 里急着干活，可以先等设备创建完成，再从真实设备实例上拷贝 vtable 地址，替换其中几个条目。D3DHOOK 的工程结构走的就是这个思路，下面拆包时会看到。
2.3 为什么把设备创建当作第一个 Hook 点
游戏画面出现之前的源头是设备创建。如果只替换 Present 或 EndScene，你必须等设备指针出现才能操作，问题是设备创建前你根本不知道 vtable 地址在哪。D3DHOOK 采取的常见做法是先拦 CreateDevice：当游戏调用 IDirect3D9::CreateDevice 时，在返回前把设备指针截获，然后立刻替换设备 vtable 中感兴趣的方法。这样一来游戏自以为拿着正常设备，实际每个渲染调用都经过了你的转发函数。
// game.cpp —— 截获 CreateDevice 返回时的设备指针，并替换 vtable 条目 HRESULT WINAPI HookCreateDevice( LPDIRECT3D9 pD3D, UINT Adapter, D3DDEVTYPE DeviceType, HWND hFocusWindow, DWORD BehaviorFlags, D3DPRESENT_PARAMETERS* pPresentationParameters, IDirect3DDevice9** ppReturnedDeviceInterface) { HRESULT hr = g_oldCreateDevice(pD3D, Adapter, DeviceType, hFocusWindow, BehaviorFlags, pPresentationParameters, ppReturnedDeviceInterface); if (SUCCEEDED(hr) && ppReturnedDeviceInterface && *ppReturnedDeviceInterface) { LPDIRECT3DDEVICE9 pDevice = *ppReturnedDeviceInterface; DWORD* pVTable = *(DWORD**)pDevice; // 取设备 vtable 首地址 g_oldPresent = (Present_t)pVTable[17]; // 保存原 Present g_oldEndScene = (EndScene_t)pVTable[42]; // 保存原 EndScene DWORD dwOldProtect = 0; VirtualProtect(&pVTable[17], sizeof(DWORD) * 2, PAGE_READWRITE, &dwOldProtect); pVTable[17] = (DWORD)HookPresent; // 替换 Present pVTable[42] = (DWORD)HookEndScene; // 替换 EndScene VirtualProtect(&pVTable[17], sizeof(DWORD) * 2, dwOldProtect, &dwOldProtect); } return hr; }逻辑说明：先调用原始 CreateDevice 让设备正常创建，成功后从返回的设备指针读取 vtable 地址。原函数的地址存进 g_old 系列变量，随后把表中 Present 和 EndScene 两个条目指向自己的 Hook 函数。VirtualProtect 是把 vtable 所在页改成可写，否则在部分系统上直接写 vtable 会触发访问违规。
参数说明：BehaviorFlags 在 Hook 原函数时原样传递，不要自作主张改；如果你为了调试把 Hardware Vertex Processing 改成 Software，某些游戏会直接拒绝创建设备。CreateDevice 的失败返回值一般不是 D3DERR_INVALIDCALL 就是 D3DERR_NOTAVAILABLE，看到这两个错误先检查参数透传是不是被改动过。
3. 拆解 D3DHOOK.zip：宿主 exe、Hook DLL 与预编译产物的分工
3.1 解决方案结构：一个 exe 加一个 dll 的经典分层
解压后不是单个源码文件，而是一整个 Visual Studio 解决方案目录。D3DHOOK.sln 是解决方案入口，里面挂着两个项目：D3DHOOK 和 game。D3DHOOK 项目包含 D3DHOOKDlg.cpp、resource.h、D3DHOOK.rc，从文件名能看出这是一个 MFC 对话框应用，它编译成 D3DHOOK.exe，角色是宿主程序，负责加载 game.dll、显示调试界面、控制 Hook 的开启关闭。game 项目包含 game.cpp、game.h、dllmain.cpp，编译成 game.dll，这才是真正干活的 Hook 模块。
两个项目的分工其实很符合实际工程习惯：宿主程序管人机交互，DLL 管技术动作。我在自己写 Hook 类工具时也倾向于拆两层，因为 DLL 注入目标进程后，调试 DLL 内部逻辑比调试注入器痛苦得多，把界面和注入逻辑隔离，至少还能用 OutputDebugString 从 DLL 里往外打日志，宿主这边统一接收。D3DHOOK 这套结构算是一个可以直接抄的模板。
Debug 目录里能看到编译后的 game.dll、game.exp、game.lib、game.ilk 和 D3DHOOK.exe、D3DHOOK.pdb。game.exp 和 game.lib 说明 game 项目导出过函数，这说明 DLL 不只是被动注入，还暴露了接口给宿主调用。D3DHOOK.ilk 是增量链接文件，说明最后一次编译大概率是增量的，不是干净 rebuild。这些推断对复现价值不小——拿到源码后如果你改动过文件，优先做一次 Rebuild Solution，别让 Incremental Link 产生的祖传 .ilk 影响判断。
| 文件 | 项目归属 | 作用 |
|---|---|---|
| D3DHOOK.sln / D3DHOOK.v12.suo | 解决方案 | VS2013 工程文件，v12 对应 VS2013 |
| D3DHOOKDlg.cpp / D3DHOOK.h | D3DHOOK | MFC 对话框逻辑，宿主角色的入口 |
| dllmain.cpp / game.cpp | game | Hook 线程入口与核心 Hook 逻辑 |
| stdafx.cpp / targetver.h | 两个项目 | 预编译头与平台 SDK 版本控制 |
| Debug/game.dll | game | 编译产物，真正被加载进目标进程的模块 |
3.2 dllmain.cpp：入口只干一件事，剩下的交给工作线程
DllMain 是动态库的入口函数，但也是 Windows 加载器锁的核心区域。在 DllMain 里做复杂操作是新手最容易踩的雷：LoadLibrary、创建窗口、等待线程这些动作在加载器锁内执行，一旦目标进程的另一个线程也在加载 DLL，就会死锁。D3DHOOK 的 dllmain.cpp 走的是推荐路线——入口只负责创建一个工作线程，真正的 Hook 逻辑全部挪到独立线程里跑。
// dllmain.cpp —— DLL 入口，所有耗时操作都交给工作线程 #include "stdafx.h" BOOL APIENTRY DllMain(HMODULE hModule, DWORD dwReason, LPVOID lpReserved) { switch (dwReason) { case DLL_PROCESS_ATTACH: DisableThreadLibraryCalls(hModule); // 减少 DLL_THREAD_ATTACH 通知开销 CreateThread(NULL, 0, HookThreadProc, hModule, 0, NULL); break; case DLL_PROCESS_DETACH: // 这里只做清理，不等待线程结束，否则同样可能死锁 break; default: break; } return TRUE; }逻辑说明：DLL_PROCESS_ATTACH 时先调用 DisableThreadLibraryCalls，告诉系统不需要为每个新线程发送 DLL_THREAD_ATTACH 通知，这在多线程游戏里能显著降低负载。然后 CreateThread 启动 HookThreadProc，线程函数里再做轮询、等待窗口句柄、创建设备等操作。
参数说明：CreateThread 的第四个参数传 hModule 是为了让线程函数能拿到模块句柄，后续解析资源或导出函数时用。注意 CreateThread 返回值没有保存，这是一个常见的隐患——如果 HookThreadProc 启动失败，进程不会收到任何提示而是静默退出。我在类似工程里会保存线程句柄并在 DllMain 末尾判断，至少打一条日志。
3.3 game.cpp：轮询等待窗口、创建虚拟设备、完成替换
game.cpp 是整套 Hook 逻辑最厚的一层。工作线程启动后，第一步通常是轮询目标窗口句柄，第二步创建虚拟设备拿 vtable，第三步才是替换函数指针。为什么要绕一圈？因为游戏主窗口还没出现时，设备可能已经创建但 vtable 地址你拿不到稳定值，轮询等窗口是保证时序最简单的方式。
// game.cpp —— 工作线程：等待窗口、创建虚拟设备、替换 vtable DWORD WINAPI HookThreadProc(LPVOID lpParam) { HWND hWnd = NULL; do { hWnd = FindWindowW(NULL, L"目标游戏窗口标题"); // 实际使用时换成目标窗口 if (!hWnd) Sleep(200); } while (!hWnd); LPDIRECT3D9 pD3D = Direct3DCreate9(D3D_SDK_VERSION); if (!pD3D) return 1; D3DPRESENT_PARAMETERS pp = { 0 }; pp.Windowed = TRUE; pp.SwapEffect = D3DSWAPEFFECT_DISCARD; pp.BackBufferWidth = 1; pp.BackBufferHeight = 1; LPDIRECT3DDEVICE9 pDummyDevice = NULL; if (FAILED(pD3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &pp, &pDummyDevice))) { pD3D->Release(); return 2; } DWORD* pVTable = *(DWORD**)pDummyDevice; // 拿到 vtable 地址 // 这里把 pVTable[17] 和 pVTable[42] 替换为 Hook 函数 pD3D->Release(); pDummyDevice->Release(); return 0; }逻辑说明：线程先阻塞式轮询目标窗口，窗口出现后创建 D3D9 环境和一个 1x1 后备缓冲的虚拟设备，用这个虚拟设备读取 vtable 地址。替换完成后立即释放虚拟设备，因为后续 Present 和 EndScene 的 Hook 函数会操作真实设备。
参数说明：BackBufferWidth 和 BackBufferHeight 设为 1 是为了最小化虚拟设备资源开销；D3DCREATE_SOFTWARE_VERTEXPROCESSING 在虚拟设备上足够用，而且比硬件顶点处理更容易在不同显卡驱动上成功。窗口标题匹配用精确匹配比子串匹配安全，避免误匹配到其他窗口。
4. 透视矩阵调整：在世界、视图、投影三个环节选对下手位置
4.1 从 3D 顶点到 2D 屏幕的矩阵链条
D3D 里一个顶点要经过三组矩阵才能落到屏幕上：世界矩阵 World 决定物体在场景里的位置，视图矩阵 View 决定相机在哪里看，投影矩阵 Projection 决定镜头能看到多远多宽。最终显示坐标 = 顶点坐标 × World × View × Projection，这个顺序是固定的，任何一组矩阵变了，画面透视关系都会跟着变。
想实现透视修改，有三个下手位置可选。改 World 矩阵会影响单个物体的摆放，改动太局部，不适合做全局透视。改 View 矩阵可以移动或旋转相机，效果类似把视角抬高、拉近，适合做位置类透视。改 Projection 矩阵可以调整 FOV 和裁剪面，画面会变宽或变窄，近处物体的大小比例随之变化。D3DHOOK 源码里主要动 View 和 Projection，这是最常见的组合——用 View 矩阵调整观察点位置，用 Projection 矩阵调整视野范围。
要理解修改后的画面效果，关键是明白矩阵乘法不满足交换律。World × View 和 View × World 完全是两个结果。这就是为什么许多人在改矩阵时发现物体飞得到处都是——乘法顺序不对，行主序和列主序又搞混，最终结果不是想要的效果。
4.2 在 SetTransform 的 Hook 点改写矩阵
游戏每帧都会调用 SetTransform 设置当前变换矩阵。D3D 设备接口里的 SetTransform 签名是固定的，这给了 Hook 一个非常干净的介入点：当检测到游戏调用 SetTransform 且状态是 D3DTS_VIEW 时，把传入的矩阵做一次复合变换，再把新矩阵交给原始函数。
// game.cpp —— 在 SetTransform 钩子内修改视图矩阵，实现观察点偏移 typedef HRESULT(WINAPI* SetTransform_t)( LPDIRECT3DDEVICE9, D3DTRANSFORMSTATETYPE, const D3DMATRIX*); SetTransform_t g_oldSetTransform = nullptr; HRESULT WINAPI HookSetTransform( LPDIRECT3DDEVICE9 pDevice, D3DTRANSFORMSTATETYPE State, const D3DMATRIX* pMatrix) { if (State == D3DTS_VIEW) { D3DXMATRIX matOffset; D3DXMatrixTranslation(&matOffset, 0.0f, 1.5f, 0.0f); // 视点上移 1.5 单位 D3DXMATRIX matNew; D3DXMatrixMultiply(&matNew, &matOffset, (D3DXMATRIX*)pMatrix); return g_oldSetTransform(pDevice, State, &matNew); } return g_oldSetTransform(pDevice, State, pMatrix); }逻辑说明：拦截到 D3DTS_VIEW 时，构造一个平移矩阵，把观察点沿 Y 轴抬高 1.5 个单位，再和原始视图矩阵相乘，最后把新矩阵传给原始 SetTransform。由于 View 矩阵代表相机位置，这个操作实际是把相机整体抬高了，画面会出现明显的俯视或透视形变。
参数说明：matOffset 平移量的单位是 D3D 世界的空间单位，不是像素。具体数值要看游戏场景尺度——有的游戏一个单位等于一厘米，有的等于一米。第一次调试时系数设小一点，从 0.1 开始逐步加，看到画面变化后再调到合适值。D3DXMatrixMultiply 的第一个参数是输出矩阵，调用顺序是输出 = 左矩阵 × 右矩阵，把这个顺序记牢能省很多调试时间。
4.3 行主序与乘法顺序：最容易翻车的数学细节
D3DX 数学库的矩阵是行主序存储，这是历史包袱也是现实。Direct3D 9 的顶点变换约定是行向量乘以矩阵，所以组合顺序必须是 World × View × Projection，而不是反过来。很多人从 OpenGL 转过来，习惯列主序的列向量约定，把乘法顺序写反，结果相机绕着场景乱转，根本不成形。
判断自己的矩阵约定对不对，有个最简单的验证方法：取一个原点附近的顶点 (0, 0, 0, 1)，乘以整个 WorldViewProjection 矩阵组，看结果落在屏幕坐标的大致范围。如果变换后坐标远离屏幕空间并且数值畸形增长，几乎可以断定乘法顺序反了。D3DX 还提供了 D3DXMatrixIsIdentity 这类辅助函数，调试时可以把每帧矩阵打印出来，手工验证是否为单位阵或正常的平移缩放矩阵。
矩阵 Hook 另一个隐蔽问题是作用时机。游戏可能在同一帧里多次调用 SetTransform，有些是初始化，有些是真正渲染。如果每帧无条件修改 View 矩阵，会导致画面抖动或闪烁。我一般会加一个开关变量，只有开关打开才执行矩阵修改，默认关闭；确认效果正常后再打开。这个习惯能省掉大量反复编译的时间。
5. 编译、注入与运行避坑：五个真实翻车现场与修复方法
5.1 现象：game.dll 加载后游戏直接闪退
第一次加载 game.dll，游戏瞬间退出，没有任何报错框，事件查看器里也只有 APPCRASH。
原因：DllMain 里做了耗时操作。很多新手把虚拟设备创建直接写进 DllMain 的 DLL_PROCESS_ATTACH 分支，此时 Windows 持有加载器锁，CreateDevice 又牵扯 COM 初始化和窗口消息，两相叠加就死锁，进程被系统强制结束。
解决：DllMain 只保留 CreateThread，所有 D3D 相关操作挪到工作线程。如果线程创建后依然闪退，检查工作线程里是否调用了 WaitForSingleObject 等待主线程消息——D3D9 设备创建需要窗口消息泵，等待主线程会等死。正确姿势是让工作线程自己在 Sleep 循环里轮询。
5.2 现象：Hook 后画面出现红色闪烁或纹理全丢
现象是画面能出，但物体表面不断闪红，纹理时有时无，像是渲染状态被破坏。
原因：Hook 函数内部调用 D3D 函数引发了递归。比如在 EndScene 钩子里又调用了 EndScene 或 Present，或者直接调用 SetRenderState 改了设备状态。D3D9 设备状态是有延续性的，你在 EndScene 里改掉的渲染状态不会自动还原，游戏下一次绘制就拿到了被污染的状态，纹理自然出错。
解决：Hook 函数里只做两件事——读取 vtable 和保存原函数指针，要么做矩阵运算，用完立即恢复设备状态。不要把任何调试用绘制指令放在 EndScene 钩子里不加保护地执行。如果非要在画面里画调试信息，记住先 PushState 再 PopState，用 D3D9 的状态块功能把改动圈在局部。
5.3 现象：VS2022 打开工程就报 d3dx9.h 找不到
用 VS2022 打开 D3DHOOK.sln，编译报错 fatal error C1083: 无法打开包括文件 d3dx9.h，或者提示需要安装 Windows SDK 旧版本。
原因：D3DHOOK.v12.suo 是 VS2013 的工程配置，D3D9 的头文件随 Windows SDK 提供，但 d3dx9.h 是旧 DirectX SDK（June 2010）的一部分，不在新版 Windows SDK 里。你在 VS2022 里不配置包含目录，系统就找不到这个头文件。
解决：在项目属性 → VC++ 目录 → 包含目录里追加 DirectX SDK 的 Include 和 Lib 路径。如果不想装旧 SDK，可以引入 Microsoft.DXSDK.D3DX 的 NuGet 替代包，或者把源码里 d3dx9.h 相关的类型和函数用 D3D9 原生接口替换掉——工作量不大，D3DXMatrix 系列函数完全可以手写替代。
5.4 现象：Hook 装上了，但游戏画面毫无变化
DLL 能加载，日志也打出来了，替换 vtable 成功，但游戏画面完全没有任何修改迹象。
原因：位数不匹配或游戏用了混合渲染。如果 D3DHOOK 工程编译成 32 位 DLL，而游戏是 64 位进程，LoadLibrary 会失败但游戏不会闪退。另一个常见原因是游戏不是直接用 IDirect3DDevice9 渲染，而是套了一层 D3D9 的 WRP 包装器，你换了设备 vtable，游戏实际调用的却是另一个对象的函数。
解决：先确认进程位数一致，用任务管理器看游戏进程架构。再在 Hook 函数第一行打日志，确认原函数是否真的被调用。如果日志没有输出，说明游戏用的渲染接口根本不是 IDirect3DDevice9，需要换技术路线，比如找游戏引擎暴露的渲染回调，而不是从系统 D3D 层下手。
5.5 现象：GPU 报错 D3DERR_DEVICELOST 或设备已移除
运行一段时间后弹出 GPU 发生崩溃或 D3D 设备已移除的报错，游戏画面冻结，资源管理器重启显卡驱动。
原因：设备丢失状态处理不当。游戏切到全屏，你按 Alt+Tab 切出，D3D9 设备进入 LOST 状态，此时再调用任何绘制函数都会失败。你的 Hook 函数如果每帧无条件执行矩阵运算和绘制，就会在这种状态下陷入崩溃循环。
解决：必须在 Hook 里检查设备状态。调用 GetDeviceState 或 TestCooperativeLevel，发现设备丢失就跳过所有后续逻辑，等设备恢复。同时把 Hook 函数里的操作尽量只做数值运算，不要调用会触发底层 GPU 作业的接口。如果你在 Hook 里创建了纹理或顶点缓冲，设备丢失后这些资源全部失效，要重新创建，别在旧资源上操作。
6. 验证与延伸：把 Hook 从能跑变成可调
先解决一个问题：替换 vtable 成功后怎么确认 Hook 真的在走你的函数？最直接的手段是拿 DebugView 看 OutputDebugString 输出。在 HookCreateDevice 和 HookPresent 里各打一条日志，启动游戏，如果只看到设备创建日志而看不到 Present 日志，说明替换的函数没被调用，问题在 vtable 索引或原函数指针保存错误。如果两条日志都在，但画面没变化，问题就出在矩阵计算逻辑或者状态设置时机上。
我验证矩阵是否生效的标准做法是做一个对比实验：先保持原始矩阵不动，把修改前后的矩阵各打印一次，手工核对平移量是否真的叠加进去了。这比直接看画面浮动靠谱得多，因为画面变化既可能是矩阵生效，也可能是游戏本身挂了。
最后一步是我现在强烈建议你养成的习惯：把魔数抽成参数。D3DHOOK 源码里偏移 1.5 个单位是写死的，实际调试中这个数值可能要反复调整。我会把这些数值放到配置文件或注册表里，每次改动不用重编译。同样，View 矩阵的修改是否启用也要做成开关，验证的时候先关掉确认画面回到原样，再打开对比差异。
// game.cpp —— 把偏移量改为可配置参数 static float g_fViewOffsetY = 0.0f; // 配置项：视图 Y 轴偏移 static bool g_bEnableMatrixHook = false; // 配置项：矩阵 Hook 总开关 HRESULT WINAPI HookSetTransform( LPDIRECT3DDEVICE9 pDevice, D3DTRANSFORMSTATETYPE State, const D3DMATRIX* pMatrix) { if (g_bEnableMatrixHook && State == D3DTS_VIEW && g_fViewOffsetY != 0.0f) { D3DXMATRIX matOffset; D3DXMatrixTranslation(&matOffset, 0.0f, g_fViewOffsetY, 0.0f); D3DXMATRIX matNew; D3DXMatrixMultiply(&matNew, &matOffset, (D3DXMATRIX*)pMatrix); return g_oldSetTransform(pDevice, State, &matNew); } return g_oldSetTransform(pDevice, State, pMatrix); }现在我把“能不能跑”和“好不好调”当成两件事来验收：先验证日志链完整，再验证开关能还原画面，最后才调数值。从那以后我每次写 Hook 类工程都强制走一遍这个流程——先查 DllMain 有没有耗时代码，再查函数指针保存路径，最后查开关是否独立。这套习惯让我少熬了很多个深夜排查问题，希望这篇拆解笔记也能帮到你。
本文还有配套的精品资源，点击获取
