Game Development Reference
In-Depth Information
So, the y axis is pointing downward because of the memory layout of the pixel colors in VRAM.
This is actually a sort of legacy inherited from the early days of computer graphics. Monitors
would update the color of each pixel on the screen, starting at the top-left corner, moving to the
right, and tracing back to the left on the next line, until they reached the bottom of the screen. It
was convenient to have the VRAM contents laid out in a manner that eased the transfer of the
color information to the monitor.
Note
If we had full access to the framebuffer, we could use the preceding equation to write a
full-fledged graphics library to draw pixels, lines, rectangles, images loaded to memory, and so on.
Modern operating systems do not grant us direct access to the framebuffer for various reasons.
Instead, we usually draw to a memory area that is then copied to the actual framebuffer by the
operating system. The general concepts hold true in this case as well, though! If you are interested
in how to do these low-level things efficiently, search the Web for a guy called Bresenham and his
line-and-circle-drawing algorithms.
Vsync and Double-Buffering
Now, if you remember the paragraph about refresh rates, you might have noticed that those
rates seem rather low and that we might be able to write to the framebuffer faster than the
display will refresh. That can happen. Even worse, we don't know when the display is grabbing
its latest frame copy from VRAM, which could be a problem if we're in the middle of drawing
something. In this case, the display will then show parts of the old framebuffer content and parts
of the new state, which is an undesirable situation. You can see that effect in many PC games
where it expresses itself as tearing (in which the screen simultaneously shows parts of the last
frame and parts of the new frame).
The first part of the solution to this problem is called
double-buffering
. Instead of having a single
framebuffer, the graphics processing unit (GPU) actually manages two of them: a front buffer
and a back buffer. The front buffer, from which the pixel colors will be fetched, is available to the
display, and the back buffer is available to draw our next frame while the display happily feeds
off the front buffer. When we finish drawing our current frame, we tell the GPU to switch the two
buffers with each other, which usually means just swapping the address of the front and back
buffer. In graphics programming literature, and in API documentation, you may find the terms
page flip
and
buffer swap
, which refer to this process.
Double-buffering alone does not solve the problem entirely, though: the swap can still happen
while the screen is in the middle of refreshing its content. That's where
vertical synchronization
(also known as
vsync
) comes into play. When we call the buffer swap method, the GPU will
block until the display signals that it has finished its current refresh. If that happens, the GPU can
safely swap the buffer addresses and all will be well.
Luckily, we barely need to care about these pesky details nowadays. VRAM and the details
of double-buffering and vsyncing are securely hidden from us so that we cannot wreak havoc
with them. Instead, we are provided with a set of APIs that usually limit us to manipulating the
contents of our application window. Some of these APIs, such as OpenGL ES, expose hardware
acceleration, which basically does nothing more than manipulate VRAM with specialized circuits
