How bitmaps are implented - making a scrolling game

[LuMan]

@ReadOnlyCat - Yep, there is some good, technical reading in those links. Although, I did try your search, but only ended up back in this thread again
I think we're both looking at the same solution here, but from different angles. In Blitz Basic you use the Show n,x,y (where n is the bitmap number and x,y are the relevant offsets). The bitmap is displayed in a Slice, which has a number of settings, but looks to be an easy way of creating a custom display. It may be that hardware jiggery-pokery may not be so straightforward using the Slice/Bitmap approach - although Blitz does have the ability to fiddle about with registers directly, as well as an in-line Assembler mode too.

Boo Boo has correctly simplified the process in his last post - perhaps a little too simply, as we've discovered a number of ways to achieve this - but the high-level process is still the same (not a criticism, Boo Boo).

If memory wasn't a problem then you could just make a massive, super-duper, ultra-size bitmap and offset the x,y to your heart's content.... But the challenge is to squeeze it into 0.5MB... or 1MB..

I'll probably rattle about with this a little bit more, as I'm interested as to how easily I can create a scroller that incorporates a massive map. It's also worth taking the game speed into account, as it is fairly simple to redraw a whole screen every game loop, but this will be bloody slow on anything less than an 030/50.

[Retro1234]

Originally Posted by LuMan

(not a criticism, Boo Boo).

How dare you sir I demand satisfaction

Originally Posted by LuMan

...........as it is fairly simple to redraw a whole screen every game loop, but this will be bloody slow on anything less than an 030/50.

Wow that is fast.

[ReadOnlyCat]

Originally Posted by Boo Boo

I think its better to have a larger screen to allow baddies on and off left and right - ok you dont need the full 672 and your method wont work on the vertical.

but dont over complitate it You scroll right you paste a Tile to the right -you scroll down you paste a tile at the bottom.

No. You are incorrect.
Drawing baddies left and right is just wasted blitter time. The blitter has zero issues clipping baddies on the sides of the screen if needed.
If you want to waste CPU and blitter time what is the point of doing it on an Amiga? Just do a PC Blitz game then. No hardware scrolling then: everything is blitted.

As explained in the graphics on my post, you need to blit two times more tiles with your method. To be able to reposition the screen at the origin when you reach the end of the bitmap.

Take the time to think about it until you understand.
The corkscrew technique is simpler:
- allocate a screen size bitmap + size of column of tile + number of pixels to scroll
- scroll horizontally
And that's it.

Your method is way more complicated than that for horizontal scrolling, which is what this post is about. It consumes more memory, it requires to blit two times more tiles, it requires to reset the screen offset, etc.

[ReadOnlyCat]

Originally Posted by LuMan

@ReadOnlyCat - Yep, there is some good, technical reading in those links. Although, I did try your search, but only ended up back in this thread again

You did not try very hard, the 2nd link in the search result was the Akira thread I mentioned.

Originally Posted by LuMan

I think we're both looking at the same solution here, but from different angles. In Blitz Basic you use the Show n,x,y (where n is the bitmap number and x,y are the relevant offsets). The bitmap is displayed in a Slice, which has a number of settings, but looks to be an easy way of creating a custom display. It may be that hardware jiggery-pokery may not be so straightforward using the Slice/Bitmap approach - although Blitz does have the ability to fiddle about with registers directly, as well as an in-line Assembler mode too.

I guarantee you that this is not the same solution at all.

And I perfectly understand what Show is doing behind the scenes: this is straightforward, "Show" obviously modifies the bitplanes pointers as well as the shifting delay, which is exactly what I mention in my post.

Originally Posted by LuMan

Boo Boo has correctly simplified the process in his last post - perhaps a little too simply, as we've discovered a number of ways to achieve this - but the high-level process is still the same (not a criticism, Boo Boo).

None of the posts I read from Boo Boo or you address the waste of memory I mentioned.

Are you sure you understood the method I posted?
Can you describe it with just two sentences just to verify? It really is that simple.

Originally Posted by LuMan

If memory wasn't a problem then you could just make a massive, super-duper, ultra-size bitmap and offset the x,y to your heart's content.... But the challenge is to squeeze it into 0.5MB... or 1MB..

Which is what the corkscrew technique addresses!

Originally Posted by LuMan

I'll probably rattle about with this a little bit more, as I'm interested as to how easily I can create a scroller that incorporates a massive map.

For horizontal scrolling, the corkscrew technique is the simplest.
For multi way scrolling, a Copper split is the best compromise.

These techniques have been discussed to death on the EAB already if you take the time to search.

Originally Posted by LuMan

It's also worth taking the game speed into account, as it is fairly simple to redraw a whole screen every game loop, but this will be bloody slow on anything less than an 030/50.

That is what my post addresses!
You really did not understand that technique, otherwise you would not say that.

Let me repeat it: no extra redrawing with the corkscrew technique, barely no extra memory needed. And it is simpler to handle.

I really are admirative of your efforts there and I love you guys but on that particular point you are walking face to the wall.

Take a step back,
re-read my post with the graphics,
If you can sum up the differences between your technique and the corkscrew then do it,
If you can't, that is a good thing! Ask questions!
then when you get it, you will have build really useful scrolling expertise!

Cheers!

[LuMan]

I suppose the question here is how we would incorporate your solution using Blitz, ReadOnlyCat. Certainly, if you try blitting a shape onto a bitmap, where it will overhang, you will get an error along the lines of "shape being blitted outside of bitmap" or something.

If the Blitz method for scrolling is to offset the x-coord using Show n,x,y then how would this be done using the HW pointers? If it can be done simply in Blitz, then we have a good solution

UPDATE: Looks like our posts crossed, ReadOnlyCat
I did try the search, but only got one result... I'll try it again using Advanced Search.
I will also re-read the threads for the various methods and see how I get on.
But, please remember, I'm obviously not as keyed up on hardware scrolling and programming as yourself, which is why I'm using Blitz Basic, as opposed to something with a bit more grunt

I'll be back to ask you more questions later.....(hahaha). Cheers

[ReadOnlyCat]

Also, as a response to Boo Boo: this technique can support vertical scrolling just fine.
Doubling the size of the bitmap allows for multi way scrolling, but forces to blit two times more tiles (in the direction of the scroll and for the reset position).

A Copper split allows to keep using a single screen +row&column of tiles. But it is clearly more complex to handle.

[ReadOnlyCat]

Originally Posted by LuMan

I suppose the question here is how we would incorporate your solution using Blitz, ReadOnlyCat. Certainly, if you try blitting a shape onto a bitmap, where it will overhang, you will get an error along the lines of "shape being blitted outside of bitmap" or something.

Good point!

I am optimistic that this is not an issue since nothing is really out of the bitmap. And moreover the name "slice" gives an indication that the Blitz guys thought about it.

There is a simple way to try:
- create a 336x300 bitmap
- set the visible screen size to 320,200
- use Show 0-4, 0, 0
- load a 320x200 image
- blit this image at (0,0)
- load a 32x32 bob (or create one full of random pixels)
- set X=1
- loop
- - do Show 0-5, X, 0
- - blit the bob at 50,50
- - blit the bob at 300, 100
- - increase X by one
- - wait VBL

If this produces an error you will soon know.


The first bob blit tests how Blitz computes blit addresses, the second one tests if Blitz clips the bob properly on the borders (it should).

Originally Posted by LuMan

If the Blitz method for scrolling is to offset the x-coord using Show n,x,y then how would this be done using the HW pointers? If it can be done simply in Blitz, then we have a good solution

Goof question again.
You would need to modify BPLnPTy and BPLCON1 but I suspect that this is exactly what Show does. Try the above example and we should have confirmation.

If this doesn't work, I'll need to look at the Blitz documentation.

[idrougge]

Originally Posted by LuMan

I suppose the question here is how we would incorporate your solution using Blitz, ReadOnlyCat. Certainly, if you try blitting a shape onto a bitmap, where it will overhang, you will get an error along the lines of "shape being blitted outside of bitmap" or something.

Use ClipBlit, or just allocate enough bitmap so that bobs always fit in.

[idrougge]

Originally Posted by ReadOnlyCat

Also, as a response to Boo Boo: this technique can support vertical scrolling just fine.
Doubling the size of the bitmap allows for multi way scrolling, but forces to blit two times more tiles (in the direction of the scroll and for the reset position).

A Copper split allows to keep using a single screen +row&column of tiles. But it is clearly more complex to handle.

I think you must leave high-level land to do a proper copper split. Manipulating the CopList with Blitz creates a blank line between bitmaps, IIRC.

[Master484]

I made a quick test with ReadOnlyCats method, and it seems to work.

Here is a short code that you can simply copy-paste into Blitz editor and run:

VWait 250
BLITZ
Blitzkeys On

Slice 0,44,320,200,$fff0,4,8,16,336,336

BitMap 1,336,300,4 ; creates bitmap 1
Use BitMap 1

Show 1,0,0 ; shows bitmap 1 in current Slice at XY 0,0

For i = 1 to 320    ; fills a 320*200 area with random lines
Line i,0,i,200,Int(Rnd(15))
Next i

GetaShape 1,0,0,320,200 ; gets a 320*200 shape from the bitmap

Cls ; clean screen

Boxf 0,0,32,32,5
GetaShape 2,0,0,32,32  ; gets a 32*32 shape from the bitmap

Cls ; clean screen

Blit 1,0,0 ; blits the 320*200 image to 0,0

x.w = 1

;----------------------------
Repeat

Show 1,x,0
Blit 2,50,50
Blit 2,300,100
x+1
VWait

Until RawStatus($45)=-1  ; ESC quits program
;-----------------------------

AMIGA
End

The bitmap indeed wraps around and starts coming from the right.

The Show command gets an ever increasing x value...so the view scrolls all the time and everything moves on the screen, but on the memory side the bitmap and the bobs actually just stay in the coordinates where they are.

Although there is some strange "jumping" visible on the left edge of the screen, but I remember that C64 hardware scrolling had this too, and the solution is most likely the same; we just hide it somehow, and there is surely some simple way to do this.

[ReadOnlyCat]

Originally Posted by Master484

I made a quick test with ReadOnlyCats method, and it seems to work.
[...]

The bitmap indeed wraps around and starts coming from the right.

The Show command gets an ever increasing x value...so the view scrolls all the time and everything moves on the screen, but on the memory side the bitmap and the bobs actually just stay in the coordinates where they are.
The
Although there is some strange "jumping" visible on the left edge of the screen, but I remember that C64 hardware scrolling had this too, and the solution is most likely the same; we just hide it somehow, and there is surely some simple way to do this.

This is good news, thanks for taking the time to test!

The jumping is probably due to the Slice library miscalculation of the data fetch start. Is there a Blitz function which allows to set the position of the screen?
If so, try incrementing it horizontally by one and redo the test. Increment until this finally gets rid of the left side jumping.

Normally you should not need to increase more than 15 pixels to get it to disappear.

Also, this is not my method, I wish I had thought of it but I learned it from CodeTapper.

[Shatterhand]

Try to do it using the Display library instead of the Slice one, it may be more stable.

[Master484]

I'm not sure if there is any command in Blitz to change the screen position...And I also tried to use the Display library, but the jump happened in that too.

But at least changing the horizontal width of the Slice seemed to help; I tried increasing the X size of the Slice from 320 to 400, and the jumping stopped. Or maybe it still happened, but the jump zone was pushed off-screen. But at any smaller Slice width than this, for example at 368 pix wide, the jump still happened. And also I tried smaller sizes like 160 pixels, and it still jumped.

And also, the jump seems to be exactly 16 pixels. And it doesn't actually "jump", but rather 16 pixels of the bitmap suddenly disappear from the left side at regular intervals, which looks like jumping. And I'm sure that I have seen jumps like this in a few Commodore 64 games that have badly programmed scrolling routines.

And also it only jumps when scrolling from right to left. On left to right scrolling there is no jump...although this direction causes another problem: random carbage starts to appear form the bottom of the screen, line by line.

But the Slice X-size increase seems to be at least a partial solution, although I'm not sure if having Slices wider than 320 in a lo-res display can cause any other side effects. But at least this seems to increase the visible screen area to the zone where you normally have the screen borders. And this would mean a larger game area where bobs would need to be blitted. And so, with this "Slice stretch" solution we might just end up blitting more, and not less.

Also one half-solution that I came up with, is to draw a black box over the "jumping area". But this of course modified the bitmap too, drawing over it. But maybe by making the box a bob and adding double buffering it could work. But still, it would be a big bob, and would need to be drawn every frame, and so I think it would eliminate all speed gain that we would otherwise get.

But anyways here is an updated main loop for my test code:

;----------------------------
Repeat

Show 1,x,0
Blit 2,50,50
Blit 2,300,100
x+1
If RawStatus($40)=-1 then x-1   ; Space - Stop scroll
If RawStatus($44)=-1 then x-2   ; Return - scroll left to right
If RawStatus($36)=-1 then x+3   ; N - fast right to left scroll
If RawStatus($37)=-1 then x-4   ; M - fast left to right scroll

x=QWrap(x,0,336)        ; when x is higher than 336 it wraps to 0 and vice versa 

;Boxf 0+x,0,16+x,200,0  ; uncomment this line to draw a filled box
                        ; that covers the left side jump

VWait

Until RawStatus($45)=-1  ; ESC quits program
;-----------------------------

It adds some keys to alter scroll speed and direction, and also the box drawing command is there, if you want to test it.

[ReadOnlyCat]

This jumping is definitely a non aligned data fetch.
And the way you are trying to solve it by hiding it is not the proper way: it is a bug and should be fixed properly rather than hidden or drawn over. It is as if you were trying to fix a flat tire by placing a cardboard with a full tire painted on it on top of the wheel.

From the looks of it Blitz positions the screen depending on visible display size so I would think using a screen size under or equal to 320 would fix it.

Can Blitz read hardware registers? If so, try reading the value of DDFSTRT and DIWSTRT when the program has this weird left side behavior. This should confirm that the problem comes from a bad data fetch start.

[idrougge]

@Master,
try to set the Slice flags to $fff9a.

[Master484]

try to set the Slice flags to $fff9a

Yes, doing that removed the jumping.

Although it also changed the colors; the random colored stripes all turned more reddish. But the scrolling was smooth to both directions, and no jumps.

Can Blitz read hardware registers?

I think so, it has the Peek and Poke commands for doing all sorts of advanced stuff. But I'm not skilled enough to use them.

[Daedalus]

Originally Posted by Master484

I think so, it has the Peek and Poke commands for doing all sorts of advanced stuff. But I'm not skilled enough to use them.

Yes, it can and is subject to the same limitations as C etc., e.g. it can't read from write-only registers and so on. Peek.l will return a 32-bit longword from any address. Alternatively, you can use pointers and Newtypes if you set them up to point at a structure and read the values from that directly. That depends on having the structure prototype available however, but it is a neater way of doing things.

[idrougge]

I think most structures and constants are available in your Blitzlibs: assign. And don't forget Blitz has an inline assembler.

There are also many commands in the Display library to manipulate Blitter and Copper registers. Check out CustomString, DisplayAdjust, DisplayControls…

[LuMan]

OK, while I understand how the scrolling works, I'm still not sure that I've got to the bottom of making massive maps and drawing them in time for the next screen. If I've been totally blind about the point, then please let me know!!

Master's demos do exactly what we would expect - in fact, I remember writing an almost identical approach in 6502 on a CBM PET back in 1985. Shifting the start-point of the screen RAM to shift the viewable area about. As I recall, we used to let the screen pointer run all the way through the physical RAM to make interesting screens.

However, with respect to this issue, I'm still not sure how this helps the issue of mapping map tiles and displaying them. We would still need to have these tiles referenced, and then order them to come onto the screen when they need to. Did I miss this? Am I going mad??

If I apply the ever-increasing x value to my original code (that I posted in The Zone), then I would need to reset something to make the screen pop back the 1 pixel of y value that we are seeing. The only way I can see this happening is to have a copy of the 'final' screen and then repoint to it - effectively re-setting, x again.

Like I said, if I've missed the point, please let me know

[ReadOnlyCat]

Originally Posted by LuMan

OK, while I understand how the scrolling works, I'm still not sure that I've got to the bottom of making massive maps and drawing them in time for the next screen. [...]

Master's demos do exactly what we would expect - in fact, I remember writing an almost identical approach in 6502 on a CBM PET back in 1985. Shifting the start-point of the screen RAM to shift the viewable area about. As I recall, we used to let the screen pointer run all the way through the physical RAM to make interesting screens.

Yup, that is indeed the exact same principle at work.
Blitz hides the re-setting of the screen address via the Show command but behind the scene this is exactly what it does.

Originally Posted by LuMan

However, with respect to this issue, I'm still not sure how this helps the issue of mapping map tiles and displaying them. We would still need to have these tiles referenced, and then order them to come onto the screen when they need to. Did I miss this? Am I going mad??

You did not miss anything and actually you got it just right.

Now that the horizontal scroll is validated to work with this technique, one indeed needs to draw the new tiles on the right border of the screen right before they emerge into view.

This means that the Blitz screen needs to be set so that the screen does not immediately wrap to the next line but leaves a few pixels (32 ideally) permanently out of view so that new tiles can be drawn on these pixels when they are still in the non visible part of the bitmap.

I do not know what the Blitz command is which does that but I guess idrougge must know.

Regarding how to draw these tiles, well, you indeed need to have an array of tiles ready somewhere in chip RAM and a "tilemap" (essentially a bidimensionnal array of tile indices) which you will use to select which tiles to copy from your array of tiles into the non visible border. I guess Blitz must have a dedicated blit function to do that kind of simple copies. As the scrolling goes, you keep track of where you are in the tilemap and draw new tiles every time the screen has scrolled by 16 pixels.

Originally Posted by LuMan

If I apply the ever-increasing x value to my original code (that I posted in The Zone), then I would need to reset something to make the screen pop back the 1 pixel of y value that we are seeing. The only way I can see this happening is to have a copy of the 'final' screen and then repoint to it - effectively re-setting, x again.

Like I said, if I've missed the point, please let me know

I am not too sure I understand what you mean there.
Why do you want to reset the screen back to horizontal position 1?
Or rather at which moment do you think you will have to do that?