Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!pyramid!amiga!jimm
From: jimm@amiga.UUCP (James D. Mackraz)
Newsgroups: net.micro.amiga
Subject: Re: Screen(Page)Flipping (or how the west was won)
Message-ID: <1488@amiga.amiga.UUCP>
Date: Wed, 20-Aug-86 01:26:52 EDT
Article-I.D.: amiga.1488
Posted: Wed Aug 20 01:26:52 1986
Date-Received: Thu, 21-Aug-86 01:06:32 EDT
References: <913@watcgl.UUCP> <589@3comvax.UUCP>
Reply-To: jimm@homer.UUCP (Jim Mackraz)
Distribution: net
Organization: Commodore-Amiga Inc., 983 University Ave #D, Los Gatos CA 95030
Lines: 82

In article <589@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes:
>In article <913@watcgl.UUCP> fdfishman@watcgl.UUCP (Flynn D. Fishman) writes:
>>
>>I recently (yesterday) implemented a method of page flipping for
>>the experiments here.
>>
>>What I did was create two screens (I guess windows would work fine
>>also)  and then I drew one image on one screen and the other
>>image on the other screen.  It is then possible to use the
>>intuition command ScreenToFront(screen), to toggle between the two screens.
>>You can then remove the flicker using the graphics command
>>WaitBOVP(ViewPort), or WaitTOF(); before toggling the screen.
>>


>This method of page flipping was the first thing I implemented.  Yes, it
>does work, and yes it is faster than rethink display.  

Wrong. From the source (edited for clarity)

ScreenToFront(screen)
{
    struct Screen *screen;

    ...
    delinkScreen(screen);
    screen->NextScreen = IBase->FirstScreen;
    IBase->FirstScreen = screen;

    RethinkDisplay();
    ...
}

>I would bet that a ScreenToBack/Front call is as simple as a
>LoadView() call, which probably only modifies a pointer to the next screen's
>copper list. 

You Lose.  ScreenToFront/Back() must set the VPHIDE bits for obscured screens,
check whether the view is Interlaced, and do that sort of View stuff.  What
you want to do is ViewPort stuff (much simpler).

>As for faster double buffering, I have heard of two other methods so far,
>one from Rob Peck and one from well!Mitsu (thanks a lot to both of them!).
>Rob's suggestions have been to open two screens and to steal the copper
>list from one and manually stuff it into the copper registers.

Don't do that.  Rob's examples come from an era before Intuition.
Don't mess with the copper registers, or you will kiss off Intuition's View,
if it doesn't kiss you off first.

>Another
>from Rob is to make two views, as given in the examples in the tutorial
>(RKM vol. 1) on graphics.  

Don't mess with Intuition's view just to double buffer.

>Mitsu volunteered that either a VBLANK interrupt
>server can be implemented to load the copper directly or that (under
>1.1 and 1.2 beta 7 only),

???? I don't understand that.

>you can load whatever bitmap pointers you want
>into the BitMap structure and these planes will be used next frame.  How
>this works, I haven't figured it out yet.  

I think this refers to the bitmap in the ViewPort->RasInfo.  
This doesn't work, really, since those pointers are only used when
graphics is explicity told to generate/modify copper lists for the
viewport. (See next comment.)

>
>If anybody knows the solution already, please post or email!

ScrollVPort, as described in a previous posting, goes in and pokes the
copper list(s), so that they match what you have in your RasInfo.  I
think this is that fastest ViewPort operation you can do.
Note that this is a vectored library call, so that if the format of the
copper lists changes in some version, your program will benefit from
the corresponding modification to ScrollVPort.

    Jim Mackraz == Commodore/Amiga