简介这是《Begining DirectX9》一书的随书源码包面向 DirectX9 入门阶段的游戏与图形编程初学者目标是弥补单看教程示例代码零散、难以直接运行的痛点。源码按章节组织收录 210 个文件压缩包大小约 1.16MB其中 71 个 cpp 与 34 个 h 文件构成主要代码逻辑39 个 sln 解决方案和 39 个 vcproj 工程文件可直接打开编译运行其余 bmp、wav 等素材用于贴图与音效演示。示例从创建窗口、初始化 Direct3D 设备开始逐步覆盖基本几何体绘制、纹理映射、光照阴影、深度缓冲、视口变换、动画与帧率控制并串起 DirectInput 键鼠输入和 DirectSound 音频播放等基础功能。对照源码实际调试时读者可以清晰看到固定功能管线与可编程管线的差异理解每个渲染状态设置的作用从而把 DirectX9 的核心知识内化成可上手的项目经验。已有 127 人学习下载适合想边读边练、以代码验证概念的入门者。 如果你在某个深夜翻出压在硬盘深处的《Beginning DirectX 9》随书源码恭喜你大概率不是单纯怀旧而是想搞明白图形渲染的底层到底发生了什么。这本书诞生在2004年写的是DirectX9时代的入门经典随书源码几乎覆盖了一个小型渲染Demo能遇到的所有基础模块窗口、设备、资源、顶点、纹理、光照、Shader。对我这种当年照着书敲代码的人来说这套源码比正文更像老师。这篇内容我就把重新翻读、编译、改造这套源码的完整过程整理出来给想从零啃D3D9的人指条近路。1. 重看这套2004年的源码能挖到什么1.1 它刚好站在两条技术路线的分水岭DirectX9最特殊的地方是它同时支持固定功能管线Fixed Function Pipeline和可编程管线Programmable Pipeline。《Beginning DirectX 9》的随书源码正好卡在这个过渡期里面既有老式的材质、光照、纹理采样组合也有用HLSL写的顶点着色器和像素着色器示例。这种“新旧同台”的安排对学习者是件极其奢侈的事。我在读源码时最常用的方法是先用固定管线把整个渲染流程跑通再跑到对应的Shader示例里看同一个效果怎么用着色器实现。比如固定管线下设置一个方向光要调光照参数、设置材质、启用顶点格式里的法线而用Shader时只需在Effect里传入一个光线方向向量剩下全部在HLSL中手动控制。两个版本对照着看你才能真正理解图形渲染从“配置状态机”走向“编程GPU”的那次切换到底切换了什么。1.2 源码结构比教材目录更适合做导航图这本书的随书源码不是一团散乱的代码而是按章节拆分的独立工程。几乎每个项目都聚焦一个知识点今天教你创建窗口明天教你画三角形后天教你贴纹理。这种组织方式看似简单但它天然就是一张进阶地图。我自己会把所有示例分成三类来读。第一类是“环境类”包括Win32窗口创建、D3D设备初始化、渲染循环这是所有示例的地基第二类是“资源类”包括顶点缓冲、索引缓冲、纹理、外部模型载入它们解决的是“如何把数据交给GPU”第三类是“效果类”包括光照、材质、雾效、Shader它们决定画面最终长什么样。按这条线走一遍源码就等于把整个渲染框架在脑子里重建了一次。1.3 老代码里的工程习惯至今没有过时读这套源码时你会频繁看到一套固定写法每个COM接口用完要Release每个HRESULT返回值都要用FAILED或SUCCEEDED宏检查每个窗口消息都要交给默认处理函数。放在今天看这些习惯甚至比很多新项目还严谨。尤其值得学习的是它处理COM资源的方式。很多源码工程会定义一个SafeRelease宏在释放后把指针置空避免野指针二次释放。这种“不信任任何调用结果”的防御式编程后来我在D3D12和Vulkan的开发环境里依然在沿用。可以说这套代码虽然老但代代相传的资源管理思维没有任何过时。2. 让老源码在Windows 10/11上重新跑起来2.1 软件版本组合怎么选不要让源码里的VC6工程文件吓到你。Visual Studio 2019/2022都可以直接打开老工程并自动升级但我更推荐另一条路新建一个空项目把所有.cpp、.h、.fx文件手动加进去然后配置好DirectX SDK的include和lib路径。理由很简单老工程升级时往往带进来一堆与编译器版本强相关的预编译配置反而容易出诡异问题。DirectX SDK方面推荐使用DirectX SDK June 2010这是最后一个包含D3D9完整开发支持、D3DX工具库和Effect编译工具的版本。虽然微软早已把它从常规下载入口下架但各类开发者存档站点上仍然可以找到官方安装包安装后默认路径一般是C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)。需要注意区分SDK开发包和运行时运行库后面编译和运行都要用到。2.2 include与lib路径的顺序是第一个坑安装完DirectX SDK后头文件扫描顺序如果不设对会引发一堆莫名奇妙的编译错误。因为Windows 10/11自带的Windows SDK里也有d3d9.h、d3dx9.h等文件两个版本的历史兼容性并不完全一致老源码里的一些宏和函数可能在新头文件里已经变了。所以Visual Studio里需要这样设置在项目属性页找到“VC目录”把DirectX SDK\Include放在Windows SDK include目录之前库目录则根据要编译的平台优先选择DirectX SDK\Lib\x86或Lib\x64。然后在“链接器-输入-附加依赖项”里显式补上d3d9.lib、d3dx9.lib、winmm.lib。这一步做完大部分“找不到头文件”和“无法解析的外部符号”问题都能提前消掉。2.3 目标平台和字符集别再踩老代码的雷DirectX9时代的源码几乎默认按32位编译我强烈建议第一步就把解决方案平台设为x86不要盲目用x64。原因是老代码里混用了大量的DWORD、LONG、LPVOID指针和char*字符串在x64下指针长度变化会引发类型截断和结构体对齐问题排查成本极高。如果后续确实需要x64版也要先确认所有自定义结构体的对齐方式。字符集方面把“项目属性-常规-字符集”设成“使用多字节字符集”。因为老源码经常直接用字符串常量调用MessageBox、CreateWindow如果用Unicode字符集编译那些不经过TEXT()宏包裹的字符串会报类型不匹配错误。换成多字节字符集多数情况下可以直接通过编译。3. 跟着源码走一遍从空窗口到第一个三角形3.1 别跳过Win32窗口那部分不少人学DirectX时会觉得Win32窗口代码是纯粹的前置负担于是直接复制粘贴从不细看。但《Beginning DirectX 9》的随书源码把窗口创建放在第一个示例是有原因的所有D3D9设备都需要一个合法的窗口句柄HWND而窗口消息循环直接决定了你的渲染循环何时启动、何时暂停、何时退出。源码里的流程通常是这样WinMain注册窗口类、创建窗口、然后进入while(PeekMessage(...))循环。在这个循环里每拿到一条WM_PAINT或空闲消息就调用一次渲染函数。理解了这个结构你就明白了为什么DirectX游戏看起来是“一直在重绘”而不是像普通GUI程序那样只在系统事件触发时才重绘。3.2 D3DPRESENT_PARAMETERS设备初始化的关键从源码里复制D3DPRESENT_PARAMETERS结构体时满屏的字段容易让人头晕。但其实只要抓住几个核心成员结构就清楚了。成员作用我常用的值BackBufferWidth / BackBufferHeight后备缓冲大小通常等于窗口客户区大小窗口尺寸BackBufferFormat后备缓冲颜色格式D3DFMT_A8R8G8B8MultiSampleType多重采样抗锯齿级别D3DMULTISAMPLE_NONESwapEffect交换链模式D3DSWAPEFFECT_DISCARDhDeviceWindow渲染目标窗口主窗口句柄Windowed是否窗口模式TRUEEnableAutoDepthStencil是否启用深度模板缓冲TRUEAutoDepthStencilFormat深度缓冲格式D3DFMT_D24S8PresentationInterval呈现间隔D3DPRESENT_INTERVAL_IMMEDIATE字段初始化完毕后调用CreateDevice源码通常会选第一个可用适配器但更讲究一点的做法是遍历IDirect3D9::GetAdapterCount查找支持D3DDEVTYPE_HAL的适配器。我用这套方式排查过不少设备兼容问题能少走很多弯路。3.3 渲染循环里的标准五连每个源码示例的核心渲染代码都长得很像因为D3D9的渲染顺序是固定套路。这个套路我在多年后依然觉得值得背下来g_pd3dDevice-Clear(0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, D3DCOLOR_XRGB(0, 0, 255), 1.0f, 0); g_pd3dDevice-BeginScene(); // 在这里绘制三角形、模型或应用Shader g_pd3dDevice-EndScene(); g_pd3dDevice-Present(NULL, NULL, NULL, NULL);Clear负责清空颜色缓冲和深度缓冲BeginScene和EndScene必须成对出现所有绘制调用都要放在它们之间Present才把后备缓冲翻转到前台。随书源码里还有个小细节值得学习很多示例在Clear前会先用GetRenderTarget得到当前渲染目标并保存这是为了方便以后做离屏渲染和后期处理。3.4 第一个三角形的完整数据流源码里画三角形的那一例是理解顶点数据最直观的切口。它通常定义一个包含三维坐标和颜色的顶点结构struct CUSTOMVERTEX { float x, y, z; DWORD color; }; #define D3DFVF_CUSTOMVERTEX (D3DFVF_XYZ | D3DFVF_DIFFUSE)然后填好三个顶点调用CreateVertexBuffer创建缓冲区再通过Lock把CPU数据拷进GPU可访问的内存最后在绘制循环里用DrawPrimitive提交。这个过程看起来繁琐但演变到今天仍然是“顶点数据-绑定资源-调用DrawCall”的老祖宗。明白这一步后面理解索引缓冲、实例化、动态顶点缓冲都会轻松很多。4. 最该反复读的三段代码4.1 Direct3DCreate9与CreateDevice的选择逻辑源码里设备初始化那十几行代码很多人只当模板抄从不研究为什么要这样写。实际上它分为两步先用Direct3DCreate9(D3D_SDK_VERSION)拿到IDirect3D9接口再枚举适配器创建设备。关键点在于D3D_SDK_VERSION这个参数它让运行时检查头文件版本与系统DLL版本是否一致不一致时会直接拒绝创建设备。如果编译时用2010 SDK运行时却混入更老或更新的D3D9运行时虽然系统自带d3d9.dll但与SDK配套的D3DX dll仍需单独处理就可能出现接口创建失败。创建参数里有两个设备类型值得对比着读D3DDEVTYPE_HAL表示使用硬件加速的光栅化设备速度较快D3DDEVTYPE_REF表示使用参考实现软件模拟功能更完整但性能很慢。我在调试时经常保留一个可以通过按键切换设备类型的逻辑因为某些特效在老旧显卡上只有REF能跑通用这种方式可以快速区别问题是出在设备能力还是出在代码本身。4.2 FVF顶点格式里的内存布局随书源码里几乎所有顶点相关示例都绕不开D3DFVF_*常量。很多人只记住了“XYZDiffuse”的写法却没意识到这些常量本质上是告诉D3D9“顶点数据在内存里怎么排列”。例如D3DFVF_XYZ | D3DFVF_DIFFUSE就表示每个顶点先连续存放3个float坐标再存放1个DWORD颜色。你填错顺序画面就会呈现撕裂、倾斜或者干脆什么都画不出来。我还见过不少初学者把D3DFVF_XYZRHW和D3DFVF_XYZ混用。前者表示顶点已经处于屏幕坐标系并携带一个齐次坐标w后者表示仍在世界/视图空间需要经过变换。源码里有些示例为了让界面元素和3D物体同时渲染会在不同VertexBuffer里混用这两类FVF。顺着这个差异去读代码你会突然明白为什么2D UI和3D场景要分开处理。4.3 从SetLight到Effect文件的路线转变这本书源码中最精彩的部分是同一个场景提供了固定管线和Shader两套实现。固定管线版本里你会看到一堆SetLight、SetMaterial、SetTransform调用渲染状态全由当前参数决定Shader版本里这些状态被封装进一个.fx文件通过BeginPass、CommitChanges来切换g_pEffect-SetTechnique(RenderScene); g_pEffect-SetVector(g_LightDir, D3DXVECTOR4(1.0f, -1.0f, 0.0f, 0.0f)); g_pEffect-Begin(NULL, 0); g_pEffect-BeginPass(0); // DrawPrimitive 提交顶点 g_pEffect-EndPass(); g_pEffect-End();我建议把同一个场景的两个版本并排对照着编译、Run、修改参数。你会发现固定管线下调一个光照参数要改一堆状态而Shader里只需要改向量值或Shader算法本身。这种“亲手摸到差距”的经验胜过读十篇架构分析文章。5. 我编译这套源码踩过的坑与最终排查链路5.1 找不到d3dx9.lib但又没有明显编译错误这个问题在VS2019/2022配合新版Windows SDK时特别常见。现象是代码高亮正常、头文件能找到但一链接就报“无法打开文件d3dx9.lib”。原因是新版Windows SDK不再默认提供D3DX辅助库老工程链接器输入里没有显式写入这个库名。排查思路其实很简单打开项目属性确认“VC目录-库目录”已经指向DirectX SDK的Lib目录并且在“链接器-输入-附加依赖项”里写入了d3dx9.lib和d3d9.lib。如果还是找不到多半是64位/32位目录指错了就检查Lib\x86和Lib\x64是否与解决方案平台匹配。5.2 程序运行时提示缺少D3DX9_43.DLL这个提示意味着编译已经通过但运行环境的PATH里没有D3DX动态库。d3dx9_43.dll是DirectX SDK中的辅助组件Windows系统不会自带必须随应用一起分发或者安装DirectX End-User Runtime。我在实际项目里喜欢直接把用到的D3DX dll复制到exe同目录这样即使用户机器上没有安装任何DirectX运行时也能跑。源码工程里有些示例会依赖多个dll我一律采用“复制到本地”策略避免在别人电脑上演示时崩掉。5.3 程序没提示错误但画面全黑这是最磨人的一类问题因为程序运行正常也没有异常崩溃。我的排查链路固定是先确认D3DPRESENT_PARAMETERS里的Windowed是否与当前窗口模式一致再检查Clear是否真的执行接着把设备类型从D3DDEVTYPE_HAL切到D3DDEVTYPE_REF如果REF能正常显示说明是硬件能力或显存初始化问题而非渲染逻辑问题。还有一个容易被忽略的点老源码常常在创建窗口时把背景色涂成黑色而D3D9的Clear又填了同样的黑色。程序其实在正常渲染但画面看起来就像黑屏。这时候把背景色改成高亮颜色或者临时在三角形上加大点坐标就能立刻判断渲染是否真正生效。5.4 中文路径引起的神奇问题老代码的预编译头处理对中文路径兼容性很差我曾在D:\图形学\Demo路径下编译结果C1010、C1853这类问题轮番出现一度以为是代码损坏。后来把所有源码移到纯英文路径D:\DX9\Demo问题立刻消失。如果你的解决方案里存在多个项目记得把中间目录和输出目录也改成英文路径。这个土办法虽然不起眼但在读《Beginning DirectX 9》随书源码这类老工程时能省下大把本不需要浪费的排查时间。我从这套源码里学到的不只是几个API的用法而是一套“先跑通、再改良、最后自建”的学习方法论。现在遇到再复杂的现代渲染引擎我依然会用这套老代码训练的直觉去追显卡命令、帧缓冲和Shader调度的来龙去脉。如果你手里也有一份这样的老光盘或历史源码备份别让它躺在角落里吃灰抽一个周末把环境搭起来亲手把那个蓝色三角形画出来你会有意外收获。本文还有配套的精品资源点击获取