🚀 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

In article <679@greens.UUCP> allegro@sunpix.UUCP ( SunVis) writes:
>   I'm pretty much a novice programmer and I'm sure this is a technique most
>of you learned in programming 101 :^). 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. Any 
>hints ?  

Stephen,
Well, I've said a few words before about techniques closely related to what
you're trying to do (maybe I should start posting my game design tips...
Nahhh, might need the secrets some day... heheheheh)... Here's my two cents
on scrolling, redrawing, and generally performing "smooth" scrolling on the
Atari ST (note, this is works on all bit mapped screens that have the ability
to change the physcial screen base...)

Ok, to ensure that the user never see you draw (this is kinda like not having
anyone see you sweat), you want to show him a complete, unchanging screen
while you construct the new screen ("frame") behind the scenes.  When you've
got the new frame built, swap it with the frame you're currently showing.
If you perform the swap while your screen isn't being drawn, the very next 
displayed frame will be a clean transition from your previous to the new.
Now use your old frame to create the next new frame in.

So how about _your_ application?  Yeah, well, it sounds like you're picking
a large section of the screen up and putting it down again -- try this
instead.  Blit the entire new screen map into the hidden screen, and then
swap it.  Write your own map blit routine in 68000 for performance, or use
the usual GEM vro_cpyfm() call to get the stuff working first!  So you
keep a master map, pick screen size pieces up to construct each new frame.
Place any objects you like on top of the new screen, then swap it in.
Ok, now there seems to be all sorts of confusion when it comes to swapping
screens on the ST.  My suggestion is this: install yourself as a VBlank
routine and stuff the screen's physical base yourself.

Good luck!
-- 
Kenneth Soohoo			{ames,imagen,portal}!atari!kens
Atari Engineering
"So Atari doesn't necessarily agree with me, so what!"