NewsForumsCodeLogsGallerySpecsSearch

millisec vs waittimer problem

Blitz3D Forums/Blitz3D Programming/millisec vs waittimer problem

Fernhout(Posted 2010) [#1]
I have this code and it work good.
Graphics 640,480,16,2

;Make some globals works better

Global Ani_Spider
Global Next_Frame
Global Fram_Number
Global start_frame
Global frameTimer=CreateTimer(20)
Global key$,pos

Ani_Spider = LoadAnimImage ("redspiderwalking.bmp",96,96,0,64)
MaskImage Ani_Spider,255,0,255

ClsColor 0,0,255
SetBuffer BackBuffer()
While Not KeyDown(1)
	WaitTimer (frameTimer)
		
		DrawImage Ani_Spider,GraphicsWidth()/2-ImageWidth(Ani_Spider)/2,GraphicsHeight()/2-ImageWidth(Ani_Spider)/2,Fram_Number+start_frame
		Next_Frame=MilliSecs()+50
		key$=Chr(GetKey())
		DebugLog key$
		pos = Instr("12369874",key$)
		Select pos
			Case 1
				start_frame = 40
			Case 2
				start_frame = 32
			Case 3
				start_frame = 24
			Case 4
				start_frame = 16
			Case 5
				start_frame = 8
			Case 6
				start_frame = 0
			Case 7
				start_frame = 56
			Case 8
				start_frame = 48
		End Select
		Fram_Number=Fram_Number+1
		If Fram_Number>7 Then Fram_Number=0
		Flip
	Cls
	
Wend


But when i use this
Graphics 640,480,16,2

;Make some globals works better

Global Ani_Spider
Global Next_Frame
Global Fram_Number
Global start_frame
Global key$,pos

Ani_Spider = LoadAnimImage ("redspiderwalking.bmp",96,96,0,64)
MaskImage Ani_Spider,255,0,255

ClsColor 0,0,255
SetBuffer BackBuffer()
While Not KeyDown(1)
	If MilliSecs()>Next_Frame 
	
		DrawImage Ani_Spider,GraphicsWidth()/2-ImageWidth(Ani_Spider)/2,GraphicsHeight()/2-ImageWidth(Ani_Spider)/2,Fram_Number+start_frame
		Next_Frame=MilliSecs()+50
		key$=Chr(GetKey())
		DebugLog key$
		pos = Instr("12369874",key$)
		Select pos
			Case 1
				start_frame = 40
			Case 2
				start_frame = 32
			Case 3
				start_frame = 24
			Case 4
				start_frame = 16
			Case 5
				start_frame = 8
			Case 6
				start_frame = 0
			Case 7
				start_frame = 56
			Case 8
				start_frame = 48
		End Select
		Fram_Number=Fram_Number+1
		If Fram_Number>7 Then Fram_Number=0
		Flip
	EndIf
	Cls
	
Wend


The program is not working on the same way.

The second option use millisec, but some times its take 1000 millisec before the next fram come up, and then 4 frames are ok. Then again a long time nothing.

this is a simple example but my reason for this is. When i want to do a good frame rate and stil need time to do other things in the program. Its easyer to use the counting of the millisecs.

If i use waittimer then the program is halting until its time for the next frame. And that i can not use.

Why is the millisec code going so slow.


Ross C(Posted 2010) [#2]
I would disable the vsync for flip:

Flip 0

This will stop the program waiting for a free vertical sync before proceeding. See if it helps?


Fernhout(Posted 2010) [#3]
Noy its not working. I don't no why but the result is the same. Any other reason why its of time.


H&K(Posted 2010) [#4]
I don't own B3d so cannot test, and cannot "see" why it should be wrong.
However the CLS should be inside the If loop. ATM you are going "IF not next frame cls, if not next frame cls"
Cls should really be called as often as the drawing loop. Also Case 8 has 8 if comparisons b4 it is run (Its how case works) so possibly an array lookup table instead.

Neither of these optimisations would account for a second delay update tho


lo-tekk(Posted 2010) [#5]
I wouldn't put the Flip inside the if statement. Try this instead:


Here's the image:


Cheers lo-tekk


H&K(Posted 2010) [#6]
Lol, I would say do exactly the opposite of that.

This isn't a tween loop he has set-up, its a fixed logic/update/move loop.

Why Clearing flipping and redrawing the exact same display. Stick them inside the if endif and only draw or cls or flip when the scene has changed


Fernhout(Posted 2010) [#7]
to H&K
In the example i give it a little bit wrong. Your are right the CLS has to go inside the loop. It was a wrong setting from me.

But i did give this code on purpes becouse the timing is way off. It is not the right way of doing this. i know. But when i was writig this little program i saw what is was doing wrong but stil the timing has to work and that did'nt.

to lo-tekk
Your way works fine. It is the way of doing. I tested it and its good. Then the other questing stay why is the way i giving so wrong that the timing is way off.

I wil give the awnser tommorow. There is a simple explanation for it. But its a little bit tricky to see.


Axel Wheeler(Posted 2010) [#8]
The general cause of the problem is that your method does not free up any cycles for the processor to do anything else. I stuck a Delay(1) after the EndIf and it works fine.

I was amazed however at how totally this program locks resources (without the Delay(1)). Even Task Manager slowed to a crawl; that's unusual.

I suspect that the reason it works with the timer (your first version) is that timer is also releasing cycles behind the scenes.

Keep in mind that I couldn't test the functionality of the program itself without the .bmp file, but it doesn't hog resources or lock up when the Delay(1) is present and I hit the various number keys.

-Pete


Fernhout(Posted 2010) [#9]
To axel wheeler.
Your are very close to the awnser. And your idea of the cycles is right. There is the problem. But because of the cls command the cycles are going way of. the if then is doing only once every 50 cycles.

The complete time to execute the whole if /endif is precies 25 cycles. and a screen refresh is done every 16.6 cycles,(60 hz) so to write to the screen is at the third screen cycle. witch is 49.8 ( oops a little bit off) so the screen update done but not worked out. this wil be done ate the fourth screen cycle. but then the CLS command is comming in the way. The screen hold on to the last frame couse the new frame is not there. its a window problem and not blitz. Even the cls command is done, the spider is stil on the screen. But if you look close to the code the screen has to blank out but it does'nt. It's all in when you start the program. thats why the program is overstepping some frames.

Your delay(1) was just that what the program needed to go in line with the system timer.

Thats why lo-tekk did the rewritting to make it happend that de drawimage was outside the if / endif then you can mis a screen cycle without seeing it.

Its that little thing what can screw up your program and drive you nuts.

For me it was an exedent to discover this. Normaly i do not write the code like this but for some reason i did it and then i discover this behavior.

I had also a long time to find out what wend wrong.

Good done Alex

Thanks people for looking in this problem. Hope it make programmaming better for all of use.