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.