简介一份配合《Beginning DirectX 9》入门教程的随书源码包面向DirectX9及3D图形编程初学者通过可编译运行的示例展示Direct3D渲染、DirectInput输入、DirectSound音频等核心组件的实际用法。包内共210个文件以cpp、h源码和vcproj、sln工程文件为主辅以bmp贴图、wav音频、rc资源与x模型文件整体仅1.16MB结构紧凑便于按章节对照学习。源码覆盖窗口与设备初始化、几何图形绘制、固定/可编程图形管线、纹理映射、光照阴影、深度缓冲与视口变换、动画帧率控制、输入响应和背景音乐播放等主题能够帮助读者把书中的概念落实到具体代码理解从创建窗口到渲染一帧画面的完整流程。已有127人学习/下载适合正在阅读入门教程、希望借助实际工程提升DirectX9实践能力的开发者。1. 十多年后翻出《Beginning DirectX 9》随书源码它还有没有价值DirectX 9 是图形编程里几乎不可能绕开的中间站而这套 Begining DirectX9 随书源码恰好落在这个时代的正中间。它不是把若干接口调用堆在一起而是把窗口创建、设备初始化、顶点缓冲、纹理、光照和第一批 HLSL 着色器串成几十个能直接运行的小工程。翻它的人未必是在怀旧更多是想弄明白“渲染管线到底从哪一步开始”。想从零学图形学、想逆向老游戏、想把旧接口代码迁到现代图形栈的人都能拿它当垫脚石前提是先把编译环境踩通。这套源码最大的价值不是“能跑”而是它逼着你亲手完成一个窗口从无到有的全过程这个过程放在今天依旧稀缺。2. 打开随书源码先冷静三分钟盘目录、盯依赖、分清运行时与SDK2.1 先按章节编号找工程别被密密麻麻的 cpp 文件带跑我拿到这种随书源码包第一件事从来不是找 README而是先展开目录数序号。源码通常按书的原始章节切成目录第一屏一定是环境初始化顶点与几何体在中间纹理光照靠后着色器示例往往放在末尾。这个顺序本身比注释更说明问题先让窗口出现再谈怎么把三角形画上去最后才讲像素如何被着色器接管。练手时也应该照这个顺序走而不是挑长得最花哨的例子下手。目录盘完接下来要面对的是依赖。DX9 时代源码的依赖比现代图形栈简单得多但简单不代表不出事D3DX 这个辅助库就是最容易翻车的地方。很多示例开头只有三行 include藏着的信息量却非常大一行对应一个要备齐的库。2.2 依赖表d3d9、d3dx9、dxguid 各负责什么源码里 cpp 文件开头那几行#include基本就决定了这个示例需要在编译期备齐哪些东西。常见的是下面这几组头文件 / 库作用运行期编译期准备d3d9.h / d3d9.libDirect3D 9 核心接口设备创建、渲染状态、顶点缓存系统自带 d3d9.dll一般可直接用d3dx9.h / d3dx9.libD3DX 辅助纹理加载、数学矩阵、效果文件解析不一定随系统提供需要早年 DirectX SDK 或手工准备的库dxguid.lib设备枚举时用到的 GUID 定义运行期不需要一般可用系统 SDK 提供windows.h / user32.lib窗口创建、消息循环系统自带自动链接这张表背后有个经验源码里的链接错误八成不是 d3d9 本身的问题而是 d3dx9 那一行。后来的系统 SDK 早把 D3DX 从开发者包里摘出去了头文件和 lib 都不再默认提供。所以编译一个用了D3DXCreateTextureFromFile的示例就会看到报错说找不到 d3dx9.h或者到链接阶段告诉你_D3DXCreateTextureFromFileA20无法解析。我一般会直接把这一行当作“需要单独准备 d3dx9 库”的信号而不是傻傻去改 include 路径。2.3 运行时和 SDK 是两个世界源码跑不起来九成是编译期的事“运行时Runtime”和“SDK”这两件事经常被混着说。运行时是 exe 启动时加载的 dllSDK 是编译时需要的头文件和 lib 文件。Win10、Win11 上基本都还带着 Direct3D 9 运行时所以随手拿一个当年编译好的 demo exe 双击窗口往往还能弹出来功能也都正常。到了自己动手编译时就发现d3d9.h、d3dx9.h 不在默认搜索路径里或者 lib 缺失。记住这一条能运行不代表能编译编译过不去不是系统坏了而是编译器搜索路径上缺材料。提示排查“源码编译失败”时先把“运行 demo 需要什么”和“编译工程需要什么”分成两张清单能少走很多弯路。检查运行时的健康程度我会用系统自带的诊断工具看一眼显卡驱动里关于 D3D9 的项确认不是硬件加速被禁用。那里面会把 DirectX 版本、驱动日期、AGP 纹理加速状态都列出来。这也顺带解释了“代码没问题画面却异常”里的一种常见情况虚拟机里跑 D3D9 经常只有软件渲染性能表现会差到让你误以为写错了代码。3. 用最小命令把第一个示例跑出画面从空白窗口到三角形3.1 建好目录、摆好头文件与库文件再把选中示例整理成一个小工程我的做法不是一次性编译整个源码包而是先清理出一个小目录只放当前要用的文件。这样错误边界很小出了问题能立刻定位是源码问题还是环境问题。mkdir dx9-samples cd dx9-samples mkdir include lib src # 把老 SDK 里的 d3d9.h、d3dx9.h 拷到 include/ 下 # 把 d3d9.lib、d3dx9.lib、dxguid.lib 拷到 lib/ 下 # 最后从随书源码里挑一个最基础的窗口示例放入 src/ 下这段命令有三个关键动作。第一是头文件与 lib 分开摆放编译器找 include链接器找 lib两者搜索路径不同混在一起会带来“头文件可见但链接失败”的诡异局面。第二是只挑一个示例进 src随书源码里的工程之间偶尔会共享公共文件全丢进来会让编译器把多个 main 函数撞在一起。第三是保留原始源码目录不动方便回头对照。3.2 一个教科书级的 D3D9 初始化片段照着随书源码精简下面的代码几乎能在每个早期示例里找到影子我把它收拢成一个最小版本。它做的事只有三件创建 D3D9 对象、填参数、创建设备。#include d3d9.h #include windows.h IDirect3DDevice9 *g_dev nullptr; // 初始化 Direct3D9创建对象、填参数、创建设备 bool init_d3d(HWND wnd, int width, int height) { // 入口固定是 Direct3DCreate9参数必须传 D3D_SDK_VERSION IDirect3D9 *d3d Direct3DCreate9(D3D_SDK_VERSION); if (!d3d) return false; D3DPRESENT_PARAMETERS pp; memset(pp, 0, sizeof(pp)); pp.BackBufferWidth width; pp.BackBufferHeight height; pp.BackBufferFormat D3DFMT_A8R8G8B8; pp.MultiSampleType D3DMULTISAMPLE_NONE; pp.SwapEffect D3DSWAPEFFECT_DISCARD; pp.hDeviceWindow wnd; pp.Windowed TRUE; // 默认适配器、硬件光栅化出错时先检查 D3DDEVTYPE HRESULT hr d3d-CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, wnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, pp, g_dev); d3d-Release(); // 设备创建完成D3D 对象就可以释放了 return SUCCEEDED(hr); }参数说明里最容易踩的是两个地方。第一BackBufferFormat用D3DFMT_A8R8G8B8是最保守的选择随书源码里偶尔写D3DFMT_UNKNOWN表示跟随窗口表面在部分驱动上会得到预期之外的格式。第二D3DDEVTYPE_HAL是硬件光栅化如果图省事改成D3DDEVTYPE_REF程序会像幻灯片一样慢因为那是软件模拟器在逐像素模拟。顶点处理方式我习惯先用D3DCREATE_SOFTWARE_VERTEXPROCESSING等读到后面着色器章节再换硬件处理这样固定管线阶段不容易被显卡驱动的差异干扰。3.3 编译命令与链接库链接顺序也有它的规矩把代码存成 main.cpp 之后用命令行编译比新建 IDE 工程更省事因为它第一分钟就会暴露缺了哪些库。g src/main.cpp -o demo.exe \ -Iinclude -Llib \ -ld3d9 -ldxguid-Iinclude指向我们摆好头文件的目录-Llib指向 lib 目录这两个路径只对本次编译生效不会污染系统全局。-ld3d9对应 d3d9.lib-ldxguid对应 dxguid.lib。链接参数不是随便排的依赖方要放在被依赖方前面这行命令里两个库互相引用实际顺序已经是最稳定的一种。如果示例里出现D3DXCreateTextureFromFile要加-ld3dx9并且确保 d3dx9.h 已经包含进来。链接阶段还有一个容易忽视的细节编译参数需要区分 Debug 和 Release。随书源码里的很多示例是在 Debug 下写的会调一堆断言和调试辅助接口如果你用 Release 编译一些宏定义行为会变化最典型的是D3D_DEBUG_INFO没有被定义某些设备能力查询返回的结构体大小不一致表现成“编译能过、运行崩溃”。3.4 窗口循环里的 Present画面没动静先看这里初始化成功不代表画面会出现DX9 里渲染结果显示到屏幕的最后一环是Present。你会在每个示例的渲染循环尾部看到它// 清屏为深蓝色然后提交后台缓冲区到前台 g_dev-Clear(0, nullptr, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0, 0, 64), 1.0f, 0); g_dev-BeginScene(); // 这里才是画三角形、画网格的代码 g_dev-EndScene(); g_dev-Present(nullptr, nullptr, nullptr, nullptr);BeginScene与EndScene必须成对出现所有绘制调用都夹在两者之间。Present的三个参数里前两个是源和目标区域传nullptr表示整张后台缓冲都上屏。随书源码里有一部分示例在窗口失焦时会停止渲染这是消息循环里对WM_ACTIVATE的常见处理如果你改掉了窗口焦点逻辑画面就会在切换窗口后永久卡死。4. 随书源码编译运行高频坑五个翻车现场与排查思路4.1 找不到 d3d9.h先查编译器搜索路径再看是不是混用了 SDK现象编译刚开始就报fatal error: d3d9.h: No such file or directory。原因d3d9.h 不在编译器默认搜索路径里多见于后来安装的系统 SDK 不包含旧头文件或者你把 64 位和 32 位头文件目录搞混了。很多源码工程默认按 32 位编译而部分新版 IDE 默认生成 64 位目标两套库路径完全不同。解决我一般用命令行先验证头文件位置确认d3d9.h确实在 include 目录里后再在编译命令里显式指定-Iinclude。不要同时把多个 SDK 目录塞进全局搜索路径那会导致头文件版本互相打架出现“两个 d3d9.h 都找到了”的警告进而引发更隐蔽的类型不匹配。4.2 链接时报 unresolved external symbold3d9.lib 和 dxguid.lib 缺一不可现象源文件编译通过链接阶段报unresolved external symbol Direct3DCreate9。原因头文件让你骗过了编译器但链接器没找到对应实现。常见于只加了头文件搜索路径没加 lib 搜索路径或者 lib 文件名拼写错误。d3d9.lib 是动态库的导入库它本身不包含实现而是告诉你运行时去 d3d9.dll 里找函数地址。丢掉它Direct3DCreate9 就悬空了。解决在链接参数里补上-ld3d9 -ldxguid。确认 dxguid.lib 也不能省设备枚举、格式查询这类代码会引用大量 GUID 常量它们住在 dxguid 里。排查时我用一个最笨但有效的办法逐个删掉链接参数看到底哪个调用对应哪个库能顺手把源码的依赖关系摸清楚。4.3 运行时窗口全黑、白屏或花屏先查 BackBuffer 格式和窗口尺寸现象程序能启动窗口也在但里面什么都没有或者整块颜色不对偶尔伴随屏幕闪烁。原因像素格式不匹配是最大嫌疑。窗口客户区尺寸和 BackBuffer 尺寸不一致时交换链拉伸会出现黑边或错位D3DFMT_UNKNOWN在部分显卡上解析出的格式不是你要的 32 位颜色Clear 的颜色也会显示异常。解决把BackBufferWidth和BackBufferHeight显式设为窗口客户区大小格式固定成D3DFMT_A8R8G8B8。还有一个我踩过的细节创建窗口时如果用了CreateWindow的默认尺寸而没调AdjustWindowRect客户区已经比你预想的小了一圈渲染出来的场景会被裁掉一块。源码里这类窗口尺寸计算代码通常被一堆宏包着调试时直接把尺寸写死成 640x480 最省心。4.4 高 DPI 下窗口被拉伸或 UI 错位补上感知设置现象窗口字体发虚、画面模糊鼠标坐标和渲染内容对不上像是整块画面被放大过。原因系统按默认 DPI 缩放窗口而渲染输出尺寸还是逻辑像素值两者比例不同导致画面被强行拉伸。随书源码年代距今太远没有高 DPI 感知的概念这个问题几乎无解。解决在程序入口最前面调SetProcessDPIAware()让系统不再自动缩放更彻底的做法是在工程里放一份 manifest 文件声明dpiAwaretrue。调完这一处后窗口在 150% 缩放下也会保持像素级清晰。这个坑通常不会误以为坏了但会严重干扰后续几何体绘制时对坐标的判断。4.5 用了 D3DX 的示例全部编译失败归根结底还是 d3dx9.lib 缺失现象前面几个纯 d3d9 示例都通过了一到纹理加载、字体绘制、效果文件相关的示例就报错错误集中在D3DX*函数上。原因D3DX 是独立于核心 D3D9 的辅助库源码里常见的D3DXCreateTextureFromFile、D3DXCreateFont、D3DXCompileShader全在这个库里。后来的开发者 SDK 不再打包 D3DX需要自己准备早年 DirectX SDK 留下的头文件、lib 和 dll。我把这件事列为“编译期准备”而不是“系统问题”。解决我一般从旧 SDK 的安装目录里把 d3dx9.h、d3dx9.lib 和对应 dll 一并收集到工程目录保持本地化。运行时如果目标机器没有 d3dx9.dll可以把 dll 放到 exe 同目录比装全局服务更干净。这套源码是初学者拿来练手的强烈建议所有 D3DX 依赖都做成文件夹内局部引用不给系统留垃圾。5. 读源码比跑源码更值钱固定管线到可编程管线的对照5.1 SetRenderState 与光照这是固定管线的主线DX9 初期的示例里你几乎见不到真正意义上的着色器而是用SetRenderState控制一个黑匣子般的状态机。光照、雾化、剔除、混合全是一行状态设置代码结构异常直白// 开启光照与雾化颜色混合交给固定管线内部处理 g_dev-SetRenderState(D3DRS_LIGHTING, TRUE); g_dev-SetRenderState(D3DRS_AMBIENT, D3DCOLOR_XRGB(40, 40, 40)); g_dev-SetRenderState(D3DRS_FOGENABLE, TRUE);这套写法的优点是入门阻力小你不必理解着色器编译过程只要看状态开关就能猜出效果。缺点是可编程性弱所有效果都被限定在预设的光照模型里。读这部分源码时我建议你把每个SetRenderState的枚举名抄下来再去查它对应的状态组比如光照、光栅化、混合分别属于不同阶段。做一次这样的整理后面看 D3D11 的状态对象就顺理成章。5.2 随书源码里第一段 HLSL 效果文件可编程管线的起点到了书中后半段示例里开始出现 .fx 或直接内嵌的 HLSL 代码。这是整套源码价值最高的地方因为固定管线与可编程管线的分界就在这里。一个最简单的效果文件长这样// 最简单的像素着色器不管顶点如何都返回红色 float4 ps_main() : COLOR0 { return float4(1.0, 0.0, 0.0, 1.0); }编译并应用这个着色器的动作把渲染从“设置状态”推向了“编写代码”。你会看到随书源码里开始出现CreateVertexShader、SetPixelShader这类调用顶点声明的结构体里也多了纹理坐标。我读这段时得到一个非常重要的认识固定管线的SetRenderState只是一个配置过程而着色器才真正定义了“每个顶点/像素如何被计算”前者是选择后者是编程。这个区别想通之后再去看 DX9 后期示例里复杂的多遍渲染就不会被吓退。5.3 从 D3D9 想明白 D3D11一张对照表讲清状态与资源的差异很多人学完 DX9 直接跳 D3D11感觉像是换了套图形栈。其实两者在同一画面上是一致的差别主要是显式化了D3D9 习惯D3D11 对应物变化点SetRenderState 全局状态ID3D11State 对象光栅化、深度、混合状态改为创建后绑定不再是全局黑匣子顶点缓冲 FVF 声明ID3D11Buffer ID3D11InputLayout输入布局需要在绘制前明确指定隐式管线着色器显式编译并绑定Shader Model 进入可编程主线D3DX 辅助函数DirectXTex 等替代库第三方工具链取代官方辅助库立即模式立即上下文 延迟上下文多线程渲染成为正式能力这张表不是让你把 DX9 忘掉而是帮你在读随书源码时建立“同一概念在不同接口里的不同位置”的映射。比如 D3D9 的SetRenderState(D3DRS_CULLMODE, …)到 D3D11 就是先创建一个D3D11_RASTERIZER_DESC再调用CreateRasterizerState最后在绘制前用RSSetState绑定。概念没变变的只是对象化。这也能解释为什么许多老工程师能快速迁移到现代图形学真正值钱的是脑子里那张状态流转图而不是某个具体接口的签名。6. 把源码改造成个人调试环境一个最小 D3D9 验证窗口的惯用手法6.1 维护一个只做两件事的迷你工程初始化与 Present我后来把随书源码的初始化部分抽成一个固定脚本任何新环境都先编译它验证通过再开始折腾新功能。它只负责创建窗口、创建设备、清屏、Present没有纹理、没有顶点、没有输入处理。这个迷你可执行文件是判断环境是否正常的金标准它能跑说明 d3d9 运行时、头文件、lib 匹配都没问题它不能跑问题在你机器不在业务代码。我会把编译命令存成一个简单的批处理脚本换机器后只改路径不碰代码。我自己也有一个执念这套老源码里的D3DADAPTER_DEFAULT在双显卡笔记本上偶尔不按预期工作集成显卡与独立显卡的切换会把设备枚举结果搞乱。所以我的最小工程里会保留一段GetAdapterCount的循环把每个适配器的名称和显存打出来肉眼确认到底用的是哪块卡避免“代码没变换台电脑就翻车”的尴尬。6.2 用一个帧率输出确认环境健康我在最小工程里加一个简单的帧率统计每秒把 FPS 打到窗口标题栏上。DX9 程序如果跑在硬件加速下哪怕只是清屏轻松也有几百 FPS如果跌到个位数多半是掉进了软件渲染。这个方法比任何调试器都直观因为 Direct3D 9 不会主动告诉你它正在用 REF 设备运行。养成这个习惯之后每次拿到新显卡、新系统我都先跑一次这个窗口再决定要不要去调示例代码。血的教训来自一次迁移演示就绪。某次在虚拟机里给学生演示随书源码的三角形示例画面卡到无法忍受我当时以为是显卡驱动问题折腾半天才发现虚拟机默认只提供软件 D3D9 支持D3DDEVTYPE_HAL根本没有硬件设备程序自动回退到软件模拟。后来我把“验证 HAL 设备是否存在”写进了最小工程里失败就明确弹一行文字而不是继续硬跑。这套源码教会我的不是某个接口怎么调而是先确认环境再谈效果。希望帮到你。最小验证工程的检查顺序 1. 系统工具里确认 D3D9 加速处于启用状态。 2. 编译最小工程并运行查看 FPS 是否远高于 60。 3. 枚举适配器名称确认使用的是目标显卡。 4. 再打开随书源码示例维持同样的窗口尺寸与格式。本文还有配套的精品资源点击获取 
长河君 · 2026/10/14 15:46:52 · 阅读 1.2k DirectX 9随书源码实战：编译环境、常见坑与管线演进
简介一份配合《Beginning DirectX 9》入门教程的随书源码包面向DirectX9及3D图形编程初学者通过可编译运行的示例展示Direct3D渲染、DirectInput输入、DirectSound音频等核心组件的实际用法。包内共210个文件以cpp、h源码和vcproj、sln工程文件为主辅以bmp贴图、wav音频、rc资源与x模型文件整体仅1.16MB结构紧凑便于按章节对照学习。源码覆盖窗口与设备初始化、几何图形绘制、固定/可编程图形管线、纹理映射、光照阴影、深度缓冲与视口变换、动画帧率控制、输入响应和背景音乐播放等主题能够帮助读者把书中的概念落实到具体代码理解从创建窗口到渲染一帧画面的完整流程。已有127人学习/下载适合正在阅读入门教程、希望借助实际工程提升DirectX9实践能力的开发者。1. 十多年后翻出《Beginning DirectX 9》随书源码它还有没有价值DirectX 9 是图形编程里几乎不可能绕开的中间站而这套 Begining DirectX9 随书源码恰好落在这个时代的正中间。它不是把若干接口调用堆在一起而是把窗口创建、设备初始化、顶点缓冲、纹理、光照和第一批 HLSL 着色器串成几十个能直接运行的小工程。翻它的人未必是在怀旧更多是想弄明白“渲染管线到底从哪一步开始”。想从零学图形学、想逆向老游戏、想把旧接口代码迁到现代图形栈的人都能拿它当垫脚石前提是先把编译环境踩通。这套源码最大的价值不是“能跑”而是它逼着你亲手完成一个窗口从无到有的全过程这个过程放在今天依旧稀缺。2. 打开随书源码先冷静三分钟盘目录、盯依赖、分清运行时与SDK2.1 先按章节编号找工程别被密密麻麻的 cpp 文件带跑我拿到这种随书源码包第一件事从来不是找 README而是先展开目录数序号。源码通常按书的原始章节切成目录第一屏一定是环境初始化顶点与几何体在中间纹理光照靠后着色器示例往往放在末尾。这个顺序本身比注释更说明问题先让窗口出现再谈怎么把三角形画上去最后才讲像素如何被着色器接管。练手时也应该照这个顺序走而不是挑长得最花哨的例子下手。目录盘完接下来要面对的是依赖。DX9 时代源码的依赖比现代图形栈简单得多但简单不代表不出事D3DX 这个辅助库就是最容易翻车的地方。很多示例开头只有三行 include藏着的信息量却非常大一行对应一个要备齐的库。2.2 依赖表d3d9、d3dx9、dxguid 各负责什么源码里 cpp 文件开头那几行#include基本就决定了这个示例需要在编译期备齐哪些东西。常见的是下面这几组头文件 / 库作用运行期编译期准备d3d9.h / d3d9.libDirect3D 9 核心接口设备创建、渲染状态、顶点缓存系统自带 d3d9.dll一般可直接用d3dx9.h / d3dx9.libD3DX 辅助纹理加载、数学矩阵、效果文件解析不一定随系统提供需要早年 DirectX SDK 或手工准备的库dxguid.lib设备枚举时用到的 GUID 定义运行期不需要一般可用系统 SDK 提供windows.h / user32.lib窗口创建、消息循环系统自带自动链接这张表背后有个经验源码里的链接错误八成不是 d3d9 本身的问题而是 d3dx9 那一行。后来的系统 SDK 早把 D3DX 从开发者包里摘出去了头文件和 lib 都不再默认提供。所以编译一个用了D3DXCreateTextureFromFile的示例就会看到报错说找不到 d3dx9.h或者到链接阶段告诉你_D3DXCreateTextureFromFileA20无法解析。我一般会直接把这一行当作“需要单独准备 d3dx9 库”的信号而不是傻傻去改 include 路径。2.3 运行时和 SDK 是两个世界源码跑不起来九成是编译期的事“运行时Runtime”和“SDK”这两件事经常被混着说。运行时是 exe 启动时加载的 dllSDK 是编译时需要的头文件和 lib 文件。Win10、Win11 上基本都还带着 Direct3D 9 运行时所以随手拿一个当年编译好的 demo exe 双击窗口往往还能弹出来功能也都正常。到了自己动手编译时就发现d3d9.h、d3dx9.h 不在默认搜索路径里或者 lib 缺失。记住这一条能运行不代表能编译编译过不去不是系统坏了而是编译器搜索路径上缺材料。提示排查“源码编译失败”时先把“运行 demo 需要什么”和“编译工程需要什么”分成两张清单能少走很多弯路。检查运行时的健康程度我会用系统自带的诊断工具看一眼显卡驱动里关于 D3D9 的项确认不是硬件加速被禁用。那里面会把 DirectX 版本、驱动日期、AGP 纹理加速状态都列出来。这也顺带解释了“代码没问题画面却异常”里的一种常见情况虚拟机里跑 D3D9 经常只有软件渲染性能表现会差到让你误以为写错了代码。3. 用最小命令把第一个示例跑出画面从空白窗口到三角形3.1 建好目录、摆好头文件与库文件再把选中示例整理成一个小工程我的做法不是一次性编译整个源码包而是先清理出一个小目录只放当前要用的文件。这样错误边界很小出了问题能立刻定位是源码问题还是环境问题。mkdir dx9-samples cd dx9-samples mkdir include lib src # 把老 SDK 里的 d3d9.h、d3dx9.h 拷到 include/ 下 # 把 d3d9.lib、d3dx9.lib、dxguid.lib 拷到 lib/ 下 # 最后从随书源码里挑一个最基础的窗口示例放入 src/ 下这段命令有三个关键动作。第一是头文件与 lib 分开摆放编译器找 include链接器找 lib两者搜索路径不同混在一起会带来“头文件可见但链接失败”的诡异局面。第二是只挑一个示例进 src随书源码里的工程之间偶尔会共享公共文件全丢进来会让编译器把多个 main 函数撞在一起。第三是保留原始源码目录不动方便回头对照。3.2 一个教科书级的 D3D9 初始化片段照着随书源码精简下面的代码几乎能在每个早期示例里找到影子我把它收拢成一个最小版本。它做的事只有三件创建 D3D9 对象、填参数、创建设备。#include d3d9.h #include windows.h IDirect3DDevice9 *g_dev nullptr; // 初始化 Direct3D9创建对象、填参数、创建设备 bool init_d3d(HWND wnd, int width, int height) { // 入口固定是 Direct3DCreate9参数必须传 D3D_SDK_VERSION IDirect3D9 *d3d Direct3DCreate9(D3D_SDK_VERSION); if (!d3d) return false; D3DPRESENT_PARAMETERS pp; memset(pp, 0, sizeof(pp)); pp.BackBufferWidth width; pp.BackBufferHeight height; pp.BackBufferFormat D3DFMT_A8R8G8B8; pp.MultiSampleType D3DMULTISAMPLE_NONE; pp.SwapEffect D3DSWAPEFFECT_DISCARD; pp.hDeviceWindow wnd; pp.Windowed TRUE; // 默认适配器、硬件光栅化出错时先检查 D3DDEVTYPE HRESULT hr d3d-CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, wnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, pp, g_dev); d3d-Release(); // 设备创建完成D3D 对象就可以释放了 return SUCCEEDED(hr); }参数说明里最容易踩的是两个地方。第一BackBufferFormat用D3DFMT_A8R8G8B8是最保守的选择随书源码里偶尔写D3DFMT_UNKNOWN表示跟随窗口表面在部分驱动上会得到预期之外的格式。第二D3DDEVTYPE_HAL是硬件光栅化如果图省事改成D3DDEVTYPE_REF程序会像幻灯片一样慢因为那是软件模拟器在逐像素模拟。顶点处理方式我习惯先用D3DCREATE_SOFTWARE_VERTEXPROCESSING等读到后面着色器章节再换硬件处理这样固定管线阶段不容易被显卡驱动的差异干扰。3.3 编译命令与链接库链接顺序也有它的规矩把代码存成 main.cpp 之后用命令行编译比新建 IDE 工程更省事因为它第一分钟就会暴露缺了哪些库。g src/main.cpp -o demo.exe \ -Iinclude -Llib \ -ld3d9 -ldxguid-Iinclude指向我们摆好头文件的目录-Llib指向 lib 目录这两个路径只对本次编译生效不会污染系统全局。-ld3d9对应 d3d9.lib-ldxguid对应 dxguid.lib。链接参数不是随便排的依赖方要放在被依赖方前面这行命令里两个库互相引用实际顺序已经是最稳定的一种。如果示例里出现D3DXCreateTextureFromFile要加-ld3dx9并且确保 d3dx9.h 已经包含进来。链接阶段还有一个容易忽视的细节编译参数需要区分 Debug 和 Release。随书源码里的很多示例是在 Debug 下写的会调一堆断言和调试辅助接口如果你用 Release 编译一些宏定义行为会变化最典型的是D3D_DEBUG_INFO没有被定义某些设备能力查询返回的结构体大小不一致表现成“编译能过、运行崩溃”。3.4 窗口循环里的 Present画面没动静先看这里初始化成功不代表画面会出现DX9 里渲染结果显示到屏幕的最后一环是Present。你会在每个示例的渲染循环尾部看到它// 清屏为深蓝色然后提交后台缓冲区到前台 g_dev-Clear(0, nullptr, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0, 0, 64), 1.0f, 0); g_dev-BeginScene(); // 这里才是画三角形、画网格的代码 g_dev-EndScene(); g_dev-Present(nullptr, nullptr, nullptr, nullptr);BeginScene与EndScene必须成对出现所有绘制调用都夹在两者之间。Present的三个参数里前两个是源和目标区域传nullptr表示整张后台缓冲都上屏。随书源码里有一部分示例在窗口失焦时会停止渲染这是消息循环里对WM_ACTIVATE的常见处理如果你改掉了窗口焦点逻辑画面就会在切换窗口后永久卡死。4. 随书源码编译运行高频坑五个翻车现场与排查思路4.1 找不到 d3d9.h先查编译器搜索路径再看是不是混用了 SDK现象编译刚开始就报fatal error: d3d9.h: No such file or directory。原因d3d9.h 不在编译器默认搜索路径里多见于后来安装的系统 SDK 不包含旧头文件或者你把 64 位和 32 位头文件目录搞混了。很多源码工程默认按 32 位编译而部分新版 IDE 默认生成 64 位目标两套库路径完全不同。解决我一般用命令行先验证头文件位置确认d3d9.h确实在 include 目录里后再在编译命令里显式指定-Iinclude。不要同时把多个 SDK 目录塞进全局搜索路径那会导致头文件版本互相打架出现“两个 d3d9.h 都找到了”的警告进而引发更隐蔽的类型不匹配。4.2 链接时报 unresolved external symbold3d9.lib 和 dxguid.lib 缺一不可现象源文件编译通过链接阶段报unresolved external symbol Direct3DCreate9。原因头文件让你骗过了编译器但链接器没找到对应实现。常见于只加了头文件搜索路径没加 lib 搜索路径或者 lib 文件名拼写错误。d3d9.lib 是动态库的导入库它本身不包含实现而是告诉你运行时去 d3d9.dll 里找函数地址。丢掉它Direct3DCreate9 就悬空了。解决在链接参数里补上-ld3d9 -ldxguid。确认 dxguid.lib 也不能省设备枚举、格式查询这类代码会引用大量 GUID 常量它们住在 dxguid 里。排查时我用一个最笨但有效的办法逐个删掉链接参数看到底哪个调用对应哪个库能顺手把源码的依赖关系摸清楚。4.3 运行时窗口全黑、白屏或花屏先查 BackBuffer 格式和窗口尺寸现象程序能启动窗口也在但里面什么都没有或者整块颜色不对偶尔伴随屏幕闪烁。原因像素格式不匹配是最大嫌疑。窗口客户区尺寸和 BackBuffer 尺寸不一致时交换链拉伸会出现黑边或错位D3DFMT_UNKNOWN在部分显卡上解析出的格式不是你要的 32 位颜色Clear 的颜色也会显示异常。解决把BackBufferWidth和BackBufferHeight显式设为窗口客户区大小格式固定成D3DFMT_A8R8G8B8。还有一个我踩过的细节创建窗口时如果用了CreateWindow的默认尺寸而没调AdjustWindowRect客户区已经比你预想的小了一圈渲染出来的场景会被裁掉一块。源码里这类窗口尺寸计算代码通常被一堆宏包着调试时直接把尺寸写死成 640x480 最省心。4.4 高 DPI 下窗口被拉伸或 UI 错位补上感知设置现象窗口字体发虚、画面模糊鼠标坐标和渲染内容对不上像是整块画面被放大过。原因系统按默认 DPI 缩放窗口而渲染输出尺寸还是逻辑像素值两者比例不同导致画面被强行拉伸。随书源码年代距今太远没有高 DPI 感知的概念这个问题几乎无解。解决在程序入口最前面调SetProcessDPIAware()让系统不再自动缩放更彻底的做法是在工程里放一份 manifest 文件声明dpiAwaretrue。调完这一处后窗口在 150% 缩放下也会保持像素级清晰。这个坑通常不会误以为坏了但会严重干扰后续几何体绘制时对坐标的判断。4.5 用了 D3DX 的示例全部编译失败归根结底还是 d3dx9.lib 缺失现象前面几个纯 d3d9 示例都通过了一到纹理加载、字体绘制、效果文件相关的示例就报错错误集中在D3DX*函数上。原因D3DX 是独立于核心 D3D9 的辅助库源码里常见的D3DXCreateTextureFromFile、D3DXCreateFont、D3DXCompileShader全在这个库里。后来的开发者 SDK 不再打包 D3DX需要自己准备早年 DirectX SDK 留下的头文件、lib 和 dll。我把这件事列为“编译期准备”而不是“系统问题”。解决我一般从旧 SDK 的安装目录里把 d3dx9.h、d3dx9.lib 和对应 dll 一并收集到工程目录保持本地化。运行时如果目标机器没有 d3dx9.dll可以把 dll 放到 exe 同目录比装全局服务更干净。这套源码是初学者拿来练手的强烈建议所有 D3DX 依赖都做成文件夹内局部引用不给系统留垃圾。5. 读源码比跑源码更值钱固定管线到可编程管线的对照5.1 SetRenderState 与光照这是固定管线的主线DX9 初期的示例里你几乎见不到真正意义上的着色器而是用SetRenderState控制一个黑匣子般的状态机。光照、雾化、剔除、混合全是一行状态设置代码结构异常直白// 开启光照与雾化颜色混合交给固定管线内部处理 g_dev-SetRenderState(D3DRS_LIGHTING, TRUE); g_dev-SetRenderState(D3DRS_AMBIENT, D3DCOLOR_XRGB(40, 40, 40)); g_dev-SetRenderState(D3DRS_FOGENABLE, TRUE);这套写法的优点是入门阻力小你不必理解着色器编译过程只要看状态开关就能猜出效果。缺点是可编程性弱所有效果都被限定在预设的光照模型里。读这部分源码时我建议你把每个SetRenderState的枚举名抄下来再去查它对应的状态组比如光照、光栅化、混合分别属于不同阶段。做一次这样的整理后面看 D3D11 的状态对象就顺理成章。5.2 随书源码里第一段 HLSL 效果文件可编程管线的起点到了书中后半段示例里开始出现 .fx 或直接内嵌的 HLSL 代码。这是整套源码价值最高的地方因为固定管线与可编程管线的分界就在这里。一个最简单的效果文件长这样// 最简单的像素着色器不管顶点如何都返回红色 float4 ps_main() : COLOR0 { return float4(1.0, 0.0, 0.0, 1.0); }编译并应用这个着色器的动作把渲染从“设置状态”推向了“编写代码”。你会看到随书源码里开始出现CreateVertexShader、SetPixelShader这类调用顶点声明的结构体里也多了纹理坐标。我读这段时得到一个非常重要的认识固定管线的SetRenderState只是一个配置过程而着色器才真正定义了“每个顶点/像素如何被计算”前者是选择后者是编程。这个区别想通之后再去看 DX9 后期示例里复杂的多遍渲染就不会被吓退。5.3 从 D3D9 想明白 D3D11一张对照表讲清状态与资源的差异很多人学完 DX9 直接跳 D3D11感觉像是换了套图形栈。其实两者在同一画面上是一致的差别主要是显式化了D3D9 习惯D3D11 对应物变化点SetRenderState 全局状态ID3D11State 对象光栅化、深度、混合状态改为创建后绑定不再是全局黑匣子顶点缓冲 FVF 声明ID3D11Buffer ID3D11InputLayout输入布局需要在绘制前明确指定隐式管线着色器显式编译并绑定Shader Model 进入可编程主线D3DX 辅助函数DirectXTex 等替代库第三方工具链取代官方辅助库立即模式立即上下文 延迟上下文多线程渲染成为正式能力这张表不是让你把 DX9 忘掉而是帮你在读随书源码时建立“同一概念在不同接口里的不同位置”的映射。比如 D3D9 的SetRenderState(D3DRS_CULLMODE, …)到 D3D11 就是先创建一个D3D11_RASTERIZER_DESC再调用CreateRasterizerState最后在绘制前用RSSetState绑定。概念没变变的只是对象化。这也能解释为什么许多老工程师能快速迁移到现代图形学真正值钱的是脑子里那张状态流转图而不是某个具体接口的签名。6. 把源码改造成个人调试环境一个最小 D3D9 验证窗口的惯用手法6.1 维护一个只做两件事的迷你工程初始化与 Present我后来把随书源码的初始化部分抽成一个固定脚本任何新环境都先编译它验证通过再开始折腾新功能。它只负责创建窗口、创建设备、清屏、Present没有纹理、没有顶点、没有输入处理。这个迷你可执行文件是判断环境是否正常的金标准它能跑说明 d3d9 运行时、头文件、lib 匹配都没问题它不能跑问题在你机器不在业务代码。我会把编译命令存成一个简单的批处理脚本换机器后只改路径不碰代码。我自己也有一个执念这套老源码里的D3DADAPTER_DEFAULT在双显卡笔记本上偶尔不按预期工作集成显卡与独立显卡的切换会把设备枚举结果搞乱。所以我的最小工程里会保留一段GetAdapterCount的循环把每个适配器的名称和显存打出来肉眼确认到底用的是哪块卡避免“代码没变换台电脑就翻车”的尴尬。6.2 用一个帧率输出确认环境健康我在最小工程里加一个简单的帧率统计每秒把 FPS 打到窗口标题栏上。DX9 程序如果跑在硬件加速下哪怕只是清屏轻松也有几百 FPS如果跌到个位数多半是掉进了软件渲染。这个方法比任何调试器都直观因为 Direct3D 9 不会主动告诉你它正在用 REF 设备运行。养成这个习惯之后每次拿到新显卡、新系统我都先跑一次这个窗口再决定要不要去调示例代码。血的教训来自一次迁移演示就绪。某次在虚拟机里给学生演示随书源码的三角形示例画面卡到无法忍受我当时以为是显卡驱动问题折腾半天才发现虚拟机默认只提供软件 D3D9 支持D3DDEVTYPE_HAL根本没有硬件设备程序自动回退到软件模拟。后来我把“验证 HAL 设备是否存在”写进了最小工程里失败就明确弹一行文字而不是继续硬跑。这套源码教会我的不是某个接口怎么调而是先确认环境再谈效果。希望帮到你。最小验证工程的检查顺序 1. 系统工具里确认 D3D9 加速处于启用状态。 2. 编译最小工程并运行查看 FPS 是否远高于 60。 3. 枚举适配器名称确认使用的是目标显卡。 4. 再打开随书源码示例维持同样的窗口尺寸与格式。本文还有配套的精品资源点击获取