Questions about: Sync, SwapScreen & Double Buffering

[SpellSword]

Questions GO!

₁₎
Are Sync & SwapScreen the same command? Different commands that do the same thing? Or similar commands that do 'almost' the same thing? (Or am I completely lost...)

₂₎
Double Buffering? Are there any tutorials specifically in how to write using it. My previous experiance with programming came from DarkBasic Classic, so this method is unfamiliar to me. (But I'd like to learn it!)

₃₎
The Help tutorials mention that "* By default, the PB Screen is double buffered." but I can't seem to find a command to change it to a different mode. Are there any? And if so, what are they?

My quest for knowledge continues!

[kevin]

Are Sync & SwapScreen the same command? Different commands that do the same thing? Or similar commands that do 'almost' the same thing? (Or am I completely lost...)

  They are the same.

Double Buffering? Are there any tutorials specifically in how to write using it. My previous experiance with programming came from DarkBasic Classic, so this method is unfamiliar to me. (But I'd like to learn it!)

     They work the same.    That is to say you always drawing to an off screen buffer (the back buffer), when we use SYNC were swapping the completed drawn image from the back (hidden) buffer with the previously visible version.

The Help tutorials mention that "* By default, the PB Screen is double buffered." but I can't seem to find a command to change it to a different mode. Are there any? And if so, what are they?

   PB automatically double buffers the screen for you, so you don't have to!   You can't change the behavior, and I can't think of a reason why you'd want to ?   If you render to the front buffer (the visible one) you'll see gfx while they're drawn.  This will flicker/flash and tear like CRAZY ! 

[SpellSword]

It sounds like I'm wrong about this. I thought there was a method that drew only to the back screen, and then copied the result to the front replacing the front image without swapping both screens.

Code Select Expand

Back      /   Front
---------------------
PlayBasic:
Screen1 <---> Screen2

????: (Ack, I thought DBC did this...)
Screen1 ----> Screen2
Is this called something else? Or does it not exist at all?

[kevin]

   Same process.   Double buffering isn't language specific.  What you're referring to is  DX behavior.  In DirectX all you do is ask it for a doubled buffered display.  The video card driver then chooses the method the card supports.   There's two methods.

   #1) Cards than can flip the front<--> back via pointer (the fastest type)

   #2) Cards that can't and therefore copy the back buffer to front (slower).   

   You should not rely upon either behavior ! 

[SpellSword]

Is there a way to tell which mode the program is currently running in?
_Example

Code Select Expand

REM Returns a 1 if DoubleBuffered, returns a 0 if not
CurrentMode = GetCurrentMode()
And, is there any way to switch which mode the program is using if the card supports both?

Edit: fixed a typo.

[kevin]

Is there a way to tell which mode the program is currently running in?

   There's probably way to detect it,  but how does that help ?

And, is there any way to switch which mode the program is using if the card supports both?

  Cards don't support both.   One or the other.

[SpellSword]

There's probably way to detect it,  but how does that help ?

If it can detect the current mode, I can build two methods for handling the graphics into the program: one for doublebuffering, and one for the other mode. Depending on which is in use, it'll run that set of functions and subroutines instead of the others.

Cards don't support both.   One or the other.

Oops, didn't realize that.  :-[Error Missing Closing Square Bracket

[kevin]

If it can detect the current mode, I can build two methods for handling the graphics into the program: one for doublebuffering, and one for the other mode. Depending on which is in use, it'll run that set of functions and subroutines instead of the others.  

  To be honest, I wouldn't bother.  While,  It'd can be useful in implementing some type of dirty rectangle based update, but doing lots of small blits is slower than large blit.


 You can detect it yourself however.. Ie.

PlayBASIC Code: [Select]

   ; When the app first executes
   mode=GetDoublebufferMethod()
   cls 0
   if Mode=0
      Print "Flips Via Pointer"
   else
      Print "Copies Back to Front"
   endif      
   
   print Mode
   Sync
   waitkey
   



Function GetDoublebufferMethod()

   ; Display program logo or something,   
   Cls rgb(30,30,30)
   Centertext getscreenwidth()/2,GetScreenHeight()*0.40,"Checking Buffer" 

   ; Show this buffer to tbe user
   Sync
   
   ; get a pixel 
   c=point(0,0)   

   ; If the pixel is zero, then this device supports flipping via pointer (Back<->Font ),
   ;  if it's one, then it always copies Back to Front. 
   mode=c<>0
      
EndFUnction mode

[SpellSword]

Cool!

Thanks for the code.