Vertical Scrolling by blitting outside the bitmap

[Shatterhand]

I've been doing some test with scrolling routines on blitz... I just figured out if you use BLOCK outside the bitmap to blit new tiles to background and keep scrolling outside its boundaries, it just works. The new blocks will show up correctly when the bitmap wraps around, you just have to keep scrolling beyond the boundaries of the bitmap and blitting the blocks outside the bitmap.

Of course you also have to turn off the debugger which won't allow you to do that.

Now I'd guess it won't let you do that for a reason. Blitting outside the bitmap is probably messing with memory addresses that aren't reserved for the Bitmap, so stuff could be overwritten, and this routine would have problems in the long run.

Or am I wrong? Can I just blit "Outside" the bitmap as much as I want, as long as I keep the debugger off?

[Retro1234]

I never thought you could Vertically scroll like this, this is basically how you horizontally scroll - It doesnt work in Amos.

I would guess its not a problem and if it works I guess your need to place BOBs right on the crease but that will also cause the Debbuger to halt.

But if the screen just Wraps round you can change your X position to minus e.g 256

When reach End >
Display BLOCK 16,Y,No instead of Bob 272,Y,No

[tolkien]

you need to allocate a large bitmap. The way you do it is dangerous cos can overwrite data when blit a block outside the allocate bitmap.

[Retro1234]

Sorry are you saying it works the same as Horizontal scrolling and when you scroll past the Top end of the Bitmap you can see the beginning again?

I never even thought to try this as it doesnt work in Amos and I never heard anyone mention it.

Creating a large Bitmap defeats the purpose of of infant scrolling but some games use it, also of course requires more memory.

Edit; Looking at this http://eab.abime.net/showthread.php?t=96410 its not that easy?

but that might help you.

[Shatterhand]

There's a clear difference between doing horizontally and vertically.

Please keep in mind that I barely understand what's the hardware is doing, so forgive me if I say something that sound stupid (The problems of only coding on high-level languages, hehe).

When you do it horizontally, you shoud keep blitting ON the bitmap. When the scrolling reach the end of the bitmap, it "wraps" around but with a vertical 1 pixel offset. You should now block your tiles on position 0 again, but minding the 1 pixel offset. If your bitmap is 320 pixels wide, bliting on pixel 0 or pixel 321 will give the same result except by that 1 pixel offset. So you should just blit on pixel 0 to keep in the boundaries of the bitmap, though I believe you'll still be writing data off the bitmap "reserved memory" because of the vertical offset (You'll need at some point to blit outside the bitmap vertically).

Keep in mind this *does* crash the display at some point if you scroll the bitmap long enough horizontally. I've tested it and I always got the display being trashed at the same point. But if you plan ahead properly, it works.

But you can blit on the "outside" of the bitmap horizontally too and it will work.

Vertically you have no pixel offset when the bitmap wraps, but what you'll see is the bitmap with wrong colors. If you keep scrolling and wraping the bitmap several times you'll get just a lot of garbage on screen. BUT if you blit the new tile on the new position of the bitmap, it works. Say, the bitmap is 240 pixels tall... when it completely wraps, the next tile should be at position Y 241... blit your tile there, and IT WILL SHOW PROPERLY instead of showing garbage if you just let the bitmap wrap around. If you blit "inside" the bitmap (say, on position 0 again), it won't show properly on the bitmap after it has wraped, you'll see just garbled colors with something that resembles the bitmap.

I don't know WHY this works, and I don't know if it *should* be done like this at all. I believe it will also crash the display at some point, and maybe even do worse stuff like maybe overwrite data on memory that's not related to the bitmap/display at all.

That said, I still don't know what's the best way to scroll vertically on Blitz. If this is safe to do (and I really doubt it is), it's certainly a great way.

EDIT: Retro 1234, that thread does have the proper way to do it, doing the copper splits which I read about it. That's probably the right way.

But writing outside the bitmap is SO MUCH EASIER AND FASTER to write

[Retro1234]

Interesting.......

Hopefully someone for knowlagable will answer, but if you can, can you try scolling at least twenty screens like this and see what happens.

Also is there not a 1 pixel gap between the wrapping around.

Thanks.

My understanding with the Corkscrew in Blitz is Apparently with initCopList after scrolling 8192 the tiles become out of sync but with Slice it's ok?

[Shatterhand]

Originally Posted by Retro1234

Interesting.......

Hopefully someone for knowlagable will answer, but if you can, can you try scolling at least twenty screens like this and see what happens.

Also is there not a 1 pixel gap between the wrapping around.

Thanks.

My understanding with the Corkscrew in Blitz is Apparently with initCopList after scrolling 8192 the tiles become out of sync but with Slice it's ok?

Oh yeah, I remember someone said it works eternally with slices (Maybe it was even you), but I never tested it.

I believe I actually tested it with more than 20 screens and still worked, but I can't be sure it will keep working when I throw more stuff at the code.

[Retro1234]

I think its very Interesting if it works

Yeah I want to try it in Blitz also want to just check if it works in Amos.

I think MickGyver found that Slice works.

I presume earok found a way around the 8192 with initCopList.

[Shatterhand]

Originally Posted by Retro1234

I think its very Interesting if it works

Yeah I want to try it in Blitz also want to just check if it works in Amos.

I think MickGyver found that Slice works.

I presume earok found a way around the 8192 with initCopList.

I was reading Andrew Braybrook's blog, and the way he describes how to do Vertical Scrolling on Amiga is exactly the way your link does it, but in Blitz.

I'd be really surprised if this ghetto "Blit outside bitmap" method is safe and works but no one used it/figured it out back at the time. Unless Blitz Basic does something different that allows this to work.

[Retro1234]

Can you link me to Andrew Braybrook's blog.

[tolkien]

You can have a good reading about scroll methods here:
https://aminet.net/package/dev/src/ScrollingTrick

Its C but is well explained.

[Shatterhand]

Originally Posted by Retro1234

Can you link me to Andrew Braybrook's blog.

http://uridiumauthor.blogspot.com/

[roondar]

Just a small, friendly warning: what you're doing will eventually likely crash the Amiga as scrolling the display always also means you're moving through memory*. Once you start seeing 'garbage' on screen (that you overwrite), you're highly likely to be overwriting your own or someone else's program and/or data.

*) That is if you scroll vertically for any distance or horizontally for more than 16 pixels.

The easiest way to scroll vertically in Blitz is probably setting up a screen twice as high as you need it to be and drawing the new tiles you want to uncover on both sides of the visible part of the bitmap as you scroll it. Then, when you reach the 'top' or 'bottom' of the display, you manually wrap it around by resetting the scroll value back to the beginning.

Note this does double the memory cost compared to a non-scrolling screen
Then again, you probably already know this given you're making a screen that scrolls

Vertical scrolling can be done without using all that extra memory by making a copper list that resets the display pointers somewhere down the screen to create a wrapping display (and splitting your bobs as you blit them), but I'm not so sure Blitz supports that in any easy to use way.

[Shatterhand]

Note this does double the memory cost compared to a non-scrolling screen
Then again, you probably already know this given you're making a screen that scrolls

Yes Also doubles the amount of blocks you have to blit on screen.

Vertical scrolling can be done without using all that extra memory by making a copper list that resets the display pointers somewhere down the screen to create a wrapping display (and splitting your bobs as you blit them), but I'm not so sure Blitz supports that in any easy to use way.

The link Retro1234 shared has an example that shows exactly how to do that. I took a quickly glance at it and I was only able to understand it because of the post you made earlier about how the Copper works

Once you start seeing 'garbage' on screen (that you overwrite), you're highly likely to be overwriting your own or someone else's program and/or data.

What's really funny is that's not exactly "garbage", it looks like it's just the bitmap but with its colors garbled. I really don't think this is a safe thing to do, but I would like some confirmation (And of course, understanding what the hell is happening is always interesting too)

[Retro1234]

Yeah I would say its not that dangerous as doing very similar horizontally I.e the corkscrew is considered good practice.

it would be interesting to hear from someone experienced in such things, cough cough earok.

[roondar]

Originally Posted by Shatterhand

Yes Also doubles the amount of blocks you have to blit on screen.

Well, a smart person only blits about a block per frame for the optimal scroller. So that would make it two per frame. Not a big deal really

The link Retro1234 shared has an example that shows exactly how to do that. I took a quickly glance at it and I was only able to understand it because of the post you made earlier about how the Copper works

Yup, it did. And happy to be of service.

What's really funny is that's not exactly "garbage", it looks like it's just the bitmap but with its colors garbled. I really don't think this is a safe thing to do, but I would like some confirmation (And of course, understanding what the hell is happening is always interesting too)

I just gave you confirmation it's not safe. Would you like me to do so again?

What is happening is that you're moving the bitplane pointers up or down through memory. This has two consequences. The first is that (part of) the display shows up distorted. The second is that part of the display now shows data from outside of the display boundaries as you allocated them.

If you write in those regions by say, using the Block command, then you're writing in unallocated memory. Anything can be there, including code & data belonging to your program or any other program that is running.

Originally Posted by Retro1234

Yeah I would say its not that dangerous as doing very similar horizontally I.e the corkscrew is considered good practice.

Only if you have allocated the required extra space for it, otherwise it actually is dangerous.

For reference, horizontal corkscrew scrolling requires you to allocate one extra line for the display for each screen you scroll horizontally. Vertical scrolling requires you to allocate one extra line for the display for each line you scroll (unless you wrap the display with the Copper, in which case you don't need to allocate extra for vertical scrolling).

[Shatterhand]

I just gave you confirmation it's not safe. Would you like me to do so again?

YOLO I LIKE TO LIVE DANGEROUSLY.

What is happening is that you're moving the bitplane pointers up or down through memory. This has two consequences. The first is that (part of) the display shows up distorted. The second is that part of the display now shows data from outside of the display boundaries as you allocated them.

If you write in those regions by say, using the Block command, then you're writing in unallocated memory. Anything can be there, including code & data belonging to your program or any other program that is running.

This means I had a lot of free memory still when I did the test

It's true, now that you said it, I remember first time I read about the corkscrew scrolling is that you *should* make the bitamp 1 pixel higher for each screen you would like to scroll.

I actually did this with the corckscrew method:
[ Show youtube player ]

Well, a smart person only blits about a block per frame for the optimal scroller. So that would make it two per frame. Not a big deal really

It depends on what you're scrolling and how fast its moving, I guess

Funny side-story to that: I currently work at the same place with my wife (We actually are the owners here), after I saw your post on this thread we went out to grab a snack, as we were walking she saw me doing some funny face or something while I was thinking how I could optimize my current scrolling routine (without overwriting data, mind you ), and she was like "What you're thinking?" and I joking said "I am writing codes on my head", to what she obviously replied "Weirdo". But then she said "Why don't you bring your laptop to work, so on those moments you're just waiting you can write your game for real, instead of in your head?"

[Retro1234]

Just a thought can you display a Bob on the crease in the correct colours etc?

[Shatterhand]

Hmm.. I only tried doing blocks and they would fit perfectly either completely inside the bitmap or outside it.

But i believe colours would be correct if I scrolled the crease into screen.

[Retro1234]

Sorry if im being a bit of a pest

because there would be a point for example the crease would be in the middle of the screen and a ship or bullet might be flying over it so it would be in both sections.