Message-ID: From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: Page flipping Date: Fri, 17 Apr 1998 10:37:18 +0100 MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk 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.