with flip() without flip() ?

Blitz3D Forums/Blitz3D Programming/with flip() without flip() ?

RemiD

(Posted 2015) [#1]

Hello,

For those who have taken a look at the blitz3d source, can you please explain what is the difference between drawing on the backbuffer then using flip() and drawing on the backbuffer then copying the results (with copyrect) to the frontbuffer ?

In theory it should produce the same result on the screen, but in practice no... Why ?
see the difference :

Graphics3D(800,600,32,2)

Camera = CreateCamera()
CameraRange(Camera,0.1,100)
CameraClsColor(Camera,000,000,000)

ThingMesh = CreateCube()
ScaleMesh(ThingMesh,1.0/2,1.0/2,1.0/2)
EntityColor(ThingMesh,Rand(025,255),Rand(025,255),Rand(025,255))

DLight = CreateLight(1)
LightColor(DLight,192,192,192)
PositionEntity(DLight,50,1000,-1000,True)
RotateEntity(DLight,45,0,0,True)

AmbientLight(064,064,064)

PositionEntity(Camera,0,1.65,-5,True)

MainLoopTimer = CreateTimer(30)

While( KeyDown(1)<>1 )

 MainLoopMsStart% = MilliSecs()

 TurnEntity(ThingMesh,0,1,0)

 If( KeyDown(2)=1 )
  WireFrame(True)
 Else
  WireFrame(False)
 EndIf

 SetBuffer(BackBuffer())
 RenderWorld()

 Color(255,255,255)
 Text(0,0,"MainLoopMsTime = "+MainLoopMsTime)

 ;WaitTimer(MainLoopTimer):Flip() ;what we usually use...
 WaitTimer(MainLoopTimer):CopyRect(0,0,GraphicsWidth(),GraphicsHeight(),0,0,BackBuffer(),FrontBuffer()) ;what we could use...

 MainLoopMsTime% = MilliSecs() - MainLoopMsStart

Wend

End()

Thanks,

Rick Nasher

(Posted 2015) [#2]

Isn't this because using flip only the physical pointer to the page in memory moves, while for copyrect the buffer needs to be copied bit by bit to another?

RemiD

(Posted 2015) [#3]

My question was more why the result displayed on screen is not the same (with copyrect to frontbuffer it seems jerky...) (but the mstime it takes to calculate/render and consequently the fps are the same)

Omnicode

(Posted 2015) [#4]

Idk if it helps at all but I swapped some stuff around and got some more noticeable timing differences when it came to loop time when using flip(1) and not using flip(1).

I intentionally put the Waitimer() before calling upon a reference Millisecs(), putting it after seems to only create the 55-60 range without any difference. Whereas Flip(1) counts up through (0-15), to satisfy vwait and without calling Flip(1) stays at (0-1).

At Default Flip(var=1), If never called Flip(var=0) ; Setting the values proves this, it will create the (0-1) range for both if set to Flip(0). Yet, Flip(0 OR 1) still appears smoother than CopyRect().

Graphics3D(800,600,32,2)

Camera = CreateCamera()
CameraRange(Camera,0.1,100)
CameraClsColor(Camera,000,000,000)

ThingMesh = CreateCube()
ScaleMesh(ThingMesh,1.0/2,1.0/2,1.0/2)
EntityColor(ThingMesh,Rand(025,255),Rand(025,255),Rand(025,255))

DLight = CreateLight(1)
LightColor(DLight,192,192,192)
PositionEntity(DLight,50,1000,-1000,True)
RotateEntity(DLight,45,0,0,True)

AmbientLight(064,064,064)

PositionEntity(Camera,0,1.65,-5,True)

MainLoopTimer = CreateTimer(15)
Toggle_Flip=False
While( KeyDown(1)<>1 )
	WaitTimer(MainLoopTimer)
	MainLoopMsStart% = MilliSecs()
	
	TurnEntity(ThingMesh,0,1,0)
	
	If( KeyDown(2)=1 )
		WireFrame(True)
	Else
		WireFrame(False)
	EndIf
	
	If KeyHit(57)=True Then Toggle_Flip=1-Toggle_Flip
	
	SetBuffer(BackBuffer())
	RenderWorld()
	
	Color(255,255,255)
	Text(0,0,"MainLoopMsTime = "+MainLoopMsTime%)
	Text(0,10,"Press space to toggle Flip:"+Toggle_Flip)
	
	If Toggle_Flip=True
		Flip() ;what we usually use...
	Else
		CopyRect(0,0,GraphicsWidth(),GraphicsHeight(),0,0,BackBuffer(),FrontBuffer()) ;what we could use...
	EndIf
	
	MainLoopMsTime% = MilliSecs() - MainLoopMsStart
	
Wend

End()

Tried using banks to help speed up the process, nothing seems to eliminate the jerky attitude to going without calling Flip().
Tried only writing pixels that weren't black ($FF000000), was faster but still didn't eliminate jerky-ness.
Flip() seems pretty hard coded into how Blitz3d flows that it may be impossible to find a suitable sub. Is there really a case that calls for it to not be used?

I'm gonna go with what Rick said above.

I found this article about it, seems to explain it quite well.
https://docs.oracle.com/javase/tutorial/extra/fullscreen/doublebuf.html

RemiD

(Posted 2015) [#5]

Flip() seems pretty hard coded into how Blitz3d flows that it may be impossible to find a suitable sub. Is there really a case that calls for it to not be used

No this was just by curiosity, to understand why not using flip makes it seems jerky.

I have also tried to add VWait() before Copyrect() but this seems even worse...

Anyway, we will use flip() !

Bobysait

(Posted 2015) [#6]

Anything you do on frontbuffer is drawn to the frontbuffer (Sorry if it seems obvious, but as you asked ... there is no answer that can resume it easier ^_^).

It means that : it's rendered on screen at the time you draw it if the scan line is ready. (it does not care about synchronisation/vertical sync, it does not care of frame being complete/safe it does not care about anything ... but the scan line.)

A copyrect will of course copy the pixels at the same time they are drawn on screen when the scan line is ready.
It also means it can draw on arbitrary frames, like at time 2 ms on a frame, and on the next loop at time 16 ms, it may/will result in a dirty and laggy render because it does not wait the synchronisation and render each frame at a different rate.

Adding a VWait can't solve the problem as the problem happens at the very moment you draw something. A VWait will just stop the loop before the next one.

With a Flip (false), the dirty thing happening is mostly due to the fact your drawing is asked to be drawned while the screen is not ready : the scan line is not synchronized with the screen-> if you draw a rect, an image or any kind of buffer, in the middle of the screen while the scan line was around the midle, it will result in a portion of the rect/buffer/whatever you draw, drawn, and the other portionnot rendered at all. It is also noticeable in 3D rendering at a high framerate and fast movements. You will see the scan line in the screen splitting your scene in two parts ; the previous frame on top, and the "current frame" on the bottom.

To resume : Use the ScanLine() function to check if your screen is ready to draw what you want.
But to make things more clear (clearer ?) the frontbuffer is not really intended to be used for rendering anything.
It's mostly a backward compatibility with old stuff, like text-based applications/games (or eventually threaded stuff ...)
it has been almost completely replaced by double/triple-buffering (BackBuffer/RenderBuffer + SwapBuffer)

RemiD

(Posted 2015) [#7]

@Bobysait>>Ok, thanks for the clarifications.