简介一份基于 Visual C 与 DirectX 开发 GUI 用户界面的完整工程源码面向希望用 Direct3D 自定义图形界面的中高级 C 开发者。工程以“引擎UI层”组织核心包含 CUIControl、CUIMessageBox、CUIWindow、CUIDesktop、CUIButton 等控件类以及 CD3DGlobal、CD3DUtility 等 DirectX 3D 初始化与工具模块适合学习如何在非传统窗口环境下构建按钮、列表框、滑块、消息框等交互组件。压缩包内共79个文件以38个头文件与36个cpp源文件为主配合ico图标、vcproj/sln工程文件和rc资源脚本整体约121KB头文件负责接口声明与结构定义cpp实现渲染、输入与控件逻辑分类清晰便于按模块拆读。目前已有328人学习下载适合需要深入DirectX UI框架设计、控件消息机制或D3D渲染流程的读者参考复用。1. 拿到这份资源之后先搞明白 DirectX UI 到底解决什么问题这份visual c基于DirectX开发制作的GUI用户界面.zip我拆完之后的第一反应是它并不是一个完整的游戏而是一个把 DirectX 9 图形能力和 C 控件封装揉在一起的 UI 框架顺带用 BattleTank 这个项目当载体。里面CUI开头的类占了八成CUIControl、CUIButton、CUIListBox、CUIMessageBox 这些文件摆在一起其实就是一套可复用的“游戏内 GUI 控件库”。适合谁两种人一种是刚把 DirectX 设备初始化摸熟、想给游戏加菜单却不知道怎么组织控件的开发新手另一种是想看老派 D3D UI 架构、想把控件分层思路搬进自己引擎的熟手。它能直接给你一套消息分发、控件绘制、键盘鼠标输入的完整回路不用再自己闭门造车。2. CUI 控件体系从 CUICore 到控件派生的消息分发脉络2.1 先看懂这个库的分层控件、渲染、系统三块怎么咬合打开压缩包UI目录下文件分成三撮CUIControl、CUIButton、CUIListBox、CUISlider、CUITextBox是控件本体CUIMessage、CUIBaseMessageHandle、CUICore是消息中枢CUIBitmapMgr、CUIBaseFont、CUIBaseSound、CUIBaseBrush是底层资源封装。这三层的关系很直白控件不直接碰 D3D 设备它只往消息队列里投事件渲染层拿到绘制命令后才会跟表面、纹理打交道。CUICore是全局控制类它管理 window 的注册和消息分发CGUIGlobal存的是跨控件共享的全局状态比如当前分辨率、默认字体句柄、全局透明度。我一般是按“控件树”来理解这套代码桌面类CUIDisktop是最外层容器往里挂各种控件按钮、消息框、弹出框都是树上的节点。CUIWindow是所有控件的基类CUIControl又在其上做了交互扩展。这样设计的好处是焦点管理和绘制顺序都统一在树里递归处理不需要每个控件自己维护 Z 序。2.2 消息分发CUIMessageHandle 与 CUIMessage 的回调路径这套库的核心是消息驱动。CUIMessage是消息体CUIBaseMessageHandle是处理者的抽象基类任何控件想接收消息就要继承它并重写处理函数。CUIMessageBox、CUIPopupDlg这类窗口类各自实现了自己的处理版本。消息类型大致包括鼠标按下/抬起、鼠标移动、键盘按键、绘制请求、控件通知。每条消息带有目标控件 ID 和发送方指针分发器根据 ID 找到目标再调用对应的虚函数。常见做法是主循环每帧调用一次CUICore的某个入口比如Update和Render外部把WM_LBUTTONDOWN、WM_MOUSEMOVE转成内部消息后灌进去。下面是一段我照着这个思路写的最小分发骨架不是库原码但流程一致// CUICore 的简化消息分发入口示意 void CUICore::DispatchMessage(CUIMessage* pMsg) { // 1. 根据消息携带的目标控件 ID 查找控件 CUIWindow* pTarget FindWindowByID(pMsg-GetTargetID()); if (pTarget nullptr) { // 没有指定目标时按鼠标命中坐标反向查找 pTarget HitTest(pMsg-GetMouseX(), pMsg-GetMouseY()); } // 2. 交给控件处理返回值决定消息是否继续冒泡 BOOL bHandled FALSE; if (pTarget) { bHandled pTarget-HandleMessage(pMsg); } // 3. 未处理的消息回退给全局处理链 if (!bHandled m_pBaseHandler) { m_pBaseHandler-HandleMessage(pMsg); } }参数上要注意GetTargetID()和HitTest的取舍显式 ID 分发适合按钮、菜单这种静态控件命中测试适合拖动条、列表项这类动态区域。HandleMessage返回TRUE表示消息被消费不再往下传递这能避免按钮点击同时触发父窗口的关闭逻辑。2.3 一个控件的完整生命周期从创建到销毁控件生命周期分四步构造时注册到CUICore获得唯一 ID收到尺寸、贴图、文本等初始化参数进入主循环后由CUICore::Render沿控件树递归绘制销毁时从注册表摘除并释放纹理。CUIMessageBox.cpp和CUIPopupDlg.cpp分别是模态窗口和弹出式窗口的典型实现前者内部阻塞消息循环直到用户点掉后者只挂载到桌面层上。这里最容易踩的坑是控件析构时忘记从CUICore反注册。挂着空指针的控件树在下一次绘制时直接访问违例而且这个崩溃往往和操作步骤对不上玄学得很。我的习惯是在CUIWindow基类析构函数里做UnregisterWindow(this)保证所有派生类都逃不掉。3. DirectX 渲染后端CD3DGlobal 初始化与窗口表面管理3.1 CD3DGlobal 到底封装了什么engine目录下CD3DGlobal和CD3DUtility是渲染后端的核心。看过代码就知道它不是把 D3D 设备再包一层那么简单——它承担了三件事设备生命周期管理、渲染状态栈、以及表面回收。设备生命周期你不用在每个控件里重复写CreateDevice和Release全局有一个设备指针控件绘制前检查是否有效。CD3DUtility则提供矩阵变换、纹理加载、颜色格式转换的工具函数。这种搞法最大的价值在资源管理。DirectX 9 时代的纹理和表面需要手动Release漏一个就是显存泄漏。CD3DGlobal内部维护一个表面列表窗口尺寸变化或设备丢失时统一重置。下面是一个标准 DX9 设备初始化骨架和库里的CD3DGlobal::Initialize逻辑一致// Direct3D9 设备初始化与 CD3DGlobal 的做法一致 LPDIRECT3DDEVICE9 g_pDevice nullptr; LPDIRECT3D9 g_pD3D nullptr; bool InitD3D(HWND hWnd, int width, int height) { g_pD3D Direct3DCreate9(D3D_SDK_VERSION); if (!g_pD3D) return false; D3DPRESENT_PARAMETERS d3dpp {}; d3dpp.BackBufferWidth width; d3dpp.BackBufferHeight height; d3dpp.BackBufferFormat D3DFMT_A8R8G8B8; d3dpp.BackBufferCount 1; d3dpp.SwapEffect D3DSWAPEFFECT_DISCARD; d3dpp.hDeviceWindow hWnd; d3dpp.Windowed TRUE; d3dpp.EnableAutoDepthStencil TRUE; d3dpp.AutoDepthStencilFormat D3DFMT_D24S8; // 硬件顶点处理优先失败退软件处理 HRESULT hr g_pD3D-CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd, D3DCREATE_HARDWARE_VERTEXPROCESSING, d3dpp, g_pDevice); if (FAILED(hr)) { hr g_pD3D-CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, d3dpp, g_pDevice); } return SUCCEEDED(hr); }关键参数D3DFMT_A8R8G8B8是带透明通道的 32 位色格式UI 贴图用这个格式才能做 alpha 混合D3DSWAPEFFECT_DISCARD在老显卡上兼容性最好但丢失后台缓冲区内容为代价所以每帧必须全量重绘。这个项目 UI 绘制是每帧从根节点重画一遍的所以 DISCARD 没毛病。3.2 设备丢失与表面回收多数人翻车的地方DirectX 9 最恶心的机制就是设备丢失。窗口被拖拽、切换分辨率、AltTab 都可能触发D3DERR_DEVICELOST如果不处理轻则花屏重则卡死。CD3DGlobal.cpp里应该有对应的恢复逻辑常规做法是检测到设备丢失后先把所有显存池为D3DPOOL_DEFAULT的资源释放再调用Reset最后重新创建纹理。我猜这套代码的资源池用的是D3DPOOL_MANAGED因为CUIBitmapMgr这类管理器通常用托管池省事——驱动会帮你做备份和恢复。但代价是每次纹理访问多一次内部拷贝对 UI 这种纹理小、频率高的场景影响不大。要是你自己改库想把性能抠出来换D3DPOOL_DEFAULT就得在设备恢复回调里重载纹理工作量直接翻倍不建议新手动。3.3 位图与字体贴图和文字的底层配合CUIBitmapMgr.cpp管位图加载CUIBaseFont.cpp管字体渲染。这里有个典型的 DirectX 方案字体先按字模栅格化到系统内存位图再上传到显存表面绘制时把带透明通道的表面 blit 到后备缓冲区。文件里出现CUIBaseBrush和CUIBaseBitmap前者是画刷状态后者是位图封装的基类。实际操作中字体这块最容易出现中文乱码。项目用的是宽字符还是窄字符取决于stdafx.h里是否定义UNICODE。我翻文件列表时看到ime.h和ime.cpp这是输入法相关说明这套 UI 对中文输入做了接入那字体渲染大概率走的是D3DXCreateFont配合GetGlyphOutline的路线。跑起来发现文字变方块先查字符集再看字体资源里有没有对应字形的编码页。4. 键盘与光标KeyControl 和 CUICursor 的输入链路4.1 KeyControl把扫描码翻译成 UI 语义engine/KeyControl.cpp和KeyControl.h把 Windows 的键盘消息翻译成语义键比如把方向键映射成UP、DOWN、LEFT、RIGHT把功能键映射成CONFIRM、CANCEL。这样控件层不需要关心实际按键只响应语义值。这个设计在游戏 UI 里非常有用因为玩家可能改了按键配置同一份控件代码不用跟着改。来看一段典型映射逻辑// 扫描码转语义键的简化实现 UINT KeyControl::TranslateKey(UINT wParam) { switch (wParam) { case VK_UP: return KEY_UP; // 上方向 case VK_DOWN: return KEY_DOWN; // 下方向 case VK_LEFT: return KEY_LEFT; // 左方向 case VK_RIGHT: return KEY_RIGHT; // 右方向 case VK_RETURN:return KEY_CONFIRM; // 确认键 case VK_ESCAPE:return KEY_CANCEL; // 取消键 default: return KEY_UNKNOWN; } }注意KEY_CONFIRM和KEY_CANCEL是语义键不是物理键。控件库里CUIButton关注的是“收到确认”而不是“按下回车”。这套抽象决定了你的按钮能不能同时支持键盘和手柄。文件里只有 KeyControl 没有 Gamepad 类说明这版本只接了键盘但语义层的设计留了扩展位。4.2 光标CUICursor 与坐标换算CUICursor.cpp维护了一个光标纹理和位置每帧根据鼠标消息更新绘制阶段最后把光标画在最顶层。坐标换算是个细节活WM_MOUSEMOVE给的是客户区坐标但 D3D 渲染的后备缓冲区坐标可能和窗口客户区尺寸不一致——尤其是开了全屏独占模式后分辨率跟桌面不一样。换算公式是// 客户区坐标到逻辑 UI 坐标的换算 float scaleX (float)uiWidth / (float)clientWidth; float scaleY (float)uiHeight / (float)clientHeight; int uiX (int)((float)mouseX * scaleX); int uiY (int)((float)mouseY * scaleY);这里uiWidth/uiHeight是 UI 逻辑分辨率clientWidth/clientHeight是 D3D 设备实际渲染尺寸。很多“按钮点不到”的诡异问题根源就在这控件按逻辑坐标系做命中测试鼠标消息却用的客户区原生坐标不换算永远点偏。做全屏自适应布局时这套换算必须绑在CD3DGlobal的尺寸变更流程里。4.3 焦点管理谁负责路由键盘事件键盘消息需要焦点概念。CUICore维护一个焦点窗口指针KeyControl翻译后的语义键发给焦点窗口而不是广播给所有控件。CUIListBox不需要键盘输入时不会吃到方向键只有CUITextBox或聚焦的按钮才响应。这种单焦点模型简单可靠但有个缺陷模态窗口弹出来时要把焦点强制锁定到CUIMessageBox上否则玩家还能操作底层菜单逻辑就乱套了。我看到CUIMessageBox的实现思路是在 Show 时把全局输入接管关闭时再还回去。如果你要扩展成多窗口同时交互这套焦点模型得加“焦点栈”才能支持。5. 常见问题排查DirectX UI 编译与运行的六个典型坑5.1 双击解决方案文件却打不开版本不匹配现象用新版 Visual Studio 双击BattleTank.sln提示项目格式不兼容打不开BattleTank.vcproj。原因vcproj是 Visual Studio 2008 及之前版本的项目文件格式2012 之后改用vcxproj。DirectX 9 时代的老项目基本都是这个格式。解决三个办法任选一个。装 VS2008 或 VS2010 直接编译用 VS2010 的“转换向导”把项目升级成vcxproj或者手动新建空工程把.cpp和.h全部拖进去重新配 DX 9 SDK 的 include 和 lib 路径。我一般用第三个干净利落还能顺便清理掉老工程里多余的平台配置。5.2 编译通过、运行时黑屏现象程序启动后窗口一片黑没有 UI 元素也没有崩溃。原因最常见的是CreateDevice失败或渲染循环没有调用Present。DX9 有句老话设备创建成功不代表每帧都渲染成功。全屏模式下Present频繁失败说明后台缓冲区和显示模式没对上。解决先查InitD3D的返回值再查每帧Present的返回值。D3DERR_DEVICELOST就得走资源重建流程D3DERR_INVALIDCALL基本可以断定绘制参数不合法。还有一个容易被忽略的窗口化的BackBufferFormat必须和桌面色深匹配D3DFMT_UNKNOWN有时需要显式传D3DFMT_A8R8G8B8。你们可以搜一下 “directx 修复工具” 里的 DirectX 运行时组件是不是完整缺少 end-user runtime 时设备枚举都会异常。5.3 按钮和图片显示成白块或花块现象界面跑起来了但按钮贴图是一块白方块文字位置是花屏噪点。原因纹理格式和表面格式不一致。UI 贴图带透明通道但加载时用默认格式创建alpha 信息被丢弃混合时就会出现白底。文字那种是字体位图上传到显存时 pitch 没对齐。解决创建纹理时统一指定D3DFMT_A8R8G8B8并调用D3DXImage_LoadFromFileInMemory加载 PNG/TGA确保每像素 32 位。我在这个资源里翻到CUIBitmapMgr.cpp你们重点看它创建纹理的第三个参数缺D3DX_DEFAULT_NONPOW2的话老显卡上非 2 次幂贴图会异常。字体方面字模位图每行字节数要按 4 字节对齐BITMAPINFOHEADER::biWidth记得算上 padding。5.4 控件能画出来但点不中现象按钮显示在屏幕上鼠标也移过去了但点击毫无反应。挪动窗口位置后命中区域反而在乱跳。原因坐标换算不一致。投射命中测试用的是 UI 逻辑坐标鼠标消息用的是客户区坐标中间缺了clientToUI换算步骤。窗口带边框移动时还会引入非客户区偏移。解决统一走CD3DGlobal暴露的坐标变换接口先GetClientRect拿到真实客户区大小再做第 4.2 节的scaleX/scaleY换算。调试时可以临时在控件命中处理里设断点对比pMsg里带的鼠标坐标和控件矩形就知道偏差量是多少了。5.5 光标残影或闪烁现象光标拖慢或者鼠标移动后屏幕上拖着一条模糊尾巴像残影。原因渲染循环只画了鼠标覆盖到的局部没清后台缓冲区残留。DX9 的SwapEffect如果是DISCARD每帧必须全量重绘光标尤其要最后画因为它可能在清除和重画之间被覆盖。解决每帧开头Clear( pDevice, 0, NULL, D3DCLEAR_TARGET, 0xFF000000, 1.0f, 0 )全屏清色绘制顺序上把CUICursor::Render放到整个 UI 树的最后。还有遇到CUICursor和CUIMessageBox重叠时弹窗的光标逻辑必须用同一个光标管理器否则两个光标互相覆盖。5.6 中文输入异常或文字乱码现象CUITextBox里输入中文直接没反应或者显示出方块。原因没接 IME 消息处理。文件里虽然带了ime.h/ime.cpp但接入点要看BattleTank.cpp的窗口过程里有没有转发WM_IME_*消息。另一个是字符集问题项目用多字节字符集编译但字体选的是 Unicode 字库调用TextOut时直接走窄字符路径汉字编码对不上。解决把项目字符集统一成 Unicode在stdafx.h里定义UNICODE和_UNICODE控件内部字符串改用TCHAR或std::wstring。IME 消息转发一定按这个顺序WM_IME_STARTCOMPOSITION→WM_IME_COMPOSITION→WM_IME_ENDCOMPOSITION漏掉COMPOSITION的话候选框出不来。这个坑我在别的项目里折腾了两天才定位到说多了都是泪。6. 上手改造把控件库嵌进你自己的 DirectX 项目最省力的用法不是直接用它的BattleTank主程序而是把UI和engine两个目录当成外部库合并到你的工程里。具体操作新建空项目把CUI*.cpp/h、CD3DGlobal.cpp/h、CD3DUtility.cpp/h、KeyControl.cpp/h加进来删掉BattleTank.cpp的入口把控件注册放到你自己的初始化函数中。关键步骤是让 UI 库的全局入口适应你的主循环。以我改造的实际经验最快方式是把CUICore的更新和渲染还有KeyControl的翻译过程统一塞进你的游戏循环里。下面是我后来一直沿用的模板你们可以直接抄// 把 CUICore 挂进自己的引擎主循环 void MyEngine::UpdateAndRenderUI() { // 1. 从 Windows 消息队列中取出鼠标、键盘事件 MSG msg; while (PeekMessage(msg, nullptr, 0, 0, PM_REMOVE)) { if (msg.message WM_MOUSEMOVE) { // 换算坐标后派发给 UI 层 int uiX msg.pt.x; // 正式代码需换成客户区换算 int uiY msg.pt.y; g_CUICore.SendMouseMove(uiX, uiY); } else if (msg.message WM_LBUTTONDOWN) { g_CUICore.SendMouseDown(MOUSE_LEFT); } else if (msg.message WM_KEYFIRST msg.message WM_KEYLAST) { UINT key KeyControl::TranslateKey(msg.wParam); g_CUICore.SendKeyDown(key); } } // 2. 更新控件状态 g_CUICore.Update(); // 3. 渲染 UI 到后备缓冲 g_CUICore.Render(); }这套写法的好处是 UI 库和游戏逻辑的解耦被推到了极致——游戏跑固定帧率UI 随消息驱动两者互不阻塞。参数上KeyControl::TranslateKey的输入是wParam我建议你们加一层 get 键状态函数同时支持按下和长按否则菜单滚动时会有粘滞感。CUICore 的Update里如果做了帧率插帧动画CUIAnimationRate.cpp 就是干这个的那Update必须带 deltaTime 参数防止不同刷新率下按钮动效速度不一致。还有个小技巧CUIAnimationRate是这套库里容易被忽略的宝贝。按钮悬停、弹窗淡入淡出全靠它算插值比例。把它从 UI 目录里拆出来接到自己的控件上能省掉大量硬编码动画帧。参数上一般给个 0.2 到 0.5 秒的动画时长配合easeOut曲线手感立刻上一个台阶。注意如果你们机器上缺 DirectX 运行时界面能启动但Direct3DCreate9返回 null多半是需要装 directx 修复工具或补 DirectX End-User Runtime。这属于环境问题不是代码问题排查时先把这个排除掉。从那以后我每次接手老 DirectX 项目都强制走一遍这个流程先拆目录确认消息分发链路再跑设备初始化看返回码最后用最小窗口把 CUICore 挂进去验证。顺序错了排查成本会翻好几倍。这套资源说到底是个很好的架构样本把控件和渲染分离的思路放到今天的引擎里依然成立。希望帮到你。本文还有配套的精品资源点击获取