Smooth H-scrolling platform game in AMOS, screen copy vs screen offset?

[Damiga]

Hi,
I'm playing around with the TOME map/level editor in AMOS and I have some issues with scrolling.
In the examples provided with TOME they used "screen copy" command for scrolling a level/map on screen. It works, but it doesn't produce smooth scrolling.
I've tried using the command "screen offset" and it works a lot better, the scrolling can't get any smoother =)
BUT, when I use screen offset I'm limited by the screen size, about 1000 pixels in width appears to be max in AMOS.
There must be some way to do big maps with smooth scrolling in AMOS, right?
Or do I have to start using Blitz Basic?
Assembler seems to difficult and time consuming for me :/

[Lonewolf10]

Did you try using double buffering with screen copy, that might produce a smoother scroll?

I'm sure there's an example of the screen offset technique in the AMOS Professional manual. I know Darren Ithell used it for his Dithell games.


Regards,
Lonewolf10

[Coagulus]

1000 pixels should be more than enough for a smooth horizontal scroll. I used to have a screen twice as wide (as a 320 screen, it was about 720-ish I think) and scroll across 1 pixel at a time blitting 2 tiles per frame (one offscreen to the left and one to the right to give a perfect copy when I looped the screen). This worked fine and quick.

[Lonewolf10]

Coagulus, that is the classic scroll technique

I tried to write my own AMOS code to do that once (years ago), but never managed to get it right. I have learnt alot since then, so I am certain it can be done


Regards,
Lonewolf10

[Photon]

I'm unfamiliar with what screen offset means in AMOS so this may be left field, but if it means what it means in hardware programming it's the way to go. A screen copy definitely should mean you're spending most of your gameloop blitting (bad, hopefully) or CPU-copying (worse, but wouldn't surprise me).

On Amiga you can scroll huge levels just changing the screen pointer and scroll-value with very little time spent blitting new blocks coming in from the edge(s) you're scrolling towards. Even on OCS, any problem with scrolling your heart out 50 times per second is only in the head of the programmer

From Coagulus' post it seems that's possible in AMOS as well?

[Lonewolf10]

Originally Posted by Photon

I'm unfamiliar with what screen offset means in AMOS so this may be left field, but if it means what it means in hardware programming it's the way to go.

Screen Offset SCREEN_NUMBER,X,Y

The command allows simple offsetting of screens without having to know how the hardware does it.

Originally Posted by Photon

A screen copy definitely should mean you're spending most of your gameloop blitting (bad, hopefully) or CPU-copying (worse, but wouldn't surprise me).

On Amiga you can scroll huge levels just changing the screen pointer and scroll-value with very little time spent blitting new blocks coming in from the edge(s) you're scrolling towards. Even on OCS, any problem with scrolling your heart out 50 times per second is only in the head of the programmer

From Coagulus' post it seems that's possible in AMOS as well?

With AMOS you can probably alter the screen addresses manually (not tried it myself) by using the Screen Base function to get the screen base address. You can then use the Screen Structure table that myself and Andrew Church worked out (it's on AmigaCoding), useful part here:

Ofs | Item
----+-----------------------
$00 | Bitplane 0 Logical
$04 | Bitplane 1
$08 | Bitplane 2
$0C | Bitplane 3
$10 | Bitplane 4
$14 | Bitplane 5
$18 | Bitplane 0 Physical
$1C | Bitplane 1
$20 | Bitplane 2
$24 | Bitplane 3
$28 | Bitplane 4
$2C | Bitplane 5
$30 | Bitplane 0 Current
$34 | Bitplane 1
$38 | Bitplane 2
$3C | Bitplane 3
$40 | Bitplane 4
$44 | Bitplane 5


For example, to get the address of Bitplane 3 of the currently active screen you would do

BITPLANE3=Screen Base+$3C


Regards,
Lonewolf10

[Retro1234]

Ive also have a problem with large screens but with the vertical when Blitter Objects are place quite far down a large screen they distorted - Im guessing this has somthing to do with the way the Blitter updates? Can anyone explain more?

More info http://www.ultimateamiga.co.uk/index...;topicseen#new

[Damiga]

Originally Posted by Coagulus

1000 pixels should be more than enough for a smooth horizontal scroll. I used to have a screen twice as wide (as a 320 screen, it was about 720-ish I think) and scroll across 1 pixel at a time blitting 2 tiles per frame (one offscreen to the left and one to the right to give a perfect copy when I looped the screen). This worked fine and quick.

I was only using 1000 pixel wide screen when trying screen offset.
When I used screen copy the screen was just 2 tiles extra in width, 2*16 pixels, the tiles I'm using are 16 pixels wide. Giving a total screen width of 352 pixels.

But when using only screen offset, the map cannot exceed the screen width of 1000 pixels if I want to avoid using the slow(?) screen copy.

The screen copy method works if I lower the height of the portion of the screen that I scroll. For example, if i would only like the ground in the game to scroll, say 60 pixels on the lower part of the screen, then I manage to get smooth scrolling with screen copy.
But a platform game with only flat ground is not so exciting.

[KevG]

A 1000 pixels is way too much. You only need two screen widths +32 pixels = 672 pixels wide if using 16 pixel wide tiles. Trust me on this, using screen offset is much better and faster than using the screen copy method.

Kev G.

[Retro1234]

The Problem is you can Scroll quicker than you can Paste Icons

It can be done I know but gets complex - I think Lonewolf you saw that demo I did of continuous large map horizontal hardware scrolling?

Originally Posted by Damiga

I was only using 1000 pixel wide screen when trying screen offset.

When I used screen copy the screen was just 2 tiles extra in width, 2*16 pixels, the tiles I'm using are 16 pixels wide. Giving a total screen width of 352 pixels.



But when using only screen offset, the map cannot exceed the screen width of 1000 pixels if I want to avoid using the slow(?) screen copy.



The screen copy method works if I lower the height of the portion of the screen that I scroll. For example, if i would only like the ground in the game to scroll, say 60 pixels on the lower part of the screen, then I manage to get smooth scrolling with screen copy.

But a platform game with only flat ground is not so exciting.

Hes suggesting you use Offset but loop back around

[Lonewolf10]

Originally Posted by Boo Boo

It can be done I know but gets complex - I think Lonewolf you saw that demo I did of continuous large map horizontal hardware scrolling?

Yes, I believe I saw it


Regards,
Lonewolf10

[Retro1234]

I seem to remember having to draw tiles while scrolling and it was quite tight
If your double buffering the screen even worse - Probably wouldnt do this.

Alastair Murray of Backbone said somthing like he had the screen 2 tiles extra wide scrolled 1 tile using offset then screen copied it back the the beginning -Screen swap -draw new edge and so on.

He did four directional scrolling how smooth you think this is I dont know but was quite fast.

interested to know how you get on.

[Damiga]

Originally Posted by Boo Boo

I seem to remember having to draw tiles while scrolling and it was quite tight
If your double buffering the screen even worse - Probably wouldnt do this.

Alastair Murray of Backbone said somthing like he had the screen 2 tiles extra wide scrolled 1 tile using offset then screen copied it back the the beginning -Screen swap -draw new edge and so on.

He did four directional scrolling how smooth you think this is I dont know but was quite fast.

interested to know how you get on.

Ok, I think I get it, combine screen offset with screen copy.
Draw the map starting from the first column of tiles, then scroll with screen offset 16 pixels(1 tile), then draw the map starting from second column of tiles and setting screen offset back 16 pixels, then scroll 16 pixels using screen offset, and so on.

Does it make sense?

[Retro1234]

Something like that but I wouldnt do it for just for horizontal scrolling

If possible Scroll with offset to the Right -Forget left Scroll for now -While drawing tiles behind you
When you reach the end of the screen using offset go back to offset 0 the tiles youve drawn behind you, you now scroll to the right and so on in a looping like that.

Of course im no expert other probably have better ideas.

[Samurai_Crow]

Originally Posted by Damiga

Ok, I think I get it, combine screen offset with screen copy.
Draw the map starting from the first column of tiles, then scroll with screen offset 16 pixels(1 tile), then draw the map starting from second column of tiles and setting screen offset back 16 pixels, then scroll 16 pixels using screen offset, and so on.

Does it make sense?

It does make some sense but it's not optimal.

I'll write you an example pseudo-code based on the example one that comes with AmigaE and post it here.

[Samurai_Crow]

This one loads a Tome formatted tile map and displays it...without using the Tome commands because they're just too slow. BTW, I didn't check the code or try to run it so there may still be mistakes in it.

Screen Open 1, 672, 256, 32, lowres
Flash off
Curs off
Cls 0
Load "tilemap.abk",6: Rem Load the map
Load "tiles.abk",2: Rem load the tile images as an icon bank
Get Icon Palette
Rem get size of map from tilemap.abk
T=Start(6)
MAXX=Deek(T)
MAXY=Deek(T+2)

Rem Draw the initial map starting at top left
Screen Hide
For Y=0 to 256 Step 16
  ROW=Y*MAXX+4+T : Rem add 4 to skip size header
  For X=16 to 336 Step 16
    Paste Icon X,Y,Peek(ROW+X/16)
  Next X
Next Y
Screen Show

Rem Scroll right until you get to the end of the map
MAXXP=MAXX*16-320 : Rem Maximum pixel coordinate
For X=0 to MAXXP
  LX = X mod 320
  Y=X and 15 : Rem Pixel offset and tile row
  If Y=0
    Rem This code is only accessed on even multiples of 16 pixels
    X1=LX
    X2=X1+336 : Rem 336=320+16
    COL1=X/16+T+4
    COL2=COL1+21 : Rem 21=336/16
  Endif
  YT=Y*16
  ROW=Y*MAXX
  Rem If you scroll faster than 1 pixel per frame
  Rem then you have to plot that many more tiles
  Paste Icon X1, YT, Peek(COL1+ROW)
  Paste Icon X2, YT, Peek(COL2+ROW)
  Wait Vbl
  Screen Offset LX+16, 0
Next X
Screen Close 1

[Damiga]

@Samurai Crow

Super! thanks!

Hopefully there is something wrong with the code so I have to figure it out and learn something

[Samurai_Crow]

I spotted a bug already.

  ROW=Y*MAXX+4+T : Rem add 4 to skip size header

Should read:

  ROW=(Y/16)*MAXX+4+T : Rem add 4 to skip size header

[Damiga]

I made a quick try yesterday with the code that samurai crow provided.
It worked, kind of =)

The issue I'm having is that I can't save a map as .ABK. I think I got an old version of the tome-editor, version 3.something. I can't find the option so save as .ABK which is mentioned in the TOME IV Manual.

I think that's the reason that it doesn't work as I expected. Wrong tiles are displayed on screen, and it doesn't seem to be able to read the size of the map. the map was just 10 tiles high, but it plotted out 16 tiles high, so the map got scrambled. Then I changed the map to 16 tiles high, but when running code after that, it crashed, had to reboot the Amiga.

So i Changed this:
Rem Draw the initial map starting at top left
Screen Hide
For Y=0 to 256 Step 16

To:
For y=0 to 144 step 16

It now worked, but the first part of the map was 10 tiles high, and the second part was 16 tiles high. And still wrong tiles. I could set the "Y-loop" up to 192 before crashing, adding 16 to the value each time.

So do anyone happen to have a later version of the TOME editor?(I have the version 4 tome libs), so I can save the maps as .ABK?

In the meanwhile I'll try to find out how to use the .map format with the code you kindly provided me with =)

Oh, and I had to change names on some of the variables, AMOS didn't like names containing "max" and "col"

[Samurai_Crow]

Try replacing the ABK load of the map with something like this:

Open In 1,"file.map"
Reserve 6 as Work, Lof(1)
Close 1
Bload "file.map",6