Design How many of you use delta timing in your games?

[Amon]

How many of you, those who release games to stores, implement delta timing in your games? I ask because it seems every tutorial I have come across doesn't use or mention delta timing to keep speeds smooth on lower end hardware. It's important for me to know whether it is actually worth implementing delta timing including using alarms based on delta timing.

 

[RujiK]

In my personal opinion delta timing is not worth the effort for 99% of pixel art games. If you look at steam stats, over 95% of users have DX10 or higher and over 98% have 4 gb of ram or more. I'm extrapolating here, but that probably means maybe 5% of steam users MIGHT have trouble with your game.

If you really want to worry about the 5% of customers with bad PC's though, it would probably be easier to just allow a few fixed options for the framerate. So like FPS choice would be: 60, 30, or 20. If you choose a lower framerate, your code still runs at 60 fps, but you only draw the screen every 2 or 3 frames. That requires almost no extra work and isn't a big hassle like delta timing is.

 

[BattleRifle BR55]

I'm making an FPS, so locking the frame rate at 60, and hoping intense, frame-dropping events won't occur aren't exactly ideal. Once I switched the engine over to delta-timing, the game started feeling a whole lot better, to the point that I'll never make another game without it, even in 2D.

 

[nacho_chicken]

How many of you, those who release games to stores, implement delta timing in your games? I ask because it seems every tutorial I have come across doesn't use or mention delta timing to keep speeds smooth on lower end hardware. It's important for me to know whether it is actually worth implementing delta timing including using alarms based on delta timing.

If you're just going to do it to support lower-end hardware, don't do it. @RujiK mentioned some excellent alternatives that are braindead easy to implement and reach an equivalent outcome. That said...

The real benefit to delta timing is decoupling logic from frame rate. This allows users with higher-end rigs to run your game at higher framerates, while also equally supporting users with average or low-end hardware. Even pixel art looks fantastic and buttery-smooth at 144Hz. This is about to become a larger deal than it has been previously, as high-framerate gaming is hitting the mainstream as we speak. Basically every 4k television above budget range supports 120Hz and consoles are just now starting to output 120Hz. If your project isn't heavily physics-based, it also isn't at all difficult to implement. My turn-based RPG uses delta timing, and I really don't have to do much besides factor in my delta global variable into all movement. Since I'm not doing anything with acceleration, this consists solely of doing

counter += DELTA;
// Or
x += speed * DELTA;

instead of

++counter;
// Or
x += speed;

This isn't really an option that's going to win over any new players (at the moment), but it's one that players with higher-end rigs will appreciate. Necessary? No. Make of this what you will. Whether or not it's worth it depends on the person doing the work and the project itself.

 

[Padouk]

My mantra... do less => do more.

it is actually worth implementing delta timing including using alarms based on delta timing.

No it's not... play with the room_speed and fps instead

using alarms like you say is pretty much recreating the room_speed configuration.

For Gameplay purposes, it's best to stick with Discrete timelines and GMS already converts the continous time into discrete steps.
If you start messing arround with delta timing, it grows like a cancer.. You need it in your collision detection, audio, etc..

Converting the continuous timeline into discrete step is one of the solutions to prevent that cancer from growing and it's already all managed by GMS.
Find the slowest device you want to support and fix your room speed and fps accordingly.

use or mention delta timing to keep speeds smooth on lower end hardware.

in 2020... fat chances are your game logic can run in less than 20-40ms.. your real issue on slower devices will be on the Displaying side.

For display purposes, Keep your room_speed and fps at 60 and turn on some frame skipping for slower devices.

Spoiler: frame skipping

// Step disable drawing every 2 frames => 60room speed, 30draw speed
draw_enable_drawevent  (frameskip++ mod 2);

// Step disable drawing every 3 frames  => 60room speed, 20draw speed
draw_enable_drawevent  (frameskip++ mod 3);

// Step disable drawing every 6 frames  => 60room speed, 10draw speed, might still be ok for some RPG...
draw_enable_drawevent  (frameskip++ mod 6);

The real benefit to delta timing is decoupling logic from frame rate.

Spoiler: I second that...

I'm in full agreement here andI second that comment..

We use delta_time variable extensivly in network games to make sure the distributed loop runs at fixed rate.
In reality what we do is convert the continuous time back into discrete step just like GMS does... Those network steps are stimply not aligned with the room steps.

updated 2021-01-11: fixed the function call should have read draw_enable_drawevent not application_surface_draw_enable

 

[Amon]

So far we have varying replies, but I think my mind is made up that I will leave delta timing alone for now. I have to admit that implementing delta time does cause me some headaches within my game but that's more than likely due to my lack of knowledge in how to implement it properly.

Thanks though guys for the replies.

 

[Khao]

I fell in love with delta in my current project. I added a ton of refresh rate options (30, 60, 75, 90, 120, 144, 240 and unlocked) and the game feels really good in all of them. The option is great both for people with hardware that is too weak and people with hardware that is too strong. ty old-as- laptop? The game is fully playable at 30 and works smoothly. High-end gaming PC? Despite it being a relatively simple 2D title, it be amazing on a 144hz monitor. If you're serious about gamedev, it's a good idea to invest on it especially considering the newest consoles, which can support 120hz TVs.

And if you ask me, from my experience, it's really not hard to work with. It's not even more work. You just get used to it and eventually you don't really think about it. It's really just a slightly different coding style. You just have to add a multiplier to anything that relies on time.

Also I mention this every time I talk about delta time, but just because it's so true and so useful. If you program your entire game with delta time, you now have a shockingly easy way to make slow-motion effects. My game even includes a "game speed" slider you can use to make matches faster or slower if you feel like it, and I got a few items and abilities that can mess with the speed of certain objects by just modifying their own delta multipliers. It's awesome, and way easier than you might think. Just keep it in mind from the start of your project and make sure you really understand where to add it and it'll never become an issue.

Delta Time's only real "weakness" is that your physics kinda end up being less and less precise the lowest your framerate goes. I get around that by clamping the delta time value, which means the game will start to slowdown if the game goes below a certain framerate. I have my limit set to 30, which means that the game will always be at full speed, unless there's a drop below 30, where delta won't go any higher. But that's fine because under 30, a fast-paced action game is gonna start feeling like anyway, and speed correction probably won't save gameplay at that point.

 

[nacho_chicken]

If you're serious about gamedev, it's a good idea to invest on it especially considering the newest consoles, which can support 120hz TVs.

I'm willing to bet that in about 5 years time, this will be a huge issue. Consoles finally have the power of a mid-range PC, and TVs are even better than PC monitors at equivalent price points. Console gamers will inevitably get in on the framerate whining and moaning PC gamers have been doing for ages, and it won't be pretty for devs of 2D games especially.

"What do you mean Hardcore Platformer 74 doesn't support 120 FPS? It's 2D, for crying out loud!"
"The physics are tied to the framerate."
"Wow, lazy dev much? This isn't 1990."

 

[HalRiyami]

...If you program your entire game with delta time, you now have a shockingly easy way to make slow-motion effects....

Just to add to this. If you implement delta timing in your game the way some other engines do, you not only have the ability to slow down time, you can actually pause the game by setting the delta time scale to 0. We're so used to disabling instances in GMS to pause that many don't consider this way of doing it. No need to disable instances and you don't need to create a pause surface. I believe this is the typical way to do it in Unity.

 

[Khao]

Just to add to this. If you implement delta timing in your game the way some other engines do, you not only have the ability to slow down time, you can actually pause the game by setting the delta time scale to 0. We're so used to disabling instances in GMS to pause that many don't consider this way of doing it. No need to disable instances and you don't need to create a pause surface. I believe this is the typical way to do it in Unity.

That's how I'm doing it too. Feels great to be able to do that. Also a great way to casually catch errors in my delta implementation. If something moves when I pause, its delta is wrong and it won't scale right to other framerates, so I need to fix it.

Not to mention it can potentially allow you to do cool stuff, like a Smash Bros. style pause camera with free panning and zooming for screenshots and stuff. Delta can really open a ton of options with super low effort.

 

[Yal]

I never use delta time, and it feels like GM specifically isn't exactly a good fit to delta time to begin with...

• Event occurrence is tied to the framerate, so logic will run more often than necessary (or less often, which can lead to unintended clips etc if you don't take special care)
• Sprite animation speed also is tied to the framerate by default (and always was in GMS1, which has ~25% market share according to my statistics)
• GM's collision functions have unspecificed behavior for non-integer coordinates, and it's much harder to ensure integer positions with delta time compared to just setting integer per-step speeds
• Alarms have no delta-time equivalent so you need to reinvent the wheel with custom counters
• Particles have no delta-time settings so you need to edit the particle types' settings every step (or only update the particle systems at a set framerate, which will probably be noticeable)

There's a whole lot of habit on top of that, but I don't see the point in having to do extra work unless there's a tangible benefit. I'm already hitting my limits in GM (I've got complaints that my 3D engine can't even hit 30 fps because of performance issues for some users) and I'd rather make a cooler frame-locked game that I can guarantee runs well than a bland smoother experience that only the most vocal 1% of users will enjoy. Sprite animation won't get smoother than the number of frames anyway, what's the point?

 

[Fern]

I think the replies here have done a great job listing off all the pros and cons of delta timing but I have one more I'd like to add.

Increased performance costs! If every frame-dependent calculation you previously did now involves multiplication to consider delta timing, then you have consistently more overhead.

Anyways delta time is cool but if you are serious about finishing a game you likely won't use delta time. I'd go out on a limb and guess that less than 1% of games released with Game Maker use delta time.

 

[DigitalBird]

My mantra... do less => do more.

No it's not... play with the room_speed and fps instead

using alarms like you say is pretty much recreating the room_speed configuration.

For Gameplay purposes, it's best to stick with Discrete timelines and GMS already converts the continous time into discrete steps.
If you start messing arround with delta timing, it grows like a cancer.. You need it in your collision detection, audio, etc..

Converting the continuous timeline into discrete step is one of the solutions to prevent that cancer from growing and it's already all managed by GMS.
Find the slowest device you want to support and fix your room speed and fps accordingly.



in 2020... fat chances are your game logic can run in less than 20-40ms.. your real issue on slower devices will be on the Displaying side.

For display purposes, Keep your room_speed and fps at 60 and turn on some frame skipping for slower devices.

Spoiler: frame skipping

// Step disable drawing every 2 frames => 60room speed, 30draw speed
application_surface_draw_enable(frameskip++ mod 2);

// Step disable drawing every 3 frames  => 60room speed, 20draw speed
application_surface_draw_enable(frameskip++ mod 3);

// Step disable drawing every 6 frames  => 60room speed, 10draw speed, might still be ok for some RPG...
application_surface_draw_enable(frameskip++ mod 6);

Spoiler: I second that...

I'm in full agreement here andI second that comment..

We use delta_time variable extensivly in network games to make sure the distributed loop runs at fixed rate.
In reality what we do is convert the continuous time back into discrete step just like GMS does... Those network steps are stimply not aligned with the room steps.

This was a big help to me mate, thankyou very much. Never thought of just skipping the draw to target certain fps. I might use this with a -fps_real check to dynamically alter the fps on lower end systems. For me I think this will be a fine trade off to using delta time.

 

[nacho_chicken]

This was a big help to me mate, thankyou very much. Never thought of just skipping the draw to target certain fps. I might use this with a -fps_real check to dynamically alter the fps on lower end systems. For me I think this will be a fine trade off to using delta time.

I would highly advise against doing this as written. It is nowhere near as simple as the method suggested above. First off, that piece of code is written incorrectly and will not work as intended (disables every x frames instead of enabling every x frames). Second, doing it correctly (application_surface_draw_enable(!(frameskip++ mod 2)) produces a horrible potentially literal seizure-inducing flickering effect—especially on a high-refresh rate monitor. Third and most importantly, disabling the app surface does absolutely nothing for game performance. It's still being drawn-to behind the scenes. You would need to disable the draw event instead and have to draw a surface to a different layer.

 

[DigitalBird]

I would highly advise against doing this as written. It is nowhere near as simple as the method suggested above. First off, that piece of code is written incorrectly and will not work as intended (disables every x frames instead of enabling every x frames). Second, doing it correctly (application_surface_draw_enable(!(frameskip++ mod 2)) produces a horrible potentially literal seizure-inducing flickering effect—especially on a high-refresh rate monitor. Third and most importantly, disabling the app surface does absolutely nothing for game performance. It's still being drawn-to behind the scenes. You would need to disable the draw event instead and have to draw a surface to a different layer.

Cheers Nacho, I was referring more to the general idea of it all.

So even doing it correctly will cause the flickering on high refresh rate monitors? I implemented something similar to this: draw_enable_drawevent (yoyogames.com)

I set it to draw only every second frame , to achieve 30 draws a second on a 60 fps game. Looks good on my 60 fps monitor.

Am I likely to have a nasty surprise if tested on a high refresh rate monitor?

Cheers for the advice. I a can't seem to find many resources on accomplishing this style of fps skipping

 

[Elodman]

Interesting topic!
A pity that frame skipping is not that easy, then.

Would capping FPS and/or draw events to a certain limit be quite difficult then (to avoid unnecessary CPU / GPU stress and spikes in performance)?

Edit:
as real Fps shows some hundred.
Or perhaps it is not a problem in reality. I don't know.

 

[nacho_chicken]

Cheers Nacho, I was referring more to the general idea of it all.

So even doing it correctly will cause the flickering on high refresh rate monitors? I implemented something similar to this: draw_enable_drawevent (yoyogames.com)

I set it to draw only every second frame , to achieve 30 draws a second on a 60 fps game. Looks good on my 60 fps monitor.

Am I likely to have a nasty surprise if tested on a high refresh rate monitor?

Cheers for the advice. I a can't seem to find many resources on accomplishing this style of fps skipping

No, using draw_event_enable should work fine. I was warning anyone using that example code as written, because just disabling the application surface does cause painful flashing.

 

[Padouk]

I would highly advise against doing this as written. (application_surface_draw_enable(!(frameskip++ mod 2)) disabling the app surface does absolutely nothing for game performance. It's still being drawn-to behind the scenes. You would need to disable the draw event instead and have to draw a surface to a different layer.

Agread. The intended function call was draw_enable_drawevent

So even doing it correctly will cause the flickering on high refresh rate monitors?

Depends on your Scene visual deltas. If you are creating a First Person Shooter where every single pixel on your screen change on every frame, don't go with frame skipping.
If you are creating a Top Down or Platformer 2D cartoonish game, you can.

First Person Shooter : It's pretty much the same as Looking Sports games on a 120hz vs 60hz tv.... the 60hz TV will give you a head headache. (Then again.. I question GMS beeing a good solution for first person shooters in it's current state)

Top Down / Platformer: 60hz is the SOTA refresh rate for those: It's pretty much the same as Looking any cartoon on a 120hz vs 60hz tv... you won't see the difference. (Then again. GMS' 2d offering is still more in line with this one)

I set it to draw only every second frame , to achieve 30 draws a second on a 60 fps game. Looks good on my 60 fps monitor.

In 2017, on Desktop, you will mostlikely be able to support 60hz. 45hz on Android and 30hz on Browsers.
I personnaly don't recommend "dynamic" frameskipping... It breaks the purpose of it. You can try it in TMC's asset on the market you will see.

Also... 60fps is a bit slow in 2017 for desktop The whole idea is to have your physics update at 120fps and your rendering set at 60hz.
Decoupling the Rendering and Update.

Cheers for the advice. I a can't seem to find many resources on accomplishing this style of fps skipping

You can compare the amount of work required for those two solutions (delta time vs frame skipping) with some of the assets on store

TMC Frame Skip by The Mojo Collective | GameMaker: Marketplace

marketplace.yoyogames.com

TMC Delta T Engine by The Mojo Collective | GameMaker: Marketplace

marketplace.yoyogames.com

 

[Padouk]

To come back to the original question.

How many of you, those who release games to stores, implement delta timing in your games?

Using GMS.. I don't.
Using Unity. I do.

When removing the fixed frames. You have to re think the way you use the engine, you can no longer rely on image_speed, speed, timeline_speed, alarm[], gravitry and overall general physics.
you need to update your own x and y update with your own speed factor, recreating a physics abstraction layer.

You can no longer ask "am I colliding with object x". There's no testable determinism so you might end up going through the objects at some point. place_meeting is not relevant anymore, You need raycasting for that, most of the collision offering from gms become useless as you start recreating a new collision abstract layer.

You can no longer assume moments. If your delta is too long you may end up skipping over a few events, you need to detect when to trigger based on time. So you can't rely on the GMS's moment and alarms system anymore and have to recreate a new trigger abstraction layer.

And a few sparse cool bug/feature. While playing your delta timing game in window mode (not fullscreen) Start dragging your window around, which pause the processing, you will see interesting delta spikes and you will see your walking toon teleporting through walls. Unless you cap your delta and workaround that pausing effectivly recreating a fixed frame rate and pausing mechanism.

While developing, your delta timing will mostlikely be bellow the 4ms critical mark... After all those efforts you will realized you actually created/tested a game which offer crappy experience on a 7th gen i3 core typical 3 years old laptop



Now you go into the original question...
Is it a monetary viable solution to recreate the nuts and bolts before assembly? It's highly arguable and has nothing to do with any technical points, you need to put the $ in there to do the math.

Do you want to align with GMS's core abstraction with embedded decisions toward fixed frames. Or do you want to extend that offering to offer something unique.


--

2D Casual games will usually go just fine with 60hz, that's what your target audience's none-gaming computer and laptop support anyway.
You want to hit the TV market with uwp? fixed 120hz will be just fine..
You want to hit the android target? fixed 45hz will be just fine..
You want to hit HTML5 target? 30hz ... now this one is tricky... i'll save it for anothe debate.
You want to monetarize true-3d at 144hz? I question GMS to be the right solution.
You want to learn/try/poc about true-3d at 144hz on GMS? Yeah .. why not.


--
Now let's come back to that Desktop conversation... let's forget about about html5 or mobile for a second.
60hz is just "fine"
But 60fps is too slow... I favor 120fps for modern desktops.
Just like I used to favor 60fps / 30hz decades ago.

Decoupling rendering and update is not a new concept and it's inheriently part of GMS's offering so you don't have to fight against it.
You don't even need 2 clocks, you just need to alternativly turn off the expensive draw event (everything from pre-draw to post-draw)


--

Why on earth would I say 120fps that's such a weird number?
It has nothing to do with rendering to be honest, it's just 60*2 for conveniance (and the UWP target forxbox one)
It's all about input lag.... the ideal fps would be 240+fps... but that's waaaayyyy out of my reach.
120fps? yeah that's a good compromise I can easily reach on a 7th gen i3 typical laptop.


if you run your game update at 30fps. It means your input are processed every 1000/30 = 33ms...
Mouse and Touch? You won't see the difference...
Keyboard and Gamepad? You can feel it! it's annoying. If feels like the game is not reacting to your inputs.

if you run your game update at 60fps. It means your input are processed every 1000/60 = 16ms...
It used to be ok... more and more casual player have now experiences the faster update rate.. it becomes a little bit more of an issue.
When you hear people saying 144hz is more responsive than 60hz... that's actually what they have in mind.. nothing to do with visual really.

Players often prefer to keep the fps high for their games and if their hardware can't support it, they will often prefer to cut on the visual features, removing shadow, removing lights, reducing resolution, before they cut on fps.
For games where fps=hz that basically means a crappy visual / crappy responsivity tradeoff.

if you run your game update at 120fs. It means your input are processed every 1000/120 = 8.3ms...
You are now pretty well aligned with typical wireless devices. and USB2 interfaces.
The game feel smoother even on an 60hz monitor.

240fps.. you get the gist.. 4ms input lag becomes virtually unnoticable.

--
Now that's where frame skipping comes into play.

at 120hz you are losing so much processing power on preparing renders that won't be displayed on that icore3 laptop...
Might as well just decouple render and update to support 120fps with 60hz. skipping draw events (draw_enable_drawevent ) every alternating frames.

--

I do have to agree tough.... All my assumptions are based on the fact you are deploying 2D games when using GMS and you scene does not change on every single pixel at every frame.

 

[kburkhart84]

Using Unity. I do.

Maybe I'm missing something, but last I heard(and last time I used Unity), it didn't have a frame capping option(except for the physics cycle/processing), at least out of the box. So unless you do something strange, you either HAVE to use delta timing for your movement, or you can only do something with movement in the physics side. This may work for gameplay, but I wouldn't want GUI stuff to use physics unless it made sense. And many games don't really work as well(or as easily) if you force them to use the physics system for movement either.

 

[nacho_chicken]

You want to hit the android target? fixed 45hz will be just fine..

Why would you ever go for 45Hz? It'll just end up creating a stuttery image on every single device since no mainstream Android device in existence runs a 45Hz display. Just go 30 on mobile if you're concerned about lag, or 60 if your game is lightweight enough.

Might as well just decouple render and update to support 120fps with 60hz. skipping draw events (draw_enable_drawevent ) every alternating frames.

AFAIK GM can't actually decouple render and update, since the rendering tick rate is hard-tied to the update tick rate at the engine level. The best you can do is what you suggest, disabling the draw event every n frames. However, running logic at 120Hz comes with a major caveat: depending on the game, it can be extremely detrimental to performance on weaker hardware. You really shouldn't make the assumption that games are always draw-heavy. Many genres tax the CPU a lot harder in the step than they do drawing. As an example, strategy games and roguelikes have dozens to thousands of units all pathfinding simultaneously. If your game starts lagging on a weaker PC because it's running all that logic at 120Hz, dropping every other render frame isn't going to do much for performance. Now you're hosed, since you programmed ALL timed logic at 120Hz.

It's the kind of thing you need to consider on a per-project basis; it is far from a one-size-fits-all lifehack to improve input lag.

 

[Yal]

I guess it could be possible to spread out heavier logic if you run your own "step_movement", "step_AI" and "collide" scripts instead of using GM's built-in events - ordered via a with loop from a controller at regular intervals, and only run them every X frames (where X could be different for different object categories). As of GMS2, empty events aren't processed in any way, so this should free up a lot of performance.

But again, just as with delta timing removing a lot of the built-in convenience stuff, you'd basically invent the wheel again for very slim benefits.

 

[Scarm]

Sorry for potential necro but, as the others said, don't implement delta-time into your project.
Unless your willing to tacobell your game with a probably confusing abstraction layer, not worth it.
Speaking from personal experience with painstakingly trying to implement delta-time, it pretty much breaks when your far from the target framerate. I'd suggest to stick with 60 or similar because delta-time is just a big no-no for gms.

 

[Yal]

If you wanna see just how breakable a game is with delta-time implemented poorly, this speedrun has some great examples:

(It also relies on other tricks like wonky hitboxes and angles >360 not being adjusted with more than 360 degrees per frame, so if you want to make a game robust, you should probably also think about that kind of stuff)

 

[Fern]

I earlier in this same thread said that delta-time is bad to use but I actually just released a tool that uses delta-time. What I've learned is that it's great if you plan on having async functionality or want to support varying framerates, but it certainly is not easy to work with.

 

[Old2DGuy]

I'm hopefully going to start using GM for several projects soon. I'm coming from Flash/Air/AS3 and I've used delta time for all of my previous apps. But the discussion probably shouldn't be based around supporting low end hardware, it may need to be about how GameMaker works on newer devices that support refresh rates of 90, 120, or more. And as one thread is already discussing, games are slowing down on higher display refresh rates. I'm guessing games locked at 60 running on 90hz devices are missing a vsync sometimes causing the game to actually run slower.

I would think setting the GMS frame rate to a high number like 240 (with Vsync enabled) and then using delta time for everything would be the best scenario moving forward because you end up automatically supporting higher refresh rates resulting in smoother movement on more capable devices. (And yes, you cap the delta to make sure it's never large enough to break the physics when running on less capable devices.)

If you're planning on deploying your app on multiple targets (pc, phones, tablets, etc) I don't see how anyone would not want to use delta time regardless how hard it might be to initially setup and utilize. The long term advantages will out weigh any short term learning curve imop.