V3 Framethrottler
Displaying 1-4 of 4 total.
1
Please enter a numerical value for the importance of this sticky.
Enter 0 to unsticky.
Omni

Heard someone mention this on the boards a while back.

So, I made one.

Read the readme please. I'm not sure how good my timing code is. It runs perfectly on my computer, but I don't know about yours.

The framethrottle can manage the rendering for a frame, and the data processing (mathematics, input code) for a frame, in two separate functions. Pass the name, similar to CallFunction(). It calls rendering according to frame throttling, and it calls processing once every frame.

The framethrottler can simulate extremely high framerates by increasing the processing function call speed (similar to turbo mode in ZSNES).

It can manage code within the 0-1000 fps range. Frameskipping is automatically corrected if negative.

I don't know what the max frame skip value is, but I imagine that if the value goes above 1000 bad stuff starts to happen. At that point most of my timing division will always return zeroes.


Quickie info:
void SetMaxFPS(int fps)
void SetFrameSkip(int skip, int type)
void FrameThrottle(string renderfunc, string processfunc)


Download Link

This is my first V3 code/demo, so ...go easy.

Keep in mind that even though it may render less than the maximum frames per second, the timing will always process exactly the correct number of frames per second. Always. In fact, it will probably always render less than the max frames per second, because the timing for 60 fps requires one frame to be 16.666 millisecs, and my code truncates that to 16. But it shouldn't matter.

Unless the code doesn't work. It which case I'm a bad coder.

Also, at 60fps automatic skip, the rotating image will rotate completely around exactly every second.

Finally, a demo note: switching frame skip types during the demo will not change the frame skip. This means that if you switch from continuous to automatic, the frame skip will keep going. Switch back to continuous, and change the frame skip to zero, then switch to automatic.

Posted on 2004-07-01 06:24:50

Omni

Framethrottler version 2.

Changes Between Version 1 and Version 2:
I made version 2 because I believed I couldn't get the render timing right on version 1.
If your PC was slow, the processing thread caught up fine, but for some reason, the math on
delay before the next render call was always off, and you'd never get quite the right max frames rendered.
So I messed with it, trying to figure out the right timing code...I never found it.
Then I thought...hey. The processing timing code works fine. Why bother with anything
else?
So I remade it. The engine always calls the render function as many times as possible
now. This way, we don't have to worry about delaying before the next render update. And this
means you don't have to worry about not getting your max fps. You'll get whatever the computer
can give you.
The processing code has been revamped to allow frameskipping on the processing side.
It delays processing to skip a number of frames, then quickly catches up on all the processing.
This gives you rock solid timing. Now...if your input is time-specific, you might miss a press of
a keyboard key while frame skipping, but it's nothing game-breaking at all, I don't think.
Also, I took away frameskip types, since the engine now automatically maintains the
needed fps, and does any skipping you tell it to.
This new approach also seriously cut down on the size of the function and the number
of tracking variables I needed.

Also, I COULD upload this to useful VC demos, if anybody's interested.

Posted on 2004-07-06 02:46:22 (last edited on 2004-07-06 02:47:02)

blues_zodiakos

Cool stuff! I was looking for a way to control the timing of my particles in my particle engine (which I'm completely redoing when I get back from Germany to make it more modern, i.e. able to do fire and smoke effects, etc.). With this code, I could make sure that the particles move at the same speed on different computers. I can pretty much get rid of my timing code, or at least give an option to disable it, if the game is using your code, because it wouldn't be needed. :D What that means, however, is that I will be able to base the particle movements on timing speeds, for example, a particle is supposed to move 1 inch per second, I can do that now. Thanks alot, I'll check it out when I get back. :D

Posted on 2004-07-06 18:41:13

Omni

for movement, you may want to do base 60 for base FPS.

For example, to increase something 100 pixels per second at 60 FPS:

int count60;

(Update)
count60++;

(compute to get the out of 100 value)
count60 = count60*100/60;

Or, substitute 50 for 50 fps, etc.

Posted on 2004-07-07 02:01:15


Displaying 1-4 of 4 total.
1
 
Newest messages

Ben McGraw's lovingly crafted this website from scratch for years.
It's a lot prettier this go around because of Jon Wofford.
Verge-rpg.com is a member of the lunarnet irc network, and would like to take this opportunity to remind you that regardless how babies taste, it is wrong to eat them.