Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Sync Rate vs. FPS rate?

Author
Message
Chris64
21
Years of Service
User Offline
Joined: 16th Oct 2004
Location: San Diego
Posted: 3rd Apr 2005 10:41
I see demo's where people reference an objects speed / framerate. I'm assuming people are using screen fps() to get the other half of that formula.

What is the benefit of that vs. setting a sync rate?

I've tried a few of the demo programs and some of them have a pulsing feel to them every second or so...I'm wondering if that might be caused by the screen fps fluctuating every second or so. I'd prefer to use the sync rate method as the other could have collision inaccuracies caused by the speed attempting to compensate on slow computers. When you set the sync rate, it should be the same on all computers...right?
Nicholas Thompson
21
Years of Service
User Offline
Joined: 6th Sep 2004
Location: Bognor Regis, UK
Posted: 3rd Apr 2005 10:46
in theory - it limits it.

Say you limit it to 60. Thats great if the machine can do 60 or more. If you play it on an old laptop though, it'll still do about 5fps and your game runs slow.

The best way is timer based where all movement is based on the fomula distance = speed * time.

My Website:
Chris64
21
Years of Service
User Offline
Joined: 16th Oct 2004
Location: San Diego
Posted: 3rd Apr 2005 13:08
By that same logic if the computer were too slow it would throw off your math so bad the game could have flaws...a bullet could fly right through you for example. Theoretically because the FPS method requires more math it would technically require a faster machine (only slightly).

I guess my main question is; are there any problems with using Sync rate to standardize the speed? Will the sync rate be the same regardless of the video settings (provided that frame rate is below the maximum of that computer of course)?
re faze
21
Years of Service
User Offline
Joined: 24th Sep 2004
Location: The shores of hell.
Posted: 3rd Apr 2005 13:20
sync rate 40 works much better in dbc than dbp, i remember it stoppetd the fps as exactly the number you specified +/- 5 fps
with dbp i set the fps to 75 and i get 32 fps but i set it to 0 and get 75 (fsex mode) this is a problem.
Baggers
22
Years of Service
User Offline
Joined: 31st May 2004
Location: Yonder over dem dere hills
Posted: 3rd Apr 2005 19:55
@Chris64: It allows you to work in units per second calculations rather than units per loop, its a nice way of making sure games run on various computers without having to restrict the frame rate.
Nicholas Thompson
21
Years of Service
User Offline
Joined: 6th Sep 2004
Location: Bognor Regis, UK
Posted: 3rd Apr 2005 20:39
@Baggers: I'm glad someone see's the point

@Chris64: You're right, in my method if the FPS slows down too much then it MIGHT jump through a wall. What you do then is after doin a collision check, just do an intersect check between the old position and the new one. That works for bullets. In fact, seeing as bullets are so small, you could just to intersect on its own which would be much faster than box, sphere or poly collision I would guess..

I use this code for EVERY ONE of my projects:


In the main loop, you end up with frameTime# being the average frametime in milliseconds. This means you can use it for movemnt like this:
turn object left 1, frameTime# * 0.090 :`This turns the object at 90 degrees per second

move object 1, frameTime# * 0.001 * playerSpeed#


@Xperiment 627: The reason you getr 75fps is fsex mode is because DX v-syncs the screen to your refresh rate which is, by the sounds of it, 75hz. If you do full screen windowed mode and sync rate 0, you should get silly FPS.

This little snippet does 83fps on my machine.

To be honest, I NEVER rely on the sync rate. It just puts wait commands in to try to limit the fps. Why would I want to LIMIT my speed? I want it to go as quickly as possible!

My Website:
re faze
21
Years of Service
User Offline
Joined: 24th Sep 2004
Location: The shores of hell.
Posted: 3rd Apr 2005 23:07
ever played a win 3x game on xp? the speeds are rediculous

and i know about fsex mode its just that sync rate is unreliable
Nicholas Thompson
21
Years of Service
User Offline
Joined: 6th Sep 2004
Location: Bognor Regis, UK
Posted: 3rd Apr 2005 23:57
Hehe.. I'm surprised you got a win 3.x game working on WinXP! unless you meant Win9x in which case I'm still surprised
I remember trying to play UFO Enemy Unknown on WinXP on my 1Ghz machine (UFO was designed for sub 66Mhz). IT was uncontrollable. It wont even load on my 3.2Ghz!

I find Sync Rate unreliable. I never rely on it for accurate speed limiting, I only ever use it if I want my game to run at about 100fps max instead of 1500fps (usefull sometimes as reltive movement can have accuracy issues when the frameTime is too small due to floating point limitations).

My Website:
Chris64
21
Years of Service
User Offline
Joined: 16th Oct 2004
Location: San Diego
Posted: 4th Apr 2005 02:35
Nicholas; I like that timer method...the samples I've seen previously use screen fps() which I don't like.

If sync rate is unreiliable that pretty much answered my question...Although I don't really understand why or how it's unreliable. I've tested it on some drastically different machines and it seems to work fine.

I guess the way I see it is that adding the extra math only slows the program down that much more. Plus, like I said earlier I've tried a bunch of the demo programs and they have a pulsing feel to them...

I was playing Collin Mcrae rally the other day and on my desktop it runs perfectly...on my lap top it runs a little glitchy at certain times, but rather than running slow it just jumps at times...the screen will pause for a half a second or so and then all of sudden your flying off the side of a cliff. I guess this is another reason why I don't like this method. I'd rather see the car pause and then continue from that same spot...and it might run a little faster if it didn't have that extra math.

So can anyone explain how I can reproduce an unreliable Sync Rate (assuming the program is built to not slow down beyond that rate of course)?
Nicholas Thompson
21
Years of Service
User Offline
Joined: 6th Sep 2004
Location: Bognor Regis, UK
Posted: 4th Apr 2005 05:01
Quote: "reproduce an unreliable Sync Rate"


Why?

I'm not entirely sure what you want.. I gave timer based movement above, that works for any fps so no need to limit. You could always have a statement after it calculates frameTime# saying if its more than say 500ms (making 2fps) then dont bother rendering the frame and skip to the next one thus it wont render that frame making the car jump off the cliff, instead it will loop around again and try to calculate another frame time. Might work, might not.. Kinda thinking out loud.

If you want to reproduce the sync rate command yourself, you'll need to have a variable keeping track of the frameTime and then calculate a target frame time (ie how long a frame SHOULD take) then you know how much off you are and can start calculating how long you want your game to sleep for each frame to try to even out the fps to whatever you want.

Any use?

My Website:
Chris64
21
Years of Service
User Offline
Joined: 16th Oct 2004
Location: San Diego
Posted: 4th Apr 2005 05:32
Your giving me the most constructive objections possible and I appreciate that. I guess what I'm struggling with is rather than multiplying the speed, rotation factors, graphic factors of every object on the screen, I'd rather just have a standardized "60 fps" and build everything to look right at that rate.

Maybe the fix is to have a time delay routine built that runs right before the sync command. BUT, that solution is only necessary if sync rate is flawed. I've never seen any flaws with this command though (except of course too much CPU that brings it below the required rate).

anyway, I appreciate your feedback and I'll mess around with it a bit and see how the results work out.
Nicholas Thompson
21
Years of Service
User Offline
Joined: 6th Sep 2004
Location: Bognor Regis, UK
Posted: 4th Apr 2005 06:41 Edited at: 4th Apr 2005 06:45
Cool - good luck and post back with any findings.

You could try to make your own, it probably wouldn't be too hard..

Basically, precalculate how long a frame should take in milliseconds (for example, for 60fps: 1000.0 / 60.0). This gives you a target frametime.
Then, record the timer() value at the begining of the loop.

Then at the end, put yourself in a while loop doing something like:

while timer() - startTime < targetTime : endwhile

That shuold make it pause for the right amount of time..
Again, this will only work if the program is capable of running at 60fps or more on the machine. If not, the while loop should skip right by.
Might work! no idea.. lol

EDIT:
Ok, got bored:


On my PC, this code holds the FPS at abuot 58fps. If I remark out the while line and change sync rate to 60, FPS holds at 79-83! Hmm..

My Website:
Chris64
21
Years of Service
User Offline
Joined: 16th Oct 2004
Location: San Diego
Posted: 4th Apr 2005 07:32
Nice...
It held very steady at 58.7 at 60, and 77.5 at 80

When I added sync rate 80 it didn't change, then I changed it to 60 and it ran at 66.6...so there's an example of Sync rate failing to hold that speed. Thanks for taking the time, I'll probably be using your method. I still prefer that method over altering the speed of everything...just my preference.
Avan Madisen
23
Years of Service
User Offline
Joined: 12th Sep 2002
Location: The Castle Anthrax
Posted: 4th Apr 2005 08:46 Edited at: 4th Apr 2005 08:48
My opinion is, never use 'screen fps()' for anything other then displaying frame rate on screen, it's inaccurate and only updates once every second. That command is only really for gauging approximately how fast the program is running.

DBPro cannot maintain a fixed fps, this is because the timing is based on a 1000 ticks per second clock working against a monitor with a fixed refresh rate (default 60hz), so asking for anything other then 60,30,15,etc. are guarenteed to result in problems. Not to mention that the 1000 ticks per second cannot be evenly divided into 60.

Here's a list of the approximate fps I get from different sync rates on my system:

Sync rate - FPS
40 - 32
50 - 32
60 - 64
75 - 64
100 - 128 (only at low screen res's with high refresh rates)

As you can see, my system and sync rates don't work well togethers so I always code for variable frame rates. Although most people's systems would have fewer problems, my point is that forcing fps to a certain number is not a reliable way to control the game speed.

My advice is that even though coding for variable fps using the timer is slightly more time consuming it is far more reliable, this is because instead of the program trying to force the graphics card to run at a particular speed, the graphics card is allowed to run at full pelt, while your program gets taken along for the ride.

There is another technique you could use which may prove better in some ways. The idea is that your program only updates things a certain number of times every second using fixed time step code while allowing the graphics card to run full speed. It works by keeping track ot the timer and updating the physics (and anything else) a number of times based on that. Using the 1000hz timer you could easily set the program to update 100 times per second, it counts the ticks and everytime it gets to 10 it updates everything. At slowler then 100fps this will work reasonably well, but at higher then 100 it may result in visibly jerky movement. Although most people's systems only use the default refresh rates. Here's an example piece of code:


Another option would be IanM's high frequency timer plugin, with that you can set virtually number of ticks per second, that would allow you to control the updates to almost any speed you like.

(lecture over)

I don't suffer from insanity:

I enjoy every minute of it!
AndyPandy
21
Years of Service
User Offline
Joined: 12th Oct 2004
Location:
Posted: 5th Apr 2005 23:30 Edited at: 5th Apr 2005 23:31
Just turn sync off with full screen exclusive on and use a timer based solution. 1. You get better fps as your cpu is not being used at 100% 2. Windows/Hardware takes over the screen refresh leaving you with silky smooth framerates as long as your hardware is up to the refresh rate of your monitor at the current resolution your using.
Neofish
22
Years of Service
User Offline
Joined: 7th Apr 2004
Location: A swimming pool of coke
Posted: 6th Apr 2005 00:45
*too lazy to read thread*
Quote: "@Chris64: It allows you to work in units per second calculations rather than units per loop, its a nice way of making sure games run on various computers without having to restrict the frame rate."

yes but if the progam lags for a second the change in time increases. Fair enough this is fine for things like models on a big map, the change is tiny, but it's not effective when something like the GUI has to be accurate...besides setting the framerate makes it easier to debug , delta times has its problems.

Login to post a reply

Server time is: 2026-06-11 11:20:49
Your offset time is: 2026-06-11 11:20:49