Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!lll-lcc!pyramid!cbmvax!ditto From: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Newsgroups: comp.sys.amiga.tech Subject: Re: Fast 2-D Scrolling Method Needed (kinda long) Summary: Would work, could even be improved Keywords: scrolling ideas Message-ID: <6283@cbmvax.UUCP> Date: 15 Mar 89 05:27:04 GMT References: <112@dg.dg.com> <10871@well.UUCP> <113@dg.dg.com> <10921@well.UUCP> <736@cord.UUCP> Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Organization: Commodore Technology, West Chester, PA Lines: 70 [ Changed to .tech only ] In article <736@cord.UUCP> nsw@cord.UUCP (Neil Weinstock) writes: > Question #1: Can the copper reload just the bitplane pointers > quickly enough to avoid blank scan lines between slices? If not, > then we're hosed. It can. The Amix console driver does this. It only uses one bitplane at the moment, so to load several planes it might have to WAIT for a slightly earlier point. Currently it waits for the beginning of the line. (BTW, if it for some reason couldn't load them fast enough, the result would not be blank lines, but some extra continuation of the previous "slice"'s bitmap, and the current slice would be shifted to the right.) >Now, horizontal scrolling is achieved with "standard" copper list twiddling. (Hopefully this means by modifying the places in the copper list where the bitplane-start and horizontal-scroll registers are set.) >Vertical scrolling, on the other hand, is achieved by creating (via tiles, >or algorithms, or who knows what) the next slice to be scrolled onto the screen, >and integrating it into the copper lists. When a slice gets scrolled >completely off the edge of screen, it can be freed up and reused. It may >be desirable to leave some sort of "buffer zone" at the top and bottom if you >don't know which direction you'll be needing to scroll. The Amix console driver does this with a few variations: A "slice" is one scanline (i.e. it doesn't really use slices, it just starts the display at whatever line it feels like). Since each slice (except the first one in memory) happens to immediately follow the previous one in memory, no copper action is necessary between slices except when the "last" slice wraps around into the first. This means the copperlist really only needs one change to support this scrolling system: At what would have been the end, it must WAIT for the spot where the memory bitmap will wrap around, and just MOVE the new BPLxPT values. The current version does not have any "buffer zone" -- exactly the number of pixels that will be displayed are allocated. Since the modified copper list is only "installed" at the top of the next field, this means that it is possible that it might be scribbling in the part of bitmap that is supposed to be at the bottom of the screen (and will be there after the new copper list takes effect next field) but is currently displayed at the very top. This is actually noticable sometimes. >So, the end result is that you have created a circular queue of display slices >which allows the display memory to be run like a treadmill. The height of each >slice would determine how long you have to create the off-screen slice, but >also how much you have to create. The height of a "slice" actually has no effect, it's the amount of "buffer zone" that determines how far you can stay ahead. The "slice" essentially becomes an arbitrary, variable thing equal to however much you scroll in a given field. For a video game you probably have to finish the update by the next frame, so it basically limits how many pixels you can scroll per frame without having some possibility of re-using some memory that is still being displayed. If you're double buffering, you wouldn't need any buffer zone. >I am convinced that if pulled off correctly, this could make for absolutely >lightning fast scrolling of an arbitrarily tall but finitely wide field, with >many bitplanes. It does. Type "cat /etc/termcap" and you'll be dizzy real quick. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!kenobi!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com