Your going to hate me

I'm going to bring up that timing issue again.

Ok i know there is a crazy amount of posts about delta timing and tweening. but thats the point, ive looked though most of the posts and had coments from all angles about which is best and problems etc.

now if there is anyone out there that has a dead simple example of rock solid timing code, please could you post it here and in the archive!

I get the tweening example in the code archive by mark but in many of the posts people seem to think that delta timing is best.

if someone posts a newbie proof example we can put this subject to rest.

If you can live with the minor niggles involved with tweening, it really is the superior ,ethod, from the perspective of ease of coding and quality of results.

so marks example is best?

I use locked game logic code (usually 90 updates per second or so) and then render whenever it can. This is blitz3D not bmax.

.Rob: thats gone right over my head?

I believe that tweening is not only a solution for time-based movement, but also a method to reduce the strain that is put on the pc.
You calculate two frames, and then render the steps in between using CaptureWorld and RenderWorld tween#.
With this method, you don't need to calculate frames as often.

And as far as I got it, delta-timing is based on the amount of time passed. Every frame, you check Millisecs() to see how much time has passed/elapsed. The movement is multiplied with this number of milliseconds passed:

Graphics3D 800, 600, 0, 2
SetBuffer BackBuffer()

camera = CreateCamera()
MoveEntity camera, 0, 0, -15

cube = CreateCube()
MoveEntity cube, -10, 0, 0

now = -1

Repeat

	old = now
	now = MilliSecs()
	If old = -1 Then old = now

	;time passed	
	elaps# = (now - old)
	
	MoveEntity cube, 0.01 * elaps, 0, 0
	
	RenderWorld
	
	Flip	

Until KeyHit(1)

End

I'll post code when I get home! It'll make more sense as code!

thanks to you both im hoping to choose a way of doing this and stick to it.

Pete...

Long time since I used B3D, but Mark's code, ripped from the Castle Demo was what I used (no idea if this is the same as the code in the archives), and it ran perfectly for me. I also tried delta time on the same project. Problems included:

1) 'Lurching' - the assumption that this frame will take the same length of time as the last is not always a good one
2) Physics is a no-no. I was writing a crazy golf game, and with different time-steps using it on different machines, the distance travelled up a slope by the ball varied wildly. You would need to have a fixed time steps for the physics, giving extra complication.
3) The pain of adding all those *dt's

Nomen luni : Ive heard alot of coments like thoughs but it must work well for some. i think ill go for whatever gives me the most consitant performance on my 2 machines.

id still like to see what code people are using?

Graphics3D 640,480,32,2

camera = CreateCamera()
MoveEntity camera,0,0,-5
cube = CreateCube()
light = CreateLight()
TurnEntity light,45,45,0

; Set the game speed to 90 updates per second.
; Change this to make the game run faster or slower
; this is also the max fps
ups=90
period=1000/ups
time=MilliSecs()-period

Repeat
	; Timing code
	Repeat
	elapsed=MilliSecs()-time
	Until elapsed
	tic=elapsed/period
	For k=1 To tic
		time=time+period
		ticks=ticks+1

		; =========================================
		; Game logic loop
		
		TurnEntity cube,.5,1,.6
		

		
		UpdateWorld	; if you're using collisions or animation
		
		; End of game logic loop
		; =========================================
		
	Next
	
	RenderWorld
	VWait
	Flip False
	
Until KeyHit(1)

It's so true that vwait() is not something people use much... But it's really effective in this case.

But what's really dumb about vwait() is that your game / program will still take 100% of CPU even if it's waiting for a vblank, which is incredibly inefficient. I'm surprized that it hasn't been made greener than this, as it's wasting watts and heating up the core at 100% usage.

thanks rob. i will give your code a go. didnt think about doing it like that.

I agree with _33 about the waste of energy. But probably this is caused by the 86 design that had a bad VSync implementation since the dawn of PCs. Unlike the hardware-Vsync-interrupt of eg. a motorola 68K, the vsync on a Intel chip must be polled by the kernel - as far as I know. (?)