タイマーベース動作について新しい考察

I don’t understand the Timer-based movement in frame property what is neither reason exists?

Moreover, should I disable this option?

Timer-based movements synchronize movements with real time, even if the program in unable to actually draw at that speed.

Here is a manual example of the concept.

A true alternative to “machine independent” option. The machine independent option works fine, but it does not have great latitude of working. It recovers application on machines slower by 25 -30% but above that, it begines to work badly.

Timer Based Movement calculates the number of pixels to move based on the time elapsed since the previous loop. So if your application runs slowly, or fast, the speed of the objects on the screen will be exactly the same. The tolerance is really high. Some games are playable from 10fps to 100fps.

The animations are also calulated based on the timer, so the animations will match the movements in timer based mode.

A check box in the frame properties allows you to turn on and off the feature. If “off”, the application will behave just as up to now. If “on”, the movements will be timer based. To preserve the compatibility with games made before this system was in place, the default setting for such games is off. You can very simply turn it on, by ticking the box. When you turn that on you must enter the next property (movement timer base) the running speed of your application. If it runs at 60hz, then enter 60. If you set this property correctly, there will be no difference in your game or application before and after turning this feature on.

If you create a new application, the property is set “On” by default. The movement timer base is also very powerful. It allows you to modify the speed of all objects of the frame at once. For example, if you created your application with a movement timer base of 50 and you turn it to 100, all your objects will move twice as fast.

The timer based movement will also be an invalueable feature for HWA games, as the speed of the application depends very much on the graphic card. On some machines, your application will run at 60fps (frames per second), and on others at 100fps. With the timer based movement, the application will have the same game play.

If you plan your application to run at various speeds, you must aviod using counters as timers, as the counters increment or decrement depends on the speed of the main loop, where as the movements depend on the the timer. If there is too much of a difference between them, the events in the game will become out of synce. You should use the timer instead.

Some third party extensions my not be able to take advantage of this feature.

Marv

Movement: left and right arrow keys.
Jump: Spacebar.

The idea of the example is to show how to make a game run at a steady speed independent of the frame rate.

That’s all 😛

P.S. for a realistic example of how this might be used; change the games frame-rate in the application properties to something low (like ~10) to emulate a computer too slow to correctly play the game.

You’ll see that the game will display slower, but that it still runs as if it were displayed at the desired frame rate.

I’m still a little bit confused about how VSync works in a MMF2 application. I know how it works in other games, but I am wondering if MMF2 is different, since FrameRate is directly coupled to the GameLoop speed.

I know that if I turn on VSync with my game’s framerate set to 60FPS, then I don’t experience any screen-tearing (my monitor is 60hz), however if I turn off VSync, then I do notice some ‘choppiness’.

What I am wondering is, if I put my game on someone’s computer who has a 50Hz monitor, does this mean that their game will run at 50 “MMF Game Loops” per second, i.e. ~20% slower than designed? Or does this mean that their game will still run at 60 “MMF Game Loops” per second, but it will just display it at 50hz (as how VSync works in most games).

I asked a similar question earlier, but I still couldn’t work out the right answer.

MMF2 does indeed sit somewhere awkward in terms of chronology.

Until recently, multimedia fusion would by default behave as if one unit of time has passed each time the display loop is called, which as you hinted at above; would lead to computer specific game-speed. ( eg. slower display = slower game )

This method ( still supported by disabling timer-based movements in the frame properties ) has several advantages over commercially ubiquitous ‘real-time-engines’ in that( during lag spikes for example ) display choppiness is eliminated by allowing only a fixed amount of game-time between each successive display update…

However, if the desired frame-rate is continuously unachievable on the target system then the result is a game in slow-motion.

Recently however; a measure called ‘Time based movement’ has been implemented; which allows position and velocity to be calculated in ‘real-time’..
Since movement is a key aspect in game-play; certain games may need nothing more then this option enabled to appear to operate at speeds independent of implementation.

However this is a stop-gap measure; it imposes a serious miss-match between the default movements and user generated events; this miss-match CAN cause application behavior which is difficult if not impossible to predict.

The two core issues with ‘Time based movement’ are as follows; controls are sampled only during the display update. quite troublesome, since those controls are acted upon an arbitrary amount of times or a single time with an arbitrary magnitude parameter limited only by the current lag intensity

The second issue is very general and stems not directly from the ‘Time based movement’ implementation, but rather from user-level understanding of implementation.

As the user sees it; events such as ‘always’ (who’s behavior is more indicative of an event who’s title might be ‘On display update’ ) are expected to occur, perhaps not ALWAYS; but at-least as often as any-other event, this is TRUE for all events and extensions (ignoring ftm immediate events) but is not the case with ‘Time based movement’ enabled ( in which case all events are given the chance of executing only ( desired frame-rate / actual-frame-rate ) number of time-steps )

Essentially I’m saying,

Timer Based movements are not the silver-bullet answer, in fact they don’t help at all unless all the motion in you application is handled exclusively by default movements and there is nothing in the events which are dependent on time synchronization; not reasonable an ask.

However,

Timer based movement does have the essential key to frame-rate independent game-play, even If, only within it’s name..

The key, Ofcoarse, is ‘Timer’.

Making use of fast-loops this example uses the internal timer function to execute time-dependent game-play at any desired speed, with no respect to the number of display redraws.

Framerate Independent platform example

There is also a Real-Time component in this recent

3D engine example

I hope that gives you some ideas; and please ask if i left anything too vague.

Thank you for the very detailed and thorough response SEELE. I really appreciate it!

The game I am currently developing uses only custom movement (i.e. X=X+1), so it is tied to MMF’s Framerate property. For this reason, I cannot use time-based movement to “workaround” the problem, and as you have already mentioned, if I could use it I think it would lead to problems since it is a “stop-gap” measure.

Your Framerate Independent platform example is a very good proof of concept, however for my game, I don’t think that it’s very practical. With many objects on screen it would probably have a performance impact (especially if Pixelthief’s grouped fast loops observation has an impact – though I haven’t experienced this in my own tests). It is also quite complicated to implement since I would have to do it for many different objects, and I could see how I could easily become confused in debugging.

The concept of using the “timer” variable is still a very good idea and perhaps it can be utilized since it’s independent of “Draw updates” – right?

In the end I guess it comes down to the amount of effort to implement independent logic/draw rate, the performance and the gains from having this new feature.

Really… what I am looking for is something that will make my game run with a MMF Framerate property of 60 (i.e. “Game Logic Update Rate”), and display smoothly on a wide range of systems.

I want my game to run at 60 FPS on a monitor with 60hz, but still run at 60 FPS (“logic updates”) on a monitor with 120hz or 50hz. I don’t want my characters to run twice as fast on the 120hz machine. I want people to play the game on one machine, and then another, and for them to feel the same.

The simplest way to achieve this is to just set the MMF2 Framerate to 60, not use VSync, and turn on Machine-independent-speed (so slow computers don’t run “slow”), but this can lead to screen tearing since there’s no vsync.

Do you have any ideas on how “timer” can be utilized with a small amount of effort? I am thinking along the lines of:

1. dt = (timer - time_since_last_update)
2. x_position = x_position + (movespeed * dt) [using temp floats]
3. time_since_last_update = timer

I think that would work in MMF2. It’s what many independent logic/draw engines use.

You have already answered your own question netninja. The code example you posted is exactly what I’m using in all my recent games. Framerate property is set to 60, machine-independent speed is set to off (cause no one has a slow comp anymore).

The example is based on Dine’s excellent bullet-time article.