fixed rate/ deltatime
Monkey Forums/Monkey Programming/fixed rate/ deltatime
| ||
| lets say you have a spaceship travelling across the screen at 8 pixels per frame, now the game is quite complicated (and therefore slow) so it doesnt update at 30FPS like its supposed to. How do you make it still travel the same distance. delta time? How do you calculate it in monkey? |
| ||
| There's a code that calculate the delta time in the sample that come with monkey. You should take a look into that. |
| ||
| Since monkey version 34 or so OnUpdate will always be called at 30FPS and only OnRender will be called less often if game is complicated / system is slow so as long as you move your ship in OnUpdate you have nothing to worry about. |
| ||
| @Simon, Since monkey version 34 or so OnUpdate will always be called at 30FPS Is that independent of the update rate (SetUpdateRate())? I get different results if that's true. @Slenkar, You can give this code a look. http://www.monkeycoder.co.nz/Community/posts.php?topic=548 L8r, |
| ||
| The 30 FPS was in context of the original post. It is of course whatever you set it to with SetUpdateRate. |
| ||
| OK, missed that:) L8r, |
| ||
| As I read OnUpdate goes at 30FPS. Means it's not necessary to write code to calculate the fixed rate? |
| ||
| That is correct. |
| ||
| Since monkey version 34 or so OnUpdate will always be called at 30FPS and only OnRender will be called less often if game is complicated / system is slow so as long as you move your ship in OnUpdate you have nothing to worry about. I'm not a fan of delta-time (which, relax, I won't blither on about here) -- would the corollary to this be that moving stuff during OnRender will ensure that no frames are skipped (ie if it's too busy it slows down)? |
| ||
| Umm, in Monkey Update rate is constant and Render rate is performance dependent so yes if you move stuff in OnRender it will slow down when the going gets busy. |
| ||
| Okay, cool -- I'm really thinking about genres like shmups where slow-down is often the expected behaviour. I guess the way to cap everything to the update rate yet never frame-skip, rather than updating during OnRender, would be to update during OnUpdate but only if a render had occurred since the previous OnUpdate. |
| ||
| I'm failing to see why you would want your update rate slower than your render rate. In a perfect world, assuming we have a target render FPS of 60 FPS (for vsync), we would only be calling OnUpdate every other frame. Surely you would want your update rate to be as fast as possible, then only call OnRender when you need to match your target render FPS. Otherwise you're rendering one "state" twice. Of course this is platform dependent, since some devices may have little to no hope of ever running 60 FPS. |
| ||
| some devices may have little to no hope of ever running 60 FPS Damn you Kindle!! :D |
| ||
| Well I don't want to destroy the party here but what if an update takes longer than the value set with SetUpdateRate? ;) |
| ||
| Then your game will slow down. |
| ||
| Yes of course it will. ;) I mean it's a bit dangerous to rely on the fix update rate alone. |
| ||
| Then your game will slow down. And this is why you use delta timing. |
| ||
| Feel like I am watching/reading a ping pong match. |
| ||
| a ping pong match With and without delta timing?!!? ;) |
| ||
| LOL... not sure. ;^) I *am* watching this thread carefully though. May find I need at some point to use delta timing. |
| ||
| I am in the delta timing camp at the moment. I have had this discussion with others and most seem to not see the benefit this kind of algorithm. With all the various targets and for that matter browsers and OS's it's hard to write code that will run on all of them as designed. I do not see the down side to gaining control over timing and thus maintaining the 'look and feel' of an application over multiple targets. Some of the arguments against delta timing range from it's unnecessary to the algorithm it self will slow an application. Both retorts are untrue IMHO. Once you grasp that the end result of delta timing is a quality application experience, I think it's a 'no brain-er'. L8r, |
| ||
| I agree Richard. I always use delta timing combined with fixed update ratios which are sometimes necessary for physics stuff... |
| ||
| I do not see the down side to gaining control over timing and thus maintaining the 'look and feel' of an application over multiple targets. Some of the arguments against delta timing range from it's unnecessary to the algorithm it self will slow an application. Both retorts are untrue IMHO. Once you grasp that the end result of delta timing is a quality application experience, I think it's a 'no brain-er'. Thus baited I shall venture :D For me it's a matter of us making games, an area in which visually representing the internal state of the application is acutely important. A system that restricts the visual information being supplied to the player at the exact time they most likely require it (when things get busy) works directly against what we're trying to deliver.As usual this is being discussed as a technical matter for spods when it's really a gameplay matter for the end-user. There's no "quality application experience" in being killed by a bullet you never saw because the game never drew it. |
| ||
| There's no "quality application experience" in being killed by a bullet you never saw because the game never drew it. And this is where I disagree. You see, you discount follow through. Your eye naturally completes sequential animation if it is displayed smoothly. There is nothing more disagreeable then a 'hiccup' in timing where your following through and the application is not. Think of it as a freeze in the display and an abrupt start. Nasty. Instead delta timing puts the screen object in the right spot at the right time. I am not targeting huge losses in a set frame rate but acceptable loss. Even though you may not see the exact point of collision your going to see the following animated explosion or what-not and your eye will naturally except the outcome. Considering that were really talking about a loss of a 10%-15% (possibly more) of frames per-second the loss is negligible given the trade off in the steady rate of display. L8r, |
| ||
| You see, you discount follow through...I am not targeting huge losses in a set frame rate but acceptable loss. Even though you may not see the exact point of collision your going to see the following animated explosion or what-not and your eye will naturally except the outcome. I think that's a thoroughly reasonable line of thought but that the current delta-time model doesn't support it reliably enough, mostly because we can't really predict what a user's system is going to do. We don't get to dictate that only small hiccups occur. For local 2D games (which is what I'm really squawking about -- networked and 3D games make intrinsic cases for delta-time) I guess what I'd like to be able to do, ideally, is declare the absolute minimum acceptable rate, below which the game will slow rather than skip frames. (And this is a play-testing issue -- I should know that at 15fps my game remains playable but at 10fps it's just too tricky.) So yeah, using delta-time to offer higher-spec'd systems *more* graphical fidelity than the minimum would be great. But that's not what happens when delta-time gets adopted, what happens is it grants carte blanche to chuck a bazillion things at a platform without caring whether the older models will cope because, superficially, detla-time makes it look like they do. I worry that it makes us sloppy, basically. |
   |