Timing. Introduction help please.

Miscellaneous Forums/General Discussion/Timing. Introduction help please.

As this question is more of an global questino (not concerning a specific language) I'll drop it here.

Til this date I've never really bothered about timing as my games has been very small and just for hobby. Now I'm developing my first commercial title and realise that my game is superfast on some computers and somwhat slow on others which brings me to the question: how on earth do you guys deal with this things?
I know some of you talk about delta timing etc but I haven't got a clue what that is. Do anyone want to help me out a little bit with this (I suspect a LOT of rewriting the code is coming up).

do a search for 'delta time', it's plenty of examples and should point in the right direction

I'm using Tweening and its just great since its applied to every aspect of my game world without additional multiplying delta value with other motion/animation dependent values..

or Fixed Rate Logic

And those were the words that I did see everywhere but didn't get any explanation of ;)

Well, I read into DeltaTiming and it looks like thats the thing that ive been looking for. Seems to work great here now.

Some day I'll look into the other techniques as well.

Try this:
http://www.blitzbasic.co.nz/codearcs/codearcs.php?code=1497
; Render Tweening

Without wanting to hijack this thread too much (sorry Andreas)

-I understand delta timing but what is Fixed Rate Logic. Doing google searches on it I cannot find anything easily. (I probably already use something like Fixed Rate Logic but I'm curious to know just what it is)

http://www.gaffer.org/game-physics/fix-your-timestep/

AJirenius: Probably delta time would be fine for your 3D game.

If you run a hook that makes sure that parts/all off you program are run at a certain frequncy
http://www.blitzmax.com/Community/posts.php?topic=69149#773135
or
http://www.blitzmax.com/codearcs/codearcs.php?code=1721
for Example.

The it runs the same speed on all computers. This is fixed rate. It probably the easiest to do, but it means you have lots of "CPU" down time

This one is bt Mark Sibly him self:

; ------------------------------------------------------------------
; 	GameCore -- support@...
; ------------------------------------------------------------------
; The basics of a frame-limited Blitz 3D game, ready to rock
; ------------------------------------------------------------------
;             Adapted from Mark Sibly's code
; ------------------------------------------------------------------



; ------------------------------------------------------------------
;	Game's frames-per-second setting
; ------------------------------------------------------------------

Global gameFPS = 50

; ------------------------------------------------------------------
;	Open 3D display mode
; ------------------------------------------------------------------

Graphics3D 640, 480

; ------------------------------------------------------------------
; Single camera setup
; ------------------------------------------------------------------

cam = CreateCamera ()
CameraViewport cam, 0, 0, GraphicsWidth (), GraphicsHeight ()

; ------------------------------------------------------------------
; General setup
; ------------------------------------------------------------------

; Load and arrange objects, textures, etc here...

	; Quick example (just delete this)...
	
	Global box = CreateCube ()
	MoveEntity box, 0, 0, 5

; ------------------------------------------------------------------
;	Frame limiting code setup
; ------------------------------------------------------------------

framePeriod = 1000 / gameFPS
frameTime = MilliSecs () - framePeriod

Repeat

	; --------------------------------------------------------------
	; Frame limiting
	; --------------------------------------------------------------

	Repeat
		frameElapsed = MilliSecs () - frameTime
	Until frameElapsed

	frameTicks = frameElapsed / framePeriod
	
	frameTween# = Float (frameElapsed Mod framePeriod) / Float (framePeriod)

	; --------------------------------------------------------------
	; Update game and world state
	; --------------------------------------------------------------
	
	For frameLimit = 1 To frameTicks
	
		If frameLimit = frameTicks Then CaptureWorld
		frameTime = frameTime + framePeriod
		
		UpdateGame ()

		UpdateWorld
			
	Next

	; --------------------------------------------------------------
	; **** Wireframe for DEBUG only -- remove before release! ****
	; --------------------------------------------------------------
		
	If KeyHit (17): w = 1 - w: WireFrame w: EndIf ; Press 'W'
	
	; --------------------------------------------------------------
	; Draw 3D world
	; --------------------------------------------------------------

	RenderWorld frameTween

	; --------------------------------------------------------------
	; Show result
	; --------------------------------------------------------------

	Flip

Until KeyHit (1)

End

; ------------------------------------------------------------------
; Game update routine, called from frame limiting code
; ------------------------------------------------------------------

Function UpdateGame ()

	; Get keypresses, move entities, etc

	; EXAMPLE CODE -- REMOVE! Uses cursors...
	If KeyDown (203) TurnEntity box, 0, 0.5, 0
	If KeyDown (205) TurnEntity box, 0, -0.5, 0
	
End Function


That's basically a fixed rate logic with a tween. SHould work well.

Does that mark sibly example then mean lots of cpu down time that you could be using?

that example by mark cant be done in Max can it ? due to the renderworld tween..

Did anyone get render tweening done in max ? it was my preferred way of game timing.

It works fine, you just have to do the tweening yourself.

Does that mark sibly example then mean lots of cpu down time that you could be using?
Yep, well, maybe not Marks one, cos Ive not looked at it. But normaly Fixed rate uses less and less % of the cpu power as the cpu power increases.
However, lets say I make a clone of... Viking Raiders, it doesnt really NEED lots of CPU time, and so if I use fixed logic, I can nearly definatly garrentee that the OS will still have loads of time, so that ppl can Play my clone of Viking Raiders whilst the Comp does stuff in the background. (A-la FreeCell, which is aparently the most played PC game ever)

I'm rather pleased with the timing that I have for this thing, so here is an example pulled from it.
(Also available here).

What I am doing there is not keeping a consistent frame rate under the hood, but having the speed that the player sees completely consistent. This makes it easy for a few neat goodies like a game speed slider! (The speed can be consistently / reliably dealt with using FL\SpeedFactor).
The code compensates for slower than expected frame speed in a magical way, by adjusting FL\SpeedFactor.

The main program (with irrelevent stuff removed) (sorry, it's a bit strange):
;#Region Global Variables
	Global Terminate = False ;Set this to True anywhere to terminate the program.
	
	Global DefaultFR=30
	
	Global Event
	
	;Frame Limiter Initialization
	Type FrameRate
		Field TargetFPS#
		Field SpeedFactor#
		Field FPS#
		Field TicksPerSecond
		Field CurrentTicks
		Field FrameDelay
	End Type
	Global FL.FrameRate = New FrameRate
	FrameLimitInit(30.0)
;#End Region

;#Region Main Loop
Repeat
	MainLoop()
Until Terminate
WB3D_EndGUI()
End
;#End Region

Function MainLoop(act=1)
	SetSpeedFactor()
	Event=WB3D_WaitEvent()
	If act=1
		Update()
	EndIf
	Render()
End Function

;Frame Limiter Functions:
Function FrameLimitInit(target_FPS#)
	FL\TargetFPS# = target_FPS#
	FL\TicksPerSecond = 1000 	
	FL\FrameDelay = MilliSecs()
End Function

Function SetSpeedFactor()
   FL\CurrentTicks = MilliSecs()
   FL\SpeedFactor = (FL\CurrentTicks - FL\FrameDelay) / (FL\TicksPerSecond / FL\TargetFPS)
   If FL\SpeedFactor <= 0 Then FL\SpeedFactor = 0.00000000001    
   FL\FPS = FL\TargetFPS / FL\SpeedFactor    
   FL\FrameDelay = FL\CurrentTicks
End Function


Then, for example, when Neutrons are moved, their movement per frame is based on something to do with the set speed and the frame rate. Again, very trimmed down, just to show the idea:
speed=2
n\angle = n\angle + Rand( (-180) * FL\SpeedFactor , (180) * FL\SpeedFactor )

n\x = n\x + ( (Sin(n\angle) * speed) * FL\SpeedFactor )
That was really weird, though. Here's a better example: Movement = NormalMovement * FL\SpeedFactor

And, somewhere in the updater I get the position of the little simulation speed slider: FL\TargetFPS=WB3D_GetTrackBarPos(guiSScroller)

That there sets the the target frame rate to that number. Note that this does not place any delays anywhere. Even when the speed slider is at 0, the game will render and 'think' at the same speed. (It will just think of much smaller movements). Instead of forcing the frame rate to a particular amount, this method tries to cooperate with the current frame rate. This can cause problems with stuff like collision detection, though, since if it runs too slowly objects are made to move faster, so beware.

I got that timing code from somewhere, but I forget where unfortunately. Probably either these forums or BlitzCoder, of course.

It's nice and easy; just call FrameLimitInit() to start it up, then put SetSpeedFactor() in your main loop, and you can find the necessary types / functions in the code here. (That would be the FrameRate Type and the functions I mentioned). I take absolutely no credit for that code, by the way!

Yeah my framework has a "slow motion mode" which runs at 25% (you can change that) of normal speed. Great for testing animations.

Thanks guys!

It all works perfectly now (well.. not perfectly maybe but it has nothing to do with timing anymore though :P )

Can someone convert that "Fix Your Timing!" last iteration to BMax?

EDIT: I mean in a Free manner...not for purchase.

someone already has in the Bmax thread a while back. TonyG I think. You gonna use it in your framework?

Yeah I'd like to put it in there. It's using straight deltatime atm which is definitely adequate for anything but it doesn't hurt to offer that method too.

Avoid delta time with any kind of physics simulation. The changing timesteps don't allow for repeatable results on different systems. I found render tweening a far better solution.

deltatime > tweening. Google!