44 replies to this topic

[R6502A]

Hello,

I've decided to attempt write a game for my beloved Atari 800XL. The intention is to write a horizontal scrolling game in the vein of R-Type and Section-Z, that makes user of the Atari 8 bit strengths/weaknesses.

I intend to post xex files of my progress and welcome advice any of you may have. Once complete I might post the source code for all to see.

I'll start by setting up a display list using Antic mode 4 lines and run a continuous scroll between two screens (Updating graphics as I go) i.e. (screen A, Screen B, Screen A (A copy)). A DLI routine or 2 will change the character set on each line (24 in total) and each will use the 80 characters for the screen area.

A software sprite routine will write to the character set area and using a character screen opens up the possibility of coarse character based sprites, which will be probably be used for weapons fire.



R6502A

Attached Files

•  HScroller2.xex   411bytes   143 downloads

[Rybags]

That's one way to go about it.

The advantage the A8 has with scrolling is that since you have 4 characters worth of fine-scroll, you don't need to do bulk memory moves in the one go.

It's entirely possible to stage it - in conjunction with LMS changes you could quite easily get away with only moving 40 characters per frame.

Of course that can cause some level of confusion with stuff like softsprites or collision mapping - but you're keeping track of each line's offset, so you just need to take them into consideration for those things.

Edited by Rybags, Thu Nov 4, 2010 10:33 PM.

[MaPa]

Rybags, on Thu Nov 4, 2010 10:32 PM, said:

The advantage the A8 has with scrolling is that since you have 4 characters worth of fine-scroll, you don't need to do bulk memory moves in the one go.

It's entirely possible to stage it - in conjunction with LMS changes you could quite easily get away with only moving 40 characters per frame.

Hmm I don't understand? AFAIK you need to update two columns every char move (one in advance and one behind the screen to prepare screen flip) so it's in his case (24 lines high play area) 48 bytes per 4 frames (if we assume 1pixel/frame scroll speed) so I get something like 12 bytes per frame if you will split it plus of course updating LMS... 24 bytes (if you will have lines in one page) once 4 frames or if you will use whole 4 chars scroll possibility, then 24 bytes once 16 frames.

[Heaven/TQA]

Mapa... you are right... only collums... that's what I call the "Gameboy" method as most of the Gameboy/SNES games do this as Nintendo defined the tile vram exactly 2 screens wide....

[Heaven/TQA]

but the challenge will be not only to build the screen... it is not only copy the bytes as they were chars but as we want to use a "bitmap" style you would need to copy the chardata for the tiles itself, too...

[Rybags]

I should have said "less than 40 chars per frame on average" or something like that.

Also I was talking from a single frame buffer perspective, where new data is introduced and the stuff that scrolls off is lost. And, not large overall buffer, just an LMS per line and less than 64 bytes used per screen line.

So, groups of lines start at offset 0 on their "buffers" and move towards a max value e.g. 24 chars offset from that (disregard fine-scroll here for a bit).

Instead of all lines hitting the max at the same time, have groups of lines such that the offsets are different, e.g. 8 lines have offset 0 when the next 8 are at 8 and the final 8 lines are at 24.

That way, you introduce new tile/char data at "offset + 40" type of thing, and reset your offset back to zero when it hits the end (and perform the block memory moves at that time). But instead of the entire screen at once, you only have to handle moving a third of it at one time when a move is required.

Of course you could expand on that - use a different offset for every line if needed, which means you don't have big block moves at once, just little ones more often.

Edited by Rybags, Fri Nov 5, 2010 1:05 AM.

[Heaven/TQA]

Rybags... what is the advantage? as I don't get it in the morning here... with the "collum" copy method you don't need to shift or move screen data? as it happens "automaticly"?

[Rybags]

There's only really 2 scenarios where no (or a minimal amount of) screen data needs to be moved in a h-scroller R-Type kind of game:

. small sized level where e.g. 8 screens worth of data is predrawn and the window moves over it.
. give every line it's own 4K region and take advantage of the Antic "feature" of wraparound when it overruns the 4K boundary.

For that second scenario it becomes a bit expensive, but a 128K system could cope - e.g. 20 lines = 80K devoted to the screen.
You don't need to move any data, all you need to do is copy the last 40 or so bytes of each 4K area backwards to the start of the 4K area so that the wraparound will look smooth.

[TMR]

Rybags, on Fri Nov 5, 2010 1:28 AM, said:

There's only really 2 scenarios where no (or a minimal amount of) screen data needs to be moved in a h-scroller R-Type kind of game:

. small sized level where e.g. 8 screens worth of data is predrawn and the window moves over it.
. give every line it's own 4K region and take advantage of the Antic "feature" of wraparound when it overruns the 4K boundary.

Or use a single LMS and write new data into whatever is the new right hand column after each update; it only needs one byte written in per character line each update (so 24 bytes in this case and that can be spread over at least four frames) and, if 4K is given over to the screen buffer, it can scroll for over sixty screens without the need for a buffer swap.

[Heaven/TQA]

TMR, on Fri Nov 5, 2010 2:38 AM, said:

Rybags, on Fri Nov 5, 2010 1:28 AM, said:

There's only really 2 scenarios where no (or a minimal amount of) screen data needs to be moved in a h-scroller R-Type kind of game:

. small sized level where e.g. 8 screens worth of data is predrawn and the window moves over it.
. give every line it's own 4K region and take advantage of the Antic "feature" of wraparound when it overruns the 4K boundary.

Or use a single LMS and write new data into whatever is the new right hand column after each update; it only needs one byte written in per character line each update (so 24 bytes in this case and that can be spread over at least four frames) and, if 4K is given over to the screen buffer, it can scroll for over sixty screens without the need for a buffer swap.

is that method the technique Analmux used in his Super Mario 3 Demo?

[MaPa]

Heaven/TQA, on Fri Nov 5, 2010 4:55 AM, said:

is that method the technique Analmux used in his Super Mario 3 Demo?

No, MWP method uses two LMS and only memory of one screen plus one line buffer I think, so in total cca. 1k of memory and it allows "endless" 8 way scroll.

[Spurge]

Bloody jealous of you guys knowing all this stuff.

[Heaven/TQA]

never got into MWP really even everything is documented and described...

But same happened with fixed point maths... I thought there is some magic behind but it is not...

[Heaven/TQA]

still all relevant information...

http://atariwiki.str...an Atari-HIPRIP

[MaPa]

Heaven/TQA, on Fri Nov 5, 2010 7:04 AM, said:

never got into MWP really even everything is documented and described...

But same happened with fixed point maths... I thought there is some magic behind but it is not...

Me too, even that I implemented this technique somehow in an attempt to write some platform game with 8way scroll. As a base I took some source code which was presented here on Aage forum, it scrolled gr. mode 1 or 2 filled with letters A,B,C... etc. I don't remember the author.. Allas maybe?

[Heaven/TQA]

MWP example... I went 100 times through the source code of your mentioned example but well... still it does not make "click" in my head...

[R6502A]

Heaven/TQA, on Fri Nov 5, 2010 12:45 AM, said:

but the challenge will be not only to build the screen... it is not only copy the bytes as they were chars but as we want to use a "bitmap" style you would need to copy the chardata for the tiles itself, too...

Yep, I got that.

That's why I said I need 80 characters (40 characters for each screen dedicated to the bitmap display/buffer). The actual graphics data will have to be written to the character set data area, depending on which line you're on you'd write to the appropriate character set. Of course I'd have to keep track of what is on/off screen and to speed things up I wouldn't need to write a full set of characters each time, only the changes, since a particular level will be quite samey I'll just loop the screens and copy chars here and there for a bit of variation.

If I want a software sprite to appear behind something I'll copy a defined character to the buffer (I'll probably store them in characters 81 - 127 and they'll have to fit nicely on character boundaries). If I want the software sprite to be in front I'll have to copy the character data to the buffer area and then plot the sprite.

[R6502A]

R6502A, on Fri Nov 5, 2010 10:49 AM, said:

Heaven/TQA, on Fri Nov 5, 2010 12:45 AM, said:

but the challenge will be not only to build the screen... it is not only copy the bytes as they were chars but as we want to use a "bitmap" style you would need to copy the chardata for the tiles itself, too...

Yep, I got that.

That's why I said I need 80 characters (40 characters for each screen dedicated to the bitmap display/buffer). The actual graphics data will have to be written to the character set data area, depending on which line you're on you'd write to the appropriate character set. Of course I'd have to keep track of what is on/off screen and to speed things up I wouldn't need to write a full set of characters each time, only the changes, since a particular level will be quite samey I'll just loop the screens and copy chars here and there for a bit of variation.

If I want a software sprite to appear behind something I'll copy a defined character to the buffer (I'll probably store them in characters 81 - 127 and they'll have to fit nicely on character boundaries). If I want the software sprite to be in front I'll have to copy the character data to the buffer area and then plot the sprite.

Of course I did meant 80 - 127, since we are zero based.

[Heaven/TQA]

ok... and how do you want to scroll after 4 pixel? shift the complete screen? and did you made any CPU calculations?

did you had a look at the Menace 6502 sources?

[R6502A]

Heaven/TQA, on Fri Nov 5, 2010 1:43 PM, said:

ok... and how do you want to scroll after 4 pixel? shift the complete screen? and did you made any CPU calculations?

did you had a look at the Menace 6502 sources?

I haven't looked at those sources. Where can I find them please?

I'm fine scrolling every third vblank (I've tried other settings 1 and 2 are too fast and slower than 3 just looks too jerky). I scroll for 4 chars then do a course scroll.

1.) Outside of vblank in the main loop I'm thinking a series of tables that define the map and call the copy routines to create the map in the off screen areas. I think this should work because they are not time critical as long as the area is off screen.

Not sure it is the best way go about it because 2.) Since the scroll will be at a constant rate maybe I should 100% sync the copying with this and I should copy the graphics during the 2 vblank entries when the scrolling is not being updated and skip it when we're scrolling (course or fine), or draw during fine scroll and only skip drawing during the coarse scroll. I'll have to experiment and see.


mainloop

<--- 1.) draw map here (need to keep track of where the screen is.)

jmp mainloop

vblank

<--- 2.) or draw map here (every frame)

count to 3

if not 3 then vblank end

fine scroll

if fine scrolled 4 chars then coarse scroll

<--- 3.) or draw map here (unless we're going to coarse scroll)

jmp vblank end

coarse scroll

vblank end


Worst case copy scenarios.

Each column = 8 x 24 bytes = 192 bytes

option 1.) No sure how quick this will be
option 2.) will copy 48 bytes (Quarter of a column) into the buffer per fine scroll
option 3.) Will copy all 4 columns = 768 bytes


I think I'm swaying towards option 2, especially when I consider I'll not be writing the full complement of 48 bytes each time.


Thanks everyone for your input so far.

A

[Wrathchild]

R6502A, on Fri Nov 5, 2010 7:25 PM, said:

... Where can I find them please?

Here

[analmux]

MaPa, on Fri Nov 5, 2010 7:16 AM, said:

Me too, even that I implemented this technique somehow in an attempt to write some platform game with 8way scroll. As a base I took some source code which was presented here on Aage forum, it scrolled gr. mode 1 or 2 filled with letters A,B,C... etc. I don't remember the author.. Allas maybe?

Do you mean this?

http://www.atariage....262#entry699262

[MaPa]

analmux, on Tue Nov 9, 2010 8:31 AM, said:

MaPa, on Fri Nov 5, 2010 7:16 AM, said:

Me too, even that I implemented this technique somehow in an attempt to write some platform game with 8way scroll. As a base I took some source code which was presented here on Aage forum, it scrolled gr. mode 1 or 2 filled with letters A,B,C... etc. I don't remember the author.. Allas maybe?

Do you mean this?

http://www.atariage....262#entry699262

Yes it is it although it's not moving.

[José Pereira]

MaPa, on Tue Nov 9, 2010 8:42 AM, said:

analmux, on Tue Nov 9, 2010 8:31 AM, said:

MaPa, on Fri Nov 5, 2010 7:16 AM, said:

Me too, even that I implemented this technique somehow in an attempt to write some platform game with 8way scroll. As a base I took some source code which was presented here on Aage forum, it scrolled gr. mode 1 or 2 filled with letters A,B,C... etc. I don't remember the author.. Allas maybe?

Do you mean this?

http://www.atariage....262#entry699262

Yes it is it although it's not moving.

Hi, indeed it isn't.
But Joystick or the KeyPad on an Emulator. It moves in the 8directions smoothly...


José Pereira.

[Heaven/TQA]

Jesus... 2004? time passes by... unbelievable...