English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. AMOS (http://eab.abime.net/forumdisplay.php?f=119)
-   -   Disable bob clipping at screen edges (http://eab.abime.net/showthread.php?t=87636)

adrazar 18 June 2017 22:01

Disable bob clipping at screen edges
 
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 18 June 2017 22:06

Find corkscrew scroller somewhere here around ;-)

adrazar 20 June 2017 21:47

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 21 June 2017 00:18

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

adrazar 21 June 2017 10:03

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 21 June 2017 22:24

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 22 June 2017 00:15

Quote:

Originally Posted by adrazar (Post 1165919)
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 22 June 2017 12:06

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 22 June 2017 15:26

Quote:

Originally Posted by phx (Post 1166759)
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 22 June 2017 17:11

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 22 June 2017 19:01

Quote:

Originally Posted by adrazar (Post 1166875)
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 22 June 2017 19:10

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 23 June 2017 01:41

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 30 June 2017 16:35

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 30 June 2017 23:28

Nice!

Retro1234 03 July 2017 13:57

Quote:

Originally Posted by adrazar (Post 1168723)
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 :great


All times are GMT +2. The time now is 16:10.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.

Page generated in 0.04205 seconds with 11 queries