Timing FPS

I have been told that in Blitzmax you can tell it how many FPS you want in the graphics initialisation command.

In Blitz Basic or Blitz3D you have to use a timer (millisecs).

Is this the best way? I use Blitz3d along with the 'VWait:flip0' command set. It now appears that this is too fast.

yes
you use
timer = createtimer(30)
to make a timer for 30 frames per second

then waittimer(timer)

just before the vwait:flip() line to wait for it

Thanks, Andy!

Would this command make the program wait an extra 30 frames before the vwait?

I seem to remember a different way when I created my first game years back in Blitz.

no, it'll wait for the next "tick" of the timer, which ticks 30 times per second, if that tick has already passed then it'll just go straight to the next vwait. So the fastest your game will run will be 30 frames per second.

No, it's one of the worst. If the computer can't keep up, the game will actually slow down, which is very unprofessional. If you have some calculations which are not done every frame, you could actually find yourself alternating constantly between different frame rates, making the game speed up and slow down, and making it virtually unplayable. Not to mention that you're artificially limiting the renderspeed, wasting CPU time, and you're unable to VSync.

The best would be what gets called "render tweening" around here, and the next best would be delta timing. Given that Bliz3D already implements render tweening for you, it's not only the best but also the easiest.

http://www.blitzbasic.com/codearcs/codearcs.php?code=1497
http://www.blitzbasic.com/codearcs/codearcs.php?code=9

I think it depends :) IMHO delta timing is easier. Many samples have been posted, use the search page. Here's however a quick description:

The game loop runs as fast as it gets, still synched with the Monitor (Note LCD Monitors often don't support VWait). While the game is running, the elapsed time between two frames is measured repeatedly.

delta# is then: Frametime / 16.67
So when the framerate is low then delta is higher and when the rate is high then delta is small. Now you can:

Moveentity player,0,0,stepwidth# * delta#

This way player will move with almost identic speed, regardless of the framerate.

Additionally the Delta Method allows to sync all animated Meshes simply by using delta# as the Parameter of Updateworld()! This is a very nice feature.

ms=millisecs()-17
while game ; start of game loop
  ms2=ms
  ms=millisecs()
  delta#=float(ms-ms2)/16.67
  ..
  moveentity player,0,0,playerspeed# * delta#
  ..
  updateworld(delta#)
  renderworld()
  vwait:flip 0
wend

*head spinning*

Hi pc_tek - what jfk EO-11110 is saying is that in your game loop, if the frame took a longer time than desired to render/update then all the movement, animation and other such features should be sped up, while if the frame took much shorter than desired you should move everything slower for the next frame.

The end result is that it does not matter how fast or slow your PC is (within reason) as the objects in your wolrd will appear to move the appropriate distance over a given time.

What I like to do, which is just one way of many is to work out the 'delta' value like in the code listed above and then pass it as a parameter to your functions which update all your game logic such as movement, particles, projectiles, animation and the like.

Glad I read this, I never quite understood tweening.

WHich would be better for someone who planned to make a networked gamed?

If your definition of easier means having to add additional code to pretty much everything in your game, then yes, it certainly is. As an added benefit, it will produce inconsistent results with just about any physics engine and if you're really lucky, it will cause tiny errors in the physics to build up over time until the whole simulation explodes ( literally.)


You present this as though it's an advantage over render tweening, but it's not. The same feature is available to both methods of timing.


Again, delta time is no more or less synced with the monitor than render tweening.