gbbrooks%sybil.cs.buffalo.edu@cunyvm.cuny.edu (12/06/89)
Newsgroups: comp.sys.amiga.tech Subject: Re: Fast Scrolling Summary: Expires: References: <762@milton.acs.washington.edu> <6072@ucdavis.ucdavis.edu> Sender: Reply-To: gbbrooks@sybil.cs.Buffalo.EDU.UUCP (G. Brandon Brooks) Followup-To: Distribution: Organization: SUNY/Buffalo Computer Science Keywords: scrolling,spam In article <6072@ucdavis.ucdavis.edu> rogers@iris.ucdavis.edu (Brewski Rogers) writes: >In article <762@milton.acs.washington.edu> zeno@milton.acs.washington.edu (Sean Lamont) writes: >> >>I am trying to do horizontal smooth scrolling. I have tried two methods, >>one using SCROLLRASTPORT and one using SCROLLVPORT. >> >>Problems I want to solve: >> >>1) I can't GET SCROLLVPORT to work at all!!! I gave it the VPORT record >> of my screen, but it did nothing. I've tried this in several >>vport environments. >> >>2) It's TOO SLOW! A SCROLLRASTPORT takes far too much time to scroll >>anything of any substance. (like a 400 x 200 5-plane bitmap) I know >>it's possible to move bitmaps much faster (for example, Screen sizing) >>How would one go about making a FAST scroll? >> > >Basically, there are NO fast intuition routines to scroll your >screens View. This may be connected to the fact that most screens >can be dragged up and down the screen... > I use Benchmark Modula-2, and to scroll a view, all I do is: ViewPort.DxOffset := 10; ViewPort.DyOffset := 5; ScrollVPort(ViewPort); This moves a view IMMEDIATELY 10 pixels to the right, and 5 pixels down; effextively making (10,5) the origin of the screen (0,0). In "C"Just change the syntax, and I think it'll work. Just changing the DxOffsets and DyOffsets doesn't do any good - I assume that is what you were doing - The computer must be TOLD that you did this. A ScrollVPort() command will do the job. -Good Luck, Brandon!
rogers%iris.ucdavis.edu@cunyvm.cuny.edu (12/07/89)
In article <13939@eerie.acsu.Buffalo.EDU> gbbrooks@sybil.cs.buffalo.edu (G. Brandon Brooks) writes: > I use Benchmark Modula-2, and to scroll a view, all I do is: > >ViewPort.DxOffset := 10; >ViewPort.DyOffset := 5; >ScrollVPort(ViewPort); > > This moves a view IMMEDIATELY 10 pixels to the right, and 5 pixels >down; effextively making (10,5) the origin of the screen (0,0). ScrollVPort is actually pretty slow. Also, in the RKM's it is described as having a slight bug where it may flicker periodically. Doesn't ScrollVPort do a MergeCopList (or whatever its called)? Basically, any system command is going to have to do some big data moving to get the screen's new copperlist to work with the screen-dragging the O.S. supports. It depends on how much CPU time you want to spend scrolling your view. ------------------------------------------------------ Quantum _\/_ 2727 Eel Bruce (6502 RULES!) Rogers |\ Duck ( 0 0) Davis, Ca 95616 Quantum Duck Software, |\ \______/ / \\\ 916-756-2684 rogers@iris.ucdavis.edu |\ < < | \/ "It's better to be the real thing than the right thing." \________/ Quark!
gbbrooks%sybil.cs.buffalo.edu@cunyvm.cuny.edu (12/07/89)
In article <6096@ucdavis.ucdavis.edu> rogers@iris.ucdavis.edu (Brewski Rogers) writes: > >ScrollVPort is actually pretty slow. Also, in the RKM's it is described >as having a slight bug where it may flicker periodically. Having programmed an Atari 800 previously, and upon spotting this command, I used it and noticed the flicker. It doesn't seem to be a bug according to what my knowledge of the Atari is. I just use a Wsync(), or the Amiga equivalent to this, WaitTOF. The flickering is then eliminated. >Doesn't ScrollVPort do a MergeCopList (or whatever its called)? Maybe, but my "Amiga Programmer's Handbook", ScrollVPort, pg. 281 doesn't say that it does. It DOES get the screen's new copperlist and fiddles with it. >Basically, any system command is going to have to do some big data >moving to get the screen's new copperlist to work with the screen-dragging >the O.S. supports. > >It depends on how much CPU time you want to spend scrolling your view. > I am in the midst of programming a scrolling game on my Amiga. So far, using ScrollVPort seems to do the job very quickly. If someone knows how to scroll a view faster, with less CPU time, please enlighten me! -Brandon!
peter%sugar.hackercorp.com@cunyvm.cuny.edu (12/07/89)
In article <7182@cbnewsm.ATT.COM> nsw@cbnewsm.ATT.COM (Neil Weinstock) writes: > screen for you, then you create your own "second screen" and make a > dual-playfield display. You can then manipulate the second playfield and > Intuition won't even know about it. You don't even need to use dual-playfield for this... just use one bitplane for Intuition and arrange your colors so that bitplane is always ignored. Then you can do dual-playfield as well, giving you an extra 4 colors (albeit expensive ones). I really wish there was a 2+4 or 1+5 dual-playfield mode as well as the regular 3+3. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "Really, a video game is nothing more than a Skinner box." -- Peter Merel <pete@basser.oz>
me300234@pa.usl.edu (Stelly John B III) (12/09/89)
I have accomplished a fast scroll, by setting up a super-bitmap, and changing the x and y offset parameters in the layer_info structure pertaining to this bitmap and then issuing a CopySBitMap(mylayer); command where mylayer is a pointer to the layer of the Superbitmap. This IS fast, but it produces a very horrible color flashing effect when used on a 32 - color image... Is there any way to eliminate this (or rather any way that someone will tell me how to eliminate this????) ? I've seen smooth scrolling in several games, and I'm not afraid to code in assembly, but how do I go about passing the pointers to my bitmaps to an assembly language scrolling routine ??? Any info will be appreciated.. --John B Stelly
poirier@dg-rtp.dg.com (Charles Poirier) (12/15/89)
In article <5473@nigel.udel.EDU> rogers%iris.ucdavis.edu@cunyvm.cuny.edu writes: >Basically, any system [scroll?] command is going to have to do some big data >moving to get the screen's new copperlist to work with the screen-dragging >the O.S. supports. Talking thru my hat again: Ever since bringing up my choice of screen- depth-control-hack program (MachII), I've never wanted to drag screens around. Would there be any chance of a speed-up in screen handling by installing "disable-drag" as, say, a Preferences option? Just a thought, Charles Poirier