I've never Figured this out

Posted by LAR Games on Sept. 8, 2011, 3:58 a.m.

How would I go about making my game have a dynamic frame rate? What I mean by that is that when the fps go from about 60 to 40 or something, the speed and timing of the objects stays the same?

This has bugged me for the longest time, and I have experimented with it, but I can never get it to work.

How would you guys do it? Is it even possible in Game Maker?

Comments

Kenon 13 years, 2 months ago

It's called Delta Time.

What you do is for every increment you have it done by a set amount of whatever per second, and then you divide that by the current framerate. So if you want to have a character always move 128 units in a second, you have it as x+=128/fps or whatever the variable for that is.

Basically.

PY 13 years, 2 months ago

better solution: write things efficiently

If you're dead set on it, though, the basic concept is to simply multiply everything by framerate / target framerate. It's never seemed a good idea to me.

blackhole 13 years, 2 months ago

Writing things efficiently is NOT a better solution, because delta time allows your players to turn off vsync without the game exploding, and the inevitable hiccups in the framerate even with vsync on won't throw everything off. While writing things efficiently is desirable, delta time solves a whole host of problems that such a mentality ignores.

The proper implementation of delta time is to write your render loop or game loop such that there is a variable that is always set to the amount of time that passed between the start of the current frame and the start of the last frame. If you have a function that returns the current time in milliseconds or something, you can achieve it via the following:

int timelast=GetTime();
while(true)
{
  int curtime=GetTime();
  int delta = (curtime-timelast)/1000; //translates into seconds
  timelast=curtime;

   // do stuff
}

Then, you multiply all values that are dependent on time by the delta value, which transforms whatever rate you were using before into x things every second. So if your character was being moved up 10 pixels per frame before, you must readjust that to a rate on a per-second basis, which can be achieved by simply multiplying the value by 60, which gives you how far he moved per second (600 pixels per second).

PY 13 years, 2 months ago

Which isn't really a concern in game maker - I'll admit I haven't used it in a while, but last time I checked GM's vsync didn't actually work. Certainly turning it off doesn't disable the framerate cap. Certainly it's very useful in an environment where changing framerate isn't exceptional behaviour, though.

blackhole 13 years, 2 months ago

In general it is a good idea to learn how to properly do delta compensation, because in pretty much anything OTHER than gamemaker, its important. So I guess the question is, is LAR ever going to be using a tool that isn't complete shit? If no, then I guess it doesn't really matter.

PY 13 years, 2 months ago

True, but Doing It Right in GM just seems… fiddly, to me, for (in most cases) little advantage. All that extra complexity simply to account for either inefficiency or low powered machines? Personally I'm not sure it's worth it - but then, I don't use GM any more, so perhaps my mindset isn't right for it these days.

blackhole 13 years, 2 months ago

If you are doing it right, it shouldn't increase the complexity, simply add a multiplication to several values. Compared to the kind of complexity you can get in an RTS, doing delta compensation is trivial. Whether or not its worth it in GM is debatable, but if LAR intends to move to anything else ever then it would be good practice for him.

PY 13 years, 2 months ago

Fair enough, I can get behind that.

Zac1790 13 years, 2 months ago

The fps* variable in GM often reads inaccurately because whatever function that writes to it isn't running during a room load, sleeps, or keyboard_waits. You can see this if you're drawing the fps to the screen while letting Fraps or something get the fps too. I guess it wouldn't be all that noticeable, but just keep that in mind if you see weird movement at a room start or when using show_message (which I assume you wouldn't use anyway :P).

Rob 13 years, 2 months ago

Quote: Zac1790
The fps* variable in GM often reads inaccurately because whatever function that writes to it isn't running during a room load

This. I faintly remember this being an issue when I tried it once.