zeno@milton.acs.washington.edu (Sean Lamont) (11/29/89)
This is a repost, since nobody wanted to answer my question.
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?
Thanks in advance.
--
| Sean T. Lamont | |
|University of Washington | "Wave upon wave of demented avengers |
|ZENO@milton.acs.washington.edu| march cheerfull y out of obscurity |
| Savery hall, room 135. | into the dream"- P. Floyd |rogers@iris.ucdavis.edu (Brewski Rogers) (11/29/89)
In article <762@milton.acs.washington.edu> zeno@milton.acs.washington.edu (Sean Lamont) writes: > >This is a repost, since nobody wanted to answer my question. > >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? > >| Sean T. Lamont | | >|University of Washington | "Wave upon wave of demented avengers | >|ZENO@milton.acs.washington.edu| march cheerfull y out of obscurity | >| Savery hall, room 135. | into the dream"- P. Floyd | The only really *FAST* (That I know of, anyhow) way to scroll a view is to take control of the copper list, or create your own copper list. Once you have done this, you can simply change a couple of bytes in the copper list, which takes almost zero cpu time, and you will have smooth scrolling. Of course the whole thing tends to be a major pain in the ass if you want intuition compatibility, but at least its possible. One cheapo way you might want to experiment with, is to have intuition allocate your copper list for you (simply open a screen) And then search through it looking for the copper commands you want to modify. Of course, that's not OS friendly, but it's probably a fairly quick and dirty way to do it. 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... Good Luck. ------------------------------------------------------ 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!
nsw@cbnewsm.ATT.COM (Neil Weinstock) (11/30/89)
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: [ ... stuff about horizontal scrolling ... ] >>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? > >The only really *FAST* (That I know of, anyhow) way to scroll a view >is to take control of the copper list, or create your own copper list. > >Once you have done this, you can simply change a couple of bytes in the >copper list, which takes almost zero cpu time, and you will have smooth >scrolling. Of course the whole thing tends to be a major pain in the >ass if you want intuition compatibility, but at least its possible. [ ... ] One method I have used successfully is to first have Intuition allocate a 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 can double buffer, smooth scroll, anything. Intuition will live happily on the first playfield. If you use color 0 as your background color on the Intuition playfield, you can get cool effects like transparent menus, where your animation will be visible (and still animating) "through" the menus. I believe the freeware program "Tapestry" does something like this, though it doesn't do any animation. You do have to be careful about screen depth arrangement. I assumed that I could do pretty much whatever I wanted with the copper lists while my screen was on top (note that I did not allow my screen to be dragged down; that would have been a mess). If I ever found that my screen was not on top, I stopped animating. You also have to be careful with locking IntuitionBase; for a while I was having some problems with Dmouse guruing when trying to unblank the screen, but eventually I managed to make everything behave. As far as I know, I wasn't being "unfriendly" to the OS once I had everything worked out. Dual playfield screens: don't leave home without them! ________________ __________________ ____________________________ //// \\// \\// \\\\ \\\\ Neil Weinstock //\\ att!cord!nsw or //\\ "Oh dear, now I shall have //// //// AT&T Bell Labs \\// nsw@cord.att.com \\// to create more Martians." \\\\ \\\\________________//\\__________________//\\____________________________////
gbbrooks@sybil.cs.Buffalo.EDU (G. Brandon Brooks) (11/30/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 (Brewski Rogers) (11/30/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 (G. Brandon Brooks) (11/30/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 (Peter da Silva) (11/30/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>
micja@majestix.ida.liu.se (Michael Jansson) (12/01/89)
This is a related question to the previous ones. I am currently trying to implement a classic game called 'Moon lander' where I want to be able to scroll a landscape (implemented as a sort of fractal) in which a space craft should try to land. One of my goals is to do this inside a workbench window (It's much more fun to do it this way, and probably harder too ;-). The big prob|em with this is that I can't use ScrollVPort because I don't have a ViewPort with a RasInfo to modify, and that using a ScrollRaster would make the window flicker because the bitplanes will scroll one at a time and not all at once. In my crrent solution I create a fake RastPort which is a exact copy of the original RastPort in the window, except for the bitmap which only have one bitplane. In this way I won't get any flicker because ScrollRaster will only scroll one plane and it will be much faster then with the original RastPort, BUT I only have two colors to play with now. THE BIG QUESTION: Is there a better way to scroll a window in the Workbench Screen (better == faster, using all colors and no flicker)? I assume that this could be done with the coper or blitter, but what about concurrency of other windows on the Workbench screen (I heard that LockLayer and LockIBase have a few bugs!? ;-) |\ /| /// # Michael Jansson | \ / | /// # Internet: mij@IDA.LIU.SE | \ / | \\\ /// # UUCP: uunet!liuida!mij | \/ | \\X// # BITNET: mij@SELIUIDA - Plan as you should live for ever, but live as you should die tomorrow.
Jeff.Petkau@weyr.FIDONET.ORG (Jeff Petkau) (12/12/89)
Original From: Sean Lamont To: All Re: Fast Scrolling > > I am trying to do horizontal smooth scrolling. I 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 Originial From: Brewski Rogers To: Sean Lamont Re: Fast Scrolling > 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... IMNSHO, ScrollVPort is just such a routine. You can easily animate at 15-20 frames/second with it (not fast enough for The Ulitmate Super-Duper Really Really Fast Action Whammo Blammo Arcade Game, but plenty enough for anything else). And it works by just the method you suggested: directly poking new offsets into the screen's copper list. Back to the original question (Sean Lamont): You probably forgot to follow the golden rule of Amiga programming--ignore everything the RKM's say about a function, except for the Autodocs (if it weren't for those, I doubt that a single working Amiga program would exist yet.) To scroll in a screen with ScrollVPort, do lak dis: MyScreen->ViewPort.RasInfo->RxOffset=x_offset_into_screen; MyScreen->ViewPort.RasInfo->RyOffset=y_offste_into_screen; if(I_am_double_buffering) MyScreen->ViewPort.RasInfo->BitMap=dbuf_bitmap; ScrollVPort(&MyScreen->ViewPort); #end of code You might want to stick a WaitTOF() before the ScrollVPort() if it's flickering a lot. Also, ScrollVPort() doesn't work on interlaced screens (bug). The edges of the screen will jump around if you don't do some setup first. Specifically, open your screen as wide as you want, then change MyScreen->Width and MyScreen->Height, and do a MakeScreen() and RethinkDisplay(). You only have to do this once. -- Jeff Petkau - via FidoNet node 1:140/22 UUCP: alberta!dvinci!weyr!Jeff.Petkau Internet: Jeff.Petkau@weyr.FIDONET.ORG Standard Disclaimers Apply...
bartonr@jove.cs.pdx.edu (Robert Barton) (12/12/89)
Jeff.Petkau@weyr.FIDONET.ORG (Jeff Petkau) writes: > Also, ScrollVPort() doesn't work on interlaced screens (bug). WaitBOVP() doesn't work right with interlace, either. These routines both use a piece of code that tests bit 4 of the high-order byte of ViewPort.ClrIns. In other words, it looks like someone wrote BTST #V_LACE,v_Modes(A0) instead of BTST #2,vp_Modes+1(A0)