Your going to hate me

Blitz3D Forums/Blitz3D Beginners Area/Your going to hate me

Pete Carter(Posted 2007) [#1]
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.


Who was John Galt?(Posted 2007) [#2]
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.


Pete Carter(Posted 2007) [#3]
so marks example is best?


Rob Farley(Posted 2007) [#4]
I use locked game logic code (usually 90 updates per second or so) and then render whenever it can. This is blitz3D not bmax.


Pete Carter(Posted 2007) [#5]
.Rob: thats gone right over my head?


b32(Posted 2007) [#6]
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:



Rob Farley(Posted 2007) [#7]
I'll post code when I get home! It'll make more sense as code!


Pete Carter(Posted 2007) [#8]
thanks to you both im hoping to choose a way of doing this and stick to it.


Who was John Galt?(Posted 2007) [#9]
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


Pete Carter(Posted 2007) [#10]
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?


Rob Farley(Posted 2007) [#11]
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)



_33(Posted 2007) [#12]
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.


Pete Carter(Posted 2007) [#13]
thanks rob. i will give your code a go. didnt think about doing it like that.


jfk EO-11110(Posted 2007) [#14]
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. (?)