Buffers

Blitz3D Forums/Blitz3D Beginners Area/Buffers

Kirkkaf13(Posted 2010) [#1]
Hi everyone,

I have been reading through the the Blitz3D manual, when it came to Front and Back Buffers I didn't quite understand how they work.

Anyone got a good explaination?

- Kirk.


Yasha(Posted 2010) [#2]
The front buffer is the area of memory that DirectX will draw to the screen - making it your "output" area. However, you don't have any control over this: the computer will update the screen at whatever rate it's been set to do so, and DirectX will pass the front buffer to it once per update whether you like it or not. This means the front buffer isn't that useful for drawing on directly, as you might be in the middle of an operation when the screen updates, or some other similar problem.

The back buffer is a general purpose drawing area that is mainly notable because of the Flip command: this allows you to quickly switch it for the front buffer so that once you're done drawing to the back buffer, the contents of it can be displayed on the screen (what happens to the contents of the old front buffer - switched to back buffer, blanked, whatever - varies from machine to machine, so don't rely on it for anything). Generally the screen is drawn to the back buffer and then flipped to the front buffer once per frame.

While there are some tasks that can be achieved adequately using only the front buffer, most people don't bother as on modern systems there is no overhead for double-buffering - it's a very old technique. You also don't have a choice if you want to use 3D graphics: the 3D scene can only be rendered to the back buffer (or to texture buffers, using extensions, but still not the front buffer).

Generally you won't ever have to think about it again as the back buffer ought to have a complete copy of what you're about to display anyway, if for some reason you need to grab an area of the screen. The real reason it's in there is to allow you a measure of control over the rate and nature of screen updates, rather than because anyone expects you to draw to it.


Kirkkaf13(Posted 2010) [#3]
Thanks for taking the time to write this Yasha.


Kirkkaf13(Posted 2010) [#4]
Here is my first program on moving around the screen.




Matty(Posted 2010) [#5]
That is fine, nothing wrong there.

However, my usual method, and what is probably used by many others is to use a slightly different structure:

repeat

cls 
update all movement etc & game logic
draw everything for that frame

flip 
until ...



Kirkkaf13(Posted 2010) [#6]
Ahh I never thought about it that way, seems alot easier actualy.

Is the basic structure of a 2D game the same as 3D expect for cameras, meshers, textures, and third axsis?


Matty(Posted 2010) [#7]
Very similar.


Kirkkaf13(Posted 2010) [#8]
Matty I just recreated the program using 'repeat', 'until', why would it make any difference later on throughout the game (if it became one).




Gabriel(Posted 2010) [#9]
There is no practical difference between Repeat..Until and While..Wend except that Repeat..Until checks the condition at the end of the loop and While..Wend checks it at the beginning of the loop. So generally, you use Repeat..Until for loops which must always run at least once, and While..Wend for loops which may not be required to run at all.


Kirkkaf13(Posted 2010) [#10]
Makes sense cheers Gabriel.


PowerPC603(Posted 2010) [#11]
It's also common practice to place the Flip command at the end of the loop.

First use CLS to clear the buffer you're gonna draw on (the backbuffer mostly), then process all your movements, then perhaps print some text/images to the screen and finally FLIP the buffers (flip the backbuffer onto the screen) when all drawing has finished.

It doesn't make much sense flipping the buffers when you didn't do any drawing first.

Also the Color command could be inside the function, instead of the main loop.
I always use the color command right before any drawing, to prevent using the wrong color that could be set anywhere else in your program.
Color 255, 0, 0 : Oval x, y, 10, 10

Note the ":", this is used as a command-separator.
This means there are actually 2 different commands on a single line.
It's mostly used for readability, where 2 (or more) commands are needed to do a single thing (draw a red oval in this case).
The above code sets the drawing color to red and draws the oval.


jfk EO-11110(Posted 2010) [#12]
One more word about Flip. It takes a parameter. Flip 1 wlll wait for a VSync, Flip 0 won't. What does that mean? VSync means the system signals that it just updated the screen (eg. at 60 Hz rate). Usually you want prevent Flipping the buffers during the peripheral screen update, because this may result in the first half of the screen taken from the old frontbuffer and the 2nd part from the new frontbuffer. So Flip 1 is normally used.

Unfort. some Hardware doesn't really wait for the Vsync, regardless of Flip 1. In these cases you may alternatively try VWAIT:FLIP 0 instead. In a serious game both should be tested, by duration measurement (millisecs()) to find out if there is a working VSync on the machine. If none can be found you probably have to use a fixed framerate, eg. 16.67 ms or in other words 60 Hz..