Scrolling in bitmap modes on A8

[Jetboot Jack]

ok -- if I wanted to a game using Antic E or D on the A8, that scrolled, how could I do it?

 

Unlike text modes I can't just lay out my playfield in RAM and scroll over it...

 

Any suggestions?

 

sTeVE

[Nukey Shay]

I'm assuming that you are referring to horizontal scrolling, but then when you mentioned the bit about text modes (i.e. easy to do) it sounds like you want to do vertical scrolling.

Clarification?

[Sheddy]

Which aspects are you concerned about in particular, Steve?

 

I haven't ever done this over a full screen, but some things spring to mind that may be helpful (hopefully)

 

Unfortunately there'll be a need to do a fair bit of copying screen memory around in these modes - unless you have loads of memory to waste.

 

You can still hard-scroll over an area slightly bigger than the normal mode D/E screen - Just like mode 4, an LMS on every line. While that's happening you can be working on building up the next screen to display and hard scroll....could get awkward if the player decides, "hmmm, let's go back the other way" though - but of course you may not allow that possibility, and have a one way scroll.

 

If you want any reasonable size of scrollable playfield area without using up loads of memory, you'll need to create your own "tiling" system - IE a kind of virtual character mode - Make all the background composed of blocks of a suitable size - say 8*8 or 16*8, and give 'em a reference number. Then you store the reference numbers and relative positions in a table, and get the drawing routine to scroll through it, and draw them at the appropriate time.

 

It's a lot harder work to do than a character mode, and more CPU is required, but I expect a lot of the clever people here can figure out ways to greatly minimise that load (TMR has done a great side-ways shooter on C64 (which can't scroll the color attributes), so he must have thought about this a lot more than me!)

 

The great thing is, you have complete flexibility over the size of the "virtual" characters this way - you can pick whatever size is best suited to the background requirements.

[Heaven/TQA]

Steve,

 

depends on the game genre???

 

you can softscroll antic e like in charmode with $d404... but you would need to rebuild the whole screen ram every VBL if you want to do it smooth... and with sheddy's "tile system"...

 

vertical scrolling is easy... and i would do it like on atari ST... you have 1 screen with 160x208 f.e.. you visible screen is just 160x192 so 16 lines of buffer for building your screen... (assuming 8x8 tiles)... so while scrolling vertical (by subtracting or adding #40 to the LMS adress in the displaylist) you build up the buffer... after scrolled 8 lines...you now have to move the f... screenram down in memory to make the next buffer... and this would need 208x40 bytes to move... quite a lot?

 

if you are not scrolling fast then you can do this even with combination of double buffering... so f.e. you scroll just every 3rd or 4th VBL then you have more time to move the whole data...

 

but to be honest... i would not go for highres antic e scrolling games... that's why atari/c64/nes/gb/sega, etc... invented tile(char)mode...

 

hve

[TMR]

It's a lot harder work to do than a character mode, and more CPU is required, but I expect a lot of the clever people here can figure out ways to greatly minimise that load (TMR has done a great side-ways shooter on C64 (which can't scroll the color attributes), so he must have thought about this a lot more than me!)

 

The kind of scrolling i've used on the C64 for stuff like Warflame or Millennium Assault is easy on the Atari in character mode (i've got a prototype that uncompresses backgrounds from one of my C64 games to see if it'd work) but there are much faster ways of doing the work on the Atari that aren't available to the C64. As a proof of concept, i managed to get a 40x20 character area scrolling at a pixel a frame, full frame rate and it only needs about six or seven rasterlines of time to do the grunt work.

 

In theory, the technique used (it utilises an LMS on every line, as Sheddy said) could be expanded to handle a bitmapped screen mode but it would take significantly longer; the "arriving" column needs to be written twice so, for 20 characters high, that's 320 writes in total as well as overwriting the addresses in the LMS commands in the display list (another 160 writes if you lay the memory out carefully).

 

i've only been awake for an hour, if this doesn't entirely make sense please tell me... =-)

[TMR]

but to be honest... i would not go for highres antic e scrolling games... that's why atari/c64/nes/gb/sega, etc... invented tile(char)mode...

 

It can be done on the C64, look at Stormlord for example - although that's relying on the C64's abilty to move half a pixel a frame in that resolution to give it eight frames between refreshes and, after that, it's double buffering like a nutter. =-)

[analmux]

Okay, but let's set up a display Antic E with horizontal smoothscrolling enabled.

 

Vertical scrolling: Easy.

 

Use the technique called the "stripchart recorder" (it is described somewhere in a Compute book).

 

Although this applies for graphics 7 with exactly 4 kB screenram, you can just wrap the screen around vertically, because the antic will stay in a 4kB block. Only 40 writes per pixel to be scrolled.

 

Horizontal scrolling:

 

Make use of a special DList (I think that is what sheddy's talking about) that rotates through the 4 kB block. Because you probably want to scroll one pixel per frame, there is only 192 writes needed after every 4th frame. When 40 bytes are scrolled then replace the line that is highest in memory with the line that is lowest. In this way (with a bit of logic) you have practically a NES-like screenwrapper, where you just need to update the screendata on the boarders (that are outside the visible area, in the 4-bytes wide buffer area to the left and the right of the screen)

 

I will use this technique in my Mario game, in charmode 4, I'm about to finish.

 

About changin a DList for vertical scrolling: Make use of a DL that moves around in memory. When one line falls off the screen on the upper side, then only move the head and tail of the DList and increase/decrease the DL-vector, and take away only the disappearing line, and add the new line on the other side.

 

-----

mux

[Heaven/TQA]

yup... all true... but scrolling of bitmaps is in theory possible. kind of piece of cake for atari... but what if really used in an action game? and with limited RAM...so you can't precalculate and built the level data (tile2highres conversion)? updating/clearing/collision detection/... might getting more complicated and time consuming than with charmode... but i haven't tried yet... my only attempt in game coding with antic e was my small timepilot test... but i realised on real hardware that my sprite engine flickers.... more than on emulator...

 

or do you think, steve, on kind of zybex game???

 

hve

[TMR]

To be honest, i wouldn't like to try scrolling a bitmap with soft sprites - as i said, Stormlord does bitmap scroll on the C64 but it's all sprites for anything that moves independent of the backgrounds... Touchlight (an unreleased game that was the first to use AGSP scrolling) runs some bullets over bitmap as software sprites but that's about as complex as i've ever seen it get.

[Heaven/TQA]

steve...or are you talking about DROL kindagame? (btw... have to check the c64 version...)

 

hve

[Jetboot Jack]

Zybex and Ninja Commando horizontal scroll with software sprites. Scrolling Antic D/E seems to offer what I need for a planned project, but I just can't figure out the RAM overhead for starters...

 

Sheddy/Mux -- I kinda get what you are suggesting, but if I have a small write buffer on the right, as i scroll left, once I have written the buffer and scrolled over it how do I reset the entire screen and reuse the buffer, without taking too much time???

 

I thought about reusing an old technique we used in char mode -- this is what we did in Beast -- we had 2 seperate displays of Antic 5, each made of 12 modelines of Antic 5 display set to 48 bytes (or maybe 60).

 

We displayed one screen area -- and uncompressed our map data to paint the buffers (left and right depending on the player's input, because we allow srolling in either direction) with characters.

 

We scrolled for 2 bytes at 30hz, then flipped to another display we had been updating per-frame to look like the "scrolled" version of the current display, but with the buffers refilled to and the screen set to "neutral" again.

 

The only overhead is building the "other" display -- we spent either 18 or 20 bytes per-frame for each of the 16 frames of scrolling -- rebuilding the second display...

 

The problem is you have to multiply the whole thing by 2 for antic 4 and by 8 for Antic D -- thats 128 bytes per frame at 30hz, then add in four 2 by 12 byte s/w sprites say for another - 144 bytes (inc buffer for horizontal movement) is this realistic per frame -- 200 bytes?

 

What I want is horizontal scolling with numerous sprites as elegantly as Zybex. And I cannot imagine how to do that with char mode s/w sprites -- I know Black Lamp does it, but I can't figure that out either

 

sTeVE

[Heaven/TQA]

ah... much clearer now Steve,

 

any reason for doing it not in charmode? (except for simplicity...)

 

any ideas how big your area will be at all? maybe you can decompress the whole shit in RAM? what is the normal "size" of a horizontal shooter? 8 screens? (even this would just need 8x4kb = 32k total...)

 

TMR how many screens do you scroll in your shooters nomrally? f.e. how many does uridium have? (i can remember that the space ships are not so large as they seem when scrolled...)

 

hve

[TMR]

From memory, Uridium is using 3x3 character tiles and has about 11 or 12 screens per dreadnought with a screen of run-off space at each end.

 

My stuff is mostly based on column compression and it's fairly open ended; Warflame has 12.5 screens per level, Millennium Assault averages out at closer to 20 (the levels are different lengths) and Co-Axis is the most primitive implementation at just over 6 screens a level (each level is 256 bytes long).

 

The thing is, my games are technically scrolling at half a pixel a frame in 160x200 mode so 6 to 10 screens is a reasonable length for a level - either the Atari has to drop scroll cycles or move at twice the speed, the former looks a bit rough to my eye (but not to everyone, it's a tough call to make) and the latter will need about twice the data for the level to "feel" the same length. At a set speed of a pixel a frame, i'd say about 16 to 20 screens is a good length.

[analmux]

Okay, but if you use tiles the size of 4*4 Antic 4 characters you'll only need to update the buffer once in 16 frames. I'm refering to a horizontal shooter.

 

16 frames= 16/60 * 1789790 cycles = 477277 cycles to use for building a strip of 4*24 Antic 4 characters at the borders, which is equivalent to 4*8*24=768 byte-writes, plus some additional logic for decompressing and manipulating the Display List. Should be far enough!!.

 

In this way you should easily be able to make Turrican like games in bitmap mode Antic E.

 

the really nice thing of this technique is off course that you wouldn't need double buffering. The buffer is in the invisible part of the screen.

 

Let me work on a demo, I'll show that it's very easy.

You'd only need 8kB of screen memory.

 

vertical scrolling though would be a real pain in the ass, because in Antic E you must worry about the second LMS in the middle of the screen.

 

-----

mux

[analmux]

By the way, do you know the atari 8bit game "Feud".

 

It looks like it's in Antic E to me. It seems to have a lot of graphics.

 

-----

mux

[Heaven/TQA]

but feud does not scroll??? like spellbound, spindizzy, starquake etc...

 

all do not scroll...

 

hve

[Sheddy]

I think Analmux is talking about about something like this? I wasn't quite thinking along the same lines to start with, but his idea should work out better.

 

Horizontal scroll:

2 normal screen widths. Grey box is memory area. black box the visible screen. Change the LMS pointers every 16 pixels to next lot. Draw just ahead, and prepare the screen behind. Get to the end of the memory area, and wrap back to the start again. Shouldn't be any problems with 4K boundaries either

[Sheddy]

Will it work if we scroll back the other way though???..........no, too late for me, can't get my head around it tonight...

[analmux]

@ Heaven

 

but feud does not scroll

 

You're right. It's a long time ago I played it , Thought it DID scroll.

 

-----

mux

[Jetboot Jack]

Sheddy -- what about double buffering these displays for smooth s/w sprites?

 

How much data shifting would that to this type of scroll?

 

Sometimes these concepts are hard for game designers to get their heads around

 

sTeVE

[analmux]

@ Sheddy

 

I think Analmux is talking about about something like this? I wasn't quite thinking along the same lines to start with, but his idea should work out better

 

Yes, that's a bit what I mean, except, you'd need 16 kB screendata. Nice pictures you made .

 

I thought about this method last weekend. It must be possible to do this in both directions, that's for sure. But I stepped off of this idea. It needs twice as much RAM.

 

I'm working on a Super Mario clone, which plays in ONE load from disk with 40 big levels, so I had to minimize the amount of RAM needed for the screen. Though it's in charmode 4, I had just about 1500 Bytes left for the screen, so I'm using a different technique, which can be applied in Antic E too.

 

It's based on some Display List hocus pocus, splitting the screen in a way you don't have to worry about the LMS bullshit. It's usable for both horizontal AND vertical scrolling.

 

You know, when you make a scroller you MUST take care of where the graphicsline BEFORE the LMS-line ends. But I don't. I just make two identical lines in different memory locations to solve the problem. So for the exceptional lines there's always one copy somewhere else.

 

The exceptional lines are not only lines before LMS but also at the line with the highest address, so the line after.... forget it, it's too complex , I'll make some pictures to demonstrate this soon.

 

It's kind of a complex way, but it saves the most time AND memory.

 

-----

mux

[TMR]

Sheddy -- what about double buffering these displays for smooth s/w sprites?

 

It's do-able, but you're looking at close to 30K for a bitmapped screens (each buffer takes two screens) - if you work with software sprites over characters that, obviously, reduces the load considerably.

 

How much data shifting would that to this type of scroll?

 

For characters, X*2 bytes every four frames if scrolling at a constant 1 pixel a frame speed; X is the height of the screen in characters, so a 40x20 area only needs two columns of 20 bytes (identical) written back to two places in the map. Multiply that by 8 for bitmap, assuming a 160*192 screen mode or 4 for 160*96.

[TMR]

Horizontal scroll:

2 normal screen widths. Grey box is memory area. black box the visible screen. Change the LMS pointers every 16 pixels to next lot. Draw just ahead, and prepare the screen behind. Get to the end of the memory area, and wrap back to the start again. Shouldn't be any problems with 4K boundaries either  

 

No problems at all, i have a fixed speed 40*20 character screen scroller running in sub 8 pixels of raster time using the same technique.

[Heaven/TQA]

the diagram looks like the No$ gb emulator when looking at the debug tile map...

 

so... actually you have to draw 2 strips. on the right side of the "window" and on the left side... otherwise you would need to shift/copy the complete screen back to position 0 when reaching the ride side of the buffer?

 

hmmm.... why the hell do i not have time to code...

 

hve

[TMR]

Mine writes a new column to the left and the right of the viewing window once every four frames (scrolling at a pixel a frame). My prototype NES scrolling routine works in almost exactly the same way, it seems to be the norm on the NES... =-)