Graphics 2D and Flip
Blitz3D Forums/Blitz3D Programming/Graphics 2D and Flip
| ||
| In creating a windowed settings program with graphics 2D, I found using Flip every update muddled up my drawing and didn't work as I thought it would , like 3D. Loading the program I text "Loading" and then when that's finished I draw (DrawImage) the interface as a bitmap. If I have a Flip, sometimes the backdrop appears, sometimes it stays on the "Loading" text, sometimes it's just black. If I don't have a Flip and just draw to the screen, it updates okay. Can someone explain a bit more about windowed 2D drawing? Does it not have doublebuffering? Should I add some delay into the main loop to free up resources for OS? Anything else I need to know? |
| ||
| The backbuffer is the current drawing buffer after a Graphics3D call but with Graphics the default buffer is set to the front buffer and if you are going to use double buffering (flip) then you need to SetBuffer BackBuffer() before you start drawing. |
| ||
| Okay. Cheers |
| ||
| Something I don't understand. I use Setbuffer Backbuffer() and draw an image. When I flip each frame, I expect the image to flicker between the drawn image and the black screen if the front buffer, but it doesn't. If I then text to the backbuffer the text still appears when flipped. With only one draw operation to the backbuffer it seems to write to the frontbuffer too ?? |
| ||
| When you flip, the backbuffer becomes the frontbuffer and vice versa. Or in other words they're switched. |
| ||
| Yes I appreciate that. But if I have on show a black screen with the text "Loading" in the middle, and draw to the backbuffer a mostly blue image I would expect a Flip to show the blue image and the black screen become backbuffer, and then the next flip to show the black screen and blue screen becomes backbuffer. What I actually have is draw the blue screen on the backbuffer and then every frame I flip, it's still there. I don't draw it again on the new backbuffer after a flip. I thought I would have to, but I don't, which confuses me. |
| ||
| I see what you mean, it looks like the contents of the backbuffer are 'added' to the current contents in the frontbuffer when you flip, as opposed to being replaced by them. |
| ||
| It is up to the driver how it implements the flip and so the state of the backbuffer after a flip is undefined and drawing MUST begin with a Cls (or equivalent outcome from renderworld due to CameraCls). Undefined - as in after a Flip the backbuffer may retain same contents as the flip if driver is implemented using a copy semantic, it may have the previous frame as in a double buffered environment or it may be n frames old if the driver is using a triple+ buffering technique. It may even be bright pink... |
| ||
| Also, are you using the CLS command to clear the backbuffer before you draw to it again? Maybe I'm not understanding your problem, but if you don't clear the contents of the backbuffer, it wil still be there when it becomes the frontbuffer with a Flip, and then becomes the backbuffer again on the next Flip. |
| ||
| At the moment I don't have a problem as it's working, and as long as other GPUs handle it the same way there's nothing to worry about. But if other GPU's draw how I'd expect, my interface is going to have ghastly flickering! Stupid me thought there'd be standard behaviours so all PCs worked the same way... @ Skidracer : You're saying that I need to work with proper Back and Front buffer management else it might do funny things on different PCs? And if I clear the buffer that'll 'initialise' it? I'll give that a whirl. |
| ||
| Clearing the buffer does "initialize" it, but remember, after your 'clear', you have to redraw everything that's going to appear (after all, it's been cleared off the screen). |
| ||
| Well, the chap managed my setup program okay without me managing flips, which was a relief. I've changed it to use proper buffer management, drawing the whole UI each frame, just in case. Fingers crossed that's the end of it ;) |
   |