Atari ST games with smooth scrolling - how?

[DanScott]

Smooth horizontal scrolling on the ST in games such as Chuck Rock (probably Wolfchild, Carvup etc.. too), used preshifted block pairs. This meant that you had to be careful about the layout of tiles on your map, but it used the minimum necessary preshifted data, so it didn't take a huge amount of memory to store.

You could also build the code for each line (that was called 16 times), to fetch the data, and move it into screen memory efficiently.

This is effectively how games like Cobra on the Spectum achieved smooth scrolling too.

[DanScott]

Originally Posted by ImmortalA1000

if you want to scroll horizontally in less than 16 pixel jumps you need to allocate duplicate 32k screens with preshifted tiles for however many pixels you really want to scroll.

nope, not really... see my post above

[Megalomaniac]

Should it have said "if you want to scroll horizontally in less than 16 pixel jumps without making significant design compromises if designing for an ST, or without cutting back on detail if converting from elsewhere you need to allocate duplicate 32k screens with preshifted tiles for however many pixels you really want to scroll". (my italics)?

[Tigerskunk]

Originally Posted by DanScott

Smooth horizontal scrolling on the ST in games such as Chuck Rock (probably Wolfchild, Carvup etc.. too), used preshifted block pairs. This meant that you had to be careful about the layout of tiles on your map, but it used the minimum necessary preshifted data, so it didn't take a huge amount of memory to store.

You could also build the code for each line (that was called 16 times), to fetch the data, and move it into screen memory efficiently.

This is effectively how games like Cobra on the Spectum achieved smooth scrolling too.

Could you explain that a bit more? For the case if I ever try to code an ST game, that is...

Love to read about clever coding techniques.

[Keops/Equinox]

Originally Posted by DanScott

nope, not really... see my post above

+1

In a 16 pixel-wide block, if you start preshifting a tile, you have to start including in those 16 pixels the next possible tile(S) existing to the right, the ones that will be displayed right after the current tile on the same line, because their preshifting "bleeds" into the current tile. If you don't do that, you will have a horrible discontinuity.

That means you have to consider all the possible associations of TileA-TileB on screen for 32 pixels, and because memory is not unlimited, you can only have a limited number of tile association for your game with that technique, which sets constraints for level artists.

If you don't want to have that constraint for preshifted tiles on ST, you will have to draw 2 tiles per 16-pixel block, using an OR each time for the second tile within your 16-pixel block, which will more than double the cost of drawing those tiles but will let you arrange them in any way you want.

[ImmortalA1000]

Originally Posted by DanScott

nope, not really... see my post above

OK that's another way of doing it but if you want to 'scroll' the entire screen in single pixel jumps that's how you could do it. Depends on your game engine and genre of game you are writing which is going to work better.

[ImmortalA1000]

I have just checked out the longplay of Turrican 2 on the ST and it has the parallax scrolling shmup level. OK it's not as fluid as the C64 version but it is impressive.

I'd give it a go but ST cracks rarely have decent trainer options, 99% of the time it's useless unlimited lives/credits.

[Tigerskunk]

Originally Posted by DanScott

Smooth horizontal scrolling on the ST in games such as Chuck Rock (probably Wolfchild, Carvup etc.. too), used preshifted block pairs. This meant that you had to be careful about the layout of tiles on your map, but it used the minimum necessary preshifted data, so it didn't take a huge amount of memory to store.

You could also build the code for each line (that was called 16 times), to fetch the data, and move it into screen memory efficiently.

This is effectively how games like Cobra on the Spectrum achieved smooth scrolling too.

@DanScott: Would you care to elaborate a bit more on those techniques?

I am a bit dabbling in ST coding at the moment, and would love to find out how some of that tricky stuff worked.. What do you mean by "block pairs" ?

Plus that "You could also build the code for each line (that was called 16 times), to fetch the data" sounds quite mysterious to me...

[AestheticDebris]

Originally Posted by Tigerskunk

I am a bit dabbling in ST coding at the moment, and would love to find out how some of that tricky stuff worked.. What do you mean by "block pairs" ?

When you're scrolling a background, the tricky part comes about because you'd normally have to mask+combine the left and right edges of tiles (because the on screen graphics will be half of one tile, half of another).

One trick to make this more performant is to only allow certain transitions between tiles. That way you can use pre-shifted versions that already contain the merged together data and so it can be drawn quicker.

Originally Posted by Tigerskunk

Plus that "You could also build the code for each line (that was called 16 times), to fetch the data" sounds quite mysterious to me...

You basically generate specific code for the exact data you're going to generate. So, for example, a sequence of instructions to draw tile A three times, then tile X, then tile Y etc..This means you have to make less decisions, because each row of tiles can use the same instructions rather than checking the tile map each time to figure out what to draw next. It's not for the feint hearted and requires solid optimization to be entirely worthwhile.

[oscar_ates]

Which chips in Amiga do and help for smooth scrolling? As far as I know copper can change the number of colors in screen only

[Tigerskunk]

Originally Posted by oscar_ates

Which chips in Amiga do and help for smooth scrolling? As far as I know copper can change the number of colors in screen only

I guess that's Denise and its scrolling register...
Not much of a problem there..

On the ST it's kind of the holy grail, though.

[Tigerskunk]

Originally Posted by AestheticDebris

When you're scrolling a background, the tricky part comes about because you'd normally have to mask+combine the left and right edges of tiles (because the on screen graphics will be half of one tile, half of another).

One trick to make this more performant is to only allow certain transitions between tiles. That way you can use pre-shifted versions that already contain the merged together data and so it can be drawn quicker.



You basically generate specific code for the exact data you're going to generate. So, for example, a sequence of instructions to draw tile A three times, then tile X, then tile Y etc..This means you have to make less decisions, because each row of tiles can use the same instructions rather than checking the tile map each time to figure out what to draw next. It's not for the feint hearted and requires solid optimization to be entirely worthwhile.

Some very interesting ideas...
Thanks...

[DanScott]

Originally Posted by oscar_ates

Which chips in Amiga do and help for smooth scrolling? As far as I know copper can change the number of colors in screen only

The copper can theoretically write to any of the hardware registers at any position on (or off) the screen.

The colour registers are just 32 of those registers. There's also (among many others), bitplane pointers, bitplane control registers, sprite registers, audio registers etc...

[Galahad/FLT]

Originally Posted by oscar_ates

Which chips in Amiga do and help for smooth scrolling? As far as I know copper can change the number of colors in screen only

Dan beat me to it, but copper can do a lot more than simply change colours lol.

It can access most of the hardware registers, triggering blits, interrupts, screen mode changes, sprite multiplexing, sample triggering, changing bitplane pointers, literally any hardware register that can be written to, can be done by the copper.

It's what makes the Amiga.......Amiga!

[CCCP alert]

I presume on Amiga you can move the screen memory pointer to scroll the screen around a large bitmap 1 pixel at a time?

[Galahad/FLT]

Originally Posted by CCCP alert

I presume on Amiga you can move the screen memory pointer to scroll the screen around a large bitmap 1 pixel at a time?

To do horizontal scrolling on 1 pixel you would use hardware scrolling, then once you've scrolled 16 pixels, change the bitplane pointers and reset hardware scroll to zero.

Scrolling vertically can be done by changing the bitplane pointers, so yes you can easily scroll around a large Bitmap and the Amiga isn't remotely being stressed doing it.