Horizontal bitmap scrolling technique

Hi!

I'm trying to implement an infinite horizontal scroll of a bitmap (not tiles), where anything that disappears on one side reappears on the other.

I'm not a game developer, so I'm probably not using the right techniques!

My initial idea was to make use of the two memory areas available for bitmaps (pages 0x60 and 0x8F).

At the beginning, my drawing buffer contains the complete image. I should be able to scroll it using a few areaCopy() calls (although I'm not entirely sure...).

Then, by changing registers 0x2F05 and 0x2F16, I swap the displayed bitmap buffer so that the newly generated image becomes visible.

My question is about what comes next.

I now need to prepare the next frame of the scroll. To do that, I need the image that has just been displayed back in my drawing buffer so I can continue modifying it.

My initial thought was simply to copy the currently displayed bitmap buffer back into the drawing buffer. Unfortunately, areaCopy() doesn't seem to support copying between different memory pages.

So I guess I'm approaching the problem the wrong way.

How would you implement this kind of infinite bitmap scrolling? Is there a better technique than the one I'm trying to use? (sure there is!)

There is no way you can scroll the full bitmap fast enough for smooth scrolling using memory copy. Copying 48000 bytes already takes an entire frame or so. And as you mention it would require partial copying to scratchpad first, then to the target, effectively dividing the (already limited) bandwidth by two.

Bitmap scrolling was sometimes acheived on some old computers by reprogramming the crtc (the scanning controller) to pretend the bitmap start address was at some other pixel position. That is unfortunately not possible on Micro-8, the page granularity does not provide pixel positionning.

On Micro-8, the only hardware-supported scrolling is for the tile layer.

Now what might be possible (not tested) is to scroll a limited portion of a bitmap (an horizontal band) using the blit function. With a smaller band to scroll, you can move the CPU window to be across the source and destination memory zone, so the blit can perform in one go. But depending on the size of the blit, it might still require double buffering to dilute the blit over several frames. Raster interrupts can be used to hide unwanted parts of the bitmap, or point to another static image.

Alternatively, if you want to create parallax effects, some sprites can be used behind the tiles. Multiplexing may allow to expand sprites vertically to cover more surface.

Hope that helps.


 

Thanks for your reply.

I succeed in making my scrolling from the bitmap (3 horizontal parts).
As you can imagine, it has a quite jerky effect (so early 80's )!
You can see it at : 

(bottom brown part is not bitmap, but tiles)

Anyway, for a start, I guess I will keep that like that, at least for a first version of my game.

To implement my horizontal scrolling in bands using tiles instead bitmap, I had actually considered using raster interrupts to do something like this: when the display reaches scanline 1, I would shift the tiles for the first horizontal band by a given offset. Then, when it reaches, say, scanline 100 (the start of the second band), I would apply a different offset, and so on until the last horizontal band.

But it seemed quite complicated to implement (and not sure if possible)... at least for now!

Excellent work !

Yes raster interrupts is the way to go for non-overlapping parallax bands of scrolling tiles. With static/slowly moving backgrounds possibly using bitmap and sprites as complement above and below tiles, I think a lot can be acheived.

At the end, I did my scrolling with tiles and raster interrupts rather than bitmap.
Not so easy!

It's a "4-band" tiles left scrolling.for a parallax effect.
There are also some sprites, but nothing to see with the tiles scrolling.

The result is here :


Unfortunately, sometimes, there are some "jerky".effects (maybe Franck has an idea?)
Really don"t know why..!
But that's not so bad!
 

Nice job.

Jerkiness might be caused by missing a frame? One way to measure the time taken by code is to change the background color (or any visible color) at the start of vertical blanking, rigth after the vSync(), and change it back at the end of the loop, right before the vSync(). The colored band should take less than the frame to ensure everything runs smoothly.