BIT-TSP 实验一这个题目放在外面可能不太起眼但真正动手做过的人都知道MiniEngine 这一步要是走稳了后面整个课程都会顺很多。我当年做这个实验的时候第一反应是“不就搭个框架吗”结果真正开始写才发现窗口、主循环、数学库、渲染设备初始化、资源管理每一块单独看都不难拼在一起却处处是坑。这篇文章就把我做实验一的全过程、踩过的坑、以及每一步为什么要这么设计讲清楚给后面做这个实验的同学一个参考也方便有基础的人快速领会 MiniEngine 的底层骨架是怎么立起来的。1. 实验整体设计与思路拆解1.1 为什么叫“起航与基石构建”实验一的名称写得很直白起航意思是整个 MiniEngine 的代码从这一步开始累积基石构建说明这阶段的核心目标不是做出花哨的渲染效果而是把引擎的基本骨架立起来。MiniEngine 这个名字本身就暗示了这是一个“麻雀虽小五脏俱全”的教学引擎它不会像商业引擎那样堆满功能而是把最核心的模块用最直接的方式实现出来让你能一眼看穿每一行代码在干什么。这一步在整个 BIT-TSP 课程体系中的定位相当于“地基中的地基”。后续实验里要加入的渲染管线、资源管理、场景系统、UI 模块全都依赖这个阶段搭好的平台层和核心层。如果窗口系统不稳定、主循环没有处理好时间步长、数学库的坐标系约定不统一后面每一节课都得回来打补丁。从实际教学角度看这个实验还有一个隐性目标让你从“写算法题”的思维切换到“写工程”的思维。算法题关心的是输入输出和复杂度而引擎开发关心的是模块边界、生命周期、错误处理、扩展性。MiniEngine 实验一本质上就是让你开始用工程师的方式去思考代码组织而不是简单地把功能堆在一起跑起来就算完。我个人理解实验一评判的高分标准并不是“实现了多少个功能”而是“模块划分是否清晰”“后续扩展是否方便”“代码是否有自我诊断能力”。“起航”这两个字意味着这门课默认你具备了 C 基础和基本的图形学概念但还不要求你有完整的游戏引擎认知因此实验一的内容会刻意控制在“够用且完整”的范围不会一次性抛出太多超出认知的概念。1.2 架构选型模块划分背后的思考MiniEngine 的架构在实验一阶段通常被划分为几个相对独立的模块每个模块只负责一件事。标准的划分方式大致是这样的平台层负责操作系统相关的初始化包括窗口创建、消息处理、输入事件采集还可能包含时间查询接口。核心层提供与平台无关的基础设施包括数学库、日志系统、断言机制、内存辅助工具。渲染层封装图形 API包括设备创建、交换链管理、着色器编译、渲染状态设置、基础绘制接口。工具层作为可选模块提供辅助调试工具例如帧率统计、渲染状态查看面板、资源浏览器。这个划分不是拍脑袋定出来的它遵循了游戏引擎设计中常见的“依赖倒置”原则上层模块只依赖抽象接口不直接依赖具体平台 API。这样做的直接好处是后续如果需要在 Windows 和 Linux 之间切换平台层只需要更换一套实现上层代码基本不需要改动。选型上还有一个关键决定用什么语言和图形 API。实验一通常默认 C因为后续的渲染、资源管理、指针生命周期控制都需要 C 级别的控制力如果选 Java、C#虽然开发效率高但少了底层内存控制的训练也不便于理解图形 API 的原始调用方式。图形 API 的选择则取决于课程配置常见的有 DirectX 11、OpenGL 或更新的 DX12/Vulkan。MiniEngine 定位为教学引擎一般不会直接上 Vulkan因为复杂度太高容易把教学重点从引擎设计转到图形 API 的繁琐细节上。我自己的做法是遵循“最小依赖原则”不引入第三方 GUI 库不引入现成的数学库所有的窗口、消息循环、数学运算全部自己实现。这样虽然前期多写几百行代码但对理解引擎底层运作特别有帮助。很多同学习惯性地把 glm、GLFW 直接引入项目短时间内确实省事但到了测试任务里要求你改内部实现时就会发现自己对底层一无所知。1.3 这个阶段的设计取舍与避坑方向MiniEngine 实验一最大的设计取舍在于“够用就好但留好扩展位”。比如数学库第一版通常只需要向量、矩阵、四元数的基本运算不需要实现完整的光栅化插值工具又比如渲染器第一版只需要能初始化设备、清屏、画一个三角形不需要立刻支持材质和光照。这样做的好处是降低上手门槛。如果你一开始就想着把引擎做到“完整”很容易陷进资源管理、异步加载、多线程渲染等复杂的工业化问题里实验一做半年都做不完。相反先把核心骨架跑通后面每一个实验都在这个骨架上加一块砖每次的增量都比较可控遇到问题也能快速定位是新代码的问题还是旧骨架的问题。取舍的另一面是必须预留扩展接口。比如绘制接口不妨一开始就定义成“绑定顶点缓冲、设置着色器、提交绘制命令”这种通用流程而不是直接写死“绘制一个三角形”。资源管理模块哪怕先只做一个纹理加载也建议设计成“资源 ID 资源管理器”的模式而不是把资源对象散落在全局变量里。后面要加载模型、加载多张贴图的时候你会感谢自己当初的设计。避坑方向方面我提醒自己特别注意三件事不要过早优化。实验一阶段的主循环、数学运算完全没有必要引入多线程和 SIMD 指令先把可读性做好。不要混合坐标系约定。左手还是右手坐标系、行主序还是列主序一开始就要定死并且写进文档否则后面矩阵运算全部乱套。不要忽略错误诊断。窗口创建失败、设备丢失、着色器编译出错这些错误都应该有明确的输出手段哪怕只是一个弹窗和一句日志也比静默崩溃强一万倍。2. 核心细节解析与实操要点2.1 窗口系统从 Win32 消息循环说起MiniEngine 的窗口系统在实验一阶段最常用的实现方式是原生 Win32 API。这一步没有太多魔法核心流程是注册窗口类、创建窗口、进入消息循环。消息循环是整个引擎的“心脏”它不断从操作系统接收消息然后决定是退出程序、处理输入还是继续渲染。这里最容易犯的错误是在消息循环里直接调用渲染函数然后发现画面卡顿严重或者窗口拖动时渲染暂停。原因在于 Windows 的消息循环是协作式的如果你在 WM_PAINT 或者 WM_SIZE 等消息处理函数里做大量计算整个窗口的消息响应就会被阻塞。正确做法是消息循环只负责收集消息、转换消息、分发消息渲染相关的操作放在循环体内的固定位置每一帧都执行一次不依赖消息到达。我在实现时采用的 Win32 消息循环大致是这样的MSG msg {}; while (msg.message ! WM_QUIT) { if (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) { TranslateMessage(msg); DispatchMessage(msg); } else { EngineFrame(); // 非阻塞时执行一帧渲染与逻辑更新 } }PeekMessage 与 GetMessage 的区别很关键。GetMessage 在消息队列为空时会阻塞线程导致引擎无法继续渲染PeekMessage 则立即返回让引擎在没有消息时也能持续产出画面。对游戏引擎来说PeekMessage 是更合理的选择因为它保证了“游戏永远在跑事件来了优先响应”的执行模型。窗口消息处理函数 WndProc 我习惯只做最小操作关窗时发送退出信号窗口尺寸变化时保存宽高并标记需要重建交换链其余消息一律丢弃。这样做一方面让窗口逻辑保持简单另一方面也把输入处理交给后续的输入模块不在系统消息层面堆业务逻辑。2.2 数学库坐标系、存储顺序与内存对齐数学库是 MiniEngine 的基石很多同学在这个模块吃了大亏不是因为算不出来而是因为约定不统一。写数学库之前必须先定几件事坐标系左手还是右手。DirectX 系通常用左手OpenGL 传统上用右手。MiniEngine 如果是纯 DX 路线直接用左手即可。矩阵存储行主序还是列主序。这个决定了矩阵乘法怎么写、向量是行向量还是列向量、矩阵传入着色器的内存布局长什么样。旋转约定欧拉角、轴角、四元数各自的使用场景。避免在旋转矩阵部分混淆。以常见的行主序 行向量约定为例变换一个顶点的写法是 v v * M其中 v 是行向量M 是变换矩阵。此时平移分量存在矩阵的第四行。而如果采用列主序 列向量约定写法变成 v M * v平移分量存在第四列。两种约定没有优劣之分但代码里必须严格统一否则从数学推导到代码实现完全是两套逻辑。内存对齐也是一个容易被忽视的点。现代 CPU 对浮点数据的访问存在对齐要求图形 API 的常量缓冲区往往需要 16 字节对齐如果你在结构体里写了 float m[4][4] 然后直接 memcpy 到常量缓冲某些环境下会崩溃或者性能骤降。C 的 alignas(16) 可以很轻松地解决这个问题但需要你在设计数学库的第一天就注意。四元数也是实验一不见得会用到、但必须写好的模块。我建议提前实现四元数乘法、旋转向量、转矩阵、从欧拉角构造四元数这几个接口即使暂时没场景用也要保证正确性和测试覆盖。旋转相关的 bug 是最难调试的因为往往表现为“绕了一圈角度不对”“物体被压扁了”一旦数学库有隐患排查代价极高。2.3 渲染设备初始化交换链、渲染目标与视口MiniEngine 的渲染层在实验一阶段的核心任务是完成渲染设备初始化并成功输出一帧画面。以 DirectX 11 为例初始化链条大致是创建设备和上下文、创建交换链、创建渲染目标视图、设置视口、清屏、Present 呈现。创建设备和交换链的环节最容易出现的错误是参数配置不合理。常见的坑包括交换链缓冲数量设置成 1导致画面闪烁或帧延迟异常Usage 标志没有加 RenderTargetOutput导致创建失败多层采样设置成大于 1 却没有准备对应的 MSAA 渲染目标导致运行时报错。交换链格式对画面影响也很大。最常见的格式组合是 DXGI_FORMAT_R8G8B8A8_UNORM 作为后台缓冲格式配合 DXGI_FORMAT_D24_UNORM_S8_UINT 作为深度模板缓冲格式。这个组合覆盖了绝大多数教学场景颜色精度足够深度模板也齐全。部分同学喜欢用 R16G16B16A16_FLOAT追求高动态范围但实验一阶段不太需要反而浪费带宽和内存。初始化完成后的第一帧通常先做清屏再调用 Present。这一步看似简单其实是检验整个初始化链条是否正确的唯一标准。如果屏幕上出现了纯色画面说明设备创建、交换链、渲染目标视图、Present 调用全部正确如果黑屏、弹错、崩溃沿着这个链条逐项排查即可。2.4 日志与断言引擎的自我诊断能力很多同学不理解为什么实验一就要求写日志模块等到程序崩了找不到出错位置时才后悔。MiniEngine 的日志系统不需要做得像大型引擎那样复杂只要能满足几个基本需求向控制台和文件同时输出带时间戳的日志。区分 LogLevelInfo、Warning、Error、Fatal方便过滤。支持格式化输出调用时类似 printf。在关键错误处触发断言中断程序并提示上下文。断言的实现也能极其简单核心是“条件不满足时主动暴露问题”。比如#define ME_ASSERT(condition, message) \ do { \ if (!(condition)) { \ LogFatal(message); \ __debugbreak(); \ } \ } while (0)这段宏看似简单实际价值非常大。引擎里每一个假设都可以用断言固化下来例如“顶点缓冲不能为空”“设备指针不能为空”“索引值不能越界”。这些断言相当于把代码中的潜规则变成了可执行的检查一旦未来某次修改破坏了假设立刻就能发现而不是等到渲染结果诡异时才去猜测。我在实验一里坚持“日志 断言”双轨策略日志记录程序的运行轨迹断言拦截违反前提条件的错误。两者配合能让调试效率提升非常多。很多同学喜欢遇到问题就直接打断点逐行跟踪效率不高有了充分的日志输出很多时候看一眼最后一条日志就能锁定问题范围。3. 实操过程与核心环节实现3.1 搭建项目骨架工程目录与构建脚本动手写代码之前先把工程结构理顺。MiniEngine 实验一的项目一般遵循“按模块分目录”的方式避免所有源码堆在一个文件夹里。我常用的目录结构是这样的MiniEngine/ src/ Platform/ // Windows 窗口、消息循环 Core/ // 数学库、日志、断言 Render/ // D3D 初始化、绘制逻辑 EngineApp.cpp // 引擎主流程、帧循环 tests/ MathTests.cpp // 数学库基础功能验证 external/ // 第三方库可选 CMakeLists.txt如果你用 CMake 管理项目一个精简的配置可以长这样cmake_minimum_required(VERSION 3.10) project(MiniEngine CXX) add_library(me_core STATIC src/Core/Math.cpp src/Core/Log.cpp ) add_library(me_platform STATIC src/Platform/Window.cpp ) add_library(me_render STATIC src/Render/D3D11Renderer.cpp ) add_executable(Test01 src/EngineApp.cpp ) target_link_libraries(Test01 PRIVATE me_core me_platform me_render)这里我没有把窗口直接做成 dll全部用静态库组合理由很简单实验一阶段完全不需要动态库的粒度静态库已经足够提供模块隔离链接也简单。等到后期引擎膨胀到需要独立插件体系时再拆动态库完全是顺理成章的事情。工程骨架的另一个重点是“可复现构建”。尽量不要依赖本机某个固定的 SDK 路径所有依赖尽量通过 CMake 的 find_package 或者手动配置在仓库里维护。这样即使换了电脑、换了教室的机器也能很快把工程跑起来。学期过程中如果你和队友共用代码仓库可复现构建会省掉无数“我这边编译不过”的扯皮。3.2 主循环与时间步进可变步长还是固定步长实验一阶段的帧循环建议直接从“可变步长 每帧计算 DeltaTime”开始。最简单的实现就是利用计时器查询当前帧与上一帧的时间差然后把这个差值传递给更新函数。这个方案对教学场景足够而且代码量少逻辑直观。一个常见的简化实现如下LARGE_INTEGER freq, start, end; QueryPerformanceFrequency(freq); QueryPerformanceCounter(start); while (running) { QueryPerformanceCounter(end); float deltaTime (float)(end.QuadPart - start.QuadPart) / freq.QuadPart; start end; InputUpdate(); SceneUpdate(deltaTime); RenderUpdate(); }这里需要注意的是时间步长不要无限大。当窗口被拖动、调试器断点命中、或者程序短暂卡顿后deltaTime 可能会变得非常大导致物理模拟瞬间飞出去。适当做一次钳制通常很有用float deltaTime min(rawDeltaTime, 0.05f);很多教程会把固定时间步长作为推荐方案这在物理引擎中更普遍。但实验一阶段如果你还没写物理系统不建议过早引入固定步长更新或插值渲染。那些优化留给后续真正需要时再做前期保持“每帧更新一次时间随帧率变化”这种朴素但正确的模型反而更容易验证场景逻辑。时间步长还有一个细节是首帧问题。第一帧的 deltaTime 如果按照初始值 0 计算会出现第一个更新步长特别大的情况稳妥的做法是初始化 lastTime 为当前时间第一帧自然得到接近 0 的 deltaTime避免跳变。3.3 渲染器初始化参数详解从设备到视口渲染器的初始化参数是实验一的重头戏这里面的每个参数几乎都有讲究。以 D3D11 创建设备为例有几个关键点值得展开说功能级别D3D_FEATURE_LEVEL_11_0 是绝大多数现代机器都能支持的级别如果担心兼容性差可以允许回退到 10_0 甚至 9_3但建议默认 11_0。驱动类型默认用 HARDWARE只有硬件不支持时才用 WARP 软件渲染兜底。实验一阶段如果直接选 WARP某些机器上会出现帧率极低的情况还容易掩盖硬件真实能力。标志位DEBUG 标志在 Debug 构建下强烈建议打开它会给你的渲染调用提供非常详细的校验信息。Release 模式下则关闭避免性能损失。交换链BufferCount 建议设为 2也就是常见的双缓冲。Multi-Sample 参数可以暂时设 1 关闭 MSAA后续做抗锯齿再开启。创建完交换链后下一步是创建渲染目标视图。这里要格外注意“交换链缓冲区的引用计数”问题在创建 RTV 后后台缓冲区接口上最好执行一次 Release否则对象一直被引用交换链在 Resize 时可能报错。很多同学在这里遇到 resize 窗口后设备丢失或者黑屏其实就是引用泄漏导致老资源没被释放。设置视口时宽高必须和当前交换链匹配。拖动窗口改变大小时不仅需要更新后台缓冲区大小还要重新创建 RTV、重新设置视口。一个常见的错误是只改交换链大小忘掉更新视口结果画面只渲染了窗口的一部分或者全部空白。下面是初始化完成后清屏并呈现的调用序列float clearColor[4] { 0.2f, 0.3f, 0.4f, 1.0f }; context-ClearRenderTargetView(rtv, clearColor); context-OMSetRenderTargets(1, rtv, nullptr); context-RSSetViewports(1, viewport); swapChain-Present(1, 0);这段代码的顺序也是有讲究的。OMSetRenderTargets 是绑定渲染目标必须在绘制之前完成清屏可以提前做但通常紧跟在绑定之后理论上效率和逻辑一致性都更好。Present 的同步间隔参数设 1也就是垂直同步避免画面撕裂如果你觉得帧率被锁 60 影响测试可以设 0但前提是你理解关闭 VSync 带来的撕裂代价。3.4 绘制第一个三角形从输入装配到着色器实验一画三角形的过程不只是一句“Draw(3, 0)”那么简单。你要把顶点数据准备好把顶点着色器和像素着色器编译好把它们装配成渲染管线然后才能真正调用绘制。顶点准备的坑主要在坐标上。MiniEngine 使用左手坐标标准 D3D 的投影变换会把 z 范围映射到 [0, 1]这和 OpenGL 的 [-1, 1] 不同。很多从 OpenGL 转过来的同学直接抄旧代码发现三角形出现位置不对或者被裁剪掉了基本就是坐标系和深度范围的问题。一个最简单的三角形顶点数组可以是这样struct Vertex { float x, y, z; float r, g, b, a; }; Vertex vertices[] { { 0.0f, 0.5f, 0.0f, 1.0f, 0.0f, 0.0f, 1.0f }, { 0.5f, -0.5f, 0.0f, 0.0f, 1.0f, 0.0f, 1.0f }, { -0.5f, -0.5f, 0.0f, 0.0f, 0.0f, 1.0f, 1.0f }, };这里 z 设为 0投影后落在近裁剪面附近适合初始调试。如果你把 z 设成 0.5在某些投影参数下会被深度测试挡住画面里什么都看不到而实际上代码逻辑完全正确。所以第一次画三角形时最好先不启用深度测试等确认三角形能正常显示后再逐步加入深度缓冲和深度测试这样定位问题更方便。着色器编译方面我建议两种方式结合Debug 下从源码实时编译方便修改和日志输出Release 下尽量用编译好的 cso 缓存缩短启动时间。但实验一阶段完全可以直接从源码编译省去额外的离线编译步骤。调试时最实用的工具是 D3D 的 Debug Layer 信息。如果你在创建设备时开启了 DEBUG 标志所有错误信息都会通过输出窗口打印出来包括“顶点着色器输入签名不匹配”“像素着色器编译失败”这类常见问题这些信息远比“程序崩了”要直观得多。4. 常见问题与排查技巧实录4.1 窗口创建与消息循环问题窗口黑屏或者根本不显示是实验一里出现频率最高的问题。第一个要查的是窗口过程函数的处理是否正确。如果你没写 WM_DESTROY 的处理窗口关闭时消息循环可能无法收到 WM_QUIT程序表现为“点 X 关不掉”。还有一个常见错误是注册窗口类时用错实例句柄导致创建失败。消息循环的设计也经常出问题。比如你把 PeekMessage 的第二个参数窗口句柄传成了 NULL导致程序接收不到子窗口或控件的消息或者你没有写 TranslateMessage导致键盘输入无法转换成字符消息。这些问题不一定当场显性但会在后续实验加载更多输入时集中爆发。排查消息循环的另一个技巧是确认 WM_SIZE 消息触发时是否正确更新了交换链尺寸。很多同学只在创建时设置了一次视口窗口一放大画面就只剩一个角这基本可以断定是 WM_SIZE 处理缺失或处理不完整。4.2 渲染结果异常黑屏、花屏与三角形缺失三角形没出现最直接的原因通常有三种顶点数据没有正确上传到 GPU、着色器编译失败、深度/裁剪设置挡住了一切。顶点数据上传方面最常见的错误是顶点布局描述InputLayout与顶点着色器输入签名不匹配。D3D11 对此会很严格任何一个语义名称对应不上都会导致创建失败。排查的方法是确认 InputLayout 的语义名和语义索引完全一致比如 POSITION、COLOR 这些名字不要拼错。着色器编译失败有时候不容易发现因为你可能只是没检查编译结果。大多数图形 API 都会返回编译错误日志其中包含行号和具体错误描述。建议在 Debug 模式把编译日志用日志模块输出而不是吞掉错误。只忽略编译结果的话后续创建 PSO 或管线状态时的报错往往和真正的根因毫无关系排查起来非常崩溃。花屏则更多是数据容量和步长的问题。比如你给顶点缓冲分配了 3 个顶点但创建缓冲时设置的 ByteWidth 只有 sizeof(Vertex) * 2后半个顶点读到的就是未初始化的内存画面上自然出现诡异的三角形延伸、颜色闪烁。每次创建顶点缓冲时都核对一遍 顶点个数、步长、缓冲大小 这三个数值。三角形缺失还有一个容易被忽略的原因裁剪和背面剔除。如果顶点按顺时针排列而在你的配置里启用了顺时针剔除三角形会被整体剔除。幸运的是实验一的绘制函数通常默认禁用背面剔除但如果某次你“顺手”打开了它又正好把顶点顺序搞反了就会出现“明明代码没问题三角形就是不显示”的假象。4.3 数学库与坐标体系的“灵异”现象旋转错乱、平移方向反了、物体被斜向拉伸这些问题的根源多半不是算法复杂度而是约定混乱。一个典型的例子是行主序和列主序的混淆。如果你在 CPU 端以行主序编写矩阵但创建常量缓冲区时忘记转换GPU 端拿到的是转置后的矩阵最终效果就是旋转方向颠倒、平移量跑偏整体看起来像是“反射扭曲”的效果。更隐蔽的是如果你从网上抄一段代码那套代码本身是列主序的混进你的行主序框架里你只改部分代码反而更乱。解决这类问题的方法只有一个在任何矩阵传给 GPU 之前先用一个简单的已知变换测试。比如创建一个只包含 X 方向平移 1.0 的矩阵把这个矩阵应用到顶点 0,0,0 上预期得到 1,0,0。如果结果不是立刻检查是矩阵构造的函数顺序有问题还是常量缓冲的转置处理有问题不要继续叠加其他变换。数学库的另一个坑是浮点精度累积。引擎跑久了之后场景中的物体会缓慢漂移甚至原地抖动。尽管实验一场景很简单最好从第一天起就养成习惯不要把位置信息反复累加在小浮点数上而是保留初始值并乘上模型矩阵或者定期重置基准点。这是引擎工程里非常重要但容易被忽略的细节。4.4 调试工具与工程化问题速查Debug 与 Release 的行为不一致也是个常见问题。表现常常是 Debug 时帧率很低但画面正常Release 下却崩溃或者颜色异常。最常见的原因是未初始化变量Debug 构建会填入固定值让错误可预测Release 构建直接使用栈上剩余数据导致随机性错误。另一个工程化经典问题是平台工具集不一致。你在自己机器上用 MSVC v143 编译队友用 v142链接时就会出现一大堆“无法解析的外部符号”。建议在工程说明里写清楚编译器版本或者在 CMake 里固定工具集版本。我习惯在提交代码前做一次“纯净环境构建”测试也就是把项目复制到一个全新目录只依赖仓库内的文件和文档完成编译构建不依赖本机额外配置。这个过程能暴露绝大多数环境相关问题而且对团队协作的帮助极大。下面整理一张实验一阶段常见的错误速查表供你遇到问题时快速对照定位。现象最常见根因处理方式窗口创建失败窗口类名未注册或注册冲突检查 RegisterClass 返回值确认类名唯一性窗口点关闭后进程不退出WndProc 中未处理 WM_DESTROY在 WM_DESTROY 里调用 PostQuitMessage画面黑屏但无报错交换链未 Present 或后台缓冲未清屏检查呈现调用与 ClearRenderTargetView 是否执行画面只有窗口左上角有内容视口尺寸未跟随窗口尺寸更新在接收 WM_SIZE 后重建 RTV 与视口三角形不可见顶点顺序被剔除或深度范围异常临时禁用背面剔除与深度测试逐步排查绘制结果颜色与顶点色不符着色器输入语义顺序不匹配逐项检查 InputLayout 与 Shader 输入签名Release 崩溃但 Debug 正常未初始化变量或运行库不一致初始化所有变量统一运行库设置帧率固定在 30/60 不达预期VSync 开启或 Present 参数为 1需要测性能时可暂时设 Present(0, 0)窗口 resize 后设备丢失旧 RTV 未被释放释放所有与后台缓冲区关联的引用再重建4.5 个人经验坚持三个好习惯做实验一的过程中我自己养成了一套基础检查流程虽然后面做复杂功能时也在不断补充但核心的这三件事基本没变过。第一每次启动引擎时开启调试层并把日志输出到文件。不要只在控制台窗口上看输出控制台默认缓冲不大滚动之后前面信息就丢了。写到文件里崩溃后还能回头翻完整日志。第二每实现一个小模块立刻做最小验证。比如写完矩阵乘法写两行测试代码验证单位矩阵和连续变换的结果写完窗口系统先跑一个只显示纯色的循环不要等全部模块写完再一起调。第三提交代码前做一次全量重构清理无效注释和无用的后门函数。MiniEngine 会伴随你整个学期代码只会越加越多实验一阶段的整洁程度决定了后面维护效率的上限。如果把这三个习惯坚持下来你会发现实验一带来的收获远不止“能画个三角形”这么简单。它真正训练的是你构建一个长期演进代码库的意识这种能力在课程结束后做真实项目时依然受用。