Visual C++与HGE引擎：超级玛丽源码解析与游戏改造指南-平芜编程栈

简介：这是一份使用Visual C++与HGE游戏引擎开发的《超级玛丽》完整源代码，适合已有C++语法基础、希望接触DirectX 2D游戏开发的学习者。压缩包共183个文件，大小约8.93MB，文件类型覆盖工程代码（hpp/cpp/h）、图像素材（png/bmp/gif）、音频资源（wav/mod）、动态库（dll）及工程配置（sln/vcproj等），可直观看到一款小型商业级游戏从代码到素材的完整组织方式。该项目已有719人学习下载。通过阅读源码，可以理解HGE引擎下的游戏循环、碰撞检测、精灵动画、键盘输入响应与音频播放等关键模块，也能看到超级玛丽中角色、敌人、砖块和关卡数据的封装方式。对于希望系统梳理2D游戏主循环、状态切换和资源管理思路的开发者来说，这是一份结构较为完整、能直接对照调试的实践样本，也为后续修改角色动作、增加关卡提供了清晰入口。

1. 一套visual c++写的HGE引擎超级玛丽源码：先搞清楚它值不值得你折腾

你手里这个写着visual c++和hge游戏引擎的超级玛丽游戏源代码包，大概率是从老游戏资源站或者某个硬盘角落翻出来的。它的价值不在“再玩一遍马里奥”，而在：用一份没有Unity、没有Godot、没有复杂架构的C++源码，看清一个完整的2D平台跳跃游戏是怎么被组织起来的。HGE是Haaf's Game Engine，一个基于DirectX的轻量级2D游戏引擎，2000年代在独立游戏圈和教学圈很流行。这套源码最适合两类人：正在学VC++但只会写控制台程序的入门者，以及想找一份“小到能读完、大到有完整玩法”的2D游戏源码做改造的从业者。代价从低到高，下面一步步讲。

2. HGE引擎怎么撑起一个马里奥：游戏循环、三层代码结构与选型理由

2.1 HGE是什么：DirectX时代的轻量级游戏引擎

HGE是一个用C++编写、对DirectX 8/9做了二次封装的2D游戏引擎。渲染、音频、输入、定时器、资源管理，全部收敛成一套C风格API，写代码的人不需要直接碰D3D设备或者COM接口。拿到手就是几个头文件、一个导入库hge.lib、一个运行时hge.dll。它没有编辑器，没有场景图，没有组件系统，和现在主流的引擎完全是两个物种。

这个轻量级游戏引擎的设计很直接：程序初始化时用hgeCreate()拿一个全局HGE对象，然后用System_SetState()配置窗口、分辨率、帧率和回调函数，最后调用System_Start()进入引擎内部的消息循环。游戏逻辑只需要给引擎交出两个函数指针：一个负责每帧更新逻辑，一个负责每帧绘制画面。所有按键状态、图片加载、声音播放都从那个全局HGE对象上拿。

选它做超级玛丽是顺手的。马里奥这类2D平台跳跃游戏的核心要素是精灵贴图、瓦片地图、键盘输入、2D音效，HGE全都有，而且没有物理引擎。没有物理引擎反而是优点：平台的碰撞手感必须自己用矩形碰撞算，你会被迫理解“为什么这个跳跃手感对了”。如果直接用Box2D或者物理引擎，反而会陷入参数调不完的被动局面。

#include <hge.h> HGE *hge = nullptr; bool frame_func() { // 返回 true 表示退出游戏循环 if (hge->Input_GetKeyState(HGE_KEY_ESCAPE)) return true; return false; } bool render_func() { hge->Gfx_BeginScene(); hge->Gfx_Clear(0xFF000000); // 这里绘制所有精灵 hge->Gfx_EndScene(); return false; } int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int) { hge = hgeCreate(HGE_VERSION); hge->System_SetState(HGE_FRAMEFUNC, frame_func); hge->System_SetState(HGE_RENDERFUNC, render_func); hge->System_SetState(HGE_TITLE, "Mario Clone"); hge->System_SetState(HGE_WINDOWED, true); hge->System_SetState(HGE_SCREENWIDTH, 800); hge->System_SetState(HGE_SCREENHEIGHT, 600); if (hge->System_Initiate()) { hge->System_Start(); } hge->System_Shutdown(); hge->Release(); return 0; }

这段代码是HGE程序的标准骨架。FrameFunc里做输入判断和逻辑更新，RenderFunc里做清屏和绘制。System_SetState的各个HGE_常量本质上是给引擎的配置项，比如HGE_FPS控制逻辑帧率上限，HGE_WINDOWED决定是否窗口模式，HGE_SCREENWIDTH和SCREENHEIGHT决定分辨率。马里奥这个层级的游戏不需要多深的引擎能力，这套骨架就足够跑出完整的玩法。

2.2 解压后你会看到的三个层次：引擎库、游戏逻辑、资源文件

一份用HGE写的游戏引擎源码工程，解压后通常可以按三层去理解，我拿到任何老游戏源码包都会先按这个框架归档：

层次	常见形态	在游戏里的角色
引擎层	include目录、hge.lib、hge.dll	提供渲染、音频、输入等通用能力，通常不需要改
游戏逻辑层	若干.cpp和.h文件	主角类、敌人逻辑、关卡加载、碰撞检测，这是源码的重点
资源层	图片、音频、地图文本文件	贴图、音效和关卡数据，决定游戏的“长相”

引擎层和资源层中间是游戏逻辑层。引擎层对游戏逻辑暴露头文件接口，游戏逻辑每帧调用引擎API把精灵画出来，资源文件里的贴图由引擎加载成纹理句柄。改游戏玩法只动逻辑层，改画面表现主要换资源层，引擎层在整个开发周期里几乎不用碰。

这个分层直接决定了改造路径。你想把这个超级玛丽改成自己风格的游戏，优先改资源层；想改跳跃手感、敌人AI和关卡规则，改逻辑层；除非遇到渲染问题，否则别碰引擎层。碰引擎层是最后手段，因为hge.dll是编译好的二进制，你要改引擎就得自己拿HGE源码重新编译，那就超出这套源码的范畴了。

2.3 核心帧循环：输入、物理、碰撞、渲染的每帧顺序

HGE的System_Start()进入主循环之后，每一帧都按固定顺序做四件事：处理输入、更新物理状态、做碰撞检测、绘制场景。拿到这套源码，第一个要找到的就是WinMain里注册的FrameFunc，整个游戏世界的时间都从那里推进。

我一般会在FrameFunc里按这样组织更新顺序：先读输入，把按键状态转成玩家的移动意图；再按速度和时间差更新位置，这里会叠加重力；接着做碰撞检测，修正位置防止穿墙；最后更新动画帧号和音效状态。渲染函数和逻辑函数分开，逻辑帧率可以固定，渲染帧率跟显示器刷新率走。

这里有一个老玩家都知道的坑：不同电脑的运行速度不同，不能拿“每帧移动固定像素”这种写法。要用时间差dt作为系数，HGE里通过hge->Timer_GetTime()拿当前毫秒级时间，相邻两帧的差值就是dt。速度乘以dt才是这一帧的位移量。老源码如果直接写成固定步长，在高端机上角色会像开了加速器，这是需要第一时间修正的地方。

bool frame_func() { float dt = 0.0f; hge->Input_Reset(); // 计算帧间隔，单位秒 static float last = hge->Timer_GetTime(); float now = hge->Timer_GetTime(); dt = (now - last) / 1000.0f; last = now; if (hge->Input_GetKeyState(HGE_KEY_ESCAPE)) return true; // 1. 输入处理 float dir = 0.0f; if (hge->Input_GetKeyState(HGE_KEY_LEFT)) dir -= 1.0f; if (hge->Input_GetKeyState(HGE_KEY_RIGHT)) dir += 1.0f; // 2. 更新玩家速度与位置 player.vx = dir * 200.0f; player.vy += 800.0f * dt; player.x += player.vx * dt; player.y += player.vy * dt; // 3. 碰撞检测，修正位置 CollideWithMap(&player); // 4. 动画与渲染准备 UpdateAnimation(&player, dt); return false; }

dt计算的几个参数值得记一下：按键方向dir取值-1到1，乘200得到水平速度，单位是像素每秒；重力加速度给800像素每秒平方，下落感觉接近原版马里奥；垂直速度没有做上限限制时，角色从高处落下会穿模，所以后面还要加一个最大下落速度，通常限制在600到900之间。这个数值区间是2D平台游戏比较通用的手感范围。

3. 把源码跑起来：Visual C++编译配置与最小可运行方案

3.1 编译器版本怎么选：从VC++ 6.0的工程到现代Visual Studio

那个年代的HGE源码工程文件大概率是.dsw或.dsp，也就是Visual C++ 6.0用的工程格式。用现代Visual Studio直接打开，会出现一个转换向导，把老工程升级成.vcxproj。转换本身通常能成功，但HGE源码用了一些老式C++写法，升级后会在字符集和多字节字符串上翻车。

我的建议是：不要执着于Visual C++ 6.0。VC6生成的exe在Win10、Win11上运行会有兼容性问题，而且VC6自带的STL和模板支持比较弱，源码里稍微用点现代语法就编译不过。直接用Visual Studio 2019或2022打开转换，把平台工具集保持在较新版本。唯一要留意的是目标平台选x86，因为老HGE库多半只有32位版本，混合64位会直接链接失败。

另外一个常被忽略的问题是运行库。编译出的exe在开发机跑得起来，换一台机器双击就报缺少VCRUNTIME140.dll或者MSVCP140.dll，这是microsoft visual c++ redistributable没装。VC++ 2019 redistributable package里包含了这些运行库，x86和x64都要装，因为exe是32位但系统里某些组件会按64位路径去找。老HGE程序依赖的正是这一套运行库，不是.NET，也不需要装额外框架。

如果源码包只给了.cpp文件而没有工程文件，最稳的办法是在Visual Studio里创建一个空C++工程，把源码文件全部加进去，再手动配置HGE的包含目录和库目录。Visual Studio新建C++项目的时候选“空项目”，注意不是Windows桌面向导，否则会自动生成一堆用不到的预编译头。配置工作集中在三处：附加包含目录、附加库目录、附加依赖项，后面详细说。

3.2 用cl.exe命令行编译的完整脚本与参数解释

不用IDE也能把这份源码编译出来，前提是机器上装了带有C++桌面开发组件的Visual Studio。打开“开发者命令提示符”，用cl.exe直接编译，这样能清楚看到每一步依赖了什么。下面是一个最小批处理脚本，假设HGE库解压在C:\hge，源码文件是main.cpp、game.cpp、player.cpp、level.cpp。

@echo off set HGE_PATH=C:\hge set SRC=main.cpp game.cpp player.cpp level.cpp cl /nologo /EHsc /MD /Zi /I"%HGE_PATH%\include" %SRC% ^ /link /LIBPATH:"%HGE_PATH%\lib" ^ hge.lib user32.lib winmm.lib ^ /OUT:mario.exe if exist mario.exe ( echo [OK] mario.exe 已生成 ) else ( echo [FAIL] 编译失败，检查上面的错误信息 )

每个参数都有明确用途。/EHsc是启用C++异常处理，HGE源码里用到了try/catch，不加上会有警告；/MD指定动态链接到VC运行时库，这样exe体积小，但部署目标机必须装redistributable运行库；/I指定HGE头文件目录，编译器在这里找hge.h。/link后面是链接器选项，/LIBPATH指向HGE的导入库目录，hge.lib是引擎库本体，user32.lib和winmm.lib是Windows系统库，HGE内部用到窗口消息和多媒体定时器，没链这两个会报一堆无法解析的外部符号。

如果源码包里带的是新版.vcxproj工程，可以直接用MSBuild命令行构建，适合想自动化编译的人：

msbuild Mario.sln /p:Configuration=Release /p:Platform=x86 /m

这里Configuration选Release而不是Debug，老HGE库的Debug版导入库经常没随包附带；Platform必须x86，原因上面说过，HGE库是32位的。MSBuild会自动处理源文件列表和头文件依赖，但包含目录和库目录还是要先在工程属性里配好，命令行参数覆盖不了这些。

编译通过后别急着双击exe。先用dumpbin看exe依赖哪些DLL，确认hge.dll被正确引用：

dumpbin /dependents mario.exe

输出里能看到hge.dll、VCRUNTIME140.dll这几个名字。如果hge.dll没被找到，确认它和exe在同一个目录。这一步能省下后面运行时闪退排查的大量时间。

3.3 IDE里的工程配置：包含目录、库目录、工作目录三条必改项

在Visual Studio里手动建工程配置HGE源码时，最常改的就三处属性。第一处是VC++目录里的“包含目录”，把C:\hge\include加进去，否则编译器报fatal error C1083: Cannot open include file: 'hge.h'。第二处是“库目录”，把C:\hge\lib加进去，否则链接器报LNK1104无法打开hge.lib。第三处是“调试”里的“工作目录”，默认留空时以.vcxproj所在目录为当前目录，而HGE加载资源用的是相对路径，会导致IDE里F5跑起来贴图全空白。

提示：工程属性里还要把“字符集”从“使用Unicode字符集”改成“使用多字节字符集”。HGE和大量老游戏源码的字符串处理基于char而非wchar_t，用Unicode字符集编译会报“无法从const char*转换为LPCWSTR”这类C2664错误。

字符集问题是这批老代码最常见的编译拦路虎，现象和解决都很明确：编译错误集中在LoadImage、CreateWindow这类Win32 API调用上，把字符集切回多字节立即消失。除了这三条，还需要在“链接器→输入→附加依赖项”里手动加上hge.lib、user32.lib、winmm.lib，IDE不会自动识别老式lib依赖。

配置完成后按一次F5，能做冒烟测试：窗口能弹出来、标题栏正确、背景色正确，就说明工程配置没问题，可以进入下一阶段的源码阅读了。

4. 读透这份马里奥源码：主角类、碰撞检测与关卡数据

4.1 主角的状态与速度设计

打开源码包，第一件事不是从头读main.cpp，而是找到玩家相关的那几个文件。游戏源码的阅读顺序应该是：数据结构优先于逻辑流程。马里奥的主角类一般不会太复杂，核心成员就是位置、速度、碰撞盒尺寸、状态编号，再加上精灵贴图句柄。一个典型的设计长这样：

class Player { public: float x, y; // 位置，左上角原点，单位像素 float vx, vy; // 速度，像素/秒 float w, h; // 碰撞盒尺寸，决定被撞判定 bool on_ground; // 是否在地面，跳跃逻辑依赖这个标志 bool face_right; // 朝向，决定贴图是否镜像 int state; // 0 站立，1 走路，2 跳跃，3 受伤 // 精灵对象，HGE里每个精灵绑定一块纹理区域 hgeSprite *spr_idle; hgeSprite *spr_walk[4]; hgeSprite *spr_jump; void Update(float dt); void Render(); };

这个类设计的几个细节值得注意。位置用float而不是int，像素坐标是连续量，用整数会导致慢速移动时一顿一顿。速度单位统一为像素/秒，配合dt时间差计算位移，不同帧率下手感才能保持一致。w和h是碰撞盒，不等于贴图尺寸，通常要比贴图略小一圈，这是动作游戏的通用处理，给玩家一点容错空间。

state字段老代码里往往只是一个int加一堆if判断，和现代游戏开发里用状态机枚举是同一套思路，只是写法更朴素。换贴图的时候就检查state，换成对应的spr_walk帧。face_right不需要单独记录，HGE的精灵对象可以设置镜像模式，Render时根据朝向决定是否调用SetFlip。

4.2 用分轴碰撞实现平台跳跃的手感

马里奥系列的手感来自一个关键细节：碰撞检测分轴处理。先水平移动并检测碰撞，再垂直移动并检测碰撞，两个方向互不混合。这样角色斜着撞向墙壁转角时，不会因为对角线移动被直接弹出去，而是先停在水平方向，再正常下落，做出“擦墙滑落”的效果。

void CollideWithMap(Player* p) { // 先水平移动，再垂直移动 p->x += p->vx * dt; // 取玩家包围盒覆盖的所有瓦片 int x0 = (int)(p->x) / TILE_SIZE; int x1 = (int)(p->x + p->w) / TILE_SIZE; int y0 = (int)(p->y) / TILE_SIZE; int y1 = (int)(p->y + p->h) / TILE_SIZE; for (int ty = y0; ty <= y1; ty++) { for (int tx = x0; tx <= x1; tx++) { if (IsSolidTile(tx, ty)) { // 水平方向修正，往回推 if (p->vx > 0) p->x = tx * TILE_SIZE - p->w; else if (p->vx < 0) p->x = (tx + 1) * TILE_SIZE; } } } // 再处理垂直移动 p->y += p->vy * dt; y0 = (int)(p->y) / TILE_SIZE; y1 = (int)(p->y + p->h) / TILE_SIZE; // 检查每个可能碰撞的瓦片，落地或顶头 }

分轴碰撞有两个必调的细节。第一，水平修正只处理vx方向，垂直修正只处理vy方向，不要让一个方向的碰撞结果影响另一个方向的速度。第二，落地判断要单独做：垂直移动后如果玩家底部压到了solid瓦片，就把y坐标推回瓦片顶边，同时把vy清零、on_ground设为true。on_ground是跳跃逻辑的核心，只有它为true时才能起跳，否则会出现空中连跳。

踩坑点在于瓦片遍历范围。x0到x1、y0到y1必须用玩家的左右上下四条边分别算，不能只算中心点。马里奥的角色碰撞盒大约15像素宽、28像素高，而瓦片是16像素见方，所以一次移动最多跨两个瓦片。如果遍历范围少算一条边，快速移动时角色会直接穿过砖块，这是老源码里最常见的穿墙原因。

4.3 敌人和道具：数据驱动的地图与对象表

读源码时会发现，关卡往往不是硬编码在逻辑里的，而是用一张文本地图描述。文本里的每个字符代表一种瓦片或一个摆位：空格是空气，1是普通砖块，2是问号砖，3是管道，M是敌人出生点。程序启动时逐行扫描这个文本，把瓦片填进二维数组，同时把M字符替换成敌人对象。

// 关卡数据，每行一个字符串，对应游戏里一行瓦片 static const char* level_map[] = { "00000000000000000000", "00000000000000030000", "000000M0000001030000", "00000000000010110000", "00000000011111111111", "11111111111111111111", }; // 编译期算出地图宽高 const int MAP_W = (int)strlen(level_map[0]); const int MAP_H = sizeof(level_map) / sizeof(level_map[0]);

解析逻辑通常写成两层循环：按行按列读字符，遇到1就在tile数组里填SOLID，遇到2在对应位置生成一个问号砖对象，遇到M调用SpawnEnemy函数。敌人列表是一个动态数组或者固定长度结构体数组，每个敌人结构体包含位置、速度、存活标记、精灵对象。这种数据驱动设计的优点是加一个新关卡不需要改动任何逻辑代码。

道具和敌人有一类共享代码要特别注意：问号砖里弹出蘑菇的实现。源码里一般会用对象池的简化版——在地图解析阶段预生成一批道具对象，初始状态设为隐藏，当玩家顶到砖块时把对应道具的隐藏标记去掉，让它开始上移然后下落。这套思路放到现在做游戏也一样适用：对象池减少运行时创建销毁的开销，老代码早就在用这个方案，只是写得朴素。

4.4 动画与音频：让角色“活起来”的两个细节

HGE里精灵动画不靠引擎，靠代码切换纹理区域。一张角色图集里横向排列了多帧动作，加载成HTEXTURE纹理后，每个hgeSprite对象只显示其中一小块矩形区域，例如new hgeSprite(tex, 0, 0, 16, 28)显示第一帧，new hgeSprite(tex, 16, 0, 16, 28)显示第二帧。行走动画就是每0.1秒切换一次帧索引，按下方向键时按帧索引递增顺序播放。

音效这部分，HGE把音频分成了音乐流和音效两类。音效适合跳跃这种短促声音，用hge->Effect_Play传入音效句柄即可，调用完不用管释放。跳跃音效的触发位置要放在输入处理之后、起跳条件成立的那个if分支里，如果放在碰撞检测之后，会出现角色已经跳起但声音晚半拍的延迟感。

背景音乐流的接口能循环播放，适合关卡BGM。切换场景时记得先停止旧音乐再播放新音乐，老引擎没有自动切换功能，忘掉停播会有两个BGM叠加播放的翻车效果。

5. HGE马里奥从编译到运行的避坑记录：5个典型翻车现场

5.1 闪退与缺DLL：运行库和文件位置

现象：编译成功，双击mario.exe黑屏一闪就退出，或者弹窗提示找不到hge.dll / VCRUNTIME140.dll。

原因分两类。hge.dll找不到是文件位置问题：HGE引擎是动态链接，exe启动时会在exe同目录、系统PATH目录里搜索DLL。老游戏源码包里的hge.dll可能放在lib子目录，而exe在另一个目录，导致运行期加载失败。VCRUNTIME140.dll缺失则是目标机器没装VC++运行库，和源码本身无关。

解决：先把hge.dll复制到exe同目录，这是最优先操作。然后在命令行里手动运行一次exe，操作系统会明确告诉你缺哪个模块，比弹窗信息更详细。最后安装对应版本的microsoft visual c++ redistributable package，注意x86版本必须装，哪怕操作系统是64位，因为exe本身是32位程序，加载的是32位运行库。

注意：不建议把hge.dll丢到C:\Windows\System32里。这台机器能跑，换台机器还是崩。正确做法是让exe和hge.dll永远待在同一目录，把整个游戏目录打包分发。

5.2 编译报错三连：hge.h找不到、字符集冲突、库不匹配

现象：Visual Studio编译报fatal error C1083，提示Cannot open include file: 'hge.h'；或者报C2664，提示无法从const char*转换到LPCWSTR；或者链接阶段报LNK2019，一堆无法解析的外部符号。

原因分别对应三个配置错误。hge.h找不到是附加包含目录没配，编译器根本不知道HGE头文件在哪。C2664是字符集问题，工程默认用Unicode字符集，而HGE老代码基于多字节字符集，Win32 API函数自动被宏替换成宽字符版本，参数类型就对不上了。LNK2019是链接器没找到hge.lib的实现，或者lib的位数和工程位数不匹配，64位工程链接32位库必然报这个。

解决：在工程属性里按顺序检查三处。C/C++常规里的附加包含目录加上HGE的include路径；链接器常规里的附加库目录加上HGE的lib路径；链接器输入里的附加依赖项手动填入hge.lib、user32.lib、winmm.lib。字符集选项在“高级”里直接改成“使用多字节字符集”。全部改完后先写一个只打印版本号的空main函数测试编译链路通不通，再引入源码文件，逐层缩小排错范围。

5.3 画面异常：全屏黑屏、贴图空白与“IDE里正常双击却崩”

现象：窗口模式一切正常，切全屏就黑屏或者花屏；游戏能跑，但角色和砖块全是空白方块；F5在Visual Studio里运行正常，关掉IDE去文件夹里双击exe，资源加载失败。

原因：全屏黑屏通常是HGE老引擎对现代显卡的DirectX 9兼容性出了问题，虚拟机环境尤其明显，显卡驱动只提供部分D3D9功能。贴图空白大概率是资源路径里的中文目录名，HGE内部用ANSI字符串打开文件，中文路径在简体中文系统上有时能跑通，但换个语言区域直接崩。IDE里正常双击崩，原因是工作目录不同：VS调试时以工程目录为当前目录，双击exe时以exe所在目录为当前目录，资源相对路径指向的位置就变了。

解决：全屏问题优先改成窗口模式，把HGE_WINDOWED设为true，分辨率降到800x600，这个问题基本消失。作为兜底，可以右键exe打开属性，在兼容性里勾选“禁用全屏优化”。贴图空白把整个游戏目录改成英文纯路径，不要出现“游戏源码_Mario”这类命名。工作目录问题在工程属性“调试→工作目录”里显式填成$(OutDir)，这样无论IDE还是双击，当前目录都统一到exe目录。

6. 从复现到改造：换贴图、加敌人，用一张验证清单收尾

6.1 把马里奥的贴图换成你自己的

找到玩家初始化时加载纹理的代码，它通常是hge->Texture_Load("res/player.png")。替换成你的图片时注意两点：纹理尺寸尽量保持2的幂倍数宽度，比如128x128，老HGE引擎对非2幂尺寸的纹理兼容性不齐，放大后会有黑边；替换贴图之后碰撞盒w和h不要改，碰撞盒应该跟着逻辑走，不是跟着美术走。

6.2 加一个新敌人：最少改动量

在敌人出生表里加一个枚举值和对应贴图，再在SpwanEnemy函数里模仿已有敌人写一行生成代码。老源码的敌人逻辑多半集中在同一个UpdateEnemy函数里，用枚举区分行为。我的习惯是先换贴图不换AI，验证数据链路通了，再改AI分支。

6.3 三分钟手感验证清单

验证项	预期表现
编译	无报错，生成exe
运行	窗口弹出，不黑屏不闪退
按键	左右移动灵敏，无拖沓
跳跃	落地前无法二段跳，顶头会弹回
碰撞	穿不过砖块，可以踩上敌人
替换素材	新贴图正确显示，无黑边空块