Mail Archives: djgpp/1998/04/17/05:38:39
Ryan Twitchell writes:
> I've looked through some of the examples that came with Allegro, but
> I still don't understand how page flipping works. I know that it
> involves the virtual screen and switching between different areas of
> it, but the code in ex9 has me confused.
On a 1 meg SVGA card in 640x480 mode, Allegro will typically give you
either a 1024x1024 or perhaps a 640x1638 virtual screen. Normally you
just draw into the top left 640x480 portion of this, but for a page
flipping system you would partition the larger image surface into two
screen areas, eg:
(0,0)----(640,0)----(1024,0)
| | |
| page 1 | |
| | |
(0,480)--(640,480) |
| | |
| page 2 | |
| | |
(0,960)--(640,960) |
| |
| offscreen vram |
| |
(0,1024)------------(1024,1024)
(proportional fonts not recommended :-)
To set such a mode, you would pass 640x960 as the virtual width and
height for set_gfx_mode(), to indicate how large you need the virtual
screen to be: Allegro will typically round that up to an even larger
surface (producing the offscreen vram area in this diagram), but this
depends on the hardware: you can't be sure of getting any more space
than you explicitly request when you set the mode.
To display a page flipping animation, you draw into one of those page
areas, while the monitor is displaying the other. When the new image
is complete, you scroll the screen to display the other page, which
you just finished drawing, and then start to prepare a new image in
the first page, which is no longer visible now that you have scrolled
away from it. This provides flicker-free animation because the user
can never see a page while you are in the process of drawing onto it,
and avoids the expensive memory->screen blit that is needed if you
do this buffering with a system memory bitmap.
The problem is that your drawing code must be able to switch back
and forth between two different regions of the screen. You could do
this by just adding 480 onto all your y coordinates when you are
drawing into the second page, but that is a pain because it means
adding this offset every single time you call a graphics function,
and there are various other nuisances like having to change the
screen clipping rectangle whenever you switch from one page to the
other. A more elegant solution is to create a sub-bitmap object that
will only address one of these page regions, and then draw onto
this sub-bitmap rather than directly to the screen. Each sub-bitmap
has a unique clipping region, and the coordinates are local to the
origin of the sub-bitmap: this is done using the lookup tables that
are already a part of any bitmap access, so it is more efficient than
explicitly adding the offset yourself. The sub-bitmaps are just an
alternative way of addressing a particular part of a larger bitmap,
which can make the code easier to read and slightly faster.
Shawn Hargreaves.
- Raw text -