Smart Frame Limiting

Below is some frame limiting code from an article on BlitzCoder. Can someone explain to me why the UpdateGame() function is called only on the last iteration of the loop?
This means that the objects in the game will only be moved by one 'step', rather than 'ticks' steps. When you run through the loop calling UpdateWorld then no objects will be moving (although they will animate) because UpdateGame() is not being called every iteration.

I have also seen others using the same frame-limiting code, but they do not use CaptureWorld. What's the idea there?

Const FPS=30
Global period=1000/FPS
Global time=MilliSecs()-period

While Not KeyHit(1)
	Repeat
		elapsed=MilliSecs()-time
	Until elapsed

	ticks=elapsed/period
	tween#=Float(elapsed Mod period)/Float(period)
	
	For k=1 To ticks
		time=time+period
		If k=ticks Then
			CaptureWorld
			UpdateGame() ;This is where all your game stuff should be updated
		EndIf
		UpdateWorld
	Next
	
	RenderWorld tween#

        Draw2DThings() ; Place 2D rendering stuff here between RenderWorld and Flip

	Flip
Wend
End

That FOR loop looks entirely redundant really...

Dunno, what I do is divide the difference between the FPS the game is meant to run and the FPS the game is running at, this gives me a constant(mathematicaly speaking) of course it's realy a variable. then I just multiply this value with any movement values. The result is a game that will run at the same speed in any machine despite the difference in FPS (of course as long as the PC is capable of running the game at a decent FPS. I'd say 20 FPS would be the minimun specs)

In case anyone cares...

The Blitzcoder article 'Smart frame limiting for 3D using the Tween option of RenderWorld' contains a broken implementation. It does not do proper frame rate limiting.

I think it's supposed to be:

For k=1 To ticks
time=time+period
If k=ticks Then CaptureWorld
UpdateGame()
UpdateWorld
Next

The idea is that you run the updategame function enough times to keep up with it's fps. The captureworld/tweening is an attempt at making it more exact. For instance, if the game is suppossed to run at 60 computational frames per second, and it's doing 50, it would add an extra tick, yet set the tween to a lower value. In the end however, MadMax's method is faster and more accurate. It just requires more planning, and more coding.

I do it the way Madmax does it. You just have to determine what is a time based variable and what isn't. After you do it for a while you are multiplying the modifier out of habbit.

The problem with the code bot builder posted (which is what Marks Castle demo uses) is that on a really slow machine the game can get slower and slower until it locks up. Basically it cannot complete the required fps in one iteration of the for loop, so next time round the number of ticks goes up, and so on.

What you need to do is to limit the number of ticks so that this does not happen. Adding something like

if ticks > 10 then ticks = 10

would do the trick.

I was really just trying to point out that the 'fix' for this problem that is posted on blitzcoder actually breaks the frame rate limiting.

Good point SLB. hadn't thought about it. That's probably why my game(using that code) always suddenly slows up. I put a debuglog on the ticks, and they suddenly shoot up to one-hundred. I've desided to go over my code and switch everything to the variable-coefficient method. Thankfully, my game is in it's beggining stages at 670 lines. Should probably have blitzcoder correct the article. Anyway, thanks for bringing this topic up, as it has solved one of my games bugs.