Archive: getframerate()


14th March 2004 11:10 UTC

getframerate()
I really would find a function that gets the current framerate very useful. The purpose of course would be to make the presets "run" faster/slower depending on the framerate. Sure you can nowadays use gettime, but the method with that seems to me a bit complicated, with getframerate it could be as easy as: time=time+speed/getframerate()
this would really help the less advanced people like myself to make presets run at correct speed depending on the framerate.
Also there would be no more need for framerate limiter ape i think ;)


14th March 2004 13:37 UTC

True dat Tuggummi. :) I'm messing around with getting time indpendent movement because the presets I make on my 700 system run pretty damn fast on my 2k system :)

You wouldn't even need a function, just a varible like b or i. AVS already keeps track of it, just drop it in.


14th March 2004 14:36 UTC

How is the current method harder than what you said?

time=gettime(0);framerate=1/(time-ltime);ltime=time;


14th March 2004 20:11 UTC

would help less advanced people
I can't even understand how is that method you posted suppose to work...

14th March 2004 21:50 UTC

Frames = frames per second

time between current frame and last frame = seconds per frame.

Better now?


14th March 2004 23:10 UTC

time=gettime(0);framerate=1/(time-ltime);ltime=time;
Uhm where is the time difference then? Well in theory there must be a 0.000001ms time difference between when the code is executed, yet i fail to understand how it's suppose measure the framerate or make presets framerate independent.

15th March 2004 02:55 UTC

The time is in ltime in the end. If you've tried pre-megabuf progression, you'll know how it works (I believe Skupers made something of this sort)


15th March 2004 03:16 UTC

Here is an easier to read piece of code:

changeintime = gettime(lasttime); // here lasttime is what was set last frame
lasttime = gettime(0);

framerate = 1/changeintime;

the method is the same i just thought it would be clearer like this


15th March 2004 03:30 UTC

Explanation
(all goes in the perframe section)
time=gettime(0); //sets time to the current time

secondsperframe=time-ltime; //calculates the seconds perframe by subtracting the current time from the last time

framespersecond=1/secondsperframe;//calculates the frames per second by dividing 1 by the number of seconds per frame

ltime=time; sets ltime to the current time for the next frame

That can all be simplified to-
ltime=gettime(0);
fps=1/(time-ltime);
ltime=time;


15th March 2004 08:53 UTC

Regardless, AVS keeps track of the fps. Why not use it in the next release (hoping against hope)


15th March 2004 12:33 UTC

Because this is more accurate of course. AVS' counter only refreshes every second or so. Using this snippet you can catch sudden changes in FPS, I needed that for e.g. Tokyo Bullet.


17th March 2004 10:07 UTC

If you need a framerate limiter, try this SSC:

Init:


n=0; ncalib=100;
//calibrate to fit your cpu
t=gettime(0);
loop(ncalib,
loop(1000,
exp(1.1)
)
);
tcalib=gettime(0)-t;

t=gettime(0);


Frame:

//calculate currentframe length
lastt=t;
t=gettime(0);
distt=t-lastt;
//and maximum frame length
maxt=max(maxt,distt);
//calculate needed loops to achieve frame length
a=(maxt-distt)/tcalib*ncalib;
//and loop often enough to fill the rest of the frame
loop(a,
loop(1000,
exp(1.1)
)
);
//get t for distance to next frame
t=gettime(0);


Beat:

//reset Maximum frame length on beat,
//in case it got screwed up
maxt=distt;


Add this SSC at the end of your preset and you have an almost constant FPS around the lowest FPS your preset had before.

8th April 2004 00:26 UTC

that's completely offtopic...

and i second ucd, there's no point in a getframerate function/variable. the code really isn't that hard to work out :\


8th April 2004 02:41 UTC

It may not be hard, but it's 3 lines of extra code that isn't needed. He wants it for the sake of simplicity, not because he can't do it with code.


8th April 2004 05:08 UTC

that was not off-topic

Also there would be no more need for framerate limiter ape i think
i replied to that and posted my framerate limiter SSC to point out that you dont need an APE for that

besides: i also agree with unconed, i never neede a getframerate function anywhere. it's plain useless: this function would calculate the framerate from the frame time(or take a value that's calculated this way) and most times you'd need to divide something by the framerate, which is slow and adding to that, it's converting something back and forth...

8th April 2004 17:39 UTC

Any time between frame rate I think give frame per second.
I mean there is relationship between second time & frame rates.


26th April 2004 10:46 UTC

what about using getframe() in a ssc code or a dynamic movement, you could make it become less dense if your framerate dropped or something like that.


26th April 2004 13:04 UTC

there is no getframe() and i don't think it's ever going to be implemented
use the usual method
t=gettime(0);
timesincelastframe=lastframet-t;
lastframet=t

making an SSC or a DM less dense to compensate framerate dropdowns is a good idea though... if only one could set the DM gridsize by code ;)
this method should work with SSC, though.


27th April 2004 06:25 UTC

When i posted this i didn't know better, now i have seen the light... :igor:

Lock it please.