Hardware scrolling question

[oRBIT]

Assume this scenario:
Two screens, horizontal scrolling. When screen 2 has passed, it automatically goes back to screen 1. Loop.
I am no graphics-hardware-guru at all, but is there a clever way of doing this without blitting?
Last time I tried this (>10 years ago ), obviously there was a problem when going from screen 2 -> screen 1 (screen 1 was one vertical line off, due to the nature of bitplanepointers & hardwarescrolling).
Anyone understand what I mean?

[nandius_c]

I can't see the problem though I'm not an experienced Amiga coder at all so... Isn't it enough detecting when you have arrived at the end of screen 2 and, then, reset bitplane pointers to top left corner of screen 1? I think you wouldn't even have to reset BPLCON1 if screen width is 320 as it would be looping from 0 to 15 and back to 0 (this would also happen at the end of screen 2).

[Kalms]

One option is to just continue scrolling, and never jumping back. This will make your screen gradually progress through chipmem so it only works if you will scroll a finite distance. If you do this then you do not need two full screens' worth of space; you just need some extra space for soft-scrolling and whatever you need to make your background & bob rendering code simple.

Another option (which is probably what you were thinking of), which allows infinite scrolling, is to have two screenbuffers just like you do now, but when you have reached screen 2, you jump back to screen 1. Now, instead of doing a full blit screen 2->screen 1 when it's time to jump back, you distribute that rendering cost over several frames. One way of doing that for backgrounds is, when you draw some new background graphics, draw it both to screen 1 and screen 2. When you have scrolled all the way to screen 2 this will result in screen 1 having identical background contents, and you can jump back there (just needing to redraw any dynamic content first).

[phx]

It's not completely clear, but I assume the key points are:
- scroll an area, which is two screens wide (i.e. 640 pixels), horizontally to the right(?)
- scroll in an endless loop, so it starts with pixel 0 again, after pixel 639
- the bitmap is static and will never change, no Blitter use

The easiest solution would be to use a bitmap area which is three screens wide and you have to make sure that the last screen and the first screen are identical.

This makes it possible to scroll from offset 0 to 639 and reset the bitplane pointers to offset 0, when reaching 640.