Side Scrolling Games on the A800

[simonl]

. . .as far as I know most games use for scrolling maps LMS per line? but why if you could handle that via the simple way?

 

all my books have scrolling tile maps examples with "scrolling windows" done via LMSs/line.

 

The LMS-per-line is the simple way starting from De Re Atari and everything after. This way the entire screen is always in memory. All the published tutorials from back in the 80s that I recall only expected to scroll around a limited map a couple screens in each direction. I don't remember any scrolling tutorial that presented the scroll-forever problem. (Though, I can think of a couple games from the 80s that did this effect, but never dissected the code to figure out how it was being accomplished.) The one-LMS solution is a non-obvious, head-slap moment. It seems like anarchy to think about it, but in the end it works almost like magic.

 

Although if you do want to use an LMS per line for some reason, it may make sense to store your square screen as a parallelogram shaped window onto the RAM buffer - this means only one line "hits the buffers" at a time and needs to be copied to the other end and the new character added. E.g. if you had a regular width (48 byte) window into a 96 byte wide buffer that you were unpacking the background into:

 

 

Cheers,

 

Simon

[snicklin]

MWP put in a simpler way is the following (for horizontal scrolling to the right)

1) 1 LMS for top left of screen.

2) Scrolling to the right, you add 1 to the LMS which then screws up every character in a vertical line down the right hand side of the screen.

3) Load the data from a buffer for what SHOULD go on the right hand side of the screen and then update the screwed up characters down the right.

 

Et voila!

[snicklin]

• @SimonL - Now that is a very interesting concept.
  

[Creature XL]

. . .as far as I know most games use for scrolling maps LMS per line? but why if you could handle that via the simple way?

 

all my books have scrolling tile maps examples with "scrolling windows" done via LMSs/line.

 

The LMS-per-line is the simple way starting from De Re Atari and everything after. This way the entire screen is always in memory. All the published tutorials from back in the 80s that I recall only expected to scroll around a limited map a couple screens in each direction. I don't remember any scrolling tutorial that presented the scroll-forever problem. (Though, I can think of a couple games from the 80s that did this effect, but never dissected the code to figure out how it was being accomplished.) The one-LMS solution is a non-obvious, head-slap moment. It seems like anarchy to think about it, but in the end it works almost like magic.

 

Although if you do want to use an LMS per line for some reason, it may make sense to store your square screen as a parallelogram shaped window onto the RAM buffer - this means only one line "hits the buffers" at a time and needs to be copied to the other end and the new character added. E.g. if you had a regular width (48 byte) window into a 96 byte wide buffer that you were unpacking the background into:

 

 

Cheers,

 

Simon

This way only one char needs to be updated per hard scroll step? Sounds clever

Edited June 1, 2012 by Creature XL

[Heaven/TQA]

looks clever, indeed... and spending few cycle per 4th VBL for 1 char sounds too good

[Heaven/TQA]

MWP put in a simpler way is the following (for horizontal scrolling to the right)

1) 1 LMS for top left of screen.

2) Scrolling to the right, you add 1 to the LMS which then screws up every character in a vertical line down the right hand side of the screen.

3) Load the data from a buffer for what SHOULD go on the right hand side of the screen and then update the screwed up characters down the right.

 

Et voila!

 

I guess not as you have 2 LMS?

[simonl]

looks clever, indeed... and spending few cycle per 4th VBL for 1 char sounds too good

 

Well, it's not quite that good, in the above scheme you'd have to copy the current 48 and write the remaining new 48 chars from the row when it wraps, but then for that row you essentially have nothing to do until next time it hits the end other than update the LMS occasionally, and only one row can wrap per 4 frames. It depends how your tile uncompression is optimised, if it's optimised for horizontal lines you're laughing.

 

Cheers,

 

Simon

[TMR]

Writing entire columns in at the end of a hardware scroll cycle for the LMS-per-line system isn't exactly CPU intensive, that old preview i posted years back with the Co-Axis 2189 graphics is only taking about three and a half scanlines to write twenty bytes of newly-arrived column into two places. That's nothing in the great scheme of things to be honest and, since the write-ins aren't visible, that load could be spread over however many frames the hardware scroll takes to do complete a cycle if it needs to be tighter.

 

The vertical scroll engine i wrote yesterday for my "fun project" uses a single LMS, 3K of screen and a similar system, writing two copies of one row in every eighth frame and using about eight scanlines without optimisation.

 

[simonl]

Writing entire columns in at the end of a hardware scroll cycle for the LMS-per-line system isn't exactly CPU intensive, that old preview i posted years back with the Co-Axis 2189 graphics is only taking about three and a half scanlines to write twenty bytes of newly-arrived column into two places. That's nothing in the great scheme of things to be honest and, since the write-ins aren't visible, that load could be spread over however many frames the hardware scroll takes to do complete a cycle if it needs to be tighter.

 

The vertical scroll engine i wrote yesterday for my "fun project" uses a single LMS, 3K of screen and a similar system, writing two copies of one row in every eighth frame and using about eight scanlines without optimisation.

 

Yes, "flyback" scroll by writing the data twice is generally more sensible, however using RLE horizontally on a tile map may mean unpacking data in long rows is easier in some instances.

 

Cheers,

 

Simon

[TMR]

Yes, "flyback" scroll by writing the data twice is generally more sensible, however using RLE horizontally on a tile map may mean unpacking data in long rows is easier in some instances.

 

When you say "RLE horizontally on a tile map" do you mean the tiles are RLE compressed or the map...?

[simonl]

Yes, "flyback" scroll by writing the data twice is generally more sensible, however using RLE horizontally on a tile map may mean unpacking data in long rows is easier in some instances.

 

When you say "RLE horizontally on a tile map" do you mean the tiles are RLE compressed or the map...?

 

Oh, just the map (i.e. x number of tile y) even I'm not OCD enough to compress a 3 byte wide tile

 

Cheers,

 

Simon

[flashjazzcat]

MWP put in a simpler way is the following (for horizontal scrolling to the right)

1) 1 LMS for top left of screen.

2) Scrolling to the right, you add 1 to the LMS which then screws up every character in a vertical line down the right hand side of the screen.

3) Load the data from a buffer for what SHOULD go on the right hand side of the screen and then update the screwed up characters down the right.

 

Et voila!

 

I guess not as you have 2 LMS?

 

I begin to understand this now. You need the second LMS to achieve vertical "wraparound" - I think.

[TMR]

Oh, just the map (i.e. x number of tile y) even I'm not OCD enough to compress a 3 byte wide tile

 

Does that get you much in the way of saving...? And what format is your map in, rows or columns?

[simonl]

 

Does that get you much in the way of saving...? And what format is your map in, rows or columns?

 

Depends on the map, but if it's some large repetitive and irregular shaped one like a NES platformer then yes, lots. Also, some tile map editors support exporting the map in that format.

 

So if you want to uncompress a line of 48 chars from 3x3 tiles that's 16 tiles which may be all or partially the same, and if the tiles are stored so you can look up the char data from row 0,1,2 then it's pretty efficient.

 

Cheers,

 

Simon

[snicklin]

I guess not as you have 2 LMS?

 

Yes, 2 LMS, sorry! I hadn't re-read the explanation and remembered only the 1 LMS.

[snicklin]

I'm trying to think of scrolling games which had huge maps on the Atari and am wondering what techniques they may have applied?

 

Rally Speedway?

[Rybags]

Spelunker has a fairly decent sized map, it uses LMS per line moving over the map.

 

Rally Speedway uses LMS per line, it's Antic 5. Unsure how it does the wraparound, possibly relies on Antic not crossing 4K boundaries.

[Shawn Jefferson]

Search the forum for Gauntman's mwp demo. It's a stripped down version and is pretty easy to see what's going on.