Persistent Backbuffer?
BlitzMax Forums/BlitzMax Programming/Persistent Backbuffer?
| ||
| Hi. I need either one of two things: * a Back buffer that remains intact after the Flip() call and doesn't flicker * a way to draw on to the frontbuffer and not bother with Flip() The problem is that I have a large grid of small tiles and even if there has been no change or very little change in the grid, the whole thing has to be redrawn every cycle and it kills speed. Like textmode which used to be super fast, emulating it with having to redraw the grid every frame means that, arguably, old computers can do it faster. I suppose the best method would be the first, where Flip() doesn't clear the backbuffer and it's still there to modify. Can one of these be done? Thanks. :D |
| ||
| Flip does not clear anything, it only swap front and back buffers. What clear the buffer is the Cls function. Don't use Cls() and your buffer will be kept intact after the flip. (?) Just remember this : anytime you call SetGraphics with a different source, it internally calls Cls/Flip 2 times, so if you use a gui application with multiples canvas for example, anytime you switch the graphics destination for an other canvas, the new canvas will be cleared. If you just do some Graphics stuff without GUI, then this is not relevant. |
| ||
| You have no guarantee that the backbuffer contains what was rendered. So it might contain garbage. You might consider using the render2texture code which was recently posted in the programming section (and on git). So you set a texture as current target...and then draw your tiles on it if something changed. Then set target to screen again...and render that texture. Bye Ron |
| ||
| Bobysait: I know it swaps the buffers instead of copying it over which would take longer. Doesn't really help me. Without CLS every second frame contains the drawn stuff so it flashes rapidly. I have epilepsy so that's not good, and it doesn't exactly solve the problem. Derron: That sounds good but won't using a drawn texture for the screen-space not kill the pixel-perfection? I'm pretty sure even if the texture is the perfect size and you plot it to the screen perfectly it'll still have hardware filtering going on.. |
| ||
| How many tiles are you drawing per frame? DrawImage is not the most efficient... drawing from an "atlas" would be much faster. |
| ||
| Both OpenGL and DirectX have an inconsistent backbuffer after a flip -- depending on the videocard and the drivers, you can end up with either: 1) The previous frame 2) the frame from two flips ago 3) the frame from three flips ago 4) the frame from four flips ago 5) a blank screen 6) random memory garbage (Some cards/drivers use multiple frame to cycle through, if you happen to have one of those then you'll end up with a lot of flickering and 'rewinds' in the background if you depend on the content remaining). The ONLY way to guarantee what's on the screen, is to redraw it each frame. (Either sprite-by-sprite, or doing a full screengrab/redraw) |
| ||
| An "atlas", Brucey? What is that? I Googled it but apparently a trillion companies have names like "atlas programming". xlsior: So there can't even be library tweaks or gl/dx code to achieve it? |
| ||
| In the background the tiles you draw are already using textures.. so you just modify the content of a new texture when using the render2texture code. An atlas is a big image containing multiple sprites and the coordinates/dimensions of each. You then tell to only draw a portion of the big image...with x,y,w,h defined in the atlas. For each drawn image texture blitzmay' max2d needs to activate the texture...a "texture swap" which is a bit expensive. Drawing from an atlas reduces the amount of texture switches (eg drawing all tiles each after another from a tile spritesheet). An animated spritesheet is already some kind of atlas... with fixed dimensions. Bye Ron |
| ||
| xlsior: So there can't even be library tweaks or gl/dx code to achieve it? Not without redrawing it for you -- pretty sure that both then OpenGL and the DX specifications declare that the backbuffer state is undetermined after a flip. |
| ||
| xlsior: and you absolutely can't draw to the front buffer directly? Derron: That atlas thing being fast because it doesn't need "texture swaps" is good to know. But whenever I've done something like that the edges blur over to the adjacent sprite. I can't just turn filtering off because it'll look horrible on anything but a native resolution. :/ I suppose I can build a new compound image where the contained sprites' edges are surrounded with the appropriate pixels, if that makes sense... A bit tricky.. |
| ||
| this is not that hard to do - and many "sprite packers" already have this functionality to avoid bleeding. I never had issues with it (am not scaling the sprites) nor did I get complaints of the players of my game (>1.500 of each main release). Of course this does not mean that it does not happen at all - maybe it is a matter of scaling and GPU. bye Ron |
   |