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?
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.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.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 }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.
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.
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.
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.
Fair enough, I can get behind that.
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).