allegro@sunpix.UUCP ( SunVis) (07/07/89)
Hello,
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 ?
--
uucp: mcnc!rti!sunpix!steve or mcnc!rti!sunpix!allegro | Stephen McKay Matson
"FRODO LIVES!!" | (919)460-8357 {voice}
---Colorado memories keep me going another day.--- |hughes@math.berkeley.edu (Eric Hughes) (07/07/89)
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
kens@atari.UUCP (Kenneth Soohoo) (07/08/89)
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!"