简介面向 C 初学者与 Windows 游戏开发入门者的贪吃蛇增强版 VC6.0 工程源码以经典贪吃蛇玩法为载体演示如何用面向对象方式拆分蛇体与界面逻辑蛇类封装位置、长度及移动增长行为蛇身采用单链表动态增删节点配合 MFC 消息处理键盘输入、定时器控制移动速度、CWnd 绘图与开始、运行、暂停、结束状态管理并含基本异常退出处理。压缩包共 58 个文件、约 8.98MB包含 5 个 cpp 与 6 个头文件等核心源码dsp、dsw 工程配置bmp、ico、rc 等界面资源以及 obj、pdb、idb、sbr 等编译调试中间文件可直接在 VC6.0 中打开参照。已有 179 人学习适合对照梳理链表操作、MFC 消息循环与定时器用法也可作为课程设计或小型游戏项目的改造底本。1. 贪吃蛇这个题目难在增强两个字贪吃蛇在 VC6.0 里做很多人第一反应是两小时能写完。真动手就会发现基础版确实两小时但一旦开始加东西——加速道具、穿墙、障碍关卡、关卡配置外置、音效——难度全在第二阶段。蛇的移动逻辑本身十分钟能写对真正制造麻烦的是蛇跑得越快越容易撞到自己、窗口切出去再切回来蛇直接撞墙、玩十分钟帧率掉到个位数、按一次方向键它自己掉头。这些都不是算法问题而是 VC6.0 那套工具链和 Win32 消息模型自带的边界。这篇笔记讲的是一条能落地的路线用 Win32 空工程搭骨架用 QueryPerformanceCounter 做固定步长主循环用双缓冲把闪烁压掉再把增强玩法的数值抽成外部配置表。适合手上有 VC6.0 还不想换、又想把贪吃蛇从能跑做到能玩的人。2. VC6.0 工程骨架从空工程到画出第一格蛇身2.1 为什么这个场景下不建议走 MFC 向导新建工程时VC6.0 的 MFC AppWizard 很省事点几下就能得到一个能跑的窗口。但对贪吃蛇这种单窗口、单线程、逻辑密集的小程序向导生成的 Doc/View 结构、消息映射宏、CWinApp 派生类全是需要绕过去才能工作的负担。更麻烦的是调试出了问题时调用栈里一大半是 MFC 自己的框架代码真正的业务函数被埋在最底下。Win32 SDK 空工程的好处是全部透明。WinMain、窗口过程、消息循环、绘制一共几个函数出问题一眼能定位。代价是字符串处理、文件对话框这些都要自己写但对贪吃蛇这种量级的程序用到的也就 CString 之外的一点点。我一般会先在 Win32 空工程里把游戏跑通真需要配置对话框了再单独引一个 MFC 的 CFileDialog 进来两者混用完全没问题。如果只是想把移动逻辑先验证一遍VC6.0 里的 Win32 Console Application 也够用system(cls)加_kbhit()、_getch()二十行就能看到蛇在跑。逻辑对了再搬进窗口工程能省不少来回。2.2 新建工程和四个必须检查的项目设置File → New → Projects → Win32 Application工程名随便起下一步选An empty project不要选那个带示例代码的。建完之后右键工程加一个snake_main.cpp然后在 Project → Settings 里把这四处改掉这四处不改后面一定出问题设置项位置值不改的后果运行库C/C → Code Generation → Use run-time libraryDebug Multithreaded / Multithreaded和某些静态库混用时链接报重定义附加库Link → Object/library modules追加winmm.lib msimg32.libPlaySound、AlphaBlend 链接报 LNK2001预处理器C/C → Preprocessor definitions保留WIN32;_DEBUG删掉_CONSOLE保留 _CONSOLE 时 WinMain 入口可能对不上警告级别C/C → General → Warning levelLevel 4未初始化变量这类坑要等到 Release 才炸字符集方面VC6.0 默认就是 ANSI标题里这种情况我不建议开 UNICODE。开了之后所有字符串字面量都要加_T()CreateWindow要换CreateWindowW而贪吃蛇的文本量小到根本不值得这套开销。保持 ANSI字符串直接用char*和sprintf、fopen这些函数配合最顺。还有一个容易被忽略的点VC6.0 的编译器允许for (int i 0; ...)但i的作用域会泄漏到循环外。写起来没问题读代码时容易误以为是个新变量。我一般要求团队在这个工程里把循环变量声明在块首风格统一别人接手时不用猜。2.3 最小可运行骨架WinMain 与窗口过程的职责切分下面这段是整个工程的地基直接能编过。注意它已经为后面三章预留了接口PushDir处理方向RunGameLoop替换掉传统的GetMessage循环。// snake_main.cpp —— VC6 Win32 空工程的最小骨架 #include windows.h #define CELL_SIZE 16 #define GRID_W 30 #define GRID_H 22 void PushDir(int dx, int dy); // 第 3 章实现 void RunGameLoop(HWND hWnd); // 第 3 章实现 LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch (msg) { case WM_ERASEBKGND: return 1; // 背景自己画告诉系统别再擦一遍省一次闪烁 case WM_KEYDOWN: // 0x40000000 是 lParam 的 bit30为 1 表示这是按住不放产生的重复消息 if ((lParam 0x40000000) 0) { switch (wParam) { case VK_UP: PushDir( 0, -1); break; case VK_DOWN: PushDir( 0, 1); break; case VK_LEFT: PushDir(-1, 0); break; case VK_RIGHT: PushDir( 1, 0); break; } } return 0; case WM_DESTROY: PostQuitMessage(0); return 0; } return DefWindowProc(hWnd, msg, wParam, lParam); } int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow) { WNDCLASS wc; HWND hWnd; RECT rc; DWORD dwStyle; ZeroMemory(wc, sizeof(wc)); wc.lpfnWndProc WndProc; wc.hInstance hInst; wc.hCursor LoadCursor(NULL, IDC_ARROW); wc.hbrBackground (HBRUSH)GetStockObject(BLACK_BRUSH); wc.lpszClassName SnakeWnd; if (!RegisterClass(wc)) return 0; // 客户区锁死成 30x22 格窗口外框交给 AdjustWindowRect 算别手填数字 dwStyle WS_OVERLAPPEDWINDOW ~WS_THICKFRAME ~WS_MAXIMIZEBOX; rc.left 0; rc.top 0; rc.right GRID_W * CELL_SIZE; rc.bottom GRID_H * CELL_SIZE; AdjustWindowRect(rc, dwStyle, FALSE); hWnd CreateWindow(SnakeWnd, Snake, dwStyle, CW_USEDEFAULT, CW_USEDEFAULT, rc.right - rc.left, rc.bottom - rc.top, NULL, NULL, hInst, NULL); if (!hWnd) return 0; ShowWindow(hWnd, nShow); UpdateWindow(hWnd); RunGameLoop(hWnd); return 0; }几个参数的取舍说清楚。CELL_SIZE取 16 是因为 16 像素格子配 30x22 的网格刚好 480x352 的客户区在 1024x768 上不至于顶满屏幕取 20 或 24 会让窗口偏大取 8 则蛇身细节看不清。GRID_W和GRID_H决定的是可玩面积30x22 意味着蛇最长 660 格对普通难度够用做关卡时这两项应该从 INI 读而不是写死第 6 章会改。WM_ERASEBKGND直接返回 1 这一行很关键。默认情况下 Windows 会在WM_PAINT之前先用背景刷子擦一遍窗口这一擦就是一次全屏填充和你的绘制之间有一个可见间隙闪烁有一半来自这里。返回非零值告诉系统我已经处理了配合第 4 章的双缓冲闪烁能压到看不见。WM_KEYDOWN里过滤 bit30 是防止系统自动重复灌满方向队列。按住方向键不放时Windows 会以大约每秒 30 次的频率重复发WM_KEYDOWN如果每个都入队队列瞬间就满了玩家真正的新指令反而被丢弃。3. 主循环与输入把 SetTimer 换成 QueryPerformanceCounter 固定步长3.1 SetTimer 的三个坑精度、消息优先级、重复创建新手写贪吃蛇最自然的做法是SetTimer(hWnd, 1, 100, NULL)然后在WM_TIMER里让蛇走一格。这个方案能跑但只要开始调速度就会撞墙。第一个坑是精度。SetTimer的定时精度受系统时钟节拍限制默认节拍大约 15.6 毫秒你设 10ms 实际可能 15ms设 100ms 实际可能 109ms而且这个误差会累积。想让蛇跑得越来越快时你得不断KillTimer再SetTimer两次调用之间就有时间漏洞。第二个坑是消息优先级。WM_TIMER是低优先级消息只有在消息队列里没有其他消息时才会被生成。如果你的程序在WM_TIMER里做了比较重的绘制导致处理时间超过一个 tick 周期系统不会给你补上错过的 tick而是直接合并掉。表现出来就是蛇越跑越慢玩家会觉得游戏卡了。第三个坑是重复创建。SetTimer用同一个 ID 再调一次不会重置而是替换但如果中间KillTimer失败或者 ID 搞混了就可能出现两个定时器同时驱动蛇一步走两格。这些不是玄学是 Win32 定时器的设计取舍。它面向的是 UI 刷新这种大致按时就行的场景不是游戏循环。3.2 用 PeekMessage 加高精度计时器做固定步长正确做法是把消息处理和逻辑推进拆开消息有就处理没有就推进游戏。下面这段是主循环的全部。// game_loop.cpp —— 固定步长主循环VC6 可直接编译 #include windows.h static LARGE_INTEGER g_qpcFreq; static LARGE_INTEGER g_qpcLast; static double g_accumulator 0.0; static double g_stepSec 0.12; // 每步 120ms关卡表里改这个值 void TickGame(void); // 只推进逻辑不做绘制 void RenderGame(HWND hWnd); // 只做绘制不改逻辑 static void InitClock(void) { QueryPerformanceFrequency(g_qpcFreq); QueryPerformanceCounter(g_qpcLast); g_accumulator 0.0; } static double TakeFrameSeconds(void) { LARGE_INTEGER now; double dt; QueryPerformanceCounter(now); dt (double)(now.QuadPart - g_qpcLast.QuadPart) / (double)g_qpcFreq.QuadPart; g_qpcLast now; if (dt 0.25) dt 0.25; // 调试断点、切窗口回来时别让蛇瞬移几十格 return dt; } void SetGameSpeed(double secPerStep) { if (secPerStep 0.03) secPerStep 0.03; // 下限 30ms再快人眼跟不上 g_stepSec secPerStep; } void RunGameLoop(HWND hWnd) { MSG msg; InitClock(); for (;;) { if (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) { if (msg.message WM_QUIT) break; TranslateMessage(msg); DispatchMessage(msg); } else { g_accumulator TakeFrameSeconds(); while (g_accumulator g_stepSec) { TickGame(); g_accumulator - g_stepSec; } RenderGame(hWnd); Sleep(1); // 让出时间片别把单核 CPU 跑满 } } }逻辑说明分三块。PeekMessage替代GetMessage。GetMessage在没有消息时会阻塞游戏就停了PeekMessage拿不到消息立刻返回程序可以继续往下走。PM_REMOVE表示取到就出队不加的话同一条消息会被反复处理。g_accumulator是累加器模式的核。每帧把真实流逝的时间加进去只要够一个 step 就推进一次逻辑并扣掉。这样逻辑推进的频率严格由g_stepSec决定和渲染帧率解耦。渲染可能跑到几百帧但蛇的移动仍然是每 120 毫秒一格。如果某一帧耗时比较长导致累加器攒了三个 stepwhile会把它们补上蛇走三格——这比丢掉 tick 更符合玩家预期。Sleep(1)这行很多人会删掉觉得浪费。删掉的后果是在没有消息时循环会满载跑满一个核风扇狂转笔记本上还可能导致降频。加 1 毫秒的让出对 120 毫秒一个 step 的游戏毫无影响。参数上g_stepSec的典型取值在 0.08 到 0.20 之间0.20 是慢速适合新手关卡0.12 是标准0.08 已经偏快需要玩家反应低于 0.06 基本没法玩。下限保护设在 0.03是为了防止关卡表配错一个 0 把游戏跑成幻灯片。3.3 方向输入队列一帧内连按两次为什么会撞死自己即使主循环改对了输入还有一个隐蔽的坑。假设蛇向右移动玩家在一个 tick 内快速按下上再按下左。直觉上这是合法的先转上再转左蛇头应该绕个弯。但如果逻辑是每次收到按键就和当前蛇头方向比较那么按左的时候蛇头方向还是右左和右相反被判定为掉头而丢弃玩家会觉得按键失灵。正确做法是把方向指令排成队列比较对象是队列末尾的方向而不是蛇头当前方向。// input_queue.cpp —— 方向指令环形队列 #define DIR_QUEUE_SIZE 4 struct DirCmd { int dx; int dy; }; static DirCmd g_dirQueue[DIR_QUEUE_SIZE]; static int g_dirHead 0; // 读位置 static int g_dirTail 0; // 写位置 static int g_dirCount 0; static int g_curDx 1; // 当前生效方向初始向右 static int g_curDy 0; void PushDir(int dx, int dy) { int refDx g_curDx; int refDy g_curDy; // 队列非空时比较对象换成队列最后一个方向 if (g_dirCount 0) { int last (g_dirTail DIR_QUEUE_SIZE - 1) % DIR_QUEUE_SIZE; refDx g_dirQueue[last].dx; refDy g_dirQueue[last].dy; } if (dx -refDx dy -refDy) return; // 180 度掉头直接丢弃 if (dx refDx dy refDy) return; // 同方向不重复入队 if (g_dirCount DIR_QUEUE_SIZE) return; // 队列满丢弃后来的 g_dirQueue[g_dirTail].dx dx; g_dirQueue[g_dirTail].dy dy; g_dirTail (g_dirTail 1) % DIR_QUEUE_SIZE; g_dirCount; } int PopDir(int* dx, int* dy) { if (g_dirCount 0) return 0; *dx g_dirQueue[g_dirHead].dx; *dy g_dirQueue[g_dirHead].dy; g_dirHead (g_dirHead 1) % DIR_QUEUE_SIZE; g_dirCount--; g_curDx *dx; g_curDy *dy; return 1; }DIR_QUEUE_SIZE取 4 是个经验值。取 2 的话玩家快速连按三次就会丢指令取 8 又太长玩家误触之后要等好几步蛇才转回来手感发黏。4 大概对应人手指在 200 毫秒内能按出的有效次数。PushDir里那个refDx/refDy的替换是整个函数的关键。没有它上例中的左会被误判有了它左是相对上判断的合法入队。TickGame里每步开头调一次PopDir拿到方向再推进蛇头队列为空就沿当前方向继续。还要提醒一点这个工程里不要混用GetAsyncKeyState轮询。消息队列和异步键盘状态是两套机制同时用会出现消息说按了左异步状态说当前按着上的矛盾最终表现是蛇的行为完全不可预测。方向一律走WM_KEYDOWN这是最省心的选择。4. 双缓冲渲染GDI 对象不释放玩十分钟就卡死4.1 闪屏的根因不是画得慢是画了两遍用BeginPaint拿到的窗口 DC 直接绘制会看到明显的闪烁。原因是每次绘制都分两个可见阶段先填背景色把整屏刷掉再画蛇。两阶段之间有个几毫秒的窗口期人眼能捕捉到于是看到的是屏幕一黑一亮。WM_ERASEBKGND返回 1 能去掉填充背景那一步但如果绘制本身比较重蛇身一个个格子画过去还是会看到撕裂。彻底的办法是双缓冲所有绘制先画到内存 DC最后一次BitBlt整体拷到屏幕。这样屏幕上只会发生一次像素变化中间过程完全不可见。4.2 内存 DC 的正确建法只用窗口 DC 创建退出时必须销毁// render.cpp —— 双缓冲的创建、复用与销毁 #include windows.h static HDC g_memDC NULL; static HBITMAP g_memBmp NULL; static HBITMAP g_oldBmp NULL; static int g_bufW 0; static int g_bufH 0; static void ReleaseBackBuffer(void) { if (g_memDC) { if (g_oldBmp) SelectObject(g_memDC, g_oldBmp); // 先还原再删 DC DeleteDC(g_memDC); g_memDC NULL; g_oldBmp NULL; } if (g_memBmp) { DeleteObject(g_memBmp); g_memBmp NULL; } g_bufW g_bufH 0; } static int EnsureBackBuffer(HDC hdcRef, int w, int h) { if (g_memDC g_bufW w g_bufH h) return 1; // 尺寸没变就复用 ReleaseBackBuffer(); g_memDC CreateCompatibleDC(hdcRef); if (!g_memDC) return 0; // 必须用窗口 DC 创建位图不能用刚建好的 memDC那个只有 1x1 单色 g_memBmp CreateCompatibleBitmap(hdcRef, w, h); if (!g_memBmp) { DeleteDC(g_memDC); g_memDC NULL; return 0; } g_oldBmp (HBITMAP)SelectObject(g_memDC, g_memBmp); g_bufW w; g_bufH h; return 1; } void RenderGame(HWND hWnd) { HDC hdc; PAINTSTRUCT ps; RECT rc; GetClientRect(hWnd, rc); if (!EnsureBackBuffer(GetDC(hWnd), rc.right, rc.bottom)) return; DrawScene(g_memDC); // 全部画到内存 hdc BeginPaint(hWnd, ps); BitBlt(hdc, 0, 0, rc.right, rc.bottom, g_memDC, 0, 0, SRCCOPY); // 一次性上屏 EndPaint(hWnd, ps); }三个容易写错的地方。CreateCompatibleBitmap的第一个参数必须是窗口 DC 或者屏幕 DC。如果传g_memDC得到的是一个 1x1 的单色位图因为你刚CreateCompatibleDC的时候它里面默认就是那个。这个错误不会报任何错只是画出来全黑排查起来很费时间。SelectObject之前选进去的位图句柄要存下来删 DC 之前先换回去。不换回去直接DeleteDC也能过但位图会一直挂在 DC 上删不掉运行久了 GDI 句柄数会缓慢增长。RenderGame里GetDC(hWnd)拿的 DC 只是为了拿尺寸和像素格式用完应该ReleaseDC。不过如果EnsureBackBuffer之后尺寸不变每次都会走快速返回分支不会重复创建实际泄漏风险不大。追求严谨的话把窗口尺寸在WM_CREATE时记到全局变量里直接用那两个数就行。4.3 蛇身、食物和道具的绘制策略对比绘制方式的选择直接影响增强玩法的扩展成本。下面几种我都试过方式单次绘制开销扩展性适用场景FillRect纯色方格低每格一次差只能靠颜色区分原型阶段、逻辑验证RoundRect圆角中每格两次 API一般蛇身想要圆润感位图贴图BitBlt低每格一次好可以直接换素材正式版、多套皮肤位图加AlphaBlend中高最好半透明道具特殊道具、闪烁效果我的做法是原型期一律用FillRect逻辑跑通了再换贴图。下面这个函数是过渡期最常用的// draw_cell.cpp —— 一次性缓存画刷避免每帧创建 #define BRUSH_COUNT 6 static HBRUSH g_brushes[BRUSH_COUNT] { NULL }; static COLORREF g_brushColors[BRUSH_COUNT] { 0 }; static HBRUSH GetCachedBrush(int slot, COLORREF color) { if (slot 0 || slot BRUSH_COUNT) return NULL; if (g_brushes[slot] g_brushColors[slot] color) return g_brushes[slot]; // 颜色没变直接复用 if (g_brushes[slot]) DeleteObject(g_brushes[slot]); g_brushes[slot] CreateSolidBrush(color); g_brushColors[slot] color; return g_brushes[slot]; } void DrawCell(HDC dc, int gx, int gy, int slot, COLORREF color) { RECT rc; HBRUSH br GetCachedBrush(slot, color); if (!br) return; rc.left gx * CELL_SIZE 1; rc.top gy * CELL_SIZE 1; rc.right rc.left CELL_SIZE - 2; rc.bottom rc.top CELL_SIZE - 2; FillRect(dc, rc, br); } void DestroyCellBrushes(void) { int i; for (i 0; i BRUSH_COUNT; i) { if (g_brushes[i]) { DeleteObject(g_brushes[i]); g_brushes[i] NULL; } } }给每类元素分配固定的 slot蛇头 0、蛇身 1、食物 2、加速道具 3、障碍 4、背景网格 5。颜色变化时函数内部自动重建画刷不变化就一直复用。相比每帧CreateSolidBrush再DeleteObject这种做法在 30x22 的网格上能把每帧的 GDI 调用量砍掉一大半。DestroyCellBrushes必须在窗口销毁前调用放在WM_DESTROY里。这份清理代码就是我一直说的后悔药写的时候觉得多余不写的时候程序会安静地泄漏直到某一局玩到一半窗口变白。5. 避坑VC6.0 贪吃蛇增强版上线前必须排掉的 5 个故障5.1 Debug 正常、Release 下蛇偶尔穿墙或者逻辑错乱现象同一份代码Debug 编译玩一小时不出问题Release 编译十几局里总有那么一两次蛇从墙边穿过去或者吃到食物不计分。原因通常有两个。一是未初始化变量VC6.0 的 Debug 构建会把栈内存填成 0xCC未初始化变量恰好取出一个看起来合理的值Release 的 /O2 优化下这块内存是上次函数残留的垃圾值完全随机。二是浮点精度差异x87 协处理器内部是 80 位精度Debug 下每次赋值会写回 64 位内存Release 下编译器可能把中间结果一直留在寄存器里导致g_accumulator g_stepSec这个边界判断在两个版本下结果不同。解决办法是把警告级别调到 Level 4把 C4700使用了未初始化的局部变量当成错误处理。更根本的是把浮点累加器换成整数毫秒累加器用DWORD存毫秒GetTickCount或者把QueryPerformanceCounter的差值换算成整数毫秒。整数运算在两种构建下行为完全一致这类只在 Release 复现的问题会直接消失。5.2 玩十几分钟后帧率肉眼可见地掉窗口最终变白现象开局流畅玩五分钟后蛇移动开始有拖影十分钟后整局卡成幻灯片任务管理器里看到进程的 GDI 对象数一路往上爬。原因是 GDI 句柄泄漏。最常见的写法是在绘制循环里CreateSolidBrush、CreateFont或CreatePen画完忘了DeleteObject或者SelectObject之后没把旧对象换回去。Windows 每个进程的 GDI 句柄上限默认是 10000每帧泄漏几个一千多帧就撞上限了之后所有绘制调用全部失败。排查方法是打开任务管理器在查看 → 选择列里勾上 GDI 对象跑一局盯着这个数看。正常应该在几十到一两百之间小幅波动如果单调上升就是泄漏。修复方式是把所有画刷、字体、画笔提到初始化阶段创建绘制循环里只SelectObject退出时统一DeleteObject就是第 4 章GetCachedBrush那套做法。5.3 方向键时灵时不灵或者按一下蛇自己掉头现象快速连续按方向键有时某个按键完全没反应偶尔蛇会在没按反向键的情况下自己撞死。原因有三层。第一层是系统自动重复按住方向键不放Windows 每秒发大约 30 条WM_KEYDOWN如果不过滤 bit30队列会被重复指令灌满新指令进不来。第二层是队列里没做去重同一个方向连入四次玩家真正想按的转弯被挤掉。第三层是刷新时机如果PushDir直接改蛇头方向而不是入队一个 tick 内收到两条指令时后一条会覆盖前一条蛇的实际路径和玩家预期不符。解决方式按第 3 章那套来WM_KEYDOWN里判断lParam 0x40000000过滤重复消息PushDir里做同向去重和反向拦截比较对象用队列末尾而不是蛇头方向。另外确认工程里没有混进GetAsyncKeyState轮询两套输入机制同时存在时行为是不可预测的。5.4 AltTab 切出去再切回来蛇瞬移好几格直接撞死现象老板走过来你切出去三十秒后切回来游戏已经结束了。原因是固定步长主循环的累加器在窗口失焦期间仍在累加。虽然PeekMessage拿不到键盘消息但循环本身还在跑TakeFrameSeconds每帧都返回真实流逝的时间累加器迅速攒到几百个 step一回焦点while循环连跑几百次TickGame蛇一步撞墙。解决分两层。第一层是TakeFrameSeconds里的if (dt 0.25) dt 0.25;这一行把单帧最大时间钳到 250 毫秒防止长时间挂起后一次性补太多。第二层是处理WM_ACTIVATE收到WA_INACTIVE时暂停游戏并把累加器清零收到WA_ACTIVE时重新InitClock。两处配合切出去再回来蛇会从原地继续而不是瞬移。5.5 SetTimer 设 50 毫秒实测每步六七十毫秒越玩越慢现象明明把定时器设成 50 毫秒蛇的实际移动间隔测出来是 60 到 70 毫秒而且游戏运行越久偏差越大。原因是SetTimer的精度受系统时钟节拍限制默认节拍 15.6 毫秒50 毫秒的请求会被向上取整到最近的节拍边界。同时WM_TIMER是低优先级消息绘制繁忙时会被合并丢弃导致实际步数少于预期。累积下来一分钟就少走十几步。解决办法是彻底不用SetTimer驱动逻辑换成第 3 章的累加器方案。如果因为某些原因必须用定时器比如老代码改不动可以在程序启动时调timeBeginPeriod(1)把系统节拍提到 1 毫秒退出时记得timeEndPeriod(1)恢复否则会白白增加整机功耗。这个函数在winmm.lib里就是第 2 章项目设置里要追加的那个库。6. 增强玩法的参数化与验收INI 关卡表加一帧耗时实测增强版做加法时最容易失控的是数值散落在代码各处。加速道具持续几秒、每吃几个食物提速一次、障碍物占多少格这些如果硬编码在TickGame里调一次关卡就要重新编译一次。我的习惯是把它们全部抽到外部 INI用GetPrivateProfileInt读。// level_ini.cpp —— 关卡参数外部化改数值不用重编 #include windows.h static char g_iniPath[MAX_PATH] level.ini; static int ReadInt(const char* section, const char* key, int def) { return (int)GetPrivateProfileInt(section, key, def, g_iniPath); } void LoadLevelConfig(int level) { char sec[16]; wsprintf(sec, Level%d, level); // Level1、Level2…… 对应 INI 里的节名 SetGameSpeed(ReadInt(sec, StepMs, 120) / 1000.0); g_gridW ReadInt(sec, GridW, 30); g_gridH ReadInt(sec, GridH, 22); g_obstacleNum ReadInt(sec, Obstacle, 0); g_boostMs ReadInt(sec, BoostMs, 3000); g_wrapWall ReadInt(sec, WrapWall, 0); // 1 表示穿墙 }INI 文件长这样改完存盘重开游戏就生效[Level1] StepMs160 GridW30 GridH22 Obstacle0 BoostMs3000 WrapWall0 [Level2] StepMs120 GridW30 GridH22 Obstacle6 BoostMs2500 WrapWall0 [Level3] StepMs100 GridW32 GridH24 Obstacle12 BoostMs2000 WrapWall1几个参数的边界要守住StepMs低于 60 会把游戏变得不可玩代码里SetGameSpeed已经有下限保护Obstacle超过网格面积的 15% 会导致食物经常刷在死角玩家明明没撞墙却无路可走WrapWall1时蛇头坐标要用取模而不是边界判断x (x g_gridW) % g_gridW这一句要处理负方向负数取模在 C 里结果还是负的。验收环节我最看重两个数一帧耗时和逻辑确定性。一帧耗时可以在RenderGame结束处打点用QueryPerformanceCounter取绘制前后差值累计一百帧算平均OutputDebugString打到调试窗口。目标是在目标机器上平均绘制耗时低于 3 毫秒这样即使按 30 毫秒一个 step 跑也留足了余量。如果超过 5 毫秒先查是不是有 GDI 对象在每帧创建再看是不是蛇身长度增长后逐格FillRect调用量太大后者可以改成对连续格子合并成一个大矩形一次填充。逻辑确定性用回放验证。把食物生成改成用固定种子的伪随机种子写在 INI 里然后录一段方向输入序列用同一个种子跑两遍两遍的最终得分、蛇长、死亡位置必须完全一致。这个检查能抓出绝大多数跨版本、跨构建的隐藏 bug——如果 Debug 和 Release 跑同一种子得出不同结果那就是 5.1 里说的未初始化变量或浮点精度问题。我自己在这类老工程上踩得最深的一次是把关卡参数写在一堆#define里调到第 8 关时发现有二十几个宏互相依赖改一个速度导致障碍密度跟着变查了一晚上才理清楚依赖链。从那以后定了一条规矩凡是玩家能感知到的数值一律进 INI凡是要进 INI 的数值代码里不再留第二份。这套习惯换到别的老工具链上一样好使。希望帮到你。本文还有配套的精品资源点击获取
简介面向 C 初学者与 Windows 游戏开发入门者的贪吃蛇增强版 VC6.0 工程源码以经典贪吃蛇玩法为载体演示如何用面向对象方式拆分蛇体与界面逻辑蛇类封装位置、长度及移动增长行为蛇身采用单链表动态增删节点配合 MFC 消息处理键盘输入、定时器控制移动速度、CWnd 绘图与开始、运行、暂停、结束状态管理并含基本异常退出处理。压缩包共 58 个文件、约 8.98MB包含 5 个 cpp 与 6 个头文件等核心源码dsp、dsw 工程配置bmp、ico、rc 等界面资源以及 obj、pdb、idb、sbr 等编译调试中间文件可直接在 VC6.0 中打开参照。已有 179 人学习适合对照梳理链表操作、MFC 消息循环与定时器用法也可作为课程设计或小型游戏项目的改造底本。1. 贪吃蛇这个题目难在增强两个字贪吃蛇在 VC6.0 里做很多人第一反应是两小时能写完。真动手就会发现基础版确实两小时但一旦开始加东西——加速道具、穿墙、障碍关卡、关卡配置外置、音效——难度全在第二阶段。蛇的移动逻辑本身十分钟能写对真正制造麻烦的是蛇跑得越快越容易撞到自己、窗口切出去再切回来蛇直接撞墙、玩十分钟帧率掉到个位数、按一次方向键它自己掉头。这些都不是算法问题而是 VC6.0 那套工具链和 Win32 消息模型自带的边界。这篇笔记讲的是一条能落地的路线用 Win32 空工程搭骨架用 QueryPerformanceCounter 做固定步长主循环用双缓冲把闪烁压掉再把增强玩法的数值抽成外部配置表。适合手上有 VC6.0 还不想换、又想把贪吃蛇从能跑做到能玩的人。2. VC6.0 工程骨架从空工程到画出第一格蛇身2.1 为什么这个场景下不建议走 MFC 向导新建工程时VC6.0 的 MFC AppWizard 很省事点几下就能得到一个能跑的窗口。但对贪吃蛇这种单窗口、单线程、逻辑密集的小程序向导生成的 Doc/View 结构、消息映射宏、CWinApp 派生类全是需要绕过去才能工作的负担。更麻烦的是调试出了问题时调用栈里一大半是 MFC 自己的框架代码真正的业务函数被埋在最底下。Win32 SDK 空工程的好处是全部透明。WinMain、窗口过程、消息循环、绘制一共几个函数出问题一眼能定位。代价是字符串处理、文件对话框这些都要自己写但对贪吃蛇这种量级的程序用到的也就 CString 之外的一点点。我一般会先在 Win32 空工程里把游戏跑通真需要配置对话框了再单独引一个 MFC 的 CFileDialog 进来两者混用完全没问题。如果只是想把移动逻辑先验证一遍VC6.0 里的 Win32 Console Application 也够用system(cls)加_kbhit()、_getch()二十行就能看到蛇在跑。逻辑对了再搬进窗口工程能省不少来回。2.2 新建工程和四个必须检查的项目设置File → New → Projects → Win32 Application工程名随便起下一步选An empty project不要选那个带示例代码的。建完之后右键工程加一个snake_main.cpp然后在 Project → Settings 里把这四处改掉这四处不改后面一定出问题设置项位置值不改的后果运行库C/C → Code Generation → Use run-time libraryDebug Multithreaded / Multithreaded和某些静态库混用时链接报重定义附加库Link → Object/library modules追加winmm.lib msimg32.libPlaySound、AlphaBlend 链接报 LNK2001预处理器C/C → Preprocessor definitions保留WIN32;_DEBUG删掉_CONSOLE保留 _CONSOLE 时 WinMain 入口可能对不上警告级别C/C → General → Warning levelLevel 4未初始化变量这类坑要等到 Release 才炸字符集方面VC6.0 默认就是 ANSI标题里这种情况我不建议开 UNICODE。开了之后所有字符串字面量都要加_T()CreateWindow要换CreateWindowW而贪吃蛇的文本量小到根本不值得这套开销。保持 ANSI字符串直接用char*和sprintf、fopen这些函数配合最顺。还有一个容易被忽略的点VC6.0 的编译器允许for (int i 0; ...)但i的作用域会泄漏到循环外。写起来没问题读代码时容易误以为是个新变量。我一般要求团队在这个工程里把循环变量声明在块首风格统一别人接手时不用猜。2.3 最小可运行骨架WinMain 与窗口过程的职责切分下面这段是整个工程的地基直接能编过。注意它已经为后面三章预留了接口PushDir处理方向RunGameLoop替换掉传统的GetMessage循环。// snake_main.cpp —— VC6 Win32 空工程的最小骨架 #include windows.h #define CELL_SIZE 16 #define GRID_W 30 #define GRID_H 22 void PushDir(int dx, int dy); // 第 3 章实现 void RunGameLoop(HWND hWnd); // 第 3 章实现 LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch (msg) { case WM_ERASEBKGND: return 1; // 背景自己画告诉系统别再擦一遍省一次闪烁 case WM_KEYDOWN: // 0x40000000 是 lParam 的 bit30为 1 表示这是按住不放产生的重复消息 if ((lParam 0x40000000) 0) { switch (wParam) { case VK_UP: PushDir( 0, -1); break; case VK_DOWN: PushDir( 0, 1); break; case VK_LEFT: PushDir(-1, 0); break; case VK_RIGHT: PushDir( 1, 0); break; } } return 0; case WM_DESTROY: PostQuitMessage(0); return 0; } return DefWindowProc(hWnd, msg, wParam, lParam); } int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow) { WNDCLASS wc; HWND hWnd; RECT rc; DWORD dwStyle; ZeroMemory(wc, sizeof(wc)); wc.lpfnWndProc WndProc; wc.hInstance hInst; wc.hCursor LoadCursor(NULL, IDC_ARROW); wc.hbrBackground (HBRUSH)GetStockObject(BLACK_BRUSH); wc.lpszClassName SnakeWnd; if (!RegisterClass(wc)) return 0; // 客户区锁死成 30x22 格窗口外框交给 AdjustWindowRect 算别手填数字 dwStyle WS_OVERLAPPEDWINDOW ~WS_THICKFRAME ~WS_MAXIMIZEBOX; rc.left 0; rc.top 0; rc.right GRID_W * CELL_SIZE; rc.bottom GRID_H * CELL_SIZE; AdjustWindowRect(rc, dwStyle, FALSE); hWnd CreateWindow(SnakeWnd, Snake, dwStyle, CW_USEDEFAULT, CW_USEDEFAULT, rc.right - rc.left, rc.bottom - rc.top, NULL, NULL, hInst, NULL); if (!hWnd) return 0; ShowWindow(hWnd, nShow); UpdateWindow(hWnd); RunGameLoop(hWnd); return 0; }几个参数的取舍说清楚。CELL_SIZE取 16 是因为 16 像素格子配 30x22 的网格刚好 480x352 的客户区在 1024x768 上不至于顶满屏幕取 20 或 24 会让窗口偏大取 8 则蛇身细节看不清。GRID_W和GRID_H决定的是可玩面积30x22 意味着蛇最长 660 格对普通难度够用做关卡时这两项应该从 INI 读而不是写死第 6 章会改。WM_ERASEBKGND直接返回 1 这一行很关键。默认情况下 Windows 会在WM_PAINT之前先用背景刷子擦一遍窗口这一擦就是一次全屏填充和你的绘制之间有一个可见间隙闪烁有一半来自这里。返回非零值告诉系统我已经处理了配合第 4 章的双缓冲闪烁能压到看不见。WM_KEYDOWN里过滤 bit30 是防止系统自动重复灌满方向队列。按住方向键不放时Windows 会以大约每秒 30 次的频率重复发WM_KEYDOWN如果每个都入队队列瞬间就满了玩家真正的新指令反而被丢弃。3. 主循环与输入把 SetTimer 换成 QueryPerformanceCounter 固定步长3.1 SetTimer 的三个坑精度、消息优先级、重复创建新手写贪吃蛇最自然的做法是SetTimer(hWnd, 1, 100, NULL)然后在WM_TIMER里让蛇走一格。这个方案能跑但只要开始调速度就会撞墙。第一个坑是精度。SetTimer的定时精度受系统时钟节拍限制默认节拍大约 15.6 毫秒你设 10ms 实际可能 15ms设 100ms 实际可能 109ms而且这个误差会累积。想让蛇跑得越来越快时你得不断KillTimer再SetTimer两次调用之间就有时间漏洞。第二个坑是消息优先级。WM_TIMER是低优先级消息只有在消息队列里没有其他消息时才会被生成。如果你的程序在WM_TIMER里做了比较重的绘制导致处理时间超过一个 tick 周期系统不会给你补上错过的 tick而是直接合并掉。表现出来就是蛇越跑越慢玩家会觉得游戏卡了。第三个坑是重复创建。SetTimer用同一个 ID 再调一次不会重置而是替换但如果中间KillTimer失败或者 ID 搞混了就可能出现两个定时器同时驱动蛇一步走两格。这些不是玄学是 Win32 定时器的设计取舍。它面向的是 UI 刷新这种大致按时就行的场景不是游戏循环。3.2 用 PeekMessage 加高精度计时器做固定步长正确做法是把消息处理和逻辑推进拆开消息有就处理没有就推进游戏。下面这段是主循环的全部。// game_loop.cpp —— 固定步长主循环VC6 可直接编译 #include windows.h static LARGE_INTEGER g_qpcFreq; static LARGE_INTEGER g_qpcLast; static double g_accumulator 0.0; static double g_stepSec 0.12; // 每步 120ms关卡表里改这个值 void TickGame(void); // 只推进逻辑不做绘制 void RenderGame(HWND hWnd); // 只做绘制不改逻辑 static void InitClock(void) { QueryPerformanceFrequency(g_qpcFreq); QueryPerformanceCounter(g_qpcLast); g_accumulator 0.0; } static double TakeFrameSeconds(void) { LARGE_INTEGER now; double dt; QueryPerformanceCounter(now); dt (double)(now.QuadPart - g_qpcLast.QuadPart) / (double)g_qpcFreq.QuadPart; g_qpcLast now; if (dt 0.25) dt 0.25; // 调试断点、切窗口回来时别让蛇瞬移几十格 return dt; } void SetGameSpeed(double secPerStep) { if (secPerStep 0.03) secPerStep 0.03; // 下限 30ms再快人眼跟不上 g_stepSec secPerStep; } void RunGameLoop(HWND hWnd) { MSG msg; InitClock(); for (;;) { if (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) { if (msg.message WM_QUIT) break; TranslateMessage(msg); DispatchMessage(msg); } else { g_accumulator TakeFrameSeconds(); while (g_accumulator g_stepSec) { TickGame(); g_accumulator - g_stepSec; } RenderGame(hWnd); Sleep(1); // 让出时间片别把单核 CPU 跑满 } } }逻辑说明分三块。PeekMessage替代GetMessage。GetMessage在没有消息时会阻塞游戏就停了PeekMessage拿不到消息立刻返回程序可以继续往下走。PM_REMOVE表示取到就出队不加的话同一条消息会被反复处理。g_accumulator是累加器模式的核。每帧把真实流逝的时间加进去只要够一个 step 就推进一次逻辑并扣掉。这样逻辑推进的频率严格由g_stepSec决定和渲染帧率解耦。渲染可能跑到几百帧但蛇的移动仍然是每 120 毫秒一格。如果某一帧耗时比较长导致累加器攒了三个 stepwhile会把它们补上蛇走三格——这比丢掉 tick 更符合玩家预期。Sleep(1)这行很多人会删掉觉得浪费。删掉的后果是在没有消息时循环会满载跑满一个核风扇狂转笔记本上还可能导致降频。加 1 毫秒的让出对 120 毫秒一个 step 的游戏毫无影响。参数上g_stepSec的典型取值在 0.08 到 0.20 之间0.20 是慢速适合新手关卡0.12 是标准0.08 已经偏快需要玩家反应低于 0.06 基本没法玩。下限保护设在 0.03是为了防止关卡表配错一个 0 把游戏跑成幻灯片。3.3 方向输入队列一帧内连按两次为什么会撞死自己即使主循环改对了输入还有一个隐蔽的坑。假设蛇向右移动玩家在一个 tick 内快速按下上再按下左。直觉上这是合法的先转上再转左蛇头应该绕个弯。但如果逻辑是每次收到按键就和当前蛇头方向比较那么按左的时候蛇头方向还是右左和右相反被判定为掉头而丢弃玩家会觉得按键失灵。正确做法是把方向指令排成队列比较对象是队列末尾的方向而不是蛇头当前方向。// input_queue.cpp —— 方向指令环形队列 #define DIR_QUEUE_SIZE 4 struct DirCmd { int dx; int dy; }; static DirCmd g_dirQueue[DIR_QUEUE_SIZE]; static int g_dirHead 0; // 读位置 static int g_dirTail 0; // 写位置 static int g_dirCount 0; static int g_curDx 1; // 当前生效方向初始向右 static int g_curDy 0; void PushDir(int dx, int dy) { int refDx g_curDx; int refDy g_curDy; // 队列非空时比较对象换成队列最后一个方向 if (g_dirCount 0) { int last (g_dirTail DIR_QUEUE_SIZE - 1) % DIR_QUEUE_SIZE; refDx g_dirQueue[last].dx; refDy g_dirQueue[last].dy; } if (dx -refDx dy -refDy) return; // 180 度掉头直接丢弃 if (dx refDx dy refDy) return; // 同方向不重复入队 if (g_dirCount DIR_QUEUE_SIZE) return; // 队列满丢弃后来的 g_dirQueue[g_dirTail].dx dx; g_dirQueue[g_dirTail].dy dy; g_dirTail (g_dirTail 1) % DIR_QUEUE_SIZE; g_dirCount; } int PopDir(int* dx, int* dy) { if (g_dirCount 0) return 0; *dx g_dirQueue[g_dirHead].dx; *dy g_dirQueue[g_dirHead].dy; g_dirHead (g_dirHead 1) % DIR_QUEUE_SIZE; g_dirCount--; g_curDx *dx; g_curDy *dy; return 1; }DIR_QUEUE_SIZE取 4 是个经验值。取 2 的话玩家快速连按三次就会丢指令取 8 又太长玩家误触之后要等好几步蛇才转回来手感发黏。4 大概对应人手指在 200 毫秒内能按出的有效次数。PushDir里那个refDx/refDy的替换是整个函数的关键。没有它上例中的左会被误判有了它左是相对上判断的合法入队。TickGame里每步开头调一次PopDir拿到方向再推进蛇头队列为空就沿当前方向继续。还要提醒一点这个工程里不要混用GetAsyncKeyState轮询。消息队列和异步键盘状态是两套机制同时用会出现消息说按了左异步状态说当前按着上的矛盾最终表现是蛇的行为完全不可预测。方向一律走WM_KEYDOWN这是最省心的选择。4. 双缓冲渲染GDI 对象不释放玩十分钟就卡死4.1 闪屏的根因不是画得慢是画了两遍用BeginPaint拿到的窗口 DC 直接绘制会看到明显的闪烁。原因是每次绘制都分两个可见阶段先填背景色把整屏刷掉再画蛇。两阶段之间有个几毫秒的窗口期人眼能捕捉到于是看到的是屏幕一黑一亮。WM_ERASEBKGND返回 1 能去掉填充背景那一步但如果绘制本身比较重蛇身一个个格子画过去还是会看到撕裂。彻底的办法是双缓冲所有绘制先画到内存 DC最后一次BitBlt整体拷到屏幕。这样屏幕上只会发生一次像素变化中间过程完全不可见。4.2 内存 DC 的正确建法只用窗口 DC 创建退出时必须销毁// render.cpp —— 双缓冲的创建、复用与销毁 #include windows.h static HDC g_memDC NULL; static HBITMAP g_memBmp NULL; static HBITMAP g_oldBmp NULL; static int g_bufW 0; static int g_bufH 0; static void ReleaseBackBuffer(void) { if (g_memDC) { if (g_oldBmp) SelectObject(g_memDC, g_oldBmp); // 先还原再删 DC DeleteDC(g_memDC); g_memDC NULL; g_oldBmp NULL; } if (g_memBmp) { DeleteObject(g_memBmp); g_memBmp NULL; } g_bufW g_bufH 0; } static int EnsureBackBuffer(HDC hdcRef, int w, int h) { if (g_memDC g_bufW w g_bufH h) return 1; // 尺寸没变就复用 ReleaseBackBuffer(); g_memDC CreateCompatibleDC(hdcRef); if (!g_memDC) return 0; // 必须用窗口 DC 创建位图不能用刚建好的 memDC那个只有 1x1 单色 g_memBmp CreateCompatibleBitmap(hdcRef, w, h); if (!g_memBmp) { DeleteDC(g_memDC); g_memDC NULL; return 0; } g_oldBmp (HBITMAP)SelectObject(g_memDC, g_memBmp); g_bufW w; g_bufH h; return 1; } void RenderGame(HWND hWnd) { HDC hdc; PAINTSTRUCT ps; RECT rc; GetClientRect(hWnd, rc); if (!EnsureBackBuffer(GetDC(hWnd), rc.right, rc.bottom)) return; DrawScene(g_memDC); // 全部画到内存 hdc BeginPaint(hWnd, ps); BitBlt(hdc, 0, 0, rc.right, rc.bottom, g_memDC, 0, 0, SRCCOPY); // 一次性上屏 EndPaint(hWnd, ps); }三个容易写错的地方。CreateCompatibleBitmap的第一个参数必须是窗口 DC 或者屏幕 DC。如果传g_memDC得到的是一个 1x1 的单色位图因为你刚CreateCompatibleDC的时候它里面默认就是那个。这个错误不会报任何错只是画出来全黑排查起来很费时间。SelectObject之前选进去的位图句柄要存下来删 DC 之前先换回去。不换回去直接DeleteDC也能过但位图会一直挂在 DC 上删不掉运行久了 GDI 句柄数会缓慢增长。RenderGame里GetDC(hWnd)拿的 DC 只是为了拿尺寸和像素格式用完应该ReleaseDC。不过如果EnsureBackBuffer之后尺寸不变每次都会走快速返回分支不会重复创建实际泄漏风险不大。追求严谨的话把窗口尺寸在WM_CREATE时记到全局变量里直接用那两个数就行。4.3 蛇身、食物和道具的绘制策略对比绘制方式的选择直接影响增强玩法的扩展成本。下面几种我都试过方式单次绘制开销扩展性适用场景FillRect纯色方格低每格一次差只能靠颜色区分原型阶段、逻辑验证RoundRect圆角中每格两次 API一般蛇身想要圆润感位图贴图BitBlt低每格一次好可以直接换素材正式版、多套皮肤位图加AlphaBlend中高最好半透明道具特殊道具、闪烁效果我的做法是原型期一律用FillRect逻辑跑通了再换贴图。下面这个函数是过渡期最常用的// draw_cell.cpp —— 一次性缓存画刷避免每帧创建 #define BRUSH_COUNT 6 static HBRUSH g_brushes[BRUSH_COUNT] { NULL }; static COLORREF g_brushColors[BRUSH_COUNT] { 0 }; static HBRUSH GetCachedBrush(int slot, COLORREF color) { if (slot 0 || slot BRUSH_COUNT) return NULL; if (g_brushes[slot] g_brushColors[slot] color) return g_brushes[slot]; // 颜色没变直接复用 if (g_brushes[slot]) DeleteObject(g_brushes[slot]); g_brushes[slot] CreateSolidBrush(color); g_brushColors[slot] color; return g_brushes[slot]; } void DrawCell(HDC dc, int gx, int gy, int slot, COLORREF color) { RECT rc; HBRUSH br GetCachedBrush(slot, color); if (!br) return; rc.left gx * CELL_SIZE 1; rc.top gy * CELL_SIZE 1; rc.right rc.left CELL_SIZE - 2; rc.bottom rc.top CELL_SIZE - 2; FillRect(dc, rc, br); } void DestroyCellBrushes(void) { int i; for (i 0; i BRUSH_COUNT; i) { if (g_brushes[i]) { DeleteObject(g_brushes[i]); g_brushes[i] NULL; } } }给每类元素分配固定的 slot蛇头 0、蛇身 1、食物 2、加速道具 3、障碍 4、背景网格 5。颜色变化时函数内部自动重建画刷不变化就一直复用。相比每帧CreateSolidBrush再DeleteObject这种做法在 30x22 的网格上能把每帧的 GDI 调用量砍掉一大半。DestroyCellBrushes必须在窗口销毁前调用放在WM_DESTROY里。这份清理代码就是我一直说的后悔药写的时候觉得多余不写的时候程序会安静地泄漏直到某一局玩到一半窗口变白。5. 避坑VC6.0 贪吃蛇增强版上线前必须排掉的 5 个故障5.1 Debug 正常、Release 下蛇偶尔穿墙或者逻辑错乱现象同一份代码Debug 编译玩一小时不出问题Release 编译十几局里总有那么一两次蛇从墙边穿过去或者吃到食物不计分。原因通常有两个。一是未初始化变量VC6.0 的 Debug 构建会把栈内存填成 0xCC未初始化变量恰好取出一个看起来合理的值Release 的 /O2 优化下这块内存是上次函数残留的垃圾值完全随机。二是浮点精度差异x87 协处理器内部是 80 位精度Debug 下每次赋值会写回 64 位内存Release 下编译器可能把中间结果一直留在寄存器里导致g_accumulator g_stepSec这个边界判断在两个版本下结果不同。解决办法是把警告级别调到 Level 4把 C4700使用了未初始化的局部变量当成错误处理。更根本的是把浮点累加器换成整数毫秒累加器用DWORD存毫秒GetTickCount或者把QueryPerformanceCounter的差值换算成整数毫秒。整数运算在两种构建下行为完全一致这类只在 Release 复现的问题会直接消失。5.2 玩十几分钟后帧率肉眼可见地掉窗口最终变白现象开局流畅玩五分钟后蛇移动开始有拖影十分钟后整局卡成幻灯片任务管理器里看到进程的 GDI 对象数一路往上爬。原因是 GDI 句柄泄漏。最常见的写法是在绘制循环里CreateSolidBrush、CreateFont或CreatePen画完忘了DeleteObject或者SelectObject之后没把旧对象换回去。Windows 每个进程的 GDI 句柄上限默认是 10000每帧泄漏几个一千多帧就撞上限了之后所有绘制调用全部失败。排查方法是打开任务管理器在查看 → 选择列里勾上 GDI 对象跑一局盯着这个数看。正常应该在几十到一两百之间小幅波动如果单调上升就是泄漏。修复方式是把所有画刷、字体、画笔提到初始化阶段创建绘制循环里只SelectObject退出时统一DeleteObject就是第 4 章GetCachedBrush那套做法。5.3 方向键时灵时不灵或者按一下蛇自己掉头现象快速连续按方向键有时某个按键完全没反应偶尔蛇会在没按反向键的情况下自己撞死。原因有三层。第一层是系统自动重复按住方向键不放Windows 每秒发大约 30 条WM_KEYDOWN如果不过滤 bit30队列会被重复指令灌满新指令进不来。第二层是队列里没做去重同一个方向连入四次玩家真正想按的转弯被挤掉。第三层是刷新时机如果PushDir直接改蛇头方向而不是入队一个 tick 内收到两条指令时后一条会覆盖前一条蛇的实际路径和玩家预期不符。解决方式按第 3 章那套来WM_KEYDOWN里判断lParam 0x40000000过滤重复消息PushDir里做同向去重和反向拦截比较对象用队列末尾而不是蛇头方向。另外确认工程里没有混进GetAsyncKeyState轮询两套输入机制同时存在时行为是不可预测的。5.4 AltTab 切出去再切回来蛇瞬移好几格直接撞死现象老板走过来你切出去三十秒后切回来游戏已经结束了。原因是固定步长主循环的累加器在窗口失焦期间仍在累加。虽然PeekMessage拿不到键盘消息但循环本身还在跑TakeFrameSeconds每帧都返回真实流逝的时间累加器迅速攒到几百个 step一回焦点while循环连跑几百次TickGame蛇一步撞墙。解决分两层。第一层是TakeFrameSeconds里的if (dt 0.25) dt 0.25;这一行把单帧最大时间钳到 250 毫秒防止长时间挂起后一次性补太多。第二层是处理WM_ACTIVATE收到WA_INACTIVE时暂停游戏并把累加器清零收到WA_ACTIVE时重新InitClock。两处配合切出去再回来蛇会从原地继续而不是瞬移。5.5 SetTimer 设 50 毫秒实测每步六七十毫秒越玩越慢现象明明把定时器设成 50 毫秒蛇的实际移动间隔测出来是 60 到 70 毫秒而且游戏运行越久偏差越大。原因是SetTimer的精度受系统时钟节拍限制默认节拍 15.6 毫秒50 毫秒的请求会被向上取整到最近的节拍边界。同时WM_TIMER是低优先级消息绘制繁忙时会被合并丢弃导致实际步数少于预期。累积下来一分钟就少走十几步。解决办法是彻底不用SetTimer驱动逻辑换成第 3 章的累加器方案。如果因为某些原因必须用定时器比如老代码改不动可以在程序启动时调timeBeginPeriod(1)把系统节拍提到 1 毫秒退出时记得timeEndPeriod(1)恢复否则会白白增加整机功耗。这个函数在winmm.lib里就是第 2 章项目设置里要追加的那个库。6. 增强玩法的参数化与验收INI 关卡表加一帧耗时实测增强版做加法时最容易失控的是数值散落在代码各处。加速道具持续几秒、每吃几个食物提速一次、障碍物占多少格这些如果硬编码在TickGame里调一次关卡就要重新编译一次。我的习惯是把它们全部抽到外部 INI用GetPrivateProfileInt读。// level_ini.cpp —— 关卡参数外部化改数值不用重编 #include windows.h static char g_iniPath[MAX_PATH] level.ini; static int ReadInt(const char* section, const char* key, int def) { return (int)GetPrivateProfileInt(section, key, def, g_iniPath); } void LoadLevelConfig(int level) { char sec[16]; wsprintf(sec, Level%d, level); // Level1、Level2…… 对应 INI 里的节名 SetGameSpeed(ReadInt(sec, StepMs, 120) / 1000.0); g_gridW ReadInt(sec, GridW, 30); g_gridH ReadInt(sec, GridH, 22); g_obstacleNum ReadInt(sec, Obstacle, 0); g_boostMs ReadInt(sec, BoostMs, 3000); g_wrapWall ReadInt(sec, WrapWall, 0); // 1 表示穿墙 }INI 文件长这样改完存盘重开游戏就生效[Level1] StepMs160 GridW30 GridH22 Obstacle0 BoostMs3000 WrapWall0 [Level2] StepMs120 GridW30 GridH22 Obstacle6 BoostMs2500 WrapWall0 [Level3] StepMs100 GridW32 GridH24 Obstacle12 BoostMs2000 WrapWall1几个参数的边界要守住StepMs低于 60 会把游戏变得不可玩代码里SetGameSpeed已经有下限保护Obstacle超过网格面积的 15% 会导致食物经常刷在死角玩家明明没撞墙却无路可走WrapWall1时蛇头坐标要用取模而不是边界判断x (x g_gridW) % g_gridW这一句要处理负方向负数取模在 C 里结果还是负的。验收环节我最看重两个数一帧耗时和逻辑确定性。一帧耗时可以在RenderGame结束处打点用QueryPerformanceCounter取绘制前后差值累计一百帧算平均OutputDebugString打到调试窗口。目标是在目标机器上平均绘制耗时低于 3 毫秒这样即使按 30 毫秒一个 step 跑也留足了余量。如果超过 5 毫秒先查是不是有 GDI 对象在每帧创建再看是不是蛇身长度增长后逐格FillRect调用量太大后者可以改成对连续格子合并成一个大矩形一次填充。逻辑确定性用回放验证。把食物生成改成用固定种子的伪随机种子写在 INI 里然后录一段方向输入序列用同一个种子跑两遍两遍的最终得分、蛇长、死亡位置必须完全一致。这个检查能抓出绝大多数跨版本、跨构建的隐藏 bug——如果 Debug 和 Release 跑同一种子得出不同结果那就是 5.1 里说的未初始化变量或浮点精度问题。我自己在这类老工程上踩得最深的一次是把关卡参数写在一堆#define里调到第 8 关时发现有二十几个宏互相依赖改一个速度导致障碍密度跟着变查了一晚上才理清楚依赖链。从那以后定了一条规矩凡是玩家能感知到的数值一律进 INI凡是要进 INI 的数值代码里不再留第二份。这套习惯换到别的老工具链上一样好使。希望帮到你。本文还有配套的精品资源点击获取
