8 way scrolling for JRPG game

[Marle]

Hiya,

Following on from my previous thread I have been doing a lot of reading on how to accomplish 8 way scrolling over the past couple of weeks and think I have exhausted everything but I've hit a bit of a roadblock.

Most people suggest downloading some C code off Aminet relating to scrolling and there is a demo that does do what I want but I cannot make head nor tail of the code and what it's doing.

The basic premise so far I can work out is to allocate a bitmap the size of the screen (e.g. 320x256) + 2 * the tile size on the width and height, so you'd end up with a 352 + 288 bitmap with a 16 pixel square tile size.

And start the game bitmap at location 16,16 on the display.

And when you get to the extreme say right edge (X = 352), blit a column of the map's tiles to X=0 on the bitmap and allow X to wrap from 352 to 0 using QWrap and DisplayBitMap.

This has sort of worked but I notice that when this happens, the Y position of the bitmap seems to shift up 1 and it only returns to its 0 Y position when the left most edge of the bitmap is at X=0 again. (if that makes sense??)

On top of this, adjusting the Y position of the bitmap via DisplayBitmap causes all sorts of screen corruption rather than wrapping around.

Essentially I want to be able to build map files for a JRPG idea I have for the Amiga, but whatever I code, doesn't seem to work.

I've attached some code that uses the cursor keys to move the display around, even if I change DisplayBitMap and set the Y offset to say 240, I get the display corruption.

I'm assuming I may have missed something with the InitCopList or CreateDisplay kind of stuff?

I have read quite a few threads on here on how to accomplish this and also some source code but none quite answered the problem.

And this is before I've even written a routine to read a map file, render the screen...

I'm just working from the basis that there isn't much of a good reason why a JRPG can't be done on an Amiga OCS/ECS machine apart from time, writing a good story, doing some nice graphics....(i.e. all the game writing bits lol)

Thanks!

[Daedalus]

What's happening here is you're trying to display way beyond the bounds of your bitmap. This is forcing the Amiga to display whatever garbage is in the nearby memory you scrolled into - in some cases this happens to be another part of the same bitmap, which is why you see the same data shifted one pixel vertically. If your bitmap is 352 pixels wide, it's only 32 pixels wider than the screen, and so you can only scroll 32 pixels to the right before you run out of bitmap to show. What you really need for what you're trying to do is to have a bitmap that's two full screens wide, plus the two columns for drawing new tiles, plus a buffer column for reversing, so 320 + 320 + 32 + 32 + 16. It's quite a big bitmap but perfectly doable. Same for the height - 256 + 256 + 32 + 32 + 16.

This should let you draw one column and row gradually so you don't have to blit all the tiles at once, and will let you do practically infinite 8-way scrolling, limited only by the map you load.

[Marle]

Thanks Daedalus

Ahhh, this is the problem of reading bits here and there and not really knowing how the hardware functions. I think I was under the impression that the hardware automatically wrapped the bitmap when the X or Y position was at an offset that would cause it to 'overflow'.

It is quite a big bitmap, but just exploring ways to make this work. There are many problems yet to solve especially if I am going to try and keep this an OCS/ECS compatible game, it appears that AGA does have some benefits such as more colourful sprites that can use a palette that the main bitmap isn't using, and more colourful dual playfields but I was hoping I could do something with the original hardware specs.

But we'll see.

Hopefully I'll get my 8 way scroller working in the next few days now I have some helpful information!

Thanks!

[Daedalus]

No problem Just bear in mind that the technique I described is one I've used, and consider conceptually relatively simple and therefore easy to implement. But there are other methods that might be better performing or use less memory or have other reasons for being preferable. The C code you were referring to on Aminet contains some nifty tricks, but are also trickier to implement and some have tight restrictions on what you can and cannot do. Still, it's worth a look because the demo executables will give you a good idea of what's possible with what resources.

[Marle]

Totally not done any work on this for a month or so now, but just starting again.

I have to say I'm still confused really, or tired, that can sometimes end up with the same result

I understand why previously the issue of display corruption was happening but I am a bit lost with why each screen worth need's 16 pixels either side, why not just one screen's worth? And what is the extra 16 for the reversing to do with? I am probably being especially thick.

I'm drawing it on paper but I can't quite make sense of even the basic pseudo code I am trying to write. Not a great start is it!

I'm struggling to work out how this ends up having reached say X position of say 720, and then scrolling another pixel to the righht makes the X value 721, outside the bounds, so how do you get it so that the right most 1 pixel wide column is coming from the bitmap at x=0.

I just can't seem to get my head around it :/

[saimon69]

First of all, Amiga is a 16 bit machine so 16 is the minimum size of a tile that can be display in the most fast and efficient way by the blitter; then the second side of the trick is that once you scroll 16 pixels you should reset the scrollcounter 16 pixels back (will look like you still there) and so on - that until you don't reach the end of the map - am explaining it in a messed up way but hope you can picture it

[Retro1234]

this describes it pretty good

Originally Posted by Coagulus

1000 pixels should be more than enough for a smooth horizontal scroll. I used to have a screen twice as wide (as a 320 screen, it was about 720-ish I think) and scroll across 1 pixel at a time blitting 2 tiles per frame (one offscreen to the left and one to the right to give a perfect copy when I looped the screen). This worked fine and quick.

You also use this for vertical scrolling

ultimately if you implement both when to scroll down diagonally to the end your bitmap has 4 equal parts looking the same.

[Daedalus]

Originally Posted by Marle

I understand why previously the issue of display corruption was happening but I am a bit lost with why each screen worth need's 16 pixels either side, why not just one screen's worth?

It's 16 pixels because that's the tile size you're dealing with. As explained above, 16 pixels suit a 16-bit blitter, so multiples of 16 get the maximum performance out of the system, leaving the most time for doing other things. What you're doing is drawing the new column of tiles a full 16 pixels clear of the edge of the screen. This means that you've always got a buffer of 16 pixels to the right of the screen (assuming you're scrolling right), so that the part you're drawing is never actually visible. When you've almost scrolled fully into that 16-pixel buffer, the next 16-pixel wide column should be finished redrawing, thus becoming the next buffer and letting you start the next column along. This is where the two sets of 16 pixels (32) comes from. If you want to scroll the other direction, you need the same on the other side.

Now, that takes care of the scrolling itself up until the edge of the bitmap. The reason you need two full screens is that once you start to move beyond the edge of the bitmap, you have to flip back to the start of it again. So in one frame, you're viewing the very right of the bitmap, the next frame you've moved one pixel to the right, but are actually showing the very left of the bitmap. Having two full screens of space means that you can already have the left of the bitmap prepared for this jump before it happens while you're viewing the right hand side, so when you do jump, it's seamless to the user. So effectively, just before you run out of bitmap, the left of the bitmap should be the same as the right of the bitmap except for being one pixel further along the map. To achieve this, you essentially draw each column twice - one 16 pixels ahead of the scroll, one 16 pixels behind.

And what is the extra 16 for the reversing to do with? I am probably being especially thick.

No, don't worry, these are tricky concepts to visualise if you haven't worked with them before (especially if you're tired). The extra column for reversing is to give an extra buffer between the display and the portion being overwritten. It's not strictly necessary, but it makes the maths and organisation a little easier because you don't need to worry about reverting a partially drawn column, you can just overwrite it as normal.

I'm drawing it on paper but I can't quite make sense of even the basic pseudo code I am trying to write. Not a great start is it!

Drawing it on paper is a good start

I'm struggling to work out how this ends up having reached say X position of say 720, and then scrolling another pixel to the righht makes the X value 721, outside the bounds, so how do you get it so that the right most 1 pixel wide column is coming from the bitmap at x=0.

Well, it's actually quite easy - just tell it that that's where it is. You will need two counters, one for your view position and the other for the bitmap position. The view position can keep increasing and you might use that for your position within a level for example, but the bitmap one will reset to 0 once it reaches (bitmap width - display width). This should occur at pixel 400 on a 720-pixel bitmap (720 - 320 = 400). So just check your new bitmap-x position when you move and check if it's 400 or above. If it is, subtract 400 to get 0. Likewise when moving left, if the bitmap position ends up lower than 0, just add 400.

If move_right
  levelpos + 1
  bmappos + 1
  If bmappos >= 400 Then bmappos - 400
End If

If move_left
  levelpos - 1
  bmappos - 1
  If bmappos < 0 Then bmappos + 400
End If

There is an alternative method for doing this too that's a little more efficient (Using the Modulo operator), but for now that should do to get it working.

[Retro1234]

@Daedalus iirc correct you can also use the wrap around for 8way but you have to mirror it for the vertical to work?

[Retro1234]

Also when you scroll down right diagonally the ultimate test to the end and then reset to x0 y0 is your image fully made and not tiles missing?

I think there should be a formula for this Screen-Bitmap size vs displayed size = number of tiles that should he drawn per pixel scrolled ? including bitmap size for buffreing for reverse

[Daedalus]

Yep, the same applies for vertical, you just consider the width and height of the display to be the screen size plus two tiles. This will ensure you have the correct tiles in place at all times.

There is a simple formula for working out the rate of drawing tiles. Essentially, the number of tiles to draw per pixel in each column is (number of tiles in the row or column / number of pixels per tile). For a simple horizontal scroller with a vertical resolution of 200, this would be 13 / 16, or around 0.8 tiles per pixel, and if it was 256 pixels tall it would work out exactly 1 tile per pixel. A simple vertical scroller would be 20/16, or 1.25 tiles per pixel.

For an 8-way scroller, you also want to take the buffer areas into account, so for horizontal scrolling on a 256-line screen you would need 18 tiles, so 1.125 tiles per pixel, and for vertical you would need 22/16, or 1.375 tiles per pixel. Now, dealing with fractions of tiles is inefficient (indeed, even dealing with fractions/floats isn't ideal), so the usual approach is to blit one tile per pixel until you don't need to blit any more if the required number is 1 per frame or less. So, the 200 high horizontal only scroller would blit 1 tile per pixel for 13 pixels, then not blit anything for 3 pixels. If more than 1 tile is needed, blit two tiles per pixel until you only need to blit one. So, for the 352 pixel 8-way scroller moving vertically, you would need 22 tiles per 16 pixels scrolled, so for the first 8 pixels blit two tiles, then for the rest blit only one. For efficiency, I would do the first tile with the 17th, the second with the 18th etc. instead of trying to blit the first two first, then the 3rd and 4th...

This gets a bit trickier if you don't include the extra column/row of tiles for reversing direction, as the order in which you blit the tiles then becomes important and should be reversed when the direction is reversed. With the extra column you don't need to worry about that.

[Daedalus]

Whether it's actually worth it or not to you just for this I cannot say, but I've covered this very technique (only in basic horizontal form but the principle is there) in Blitz Workshop in the current edition of Amiga Future magazine if you wanted to check that out.

[Marle]

Thanks for all the help so far. Last night I was just hitting a road block, I felt like the thickest person ever, and I've been coding now in some way for at least 25 years.... I never thought I'd get so stumped at the first hurdle so easily!

I need to read everything here and digest and see if I can figure it out. I think looking at some of the scrolling examples on the Blitz CD has confused me as the code on there is mostly badly commented and some of it looks like garbled nonsense to my eyes! (I'm sure at least one of the files had statements called things like 'C' and 'S'...not very descriptive!)

I'm going to have a good read of this and hopefully make some sense of it and go from there.

Thank you so much everyone.

[Daedalus]

Originally Posted by Marle

I think looking at some of the scrolling examples on the Blitz CD has confused me as the code on there is mostly badly commented and some of it looks like garbled nonsense to my eyes! (I'm sure at least one of the files had statements called things like 'C' and 'S'...not very descriptive!)

Yeah, some of the examples aren't great initially, though there's a chance that they are actually garbled - Blitz 2 by default saves in tokenized format, with the commands stored as binary and the rest stored as text. If you load that just as text, the commands will be garbled when you look at them. Of course, the code won't compile if that's the case. Another possibility is that they're using some little ASM snippets mixed in with the Basic, often that will look pretty alien compared to the surrounding "normal" code.

[Marle]

Yeah I know what you mean, the tokenised code is genuinely unreadable but in this case it's just poorly formatted code that is making it harder to read.

I think I have run into examples that are using LSL or something like that which is I think 68K assembler, and with the best will in the world I'm not 68k savvy

I think this is becoming a little clearer to me. I think I will need to pick up a copy of Amiga Future with your tutorial to get me started.

[Daedalus]

Cool LSL and LSR are bitwise logical operators, like and, not, or, and so on. They stand for "Logical Shift Left" and "Logical Shift Right". They are assembly I guess in that they translate 1:1 with a CPU instruction, but they are also operators that you'll find in most languages.

What they do is simply move a binary number left or right by a fixed number of digits, which in binary terms is a quick way of doing multiplies and divides by powers of two. E.g. 2 LSL 4 becomes 32, because you're taking the binary representation of 2 (%00000010) and moving it left 4 digits (%00100000), which is effectively multiplying by 16 for a result of 32.

[Marle]

Originally Posted by Daedalus

Cool LSL and LSR are bitwise logical operators, like and, not, or, and so on. They stand for "Logical Shift Left" and "Logical Shift Right". They are assembly I guess in that they translate 1:1 with a CPU instruction, but they are also operators that you'll find in most languages.

What they do is simply move a binary number left or right by a fixed number of digits, which in binary terms is a quick way of doing multiplies and divides by powers of two. E.g. 2 LSL 4 becomes 32, because you're taking the binary representation of 2 (%00000010) and moving it left 4 digits (%00100000), which is effectively multiplying by 16 for a result of 32.

Ahh cool that makes sense, I don't feel completely useless now!

I have just puchased a copy of Amiga Future 131 to hopefully make sense of all this.

I get the jist of what is being said but I suppose I'm just struggling with how the wrapping of the bitmap works.

It's frustrating because if I can't crack this I can't move on to all the other things I want to do for the game. I guess I'm struggling with how the bitmap in the viewport is going to able to contain both some of it's say right most margins and then flow immediate back into some of the left most regions on the same screen.

E.g. from a simplistic point of view my brain is looking at this like:

                       320
                         v
+-------- Viewport ------+
|                        |
|          400 0         |
|            v v         |
|---Bitmap---+ +---Bitmap|
|            | |         |
|            | |         |
|            | |         |
|            | |         |
|            | |         |
|            | |         |
+------------+-+---------+ < 256

[Daedalus]

Yeah, the thing is that for the simple wrapping setup I'm describing, the bitmap should never be displayed like it is in your diagram there - the join would never be visible, and the viewport would never move beyond the point where the last bitmap pixel is the last displayed pixel on the right. It's hidden by the fact that the left side of the bitmap is written to look like the right side, so when you try to move the join into view, you jump back to pixel 0 instead.

[Marle]

Originally Posted by Daedalus

Yeah, the thing is that for the simple wrapping setup I'm describing, the bitmap should never be displayed like it is in your diagram there - the join would never be visible, and the viewport would never move beyond the point where the last bitmap pixel is the last displayed pixel on the right. It's hidden by the fact that the left side of the bitmap is written to look like the right side, so when you try to move the join into view, you jump back to pixel 0 instead.

I'll take your word for it, thank you for your patience, I think once I can see the code in your tutorial all will make better sense

[Marle]

I got the magazine today, trying to sneak a read of it at work but failing but so far what I have read makes much more sense, I think I have been getting this totally wrong in my head!