@3 SUPER FAST SWAP SCROLL ALGO --------------------------- By Paul Overy (programmer of mega-hit High Octane Turbo) @1 The routine is unlike any other scroll as it approaches the problem a totally different way, it can even do full screen HAM on an A500 with no fringeing, whizzing along at 50fps how about that then? So how does it work... See the diagram swap_scroll.iff & Amos listing Swap_scroll.amos before reading this document. Well the average scroll routine normally just moves the whole screen in one go, even using the blitter this task is just too much for a full screen 32 colour scroll. To get round this problem you have to use all the Amiga's extra hardware. My method of attacking the problem is to only move a small amount of screen data at a time. This would be carried out in the background hidden from the viewer. The background screen is moved in 16 pixel steps while the screen is offset giving a smooth scrolling effect. To do this the background screen is updated from the physical screen (background being the logical). The user just sees the screen offsetting. A extra 16 pixel screen boundary is always needed for each direction to be scrolled. i.e. For an 8 direction scroll the top,bottom,left & right sides of the screen must have an extra 16 Pixels added to the total screen size. So for an 8 way 320x250 screen view, you would need a (320+32)x(256+32) screen area, the borders being hidden with the "screen display" command which only needs to be done once. If the screen is only to be scrolled up, then only an extra 16 pixels are needed to be added on the depth size of the screen. i.e. 320x(256+16) for a 320x256 up only scroll (Although you could move down a limited amount, until the boundary is hit). Once a 16 pixel boundary has been reached the background screen is swapped with the front physical screen, then the screen offset is reset to a central point and the screen border(s) are updated. Then the process would start all over again. If you were to look at the background screen as the routine is running, you would see the screen scrolling at 16 pixies jumps with a wavy update. On a 16 pixel boundary the background screen matches the next scrolling step to be taken, and is not noticed when a screen swap takes place. Updating the borders can be carried out in two ways, the second method will free even more time for your programs. 1. By updating the border(s) all in one go. This can only really be done if you have a fast extension that updates blocks in rows and columns, such as the turbo_plus extension. Although it can be done in one update with the PD turbo1_9.lib extension, it has no row/column updates but it does have some very fast block update routines. But don't use them inside a loop, have a long list of block updates as a FOR loop would slow things down. 2. By updating the border(s) a small amount at a time, this has to be done so the border is completely updated on the next 16 pixel boundary. This method has been used in the demo version. 3. No, I only said there were two methods. The routine comes into its own when you only scroll the screen at 1 pixel per frame. This means you can break down moving the background screen into 16 separate areas, each being copied from the front screen on a frame (1/50th sec) as you work your way down the screen. As a result vast amounts of extra time are gained as you only have to move a 16th of the total screen area at a time. To keep border updates as simple as possible, scroll speeds must increment in steps of 1,2,4 & 8. This way you don't have to waste time cutting up map block data. As with a step of say 3, you would need information from two different mapped blocks for one part of the boarder update. This means you can't speed up in a smooth fashion, it doesn't notice that much, as 2^n speeds up slowly at the lower end of the scale. When faster speeds are reached you normally do this anyway. Cut sizes (segments) directly affect the stepping speeds which can be achieved. 16 segments -> 1 pixel step | more time free 8 segments -> 1 &2 pixel step | 4 segments -> 1,2 &4 pixel step | 2 segments -> 1,2,4 & 8 pixel step V less time free If you are only going to scroll at 1 pixel per frame, then used 16 segments. This will give you loads of extra free time to do other things, its just as if you were scrolling 1/16th of the screen. You don't have to stop with a 16 pixel(8 pixel jumps), it can be bigger. A 32 boundary would give some really fast scroll speeds(max 16 pixel jumps!), maybe even too fast. Now for some bad points about this scrolly... - Can't use the bob updating system (not even autoback 0). It needs a much more complex system, you will have to store the backgrounds yourself before pasting bobs on. - Only 6 of the eight sprites(0-7) can be used with a screen bigger than 320x256 in view area. Sprites 6/7 are effected by the screen offsetting. Nothing to do will me, read the Amos user guide p150 for the reason. - Unbuffered bob's can't be used with the "screen swap" command. The "screen to front/back" has to be used instead of the preferred "screen swap". To do this double buffering is not used, and you would have to open two screens up to replace the double buffering. - Using the above method makes timing very critical with unbuffered bob's, or tearing will occur. Without an extension such as Turbo, you only have the "wait vbl" command which offers very little flexibility to the Amos coder. With Turbo you get a "vbl wait n" command, i.e. you get to state which scan line you want to wait for. Another method to use bobs would be to open up one big screen 640x256 (+ borders), and use the screen offset command as a replacement for the "screen swap" command. This would make things quite complex as you would be jumping left and right each frame by 320 pixels and also adding the scroll offset on top of this. With some clever tricks you may be able to use buffered bob's, this is only an idea; I have not tried this one out. Because of the methods used, I have named my little 8 way scrolly the Swap Scroll. If this document makes no sense to you then don't worry, as my cat helped me with the grammar and spellings. All right I confess, I woke up one morning and my CAT had written this really cool scrolly routine, just to say thanks for all the food. Exalts, Paul Overy. Paul Overy "Fry-up Productions" 27 Barton Road Maidstone Kent ME15 7BU England