众所周知，gamemaker默认是延时保帧的工作模式，该引擎让你可以拥有保时丢帧的工作模式。（目前仍为beta版）
2楼地址，3楼为“延时保帧”和“保时丢帧”的解释，4楼为插件用法。

地址楼保留，一会儿放在此楼回复里，先更3、4楼。

何为“延时保帧”与“保时丢帧”？
---------------------------------------
通俗一点讲，从视觉效果上解释：
假设你的游戏里有一个方块，你想要它在1秒内横向运动500像素，你的房间速度是60，那么你可以这样在Step事件里写：
var spd_per_frame=500/(1*room_speed);//计算出1帧内运动的距离，即速度
x+=spd;//运动
因为我们知道正常情况下，room_speed即是游戏循环1秒内会执行的次数，即帧率。由于房间速度是60，所以正常情况下1秒会经过60帧，即1帧为1/60秒。方块会按照预期在1秒内经过60次运算走过500像素。
但是，什么是“正常情况”？所谓正常情况指的是你的游戏在一台配置足够的电脑上运行，游戏能够做到按房间速度1秒刷新60次。那假如在一台老爷机上或者你的游戏有超赞的特效导致“掉帧”呢？
假设此时实际fps只有30帧每秒，你的代码却仍然没有改变，此时你的方块会在1秒内经过30次运算，也就是只走过250像素。所以按照gamemaker默认的模式，游戏看起来变慢了。
故延时保帧就可以理解为，在实际帧率达不到设定的房间速度时，通过【延长】总执行完方块运动500像素的【时间】，来【保证】每一【帧】的方块的运动量都符合原定代码，掉帧时给人的视觉感受是【变慢】。
--------------------------------------
但有时我们并不希望这样的事发生——可能游戏速度变慢会导致玩家玩起来自带外挂，因为给他们的反应时间变长了，降低游戏性。
此时就有保时丢帧的出现。不同于前者，保时丢帧的模式保证游戏无论帧数多低都能在同样的现实时间内完成任务。采用这种模式的话，你要方块在1秒内运动完500像素，那么不管你fps实际上是60帧30帧2帧还是120帧，它都会在1秒内到达目的地，但代价是什么？
举个例子，假设正常60帧率的时候，每一帧的速度是spd，如果此时掉到30帧，为了仍然保证同样时间走完同样路程，是不是速度不得不变为(60/30)*spd，也就是2倍的原速度？所以相比于正常情况，掉帧时方块会“跳过”某些位置的绘制直接到预定的位置来保证按时完成任务。
故保时丢帧可以理解为，在实际帧率达不到设定的房间速度时，为了【保证】仍按照预定的【时间】执行完方块运动500像素，【丢弃】一些来不及渲染或运算的【帧】，掉帧时给人的视觉感受是【变卡】。

似乎
和我的讯飞娘一样
并无 用

楼主，可不可以游戏开始放个计时器设定每间隔出发一次时间，把所有逻辑时间放到这里解决，这不就避开了基于帧的矛盾了吗

大哥你说了这么多，其实就是利用插件把基于帧的全局事件处理为基于时间。

我又详细的了解了一下gm不是基于帧的，gm里帧生成是在每个step里，所以会 出现你说的第一种“延时保真”，而你给的第二种‘保时丢帧，的方法会造成，物体穿墙等bug

Unity里的Time.deltaTime

其实用draw_enable_drawevent也可以不过缺点是，绘制事件会发生“跳帧”，如果有人在绘制事件里构筑游戏逻辑，那么会导致游戏出现一些意想不到的情况
下面是官方的例子
frame_skip ++;
if (frame_skip mod 5) == 0
{
draw_enable_drawevent(true);
}
else
{
draw_enable_drawevent(false);
}