fdfishman@watcgl.UUCP (Flynn D. Fishman) (08/11/86)
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. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mykes@3comvax.UUCP (Mike Schwartz) (08/19/86)
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!
jimm@amiga.UUCP (James D. Mackraz) (08/20/86)
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