Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!topaz!ll-xn!nike!oliveb!3comvax!mykes From: mykes@3comvax.UUCP (Mike Schwartz) Newsgroups: net.micro.amiga Subject: Re: Screen(Page)Flipping (or how the west was won) Message-ID: <589@3comvax.UUCP> Date: Mon, 18-Aug-86 23:44:50 EDT Article-I.D.: 3comvax.589 Posted: Mon Aug 18 23:44:50 1986 Date-Received: Wed, 20-Aug-86 01:39:20 EDT References: <913@watcgl.UUCP> Reply-To: mykes@3comvax.UUCP (Mike Schwartz) Distribution: net Organization: 3Com Corp; Mountain View, CA Lines: 108 In article <913@watcgl.UUCP> fdfishman@watcgl.UUCP (Flynn D. Fishman) writes: >Of some interest to >>From 3comvax!mykes Thu Aug 7 09:15:59 EDT 1986 >>From sun!cmcmanis Sun Aug 10 12:15:48 EDT 1986 > >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. > >Questions: >1) Does this take longer than a millisecond? >2) Does this use the Blitter chip and therefore effect the > 8520A-b chip we use for the timer? >3) Is this a good way to do things, assuming that we do not care > about the user getting access to intuition? > >P.S. there is also a ScreenToBack(screen) command and >WindowToFront(Window), WindowToBack(Window) if you want to use >Windows. Windows might also have another advantage in that you >do not have to define a window to be the entire screen but rather >only a small portion of the screen, therefore saving memory. > >There is also another method that could be used, although is is >somewhat limited if you are using a lot of colours (or shapes), >but is faster, and less of a memory hog. >You could place a different image on a different bit plane, and then >change the colour map. >i.e. lets say you have to black and white images. >1) you would define a two bitplane window >2) Set Draw Mode to COMPLEMENT{XOR} (i.e. SetDrMd(RastPort, COMPLEMENT) ) >3) Set the pen colour to 1 (i.e. SetAPen(RastPort, 1) >4) Draw the first image >5) Set the pen colour to 2 (i.e. SetAPen(RastPort, 2) >6) Draw the second image >7) then to flash the image one, you would set Colour 1 AND colour 3 > to white (i.e. SetRGB4(ViewPort, 1, 15, 15, 15); > SetRGB4(ViewPort, 3, 15, 15, 15); > and colour 2 to Black (SetRGB4(ViewPort, 2, 0, 0, 0); > The reason you also set colour 3 to white is since where ever > both images intersect the colour will be 3 > i.e. colour 1 = %01, 2 = %10 so 1 XOR 2 = (%10 XOR %01 = %11) = 3 >8) to show the second image you would turn colour 2 and colour 3 white > and colour 1 black > >This will work with up to 4 black and white (or red and green) images in >Hi-res mode and 5 (b&w) images in low-res mode. And would also work for >two 4 colour images in both modes, however the colour maps get >more complex. > >Again I would ask that anybody, and everybody please comment on >these two methods, in any way they feel like. > >-- > > FDFISHMAN (Flynn D. Fishman) @ WATCGL > >UUCP : ...!{decvax|ihnp4|clyde|allegra|utzoo}!watmath!watcgl!fdfishman >ARPA : fdfishman%watcgl%waterloo.csnet@csnet-relay.arpa >CSNET : fdfishman%watcgl@waterloo.csnet >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >This Cutsie saying space left intentionally left blank until such a time as > 1) The above mentioned user can think of a cutsie saying > 2) The above mentioned user with the aid of some friends can think of a > cutsie saying. >or 3) Sufficient time has passed such that plagerism of someone else's cutsie > saying would not be noticed by many. >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This method of page flipping was the first thing I implemented. Yes, it does work, and yes it is faster than rethink display. However, it fails to meet one requirement of what I think of as a well behaved Amiga program. The main failing of this method is that it does not work well with ScreenToBack() calls if the workbench screen is open, and ScreenToFront() calls prevent you from arranging multiple applications at the same time. As to your questions, I can venture a pure somewhat educated guess. 1) 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. I am reasonably sure that these screento... calls also do a WaitTOF() as well, so any other WaitTOF() calls may be redundant. If they are redundant (again, this is a guess, I should step through ScreenToFront() with WACK). 2) The RKM indicates that the 8520 is driven by an interrupt handler (a level 2 interrupt is handled by source #3 of the 15 interrupt sources demultiplexed by the ROM routines). 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. Another from Rob is to make two views, as given in the examples in the tutorial (RKM vol. 1) on graphics. 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), 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 have some of these methods without success. I will get the answer with WACK in the next few days and will post my solution. If anybody knows the solution already, please post or email!