Vertical Scrolling by blitting outside the bitmap

[Shatterhand]

Yes, but I think if you are showing the crease of the bitmap, and you blit there, the colors will work. If you blit outside the bitmap but you tell the program to SHOW this "outside", colors are correct. I don't see why it shouldn't "work" except by the fact you are trashing the Chip Ram

I really think we should hear Roondar's advice and NOT use this amazing new technique discovered by me, hehehehe. What he said really made sense, I am writing the new graphics on a wrong area of memory, and that's why it shows properly, its because I am "displaying" that area of the memory.

But that area is not reserved for the bitmap, so anything could be there.

[roondar]

Originally Posted by Shatterhand

YOLO I LIKE TO LIVE DANGEROUSLY.

I know

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

Of course, but the idea is (obviously) to only blit as much as you need per frame. For 'normal' games you just don't need that many tiles blit per frame to keep up with scrolling. Generally scrolling speed is not that high.

Couple that with the low overhead of tile/block blitting and in general the time spent getting the extra tiles on screen is a very small percentage of the time you get in a frame - even if you double the workload.

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?"

I'd better not bring a laptop to work for Amiga coding. I'd be ever so productive, but strangely nothing work related would ever get done

Originally Posted by Shatterhand

Yes, but I think if you are showing the crease of the bitmap, and you blit there, the colors will work. If you blit outside the bitmap but you tell the program to SHOW this "outside", colors are correct. I don't see why it shouldn't "work" except by the fact you are trashing the Chip Ram

I'm not sure what you mean by 'crease' here, but if you mean the Copper screen split seen in vertical scrolling then the answer is usually 'no' (for blits). To display bobs correctly across such a split requires you to split them in two.

[Retro1234]

I find it hard that to take anything you say as fact in the other thread you didn't even know how scrolling works now your an expert, Im sorry I just don't like you.

[roondar]

FYI, I've written working scrollers on the Amiga before and have provided several Amiga programs using scrolling, with full source code, on my website. These are also linked to on EAB in several threads on OCS chipset hardware coding. So I do know how scrolling works and actually proved that several times in the other thread - what I wrote there was true.

As for not liking me, I'm sorry it got so heated over in the other thread. I pointed out my dislike for how it went down over there already. That the interactions we had over there mean you no longer like me is not what I set out to do - I never tried to actively be antagonistic or come across as some sort of know-it-all but somehow it did end up like that. Sorry.

[Retro1234]

Ok apologies as well, all over the top by me, pease carry on.

[Shatterhand]

Originally Posted by roondar

I'm not sure what you mean by 'crease' here, but if you mean the Copper screen split seen in vertical scrolling then the answer is usually 'no' (for blits). To display bobs correctly across such a split requires you to split them in two.

I think he meant if I try to blit bobs half inside the Bitmap, half outside, using the "technique" (I use the term loosely) I described here.

Which means I'll be showing the "outside" of the Bitmap.

I believe it will show up correctly but you'll be overwritting memory, so it shouldn't be done anyway.

I know you should split the BOBs to do this properly. Or you can have some extra bitmap room just to make the bobs "enter" and "leave" the screen.

OR you can just blit them entirely on screen. I've been "studying" some old games and I am surprised of how many games actually do that. Just show the whole sprite on screen when they enter it, and make it dissapear as soon as it touches the border instead of smoothly "Leaving" the screen. And usually in the middle of hectic action, the player won't notice.

Actually, by studying how some old games work, I am surprised by the amount of shit players usually "won't notice"

[roondar]

Originally Posted by Shatterhand

Actually, by studying how some old games work, I am surprised by the amount of shit players usually "won't notice"

Yes, many tricks are used. Usually only the programmers or rather observant people notice it.

Still happens to this day - many games (even on PC) don't have full resolution lightning, shadows or transparency. Almost all 3D games use really low-res models or even just a simple .JPG for stuff that is far away. Then there's games that use dynamic resolution. Super visible in stills, yet barely noticeable in motion.

[Shatterhand]

I remember when I first read that the waterfall slowdowns and sometimes even completely stops in Elfmania and I was like "NO WAY". Then I went to play and saw it, and I was like "Holy crap how come I never noticed this?".

Problem is that, after you know it, you ALWAYS notice it. "Oh look, the waterfall is stopping LOL".

[Photon]

Don't know about Blitz Basic, but the hardware allows full 8-way scrolling for huge maps by allocating a slightly larger bitmap than you need to have on-screen. You need to be able to change the Copper and hardware registers of the current screen to do this, but that's all.

[MickGyver]

Originally Posted by Photon

Don't know about Blitz Basic, but the hardware allows full 8-way scrolling for huge maps by allocating a slightly larger bitmap than you need to have on-screen. You need to be able to change the Copper and hardware registers of the current screen to do this, but that's all.

It's possible in Blitz Basic, I have posted demos for horisontal, vertical and 8-way scrolling in another thread (also mentioned in this thread), all based on the ScrollingTrick demos written in C.

[idrougge]

Originally Posted by Retro1234

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)

The colours are garbled because the Blitz bitplanes are stored sequentially, so when you've scrolled a screenful, you've scrolled past the first bitplane, and suddenly the pointer for bitplane 0 points at bitplane 1, the one for bpl 1 points at bpl 2, and the last one points beyond the screen, bringing in uninitialised garbage into the top bitplane.

[Shatterhand]

Originally Posted by idrougge

The colours are garbled because the Blitz bitplanes are stored sequentially, so when you've scrolled a screenful, you've scrolled past the first bitplane, and suddenly the pointer for bitplane 0 points at bitplane 1, the one for bpl 1 points at bpl 2, and the last one points beyond the screen, bringing in uninitialised garbage into the top bitplane.

OH MY GOD. Thank you for this explanation. Makes 100% sense.