Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!husc6!husc7!byrd
From: byrd@husc7.HARVARD.EDU (John Byrd)
Newsgroups: comp.sys.cbm
Subject: Re: Machine Language Smooth Scrolling Problem
Summary: Everything you never wanted to know about smooth scrolling
Keywords: machine language, scrolling, C64, squid, gratification
Message-ID: <2911@husc6.harvard.edu>
Date: 20 Oct 89 07:13:02 GMT
References: <2317@jarthur.Claremont.EDU> <136@cbmtor.UUCP> <2823@husc6.harvard.edu> <1989Oct11.151724.18728@jarvis.csri.toronto.edu>
Sender: news@husc6.harvard.edu
Reply-To: byrd@husc7.UUCP (John Byrd)
Organization: Harvard University Science Center   Cambridge, MA
Lines: 77

In article <1989Oct11.151724.18728@jarvis.csri.toronto.edu> leblanc@eecg.toronto.edu (Marcel LeBlanc) writes:
>In article <2823@husc6.harvard.edu> byrd@husc7.UUCP (John Byrd) writes:
> (much deleted)
>>The programmer must watch for "flicker" when designing and writing this
>>type of sliding routine.  If the raster (present line which is being drawn on
>>the television screen) happens to be on the screen when the screen is being
>			^^^^^^^^^^^^^^^^^^^^^^^^^^^ (difficult to avoid!)
>>moved via the software routine, the screen will flicker.  This can be
>>resolved by checking location $D012.  The raster is on the screen only when
>>the value of this location is between 51 and 251, AND when the high bit of
>>location $D011 is OFF.  Otherwise it is okay to do the software scroll.
>
>Have you ever actually tried this (without double buffering)?  As you point
>out later in your posting, the display is redrawn every 1/60 sec.  This is a
>pretty tough timing problem.  Try this loop:
>

 (huge amount of code deleted)

>total cycles = 2 + ( (4+40/256+5+2+3)*256-1+6+6+4+2+3)*4-1
>	     = 14577 us (not counting VIC cycles)

 (more deletion)

>Starting from the bottom of the screen just after the raster has
>left the visible area doesn't leave enough time to complete the scroll
>before the raster starts displaying the top of the visible area on the next
>refresh! 

 (still more deletion)

Okay, guys.  Marcel has a point (and can you believe how he arrived at it?)
When I implemented a scroll for a game, I did it in a way only *similar* to
the way listed above.  The scroll was left to right, and I didn't have to
worry about the down factor.  More on that later.

Marcel has pointed out that scrolling a screen full of characters in the time
it takes the raster (television scanning line) to leave the bottom of the 
screen and arrive at the top would be a tight timing squeeze, at best.  I
did indeed use double-buffering when scrolling left and right.  Double-
buffering refers to drawing a picture on one screen while viewing the other
screen (a "screen" being a screen-sized section of memory) and then swapping
the viewed screen and the drawing screen.

However, if you are willing to put up with a certain amount of flicker (and
most games and demos from Europe seem to not mind a little flicker) and are
confused by coding a double-buffer, then it is possible to survive with one
screen.

Regarding scrolling down.  This algorithm does it, starting from the top of
the screen and working its way down: 

1. Copy present character row into buffer B.
2. Copy buffer A into present character row.
3. Copy buffer B into buffer A.
4. Go to next lower character row, if there is one; if not, end.
5. Go to step 1.

But the big question: is it fast enough to get to the bottom of the screen
before the raster, released at the previous bottom edge, does?  I don't
think so, after Marcel's analysis.  It should take about 3 times as long as
Marcel's routine, or about 1/20 of a second.  Dang it, not fast enough!
However, if it were possible to do this much computation in 1/60 of a
second, and your normal down-scroll algorithm wasn't fast enough to beat
the raster to the top of the screen, this one would do it.

SPECIAL TO LeBlanc: Anyone who counts clock cycles is not completely sane. :)

>Marcel A. LeBlanc	   | University of Toronto -- Toronto, Canada
>"leblanc@eecg.toronto.edu"| and: LMS Technologies Ltd, Fredericton, NB, Canada
>------------------------------------------------------------------------------
>UUCP:	uunet!utai!eecg!leblanc    BITNET: leblanc@eecg.utoronto[.ca]

John Byrd
"byrd@husc7.harvard.edu"

I can't think of an intelligent quote....