首页/资讯中心/详情

从MFC俄罗斯方块源码解析游戏编程核心：碰撞检测、双缓冲与消息循环

从MFC俄罗斯方块源码解析游戏编程核心：碰撞检测、双缓冲与消息循环
📅 发布时间：2026/8/3 18:49:15

1. 项目概述：从经典游戏到现代编程的桥梁

提起俄罗斯方块，几乎无人不知。这个诞生于上世纪80年代的简单游戏，却蕴含着令人着迷的数学之美和编程逻辑。对于许多像我一样，从Visual C++ 6.0那个“蓝底白字”的IDE时代走过来的开发者来说，俄罗斯方块几乎是学习Windows图形编程和游戏逻辑的“第一课”。它不像大型3A游戏那样复杂，却麻雀虽小五脏俱全，涵盖了图形绘制、键盘事件响应、定时器控制、碰撞检测、游戏状态管理等核心概念。今天，我们就来深入剖析一个基于经典Visual C++环境（特别是MFC框架）的俄罗斯方块项目源代码，并探讨如何将其核心思想迁移到现代开发环境中进行实践。这不仅仅是一次怀旧之旅，更是理解游戏编程底层逻辑、锻炼工程化思维的最佳实践。无论你是想重温经典，还是希望为学习更复杂的游戏引擎（如Unity、Unreal）打下坚实基础，这个项目都能提供宝贵的经验。

2. 项目整体设计与架构思路拆解

2.1 核心需求与功能模块解析

一个完整的俄罗斯方块游戏，其核心需求可以分解为几个相互独立又紧密协作的模块。理解这些模块，是读懂任何版本源代码的前提。

首先，是游戏世界（Game World）的建模。这通常是一个二维网格，比如10列宽、20行高。每个格子只有两种状态：被方块占据或为空。这个网格就是所有游戏逻辑发生的舞台。在代码中，它通常被实现为一个二维数组（如int board[20][10]），用不同的整数值（如0代表空，1-7代表不同颜色的方块）来表示状态。

其次，是方块（Tetromino）系统。俄罗斯方块有7种基本形状（I, J, L, O, S, T, Z）。每个形状由4个小方块（Block）组成。系统需要管理当前正在下落的“活动方块”（Current Piece）和下一个即将出现的“预览方块”（Next Piece）。方块的核心属性包括：形状类型、旋转状态（0-3，代表4个方向）、以及其在游戏网格中的坐标（通常是其左上角或某个中心点的坐标）。在经典实现中，这7种形状的初始坐标和旋转后的坐标变换表（Rotation Table）会被预先定义好，这是实现旋转逻辑的关键。

第三，是游戏循环与状态机。游戏处于不同的状态：开始、进行中、暂停、游戏结束。游戏主循环（通常由Windows定时器WM_TIMER驱动）负责在“进行中”状态下，周期性地让当前方块下落一行（重力）。同时，它需要实时响应用户的键盘输入（左、右、下、旋转、瞬间下落）。这个循环是游戏的心脏。

第四，是碰撞检测系统。这是游戏逻辑中最核心的部分。在方块尝试移动（左、右、下）或旋转之前，必须进行碰撞检测。检测的内容包括：方块是否与网格边界碰撞？方块是否与网格中已固定的方块碰撞？如果检测到碰撞，移动或旋转操作将被阻止。当下落碰撞发生时，当前方块就会被“固化”到游戏网格中。

第五，是消行与计分逻辑。当一行被方块完全填满时，这一行需要被消除，上方的所有行整体下移。消除的行数越多，获得的分数加成越高（通常是1行100分，2行300分，3行500分，4行800分）。同时，随着分数的增加，游戏难度（方块下落速度）应逐步提升。

最后，是图形用户界面（GUI）。在Visual C++/MFC项目中，这通常通过GDI（Graphics Device Interface）在对话框或视图的客户区进行绘制。需要绘制的内容包括：游戏主网格、当前方块、预览方块、分数、等级、下一个方块预览等。

2.2 技术选型：为何是Visual C++与MFC？

你可能会有疑问：为什么是古老的Visual C++和MFC？在DirectX、OpenGL乃至各种游戏引擎大行其道的今天，学习这个组合还有意义吗？我的答案是：非常有意义，尤其是对于想深入理解Windows桌面程序原理和游戏底层逻辑的开发者。

选择Visual C++（特别是VC++ 6.0或VS2008等经典版本）的原因在于其“纯粹性”。它剥离了现代引擎提供的各种便利工具和高级抽象，迫使你亲手处理消息循环（Message Loop）、设备上下文（DC）、画笔（Pen）和画刷（Brush）。当你用Rectangle()和FillRect()函数一个个画出方块时，你对“绘制”这件事的理解会比调用一个DrawSprite()函数深刻得多。这种从零开始的构建过程，是理解计算机图形学基础的绝佳途径。

MFC（Microsoft Foundation Classes）框架则提供了构建Windows应用程序的骨架。它封装了原始的Win32 API，使窗口创建、消息映射、对话框设计变得相对容易。对于俄罗斯方块这样的项目，一个基于CDialog或CView的类就足以承载整个游戏。MFC的文档-视图架构虽然有些过时，但其事件驱动（消息响应）的编程模型，与现代GUI框架（如Qt、WinForms）乃至游戏引擎中的事件系统在思想上是一脉相承的。通过为WM_KEYDOWN,WM_TIMER,WM_PAINT消息编写处理函数，你能清晰地看到用户输入、时间流逝、屏幕刷新是如何驱动游戏运行的。

注意：现代实践通常不会用纯GDI和MFC开发新游戏，但这次分析实践的目的不是学习“最先进”的工具，而是掌握“最本质”的原理。理解了这些，你再去看Unity的Update()循环或Unreal的Tick机制，会有豁然开朗的感觉。

3. 核心代码模块深度解析

3.1 游戏数据模型与方块表示

让我们深入到代码层面。首先，我们定义一个核心的CGameBoard类来管理游戏网格。

class CGameBoard { private: static const int BOARD_WIDTH = 10; static const int BOARD_HEIGHT = 20; static const int EMPTY = 0; int m_grid[BOARD_HEIGHT][BOARD_WIDTH]; // 游戏主网格 int m_score; int m_level; int m_linesCleared; public: CGameBoard(); void Init(); // 初始化网格，全部置为EMPTY bool IsCellEmpty(int row, int col) const; void SetCell(int row, int col, int value); // value为0-7，0为空，1-7为方块颜色 int GetCell(int row, int col) const; // ... 其他方法，如消行检查、分数计算等 };

接下来是方块系统。7种方块的形状定义是项目的精髓。一种经典且高效的方法是使用“旋转表”。

// 定义7种方块类型 enum TetrominoType { TYPE_I, TYPE_J, TYPE_L, TYPE_O, TYPE_S, TYPE_T, TYPE_Z }; // 每个方块由4个小方块(blocks)组成，用相对于方块中心(或某个锚点)的坐标表示 struct Point { int x; int y; }; class CTetromino { private: TetrominoType m_type; int m_rotation; // 0, 1, 2, 3 代表4个旋转状态 Point m_position; // 方块在游戏网格中的位置（通常指某个参考点，如左上角或中心） Color m_color; // 旋转表：对于每种类型、每种旋转状态，存储4个方块的相对坐标 // 这是一个简化的示意，实际是一个三维数组或通过函数计算 static const Point m_rotationTable[7][4][4]; // [类型][旋转状态][第n个方块] public: CTetromino(); void SetRandomType(); // 随机生成一种方块 void Rotate(); // 旋转，本质是改变m_rotation，并查询旋转表获取新坐标 void Move(int dx, int dy); // 移动 Point GetBlockPos(int index) const; // 获取第index个小方块在游戏网格中的绝对坐标 // 碰撞检测辅助函数 bool IsValidPosition(const CGameBoard& board) const; };

这里的“旋转表”是关键。以I型方块（长条）为例，它有两种旋转状态（横和竖）。我们预先计算好这两种状态下，4个小方块相对于某个中心点的坐标。当调用Rotate()时，我们并不进行复杂的矩阵计算，而是简单地m_rotation = (m_rotation + 1) % 4，然后从m_rotationTable[m_type][m_rotation]中取出新的相对坐标。这种方式效率极高，且避免了旋转时可能出现的复杂边界问题（尽管O型方块旋转不变，但表里它的四种状态坐标都一样即可）。

3.2 游戏主循环与消息驱动架构

在MFC中，游戏主循环并非传统的while(true)循环，而是由Windows消息和定时器驱动。这是理解Windows编程的关键。

首先，在对话框初始化函数（如OnInitDialog）中，我们设置一个定时器：

SetTimer(1, 500, NULL); // 定时器ID为1，间隔500毫秒

然后，在消息映射中响应WM_TIMER事件：

BEGIN_MESSAGE_MAP(CMyTetrisDlg, CDialogEx) ON_WM_TIMER() ON_WM_KEYDOWN() ON_WM_PAINT() END_MESSAGE_MAP() void CMyTetrisDlg::OnTimer(UINT_PTR nIDEvent) { if (nIDEvent == 1 && m_gameState == STATE_PLAYING) { // 游戏核心逻辑：让当前方块下落一格 if (!MoveCurrentPieceDown()) { // 尝试下落，如果失败（碰到底部或固定方块） LockCurrentPiece(); // 锁定当前方块到网格 ClearFullLines(); // 检查并消除满行 SpawnNewPiece(); // 生成新方块 if (IsGameOver()) { // 检查游戏是否结束（新方块出生即碰撞） m_gameState = STATE_GAME_OVER; KillTimer(1); // 停止定时器 // ... 显示游戏结束信息 } } Invalidate(); // 请求重绘，触发OnPaint } CDialogEx::OnTimer(nIDEvent); }

Invalidate()函数是连接逻辑与渲染的桥梁。它并不立即绘制，而是向系统发送一个WM_PAINT消息，告诉系统“这个窗口区域需要重画了”。系统会在合适的时机（通常是消息队列空闲时）调用OnPaint函数。这样做的好处是避免了在定时器线程中直接进行耗时的绘图操作，保证了UI的响应性。

键盘控制则在OnKeyDown中实现：

void CMyTetrisDlg::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags) { switch (nChar) { case VK_LEFT: TryMoveCurrentPiece(-1, 0); // 尝试左移 break; case VK_RIGHT: TryMoveCurrentPiece(1, 0); // 尝试右移 break; case VK_DOWN: TryMoveCurrentPiece(0, 1); // 尝试加速下落 break; case VK_UP: TryRotateCurrentPiece(); // 尝试旋转 break; case VK_SPACE: HardDropCurrentPiece(); // 瞬间下落（硬降） break; } Invalidate(); // 每次操作后都请求重绘 CDialogEx::OnKeyDown(nChar, nRepCnt, nFlags); }

3.3 碰撞检测的实现细节

碰撞检测是游戏逻辑的守卫者。所有移动和旋转操作都必须先通过它的检查。CTetromino::IsValidPosition函数是核心。

bool CTetromino::IsValidPosition(const CGameBoard& board) const { for (int i = 0; i < 4; ++i) { Point blockPos = GetBlockPos(i); // 计算第i个小方块的绝对网格坐标 // 1. 检查是否超出左、右、下边界 if (blockPos.x < 0 || blockPos.x >= BOARD_WIDTH || blockPos.y >= BOARD_HEIGHT) { return false; } // 注：上方超出是允许的（新方块从顶部出现），所以不检查blockPos.y < 0 // 2. 检查是否与网格中已固定的方块重叠 if (blockPos.y >= 0 && !board.IsCellEmpty(blockPos.y, blockPos.x)) { return false; } } return true; }

在游戏主逻辑中，任何尝试性操作都遵循“先模拟，后检测，再应用”的模式：

bool CMyTetrisDlg::TryMoveCurrentPiece(int dx, int dy) { // 1. 模拟：创建一个当前方块的副本 CTetromino tempPiece = m_currentPiece; // 2. 对副本应用操作 tempPiece.Move(dx, dy); // 3. 检测：检查新位置是否有效 if (tempPiece.IsValidPosition(m_gameBoard)) { // 4. 应用：如果有效，则将操作应用到真正的当前方块 m_currentPiece = tempPiece; return true; } return false; }

旋转操作的尝试逻辑完全相同，只是将Move换成Rotate。这种模式保证了游戏状态不会被无效的操作破坏。

3.4 图形绘制：从GDI到双缓冲技术

在OnPaint函数中，我们负责将游戏状态可视化。最基础的绘制就是遍历网格，为每个非空单元格画一个填充的矩形。

void CMyTetrisDlg::OnPaint() { CPaintDC dc(this); // 获取设备上下文 // 1. 绘制游戏主网格背景和边框 dc.FillSolidRect(m_boardRect, RGB(0, 0, 0)); // 黑色背景 // ... 绘制网格线 // 2. 绘制已固定的方块 for (int row = 0; row < BOARD_HEIGHT; ++row) { for (int col = 0; col < BOARD_WIDTH; ++col) { int cellValue = m_gameBoard.GetCell(row, col); if (cellValue != EMPTY) { COLORREF color = GetColorByValue(cellValue); // 根据值获取颜色 CRect blockRect = CalculateBlockRect(row, col); // 计算屏幕坐标 dc.FillSolidRect(blockRect, color); dc.Draw3dRect(blockRect, RGB(255,255,255), RGB(64,64,64)); // 画立体边框 } } } // 3. 绘制当前正在下落的方块（半透明或描边，以示区别） DrawCurrentPiece(&dc); // 4. 绘制预览窗口、分数、等级等信息 // ... }

然而，直接这样绘制会遇到严重的闪烁问题。因为OnPaint被频繁调用，每次都在屏幕上直接擦除重画，会导致画面撕裂。解决这个问题的标准技术是“双缓冲”（Double Buffering）。

双缓冲的原理是：先在内存中的一个“画布”（内存DC）上完成所有绘制操作，然后将整块画布一次性拷贝到屏幕DC上。这样用户看到的是一个完整的、瞬间更新的画面，避免了逐步绘制带来的闪烁。

MFC中实现双缓冲的典型代码如下：

void CMyTetrisDlg::OnPaint() { CPaintDC dcScreen(this); // 这是最终输出到屏幕的DC CRect rect; GetClientRect(&rect); // 创建内存DC和兼容位图 CDC dcMemory; CBitmap bitmap; dcMemory.CreateCompatibleDC(&dcScreen); bitmap.CreateCompatibleBitmap(&dcScreen, rect.Width(), rect.Height()); CBitmap* pOldBitmap = dcMemory.SelectObject(&bitmap); // 1. 先在内存DC上绘制整个背景 dcMemory.FillSolidRect(rect, RGB(0, 0, 0)); // 2. 在内存DC上执行所有游戏元素的绘制（网格、方块、文字等） DrawGameToDC(&dcMemory); // 3. 一次性将内存DC的内容“贴”到屏幕DC上 dcScreen.BitBlt(0, 0, rect.Width(), rect.Height(), &dcMemory, 0, 0, SRCCOPY); // 4. 清理资源 dcMemory.SelectObject(pOldBitmap); bitmap.DeleteObject(); dcMemory.DeleteDC(); }

实操心得：在早期硬件性能有限的年代，双缓冲是保证游戏画面流畅的必备技巧。即使在今天，理解双缓冲原理对于优化图形性能仍有意义。在现代图形API中，这个概念演变成了“前缓冲”和“后缓冲”的交换链（Swap Chain）。

4. 从经典到现代：实践与迁移指南

4.1 在现代Visual Studio中复现经典项目

你可能手头有一个古老的VC++ 6.0项目（.dsp, .dsw文件），或者从网上下载了类似的源代码。如何在Visual Studio 2022中打开并运行它？这个过程本身就是一个很好的学习经历。

第一步：项目转换与兼容性设置。直接用VS2022打开旧版解决方案文件，向导会提示进行转换。转换后，你需要关注几个关键点：

  1. 字符集：旧项目默认使用多字节字符集（MBCS），而VS2022默认使用Unicode字符集。这会导致所有涉及字符串的API调用（如MessageBox）报错。你需要在项目属性 -> 配置属性 -> 高级 -> 字符集中，将其改为“使用多字节字符集”。
  2. Windows SDK版本和平台工具集：升级到最新的Windows 10/11 SDK和合适的平台工具集（如v143）。这通常没问题，但极少数情况下旧的API可能被废弃。
  3. MFC库：确保在项目属性 -> 配置属性 -> 高级 -> MFC的使用中，设置为“在共享DLL中使用MFC”。

第二步：解决编译错误。最常见的错误来自<afxwin.h>等MFC头文件，提示“WINVERnot defined”等。这是因为旧项目没有明确指定目标Windows版本。在stdafx.h文件的最开头，添加以下定义可以解决大部分问题：

#define WINVER 0x0A00 // Windows 10 #define _WIN32_WINNT 0x0A00 // Windows 10

第三步：处理已弃用的函数。例如，旧的GetVersionEx函数在现代Windows中行为已变。对于俄罗斯方块这种不依赖具体版本信息的程序，通常直接注释掉或替换为无害的实现即可。

完成这些步骤后，你就能在现代化的IDE中编译和调试这个“古董级”代码了。利用VS2022强大的调试器、性能分析器和代码导航功能，去分析它的运行流程，比在VC6里要舒服得多。

4.2 核心逻辑的跨平台迁移思路

理解了MFC版本的核心逻辑后，我们可以将其“灵魂”抽取出来，用现代C++和跨平台框架（如Qt、SDL2、甚至控制台）重新实现。这才是学习的最终目的：掌握原理，而非绑定于特定技术栈。

以Qt为例，我们可以这样重构：

  1. 数据模型层（Model）：CGameBoard和CTetromino类几乎可以原封不动地移植。它们是纯粹的逻辑类，不依赖任何UI框架。
  2. 控制层（Controller）：游戏主循环不再依赖WM_TIMER，而是使用Qt的QTimer。键盘事件通过重写QWidget::keyPressEvent来处理。
  3. 视图层（View）：绘制工作从GDI切换到Qt的QPainter。在paintEvent函数中实现双缓冲绘制。Qt本身在内部已对很多控件做了双缓冲优化，但我们自己进行游戏绘制时，手动双缓冲或使用QPainter在QPixmap上先画再渲染，仍然是更稳妥的选择。
// Qt版本的游戏主窗口类头文件片段 class TetrisWidget : public QWidget { Q_OBJECT public: TetrisWidget(QWidget *parent = nullptr); protected: void paintEvent(QPaintEvent *event) override; void keyPressEvent(QKeyEvent *event) override; void timerEvent(QTimerEvent *event) override; // 使用QBasicTimer private: void drawGame(QPainter &painter); void updateGame(); // 执行下落、消行等逻辑 private: CGameBoard m_board; CTetromino m_currentPiece; QBasicTimer m_gameTimer; // ... };

迁移到控制台（Console）：这听起来有点复古，但却能极致地聚焦于游戏逻辑。用字符（如[]表示方块，##表示墙体，空格表示空）在控制台窗口中渲染游戏。你可以使用system(“cls”)清屏（效率低），或者使用Windows Console API或跨平台的curses库来移动光标，实现更流畅的动画。这个过程会强迫你思考如何将网格坐标映射到屏幕字符位置，是对逻辑抽象能力的绝佳锻炼。

4.3 功能增强与扩展实践

掌握了基础版本后，可以尝试添加更多功能，让这个经典项目焕发新生。

1. 游戏功能扩展：

  • Hold（暂存）功能：增加一个区域存放一个临时方块。玩家可以按某个键（如C键）将当前方块与暂存区的方块交换。这需要新增一个CTetromino m_holdPiece成员变量和相应的交换逻辑，并注意交换冷却（一次下落周期内只能交换一次）的规则。
  • 幽灵方块（Ghost Piece）：在绘制当前方块时，同时用半透明方式绘制出该方块如果直接硬降会落在的位置。这需要实现一个CalculateDropPosition函数，模拟方块一直下落直到碰撞，然后获取其最终位置并绘制。
  • 多种游戏模式：例如马拉松模式（经典）、冲刺模式（40行竞速）、无限模式等。这需要抽象出一个CGameMode基类，定义分数计算、速度提升曲线等接口，然后派生出不同的模式类。

2. 代码结构优化：

  • 应用MVC/MVVM模式：将游戏逻辑（Model）、绘制（View）和输入/定时器控制（Controller）更清晰地分离。这样，未来替换UI层（比如从MFC换到Qt）会非常容易。
  • 使用智能指针管理资源：如果项目中有动态分配的资源，将原始指针替换为std::unique_ptr或std::shared_ptr，避免内存泄漏。
  • 引入简单的状态模式：将“开始菜单”、“游戏中”、“暂停”、“游戏结束”等状态封装成独立的类，使状态转换逻辑更清晰。

3. 性能与体验优化：

  • 更平滑的动画：基础版本中方块是“一格一格”地移动。可以尝试实现“软降”的平滑动画，即方块在两次定时器触发之间，根据时间插值（Interpolation）连续绘制其位置。这需要引入基于高精度计时器（如QueryPerformanceCounter）的游戏循环，而非简单的WM_TIMER。
  • 音效与音乐：使用PlaySoundAPI或第三方库添加方块移动、旋转、消行、游戏结束的音效。
  • 本地高分记录：将最高分数保存到注册表或本地文件（如INI、JSON）。

5. 常见问题与调试技巧实录

在分析和实践这类项目时，你几乎一定会遇到下面这些问题。我把我的踩坑经验和解决方法记录下来，希望能帮你节省时间。

5.1 编译与运行问题

问题1：在VS2022中编译旧项目，报错“无法打开包括文件: ‘afxwin.h’”

  • 原因：项目没有正确配置MFC支持。
  • 解决：对于控制台项目，你需要创建一个新的“MFC应用程序”项目，然后将代码迁移过去。对于已有的对话框项目，检查项目属性 -> 配置属性 -> 常规 -> 项目默认值 -> MFC的使用，确保不是“使用标准Windows库”，而是“在共享DLL中使用MFC”或“在静态库中使用MFC”。

问题2：程序运行时界面布局错乱，控件位置不对

  • 原因：旧项目使用的对话框单位（DLU）和字体在新系统上可能渲染不同。
  • 解决：这是一个历史遗留问题，彻底解决较麻烦。一个快速但不完美的办法是，在资源编辑器中打开对话框（.rc文件），手动调整控件的位置和大小，使其在新环境下看起来正常。更好的办法是学习使用新的对话框布局管理器。

问题3：键盘响应不灵敏或“粘键”

  • 原因：在OnKeyDown中处理键盘事件时，如果用户长按按键，系统会先发送一个WM_KEYDOWN，短暂延迟后开始快速重复发送。如果游戏逻辑（如移动方块）较慢，可能会积压很多重复消息，导致控制不跟手。
  • 解决：引入“输入缓冲”或“按键状态跟踪”。不要直接在OnKeyDown中执行移动，而是设置一个标志位（如bool m_keyLeftPressed）。在OnKeyDown中将其设为true，在OnKeyUp中设为false。然后在游戏主循环（OnTimer）中，根据这些标志位的状态来执行移动。这样可以实现更稳定、可预测的按键响应，也便于实现“长按连续移动”的效果。

5.2 逻辑与渲染Bug

问题4：方块旋转时“卡”进墙里或已固定方块里

  • 原因：这是俄罗斯方块实现中最经典的Bug，通常是因为旋转的“轴心点”定义不准确，或者旋转后的形状超出了网格边界。经典的“墙壁踢”（Wall Kick）机制就是为了解决这个问题而设计的。
  • 排查：首先，打印或调试查看旋转前后方块的四个小方块的绝对坐标。确认你的旋转表数据是否正确。其次，在IsValidPosition函数中，对于旋转操作，如果新位置无效，可以尝试进行“踢墙”测试：即让方块在旋转的同时，尝试向左、右、下微调一个单位（具体偏移表遵循标准SRS旋转系统），看看是否有某个偏移位置是有效的。这是现代俄罗斯方块（如Tetris Guideline）的标准做法。

问题5：消行后，上方方块没有正确下落

  • 原因：消行逻辑有误。典型的错误算法是：从下往上遍历每一行，如果该行满，就将其删除，然后将其上方的所有行整体下移一行。这个算法的问题在于，当你删除一行后，当前索引的行已经变了，如果继续循环，逻辑会混乱。
  • 正确算法：应该从底部开始，用一个“写指针”指向当前正在处理的行。遍历每一行（“读指针”），如果该行不满，则将其复制到“写指针”指向的行，然后“写指针”上移一行。如果该行满，则跳过（不复制），并增加消行计数。遍历结束后，从“写指针”开始到顶部的所有行，都应该被清空。这个算法是原地操作，高效且不易出错。

问题6：双缓冲绘制仍然有轻微闪烁

  • 原因：可能是在OnPaint之外的其他地方（比如OnTimer或OnKeyDown）直接调用了绘制函数，或者Invalidate()的参数使用不当，导致背景擦除。
  • 解决：确保所有绘制指令都只在OnPaint或其调用的函数中执行。在OnTimer或事件处理函数中，只更新游戏状态，然后调用Invalidate(FALSE)。Invalidate(FALSE)参数表示不擦除背景，由我们的双缓冲代码完全负责绘制，可以避免因背景擦除带来的闪烁。此外，在对话框的属性中，设置Clip Children和Clip Siblings为True也可能有帮助。

5.3 性能与资源管理

问题7：游戏在高刷新率屏幕（如144Hz）上运行过快

  • 原因：游戏速度依赖于WM_TIMER的精度，而WM_TIMER的精度很低（通常约15ms），且与屏幕刷新率无关。但在一些系统上，消息循环处理得非常快，可能导致定时器回调比预期更频繁。
  • 解决：放弃WM_TIMER，改用高精度计时器。使用QueryPerformanceFrequency和QueryPerformanceCounter来获取精确的时间差，自己控制游戏更新的节奏。例如，设定一个固定的逻辑更新间隔（如每50ms更新一次游戏状态），无论帧率多高，逻辑更新频率是稳定的。渲染则可以每帧都进行，以实现平滑的动画。
// 伪代码示例：基于高精度计时器的游戏循环 LARGE_INTEGER freq, now, lastUpdate; QueryPerformanceFrequency(&freq); QueryPerformanceCounter(&lastUpdate); double updateInterval = 0.05; // 50毫秒更新一次逻辑 double lag = 0.0; while (gameIsRunning) { QueryPerformanceCounter(&now); double deltaTime = (double)(now.QuadPart - lastUpdate.QuadPart) / freq.QuadPart; lastUpdate = now; lag += deltaTime; // 处理输入消息... // 固定时间步长的逻辑更新 while (lag >= updateInterval) { UpdateGameLogic(); // 更新游戏状态 lag -= updateInterval; } // 渲染（可以根据lag进行插值，实现平滑渲染） RenderGame(); // 适当的睡眠，避免占用100% CPU Sleep(1); }

通过这样一个从源码分析到现代实践的完整旅程，我们不仅复活了一个经典的游戏项目，更重要的是，我们拆解了游戏编程的核心骨架。那些关于状态、循环、碰撞、渲染的概念，是放之任何游戏项目而皆准的真理。当你下次用Unity创建一个新场景，或者在Unreal里编写角色控制器时，你会想起这个在MFC对话框里下落的俄罗斯方块，并会心一笑——复杂的系统，往往始于最简单的逻辑。