简介：基于Windows API与VC++6.0编写的俄罗斯方块完整工程，面向刚接触C语言、希望借小项目理解Win32编程的初学者，也适合课程设计或大作业参考。压缩包共28个文件、约1.12MB，包含game3.cpp、function.cpp等3个cpp源码及3个头文件，game3.dsp、game3.dsw工程文件，ico图标与rc资源脚本，并附带可直接运行的exe及若干编译中间文件，便于对照编译与调试。已有4515人学习下载。源码带注释，覆盖窗口创建、消息循环、按键响应与方块绘制等环节，游戏支持左右移动、下键加速、上键变形和空格暂停。读者可借此梳理Win32 API程序结构，理解资源组织与VC6工程配置，并在现有代码上修改方块矩阵、计分规则或界面表现，作为继续扩展的起点。
1. 从一份 C 语言俄罗斯方块源码说起：Windows 编程到底能练到什么
很多人第一次读 Windows 编程教材，卡在消息循环；把一份 C 语言编写的俄罗斯方块源码拆开跑通，反而更容易理解窗口、定时器和键盘消息怎么串起来。这份资源是一个用 C 语言实现的俄罗斯方块项目，落在 Windows 编程场景里，核心不是画面多花哨，而是把 Win32 窗口、GDI 绘制、定时下落、矩阵碰撞和消行逻辑压进一个能独立编译的小工程。适合刚学完 C 语言语法、想找一个完整闭环练手的人，也适合需要对照源码排查消息泵和绘制问题的从业者。它解决的是“知识点都会、拼不成程序”的断层，拿源码改参数、看现象，比只读 API 列表更踏实。
2. 把源码跑起来：Win32 工程入口、字符集与编译链
2.1 先判断源码是控制台版还是 Win32 窗口版
拿到源码包后，别急着双击工程文件。先看入口函数和链接参数，能少走很多弯路。C 语言俄罗斯方块常见两种形态：一种是在控制台里用字符画方块，入口是main或wmain，依赖标准输入输出；另一种是 Win32 窗口版，入口是WinMain或wWinMain，要链接user32、gdi32这类系统库。两者都能叫“C 语言俄罗斯方块”，但调试路径完全不同。控制台版适合看逻辑，窗口版才真正涉及 Windows 编程里的消息泵、定时器和绘图。
判断方法很直接：搜源码里的入口函数名，再看有没有CreateWindowEx、RegisterClassEx、WM_PAINT、WM_TIMER这些符号。出现窗口类注册和消息循环，基本就是 Win32 版；只看到printf、scanf、getch，大概率是控制台版。还有一种混合写法：逻辑层用纯 C，界面层用 Win32，这种结构最适合改，因为方块矩阵、碰撞、消行可以单独抽出来测试。
常见文件类型可以按下面这张表先归类，别一上来就逐行读：
| 文件类型 | 常见作用 | 先看什么 |
|---|---|---|
.c源文件 | 游戏逻辑、窗口过程、绘制 | 入口函数、消息循环、定时器 |
.h头文件 | 结构体、常量、函数声明 | 方块矩阵尺寸、棋盘宽高 |
.rc资源脚本 | 图标、菜单、对话框 | 是否引用了缺失资源 |
| 工程/构建文件 | 编译选项、链接库 | 字符集、入口点、附加依赖库 |
如果源码包带工程文件，先确认目标平台和字符集；如果没有工程文件，就按单文件或多文件 C 工程手动建。不要在不清楚入口点的情况下直接编译，否则最常见的报错就是“无法解析的外部符号 WinMain”或者“入口点必须定义”。
2.2 用常见编译环境建工程：从文件清单到可执行程序
我一般会先建一个干净目录，把源码放进去，再根据文件数量决定编译方式。单文件或少量文件，直接命令行编译最快；文件多、依赖资源脚本，再用工程管理。下面这条命令是 gcc 工具链下编译 Win32 窗口程序的典型形式，源码文件名要按实际替换：
# 进入源码目录后，按实际 .c 文件替换 main.c game.c render.c gcc main.c game.c render.c -o tetris.exe \ -mwindows \ -DUNICODE -D_UNICODE \ -lgdi32 -luser32这条命令里，-mwindows表示生成窗口子系统程序，避免运行时额外弹出控制台窗口；如果源码还在调试阶段，可以临时去掉它，保留控制台看日志。-DUNICODE -D_UNICODE是告诉编译器走宽字符 API，和源码里的wWinMain、TCHAR系列保持一致。-lgdi32负责绘图相关符号，-luser32负责窗口、消息、定时器相关符号。链接顺序一般把业务源文件放前面，系统库放后面；如果出现未定义符号，先看库有没有漏，再看入口函数是否匹配。
如果源码使用的是WinMain而不是wWinMain，字符集宏就不要硬加，或者把入口统一改成宽字符版本。编译命令不是越复杂越好，先保证最小可运行，再补资源脚本和图标。带.rc资源脚本时，通常还要多做一步资源编译，把.res或.o目标一起链接；这一步不同工具链命令不一样，建议先注释掉资源引用，跑通主窗口后再加回来。
工程配置里重点看三个地方：入口点、字符集、附加依赖库。入口点要和源码实际函数一致；字符集要和字符串宏一致；附加依赖库至少包含user32和gdi32。如果编译能过、运行时窗口一闪就退，优先检查消息循环是否写成了if而不是while，以及GetMessage的返回值判断是否正确。
2.3 入口函数、字符集和链接参数的落地配置
Win32 窗口版的入口不是普通main，而是WinMain或wWinMain。这两者的参数含义一样：当前实例句柄、前一个实例句柄、命令行参数、显示方式。很多初学者把main里的argc/argv习惯带进来，结果参数对不上，编译报类型错误。更稳妥的做法是先保留入口签名不动，把游戏初始化、窗口创建、消息循环拆成三个函数，入口只负责串联。
字符集是第二个高频翻车点。源码里如果用了MessageBox、CreateWindow这类宏，编译器会根据UNICODE宏展开成宽字符或窄字符版本。你一边定义UNICODE，一边传窄字符串字面量，就会遇到类型不匹配。统一原则是：源码用TCHAR、TEXT()、_T()就跟着工程字符集走；源码明确写wchar_t、L"..."就开宽字符；源码全是char、"..."就关掉宽字符宏。不要混着改，否则错误会散落在几十个调用点上。
链接参数也要和入口匹配。窗口程序常见依赖是user32、gdi32，如果源码用了公共对话框，还可能涉及comdlg32；用了多媒体计时器，可能涉及winmm。但不要凭感觉把所有库都加上，先让编译器报未定义符号，再按符号补库，工程会更干净。下面这个检查顺序我常用：
- 先确认入口函数名和工程入口点一致。
- 再确认字符集宏和字符串字面量一致。
- 然后按未定义符号补系统库。
- 最后处理资源脚本和图标引用。
跑通标准是：程序启动后出现固定尺寸窗口，方块能按定时器下落，键盘左右能移动，关闭窗口能正常退出。只要这四件事成立，后面的逻辑调试就有了稳定基座。
3. 消息泵与帧节奏：定时器、输入队列和重绘时机
3.1 俄罗斯方块的游戏循环为什么不能写成死循环
控制台版俄罗斯方块可以写while(1)加sleep，窗口版不能这么干。Win32 程序靠消息驱动，窗口过程要不断处理WM_PAINT、WM_KEYDOWN、WM_TIMER、WM_CLOSE。如果你在窗口过程里写死循环，消息队列会被堵住，窗口拖动、最小化、关闭都会失去响应。正确结构是“消息循环负责取消息，窗口过程负责处理消息，定时器负责推进游戏节拍”。
俄罗斯方块看似是实时游戏，实际可以拆成离散节拍：每隔一段时间让当前方块下落一格，收到键盘消息时尝试左右移动或旋转，收到绘制消息时把棋盘和当前方块画出来。这个模型不需要多线程，也不需要高精度帧同步。对练手项目来说，SetTimer足够；对商业级手感，才需要更细的时间片和输入缓存。先用定时器把闭环跑通，再谈优化。
消息循环的最小骨架如下，源码里的窗口创建部分可以不同，但取消息和分发消息的逻辑基本一致：
// 最小 Win32 消息循环：取消息、翻译、分发 MSG msg; BOOL ret; while ((ret = GetMessage(&msg, NULL, 0, 0)) != 0) { if (ret == -1) { break; // 取消息失败，直接退出，避免死循环 } TranslateMessage(&msg); DispatchMessage(&msg); } return (int)msg.wParam;GetMessage返回 0 表示收到WM_QUIT，返回 -1 表示出错，其他值继续循环。TranslateMessage主要把按键消息转成字符消息，俄罗斯方块如果只处理虚拟键码，可以保留也可以不依赖它。DispatchMessage把消息送到窗口过程。这里不要用if (GetMessage(...))的简写，因为 -1 也会被当成真，出错时容易卡住。
窗口过程里用switch分派消息，默认分支必须走DefWindowProc。很多“窗口能开但关不掉”的问题，就是WM_CLOSE或WM_DESTROY没处理，或者默认分支被漏掉。WM_DESTROY里调用PostQuitMessage(0)，消息循环才会退出。
3.2 SetTimer 与 WM_TIMER：下落节拍的最小实现
定时下落可以用SetTimer创建一个窗口定时器，在WM_TIMER里推进方块。间隔不要一开始就设得太激进，先给 500 毫秒左右，确认下落、碰撞、锁定、消行都能走通，再按等级缩短。定时器精度不适合做毫秒级动画，但俄罗斯方块的格落下落完全够用。真正要控制的是“每次定时器触发只下落一格”，不要在WM_TIMER里循环下落多格，否则手感会突然变快。
示例代码：
// 创建定时器：ID 为 1，间隔 500ms，绑定到当前窗口 SetTimer(hwnd, 1, 500, NULL); // 窗口过程中的定时器处理 case WM_TIMER: if (wparam == 1) { GameTick(); // 尝试下落一格，内部做碰撞检测 InvalidateRect(hwnd, NULL, FALSE); // 标记重绘，不强制擦背景 } return 0;SetTimer的第二个参数是定时器 ID，后面WM_TIMER的wParam会带上它；第三个参数是间隔毫秒数；第四个参数为NULL时走系统默认回调，消息发到窗口过程。InvalidateRect的第三个参数设为FALSE，表示不先擦背景，能减少一部分闪烁；但真正压闪烁还要靠双缓冲。GameTick里只做“尝试下移、失败则锁定、锁定后检查消行、再生成新方块”，不要在这里做绘制。
定时器间隔和等级速度要分开看。常见做法是维护一个“当前等级”变量，用表或公式换算成间隔，再调用SetTimer重设定时器。不要每次下落都改间隔，也不要把间隔写成固定值后再靠增加下落格数来提速。前者会让节奏抖动，后者会让碰撞检测跨格，容易出现穿模。
| 参数 | 常见取值 | 作用 | 调整建议 |
|---|---|---|---|
| 定时器 ID | 1 | 区分多个定时器 | 固定一个，别和动画定时器混用 |
| 初始间隔 | 400～600ms | 一级下落速度 | 先慢后快，便于观察逻辑 |
| 重绘方式 | InvalidateRect | 请求重绘 | 配合双缓冲使用 |
| 下落步长 | 1 格 | 每次定时器触发 | 不要跨格，避免碰撞漏判 |
如果发现方块下落越来越快，先查是不是在WM_TIMER里重复调用了SetTimer，导致多个同 ID 定时器叠加；如果发现方块不动，查GameTick是否被条件拦住，或者InvalidateRect后WM_PAINT没有真正绘制当前方块。
3.3 键盘消息与 DAS/ARR：左右移动手感怎么调
键盘处理是俄罗斯方块手感的核心。WM_KEYDOWN只给按下事件，系统按键重复率受控制面板影响，直接拿它做左右移动会“先慢后快”，很不稳定。常见做法是自己维护按键状态：按下时记录时间，首次移动立即生效，按住超过 DAS 后按 ARR 间隔连续移动。DAS 是首次延迟，ARR 是重复间隔。调参比堆代码更重要。
示例结构：
// 按键状态：记录左右键是否按住，以及下一次允许移动的时间 static int leftHeld = 0, rightHeld = 0; static DWORD leftNext = 0, rightNext = 0; const DWORD DAS_MS = 160; // 首次重复延迟 const DWORD ARR_MS = 45; // 连续重复间隔 case WM_KEYDOWN: if (wparam == VK_LEFT) { leftHeld = 1; TryMove(-1, 0); // 首次按下立即移动 leftNext = GetTickCount() + DAS_MS; } else if (wparam == VK_RIGHT) { rightHeld = 1; TryMove(1, 0); rightNext = GetTickCount() + DAS_MS; } else if (wparam == VK_UP) { TryRotate(); } else if (wparam == VK_DOWN) { GameTick(); // 软降，立即下落一格 } return 0;GetTickCount返回系统启动后的毫秒数，适合做这种短周期输入计时；DAS_MS控制按住后多久开始连续移动，ARR_MS控制连续移动的间隔。TryMove内部要做边界和堆叠检测，失败就不改变位置。软降不要直接改定时器间隔，而是调用一次下落逻辑，同时可以加一个短暂的重置，避免和自动下落打架。
按键状态要在WM_KEYUP里清掉，窗口失去焦点时也要清，否则切出去再切回来会出现“按键卡住”。如果源码里没有处理WM_KILLFOCUS，建议补上。手感参数没有绝对标准，我一般从 DAS 150～180ms、ARR 40～60ms 起调，觉得拖沓就减 ARR，觉得一按就飞就加 DAS。先保证移动不穿墙、不穿块，再谈顺滑。
4. 方块矩阵与消行：数据结构、碰撞检测和随机序列
4.1 用 4x4 方块矩阵表示七种形状：旋转状态怎么存
俄罗斯方块的形状可以用固定 4x4 矩阵表示，每个格子存 0 或 1。七种方块各自有旋转状态，常见做法是把每个形状的四个旋转态都写死，运行时只切换索引。这样比运行时做矩阵旋转更稳，也更容易调碰撞。4x4 的好处是旋转包围盒固定，边界检查简单；缺点是有些形状周围有空列，视觉上会显得偏，但可以靠偏移量修正。
示例结构：
// 每个方块用 4x4 矩阵表示，最多 4 个旋转态 typedef struct { int cells[4][4]; } Shape; // 以 T 形方块为例，实际源码里会有七种形状的多组旋转态 static const Shape kShapes[] = { { .cells = { {0,1,0,0}, {1,1,1,0}, {0,0,0,0}, {0,0,0,0} }}, // 其他旋转态和形状按同样格式补齐 };cells里 1 表示实心格，0 表示空。运行时用shapeIndex和rotationIndex定位当前矩阵，再叠加棋盘坐标(x, y)做碰撞检测。不要把形状直接写进棋盘数组，否则旋转和回退会很麻烦。棋盘只保存已经锁定的方块，当前方块单独维护，绘制时先画棋盘再画当前方块。
旋转态写死虽然占一点空间，但换来了确定性。每个形状的旋转索引按 0、1、2、3 循环，旋转失败时不改变索引。某些形状只有两个有效旋转态，另外两个可以重复或留空，切换时做取模即可。这样做的好处是调试时能一眼看出当前是哪个态，不会出现“矩阵转着转着多了个空格”的玄学问题。
4.2 碰撞检测与锁定：边界、堆叠和游戏结束判定
碰撞检测要同时看三件事：是否超出左右边界、是否超出底部、是否和已锁定方块重叠。当前方块矩阵里为 1 的格子才参与检测，为 0 的格子跳过。检测顺序一般是先算目标位置，再逐格判断，任何一格不合法就回退。锁定发生在向下移动失败时，把当前方块写入棋盘，然后检查消行。
示例函数：
// 检查当前方块在 (nx, ny) 是否合法 int CanPlace(const int board[BOARD_H][BOARD_W], const Shape *shape, int nx, int ny) { for (int r = 0; r < 4; ++r) { for (int c = 0; c < 4; ++c) { if (!shape->cells[r][c]) continue; int x = nx + c; int y = ny + r; if (x < 0 || x >= BOARD_W || y >= BOARD_H) return 0; if (y >= 0 && board[y][x]) return 0; } } return 1; }BOARD_W、BOARD_H是棋盘宽高，常见是 10 列、20 行可见区，上面可以多留几行隐藏区给生成方块。nx、ny是当前方块左上角在棋盘中的坐标。y < 0的格子允许存在，用于方块从顶部生成；但y >= BOARD_H直接判失败。和棋盘重叠时返回 0，调用方回退位置。
锁定后要检查游戏结束：如果新生成的方块在初始位置就CanPlace失败，说明堆到顶了。不要等绘制越界才判断。消行时从底部往上扫，遇到满行就把上面的行整体下移，再把顶行清空。行扫描不要从中间跳着来，否则容易漏行或重复消行。
4.3 消行与随机方块：队列、种子和可复现调试
随机方块如果直接用rand() % 7，会出现连续十几个同形状，调试时很难复现。常见做法是“7-bag”：把七种形状洗牌后依次发出，发完再洗下一袋。这样既保证短期均匀，也保留随机感。调试阶段可以固定种子，让每次启动的序列一致；正式玩再换成时间种子。
示例逻辑：
// 7-bag：每袋包含七种形状，洗牌后逐个取出 static int bag[7]; static int bagIndex = 7; static void RefillBag(void) { for (int i = 0; i < 7; ++i) bag[i] = i; for (int i = 6; i > 0; --i) { int j = rand() % (i + 1); int t = bag[i]; bag[i] = bag[j]; bag[j] = t; } bagIndex = 0; } static int NextShape(void) { if (bagIndex >= 7) RefillBag(); return bag[bagIndex++]; }RefillBag先把 0～6 填进袋子，再用 Fisher-Yates 洗牌；NextShape取完一袋再补。调试时在启动处调用srand(12345)，每次序列一致，方便复现某个消行 bug；正式运行时用srand((unsigned)time(NULL))。如果源码里没有 7-bag，只有rand() % 7，可以先补这个逻辑，再观察连续同形状是否减少。
消行和随机序列要分开验证：先固定种子，连续玩几局，看是否还会出现不可能的形状组合；再改种子，确认随机分布没有明显偏斜。不要用“看起来随机”来判断，连续同形状和长时间不出某形状都是可观察的异常。
5. 避坑与排查：编译链接、GDI 泄漏、定时器漂移和输入玄学
5.1 编译期与链接期：入口点、字符集、库顺序
现象一：编译报“无法解析的外部符号 WinMain”或“入口点必须定义”。
原因通常是源码入口是wWinMain，工程却按WinMain找；或者源码是控制台main，却用了窗口子系统。解决方式是先搜入口函数名，再统一工程入口点；如果开了UNICODE，入口一般用wWinMain，没开就用WinMain。不要靠加一个空的main糊弄，后面消息循环还是会缺。
现象二：字符串参数类型不匹配，const char*和LPCWSTR互报。
原因是字符集宏和字符串字面量不一致。解决方式是统一字符集：要么全走宽字符，用L"..."、TEXT("...")；要么全走窄字符，关掉UNICODE宏。不要在一个文件里混用两套 API。改的时候从入口和窗口创建开始，顺着编译错误逐个替换。
现象三：链接时报CreateDIBSection、BitBlt等符号未定义。
原因是漏了gdi32；窗口、消息、定时器相关符号漏了会报user32。解决方式是按报错符号补库，别一次性堆一堆库。命令行编译时把-lgdi32 -luser32放在源文件后面；工程配置里在附加依赖库中补对应库名。
排查命令可以先用预处理和编译检查入口与宏：
# 只编译不链接，先看语法和头文件问题 gcc -c main.c -DUNICODE -D_UNICODE -o main.o # 链接阶段保留报错符号，按符号补库 gcc main.o game.o render.o -o tetris.exe -mwindows -lgdi32 -luser32-c只编译不链接，能把语法错误和链接错误分开；先过编译，再处理链接。链接时如果还报入口问题，用工具查看目标文件符号，确认是WinMain还是wWinMain，再改工程配置。
5.2 运行期：GDI 对象泄漏、闪烁和定时器漂移
现象四：程序运行越久越卡，任务管理器里 GDI 对象数一直涨。
原因是WM_PAINT里创建了画笔、刷子、位图，却没有释放。GDI 对象是系统资源，不是普通内存，泄漏到一定数量会绘制失败。解决方式是“谁创建谁释放”，CreatePen、CreateSolidBrush、CreateCompatibleBitmap配DeleteObject；内存 DC 配DeleteDC。不要把创建放在每帧绘制里，能复用就复用，不能复用就确保成对释放。
现象五：画面闪烁，方块边缘抖动。
原因是每次WM_PAINT先擦背景再画，中间有一帧空白。解决方式是双缓冲：内存 DC 画完再一次性BitBlt到窗口；同时在WM_ERASEBKGND里返回非零，减少背景擦除。InvalidateRect的第三个参数用FALSE，避免每次都擦背景。双缓冲不是玄学，核心就是“离屏画完再拷贝”。
现象六：定时器越跑越不准，切窗口回来后方块猛掉几格。
原因是WM_TIMER是低精度消息，系统忙时会合并、延迟；如果窗口过程里还做了重活，延迟更明显。解决方式是不要在WM_TIMER里做大量绘制和计算，只推进一格并标记重绘；切回窗口时不要补算漏掉的节拍，直接按当前时间重置下一次下落时间。对俄罗斯方块来说，丢掉几拍比一次补十几格更安全。
5.3 手感与逻辑：旋转踢墙、软降重复、随机序列翻车
现象七：方块贴墙旋转时直接卡住或穿进墙里。
原因是旋转后没有做踢墙检测。解决方式是旋转后先检查合法性，不合法就尝试左右偏移一格或两格，再不行就回退旋转。简单项目可以只做左右踢墙，不做复杂踢墙表；但至少要有“旋转失败不改变状态”的保护。不要先改旋转索引再判断，失败后要能恢复原索引。
现象八：按住下键时方块一次掉很多格，或者和自动下落叠加。
原因是WM_KEYDOWN的系统重复和定时器同时触发。解决方式是软降只调用一次下落逻辑，并重置自动下落计时；或者自己维护按键状态，按固定间隔软降。不要在WM_KEYDOWN里循环调用下落，否则按键重复率一高就穿透。
现象九：随机方块连续同形状，调试时无法复现。
原因是直接取模随机，没有袋子机制，也没有固定种子。解决方式是改用 7-bag，调试期固定srand种子，记录当前袋子序列。出现消行 bug 时，先固定种子复现，再逐步打印当前方块、旋转态、坐标和棋盘。不要靠“再玩一局看看”排查随机相关的问题。
6. 进阶调参与验证：双缓冲、速度曲线和一页自检表
6.1 双缓冲：把闪烁压下去的最小改动
双缓冲不需要重写绘制逻辑，只要把绘制目标从窗口 DC 换成内存 DC。下面是最小骨架：
// WM_PAINT 中：先画到内存 DC，再一次性拷贝到窗口 PAINTSTRUCT ps; HDC hdc = BeginPaint(hwnd, &ps); HDC mem = CreateCompatibleDC(hdc); HBITMAP bmp = CreateCompatibleBitmap(hdc, width, height); HBITMAP old = (HBITMAP)SelectObject(mem, bmp); DrawGame(mem); // 所有绘制都画到 mem BitBlt(hdc, 0, 0, width, height, mem, 0, 0, SRCCOPY); SelectObject(mem, old); DeleteObject(bmp); DeleteDC(mem); EndPaint(hwnd, &ps);CreateCompatibleDC创建内存 DC，CreateCompatibleBitmap创建同尺寸位图，SelectObject换入后DrawGame全部画到内存，最后BitBlt一次拷贝。释放顺序要和创建顺序相反，SelectObject换回旧位图后再删位图，否则位图还被 DC 占用。位图尺寸不要每次WM_PAINT都重建，能在窗口创建时建一次就建一次。
6.2 速度曲线与难度参数：按等级改间隔而不是改步长
速度曲线建议用等级查表，别用复杂公式。一级 500ms，二级 450ms，逐级递减，最低不要低于 80～100ms；每次只改定时器间隔，不改变每次下落一格。软降和硬降单独处理，硬降直接落到底并锁定，软降只下移一格。下表可以作为调参起点：
| 等级 | 下落间隔 | 说明 |
|---|---|---|
| 1 | 500ms | 观察逻辑，适合调试 |
| 2 | 450ms | 轻微加速 |
| 3 | 400ms | 开始有压力 |
| 4 | 350ms | 需要提前规划 |
| 5 | 300ms | 手速介入 |
6.3 交付前验证：从冷启动到连续消行的检查表
交付前我习惯按一页清单走一遍：冷启动是否只出现一个窗口；关闭窗口是否正常退出；左右移动是否穿墙；旋转贴墙是否回退；软降是否和自动下落叠加；连续消两行、三行、四行是否行索引正确；固定种子下随机序列是否可复现；连续运行十分钟 GDI 对象数是否稳定。每次改完定时器或绘制代码，至少跑一遍“贴墙旋转 + 连续消行 + 最小化恢复”。
从那以后我每次拿到这类 Win32 小工程，都强制先跑入口和字符集检查，再跑双缓冲和资源释放检查，最后才调手感参数。希望帮到你。
本文还有配套的精品资源，点击获取
