• We always blit complete blocks, because that's much faster than for example blitting each last pixel line of 16 different blocks, although the amount of data is the same. For vertical scrolling maybe one could do this nevertheless, but for horizontal scrolling the planar format of the Amiga forbids using the pixel-column-fillup-technique if you attach importance to speed.

  • We never blit complete block columns (horizontal scrolling) or complete block rows (vertical scrolling) in one frame. Instead we devide the job into BLOCKWIDTH or respectively BLOCKHEIGHT steps. For 16 x 16 blocks this means that for both horizontal and vertical scrolling we use 16 steps. 16, because after 16 pixels of scrolling the block column/row (which is 16 pixels large/high) will come into view and at that time it must be finished.

  • For all algorithms we assume, that it shall be possible to change direction at any map position. Therefore doing a 8 way scroller is rather complicated. If we allowed direction changes to happen only every BLOCKWIDTH/BLOCKHEIGHT pixels, everything would be much easier.

  • Since the programs all use single buffering. it is sometimes possible to see how blocks are blitted near the borders, especially if you scroll fast. When using double buffering (something you do nearly always in a real game) this does not happen.

  • The demo source codes are far from being optimized!! For example some blitter registers are set again and again, instead of only one time before the scrolling routines. Further in some cases it is certainly a good idea to do some work with the CPU instead of the Blitter (maybe one block with the Blitter, the next with the CPU, then again with the Blitter, etc.) or to give the Blitter DMA priority over the CPU (DMAF_BLITHOG in DMACON). No tables are used in the source codes - for multiplications they might be quite effective. The source codes' only purpose is to make the techniques more understandable.

  • If you want to make the demo source codes work with other block sizes (for example 32 x 32) then it is not enough to change the #defines. Several things will have to be adapted or rewritten.

  • In this documentation coordinate pairs are often written like this:

    (CoordinateX,CoordinateY)

    The used unit depends on the context. Be especially careful when looking at the CoordinateY, which sometimes does not use the same unit as the CoordinateX, for example planelines instead of pixels. Areas are written like this:

    (StartCoordinateX,StartCoordinateY) - (EndCoordinateX,EndCoordinateY)

    Regarding the used unit the same things apply.

  • All source codes use the same #defines and variables. Description.