English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 19 August 2018, 23:24   #1
AChristian
Registered User

 
Join Date: Aug 2018
Location: england
Posts: 23
How to scroll horizontally?

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.
AChristian is offline  
Old 19 August 2018, 23:34   #2
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 45
Posts: 7,037
Quote:
Originally Posted by AChristian View Post
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.
Galahad/FLT is offline  
Old 19 August 2018, 23:41   #3
AChristian
Registered User

 
Join Date: Aug 2018
Location: england
Posts: 23
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?
AChristian is offline  
Old 19 August 2018, 23:53   #4
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 45
Posts: 7,037
Quote:
Originally Posted by AChristian View Post
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.
Galahad/FLT is offline  
Old 20 August 2018, 10:12   #5
AChristian
Registered User

 
Join Date: Aug 2018
Location: england
Posts: 23
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?
AChristian is offline  
Old 20 August 2018, 11:09   #6
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 564
Quote:
Originally Posted by AChristian View Post
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.
mcgeezer is offline  
Old 20 August 2018, 11:20   #7
AChristian
Registered User

 
Join Date: Aug 2018
Location: england
Posts: 23
Quote:
Originally Posted by mcgeezer View Post
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?
AChristian is offline  
Old 20 August 2018, 11:34   #8
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 564
Quote:
Originally Posted by AChristian View Post

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.
mcgeezer is offline  
Old 20 August 2018, 11:52   #9
AChristian
Registered User

 
Join Date: Aug 2018
Location: england
Posts: 23
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?
AChristian is offline  
Old 20 August 2018, 12:02   #10
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 564
Quote:
Originally Posted by AChristian View Post
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.
mcgeezer is offline  
Old 20 August 2018, 13:35   #11
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 568
Quote:
Originally Posted by AChristian View Post
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.
roondar is offline  
Old 20 August 2018, 13:38   #12
AChristian
Registered User

 
Join Date: Aug 2018
Location: england
Posts: 23
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.
AChristian is offline  
Old 20 August 2018, 14:52   #13
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 568
Quote:
Originally Posted by AChristian View Post
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.

Quote:

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:
Code:
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:
Code:
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:
Code:
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:
Code:
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.
roondar is offline  
Old 20 August 2018, 18:14   #14
AChristian
Registered User

 
Join Date: Aug 2018
Location: england
Posts: 23
yes there do seem to be a fair amount of extra steps thanks

and thanks mcgeezer
AChristian is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
WinUAE Display Problem - Gloom Pushed Horizontally To Left CodyJarrett support.WinUAE 1 23 December 2014 11:29
Using SSCAN2 & SH10 register to repeat sprites horizontally in Blitz2 leathered Coders. Blitz Basic 1 03 June 2014 20:29
Demos which scroll a large part of the screen horizontally mark_k request.Demos 7 22 December 2012 16:21
Scroll with the mouse? BarrySWE support.Apps 14 29 May 2012 23:16
help me smooth scroll rusty71 support.WinUAE 7 21 November 2011 16:36

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.08589 seconds with 13 queries