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 / Can a capped frame rate substitute timer based movement?

Author
Message
wattywatts
14
Years of Service
User Offline
Joined: 25th May 2009
Location: Michigan
Posted: 10th Sep 2015 19:39 Edited at: 10th Sep 2015 19:42
It seems that no matter what timer function I use, my game runs choppy. If I cap the frame rate and set normal values everything runs smooth. But will it work this way on all computers?
I'm not worried about it slowing down on older or less powerful pc's, as mine is pretty old. Mainly I'm just wondering if syncing to 60 will mean the move object value will make my character walk at the same speed on more powerful pc's.

edit
I'm pretty sure the dark souls pc port works this was (admittedly it's a sloppy port)
Le Verdier
12
Years of Service
User Offline
Joined: 10th Jan 2012
Location: In the mosh-pit
Posted: 10th Sep 2015 20:59 Edited at: 10th Sep 2015 21:01
I wouldn't recommend it. The help file states it is only aporoximative...
I had the same problem a long time ago
Where my game behaved diffrently on different computers...
So better use sync rate 0, w or without syncing, and a tbm...with performance timer
http://forum.thegamecreators.com/?m=forum_view&t=212461&b=1&msg=2538329#m2538329

All hail the new flesh
wattywatts
14
Years of Service
User Offline
Joined: 25th May 2009
Location: Michigan
Posted: 10th Sep 2015 22:52 Edited at: 10th Sep 2015 23:03
Quote: "So better use sync rate 0, w or without syncing, and a tbm...with performance timer"

Perftimer does cut down on the jerky movement, but as I'm running an older version of dbp the perffreq function isn't available.
I made a video but unfortunately the screen capture software I used doesn't show the problem (https://www.youtube.com/watch?v=qRg11MDLjE0) but basically with tbm constantly changing values my character sometimes jumps forward and the only way I can see to completely fix the issue is not using any tbm.

Unless there's some way to make sure the tbm value always stays the same - but I think that would defeat the purpose right?

edit
upon further reading of the thread you linked to I guess I have my answer about using sync rate, but then the question changes - I need a better tbm method. Even with matrix1 hitimer the movement is jumpy, albeit less so.
Le Verdier
12
Years of Service
User Offline
Joined: 10th Jan 2012
Location: In the mosh-pit
Posted: 10th Sep 2015 23:54 Edited at: 10th Sep 2015 23:56
Freq can be retrieved with an API call:



http://forum.thegamecreators.com/?m=forum_view&t=210153&b=6&msg=2510406#m2510406

All hail the new flesh
wattywatts
14
Years of Service
User Offline
Joined: 25th May 2009
Location: Michigan
Posted: 11th Sep 2015 00:14
I did not know that, that's awesome! Thanks Le Verdier!
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 11th Sep 2015 09:37 Edited at: 11th Sep 2015 09:49
Limiting frame rate sucks, it's a bad thing to do as it greatly reduces the quality of your game.

That being said, there's a few things to consider:

1. If you cap your frame rate, what happens if the game dips below that frame rate? The cap is 100% useless if the computer cannot maintain that frame rate.

2. What happens if the frame rate is too high? What happens if the frame rate is 1000 or 10000 and the TBM corrections are making movements per frame so small that they are rounded to 0? Or have other CPU math rounding errors?

You can get situations where your game glitches out or locks up and you tear your hair out wondering why. Consumer CPU's cannot handle very small numbers properly and begin rounding them even though they can store many more decimal places.


So in an actual finished video game product you should have some upper limit that the player can set for frame rate. An ini file that simply enables the frame limiter, and it's limit might be all you need.


3. Consider the concept of modern mobile computing. If I am running a laptop or a tablet then battery life is important. A CPU/GPU friendly frame limiter is often an obvious thing. If your game runs well at 30fps, what good is it for me to run the game at maximum achievable frame rate, sucking all available resources, for only 10 minutes as the battery depletes?

If I can hit 30 or 60 fps with only 1% CPU usage, then why have the game use 100% CPU anyway? For a mobile user, or anyone with a noisy computer fan this makes no sense.

Here's an example of a CPU friendly limiter:
http://forum.thegamecreators.com/?m=forum_view&t=202812&b=1

wattywatts
14
Years of Service
User Offline
Joined: 25th May 2009
Location: Michigan
Posted: 12th Sep 2015 20:11
Those functions are really cool Mage. I'm not sure if I can use them in my project or not, I'd really like to use the standby function but there's no point where something on the screen isn't moving because of my characters idle animation.
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 13th Sep 2015 08:28 Edited at: 13th Sep 2015 08:42
The standby function is more for a situation where you don't need to continuously animate. Such as an editor or some kind of mouse click driven game.

What's important is the CPU friendly limiter. It's posted above the standby section. It is a very useful thing to have.

If you just have a Do Loop or a While Loop (or Sync Rate) running to cap your frame rate, then your CPU (or CPU Core) stays at 100%. A CPU friendly limiter would let the CPU rest if a frame is drawn to the screen with time to spare. That free time lets the computer save heat and battery life. It means that your game doesn't max out your computer if it doesn't need to.

If your game is hitting 120 fps and all you need is 60 that means each frame you are drawing in 8ms instead of 16ms. So you can dynamically spend that spare 8ms (or whatever needed time) doing nothing instead of drawing the next frame early. You drop the frame rate to 60 and effectively half the workload for the CPU and GPU.

Login to post a reply

Server time is: 2024-04-20 00:32:56
Your offset time is: 2024-04-20 00:32:56