企业官网建设流程全解析

简介：该资源为一个用 C++ 与 DirectX 11 实现的经典吃豆人游戏项目，灵感来源于 1980 年原始版本，适合对游戏开发、图形渲染或复古游戏复刻感兴趣的初学者与进阶开发者。项目依赖 DirectXTK 简化 DirectX 使用，工程基于 Visual Studio 2017，包含完整可编译源码、着色器、精灵图及资源文件，共 61 个文件，涵盖 h/cpp 源码、hlsl 着色器、png/gif 图像资源以及 sln/vcxproj 工程配置等，压缩包约 6MB。游戏还原了原版操作手感，支持方向键控制、幽灵追击、能量豆反制等经典机制，四个幽灵均拥有基于 1980 年代版本的独立 AI，并提供能量状态切换与阶段变化。地图以分离立方体构建，通过相邻面合并优化三角形数量，避免 z-fighting 问题，体现了实际渲染优化思路。压缩包内附 README 与资源说明，便于查阅与二次开发。截至目前已有 109 人学习下载，适合作为 DirectX 入门练手或游戏机制复刻的参考项目。

1. 用 C++ 和 DirectX 11 重写吃豆人：为什么值得折腾？

用 C++ 和 DirectX 11 开发一个吃豆人游戏，听起来像 Computer Graphics 课的陈年作业，但当你在网上看到那个“吃豆人游戏.zip”并解压后，会发现这里藏着的不是几张贴图，而是一条完整的 DirectX 11 渲染管线。这套东西能让你明白现代游戏引擎替你藏了多少事。如果你已经会 C++ 基础，想搞清楚 2D 游戏从窗口创建到精灵绘制、再到碰撞判定到底是怎么串起来的，这个项目非常合适。本文不点评某个具体压缩包，而是讲清这类 C++/DirectX 11 吃豆人工程最常见的实现路径、参数和翻车点，让新手能照着复现，熟手能直接填坑。

2. 拿到工程先别急着跑：弄清楚 D3D11 项目该长什么样

2.1 解压后的常见文件结构：一份清单的意义

一个用 C++ 和 DirectX 11 写的吃豆人项目，解压后通常不是只有一个 exe。我更关心源码、资源、着色器是怎么组织的，因为这三个部分分别代表了渲染逻辑、游戏内容和 GPU 指令。

拿到 zip 先做的事不是找 exe，而是看 README 和构建文件。很多这类项目都是课程作业级别，默认你用 Visual Studio 且装过 Windows SDK。如果你直接双击编译好的 exe，可能会因为 shaders 或 assets 路径不对而黑屏。为何？因为代码里常常用相对路径“shaders\sprite.hlsl”，而工作目录和 exe 所在目录不一致时，文件就找不到了。我一般会在构建阶段自动把 assets 和 shaders 复制到目标目录，这个后面讲。

还有一点容易忽视：资源文件是文本地图还是图片地图。经典吃豆人用字符网格表示墙和豆子，比如 '#' 代表墙，'.' 代表豆子，'O' 代表能量豆。这种格式的好处是任何人都能直接改关卡，也方便在控制台输出 DEBUG 状态。DirectX 11 只是渲染最外层，游戏逻辑其实不依赖图形 API，这也是为什么这种项目特别适合学习解耦。

2.2 环境配置：Visual Studio 与 Windows SDK 的边界

在 Visual Studio 2019 或 2022 中，Windows SDK 自带 d3d11.h 和 d3d11.lib，不需要像旧时代那样单独装 DirectX SDK。很多新手在配置属性里乱加包含路径，结果反而让编译器找到版本不对的 d3d11.h，报出一堆不明错误。

我的做法很简单：安装 VS 时勾选“使用 C++ 的桌面开发”工作负载，它默认会装上 Windows SDK。项目平台建议选 x64，不要用 x86。为什么？DirectX 11 本身 32/64 都支持，但现代系统里 x64 下指针宽度一致，调试工具识别更好，资源加载也不容易碰到重定向问题。如果你遇到“无法打开 d3d11.h”，多半是 Windows SDK 版本没装全，回到 VS Installer 里勾选当前 Windows SDK 后修复即可。

如果你更习惯 vscode 配置 c/c++ 环境再配 CMake，当然也可以，但需要确认编译器能链接到系统库。直接在 CMake 里使用target_link_libraries指向 d3d11、dxgi、d3dcompiler 是跨 VS 与 vscode 的标准做法。另外一个值得注意的点是NOMINMAX。Windows.h 里有min和max宏，会和 C++ 标准库的std::min冲突，让代码变得很玄学。CMake 里加target_compile_definitions(PacMan PRIVATE NOMINMAX)能省掉很多烦躁。

2.3 用 CMake 组织构建是这类项目最常见的后悔药

很多从课程流出的源码是 .sln 工程的，VS 打开能直接编，但可移植性差。我更愿意用 CMake 重写构建脚本，至少以后换机器不用反复配置库路径。下面是一个最精简的 CMakeLists.txt，能覆盖大多数 D3D11 2D 游戏项目。

cmake_minimum_required(VERSION 3.20) project(PacManD3D11) set(CMAKE_CXX_STANDARD 17) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) add_executable(PacMan src/main.cpp src/PacManGame.cpp src/PacManGame.h src/D3D11Helper.cpp src/D3D11Helper.h shaders/sprite.hlsl ) target_include_directories(PacMan PRIVATE src) target_compile_definitions(PacMan PRIVATE NOMINMAX) # DirectX 11 链接 target_link_libraries(PacMan PRIVATE d3d11 dxgi d3dcompiler) # 运行前自动拷贝 assets 和 shaders 到 exe 所在目录 add_custom_command(TARGET PacMan POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_SOURCE_DIR}/assets $<TARGET_FILE_DIR:PacMan>/assets COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_SOURCE_DIR}/shaders $<TARGET_FILE_DIR:PacMan>/shaders COMMENT "Copying runtime resources" )

这段脚本的逻辑很简单：d3d11提供设备和上下文，dxgi负责交换链和显示模式，d3dcompiler负责在运行时把 HLSL 编译成字节码。加 DirectXTK 这类第三方库时再补find_package就可以，但这里的核心项目用不到。POST_BUILD这两条命令非常重要，否则因为你直接运行bin/PacMan.exe时，当前目录是 bin，代码里std::ifstream("assets/map.txt")会失败。

在实际项目里我还会加一个#define用来控制是否启用 D3D11 调试层。平时 Debug 构建开启调试层，可以帮你看到很多资源和状态错误；Release 构建就关掉，避免性能损耗。配置参数就写在 CMake 里，比如：

target_compile_definitions(PacMan PRIVATE $<$<CONFIG:Debug>:D3D11_DEBUG> )

然后在 C++ 里读取它，决定传给D3D11CreateDevice的D3D11_CREATE_DEVICE_DEBUG标志。这是后面排查纹理格式和渲染状态最有效的第一步，别等画面黑屏了再去猜哪里爆了。

3. DirectX 11 渲染管线的最小骨架：从窗口到第一个精灵

3.1 创建设备与交换链：每个 D3D11 游戏的“地基”

无论吃豆人还是其他 2D 游戏，第一步都是在 Win32 窗口上创建ID3D11Device（设备）和IDXGISwapChain（交换链）。设备用来创建纹理、缓冲区、着色器，交换链则决定你渲染好的画面怎么输出到显示器。窗口初始化不是本文重点，但hwnd必须有。

#include <d3d11.h> #include <dxgi1_3.h> #include <wrl/client.h> using Microsoft::WRL::ComPtr; ComPtr<ID3D11Device> device; ComPtr<ID3D11DeviceContext> context; ComPtr<IDXGISwapChain> swapChain; DXGI_SWAP_CHAIN_DESC sd = {}; sd.BufferDesc.Width = 800; sd.BufferDesc.Height = 600; sd.BufferDesc.Format = DXGI_FORMAT_B8G8R8A8_UNORM; sd.BufferDesc.RefreshRate.Numerator = 60; sd.BufferDesc.RefreshRate.Denominator = 1; sd.SampleDesc.Count = 1; sd.SampleDesc.Quality = 0; sd.BufferCount = 2; sd.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT; sd.OutputWindow = hwnd; sd.Windowed = TRUE; sd.SwapEffect = DXGI_SWAP_EFFECT_DISCARD; HRESULT hr = D3D11CreateDeviceAndSwapChain( nullptr, D3D_DRIVER_TYPE_HARDWARE, nullptr, D3D11_CREATE_DEVICE_BGRA_SUPPORT, nullptr, 0, D3D11_SDK_VERSION, &sd, &swapChain, &device, nullptr, // 不关心 feature level &context ); if (FAILED(hr)) { // 打印 hr 值，大概率是设备初始化失败 }

这段代码里的参数直接影响后面能不能画对。BufferCount = 2是双缓冲，减少画面闪烁；Format = DXGI_FORMAT_B8G8R8A8_UNORM是交换链常见格式，和 GDI 兼容性更好；SwapEffect用DISCARD表示每帧丢弃前一个缓冲，简单粗暴但也够用。

创建完交换链还要拿到它的后台缓冲区，绑定为渲染目标，否则你画的东西无处可去：

ComPtr<ID3D11Texture2D> backBuffer; swapChain->GetBuffer(0, IID_PPV_ARGS(&backBuffer)); ComPtr<ID3D11RenderTargetView> rtv; device->CreateRenderTargetView(backBuffer.Get(), nullptr, &rtv); context->OMSetRenderTargets(1, rtv.GetAddressOf(), nullptr);

之后在绘制循环里，先清屏再绘制：

float clearColor[4] = { 0.0f, 0.0f, 0.0f, 1.0f }; context->ClearRenderTargetView(rtv.Get(), clearColor);

有个常踩的坑是忘记在窗口大小变化时重建缓冲区和 RTV，结果拉伸后画面糊掉或直接花屏。吃豆人一般窗口固定，可以跳过，但如果你加缩放功能，必须监听WM_SIZE并调用IDXGISwapChain::ResizeBuffers。

3.2 用两个三角形拼出一个 sprite：没有 SpriteBatch 的日子

DirectX 11 没有内置的SpriteBatch，这和 XNA 时代不一样。2D 渲染的本质是画两个三角形，组合成一个四边形，再贴上纹理。四个顶点组成一个矩形，这个矩形就是你要显示的精灵。

顶点结构通常这样定义：

struct SpriteVertex { DirectX::XMFLOAT3 pos; // 位置 DirectX::XMFLOAT2 uv; // 纹理坐标 };

随后创建顶点缓冲区，把四个点按三角形顺序填进去。这里最关键的参数是纹理坐标的方向。我一般用 (0,0) 表示纹理左上角，(1,1) 表示右下角，这样和美术同学的习惯一致。代码里把坐标写成：

SpriteVertex vertices[] = { { { -0.5f, -0.5f, 0.f }, { 0.f, 1.f } }, { { 0.5f, -0.5f, 0.f }, { 1.f, 1.f } }, { { 0.5f, 0.5f, 0.f }, { 1.f, 0.f } }, { { -0.5f, 0.5f, 0.f }, { 0.f, 0.f } }, };

请注意这里 uv 的 y 值。DirectX 纹理坐标系中，v=0 对应纹理顶部，还是底部，取决于顶点着色器的SV_Position语义和你的投影矩阵。若搞反，你会发现图案上下颠倒。为了避免这种反直觉，我在实际项目里统一以屏幕左上角为原点，并在 HLSL 中处理顶点的y方向翻转，这放在 3.3 节详细讲。

然后是 HLSL 着色器。这是整个 D3D11 黑匣子里最容易出错的部分，一旦矩阵顺序写错，精灵通常直接消失或变成一条线。

cbuffer Transform : register(b0) { matrix mvp; }; Texture2D tex : register(t0); SamplerState samp : register(s0); struct VSInput { float3 pos : POSITION; float2 uv : TEXCOORD0; }; struct PSInput { float4 pos : SV_POSITION; float2 uv : TEXCOORD0; }; PSInput VSMain(VSInput input) { PSInput output; // 行主序矩阵，向量在前 output.pos = mul(float4(input.pos, 1.0f), mvp); output.uv = input.uv; return output; } float4 PSMain(PSInput input) : SV_TARGET { return tex.Sample(samp, input.uv); }

mul(float4(input.pos, 1.0f), mvp)是行主序矩阵乘法，DirectXMath 的XMMatrixTranspose和它配套。如果你发现精灵没有出现，优先怀疑矩阵是否在 CPU 端被转置错了。

顶点缓冲区和输入布局创建完之后，绘制调用只有一句：

context->VSSetShader(vs.Get(), nullptr, 0); context->PSSetShader(ps.Get(), nullptr, 0); context->IASetInputLayout(layout.Get()); context->IASetPrimitiveTopology(D3D11_PRIMITIVE_TOPOLOGY_TRIANGLELIST); context->Draw(4, 0);

3.3 正交投影：让精灵坐标和像素坐标对上

吃豆人这类 2D 游戏，最省心的做法是用单位化像素坐标，比如你想把精灵画到屏幕 (100, 200) 的位置，就直接以像素为单位设置顶点位置。要达到这个效果，需要为渲染创建一个正交投影矩阵。

常见做法是让投影矩阵把像素坐标映射到屏幕中心：

DirectX::XMMATRIX proj = DirectX::XMMatrixOrthographicLH( (float)screenWidth, (float)screenHeight, 0.1f, 1000.0f);

但XMMatrixOrthographicLH默认把原点放在屏幕中心，x 朝右，y 朝上。画面坐标和 Windows 窗口坐标不一致，因为窗口坐标 y 轴是朝下的。解决方式有好几种，我一般采用“先平移，再翻转 y”的方案。

定义一个适合吃豆人的坐标系：左上角为 (0,0)，x 向右，y 向下，便于直接对应地图行列。这可以通过修改投影矩阵实现：

DirectX::XMMATRIX view = DirectX::XMMatrixIdentity(); DirectX::XMMATRIX proj = DirectX::XMMatrixOrthographicLH( (float)screenWidth, (float)screenHeight, 0.1f, 1000.0f); proj = DirectX::XMMatrixMultiply( DirectX::XMMatrixTranslation(-(float)screenWidth * 0.5f, (float)screenHeight * 0.5f, 0.0f), proj);

这个矩阵会让原本在中心的原点移动到左上角，并且 y 向下。实际使用时，你只需要给精灵设置世界矩阵：

// 精灵的屏幕位置：spriteX, spriteY, 缩放 scaleX/scaleY DirectX::XMMATRIX world = DirectX::XMMatrixTranspose( DirectX::XMMatrixTranslation(spriteX, spriteY, 0.0f) * DirectX::XMMatrixScaling(scaleX, scaleY, 1.0f));

这里的核心参数是screenWidth和screenHeight，如果和交换链缓冲尺寸不匹配，精灵就会显示偏移。我一般会把这段代码封装成SetOrthographicProjection辅助函数，并每次窗口WM_SIZE重建。

3.4 纹理加载：D3DX 已是旧时代，WIC 才是现役方案

很多旧教程还在用D3DX11CreateShaderResourceViewFromFile，但 DirectX SDK 已经废弃，这个函数不存在于标准 Windows SDK 中。现役方案是用 WIC（Windows Imaging Component）加载 PNG/JPEG，或者直接使用 DirectXTK 的CreateWICTextureFromFile。我们在 CMake 里没有引入 DirectXTK，所以这里给出一个基于 WIC 的最小加载流程。

#include <wincodec.h> #include <d3d11.h> HRESULT LoadTextureFromWIC(ID3D11Device* device, const wchar_t* path, ID3D11ShaderResourceView** srvOut) { if (!device || !path || !srvOut) return E_INVALIDARG; // 初始化 COM，因为 WIC 是 COM 组件 CoInitialize(nullptr); IWICImagingFactory* factory = nullptr; IWICBitmapDecoder* decoder = nullptr; IWICBitmapFrameDecode* frame = nullptr; IWICFormatConverter* converter = nullptr; HRESULT hr = CoCreateInstance( CLSID_WICImagingFactory, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&factory)); if (FAILED(hr)) return hr; hr = factory->CreateDecoderFromFilename( path, nullptr, GENERIC_READ, WICDecodeMetadataCacheOnLoad, &decoder); if (FAILED(hr)) goto cleanup; hr = decoder->GetFrame(0, &frame); if (FAILED(hr)) goto cleanup; // 统一转为 32bpp BGRA 格式，和交换链一致 hr = factory->CreateFormatConverter(&converter); if (FAILED(hr)) goto cleanup; hr = converter->Initialize(frame, GUID_WICPixelFormat32bppBGRA, WICBitmapDitherTypeNone, nullptr, 0.0, WICBitmapPaletteTypeCustom); if (FAILED(hr)) goto cleanup; hr = device->CreateShaderResourceViewFromWIC(converter, srvOut); cleanup: if (converter) converter->Release(); if (frame) frame->Release(); if (decoder) decoder->Release(); if (factory) factory->Release(); CoUninitialize(); return hr; }

这段代码每个函数的参数都有讲究：GUID_WICPixelFormat32bppBGRA对应交换链的DXGI_FORMAT_B8G8R8A8_UNORM；CreateShaderResourceViewFromWIC是 D3D11 提供的便捷方法，内部会创建纹理和 SRV。你不需要自己再创建纹理。

加载成功后，在像素着色器里采样这张贴图。吃豆人的地图可以拆成几个小精灵（豆子、墙、鬼魂、角色），也可以全部放到一张图集里，用不同的 uv 区域绘制。推荐图集法：一次纹理加载，多次Draw，节省 GPU 状态切换。后面避坑章节会提到，图集 uv 写错是最容易翻车的地方。

4. 吃豆人自己的逻辑层：地图、移动、碰撞与简单 AI

4.1 用字符数组做地图，省心且容易调试

吃豆人世界里没有复杂的物理引擎，地图本质是网格。最靠谱的数据结构是二维字符数组。'#' 表示墙，'.' 表示普通豆子，'O' 表示能量豆，' ' 表示空地。下面是一段典型地图（摘取片段）：

const int mapRows = 15; const int mapCols = 19; char map[mapRows][mapCols + 1] = { "###################", "#.........#.......#", "#o##.###.#.###.##.#", "#.................#", "#.##.#.#####.#.##.#", "#....#...#...#....#", "####.###.#.###.####", "###.#.........#.###", "####.#.#.###.#.####", "#........#........#", "#.#####.#.#####..#.", "#o................o#", "###################", };

每个字符对应地图上一个格子。格子大小cellSize是精灵移动的标准单位。我习惯用 18 或 20 像素，这样角色大小 16 像素时能居中。角色位置和地图坐标的换算：

float spriteX = col * cellSize + (cellSize - spriteWidth) / 2.0f; float spriteY = row * cellSize + (cellSize - spriteHeight) / 2.0f;

这样做的最大好处是碰撞检测可以完全不依赖像素，只依赖“格子是否可通行”。当角色准备移动到下一格时，检查目标单元格的字符是否'#'即可。如果你让角色在网格间平滑移动，就还需要判断“正在穿越的格子”和“目标格子”之间的边界，这部分很容易产生穿墙问题，放到第五章详细说。

吃豆人豆子的管理可以做成一个简单数组或链表。每个豆子保存所在行列、是否已被吃掉。因为地图量小，每帧遍历所有豆子做矩形相交测试成本可以忽略。但如果你想更专业一点，可以在每格用一个位图标记豆子是否还存在，省去遍历。

4.2 固定时间步长：不要让快机器吃掉更多豆子

游戏循环是吃豆人最微妙的部分。如果直接while (running) { Update(); Draw(); }，帧率高的机器上豆子会以双倍速度被吃完，幽灵快如闪电。现代游戏引擎普遍使用固定时间步长加帧率插值，但吃豆人这种逻辑简单的小游戏，固定步长就够了。

const float fixedStep = 1.0f / 60.0f; float accumulator = 0.0f; LARGE_INTEGER prev = {}, curr = {}, freq = {}; QueryPerformanceFrequency(&freq.past &&); // 纠正：QueryPerformanceFrequency(&freq); QueryPerformanceCounter(&last); while (running) { QueryPerformanceCounter(&curr); float frameTime = static_cast<float>(curr.QuadPart - prev.QuadPart) / static_cast<float>(freq.QuadPart); frameTime = min(frameTime, 0.25f); // 防止长时间卡顿后跳帧 prev = curr; accumulator += frameTime; while (accumulator >= fixedStep) { Update(fixedStep); accumulator -= fixedStep; } Draw(); }

重要参数：fixedStep = 1/60。如果逻辑里用dt乘以速度，那么这个值就是基础时间单位。考虑到 Debug 断点暂停恢复时会累计很多帧，必须限制frameTime最大值；否则当你从断点恢复时，游戏会瞬间“追上”一大段逻辑，幽灵瞬移。限制 0.25 秒是一个常见选择，能避免这种跳跃感。

关于角色速度，我喜欢用“每多少秒移动一格”来描述，而不是像素每秒。比如吃豆人移动速度是cellSize * 6秒每格？其实写成每秒格数比较好：speed = 6，则每帧移动speed * fixedStep格。这样地图调整大小也不会影响手感。

4.3 幽灵 AI 与碰撞：曼哈顿距离和 AABB 足够用

吃豆人的幽灵不需要 A* 寻路，因为地图小且多为连通走廊，最经典的策略是“追逐”和“逃逸”两态切换。敌人要去的目标就是玩家所在格子，然后用曼哈顿距离判断下一步走哪个相邻格子最靠近玩家。

struct Vec2i { int row, col; }; Vec2i nextGhostStep(Vec2i ghost, Vec2i player, int map[mapRows][mapCols], Vec2i prevDir) { int dirs[4][2] = { {-1,0}, {1,0}, {0,-1}, {0,1} }; // 禁止 180 度掉头，否则幽灵会原地抽搐 int dirIndex[4] = {0,1,2,3}; Vec2i bestDir = prevDir; int minDist = INT_MAX; for (int d = 0; d < 4; ++d) { if (dirs[d][0] == -prevDir.row && dirs[d][1] == -prevDir.col) continue; int nr = ghost.row + dirs[d][0]; int nc = ghost.col + dirs[d][1]; if (map[nr][nc] == '#') continue; int dist = abs(player.row - nr) + abs(player.col - nc); if (dist < minDist) { minDist = dist; bestDir = { dirs[d][0], dirs[d][1] }; } } return bestDir; }

这段代码里最值得学习的是“禁止掉头”逻辑：只排除与当前移动方向完全相反的方向，避免鬼魂卡在走廊里左右横跳。INT_MAX初始值保证必然选出一个方向，因为地图不会四周全是墙。如果要实现逃跑模式，把minDist改为maxDist即可。

碰撞检测方面，因为所有角色使用像素坐标绘制，但逻辑用格子坐标，最简单的做法是分别维护两种表示：格子坐标用于更新，像素坐标用于渲染。在渲染前根据格子坐标计算像素位置，再做矩形重叠测试：

bool overlapRect(float ax, float ay, float aw, float ah, float bx, float by, float bw, float bh) { return ax < bx + bw && bx < ax + aw && ay < by + bh && by < ay + ah; }

吃豆人和豆子的碰撞，豆子中心所在格子是否被玩家“吸收”，只需要检测玩家矩形中心和豆子中心的距离是否小于某个阈值，而不需要严格的矩形相交，因为豆子本身就是 8x8 像素。参数阈值我会取cellSize * 0.4f，这样在看着没碰到但实际已进入格子时能提前吃掉豆子，手感会很顺滑。如果用过大的阈值，玩家会还没靠近就吃掉，显得作弊。

5. DirectX 11 吃豆人最常见的 4 个翻车现场

5.1 现象：豆子和角色上下颠倒，墙壁位置全反

很多人第一次用 D3D11 渲染 2D 时，屏幕上的贴图是上下颠倒的。原因并不玄学：Direct3D 的剪裁空间和纹理采样坐标，都没有统一约定“屏幕左上角”。当你把原本用于屏幕左下角为原点的顶点 y 同时用在 HLSL 的SV_Position时，v 坐标方向就会有一个隐含的反转。

解决：确认你的纹理坐标约定。我统一写成左上角为 uv 原点 (0,0)，并且正交投影矩阵翻转 y 轴，代码见 3.3。如果你看到 y 翻转，只需要把proj改成XMMatrixOrthographicLH(width, -height, ...)或者修改世界矩阵，在 y 轴乘以 -1。具体改哪个，取决于你是要在数学坐标系（y 向上）里做逻辑，还是在窗口坐标系（y 向下）里做逻辑。吃豆人游戏逻辑建议直接用窗口坐标系，整个世界都在屏幕左上角，直觉最舒服。

5.2 现象：纸张纹理 + 白色豆子，半透明边缘发白

用 PNG 做豆子贴图时，你会发现画面边缘有一圈白边。主因是纹理格式和混合状态不一致。如果你把一张 RGBA PNG 载入DXGI_FORMAT_R8G8B8A8_UNORM，通常没问题；但如果原图带 alpha，而你没有创建合适的混合状态，默认的 D3D11 state 是对 alpha 零处理的，白边就出来了。

解决：创建ID3D11BlendState：

D3D11_BLEND_DESC bd = {}; bd.RenderTarget[0].BlendEnable = TRUE; bd.RenderTarget[0].SrcBlend = D3D11_BLEND_SRC_ALPHA; bd.RenderTarget[0].DestBlend = D3D11_BLEND_INV_SRC_ALPHA; bd.RenderTarget[0].BlendOp = D3D11_BLEND_OP_ADD; bd.RenderTarget[0].SrcBlendAlpha = D3D11_BLEND_ONE; bd.RenderTarget[0].DestBlendAlpha = D3D11_BLEND_ZERO; bd.RenderTarget[0].BlendOpAlpha = D3D11_BLEND_OP_ADD; device->CreateBlendState(&bd, &blendState); context->OMSetBlendState(blendState.Get(), nullptr, 0xffffffff);

参数里最有价值的是SrcBlend = SRC_ALPHA和DestBlend = INV_SRC_ALPHA，这是最标准的 alpha 混合。若你的贴图中不含 alpha 通道，只是 BGR，那大概率是美术资源导出的问题，而不是代码问题。另一个隐藏参数是SampleMask，如果不是 0xffffffff 会导致奇怪半透明效果，很多老代码会忽略。

5.3 现象：纹理加载失败，但文件路径明明存在

CreateDecoderFromFilename返回0x80070003（路径不存在），但资源文件就在 exe 同级的 assets 目录里。原因极有可能是工作目录不是 exe 所在目录。当你从 Visual Studio 调试启动时，默认工作目录是工程目录，而不是输出目录。所以相对路径 “assets/map.png” 自然找不到。

解决：在代码里不做相对路径拼接，而是用模块路径。获取 exe 路径再拼资源路径：

wchar_t buffer[MAX_PATH]; GetModuleFileNameW(nullptr, buffer, MAX_PATH); std::wstring baseDir = buffer; baseDir = baseDir.substr(0, baseDir.find_last_of(L"\\/")); std::wstring texPath = baseDir + L"\\assets\\map.png";

这样无论是调试还是双击 exe，资源路径都稳定。如果你用 CMake 的POST_BUILD拷贝资源，exe 目录和资源目录一致性就更有保障。这是解决所有 DirectX 项目资源加载问题的通用后悔药。

5.4 现象：碰撞检测时灵时不灵，幽灵穿墙频繁

吃豆人和墙碰撞靠格子判断，理论上不会穿墙，但如果你采用了更“精致”的像素移动，就可能在每帧Update里一次跨越多个格子。正常情况角色按 fixedStep 移动，速度太快、格子太小时就可能跳过墙线。比如在 80 帧的调试窗口下，速度cellSize * 8，每帧移动约 2.4 像素，而墙的碰撞边界只有 1 像素，就会漏检。

解决：为移动做细分。把一步拆成多个小步，每一小步执行碰撞检测并停止：

float stepTotal = speed * fixedStep * cellSize; while (stepTotal > 0.0f) { float step = min(stepTotal, cellSize * 0.3f); float nextX = position.x + dir.x * step; float nextY = position.y + dir.y * step; // 检查 nextX/nextY 所在格子是否撞墙 if (canMoveTo(nextX, nextY)) { position.x = nextX; position.y = nextY; } else { break; } stepTotal -= step; }

这里的关键参数是cellSize * 0.3f，即每步最多移动格子的三分之一，保证不会跨格。如果你直接限制最大速度，也可以避免它，但细分步长更稳定。顺着这条路做下来，你还会发现幽灵在病死路口的转向不自然，因为 AI 只选择最近曼哈顿距离，而非考虑前方路段是否需要回头。这时可以结合“当前格只能前进或转弯”限制，让幽灵回到经典吃豆人的行为风格。

6. 调试、扩展与让项目真正变成产品的落地技巧

当你跑通第一版之后，值得花时间做的事情有三件：调试、批处理、地图数据化。

用 Visual Studio 的“图形诊断”功能可以逐帧捕获画面，查看每个 draw call 绑定了哪些资源。这是 DirectX 11 调试最重要的入口。如果你之前没开启调试层，在D3D11CreateDeviceAndSwapChain的flags参数里加上D3D11_CREATE_DEVICE_DEBUG，IDE 的输出窗口会实时打印错误信息，比如“D3D11 ERROR: ID3D11DeviceContext::Draw: Input Assembler 没有绑定顶点缓冲区”。这个信息比黑屏直接得多。

批处理是 2D 游戏性能的分水岭。吃豆人地图最多不到 200 个豆子，如果每个豆子都单独Draw(4,0)，就是 200 次 draw call。D3D11 单帧 draw call 多了会明显吃 CPU。常见做法是把地图中所有豆子收敛到一个顶点缓冲区，一次性传入所有四边形的顶点和 uv，然后一次绘制。这样豆子的全部变化只是顶点位置不同，纹理全部相同。你可以维护一个std::vector<SpriteVertex>，每次地图更新后UpdateSubresource重建顶点缓冲，但吃豆人豆子只在被吃掉时消失，所以也可以不重建，而把消失豆子的 uv 设置为一个透明区域，一次性绘制整张地图。

地图数据化是接下来最值得投入的改动。把 4.2 里的char map[15][20]从 C++ 源码移到assets/map.txt，游戏启动时用文本流读取。一个简单的std::ifstream就能完成，但要注意换行符\r在 Windows 下会被读进字符串，导致地图错位。读每行后手工去掉\r是必须的：

std::string line; std::getline(ifs, line); if (!line.empty() && line.back() == '\r') line.pop_back();

地图文件还能顺便承载关卡编号，比如在文件开头写一个数字，代表能量豆数量或幽灵速度，这套方案是课程项目常见扩展方向。有了外部关卡，后续加新地图、调整难度、甚至写地图编辑器都方便。

音效方面，DirectX 11 不负责音频，常见的做法是 XAudio2 或直接调第三方库。对吃豆人来说，播放豆子被吃掉和吃到能量豆的两段 wav 足够。它的初始化思路类似 D3D11 设备创建，也需要一个设备对象和一个声音源缓冲，但不牵涉渲染管线。如果你没有做过 XAudio2，可以先不碰，图形项目没有音效也能跑通。

最后说一个我自己的习惯：游戏循环里加一个帧率计数器，每秒钟把 FPS 写到窗口标题栏。别看这很简单，它能最快暴露“逻辑更新耗时还是渲染耗时”。当我发现 Debug 模式 FPS 只有个位数，而 Release 模式很流畅时，就知道是断点调试期间构建的 Debug 没有优化，而不是代码本身的问题。和 DirectX 11 相处越久越能体会，黑屏和闪烁大半是状态设置问题，不是代码逻辑问题。当初我因为没有理解垂直同步和Present参数，导致一台 144Hz 显示器上豆子消失速度加快，最后用IDXGIOutput::GetFrameStatistics才搞清楚。希望这些接地气的填坑记录能帮你少走几步，如果哪天你解压了类似的项目，先看构建脚本，再抓一次帧，剩下的多半能在半小时内跑通。希望帮到你。

本文还有配套的精品资源，点击获取