Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!ruuinf!praxis!njluurin From: njluurin@cs.ruu.nl (Niek Luuring) Newsgroups: comp.sys.amiga.tech Subject: Re: Scrolling in 512K - Advice? Keywords: amiga 512k scrolling bitmap graphics Message-ID: <4364@ruuinf.cs.ruu.nl> Date: 21 Nov 90 14:33:46 GMT References: <1149@xroads.UUCP> <2259@exodus.Eng.Sun.COM> <1990Nov16.222133.23158@daffy.cs.wisc.edu> Sender: news@ruuinf.cs.ruu.nl Lines: 81 In <1990Nov16.222133.23158@daffy.cs.wisc.edu> pochron@cat37.cs.wisc.edu (David Pochron) writes: >{stuff deleted} > >I also have been experimenting with scrolling huge screens (with AMOS, of >course) and have a few additional comments I would like to add: > >{remark reffering to other solutions deleted} > >Okay, this appears fine for coarse scrolling, but how does one go about doing >fine scrolling - using the hardware pointers, of course. It seems you would >need to double buffer everything and redraw one buffer completely every time >an entire panel was uncovered. (ie. redraw logical buffer in direction of >scroll, fine scroll physical buffer, switch to logical buffer when entire block >is revealed (now the physical buffer), go back to step 1 with the new logical >buffer) > >Phew! Sure wish they had just put multicolor text modes in the Amiga! :-) > > >If there is an easier way, please tell me - timing the redraw blits with the >hardware scroll pointers is a real pain. > >------------------------------------------------------------------------------- >David M. Pochron | from Rescue Rangers, _A Fly in the Ointment_ >pochron@garfield.cs.wisc.edu| Gadget to Dale: "Keep the hands off the body!" >------------------------------------------------------------------------------- Ok, this thread has been up several times before. Since this was the first problem I looked into when I got my Amiga, (and have been improving upon the ideas for over three years now) I may have some helpfull comments: When you are just scrolling in one direction (horizontal or vertical), there is no need for two buffers! Lets assume we are scrolling in a horizontal direction, and the field you want to scroll is divided into blocks which can easily be blitted onto the screen. We maintain the following bitmap: ----------------------------------- Two screens wide with on both sides two | | | | | aditional blockwidths to put the new | | | | | blocks in. | | | | | | | | | | ----------------------------------- The bitmap has the following purpose: ----------------------------------- Somewhere in the bitmap is the visible | |ee|*************|ee| | portion, the window. (marked *) | |ee|*************|ee| | The first block of the expansion (next | |ee|*************|ee| | to the window) has a valid block | |ee|*************|ee| | Into the second block the new portion ----------------------------------- of the screen can be blitted. On the left (resp. right) side you ---------------------------------- keep a copy of the right (left) side |ghijklmnop*aBCDEFGHIJKLMNOp*abcd| of the window plus its first expansion ---------------------------------- block. |ghijklmnopq*bCDEFGHIJKLMNOPq*bcd| ---------------------------------- When scrolling to the left, (moving the |ghijklmnopqr*cDEFGHIJKLMNOPQr*cd| window to the right) the following ---------------------------------- has to be done: |ghijklmnopqrs*dEFGHIJKLMNOPQRs*d| ---------------------------------- Blit the new portion of the screen on |ghijklmnopqrst*eFGHIJKLMNOPQRSt*| both the left and the right side of the ---------------------------------- window plus its first expanding blocks. |ghijklmnopqrstu*fGHIJKLMNOPQRSTu| This has the effect that when you ---------------------------------- encounter the right side of the bitmap, |gHIJKLMNOPQRSTUv*ghijklmnopqrstu| on the left side your copy is available ---------------------------------- (and vica versa). Further improvement can be made when scrolling in the vertical direction: By using a 'split screen' the copies on the upper and lower side of the bitmap need not be used. But can be simulated by a "clever" copper list waiting for the right moment and then swithing to another part of the bitmap (using modulo). Hope this is of some help to whomever is wrestling with this problem too. ------------------------------------------------------------------------------- Niek Luuring jr., student computer science, Utrecht University, The Netherlands EMail: njluurin@praxis.cs.ruu.nl -------------------------------------------------------------------------------