How to scroll horizontally?

[AChristian]

I did a search on the forum but found nothing definite.

I'm just wondering how it is done, just scrolling a single tile map..no parallax, also with sprites on top.

I dont want the details in assembly but just an overview of what has to be done.

[Galahad/FLT]

Originally Posted by AChristian

I did a search on the forum but found nothing definite.

I'm just wondering how it is done, just scrolling a single tile map..no parallax, also with sprites on top.

I dont want the details in assembly but just an overview of what has to be done.

Basically use the hardware scroll register to scroll 1 pixel at a time. When the hardware scroll register has scrolled 16 pixels, reset the scroll register back to zero and at the same time add 2 to the bitplane pointers, then repeat.

[AChristian]

Thanks,
when drawing bobs over the background does the background under the bob have to be saved to memory and then re-drawn each time the bob is drawn?

[Galahad/FLT]

Originally Posted by AChristian

Thanks,
when drawing bobs over the background does the background under the bob have to be saved to memory and then re-drawn each time the bob is drawn?

In most cases yes, unless you use dual playfield mode and then you don't need to, but that comes with some limitations.

[AChristian]

oh, so using one playfield for the background basically gives you 'free' (as in almost zero cpu usage) scrolling
then you can draw the bobs on another playfield,
wait for the raster to be in the right position, then erase and redraw bobs in their new positions?

[mcgeezer]

Originally Posted by AChristian

oh, so using one playfield for the background basically gives you 'free' (as in almost zero cpu usage) scrolling
then you can draw the bobs on another playfield,
wait for the raster to be in the right position, then erase and redraw bobs in their new positions?

If you have the memory keep a pristine buffer of the background, that way u don't have to save the sprite background saving you CPU/Blit time.

[AChristian]

Originally Posted by mcgeezer

If you have the memory keep a pristine buffer of the background, that way u don't have to save the sprite background saving you CPU/Blit time.

so you have an offscreen buffer that is just the background,
you then draw sprites onto the screen,

then copy just areas of the buffer back to the screen which erases the sprites
then draw sprites again

I guess that would be faster, as you dont have to work out how many bits a background graphic has been shifted by scrolling?

But then, wouldnt you have to copy the whole screen to a buffer each frame?

[mcgeezer]

Originally Posted by AChristian

I guess that would be faster, as you dont have to work out how many bits a background graphic has been shifted by scrolling?

But then, wouldnt you have to copy the whole screen to a buffer each frame?

Yes, all you do is save the address offsets from screen starting address so you know which regions to copy back from your pristine buffer.

You dont have to copy thr whole screen, you just blit in the tiles in the pristine buffer exactly as you do for the onscreen buffers.

[AChristian]

ok so lets say you:

copy tiles onto the screen

copy same tiles to the buffer

draw bobs

then the scroll register is incremented by one

so now on the screen the display has been shifted by one bit

so now copying the buffer to the screen has to be shifted by one bit


Alternatively:

copy tiles to screen

draw bobs

scroll by one pixel

draw tiles to screen shifted by one pixel (only where bobs are)



for both methods you would have to calculate the parts of the screen that have to be redrawn, so im not sure why the buffer method is faster?

[mcgeezer]

Originally Posted by AChristian

ok so lets say you:

copy tiles onto the screen

copy same tiles to the buffer

draw bobs

then the scroll register is incremented by one

so now on the screen the display has been shifted by one bit

so now copying the buffer to the screen has to be shifted by one bit


Alternatively:

copy tiles to screen

draw bobs

scroll by one pixel

draw tiles to screen shifted by one pixel (only where bobs are)



for both methods you would have to calculate the parts of the screen that have to be redrawn, so im not sure why the buffer method is faster?

Nothing is shifted by one pixel, they are still all on word boundaries. The Amiga hardware scrolling just displays them at the desired pixel offset between 0 and 15.

[roondar]

Originally Posted by AChristian

for both methods you would have to calculate the parts of the screen that have to be redrawn, so im not sure why the buffer method is faster?

It's faster because you only need to blit once (and thus only have to calculate the blitter register values once). Blitting from the tile map would mean fetching each of the tile addresses from the map and then blitting once for every tile the bob overlaps.


This is a more complicated algorithm, which potentially restarts the blitter multiple times. So, while the blitter itself will spend the same time for both copies, the CPU will be spending quite a bit more time.

[AChristian]

yes, so the second method would be
storing each tile position
so lets say a tile is 16x16
then storing the offset 0 to 15

then just drawing tiles onto the screen at the correct offset, where the bobs were.

Just wondering why this would be slower than copying the buffer.

It could be because the area might cover 5 tiles and then you would have to:
start and stop 5 times,
fetch different tiles,
and other calculations.

I could imagine that being slower than just doing one copy.

[roondar]

Originally Posted by AChristian

yes, so the second method would be
storing each tile position
so lets say a tile is 16x16
then storing the offset 0 to 15

then just drawing tiles onto the screen at the correct offset, where the bobs were.

When the Amiga scrolls, it doesn't actually change the screen buffer content in any way - it only displays the buffer differently (namely, at an offset).

Since the blitter always updates 16 bits/pixels at a time, this means that restoring bobs never needs to include any pixel offsets. It is enough to know which words the bob that needs be be restored covered in the bitmap.

Just wondering why this would be slower than copying the buffer.

It could be because the area might cover 5 tiles and then you would have to:
start and stop 5 times,
fetch different tiles,
and other calculations.

I could imagine that being slower than just doing one copy.

This is pretty much the reason. However, it is still slower even if only one tile needs to be restored.

A small bit of psuedocode might help here to show why it's always slower. First up, using a pristine restore buffer:

Blit:

bitmap = get_destination_bitmap_address(); // Destination bitmap for drawing bobs

For each bob do 
{
   calculate_destination_byte_offset();
   restore_offset[bob]=destination_byte_offset;
   destination_address=bitmap+destination_byte_offset;

   calculate_rest_of_blitter_values(mode_cookiecut);
   blit_bob();
}

Restore:

bitmap = get_destination_bitmap_address(); // Destination bitmap for restoring bobs

For each bob do
{
   destination_address=bitmap+restore_offset[bob];

   calculate_rest_of_blitter_values(mode_copy);
   blit_copy();
}

Now, using the tilemap as source for the restore operation


Blit:

bitmap = get_destination_bitmap_address(); // Destination bitmap for drawing bobs

For each bob do 
{
   calculate_destination_byte_offset();
   restore_offset[bob]=destination_byte_offset;
   destination_address=bitmap+destination_byte_offset;

   calculate_rest_of_blitter_values(mode_cookiecut);
   blit_bob();
}

Restore:

bitmap = get_destination_bitmap_address(); // Destination bitmap for restoring bobs

For each bob do
{
   destination_address=bitmap+restore_offset[bob];

   determine_tiles_covered(bobx,boby,bobsize);
   For each tile covered do
   {
      calculate_tile_address(tilex,tiley);
      calculate_rest_of_blitter_values(mode_copy);
      blit_copy();
   }
}

As you can see, the restore step is more complicated, even if only one tile is covered. This extra complexity slows down the program.

[AChristian]

yes there do seem to be a fair amount of extra steps thanks

and thanks mcgeezer