🚀 go-pugleaf

In article <679@greens.UUCP>, allegro@sunpix ( SunVis) writes:
>   I'm pretty much a novice programmer and I'm sure this is a technique most
>of you learned in programming 101 :^).

No, it's second semester. :-)

>Anyway I'm writing a program that uses a map 3 to 4 times the screen
>size and I want to be able to scroll smoothly around the whole map.
>The best technique I have come up with so far involves shifting the
>displayed map area over one grid then filling in the blank areas with
>the new data from off screen. The shift of the screen is relatively
>fast but the new data redraw is a bit slow for what I've had in mind.

Each byte in the video memory must be written anyway, so keep a
complete video image somewhere and do a block transfer to move the
desired part onto the screen.  You probably will not be able to get
away with a straight byte-for-byte copy, and so you'll need (I am
guessing) two nested loops rather than a single one.

A further advantage to this method is that the size of the transfered
image is also parameterizable.  Thus not just full screens could be
transfered, but also arbitrary rectangular pieces.

These kind of operations in their generality are called bitblt's, or
bit block transfers, and include not only moves, but also logical
operations on the target as well.  For example, you can xor each
source byte with its corresponding target byte.  This has the effect
(on a two color screen) of making the source appear in inverse
contrast to the pre-existing background, i.e. black letters on white
background and white letters on black.  Many graphics textbooks
discuss this in more detail.

Eric Hughes
hughes@math.berkeley.edu   ucbvax!math!hughes