NU105451@NDSUVM1.BITNET (Walter Reed) (02/21/88)
I would like to do a wrap around scroll on a bitmap. I tried using a ScrollRaster call but it was too darned slow and the colors were messy (it scrolls one plane at a time.) I want to do a smooth scroll from bottom to top with the stuff going off the top re-appearing on the bottom. It would be nice to be able to change the graphics before it re-appears on the bottom (would be easy if the bitmap was taller than the viewable area.) HOW DO you do this? The RKM's don't give any clue at all how this could be done. If you haven't guessed, this is for a character generator type of thing. Walter Reed NU105451@NDSUVM1 or ncreed@ndsuvax.BITNET via bitnet uunet!ndsuvax!ncreed via uucp
cs178abu@sdcc8.ucsd.EDU (John Schultz) (02/23/88)
In article <595NU105451@NDSUVM1> NU105451@NDSUVM1.BITNET (Walter Reed) writes: >I would like to do a wrap around scroll on a bitmap. I tried using > >Walter Reed For vertical scrolling, allocate a bitmap twice as high as the display (for 200 lines, allocate a bitmap with a height of 400, etc). Set up a Dwidth of 200 lines. Make the RP handle 400 lines. You now have a drawing area 400 pixels tall, but you can only see 200 pixels. Increment RyOffset then call ScrollVPort(). Notice no flicker, incredible speed and smoothness; the result of hardware scrolling. (you don't need WaitTOF() or WaitBOVP()) You can't increment RyOffest forever, so you'll have to set RyOffset back to zero when it is equal to BITMAP HEIGHT / 2 (If your Bitmap is twice as high as your viewport display). The last excersize is left to the reader: How to handle the reset situation described above. John
peter@nuchat.UUCP (Peter da Silva) (02/28/88)
In article <795@sdcc8.ucsd.EDU>, cs178abu@sdcc8.ucsd.EDU (John Schultz) writes: > For vertical scrolling, allocate a bitmap twice as high as the > display (for 200 lines, allocate a bitmap with a height of 400, > etc). Set up a Dwidth of 200 lines. Make the RP handle 400 lines. > You now have a drawing area 400 pixels tall, but you can only see > 200 pixels. Increment RyOffset then call ScrollVPort(). > Notice no flicker, incredible speed and smoothness; the result of > hardware scrolling. (you don't need WaitTOF() or WaitBOVP()) Is this a solution to the double-buffering page-flipping dillemma? A quick review. Programs that use double buffering have a problem: if they are well behaved they have to call a RethinkDisplay when they switch. That's real slow, but if they are badly behaved they produce weird effects like the ones you can see when you mouse around in Halfbrite Hill or ShowAnim. Is ScrollVPort fast enough for the job? Does it work right under Intuition? -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
cs178abu@sdcc8.ucsd.EDU (John Schultz) (03/01/88)
In article <699@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >Is this a solution to the double-buffering page-flipping dillemma? > >Is ScrollVPort fast enough for the job? Does it work right under Intuition? >-- a clone of Peter (have you hugged your wolf today) da Silva `-_-' Answers: 1. Depends. 2. Yes. 3. Of course. Trivia: ScrollVPort() just re-interprets your RasInfo. RethinkDisplay()? Oh jeez, slow yes. Drawing into screens? Oh jeez, slow yes. LoadView()? Oh, fast yes. Not intuition compatible? There is at least one way... John
dillon@CORY.BERKELEY.EDU (Matt Dillon) (03/03/88)
> RethinkDisplay()? Oh jeez, slow yes. Drawing into screens? Oh > jeez, slow yes. LoadView()? Oh, fast yes. Not intuition A screen's rastport does not have a layer associated with it and thus drawing in it (Move/Draw/etc....) is much faster than drawing in a window. Not having a layer means you must ensure your calls do not contain any out of bound arguments. -Matt