小球动画这个系列写到第三篇其实已经过了“能跑起来就行”的阶段了。前两篇我们把窗口、绘图循环、小球的基本运动搭了起来但真正让一个初学者从“照着敲代码”跨到“自己能改效果”的分水岭恰恰是这第三篇要聊的东西——运动状态的精细控制。我见过太多人卡在这里球能动但动得别扭撞墙反弹角度不对速度一快就穿墙帧率一变整个动画就乱套。这些问题不解决后面做打砖块、做弹球游戏全是空中楼阁。这篇内容面向的是已经能用 EasyX 画出图形、写过简单循环的 C/C 学习者也适合那些想给孩子做编程启蒙、自己先摸一遍路的家长朋友。我会把小球动画里最容易被忽略的速度分解、边界检测、帧率控制、状态管理这几块掰开揉碎讲清楚每个参数为什么这么设、每行关键代码背后的意图是什么都给你交代明白。看完你手里的小球应该能做到匀速运动、精准反弹、速度可调、窗口拉伸不乱、长时间运行不飘。这些听起来基础但真正做到“稳”里面全是细节。1. 整体设计思路为什么第三篇才是真正的分水岭1.1 从“会画”到“会动”再到“动得对”的三级跳很多人学 EasyX 的路径是这样的第一篇学会initgraph开窗口、circle画圆、getchar停住第二篇学会用while循环加cleardevice做刷新让球位置每次加一点看起来就动了。到这一步大部分人会有一种“我已经会了”的错觉。但你把代码跑上三十秒就会发现球要么越跑越偏要么撞到边上直接卡死要么窗口一拖动整个节奏就崩。原因在于前两篇解决的是“视觉上的动”第三篇要解决的是“物理上的对”。这两者之间的差距本质上是从命令式绘图思维切换到状态机加时间步进思维。我打个比方前两篇你是在一张纸上反复擦掉重画第三篇你要开始考虑“这张纸多大、我每秒擦几次、球撞到纸边该怎么拐弯”。这是完全不同的思考层次。具体来说第三篇要引入四个核心概念它们构成了后续所有 2D 小游戏的地基速度向量分解把“速度”拆成 x 和 y 两个分量而不是一个笼统的“快慢”。边界反射逻辑撞墙不是简单取反要判断撞的是哪面墙、反弹后位置怎么修正。帧率与时间步让运动速度跟真实时间挂钩而不是跟循环次数挂钩。状态封装把球的位置、速度、半径打包成一个结构体为后面加多个球做准备。这四个点任何一个没吃透后面做复杂游戏都会反复回来补课。所以我说第三篇是分水岭不是夸张。1.2 为什么不用现成物理引擎偏要手写有朋友会问现在不是有 Box2D 这类物理库吗为什么还要手写这些这个问题问得好我的回答分两层。第一层是学习目的你连一个球的反弹都写不明白给你物理引擎你也调不动参数出了问题根本不知道从哪查。第二层是工程现实EasyX 本身是个轻量绘图库它的定位就是教学和小型 Demo硬塞一个物理引擎进来编译配置、依赖管理对初学者是灾难。手写这套逻辑代码量其实不大一个Ball结构体加一个更新函数两百行以内能搞定但换来的是你对每一帧发生了什么完全心里有数。我个人的经验是手写一遍之后你再去看任何 2D 游戏的源码看到velocity、deltaTime、collision这些词脑子里立刻能还原出画面。这种“底层可视感”是调库调不出来的。1.3 本篇的代码组织约定为了后面讲得清楚先约定一下代码结构。我用一个Ball结构体承载状态主循环里做三件事处理输入本篇暂时只有退出、更新状态、渲染画面。这个“输入-更新-渲染”三段式是所有游戏循环的通用骨架你现在养成习惯后面换任何语言、任何框架都是这个套路。struct Ball { float x, y; // 球心坐标 float vx, vy; // 速度分量单位像素/秒 float radius; // 半径 COLORREF color; // 颜色 };注意这里坐标和速度我都用float而不是int。这是本篇第一个关键决策后面会详细解释为什么。先记住一句话整数坐标做匀速运动必然抖动浮点坐标加渲染时取整才是正解。2. 速度向量与边界反射把“撞墙”这件事算明白2.1 速度为什么要拆成 vx 和 vy初学者最容易犯的错是把速度当成一个标量比如“球每秒走 5 像素”然后斜着运动时用x 5; y 5;。这样写出来的球永远走 45 度角你想让它走得平一点、陡一点根本没法调。更麻烦的是撞墙反弹你没法只反转“水平方向的速度”因为速度根本没分方向。正确的做法是把速度看成二维向量拆成水平分量vx和垂直分量vy。斜向运动时vx和vy的比值决定了运动方向它们的模长决定了快慢。比如vx 300, vy 150球就是往右下方向、水平偏多的斜线走速度大小是sqrt(300² 150²) ≈ 335像素/秒。这个拆分的直接好处是撞左墙或右墙时只反转vxvy不动撞上墙或下墙时只反转vyvx不动。物理上这叫“法向速度反转、切向速度保持”是弹性碰撞在轴对齐边界上的简化形式。你不用记这个术语记住“撞哪面墙就反哪个分量”就够了。2.2 边界检测的三种写法与踩坑实录边界检测看起来简单其实写法差异很大我按从差到好给你排一遍。写法一先移动再判断撞了就取反x vx * dt; y vy * dt; if (x - radius 0 || x radius width) vx -vx; if (y - radius 0 || y radius height) vy -vy;这是最常见的入门写法能跑但有两个隐患。第一球撞墙后位置已经越界了你只反转速度没修正位置下一帧它可能还在墙外导致连续反转、球卡在墙边抖动。第二速度大的时候一帧移动距离超过球直径球可能直接“穿”过墙跑到另一边检测都检测不到。写法二先判断再移动撞了就修正位置if (x - radius vx * dt 0) { vx -vx; x radius; // 强制拉回边界内侧 } else if (x radius vx * dt width) { vx -vx; x width - radius; } else { x vx * dt; }这种写法把“预测下一帧位置”和“修正”结合起来球不会越界也不会卡墙。缺点是代码变长而且左右、上下要写四段稍显啰嗦。但这是我认为最稳妥的写法尤其适合初学者因为逻辑直白出问题好查。写法三统一用反射公式x vx * dt; if (x - radius 0) { x radius; vx -vx; } if (x radius width) { x width - radius; vx -vx; }这是写法二的简化版先移动再修正。因为修正时把位置强制拉回边界所以不会出现写法一的卡墙问题。穿墙问题依然存在但可以通过限制单帧最大位移来缓解见 2.4 节。实际项目中我用得最多的就是这种简洁且够用。注意无论哪种写法判断条件里的radius都不能漏。漏了的话球是“球心撞墙”才反弹视觉上球会陷进墙里一半非常难看。2.3 反弹时的位置修正为什么不能省我单独把这条拎出来讲是因为它是最容易被忽略、又最影响观感的一环。假设球半径 20窗口宽 800球从右边撞墙某一帧算出来x 815已经超出800 - 20 780的合法上限。如果你只反转vx不修正x下一帧球从 815 往回走但它要走到 780 才“看起来”贴墙中间这段它在墙外飘着视觉上就是球穿出去了又回来。修正的做法就是把x直接设成width - radius让球紧贴边界内侧。这样反弹点精确、观感干净。同理左边是x radius上边y radius下边y height - radius。这四个值建议你拿张纸画一下把坐标系EasyX 原点在左上角y 向下为正标清楚画一遍比看十遍代码管用。2.4 高速穿墙一个必须提前防的坑当vx很大比如 2000 像素/秒而你的循环一帧间隔 16 毫秒那一帧球移动 32 像素。如果球半径只有 10它完全可能从墙内 10 像素的位置一帧直接跳到墙外 22 像素中间跨过了整个边界区域。如果你的检测是“移动后判断是否越界”那还能抓到但如果是“判断下一帧是否越界再决定移不移”就可能漏判。解决办法有两个。一是限制单帧最大位移比如规定一帧最多移动radius像素超了就拆成多次小步更新。二是用连续碰撞检测算球在这一帧路径上最早碰到墙的时刻。第二种对初学者偏复杂我推荐第一种简单有效float maxStep radius; // 单步最大位移 int steps (int)ceil(maxSpeed * dt / maxStep); for (int i 0; i steps; i) { // 每次只走 dt/steps 的时间重复检测 }这段代码的意思是这一帧总共要走多远如果超过一个半径就拆成几步走每步都做一次边界检测。这样再快也不会穿墙。实际做小游戏时速度一般不会夸张到需要拆步但你把这段逻辑留着后面做子弹、做快速移动的敌人时直接能用。3. 帧率控制与时间步让动画“稳”下来的核心3.1 为什么按帧计数运动一定会出问题第二篇里我们大概率是这么写的while(1) { x 5; cleardevice(); circle(x, y, r); Sleep(10); }。这段代码在你自己电脑上跑得好好的换台机器就变快或变慢窗口一拖动球就“瞬移”最小化再恢复直接乱套。根源在于你把“运动速度”绑死在了“循环执行频率”上而循环频率受 CPU 调度、系统负载、窗口消息处理影响根本不稳定。正确的思路是运动只跟真实流逝的时间挂钩。每帧开始时记录当前时间和上一帧时间相减得到dtdelta time单位秒然后x vx * dt。这样不管你这帧花了 10 毫秒还是 50 毫秒球移动的距离都对应真实时间视觉速度恒定。这就是所谓“基于时间步进”的运动是所有正经游戏引擎的标配。3.2 用 EasyX 自带计时还是标准库计时EasyX 提供了GetTickCount()这类接口精度是毫秒级够用但偏粗。我更推荐用 C11 的std::chrono精度到微秒代码也不复杂#include chrono using Clock std::chrono::steady_clock; auto last Clock::now(); while (running) { auto now Clock::now(); float dt std::chrono::durationfloat(now - last).count(); last now; // 用 dt 更新球的状态 }steady_clock是单调时钟不受系统时间调整影响做游戏循环最合适。注意durationfloat把时间差转成浮点秒数这样vx * dt直接就是像素位移单位统一不用来回换算。3.3 dt 的钳制一个救命的细节直接拿两帧时间差当dt有个隐患如果程序被系统挂起、或者你拖动窗口卡了一下dt可能变成好几秒。这时候vx * dt会算出一个巨大的位移球直接飞出天际甚至触发浮点异常。所以必须对dt做上限钳制const float MAX_DT 0.05f; // 最大 50 毫秒约等于 20 FPS 的下限 if (dt MAX_DT) dt MAX_DT;这个 0.05 秒不是随便定的。它对应 20 FPS意思是“就算你这帧卡成 20 帧每秒我也只按 20 帧的步长更新”。低于这个帧率动画本来就已经不流畅了再按真实时间走反而会让球瞬移不如钳住让运动稍微变慢但保持连续。这个技巧在真实项目里非常常用你记住“dt 一定要钳”就行。3.4 固定时间步 vs 可变时间步的取舍严格来说物理模拟用固定时间步更稳定比如固定每步 1/60 秒累积真实时间够一步就更新一步。但对我们这个级别的小球动画可变时间步加钳制已经完全够用代码也简单得多。我的建议是小球动画用可变步长等你以后做多物体碰撞、做需要精确复现的物理效果时再上固定步长加插值。现在别过度设计先把可变步长跑稳。不过有个细节要注意可变步长下如果dt每帧波动很大球的运动会有轻微不均匀感。解决办法是渲染时对位置做插值或者干脆把dt平滑一下比如取最近几帧的平均。这些属于锦上添花初学阶段可以先不做但你要知道有这回事。4. 状态封装与主循环骨架为后续扩展留好接口4.1 用结构体管理球的状态前面已经给出了Ball结构体的定义这里说说为什么这么设计。把x, y, vx, vy, radius, color打包在一起好处是更新函数只需要接收一个Ball渲染函数也只需要一个Ball将来加第二个球、第三个球直接开数组或者vectorBall循环处理即可。如果你把位置速度散落成一堆全局变量加第二个球的时候就得复制粘贴一堆代码改一个参数要改好几处维护成本爆炸。void updateBall(Ball b, float dt, int width, int height) { b.x b.vx * dt; b.y b.vy * dt; if (b.x - b.radius 0) { b.x b.radius; b.vx -b.vx; } if (b.x b.radius width) { b.x width - b.radius; b.vx -b.vx; } if (b.y - b.radius 0) { b.y b.radius; b.vy -b.vy; } if (b.y b.radius height) { b.y height - b.radius; b.vy -b.vy; } }这个函数就是整个动画的心脏。它不关心窗口怎么开、颜色怎么设只负责“根据当前状态和流逝时间算出新状态”。这种“状态更新与渲染分离”的设计是后面所有游戏逻辑的基础。你以后加重力就在这里面给vy加一个增量加摩擦力就给vx, vy乘一个衰减系数。改动都集中在一处非常清爽。4.2 主循环的三段式骨架initgraph(800, 600); Ball ball { 400, 300, 300, 200, 20, RED }; auto last Clock::now(); bool running true; while (running) { // 1. 处理输入 if (_kbhit()) { if (_getch() 27) running false; // ESC 退出 } // 2. 更新状态 auto now Clock::now(); float dt std::chrono::durationfloat(now - last).count(); last now; if (dt 0.05f) dt 0.05f; updateBall(ball, dt, 800, 600); // 3. 渲染 cleardevice(); setfillcolor(ball.color); solidcircle((int)ball.x, (int)ball.y, (int)ball.radius); FlushBatchDraw(); // 如果开了批量绘图 Sleep(1); // 让出 CPU避免空转占满一个核 } closegraph();这个骨架里有两个细节值得说。第一Sleep(1)不是必须的但强烈建议加。不加的话循环会疯狂空转CPU 占用飙到 100%笔记本风扇狂转而且dt会小到接近 0反而让计时精度变差。加 1 毫秒让出 CPU循环频率自然降到千赫兹级别既流畅又不浪费。第二solidcircle的坐标参数是int所以渲染时把float强转成int。这里用强转而不是round是因为强转是截断对高速运动影响不大如果你追求更平滑可以用(int)round(ball.x)代价是多一次函数调用。4.3 窗口尺寸变化时的处理EasyX 的窗口默认不能拉伸但如果你用了可调整大小的窗口或者以后想支持全屏就得处理尺寸变化。核心思路是把窗口宽高存成变量每次更新前重新获取边界检测用最新的宽高。这样窗口一变球的反弹边界立刻跟着变不会出现球跑到窗口外面去的情况。int width getwidth(); int height getheight(); updateBall(ball, dt, width, height);getwidth和getheight是 EasyX 提供的接口返回当前绘图窗口的尺寸。每帧调一次开销很小换来的是对窗口变化的即时响应。这个习惯建议从现在就养成别把 800 和 600 硬编码在边界检测里。5. 常见问题排查与调参经验5.1 球卡在墙角抖动怎么办这是最典型的问题现象是球撞到角落时在两个方向反复反转卡住不动或者疯狂抖动。原因通常是两个方向的检测在同一帧都触发了而且位置修正没做或者做错了。排查步骤先确认四个边界判断是不是独立的if而不是else if角落需要两个方向都处理再确认每个分支里都做了位置修正。如果还抖检查是不是速度太大导致一帧内多次越界用 2.4 节的拆步方案解决。5.2 球运动一顿一顿的先看dt是不是波动太大。可以在循环里临时打印dt正常应该在 0.001 到 0.02 之间小幅波动。如果经常跳到 0.05 以上说明你的循环里有阻塞操作比如Sleep时间太长、或者渲染太慢。另一个常见原因是用了int存坐标导致低速运动时位置取整后跳变。改成float存坐标、渲染时取整立刻顺滑。5.3 反弹角度看起来不对如果你发现球撞墙后角度变得很怪检查是不是把vx和vy搞混了或者撞左墙却反转了vy。还有一种情况是速度分量大小差太多比如vx 500, vy 10球几乎是水平飞撞上下墙后vy反转但依然很小看起来就像“贴着墙滑”。这不是 bug是参数设置问题调一下vx, vy的比例就行。5.4 长时间运行后球的位置飘了浮点数累加会有精度误差跑几个小时可能偏几个像素。对小球动画来说这无所谓但如果你做的是需要精确复现的场景就得定期把位置钳制在合法范围内或者用定点数。日常小游戏不用管这个知道有这回事即可。问题现象最可能原因排查动作球卡墙角抖动位置修正缺失或用了 else if检查四个 if 是否独立、是否都修正位置运动一顿一顿dt 波动大或坐标用了 int打印 dt、坐标改 float高速穿墙单帧位移超过半径加拆步逻辑或限制最大速度反弹角度怪vx/vy 搞混或反转错分量对照撞墙方向检查反转的是哪个分量窗口变化后球跑出去边界硬编码改用 getwidth/getheight5.5 几个调参的小心得速度参数我一般从vx 300, vy 200起步这个组合在 800x600 窗口里大约 3 秒横穿一次观感比较舒服。半径 20 左右太小了看不清太大了撞墙频繁。颜色用纯色就行别一上来就搞渐变渲染开销和代码复杂度都不划算。如果你想让球看起来更有“弹性”可以在撞墙瞬间给球做一个短暂的缩放动画这个属于进阶效果等基础跑稳了再玩。提示调试运动逻辑时把速度调慢比如 vx50, vy30肉眼能看清每一帧球的位置变化比盯着快速运动的球找 bug 高效得多。6. 从单球到多球这套骨架的扩展性验证6.1 加第二个球只需要改三行前面强调结构体封装的好处这里验证一下。加第二个球你只需要定义第二个Ball变量、在主循环里对它调一次updateBall、渲染时多画一个圆。核心逻辑一行不用改。这就是“状态与逻辑分离”的威力。如果你一开始用全局变量写现在就得复制一整套x2, y2, vx2, vy2还要复制边界检测代码改一个 bug 要改两处迟早出错。Ball ball2 { 200, 200, -250, 180, 15, BLUE }; // 循环里 updateBall(ball, dt, width, height); updateBall(ball2, dt, width, height); // 渲染 solidcircle((int)ball.x, (int)ball.y, (int)ball.radius); solidcircle((int)ball2.x, (int)ball2.y, (int)ball2.radius);更进一步用std::vectorBall存任意多个球循环遍历更新和渲染代码量几乎不随球数增长。这个模式你以后做粒子效果、做敌人群都是同一套。6.2 球与球碰撞的预告多球之后自然会想“让它们互相撞”。球球碰撞比撞墙复杂核心是判断两球圆心距离是否小于半径之和碰撞后要沿连心线方向交换速度分量。这部分内容量不小我打算放在下一篇单独讲。这里先给你一个判断条件你可以自己先试试float dx b2.x - b1.x; float dy b2.y - b1.y; float dist sqrt(dx*dx dy*dy); if (dist b1.radius b2.radius) { // 发生碰撞处理反弹 }注意sqrt有开销实际项目里常比较距离平方来避免开方即dx*dx dy*dy (r1r2)*(r1r2)。这个优化在小规模场景无所谓但养成习惯没坏处。6.3 性能上的现实考量有人担心每帧cleardevice加重绘会不会卡。实测在 800x600 窗口、几十个球的情况下EasyX 完全扛得住帧率轻松上百。真正的瓶颈往往在FlushBatchDraw的调用时机和Sleep的设置上。如果你发现球多了以后变卡先检查是不是每画一个球就FlushBatchDraw一次正确做法是所有绘制完成后统一 flush 一次。批量绘图的开关用BeginBatchDraw和EndBatchDraw包住整个渲染段能显著减少闪烁和开销。我在实际项目里踩过的一个坑是开了批量绘图却忘了在循环里调FlushBatchDraw结果画面一直不更新还以为是运动逻辑写错了查了半天。这个教训分享给你遇到“逻辑对但画面不动”先查批量绘图的 flush。7. 写在代码之外的一点体会这套小球动画的代码前后加起来不到两百行但它把游戏开发里最核心的几个概念——时间步进、状态管理、边界处理、渲染循环——全都串了一遍。我带过不少初学者发现一个规律那些愿意在这里停下来把dt钳制、把位置修正、把结构体封装这些“看不见效果”的细节做扎实的人后面学什么都快而那些急着加功能、跳过基础的人做到第三个项目就会全面崩盘回头补课的成本高得多。所以我的建议很直接别急着让球变出花样先让它稳稳地跑上十分钟不出任何异常。你能做到这一点说明你对这套骨架的理解到位了后面加重力、加碰撞、加关卡都是在这个稳固地基上添砖加瓦。速度参数你可以随便调调坏了大不了重来但时间步进和状态封装这两块的设计一开始就要按对的来别图省事用全局变量加固定增量那是给自己挖坑。最后分享一个我常用的自检方法把窗口最小化放那儿跑半小时再恢复看球是不是还在正常运动、位置有没有异常。这个测试能一次性暴露计时、钳制、状态更新里的绝大多数隐藏问题。跑得过这一关你的小球动画才算真正“稳”了。 
长河君 · 2026/10/27 22:32:13 · 阅读 1.2k C/C++小球动画进阶：速度分解、边界反射与帧率控制
小球动画这个系列写到第三篇其实已经过了“能跑起来就行”的阶段了。前两篇我们把窗口、绘图循环、小球的基本运动搭了起来但真正让一个初学者从“照着敲代码”跨到“自己能改效果”的分水岭恰恰是这第三篇要聊的东西——运动状态的精细控制。我见过太多人卡在这里球能动但动得别扭撞墙反弹角度不对速度一快就穿墙帧率一变整个动画就乱套。这些问题不解决后面做打砖块、做弹球游戏全是空中楼阁。这篇内容面向的是已经能用 EasyX 画出图形、写过简单循环的 C/C 学习者也适合那些想给孩子做编程启蒙、自己先摸一遍路的家长朋友。我会把小球动画里最容易被忽略的速度分解、边界检测、帧率控制、状态管理这几块掰开揉碎讲清楚每个参数为什么这么设、每行关键代码背后的意图是什么都给你交代明白。看完你手里的小球应该能做到匀速运动、精准反弹、速度可调、窗口拉伸不乱、长时间运行不飘。这些听起来基础但真正做到“稳”里面全是细节。1. 整体设计思路为什么第三篇才是真正的分水岭1.1 从“会画”到“会动”再到“动得对”的三级跳很多人学 EasyX 的路径是这样的第一篇学会initgraph开窗口、circle画圆、getchar停住第二篇学会用while循环加cleardevice做刷新让球位置每次加一点看起来就动了。到这一步大部分人会有一种“我已经会了”的错觉。但你把代码跑上三十秒就会发现球要么越跑越偏要么撞到边上直接卡死要么窗口一拖动整个节奏就崩。原因在于前两篇解决的是“视觉上的动”第三篇要解决的是“物理上的对”。这两者之间的差距本质上是从命令式绘图思维切换到状态机加时间步进思维。我打个比方前两篇你是在一张纸上反复擦掉重画第三篇你要开始考虑“这张纸多大、我每秒擦几次、球撞到纸边该怎么拐弯”。这是完全不同的思考层次。具体来说第三篇要引入四个核心概念它们构成了后续所有 2D 小游戏的地基速度向量分解把“速度”拆成 x 和 y 两个分量而不是一个笼统的“快慢”。边界反射逻辑撞墙不是简单取反要判断撞的是哪面墙、反弹后位置怎么修正。帧率与时间步让运动速度跟真实时间挂钩而不是跟循环次数挂钩。状态封装把球的位置、速度、半径打包成一个结构体为后面加多个球做准备。这四个点任何一个没吃透后面做复杂游戏都会反复回来补课。所以我说第三篇是分水岭不是夸张。1.2 为什么不用现成物理引擎偏要手写有朋友会问现在不是有 Box2D 这类物理库吗为什么还要手写这些这个问题问得好我的回答分两层。第一层是学习目的你连一个球的反弹都写不明白给你物理引擎你也调不动参数出了问题根本不知道从哪查。第二层是工程现实EasyX 本身是个轻量绘图库它的定位就是教学和小型 Demo硬塞一个物理引擎进来编译配置、依赖管理对初学者是灾难。手写这套逻辑代码量其实不大一个Ball结构体加一个更新函数两百行以内能搞定但换来的是你对每一帧发生了什么完全心里有数。我个人的经验是手写一遍之后你再去看任何 2D 游戏的源码看到velocity、deltaTime、collision这些词脑子里立刻能还原出画面。这种“底层可视感”是调库调不出来的。1.3 本篇的代码组织约定为了后面讲得清楚先约定一下代码结构。我用一个Ball结构体承载状态主循环里做三件事处理输入本篇暂时只有退出、更新状态、渲染画面。这个“输入-更新-渲染”三段式是所有游戏循环的通用骨架你现在养成习惯后面换任何语言、任何框架都是这个套路。struct Ball { float x, y; // 球心坐标 float vx, vy; // 速度分量单位像素/秒 float radius; // 半径 COLORREF color; // 颜色 };注意这里坐标和速度我都用float而不是int。这是本篇第一个关键决策后面会详细解释为什么。先记住一句话整数坐标做匀速运动必然抖动浮点坐标加渲染时取整才是正解。2. 速度向量与边界反射把“撞墙”这件事算明白2.1 速度为什么要拆成 vx 和 vy初学者最容易犯的错是把速度当成一个标量比如“球每秒走 5 像素”然后斜着运动时用x 5; y 5;。这样写出来的球永远走 45 度角你想让它走得平一点、陡一点根本没法调。更麻烦的是撞墙反弹你没法只反转“水平方向的速度”因为速度根本没分方向。正确的做法是把速度看成二维向量拆成水平分量vx和垂直分量vy。斜向运动时vx和vy的比值决定了运动方向它们的模长决定了快慢。比如vx 300, vy 150球就是往右下方向、水平偏多的斜线走速度大小是sqrt(300² 150²) ≈ 335像素/秒。这个拆分的直接好处是撞左墙或右墙时只反转vxvy不动撞上墙或下墙时只反转vyvx不动。物理上这叫“法向速度反转、切向速度保持”是弹性碰撞在轴对齐边界上的简化形式。你不用记这个术语记住“撞哪面墙就反哪个分量”就够了。2.2 边界检测的三种写法与踩坑实录边界检测看起来简单其实写法差异很大我按从差到好给你排一遍。写法一先移动再判断撞了就取反x vx * dt; y vy * dt; if (x - radius 0 || x radius width) vx -vx; if (y - radius 0 || y radius height) vy -vy;这是最常见的入门写法能跑但有两个隐患。第一球撞墙后位置已经越界了你只反转速度没修正位置下一帧它可能还在墙外导致连续反转、球卡在墙边抖动。第二速度大的时候一帧移动距离超过球直径球可能直接“穿”过墙跑到另一边检测都检测不到。写法二先判断再移动撞了就修正位置if (x - radius vx * dt 0) { vx -vx; x radius; // 强制拉回边界内侧 } else if (x radius vx * dt width) { vx -vx; x width - radius; } else { x vx * dt; }这种写法把“预测下一帧位置”和“修正”结合起来球不会越界也不会卡墙。缺点是代码变长而且左右、上下要写四段稍显啰嗦。但这是我认为最稳妥的写法尤其适合初学者因为逻辑直白出问题好查。写法三统一用反射公式x vx * dt; if (x - radius 0) { x radius; vx -vx; } if (x radius width) { x width - radius; vx -vx; }这是写法二的简化版先移动再修正。因为修正时把位置强制拉回边界所以不会出现写法一的卡墙问题。穿墙问题依然存在但可以通过限制单帧最大位移来缓解见 2.4 节。实际项目中我用得最多的就是这种简洁且够用。注意无论哪种写法判断条件里的radius都不能漏。漏了的话球是“球心撞墙”才反弹视觉上球会陷进墙里一半非常难看。2.3 反弹时的位置修正为什么不能省我单独把这条拎出来讲是因为它是最容易被忽略、又最影响观感的一环。假设球半径 20窗口宽 800球从右边撞墙某一帧算出来x 815已经超出800 - 20 780的合法上限。如果你只反转vx不修正x下一帧球从 815 往回走但它要走到 780 才“看起来”贴墙中间这段它在墙外飘着视觉上就是球穿出去了又回来。修正的做法就是把x直接设成width - radius让球紧贴边界内侧。这样反弹点精确、观感干净。同理左边是x radius上边y radius下边y height - radius。这四个值建议你拿张纸画一下把坐标系EasyX 原点在左上角y 向下为正标清楚画一遍比看十遍代码管用。2.4 高速穿墙一个必须提前防的坑当vx很大比如 2000 像素/秒而你的循环一帧间隔 16 毫秒那一帧球移动 32 像素。如果球半径只有 10它完全可能从墙内 10 像素的位置一帧直接跳到墙外 22 像素中间跨过了整个边界区域。如果你的检测是“移动后判断是否越界”那还能抓到但如果是“判断下一帧是否越界再决定移不移”就可能漏判。解决办法有两个。一是限制单帧最大位移比如规定一帧最多移动radius像素超了就拆成多次小步更新。二是用连续碰撞检测算球在这一帧路径上最早碰到墙的时刻。第二种对初学者偏复杂我推荐第一种简单有效float maxStep radius; // 单步最大位移 int steps (int)ceil(maxSpeed * dt / maxStep); for (int i 0; i steps; i) { // 每次只走 dt/steps 的时间重复检测 }这段代码的意思是这一帧总共要走多远如果超过一个半径就拆成几步走每步都做一次边界检测。这样再快也不会穿墙。实际做小游戏时速度一般不会夸张到需要拆步但你把这段逻辑留着后面做子弹、做快速移动的敌人时直接能用。3. 帧率控制与时间步让动画“稳”下来的核心3.1 为什么按帧计数运动一定会出问题第二篇里我们大概率是这么写的while(1) { x 5; cleardevice(); circle(x, y, r); Sleep(10); }。这段代码在你自己电脑上跑得好好的换台机器就变快或变慢窗口一拖动球就“瞬移”最小化再恢复直接乱套。根源在于你把“运动速度”绑死在了“循环执行频率”上而循环频率受 CPU 调度、系统负载、窗口消息处理影响根本不稳定。正确的思路是运动只跟真实流逝的时间挂钩。每帧开始时记录当前时间和上一帧时间相减得到dtdelta time单位秒然后x vx * dt。这样不管你这帧花了 10 毫秒还是 50 毫秒球移动的距离都对应真实时间视觉速度恒定。这就是所谓“基于时间步进”的运动是所有正经游戏引擎的标配。3.2 用 EasyX 自带计时还是标准库计时EasyX 提供了GetTickCount()这类接口精度是毫秒级够用但偏粗。我更推荐用 C11 的std::chrono精度到微秒代码也不复杂#include chrono using Clock std::chrono::steady_clock; auto last Clock::now(); while (running) { auto now Clock::now(); float dt std::chrono::durationfloat(now - last).count(); last now; // 用 dt 更新球的状态 }steady_clock是单调时钟不受系统时间调整影响做游戏循环最合适。注意durationfloat把时间差转成浮点秒数这样vx * dt直接就是像素位移单位统一不用来回换算。3.3 dt 的钳制一个救命的细节直接拿两帧时间差当dt有个隐患如果程序被系统挂起、或者你拖动窗口卡了一下dt可能变成好几秒。这时候vx * dt会算出一个巨大的位移球直接飞出天际甚至触发浮点异常。所以必须对dt做上限钳制const float MAX_DT 0.05f; // 最大 50 毫秒约等于 20 FPS 的下限 if (dt MAX_DT) dt MAX_DT;这个 0.05 秒不是随便定的。它对应 20 FPS意思是“就算你这帧卡成 20 帧每秒我也只按 20 帧的步长更新”。低于这个帧率动画本来就已经不流畅了再按真实时间走反而会让球瞬移不如钳住让运动稍微变慢但保持连续。这个技巧在真实项目里非常常用你记住“dt 一定要钳”就行。3.4 固定时间步 vs 可变时间步的取舍严格来说物理模拟用固定时间步更稳定比如固定每步 1/60 秒累积真实时间够一步就更新一步。但对我们这个级别的小球动画可变时间步加钳制已经完全够用代码也简单得多。我的建议是小球动画用可变步长等你以后做多物体碰撞、做需要精确复现的物理效果时再上固定步长加插值。现在别过度设计先把可变步长跑稳。不过有个细节要注意可变步长下如果dt每帧波动很大球的运动会有轻微不均匀感。解决办法是渲染时对位置做插值或者干脆把dt平滑一下比如取最近几帧的平均。这些属于锦上添花初学阶段可以先不做但你要知道有这回事。4. 状态封装与主循环骨架为后续扩展留好接口4.1 用结构体管理球的状态前面已经给出了Ball结构体的定义这里说说为什么这么设计。把x, y, vx, vy, radius, color打包在一起好处是更新函数只需要接收一个Ball渲染函数也只需要一个Ball将来加第二个球、第三个球直接开数组或者vectorBall循环处理即可。如果你把位置速度散落成一堆全局变量加第二个球的时候就得复制粘贴一堆代码改一个参数要改好几处维护成本爆炸。void updateBall(Ball b, float dt, int width, int height) { b.x b.vx * dt; b.y b.vy * dt; if (b.x - b.radius 0) { b.x b.radius; b.vx -b.vx; } if (b.x b.radius width) { b.x width - b.radius; b.vx -b.vx; } if (b.y - b.radius 0) { b.y b.radius; b.vy -b.vy; } if (b.y b.radius height) { b.y height - b.radius; b.vy -b.vy; } }这个函数就是整个动画的心脏。它不关心窗口怎么开、颜色怎么设只负责“根据当前状态和流逝时间算出新状态”。这种“状态更新与渲染分离”的设计是后面所有游戏逻辑的基础。你以后加重力就在这里面给vy加一个增量加摩擦力就给vx, vy乘一个衰减系数。改动都集中在一处非常清爽。4.2 主循环的三段式骨架initgraph(800, 600); Ball ball { 400, 300, 300, 200, 20, RED }; auto last Clock::now(); bool running true; while (running) { // 1. 处理输入 if (_kbhit()) { if (_getch() 27) running false; // ESC 退出 } // 2. 更新状态 auto now Clock::now(); float dt std::chrono::durationfloat(now - last).count(); last now; if (dt 0.05f) dt 0.05f; updateBall(ball, dt, 800, 600); // 3. 渲染 cleardevice(); setfillcolor(ball.color); solidcircle((int)ball.x, (int)ball.y, (int)ball.radius); FlushBatchDraw(); // 如果开了批量绘图 Sleep(1); // 让出 CPU避免空转占满一个核 } closegraph();这个骨架里有两个细节值得说。第一Sleep(1)不是必须的但强烈建议加。不加的话循环会疯狂空转CPU 占用飙到 100%笔记本风扇狂转而且dt会小到接近 0反而让计时精度变差。加 1 毫秒让出 CPU循环频率自然降到千赫兹级别既流畅又不浪费。第二solidcircle的坐标参数是int所以渲染时把float强转成int。这里用强转而不是round是因为强转是截断对高速运动影响不大如果你追求更平滑可以用(int)round(ball.x)代价是多一次函数调用。4.3 窗口尺寸变化时的处理EasyX 的窗口默认不能拉伸但如果你用了可调整大小的窗口或者以后想支持全屏就得处理尺寸变化。核心思路是把窗口宽高存成变量每次更新前重新获取边界检测用最新的宽高。这样窗口一变球的反弹边界立刻跟着变不会出现球跑到窗口外面去的情况。int width getwidth(); int height getheight(); updateBall(ball, dt, width, height);getwidth和getheight是 EasyX 提供的接口返回当前绘图窗口的尺寸。每帧调一次开销很小换来的是对窗口变化的即时响应。这个习惯建议从现在就养成别把 800 和 600 硬编码在边界检测里。5. 常见问题排查与调参经验5.1 球卡在墙角抖动怎么办这是最典型的问题现象是球撞到角落时在两个方向反复反转卡住不动或者疯狂抖动。原因通常是两个方向的检测在同一帧都触发了而且位置修正没做或者做错了。排查步骤先确认四个边界判断是不是独立的if而不是else if角落需要两个方向都处理再确认每个分支里都做了位置修正。如果还抖检查是不是速度太大导致一帧内多次越界用 2.4 节的拆步方案解决。5.2 球运动一顿一顿的先看dt是不是波动太大。可以在循环里临时打印dt正常应该在 0.001 到 0.02 之间小幅波动。如果经常跳到 0.05 以上说明你的循环里有阻塞操作比如Sleep时间太长、或者渲染太慢。另一个常见原因是用了int存坐标导致低速运动时位置取整后跳变。改成float存坐标、渲染时取整立刻顺滑。5.3 反弹角度看起来不对如果你发现球撞墙后角度变得很怪检查是不是把vx和vy搞混了或者撞左墙却反转了vy。还有一种情况是速度分量大小差太多比如vx 500, vy 10球几乎是水平飞撞上下墙后vy反转但依然很小看起来就像“贴着墙滑”。这不是 bug是参数设置问题调一下vx, vy的比例就行。5.4 长时间运行后球的位置飘了浮点数累加会有精度误差跑几个小时可能偏几个像素。对小球动画来说这无所谓但如果你做的是需要精确复现的场景就得定期把位置钳制在合法范围内或者用定点数。日常小游戏不用管这个知道有这回事即可。问题现象最可能原因排查动作球卡墙角抖动位置修正缺失或用了 else if检查四个 if 是否独立、是否都修正位置运动一顿一顿dt 波动大或坐标用了 int打印 dt、坐标改 float高速穿墙单帧位移超过半径加拆步逻辑或限制最大速度反弹角度怪vx/vy 搞混或反转错分量对照撞墙方向检查反转的是哪个分量窗口变化后球跑出去边界硬编码改用 getwidth/getheight5.5 几个调参的小心得速度参数我一般从vx 300, vy 200起步这个组合在 800x600 窗口里大约 3 秒横穿一次观感比较舒服。半径 20 左右太小了看不清太大了撞墙频繁。颜色用纯色就行别一上来就搞渐变渲染开销和代码复杂度都不划算。如果你想让球看起来更有“弹性”可以在撞墙瞬间给球做一个短暂的缩放动画这个属于进阶效果等基础跑稳了再玩。提示调试运动逻辑时把速度调慢比如 vx50, vy30肉眼能看清每一帧球的位置变化比盯着快速运动的球找 bug 高效得多。6. 从单球到多球这套骨架的扩展性验证6.1 加第二个球只需要改三行前面强调结构体封装的好处这里验证一下。加第二个球你只需要定义第二个Ball变量、在主循环里对它调一次updateBall、渲染时多画一个圆。核心逻辑一行不用改。这就是“状态与逻辑分离”的威力。如果你一开始用全局变量写现在就得复制一整套x2, y2, vx2, vy2还要复制边界检测代码改一个 bug 要改两处迟早出错。Ball ball2 { 200, 200, -250, 180, 15, BLUE }; // 循环里 updateBall(ball, dt, width, height); updateBall(ball2, dt, width, height); // 渲染 solidcircle((int)ball.x, (int)ball.y, (int)ball.radius); solidcircle((int)ball2.x, (int)ball2.y, (int)ball2.radius);更进一步用std::vectorBall存任意多个球循环遍历更新和渲染代码量几乎不随球数增长。这个模式你以后做粒子效果、做敌人群都是同一套。6.2 球与球碰撞的预告多球之后自然会想“让它们互相撞”。球球碰撞比撞墙复杂核心是判断两球圆心距离是否小于半径之和碰撞后要沿连心线方向交换速度分量。这部分内容量不小我打算放在下一篇单独讲。这里先给你一个判断条件你可以自己先试试float dx b2.x - b1.x; float dy b2.y - b1.y; float dist sqrt(dx*dx dy*dy); if (dist b1.radius b2.radius) { // 发生碰撞处理反弹 }注意sqrt有开销实际项目里常比较距离平方来避免开方即dx*dx dy*dy (r1r2)*(r1r2)。这个优化在小规模场景无所谓但养成习惯没坏处。6.3 性能上的现实考量有人担心每帧cleardevice加重绘会不会卡。实测在 800x600 窗口、几十个球的情况下EasyX 完全扛得住帧率轻松上百。真正的瓶颈往往在FlushBatchDraw的调用时机和Sleep的设置上。如果你发现球多了以后变卡先检查是不是每画一个球就FlushBatchDraw一次正确做法是所有绘制完成后统一 flush 一次。批量绘图的开关用BeginBatchDraw和EndBatchDraw包住整个渲染段能显著减少闪烁和开销。我在实际项目里踩过的一个坑是开了批量绘图却忘了在循环里调FlushBatchDraw结果画面一直不更新还以为是运动逻辑写错了查了半天。这个教训分享给你遇到“逻辑对但画面不动”先查批量绘图的 flush。7. 写在代码之外的一点体会这套小球动画的代码前后加起来不到两百行但它把游戏开发里最核心的几个概念——时间步进、状态管理、边界处理、渲染循环——全都串了一遍。我带过不少初学者发现一个规律那些愿意在这里停下来把dt钳制、把位置修正、把结构体封装这些“看不见效果”的细节做扎实的人后面学什么都快而那些急着加功能、跳过基础的人做到第三个项目就会全面崩盘回头补课的成本高得多。所以我的建议很直接别急着让球变出花样先让它稳稳地跑上十分钟不出任何异常。你能做到这一点说明你对这套骨架的理解到位了后面加重力、加碰撞、加关卡都是在这个稳固地基上添砖加瓦。速度参数你可以随便调调坏了大不了重来但时间步进和状态封装这两块的设计一开始就要按对的来别图省事用全局变量加固定增量那是给自己挖坑。最后分享一个我常用的自检方法把窗口最小化放那儿跑半小时再恢复看球是不是还在正常运动、位置有没有异常。这个测试能一次性暴露计时、钳制、状态更新里的绝大多数隐藏问题。跑得过这一关你的小球动画才算真正“稳”了。