Dark Bit Factory & Gravity
GENERAL => Projects => Topic started by: Shockwave on August 20, 2006
-
Hiya,
Having been miffed at jittery refresh rates with tinyptc I think I might have cracked the problem.
I have tested this intro at several refresh rates, right down to 9fps. It remains watchable at speeds as low as 20fps, anything between 50 and 400fps looks nice and smooth.
BUT! As I am painfully aware, that doesn't mean that it would be the same on all systems so please give it a run if you can.
The intro will stutter for approximately the first second while it works out what speed it should be running at on your system, then it should smooth it's self out.
Cheers.
-
About 120-125fps here. What exactly is the problem you are trying to fix? The fact that the time it takes to draw a frame isn't consistent? So are you now averaging out the first N frames-worth to find out what the amounts you are adding on should be? Under Windows you should be able to adjust continually, because you never know what the rest of the OS is going to throw at you. In our games we used to use the time it took to draw the previous frame as the best guess for how long it will take to draw the next frame. Or you can average the last few to get a smoother guess. All our movement/AI/physics/animation routines took time as a parameter, so any movement gets scaled by how fast you're rendering. For instance angle = angle + elapsed_time_of_last_frame * some_suitable_scale_factor.
Just watch that that time doesn't drop below 1ms or go to a huge value when someone alt-tabs away and your app effectively stopped.
As this is an experiment can you show some source with the problem?
Jim
-
Mmm, sorry Jim, I wasn't really after FPS, I just wanted to make sure that it looked smooth on several different systems to be sure that my technique works.
All I am doing is seeing how many frames are rendered over the last second and then adjusting accordingly, it does this throughout so if an event happened that slows the PC down then the intro should compensate.
I will of course release the full code for this intro when it's finished, it's a little bit of a mess at the minute.
-
Silky smooth after the first few hundred milliseconds. I should try inserting a CD or plugging in a USB dongle while it's running to try out the new features.
Jim
-
nice and smooth here shockwave.
very cool btw.
-
Again, Shockwave - looks amazing - no problems with my rig . . .
Ive got an AMD Athlon 2600+ with 1Gb ram, A GF5600 with 256Mb Ram - nothing special!
Hope this helps - can't wait to see the source code!
Drew
-
Smooth here, 60 to 70 fps on my PC - P4 2.8ghz Geforce 6600GT
-
Smooth here as well 50-60 fps
-
just over 60 here and pretty smooth.
-
Thanks a bunch :)
-
'Bout 130 FPS here and silky smooth
-
Thank you BA. I'm quite confident that it will be fine to use this technique now.
-
64 Fps here dude.
And that's very clever how you've managed to toggle the Effect Screen & console window with alt + tab using tinyptc.
Cheers,
Clyde.
-
That's automatic mate, as long as you compile the program -s console the console window will run in the background, Alt+Tab will send most programs to the background.
-
Cool and thanks for that mate.
Cheers,
Clyde.
-
Runs smooth here @ 50fps
One thing I noticed though, when I alt-tab back to it after a while of looking at the fps, the effect is in turbo mode then settles back down again, so it does seem to catch up :)
-
Thanks Daf. This technique has come to fruition now, hopefully I'll be able to use it in something. :) It goes ape because it averages fps over 1 second. Jims method would be better.. ie see how many millisecs it took to draw the last frame and base it on that.
-
Runs at about 25 FPS here 750 duron but it feels like it runs at 60FPS. It's sooooooo smooth!!!! You'd have to teach us how to do that!
O0
-
It's really easy Rel, I'll make a little tutorial post about it with an example soon :)
-
It's really easy Rel, I'll make a little tutorial post about it with an example soon :)
Does it work like this?
get time difference from last frame to current frame
divide the time diffirence by the needed frames
multiply each vector component with the multiplier
Hell, just make a tute. I like it!
-
Yip, easy as that.
I did an example program instead, you can find it here;
http://dbfinteractive.com/index.php?topic=587.0
-
kool!!!
-
I'm going to sound a bit dim here. I thought delta timeing was to have the prog run at the same speed on all capable machines?
So if you are having a variance (on the faster machines) of fps doesn't that mean that the timing routine is not working on those faster machines? Or does it mean that the display(movement etc.) will be the same no matter what the fps? Hit me with the stick of knowledge please :whack:
-
Say your game ran at 60fps and you moved everything 1 pixel across every frame, then it's speed would be 60 pixels per second.
If your code only runs at 30fps, then it'll only move 30 pixels in a second, half the speed.
And if your code is jumping about all over the place, like it tends to do on Windows, then the speed is erratic.
What you need to do is compensate. If you were running at 30fps, you could simply double the number of pixels moved per frame, so 30x2 = 60x1. But more generally, assume the framerate you are running at is based on how long it took to draw the previous frame. If the last frame took 1/60th then add 1 pixel, if it took 1/30th then add 2 pixels. 1/15 is 4 pixels etc. So you automatically compensate.
Taking it to it's conclusion, if the last frame took 1/n seconds to draw, then the amount to move would be
(1/n)/(1/60) = 60/n pixels per frame
It means on slow machines, even though you compute the physics less often, it moves just as far across the screen. You can do it with positions, rotations, colour changes, anything really.
Jim
-
Jim has explained it much better than I could. It's more or less the same as what I am doing, only I am taking an average of more frames, I don't know why but the movement just didn't look quite right to me when I was taking the time in millisecs to draw the last frame, I need to experiment with it more.
-
Thanks Jim and Shockwave for the explanation. :cheers:
-
Silky smooth Shockwave. Looks retro and very cool too BTW.
145 FPS here
-
Thanks Voltage :) I actually completed an intro using this technique but unfortunately I couldn't release it here because I would have technically been breaking the rules of the forum, but it's on the Intro Inferno site released under the group name Rituel.
-
@Shockwave - What do you mean about technically breaking the forum rules?
Obviously after my first demo its plain to see that i need some delta timing in my code to at least slow the scroller down! lol!
Drew
-
Rituel are a piracy group and since this forum is 100% legal only I could not really justify releasing the Rituel intros here :) Still, they are on Intro Inferno if you feel like looking :-X
-
Btw. I want to say for the record that I do not possess *any* pirated stuff. I even paid to register my copy of Winzip. I think that if you use a product then you should always support the people who made it, having said that, I do love the art form of coding cracktros, it's where the demo scene came from and if it wasn't for them, this place would not exist.
-
Thanks for clearing that up Shockwave. I see where you are coming from now!
Drew