Simple corkscrew scroller in Blitz2

[idrougge]

There has been talk in several threads about scrolling techniques, and one which is very promising is the so-called corkscrew scroll. This has been described in depth in depth in http://aminet.net/package/dev/src/ScrollingTrick and some have already investigated its feasibility in Blitz Basic.

Here is a very basic implementation. It scrolls for ten screens using only a bitmap 352 pixels wide and 256+10 pixels high. This exploits the fact that soft scrolling on the Amiga only offsets a starting pointer into a bitplane. Since Blitz's DisplayBitmap command doesn't do any bounds checking (thankfully), it can be incremented beyond the width of the bitmap scrolled, upon which it "wraps around" to the starting position, but one pixel down. So if you allocate an extra pixel in height for your bitmap (for each screenwidth scrollable — in this case ten), the bitmap is offset down, and all you have to do is blit in new background blocks in the currently obscured part of the bitmap (it's two blocks wider than the visible screen), offset one pixel down for each screenwidth scrolled.

Thanks to ReadOnlyCat, MrsBeanBag, Shatterhand, Luman and others for discussing this in depth in previous threads.

#BORDER=1
.makron
Macro Border
  CNIF #BORDER=1
  MOVE.w #`1,$dff180
  CEND
End Macro

.init
DecodeShapes 0,?font          ; Incbinned below
#SCRWIDTH=320
#BLOCKWIDTH=16
#BMWIDTH=#SCRWIDTH+#BLOCKWIDTH+#BLOCKWIDTH
#SCREENS=10
BitMap 0,#BMWIDTH,256+#SCREENS,4
BitMap 1,320,10,1
shapenr=1
Use BitMap 0
For y=0 To 256-16-1 Step 16
  For x=0 To (320+16) Step 16
    Block shapenr,x,y
  Next x
  shapenr+1
Next y

BLITZ

For i=0 To 15 : PalRGB 0,i,i,i,i : Next i
PalRGB 0,1,15,15,15
InitCopList 0,44,240,$14,8,16,0      ; lores, 4 bpl, 8 spr, mjukscroll
InitCopList 1,44+240+2,$10,$11,8,2,0 ; lores, 4 bpl, 8 spr, mjukscroll

BLITZ                          ; Enter Blitz mode
BitMapOutput 1                 ; Write debug info on little screen
CreateDisplay 0,1              ; A screen with coplist 0 och 1
DisplayPalette 0,0             ; Use palette for bitmap 0
DisplayPalette 1,0             ; Use palette for bitmap 1
DisplayBitMap 1,1              ; Make debug screen visible

.finscroll
#VBL=1
#SCROLLSPEED=1
xscroll=16  ; Scroll position, increments infinitely
x=0         ; X position for blitting, reset upon each wraparound
yoffset=1   ; Y offset for blitting, incremented for each wraparound
Repeat
  VWait #VBL
  DisplayBitMap 0,0,xscroll,0
  If xscroll MOD #BMWIDTH = 0
    !Border{$ff0}
;    MouseWait
    shapenr+1
  EndIf
  If x=320+16+16
    x=0
    yoffset+1
  EndIf
  Locate 0,0 : Print "Xscroll: ",xscroll,"  X: ",x,"  yoffset: ",yoffset
  If xscroll MOD #BLOCKWIDTH = 0
    !Border{$f00}
;    MouseWait
    For y=0 To 256-16 Step 16
      Block shapenr,x,y+yoffset
      ;Line x,y+yoffset,x+15,y+yoffset,3
    Next y
  EndIf
  xscroll+#SCROLLSPEED : x+#SCROLLSPEED
Until JoyC(0)=2
End

.font
IncBin "Data:BB2/font.shapes"

Note that this is very rough around the edges. It looks boring, there is debug output, the blitting of blocks isn't spread out in time so it doesn't run smoothly and there is no provision for scrolling in the opposite direction. But it goes to show that horizontal corkscrew scrolling is quite possible in Blitz2.

[Retro1234]

Well done you could have commented it
Is it actully any faster than Amos?

Why do most examples allways use screen copy when we know this is wrong?

: Lot of Flicker on 68000 - id say not better than Amos and about the same on 68020 - but Bobs are better in Blitz 2 but if you animated your Tiles instead of Bobs in Amos you could probably reach the same.

Maybe try FBlit with BlockScroll - ill have a look some time but the Blitz 2 Syntax is Yuk!
^ on faster processor - but no need this will work on faster processor

[idrougge]

I've only tried it briefly on my A4000 with an LCD screen. No discernible flicker there. But I know from before that AMOS can't really blit an entire row of tiles in one vbl while also printing on the screen.

[Retro1234]

Flicker only on 68000 -Yeah a whole row is to much on 68000 even in ASM
maybe ask Graham how he did downfull

this video is on 68030@40 I uploaded a video of 68000 but my Archos didnt do it justice in the top corner you can see 17 thats 17 Amos waits,Double Buffer Two Wait Vbl, 32 colour and still to fast.
If you want ill get you a compiled version at some point
[ Show youtube player ]

[Cylon]

It is nicely running. but from around xs=8000 and up the bmap gets trashed from the top.

[idrougge]

8000? Xscroll should never go that far with the debugger on, only around 3000.

[Retro1234]

Im not having a go at you but thats a 16 colour screen, scrolling 1 pixel and a 1 colour tile not reading a map and it doesnt work on 68000 not very fast is it.

[idrougge]

Where did I say it was fast? It's a proof-of-concept, not an arcade game.

[Retro1234]

I know and I wasnt questioning you but where is there an example that Blitz can handle a Map at a good speed?

[idrougge]

Not here.

[Retro1234]

Ok.

[LuMan]

Good going, idrougge. There was a LOT of discussion about this topic - and other scroll methods too - so another example of a technique is a really interesting read.

@Boo Boo - check The Zone for a proof of concept game I threw together. It has a never-ending scroller that uses a bitmap that is only one block (16 pixels, I think) wider than the display. It also uses BlockScroll to copy a full game screen in one VWait. I'm currently re-writing my GogoPogo game to use the same approach. Blitz should be able to handle this on an A500 (although I've only tested it on an A600).

[Retro1234]

Now that is faster than Amos equivalent
But just use your tiles in his code and change untill it works that should be full hardware scrolling.

[Samurai_Crow]

The point of the corkscrew wrap around isn't speed so much as saving chip RAM.

[Cylon]

Yes, the ChipRAM issue is the true problem. Scrollspeed is not an issue with BB2, as Blitz has Copper"scroll" support. I have a horizontal scroller as well, but it uses double width bmaps (16cols) plus a really wide second bmap as parallax background (aga dpf). I have to chg that someday to another 8way-engine, but who has the time...

[Retro1234]

I think it will work if you build on itl.

[idrougge]

Originally Posted by Samurai_Crow

The point of the corkscrew wrap around isn't speed so much as saving chip RAM.

Yes, but the only scroll method that is more speedy is scrolling a prerendered bitmap. Corkscrew only blits new tiles on one side whereas other infinite scroll techniques draw the same tiles on two ends.

What makes corkscrew quite difficult is not the plain scrolling, but placing your bobs. Position X on the visible screen is not straight-forward to calculate, and once every wrap-around, it is at the end of the bitmap, which requires two partial blits to take the Y offset into account and must also be clipped so that the Blitz debugger doesn't halt because you're blitting outside the bitmap.

[Retro1234]

This will work and already works on 68020+

[ReadOnlyCat]

The code looks really good with no extra fluff and is very readable.
I see no reason why Blitz could not handle drawing a full column of tiles every 16 pixels, maybe it is the

Print

that is slow?

Also, you should also credit CodeTapper, it was he who first mentioned this technique in the scrolling thread started by Akira.

[Retro1234]

It probably could if you double buffer but change it to one tile per pixel take out the print command and load in megaman x Tiles