graphics.SetFPSLimit

[hartnell]

While I'm at it, there really needs to be a graphics.SetFPSLimit where the argument is a cap on the number of frames that can be drawn a second. This is a very common feature and essential for creating games that run at the same speed on different speed computers.

-hartnell

[Guilect]

Limiting frame rate is an outdate method of having a game run the same across different platforms.
Once you try the time-based methods of movement, see u9's examples, you will never go back.

But for those who have yet to embrace time-based:
option explicit

class stat
public old
end class
Dim objstat  
Set objstat = New stat
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'  Declare our variables
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dim bRunning
bRunning = True

dim Font1

'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'  Our main routine
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sub main()

if (graphics.initialize(800,600) <> True) then exit sub ' default of 640x480 windowed

graphics.setTitle "Demo - FPS"

key.initialize  ' initialze the keyboard routines so we can ESC the program

Font1 = graphics.CreateFont("system", 14)

do while bRunning = True
if key.pressed(1) or key.pressed(0) = True then bRunning = False
       
   graphics.clear(255)
   graphics.SetText "Press [ESC] to exit", 0,0, Font1    
   graphics.SetText "FPS: " & CStr(graphics.fps), 10,150,Font1
   FPSLimit 85
   graphics.display
   
loop

key.terminate
graphics.terminate

end sub  

Call Main   ' start the program

Sub FPSLimit(ByVal FrameRate)
       Dim lngTicksPerFrame
       lngTicksPerFrame = 1000 / FrameRate
       Do While system.GetTime() < objstat.old
            system.processMessages
       Loop
       objstat.old = system.GetTime() + lngTicksPerFrame
   End Sub

[u9]

I will have to agree with Guilect on this. Having games run similar on different platforms by limiting the frame rate is outdated. But here's another example. I feel that it is much simpler then Guilect's and others I have seen, so I'm not sure if I'm smarter or doing something wrong. And just to try it out, this example is written in JScript.


// This is the amount of time we want the frame to take (measured in ms)
frameTime = 1000/60 // 60 fps

graphics.initialize()
key.initialize()
font = graphics.createFont( "system", 12, true )

isRunning = true
do {
   
   // Record time at beginning of frame
   timestamp = system.gettime()
   
   // Do some game simulation and rendering
   graphics.clear( argb(0,0,0,0) )
   graphics.settext( "fps: " + graphics.fps(), 10, 10, font, argb(255,255,255,255) )
   graphics.display()
   
   // Wait until correct amount of time has passed (frameTime)
   do {
       if ( key.pressed(0) || key.pressed(1) ) {
           isRunning = false
       }
   } while ( timestamp + frameTime > system.gettime() && isRunning )
   
} while ( isRunning )

key.terminate()
graphics.terminate()



The only thing I do is essentially record the time at the beginning of each frame, then when done with the game physics and drawing, I wait until a pre-defined amount of time has passed and then continue to the next frame.

[hartnell]

Do you think you could build it in for those people who like doing it that way?

-hartnell

[u9]

I must say, I would find this decision very difficult to make. One wants the learning curve to be as fast as possible and make it as easy as possible for people to use although avoiding "bad" functions/features/syntax etc. that encourage bad programming practice.

But currently Brutus2D is already doing this to some extent. When running in full-screen, one cannot update the display faster then the refresh rate of the monitor. It might not be a good thing if the game sets a different refresh-rate (fps limit) as when one gets close to the limit it will appear as if there are glitches in the game.

In windowed mode it is a completely different story however.

Personally, I think this shouldn't be implemented, but then again, I don't even like BASIC hehe.

[hartnell]

Limiting the FPS is normally done in concert with the vertical blank, so this is not usually a problem. I'm still arguing for it. Some people prefer it over anything else, and, how would you do bullet time easily without it?

-hartnell

[u9]

Well, that's why I made the timing tutorial on www.gamedesignnovice.com/wiki But I am actually thinking of making another tutorial regarding collision detection and stuff for fast paced objects that otherwise might fly right past/through something because of the time-step being too large. I will need to figure out how to do that anyways as I need fast bullets in my space shooter game (which is lying idle atm because of school). Currently I just have very small time-steps to avoid missing any collisions (in mini racer), but I don't think that is the best solution for collision detection.

[hartnell]

That's fast. I'd like to see it.

-hartnell