Disable bob clipping at screen edges

[adrazar]

Hi all! I found a new and interesting scrolling method here: ftp://de.aminet.net/pub/aminet/dev/s...llingTrick.lha. The idea is that continued increments of Screen Offset in x-direction will eventually result in the screen wrapping over, except being shifted one pixel up in y-direction.

Since I need to improve the scrolling system for a game I'm making, I thought this solution could be promising. There is a catch however. If Screen Offset is positioned such that the edge of the screen lies within the visible part of the display, any of my monsters (represented by bobs) are clipped whenever they move across this line. I imagine this effect is produced by amos rather than the blitter itself.

So the question would be: could this automatic clipping effect be "disabled" somhow?

[Cylon]

Find corkscrew scroller somewhere here around ;-)

[adrazar]

Thanks for your reply

There were indeed a few threads on this forum discussing this method. Unfortunately I could not find anything of use considering handling bobs. Was there a particular thread you had in mind? I feel I need more clear-cut directions to proceed.

Let's see... As a simple way to solve my problem, one could duplicate all bobs and have the double appear as the "real" bob departs over the screen edge. I don't like this very much, because one of my reasons for desiring a corkscrew scroller is that it should save a few blitter operations. So I need a better idea to make this work.

[idrougge]

Use Screen Display to cut off the extremes of the screen. This should mask your bobs while still permitting you to scroll.

[adrazar]

Assuming you by the extremes of the screen are referring to the columns with x-coordinates 0 and (Screen Width - 1) respectively, I can't see how Screen Display could be used to hide these as soon as the extremes are scrolled into the visible part of the screen. The extremes will regularly appear within the visible area due to the scrolling technique.

[idrougge]

Sorry, I was thinking of a quite different problem. Now I understand that it's about the wraparound of the screen coordinates, and AMOS clipping the bob at what it perceives to be the screen edges.

In that case, the only solution I can think of is to check vicinity to the screen edges before placing your bob on the screen, and if the bob's width overlaps the screen, you must place two bobs instead. In most cases, this will not cause a great amount of extra blitter operations.

[phx]

Originally Posted by adrazar

So the question would be: could this automatic clipping effect be "disabled" somhow?

I'm not sure if I understand you correctly, but I know this scrolling algorithm quite well, because I used it in all my last games.

You are probably talking about the "split", when scrolling in vertical direction, although you mentioned x-offsets? The Copper is used to connect the end of your bitmap with the start of your bitmap, by resetting the BPLxPTs in the middle of the display.

When a BOB crosses this split you have to run the Blitter first for the lines visible before the split and then again for the lines after the split. No need to blit the whole object twice, only parts of it.

[idrougge]

Unfortunately you don't have that luxury in AMOS. It will automatically clip bobs at edges and you can't choose to draw only part of a bob.

[adrazar]

Originally Posted by phx

You are probably talking about the "split", when scrolling in vertical direction, although you mentioned x-offsets? The Copper is used to connect the end of your bitmap with the start of your bitmap, by resetting the BPLxPTs in the middle of the display.

I'm trying to make a horizontal scroller, which means I don't require any vertical copper splitting. But your expert tip for handling bobs in this case is gratefully accepted Although, I probably won't try a copper splitting vertical scroller in AMOS because I haven't quite grasped which features I involuntarily relenquish by so doing. And being very intrusive sort of defeats the purpose of using AMOS anyway I think.

The problem I'm trying to address is the analogue situation where the top and bottom of the bitmap are replaced by the left and right edge of the bitmap. Here the bobs are being clipped, but I don't want them to. I wonder if this is a rather AMOS-specific issue, or if it is common to other languages as well?

[Retro1234]

You want Bob clipping but there isnt a basic command for this in Amos unless one of the extensions has one anyone know?

you could write your own routine fairly complex ive not tried but should work with some good planning in advance you store your sprites in a sprite sheet not in the bank and some kind of Dim variable with all the sizes etc and use of the get Bob command.

[phx]

Originally Posted by adrazar

The problem I'm trying to address is the analogue situation where the top and bottom of the bitmap are replaced by the left and right edge of the bitmap. Here the bobs are being clipped, but I don't want them to.

Ok... so your BOBs are clipped vertically, i.e. pixels of the left or right side are missing?

This must be an AMOS thing, where I unfortunately can't help you much. Usually there should be no reason, as there is no Copper split. You just increment the bitplane pointers until you reach your maximum x-offset. Probably AMOS uses the original bitmap dimensions for automatic clipping? An option to disable that would be useful (and also much faster).

[Retro1234]

Does anyone know if this happens in Blitz?

Im surprised it if it only happens in Amos as Bob clipping with corkscrew was something I learnt out of context with Amos.

[idrougge]

Blitz doesn't clip bobs unless you use ClipBlit, but the debugger will trap if you try to blit outside the bitmap edges, so you would need to go without debugger.

[adrazar]

Good news! Turns out there is an easy way to prevent AMOS from clipping bobs along the horizontal edges (at least for the simple testing program I made):

Doke Screen Base+76,NEW_SCREEN_WIDTH

By chosing NEW_SCREEN_WIDTH larger than the original (real) screen width, the automatic Bob clipping is delayed until a Bob reaches x-coordinate NEW_SCREEN_WIDTH. Thus one may corkscrew scroll horizontally as far as the largest value of NEW_SCREEN_WIDTH permits (presumably $FFFF, which would be 204 x 320 screens wide).

I have not tested this properly yet, meaning there might be any sort of trouble here that I'm unaware of. I should also say that the address Screen Base+76 was discovered through inspection rather than reading the documentation (if such a thing exists). But it seems to work generally, at least the address remains static for various choices of colour depths and screen sizes.

The value written to Screen Base+76 should directly affect the value returned by Screen Width.

[idrougge]

Nice!

[Retro1234]

Originally Posted by adrazar

Good news! Turns out there is an easy way to prevent AMOS from clipping bobs along the horizontal edges (at least for the simple testing program I made):

Doke Screen Base+76,NEW_SCREEN_WIDTH

By chosing NEW_SCREEN_WIDTH larger than the original (real) screen width, the automatic Bob clipping is delayed until a Bob reaches x-coordinate NEW_SCREEN_WIDTH. Thus one may corkscrew scroll horizontally as far as the largest value of NEW_SCREEN_WIDTH permits (presumably $FFFF, which would be 204 x 320 screens wide).

I have not tested this properly yet, meaning there might be any sort of trouble here that I'm unaware of. I should also say that the address Screen Base+76 was discovered through inspection rather than reading the documentation (if such a thing exists). But it seems to work generally, at least the address remains static for various choices of colour depths and screen sizes.

The value written to Screen Base+76 should directly affect the value returned by Screen Width.

Thanks