Simple corkscrew scroller in Blitz2

[ReadOnlyCat]

Originally Posted by Boo Boo

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

I think it should be able to do it as is.
There are only 16 small blits covering an area of 16x256 pixels and that is nothing for the Blitter, even a CPU copy would do it under one frame.

If the overhead of the blit function is so high that it prevents 16 small copies to run in one frame then Blitz would have a hard time to run an actual game so I suspect the issue is the Print statement.

[Retro1234]

Taking out Print works and its fast
Load in the megaman tiles

[Retro1234]

If you add another wait vbl you can also print
So I just If mouse button, print on Debug screen, wait vbl

[idrougge]

Originally Posted by ReadOnlyCat

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

Actually, it was Mr. ComputingData that raised my attention to this technique in this thread.

[Retro1234]

and it was MrsBeanbag that told me - wierd post - Do not start trolling me.

The print command also has an inpact in Amos but I would say not to this extent.

load in megaman tiles if no one does it Ill generate a map and tile set - some array to read them

So ill have a look later but you want something like

Do
If Joy Right call idrougge code
Loop

positioning Bobs shouldnt be any harder this is the same as the jump back method but you just dont jump back - but when a Bob crosses that point you might have to Bob clip

Originally Posted by Samurai_Crow

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

Of course its about speed otherwise we'd use screen copy? this is just a easier way of doing hardware horizontal scrolling - what you wanted to charge to program idrougge has given away for free

[Samurai_Crow]

Huh? I need payment only for my time. Not for the library I was going to write.

Also, speed is always a concern using the blitter, but hop-back is nearly as fast with more flexibility. Relative to that, memory usage is a concern in favor of the corkscrew.

[LuMan]

I've done a bit more fiddling with a tile-strip scrolling approach. On an A600 I can scroll left and right, for a playable area of 3 screens wide and 2 screens high, using 2 bitmaps of 384x512. The bitmaps will remain the same regardless of how big I make the play area, so I could do 20 screens wide if I wanted to. But this demo does have full 8-way scrolling

The play area is read from an array and is currently just a load of 1's and 0's that I typed in without thinking about it, but it proves the concept works.

When using a single-pixel scroll, there is a little bit of judder as the BlockScroll kicks in, but by using VWait 2 for normal scrolling, then a single VWait for the BlockScroll, and moving 2-pixels per frame, things look a bit smoother.

The code is still on my A600 at the moment, so I'll make the map array a bit more meaningful and move it to my Mac, so I can upload it tomorrow. The Megaman tileset can easily be added if anyone wants to create a map out of it.

EDIT: Oops! I tried tightening the code a bit, but now it's gone all nasty when moving left. I'll fix it and then post it.

[carrion]

Guys
let me bring this subject once again. I think I understand all previous posts and threads especially ReadOnlyCat's detailed explanation so I thought I code it.

And it works more or less. I setup a bitmap 320+32 I scroll it from right to left and put a line of tiles (from binary map in Dim).
I roll the screen and put the vertical line of tiles on positions incremented by 16 (16x16 is the size of tile)
the problem is when the scrolled screen closes to 320 it starts to show the vertical line of newly put tiles on the left side of the screen. as the scrolling is too fast for tiles line to put and the tiles put procedure lags behind it

sorry i can't describe it better.
please refer to the executable file I've included. (it works on a500 and a1200 fs-uae)

why is that? I'mean I think I know at some point the put-line-of-tiles procedure starts lagging but why? my algorithm is like this:

put a vertical line of tiles on position x=0
loop:
scroll 16 pixels
put a line on x=x+16
repeat loop:

so? any ideas what I do wrong?
oh and i tried bigger screens like 320+320 to see when in starts to lag but it always happens sooner or later

TIA

[idrougge]

1. You're not masking your screen correctly
2. You have a logic problem concerning the calculation for where the next blit should begin.

[carrion]

that obvious but what do I do wrong?

[idrougge]

Easier to say if you posted your code.

[carrion]

There you go:

;----------------------------------------

#TILEWIDTH =16
#TILEHEIGHT=16

mapScreenWidth=20
mapScreenHeight=15

mapWidth=40
mapHeight=30

mapStartX=0
mapStartY=0

;----------------------------------------

WBStartup
CloseEd

;NoCli

INCLUDE "tilemap.bb2"

a$="data/map2.bin"
loadBinaryMap{a$}

BitMap 0,320+32,240,4
LoadBitMap 0,"data/tiles1.iff",0

BLITZ
InitCopList 0,44,240,$14,8,16,0
CreateDisplay 0
DisplayPalette 0,0
DisplayBitMap 0,0,16,0

For i=0 To 16
  GetaShape i,i*#TILEWIDTH, 0, #TILEWIDTH, #TILEHEIGHT
Next i

  GetaShape 17,16,16,26,32
MakeCookie 17

Cls


;----------------------------------------

Statement drawTileColumn {x,column}
SHARED tileMap(), mapScreenWidth, mapScreenHeight, mapWidth
i=column : y=0
    Repeat
        t=tileMap(i)
          Block t, x*#TILEWIDTH, y*#TILEHEIGHT
          i=i+mapWidth
          y=y+1
    Until y=mapScreenHeight
End Statement

;----------------------------------------


dx=080 : dy=100
mx=0 : my=0

startX=32

frame=15

While Joyb(0)=0
  VWait
  UnBuffer 0

    dx=dx+Joyx(1)
    dy=dy+Joyy(1)

    DisplayBitMap 0,0,startX+mx,my

    If col <> mapWidth
        If frame=15

          drawTileColumn { QWrap(counter,0,22), col }
          counter=counter+1
          col=col+1
          frame=0
        EndIf

    VWait


        mx=mx+1
        frame=frame+1

    EndIf

Wend

AMIGA
End

[idrougge]

Whenever you reset the "frame" variable, it is immediately incremented from 0 to 1. That means it only does 15 iterations before blitting a row instead of the 16 you expected.

[carrion]

damn, you're right...
thanks a lot for helping me with this. will get back home and try to reimplement this part

btw: anyone tried / thought about a Zelda like game for Amiga 500?
I'll try and this is the first tests.

[Anakirob]

Originally Posted by carrion

btw: anyone tried / thought about a Zelda like game for Amiga 500?
I'll try and this is the first tests.

There are a few for AGA Amiga's, but I'm not real sure that OCS/ECS Amiga's ever got such a game. And I must say I was not particularly impressed with either Legend or Speris Legacy anyway. They aped Zelda's look, but somehow managed to completely lose the gameplay.

I haven't played either of them, but I think that Tales of Gorluth 1 & 2 will run on an A500, but they ARE backbone games (which is why I have not bothered with them), so they probably don't play very well on a standard A500.

Here's an idea I would like to see implemented in an Amiga game: I notice that there are a large number of PC games with procedurally generated levels released in recent years. "Rogue-Like" is a common term for this, and does not necessarily mean a turn based RPG like it used to. Anyway, randomly generated levels seem to keep gameplay interesting and vastly increase replayability.

If you could combine that with your Zelda idea then that would be one game I would be most eager to play.

[Lonewolf10]

Originally Posted by Anakirob

Here's an idea I would like to see implemented in an Amiga game: I notice that there are a large number of PC games with procedurally generated levels released in recent years. "Rogue-Like" is a common term for this, and does not necessarily mean a turn based RPG like it used to. Anyway, randomly generated levels seem to keep gameplay interesting and vastly increase replayability.

That can be good, but depends on the game.

There was a first person shooter on the Atari Jaguar that had randomly generated levels, but would occasionally create impossible levels. The same was true for F-Zero 64 on the Nintendo 64, which is why it was left as an option, rather than part of the main game.

[idrougge]

Let's stay a bit on topic, shall we?

Regarding Zelda style gameplay, that usually implies four-way scrolling. I don't think anyone's implemented corkscrew scrolling with vertical scrolling in Blitz — it requires that you split the screen.

[LuMan]

This topic is up again? IIRC there were a number of discussions about the best way to scroll an Amiga screen in Blitz, most of them very useful.

I still maintain that the 'best' way to do any scrolling is to make a massive super-bitmap and use the XY offset of Slice, DisplayBitmap, (or your favourite command) to view the screen-sized area of the map that you need to see.

However, this can be hugely inefficient from a RAM viewpoint, hence the novel ways of writing blocks of playmap every 16 or 32 pixel-scrolls.

If you can do it, a simple, 8-way approach can be got by using a 3x3-screen bitmap and starting the gameplay in the middle:

XXX
XOX
XXX

Set your initial XY offset (for a 320x256 screen) to 320,256 and you'll be where the 'O' is. Once you've scrolled either +-319 horizontally, or +-255 vertically, re-draw your super-bitmap and plonk yourself centrally again.

It works on an A1200 with an 040/25, but you may find a bit of stutter on anything less.

A year or so ago I managed a never-ending scroller in 8 directions by BlockScroll-ing 32px tiles into an off-screen border, depending on the direction of scroll. You could easily use a simple array to organise a 'proper' Zelda-like map and have something pretty massive.

My Amiga's in storage, but I may have a copy of the code on my Mac. If I can dig it out I'll post it for interest.

Good luck with your project, Carrion. Please let us know if you get a demo done

[Anakirob]

Originally Posted by LuMan

It works on an A1200 with an 040/25, but you may find a bit of stutter on anything less.

Correct me if I'm wrong, but using Blitz functions wouldn't this method be far more blitter intensive than CPU intensive, and therefore run at the same speed regardless of processor? If not, then one can always compromise on the frame rate and update the screen every 2 or 3 vertical blanks for stability.

[LuMan]

@Anakirob - Not sure. But I ended up amending my draw routines for the A500 after having it work perfectly on my A1200 040/25. I tried a couple of approaches, but the faster Amiga was definitely faster.

One thing I did try was only blitting one off-screen tile per pixel scroll. So, if I scrolled at 2 pixels per frame, I would have 16 chances to blit as many 32px tiles as I needed. I could blit about 4 per frame without any slowdown. A diagonal scroll would require 19 tiles for a 320x256 screen (10 across, 8 down, and one for the corner). Easily done in 5 frames