Simple corkscrew scroller in Blitz2

[idrougge]

I just read something on the Blitz mailing list to the effect that Blitz only handles blits in the background until the first bitplane is finished, then it sits waiting for the entire blit to complete.

[Shatterhand]

If you just turn off the debugger you don`t even need to make the bitmap higher. You just keep blitting the blocks with the new offset and it work, as blitting also wraps around the bitmap when you try to blit outside of it *and* you turn off the debugger. This seems to be a hardware feature to be honest.

Problem is, after you wrap around 22 screens (I actually got it at exactly 8192 pixels scrolled with a 384 pixels wide bitmap), the bitmap goes back to the initial positon (both horizontally and verticall). I am trying to make an infinite scroller here, but the hardware doesn`t want to help me

[Retro1234]

Apparently it is only with initCopList and is ok with Slice I never tried but after 8192 you could try and position to the new position off screen.

[Shatterhand]

Originally Posted by Retro1234

Apparently it is only with initCopList and is ok with Slice I never tried but after 8192 you could try and position to the new position off screen.

I tried that but then after sometime it does the same thing again, and its not at 16384.

Good to know it works with slice, though I haven't used slices for ages now.

Since what I am doing right now doesn't use much memory I'll be using the blockscroll + 2 screen width bitmap thing, less headaches to me.

This corckscrew thing wil workl if you don't need to scroll more than 20 screens. The other game I am coding won't scroll that far, so it works.

Blitz Basic is great, but sometimes it feels so bugged....

[Retro1234]

Originally Posted by Shatterhand

I tried that but then after sometime it does the same thing again, and its not at 16384.

Do you know what screen offset it is there might be a pattern.

[Shatterhand]

Around 68. I rewrote my code to do it differently, so I can't test it anymore. But it's easy to test it, I can share the code used it there's any interest.

[Retro1234]

Thanks for the reply I'll have a look some time but if it's only another 68 this would be a real pain to keep adjusting

[carrion]

Guys
Allow me to bring this topic once again.
I've started to code unlimited vertical scroll like in the vertical shooters.
The vertical approach is different that the horizontal one discussed here, so let me explain what I do and what I struggle with:

1. I have 2 screen high bitmap
2. start on the bottom half of the bitmap and show it on the screen
3. I start to scroll the bitmap (by using DisplayBitmap) and every 16 pixel lines I draw new tile line (16x16) at lower half of bitmap and another one on upper half of bitmap.
4. after scrolling full screen (224 in my case) I switch screen to show bottom part of bitmap
5. repeat

my problem is that after first switch of screen my procedure desynchronizes and I start seeing the tiles been rendered on screen, and normally it should be rendered off screen.
I know that without my code pasted here you won't help me right away but before posting my code I want to understand the overall algorithm with scrolling and to implement it myself.
I guess my problem is the number of counters I use to count when to put tile line on both parts of bitmap but again. The code is ugly and needs optimization, but for now it doesn't work IMO.
if you be so kind and help me with understanding the algorithm I'll appreciate a lot.
Of coz if needed I can post my code (+gfx I ripped off from Battle Squadron ) so you could see what I do.

Any help? suggestions? ideas?
TIA

[Daedalus]

You probably need a little extra space between the two screens, a buffer where you can always draw off-screen. So your bitmap would be 2 screens + 4 rows high, so that you can have half a row off either end of the display plus an extra row each side you can draw into. 3 rows extra would probably be doable if you were careful too.

If that's not the issue, it's simply a case of your calculations being a row out - perhaps when you wrap around you start 1 row up or something?

[Master484]

Yes, some "extra scroll space" is usually needed in a 2 bitmap scroller like this.

If you want to know the theory, then here is how I would do it.

So if the bitmap is 224 + 224, and tiles are 16*16 pix, then to this bitmap I would add a 16 pixel "scroll zone" to the top. So the actual bitmap becomes 224 + 224 + 16.

The extra scroll zone is needed, because when the last line of the top part has been scrolled, then without the extra scroll zone the bitmaps will look like this:

3333
2222
1111

EEEE - empty row
3333
2222

That is how the bitmaps would look if they were both 3 tile rows high, and 3 tile rows have now been scrolled. And in the screen we now see the top part tile rows "1111,2222,3333".

And now, if we do the View switch to the bottom part, we get out of sync.

But with an extra scroll zone, the same situation looks like this:

EEEE - extra scroll row

3333
2222
1111

EEEE - empty row
3333
2222

So now, we can draw tile line 4 to the extra part, and the same tiles also to the top row of the bottom bitmap. And then we scroll the extra row to screen, and then it looks like this:

4444 - Extra scroll row

3333
2222
1111

4444
3333
2222

So now we have scrolled to the extra row, and in the screen we now see lines 4444,3333 and 2222.

And now we can draw tile row 5 to that "1111" part, and then do the View switch to the bottom part.

And now scroll continues normally and everything should be in sync.

[carrion]

Gents
All this make sense.
Ihave to digest it and see what I do wrong, because at first sight it's more or less what I do. I'll be back...