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

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 :/

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

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.

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

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?

Screen Offset SCREEN_NUMBER,X,Y

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


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

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

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.

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.

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?

Hes suggesting you use Offset but loop back around

Yes, I believe I saw it :)


Regards,
Lonewolf10

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?:crazy

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.

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.

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.

@Samurai Crow

Super! thanks!

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

I spotted a bug already.

Should read:

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"

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