"Buffer Not Locked" error

[Tracy]

Hi there.

I've got a quick question about drawing maps. Here's a section of code from my game:

Code Select Expand


LockBuffer
   CaptureToScene
  `Cls 0

   ClsScene

   RenderToImage screen
   `Cls 0
   CaptureDepth 200
   For i = 2 To 3
   
    DrawMap thismap,i,0,0
   
   Next i

   DrawOrderedSprites
     
     DrawCamera 1
 


      RenderToScreen
      DrawImage screen,0,0,1  
UnLockBuffer


It works great- as long as the maps are set to transparent mode. If I use the LevelSolid command for one of the maps, the game won't even load and I get an error about the buffer not being locked. What, exactly, does that mean? As you can see from my code above the buffer IS locked, or should be. Am I missing something?

Thanks.

-Tracy

[Big C.]

Hi Tracy,

I want to attempt to help you, but I don't know 100%, whether I am right...

firstly, I would rewrite your section of code as follows..

Code Select Expand


  CaptureToScene
 `Cls 0

  ClsScene

  RenderToImage screen
  `Cls 0
  CaptureDepth 200

  For i = 2 To 3
 
   DrawMap thismap,i,0,0
 
  Next i

  DrawOrderedSprites
   
  DrawCamera 1

  RenderToScreen

LockBuffer
   DrawImage screen,0,0,1;<--- I think, here is your output draw to screen
UnLockBuffer


because with the command RenderToImage you will make play basic direct it's drawing operations like Text,Images,Sprites etc to your Image screen rather than the screen. With the later command RenderToScreen you switch back to Screen output. If I have understood the help of Lockbuffer and UnlockBuffer correctly, then the commands affect only the current graphics buffer (= the BACK Screen).

secondly, if you want to use the LevelSolid command then you should use it before lock/unlock the buffer, because its not really a drawing command

Please, that should be confirmed by Kevin or somebody else...  

Big C.

[kevin]

This is an error with PB1.30  (and perhaps PB1.28) and occurs when drawing solid maps, it's fixed in PB1.31.

As you can see from my code above the buffer IS locked, or should be. Am I missing something?

What LockBUffer and UNLockBuffer do is they enable user management of buffer locking.  Which overrides each drawing commands native lock/unlock process.

 The problem here was Map drawing routines could attempt to release the buffer twice.     A NO NO.. but as i said it's fixed in PB1.31.

[Tracy]

This is an error with PB1.30  (and perhaps PB1.28) and occurs when drawing solid maps, it's fixed in PB1.31.
What LockBUffer and UNLockBuffer do is they enable user management of buffer locking.  Which overrides each drawing commands native lock/unlock process.

  The problem here was Map drawing routines could attempt to release the buffer twice.     A NO NO.. but as i said it's fixed in PB1.31.

Cool. I thought it might be a bug.

Big C., thanks for the tip on the buffer. I'll impliment it (Kevin, this is where you step in and give Big C and I the correct info if he's got it wrong above) and see if it speeds things up at all.

Cheers to both of you.

-Tracy

[kevin]

 Here's PlayBasic V1.31 Update (login required)


 All  buffers (the screen and image)  that are stored  in video memory (not FX buffers) require lock/unlocking and when your going to manually drawing a  cluster of gfx items to that surface.   Except, when you are capturing to those gfx items to either the scene or a world buffer.

Given your example, the locking/unlock around the capturetoscrene/drawcamera isn't really required.  As the gfx items are being added to the scene list.  Not actually drawn at that time.     The DrawCamera command manages the buffer locking/unlocking internally for you.  

So Big C's code is pretty much correct.

PlayBASIC Code: [Select]

   CaptureToScene

   ClsScene

   CaptureDepth 200
   For i = 2 To 3
     CaptureDepth 200+lp  ; ensure both layers are a diffent Z depths
     
      DrawMap thismap,i,0,0 
    
   Next i

   DrawOrderedSprites
     
   DrawCamera 1
  

   RenderToScreen
Lockbuffer
      DrawImage screen,0,0,1  
UnLockBuffer

[Tracy]

And my hat's off to both of you. Frankly, eliminating the cls step in drawing the maps sped things up greatly, and along with locking the buffer in the correct place, the alpha addition for the sprites is now working very smoothly, and looks as good as I'd hoped.

Thanks much.

[kevin]

Well that goes back to eliminating overdraw where possible.   As by default cameras perform a CLS for you, just prior to render the scene. While you can can actually turn this on/off.  But if it's on, there's no real point clearing the screen manually.  Beside wasting valuable drawing time.

[Big C.]

Tracy,

with pleasure happen, I am pleased if I can help with my restricted knowledge

I am tense as your result in the future will look...  ;)

Kevin, many thanks for your explanation. If I have understood you correctly, I can use lock/unlock for drawing on Images too in order to achieve a speed advantage, right?

Big C.

[kevin]

Kevin, many thanks for your explanation. If I have understood you correctly, I can use lock/unlock for drawing on Images too in order to achieve a speed advantage, right?

Yes,  providing the Image is a Normal image (not an effects buffer) Then manually locking/unlocking the buffers can give some speed ups.

[Big C.]

Many thanks Kevin,

I find, that is an important hint... From the help files for the commands Lock-/UnlockBuffer I could not have interpreted that.  :(

Maybe you might complement the help correspondingly (or take it on your todo-List)?  :)

thx Big C.

[kevin]

Ok, i've revised the LockBuffer help a little.  Just to make sure that the points above are made.