用C++和EasyX仿制超级马里奥：完整解析2D游戏开发核心机制

简介：这是一份基于C++语言与EasyX图形库，对经典《超级马里奥》进行还原仿制的完整项目源码包，适合正在学习游戏开发、图形编程或希望模仿经典游戏玩法的初学者和爱好者。项目已实现1-1、1-2、1-3三个完整关卡，涵盖移动、跳跃、加速/发射火球、下蹲/钻管道等核心操作，并配有项目说明文档，可直接在Visual Studio 2022与EasyX_20220901环境下编译运行。压缩包共239个文件，约10.6MB，素材与代码划分明确：163个PNG图片用于角色、场景和道具，25个MP3与1个WAV提供背景音乐和音效，21个C++头文件与21个源文件构成源码主体，另有ICO图标、过滤器与工程配置文件，方便按模块阅读。源码按事件处理、关卡场景、角色控制、怪物互动、墙体与道具等模块组织，配合说明文档可快速理解EasyX绘图与游戏循环逻辑。目前已有567人下载学习，适合作为入门游戏开发、理解像素级游戏还原的实践参考。

1. 用 C++ 和 EasyX 仿制超级马里奥，值得动手做一次

用 C++ 和 EasyX 图形库仿制超级马里奥，看起来像课程设计，真正跑起来你会发现它比多数 c++ 小游戏 demo 更接近真实游戏项目。这个源码已经完整做出 1-1、1-2、1-3 三个关卡，包含马里奥的移动、跳跃、加速、发射火球、下蹲、钻入管道等基础操作，怪物与道具也拆成了独立模块，而不是堆在单个文件里的玩具代码。对刚结束 C++ 语法学习、想找项目巩固类设计和 STL 用法的开发者来说，这是一个能直接编译运行的 c++ 游戏源码；对想了解 2D 平台游戏底层逻辑的人，它把 EasyX 渲染、碰撞检测和关卡数据解析串成完整链路。下面按渲染循环、对象设计、碰撞处理、怪物与关卡配置、编译排错的顺序拆开讲，并给出可照着修改的代码。

2. EasyX 渲染循环与双缓冲绘图机制

2.1 选型：为什么这个项目不用 SDL2 而是 EasyX

C++ 做 2D 游戏最常被推荐的是 SDL2 和 SFML，但它们都需要先处理窗口创建、事件循环、渲染上下文，对一个目标是还原红白机画面的练习项目来说，这些前置代码反而会淹没游戏逻辑。EasyX 的定位是给 C/C++ 做教学用的图形接口，它把 Win32 GDI 封装成类似早期 Turbo C 的 API，画点、画矩形、贴位图都只要一条函数。从源码里的 image.cpp、platform.cpp 文件结构也能看出来，作者想要的是“快速搭画面、慢慢调玩法”。

EasyX 也不是没有代价：它不跨平台，只能在 Windows 下用 MSVC 编译；没有场景图，也没有自动脏矩形重绘。不过这两个缺点对这个项目不构成阻碍。关卡是固定背景的 2D 滚屏，绘制顺序固定，逻辑更新频率用 Sleep 控制就足够。对 C++ 学习者来说，用 EasyX 可以把注意力放在“游戏怎么组织”，而不是“渲染管线怎么调”。

2.2 主循环骨架：输入、更新、绘制、等待

查看 main.cpp 或场景刷新函数，看到的通常是下面这段逻辑：

#include <graphics.h> #include <conio.h> int main() { const int SCREEN_W = 800; const int SCREEN_H = 600; initgraph(SCREEN_W, SCREEN_H); BeginBatchDraw(); // 开启后台缓冲画布 while (true) { // 输入读取：0x8000 表示当前帧按键被按住 if (GetAsyncKeyState('A') & 0x8000) mario->MoveLeft(); // 逻辑更新：按 16ms 逻辑帧推进 scene->Update(16); // 绘图：严格按远近顺序 scene->Draw(); // 将后台画布一次性提交到屏幕 FlushBatchDraw(); // 简单限帧，实际项目中建议替换为高精度定时器 Sleep(16); } closegraph(); return 0; }

GetAsyncKeyState 与 _getch 的最大区别是：它返回按键的“当前状态”而不是“是否发生过输入”。这意味着按住 A 键可以连续向左走，不需要自己维护上一次按键的标记。对平台跳跃游戏，这是必须的行为。0x8000 是掩码值，代表高位 15 位置 1，也就是按键处于按下状态。

Sleep(16) 在普通桌面机上能把画面稳定在 60 FPS 附近，但注意它让出 CPU 的最小粒度是系统时钟周期（通常 15.6ms），所以实际帧间隔可能在 16ms 到 31ms 之间抖动。手感要求高时，应该改用 QueryPerformanceCounter 做高精度等待。这个项目采用 16ms 固定逻辑步长，配合双缓冲，即便绘制偶尔掉帧，物理运算也不会出现突变。

2.3 双缓冲：BeginBatchDraw 到底解决了什么

如果不做批量绘制，每画一个矩形就交给 GDI 输出一次，显卡和显示器之间会产生大量零碎的写入。在 CRT 时代这会造成闪烁：刷新率与绘制速率不同步，前一帧没画完，后一帧就开始覆盖。BeginBatchDraw 会创建一个与屏幕尺寸相同的内存位图作为后台画布，之后的 putimage、rectangle、fillrectangle 都先画在这块内存里，直到 FlushBatchDraw 才整体复制到前台。用户只看到一次完整的帧切换，这就是“双缓冲”。

在 EasyX 里这个机制还有隐藏好处：GDI 对象的创建开销很大，批量模式下可以复用大量绘图调用。像关卡里几百个砖块，如果每个都用独立 putimage，性能会立刻劣化。更优做法是把所有静态地形先组合成一张背景位图，绘制时一次 putimage 即可。platform.cpp 的作用往往就是这个——把地形批量光栅化到一个 IMAGE 对象中，循环时只做一次整图张贴。

2.4 绘制顺序：画家算法与分层结构

2D 游戏普遍采用画家算法：先绘制远距离物体，再绘制近距离物体，覆盖关系自然正确。在这个项目中，绘制顺序大致是：远景背景 → 静态地形（墙、砖块、管道） → 道具 → 怪物 → 马里奥 → 界面信息（分数、剩余时间）。

void GameScene::Draw() { // 背景层：天空、云和远景山脉，整块张贴 putimage(0, 0, &bgImage); // 地形层：砖块和管道，管道比砖块高，放在同一层 for (auto* wall : walls) wall->Draw(); for (auto* block : blocks) block->Draw(); // 道具层：金币、蘑菇、火花，通常画在砖块之上 for (auto* prop : props) prop->Draw(); // 怪物层：Goomba 等敌人，画在道具层之后 for (auto* monster : monsters) monster->Draw(); // 玩家层：马里奥最后画，确保他出现在怪物和道具前方 player->Draw(); // UI 层：分数与命数使用文本写入 drawUI(); }

这段代码值得注意：障碍物和砖块的绘制放在同一层，是因为马里奥的碰撞盒需要同时与两者交互；绘制顺序不影响逻辑，只影响视觉。道具画在怪物之前，所以同屏时道具会被怪物遮挡，这也是原版马里奥里的常见现象。如果希望道具悬浮在怪物上，就把道具循环挪到怪物之后。

2.5 图片加载：loadimage 的路径与透明问题

image.cpp 通常会封装一个资源管理器：

IMAGE imgs[IMG_COUNT]; void LoadAllImages() { // 注意：图片路径相对于 .vcxproj 所在目录，而不是 cpp 文件目录 loadimage(&imgs[IMG_BG], "res/bg1.png"); loadimage(&imgs[IMG_BRICK], "res/brick.png"); loadimage(&imgs[IMG_MARIO], "res/mario.png"); loadimage(&imgs[IMG_GOOMBA], "res/goomba.png"); }

loadimage 的结果放进数组，后续绘制时从数组取，避免每帧重复读文件。很多新手直接放在 Update 里，导致每帧都触发磁盘 IO，帧率会跌破个位数。

EasyX 20220901 版本开始支持带透明通道的 32 位位图，但 putimage 遇到半透明像素时会重新计算背景色，效果与浏览器中的 PNG 不完全一致。自己画素材时，建议统一导出为不透明背景的 24 位 BMP，或使用纯色掩码图。如果一定要用 PNG，可以使用两次 putimage 的掩码绘制法：先贴 AND 掩码图，再贴 XOR 原图，这是 GDI 时代的经典做法。

常用 EasyX 绘图函数对比：

putimage 的坐标参数是矩形左上角在窗口中的坐标，而游戏对象坐标通常也存储为左上角，所以绘制时可以直接传 x, y。如果以对象中心点作为坐标更顺手，则在 Draw 里做putimage((int)(x - width / 2), (int)(y - height / 2), ...)的换算。这个项目用 EasyX 绕过了 Win32 复杂消息循环，核心绘制参数都集中在上表函数里，排错范围很小。

实际测试时可以把 Sleep(16) 去掉，观察画面明显闪烁，再恢复，就能直观理解双缓冲的作用。

3. 对象模型与关卡数据驱动：从 block.cpp 到 gamescene.cpp

3.1 为什么要拆分出这么多 cpp 文件

打开源码包，能看到 check.cpp、event.cpp、block.cpp、gamescene.cpp、mario.cpp、monster.cpp、wall.cpp、prop.cpp、image.cpp、platform.cpp。这种文件命名很直白，每个都对应游戏中的一个实体或系统。这样拆不是为了凑数，而是为了让依赖方向清晰：gamescene 是场景管理器，它知道所有对象；其他对象只依赖图形接口和事件定义，不知道自己属于哪个场景。check.cpp 通常负责碰撞检测查询，event.cpp 负责把碰撞结果变成事件，这两个文件被场景和对象同时调用。

如果不拆分，把所有函数写在一个 main.cpp 里，项目做到一半就会出现“改一个跳跃参数需要重新编译所有代码”的情况。按对象划分后，改怪物逻辑时只用动 monster.cpp，其他文件不受影响。对用 C++ 做课程设计的人来说，这种组织方式也更接近真实项目的模块边界。

3.2 用 GameObject 基类统一 Update 与 Draw

虽然源码里可能没有显式定义一个基类头文件，但从各对象提供的方法可以看出，它们都可以归纳为三个能力：更新自身状态、绘制自身、返回碰撞盒。这里补一个轻量基类，让后续新增对象更省事：

// GameObject.h #pragma once #include <graphics.h> #include <vector> class GameObject { public: virtual ~GameObject() = default; // 每帧逻辑更新，入参为距离上一逻辑帧的毫秒数 virtual void Update(long deltaMs) = 0; // 绘制到当前 EasyX 后台缓冲 virtual void Draw() const = 0; // 返回与世界坐标对齐的碰撞矩形 virtual RECT GetBox() const = 0; protected: float x = 0.0f; // 世界坐标 X（像素） float y = 0.0f; // 世界坐标 Y（像素，向下为正） float width = 32.0f; float height = 32.0f; };

为什么不推荐把所有对象都坐上继承链？因为砖块和被顶出的道具差异不大，但行为完全不同：墙永远不会移动，道具可以沿抛物线飞出去。用组合或扁平结构反而更容易实现，例如给 GameObject 增加一个bool movable标志，比层层继承来得直观。继承最好只用在“共享接口、不同实现”，也就是这里的纯虚方法。

3.3 关卡文本格式：用字符矩阵描述三关地图

gamescene.cpp 最重要的功能是加载关卡。常见做法是把 1-1、1-2、1-3 分别写成 level1.txt、level2.txt、level3.txt，每行一个字符序列，字符与对象类型对应。

简化版关卡片段：

....M...............M.... +++....????.......+++.... ....TT..........TT....... =========================

最后一行=表示地面，实际用#填充更常见。解析代码：

bool GameScene::LoadLevel(int level) { std::string path = "level" + std::to_string(level) + ".txt"; std::ifstream in(path); if (!in.is_open()) return false; ClearLevel(); // 先清空上一关的对象 std::string line; const float TILE = 32.0f; // 每格像素大小 int row = 0; while (std::getline(in, line)) { // 去掉末尾可能的 \r，否则 Windows 换行符会影响字符比较 if (!line.empty() && line.back() == '\r') line.pop_back(); for (int col = 0; col < (int)line.size(); ++col) { const float px = col * TILE; const float py = row * TILE; switch (line[col]) { case '#': walls.push_back(new Wall(px, py)); break; case '+': blocks.push_back(new Block(px, py, BlockType::Normal)); break; case '?': blocks.push_back(new Block(px, py, BlockType::HiddenProp)); break; case 'T': platform->AddPipe(px, py); break; case 'M': monsters.push_back(new Monster(px, py, MonsterType::Goomba)); break; case 'P': player->SetSpawn(px, py); break; case 'o': props.push_back(new Prop(px, py, PropType::Coin)); break; default: break; // 空格直接跳过 } } ++row; } return true; }

这段代码有四个参数值得注意：

• TILE是瓦片大小，本项目素材按 32×32 设计。如果换成 48×48 素材，只需改这一个值，所有对象坐标都会自动跟着乘算。
• row从 0 开始，对应屏幕上从上到下的行数；EasyX 的 Y 轴向下增长，所以py = row * TILE正好符合。
• P不创建对象，因为马里奥在关卡开始时已经位于场景中，SetSpawn 只是重置他的位置和速度。
• 管道T交给 platform 对象处理，是因为管道高度可能跨多行；需要先收集所有 T 的位置，再按 x 方向合并成完整矩形。否则每个 T 单独生成一个 32×32 方块，碰撞时会把管道当普通砖块。

如果出现角色卡在管道里的问题，先检查管道 T 是否被正确合并。通常在 platform.cpp 里会做二次扫描：按 x 排序，把所有连续 T 合并为一个大的 RECT。

3.4 对象生命周期：谁负责 delete

关卡对象使用 new 创建，那么在游戏结束或切换关卡时必须有对应的 delete。简单做法是 GameScene 析构函数中统一清理：

GameScene::~GameScene() { for (Wall* w : walls) delete w; for (Block* b : blocks) delete b; for (Monster* m : monsters) delete m; for (Prop* p : props) delete p; walls.clear(); blocks.clear(); monsters.clear(); props.clear(); }

如果想更安全，可以把容器换成std::vector<std::shared_ptr<...>>，但在循环引用下 shared_ptr 也救不了。这个项目规模小，裸指针配统一析构点反而最透明：能明确知道每个对象何时死亡。真正的坑在于怪物死亡动画期间对象是否还在碰撞检测列表里。建议在 Monster 里加bool alive标志，DYING 状态也继续返回碰撞盒，但碰撞逻辑忽略它的攻击性。否则，死亡中的怪物会直接穿过马里奥身体，看起来很不自然。

事件分发可以放在 check.cpp 和 event.cpp 中。check 模块负责计算所有碰撞对，event 模块把碰撞对转换为事件。例如马里奥顶砖块的事件流是：碰撞检测发现头与砖块相交 → 判定运动方向为向上 → 调用 block->OnHit() → block 判断 hidden 属性并生成道具。事件机制的好处是 mario.cpp 不需要 include block.h，通过事件 ID 通信，编译依赖和时间都减少了。

4. AABB 碰撞检测与马里奥按键状态机

4.1 矩形碰撞为什么对马里奥足够

原版 NES 马里奥的所有判定都是用多个轴对齐矩形完成的：玩家、砖块、管道、金币分别有 AABB。AABB 的意思是矩形边不旋转，始终与坐标轴平行。检测两个 AABB 是否相交，只需要判断左右边界和上下边界是否全部重叠。

像素级碰撞听起来更精确，但有两个问题：一是素材会有半透明部分，判定边界不明确；二是对 CPU 消耗高。在像素风 2D 游戏中，矩形盒与素材误差很小，玩家能接受贴图边缘略微碰不到砖块。因此 AABB 是性能和表现的最佳折中。

4.2 判定函数与重叠深度

inline bool IsCollide(const RECT& a, const RECT& b) { return a.left < b.right && a.right > b.left && a.top < b.bottom && a.bottom > b.top; } // 求水平重叠深度，用于 X 轴处理 inline float OverlapX(const RECT& a, const RECT& b) { return (a.right < b.right ? a.right : b.right) - (a.left > b.left ? a.left : b.left); }

RECT 的 left/top/right/bottom 是LONG类型，在两个对象边缘刚好接触时 left == right，IsCollide 返回 false，符合预期。由于物体移动按像素步进，很少出现刚好相等。

重叠深度用于修正方向。如果dx > 0说明马里奥向右移动，撞墙时应将 x 调整为墙的 left - 马里奥宽度/2；如果dx < 0则调整为墙的 right + 宽度/2。这里建议以对象中心点存储位置，因为马里奥下蹲时高度变化，中心点不变，只需要调整 height。

4.3 分轴移动：平台跳跃最关键的工程决策

很多新手把碰撞响应做成“移动整个 (x,y) 后再统一检测”，结果角色卡进墙角无法动弹。正确做法是分轴处理：先移动 X，检测所有固体，修正 X；再移动 Y，检测并修正 Y。这样水平撞墙时 Y 轴不受影响；踩到怪物时 X 轴不抖动。

void Mario::MoveWithCollision(float dx, float dy, const std::vector<RECT>& solids, bool& onGround) { onGround = false; // 先处理水平方向 x += dx; RECT box = GetBox(); for (const RECT& s : solids) { if (IsCollide(box, s)) { if (dx > 0.0f) x = s.left - width / 2; // 右边界被墙挡住 else if (dx < 0.0f) x = s.right + width / 2; // 左边界被墙挡住 box = GetBox(); // 修正后立刻更新碰撞盒 } } // 再处理垂直方向 y += dy; box = GetBox(); for (const RECT& s : solids) { if (IsCollide(box, s)) { if (dy > 0.0f) { y = s.top - height / 2; // 落地 onGround = true; dy = 0.0f; // 关键：清除下落速度 } else if (dy < 0.0f) { y = s.bottom + height / 2; // 顶头 } box = GetBox(); } } }

参数说明：dx 和 dy 是这一逻辑帧内的位移量，单位为像素。s.left 和 s.right 都是整型，在修正 x 时如果直接把 float x 赋给整型矩形，会丢失小数。所以 GetBox 里应该用 floor/ceil 取整，保证碰撞盒与绘制位置一致，否则角色会随着帧数累积亚像素误差。

另外注意：当马里奥站在地面上时，每帧重力都会给 dy 加一个正数。如果与地面碰撞检测成功后不把 dy 置 0，下一帧会用更大的正速度再次下穿，最终穿透地面。这个语句容易被忽略，我把它放在onGround = true;之后。

4.4 马里奥状态机：四种基础状态 + 火球

mario.cpp 内部至少要维护一个枚举：

enum class MarioState { Idle, // 站立 Run, // 跑动 Jump, // 跳跃 Squat, // 下蹲 Fire // 发射火球后的短暂状态 };

状态转换表：

实现跳跃手感时，三个参数最关键：重力加速度、起跳初速度、跳跃按键衰减。常见的初始值：

const float GRAVITY = 0.45f; // 每帧下落加速度（像素/帧^2） const float JUMP_SPEED = -11.0f; // 起跳瞬间 y 方向速度，负值向上 const float FALL_CAP = 10.0f; // 最大下落速度，避免穿地

如果感觉跳跃太飘，减小 JUMP_SPEED 或增大 GRAVITY；如果总是够不到高处砖块，适当调大 JUMP_SPEED。EasyX 的 Y 轴向下为正，所以起跳是负速度。

跳跃手感还有一个细节是“可变跳”：玩家按住跳跃键时重力较小，松开跳跃键后重力立刻变大。轻点按键是小跳，长按是大跳。实现上是在 Update 里判断：如果按住 K 且速度小于 0，GRAVITY 用 0.3；否则用 0.45。加了之后游戏才不像弹簧跳。

4.5 check.cpp 与 event.cpp：碰撞结果如何变成游戏事件

check.cpp 的职责是批量计算碰撞对：

for (auto* m : monsters) if (IsCollide(player->GetBox(), m->GetBox())) eventQueue.push({EventType::PlayerHitMonster, m});

event.cpp 消费事件队列，根据事件类型做决策：

switch (ev.type) { case EventType::PlayerHitMonster: // 判断是踩到还是侧面撞到 if (player->IsFalling() && player->GetBottom() < ev.obj->GetBox().top + 16) ev.obj->OnStomped(); else player->OnHurt(); break; }

“踩到”的判断标准是玩家矩形底边在怪物顶部以下 16 像素内，并且 y 方向速度为下落。16 像素约等于怪物高度的四分之一，可以根据手感微调。数值越小，越容易判定为受伤。check 和 event 的拆分解耦了对象依赖，mario.cpp 里不再需要 include monster，依赖图更干净。

5. 怪物 AI、道具系统与三关差异化配置

5.1 板栗仔的两态有限状态机

monster.cpp 里的敌人行为不复杂。Goomba 只有 ALIVE、DYING、DEAD 三个状态。ALIVE 时以恒定 speed 水平移动，碰到固体墙体或悬崖边缘就反转方向。DYING 是不参与碰撞的死亡动画，500ms 后转为 DEAD 并被移除。

void Monster::Update(long deltaMs) { if (state == MonsterState::Dying) { dieTimer += deltaMs; if (dieTimer > 500) state = MonsterState::Dead; return; } // 将速度换算到当前帧的位移 x += speed * (deltaMs / 16.0f); RECT box = GetBox(); if (HitSolid(box)) // 前面有墙或砖块 speed = -speed; // 掉头 if (NoGround(box)) // 脚下没有地面 speed = -speed; // 悬崖边缘掉头 }

这里deltaMs / 16.0f是实用小技巧：正常情况下 16ms 对应 1 逻辑帧；如果某次更新用了 32ms，就移动 2 倍距离。这样游戏在不同性能的机器上不会明显变速。但要注意不能直接把该值用于碰撞穿透判断，因为大步长可能导致矩形直接跳过墙体。通常限制单帧最大步长，比如一个逻辑帧内最多移动speed * 2。

NoGround 判断要小心：往下探测一格矩形，如果检测不到任何固体，就认为怪物走到悬崖边。探测矩形建议比怪物本体窄几像素，否则在砖块边缘会提前掉头，导致怪物卡在边缘反复横跳。

5.2 道具：金币、蘑菇和火花

prop.cpp 中常见的道具类型：

蘑菇和火花的移动方式不同：蘑菇是会行走的道具，需要像怪物一样检测碰撞，碰到墙或悬崖就变向；火花不需要移动，马里奥碰到即拾取。因此 prop 类里最好加一个bool movable标志。顶砖块弹出道具的动画也在这里处理：道具出生后前 200ms y 坐标持续向上偏移，之后切换到正常移动。

void Prop::Update(long deltaMs) { if (state == PropState::Emerging) { emergeTimer += deltaMs; y -= 0.8f * deltaMs / 16.0f; // 先向上钻出 if (emergeTimer >= 200) { state = PropState::Active; y -= BLOCK_TILE; // 弹出到砖块上方一格 } return; } if (movable) { x += speed * (deltaMs / 16.0f); if (HitSolid(x > prevX ? dirRight : dirLeft)) speed = -speed; } }

emergeTimer 控制弹出动画时长，200ms 后道具移动到砖块上方 32 像素处，玩家才能看到完整蘑菇。如果蘑菇卡在砖块内部，检查 y 的修正是否用 BLOCK_TILE 而不是道具自身的 height。

5.3 三关难度是怎么拉开的

三关地图的参数差异是项目最值得借鉴的地方。1-1 是教学关，敌人稀疏，跳跃点之间的宽度不超过 3 格，地面平整；1-2 用大量砖块搭出高位通道，玩家需要下蹲通过矮顶隧道；1-3 加入管道包围和连续跳跃平台，怪物密度明显增大。可以用配置表管理：

这些参数可以写在 gamescene.cpp 顶部的结构体中，在每个关卡加载后使用。比如 1-2 的地下关卡天空背景变暗，可以在 level 配置里加一个bg_id字段。判断“最大跳跃宽度”的方法是让马里奥以最高水平速度地面起跳，看水平移动经过多少格。如果角色能轻松跳过 6 格，说明重力太小或水平速度过快，需要平衡。

5.4 通关判定与“自动关闭”的真相

项目说明里特意提到“通关 1-3 后程序自动关闭属正常现象”。原因是游戏循环中到达旗帜后，关卡索引递增，索引超过最大关卡时直接调用了 exit(0)。对应代码大致是：

void GameScene::CheckGoal() { if (player->ReachedFlag()) { ++currentLevel; if (currentLevel > MAX_LEVEL) { exit(0); // 所有关卡完成，演示结束 } else { LoadLevel(currentLevel); player->ResetToSpawn(); } } }

exit(0) 会立刻终止进程，不调用局部对象析构。如果想做“全通关”结算画面，需要把 exit(0) 替换为gameFinished = true，然后在外层循环中显示胜出画面并等待按键。但作为课程设计，直接退出符合项目说明。如果想循环游玩，把 exit(0) 改成currentLevel = 1即可。

遇到旗帜时另一个常见 bug 是“卡在旗杆”：马里奥碰到旗杆后仍然向右移动，反复触发判定。解决方案是在碰到旗帜后禁用玩家输入，同时把 x 速度清零，等下滑动画完成后再进入下一关。

6. VS2022 编译 EasyX 项目的排错与调试技巧

6.1 装好 EasyX 后还差一步配置

EasyX_20220901 默认会安装到 VS2022 的第三方库目录中，但保险起见还是确认三个位置：

• 项目属性 → C/C++ → 常规 → 附加包含目录：包含 EasyX 的include路径
• 链接器 → 常规 → 附加库目录：包含lib路径
• 链接器 → 输入 → 附加依赖项：填入EasyX.lib（64 位）或EasyXa.lib（32 位）

只报找不到graphics.h，多半是附加包含目录没写对；报unresolved external symbol，多半是附加依赖项没加。

6.2 LNK2019 错误：main 和 WinMain 的入口之争

用 EasyX 写int main()，链接时却报 LNK2019_mainunresolved，这是最常见的问题。原因是图形库的链接配置默认指向图形程序入口WinMain，而你的代码是控制台程序入口main。最简单的修复是在项目属性 → 链接器 → 系统 → 子系统中选择“窗口”，或者在代码最前面加：

#pragma comment(linker, "/subsystem:windows /entry:mainCRTStartup")

这样告诉链接器用main作为程序入口，同时以窗口子系统运行。注意mainCRTStartup是 CRT 启动函数，它会初始化运行时环境后调用你的main，所以控制台的 printf 输出仍然有效（但不会弹出控制台窗口）。

6.3 中文乱码与资源路径

EasyX 的loadimage接受LPCTSTR，VS2022 默认使用 Unicode 字符集，字符串常量要写成_T("res/bg.png")或L"res/bg.png"。如果源码文件是 UTF-8 无 BOM，中文注释和路径会在编译时被当成 GBK 解析。最稳妥的办法是：项目属性 → C/C++ → 命令行，添加/utf-8编译选项，同时把源文件另存为 UTF-8 with BOM。

6.4 用调试开关画出所有碰撞盒

碰撞逻辑看起来没问题但角色老穿墙，最有效的排查方式是可视化碰撞盒。EasyX 没有DrawRect，可以用rectangle函数画空心矩形：

void GameScene::DrawDebugBox() { if (!showDebug) return; setlinecolor(RED); for (auto* w : walls) rectangle(w->GetBox().left, w->GetBox().top, w->GetBox().right, w->GetBox().bottom); for (auto* b : blocks) rectangle(b->GetBox().left, b->GetBox().top, b->GetBox().right, b->GetBox().bottom); for (auto* m : monsters) rectangle(m->GetBox().left, m->GetBox().top, m->GetBox().right, m->GetBox().bottom); player->DrawDebugBox(); }

用 F1 键切换showDebug。观察时重点看两个位置：马里奥站立时矩形是否刚好贴地；下蹲时矩形顶部是否穿过头顶砖块。如果矩形比素材大，调小 width/height，而不是去改碰撞检测逻辑。

6.5 区块化绘制与固定步长优化

当关卡砖块超过上百个时，逐块putimage会白白消耗 GDI 调用。一种有效优化是把静态地形预先绘制到一张离屏IMAGE上，加载时只画一次，渲染循环里一次putimage整块贴出。实现时可以用SetWorkingImage切换当前设备，把staticMap作为绘图目标，然后把所有 wall 和 block 的位置画上去。动态物体仍按对象绘制，帧率能明显提升。

另一个建议是把逻辑更新和绘制分离，用固定 16ms 步长累加。不要直接用 Sleep 控制物理；相反，先让循环尽可能跑，每累计满 16ms 才执行一次物理更新。这样在高刷新率屏幕上，逻辑频率稳定，跳跃高度不会随帧率变化。记得把 staticMap 的尺寸设置成与游戏区完全一致，否则滚屏时边界会露出空白。

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