clipping problem

[geldo79]

Hi,

I am currently coding a little asteroids-like game. That means, my sprites and bobs should be able
to leave the screen and reenter on the opposite side. For my sprites, it already works well. But for my
bobs, i need some help: Currently, the bobs reach the end of the playfield, e.g. the right boundary, and
if it moves further, some funny effects occur, likely because the bob already enters the next bitplane. I think
that problem can be solved using modulos (e.g. 1 Word for my 16x16 bob) for the bitplanes, to create some
hidden space. I did not test it yet, but I think that should be the way to do it. But, what i do not understand
so far: if my bob reaches e.g. the bottom of the playfield, the hidden space has to be bigger!? How can this be achieved?
Do I have to set the address of the next bitplane to the end of the prior bitplane + e.g. 40*16 in order to be able
to hide my 16x16 bob below the bitplane? But if so, the bitplanes are not contiguous. Wouldn't that lead to problems
for blitting the bobs into the bitplanes, especially if i want to use the interleaved mode? And what about the first
and the last bitplane....if i write my bob to addresses before the first or behind the last bitplane....
won't i write into unknown memory addresses ?

[meynaf]

So basically what you want to do is to have a screen buffer that's bigger than actual view, to hide objects blitted at the edges ?

Setting a modulo alone will not help, you really have to have a surface that's bigger than the screen.
However it is not the "proper" way to do that.

The best way to do what you want to do is to do real clipping.
You can do this by moving the starting point and changing the size.
For example, for bottom, if you have 320x256 screen and want to display 16x16 bob located at y=244, reduce the bob height to (256-244) = 12 lines.
For top, reduce the height accordingly, but also move the starting line, to show only part of the graphic.

[DanScott]

And for the left/right, you need to have a screen buffer that is 16 pixels (2 bytes) wider than the display area (use modulo to correct the bitplane display).

Then you have to reduce the bob width as it is being clipped (and also the source & destination blitter modulos too, to compensate)

[geldo79]

Originally Posted by DanScott

And for the left/right, you need to have a screen buffer that is 16 pixels (2 bytes) wider than the display area (use modulo to correct the bitplane display).

Then you have to reduce the bob width as it is being clipped (and also the source & destination blitter modulos too, to compensate)

Why do I have to reduce the bob width? I thought the extra 2 bytes screen buffer can be used to hide to bob in that area?

[DanScott]

Originally Posted by geldo79

Why do I have to reduce the bob width? I thought the extra 2 bytes screen buffer can be used to hide to bob in that area?

Maybe your bob is 64 pixels wide It always pays to write a generic routine if possible to handle any sized blitter object. Unless you know they will never be more than "x" words wide.. then you can just use "x" words of extra screen padding

EDIT: just read your original post that it's 16x16.. so yeah, just an extra word required on your bitplanes

[geldo79]

Ok. With "reducing the bob width" you mean reducing in terms of words? Thus, if a 64x64 bob is placed at x=310, only 10 pixels can be displayed, so that the last 3 words of the bob can be ignored, 10 pixels of the last word will be shown on the screen...6 pixels will be placed in the hidden extra word?

[DanScott]

Originally Posted by geldo79

Ok. With "reducing the bob width" you mean reducing in terms of words? Thus, if a 64x64 bob is placed at x=310, only 10 pixels can be displayed, so that the last 3 words of the bob can be ignored, 10 pixels of the last word will be shown on the screen...6 pixels will be placed in the hidden extra word?

yes... so you just reduce the blitsize width, and increase the modulos of the source and dest blitter A,B,C & D pointers
by 2 for each word you want to reduce in size by.

As i mentioned, it's worth writing a bob clipping routing to handle arbitrary sizes of bobs, would take probably one or 2 evenings to get it fully working and optimised.. but then you have ARFL (a routine for life). It's a long time since I wrote one, as the ones I used in my games back in the early 1990's are long lost... but it is something that I need to look at soon anyway.

[geldo79]

Originally Posted by DanScott

And for the left/right, you need to have a screen buffer that is 16 pixels (2 bytes) wider than the display area (use modulo to correct the bitplane display).

Then you have to reduce the bob width as it is being clipped (and also the source & destination blitter modulos too, to compensate)

Thus, If i have a background image, I have to enlarge it (1 extra word on the right side), and set the bitplane modulos to 2?

[roondar]

I want to point out something. While DanScott & meynaf are 100% correct and I agree that having a Blitter routine that clips properly is a very good thing to have and code, there is an alternative that you could consider.

You could simply make the bitmap you draw to (much) bigger than it needs to be and set the pointers/modulo's so that the visible part is in the middle of the bitmap. This is normally done anyway to aid in clipping, but you can also use this to avoid clipping code.

So, if your maximum bob size is 64 pixels, you add at least 64 pixels to all sides of the display. This way you can move the bobs anywhere on and partially on the screen without needing any clipping. The price you pay is larger memory use and a lack of flexibility - if your buffer zone is 64 pixels on all four sides, you can't support 80 pixel bobs (etc).

Not the most elegant way of dealing with clipping, but if you mostly deal with small objects it can be very effective.

[geldo79]

Originally Posted by roondar

You could simply make the bitmap you draw to (much) bigger than it needs to be and set the pointers/modulo's so that the visible part is in the middle of the bitmap. This is normally done anyway to aid in clipping, but you can also use this to avoid clipping code.

I think that makes sense. I already wrote some clipping code which works fine for me. But I think, in my case it might be more efficient to use your approach, because i think i will only use small bobs. And I'd like to have fast bob code and don't care for a bit more of memory usage.



But, can someone please help? What settings do I have to use for bitplane modulos, diwstart, diwstop, ddfstrt, dfstop in order to show the center a 352x288 bitplane....having 16 pixels hidden space on each side? I'm a bit confused and don't find the solution


Greetings Christian

[roondar]

I can certainly give it a try

Let's start with the easy ones: diwstart, diwstrop, ddfstrt & ddfstop
These will be the same as usual (as in, the same as for a 320x256 display). To see why, consider the following:

• DIWSTART & DIWSTOP define the location and size of the onscreen display window. This won't change for larger bitmaps, only for larger/differently positioned display windows.
• DDFSTOP & DDFSTART tell the system when to start getting data from memory for the display and when to stop. This is directly linked to the display window size and thus won't change if the window doesn't resize (be aware that horizontal scrolling does require a different DDFSTART value)

The modulo's and pointers are different, because you're changing the size of the bitmap vs what you show. The bitplane pointers should be increased by 2 bytes for every 16 pixels of additional space you use on the left side of the screen. This will skip the invisible part of the bitmap. One byte is 8 pixels due to the nature of the bitplane display where each pixel is represented by 1 bit (per plane).

The modulo values will need to be increased by 2 for every 16 pixels of total 'buffer' space you've defined - that is, for 16 pixels either side you need to add 4 to the modulo (representing the 32 pixels you've added). Similarly, you will also need to add 4 to the Blitter destination modulo (as that is dependent on the size of the bitmap, which is now bigger). Just as before, one byte is 8 pixels due to the nature of bitplane displays.

[mcgeezer]

In rygar i only clip vertically and i do exactly what roondar has suggested on the horizontal axis.

[geldo79]

That also works for me now. But now that the clipping of the bobs work properly, I wonder if this would also work for sprites. I know that i don't have to clip sprites. But what i mean is: If i decide to have a info screen at the bottom, which does not belong to the playfield, i could clip my bobs now so that they don't enter that area. But my sprites will still do. How can i tell the sprites to also clip at that position?

[ross]

Originally Posted by geldo79

That also works for me now. But now that the clipping of the bobs work properly, I wonder if this would also work for sprites. I know that i don't have to clip sprites. But what i mean is: If i decide to have a info screen at the bottom, which does not belong to the playfield, i could clip my bobs now so that they don't enter that area. But my sprites will still do. How can i tell the sprites to also clip at that position?

There may be more than one solution and it depends on whether you use sprites in the bottom area of the video.

You can disable sprites DMA (and reenable on next VB)* or just define the sprite as less high in your sprite list in memory (and add 0,0 as sprite termination on list instead of DATA).
You need to buffer this DATA to reinsert when sprite y-move.

*you also need to zero SPRxDATx to avoid 'stripes' but can be easily done on copper list.

[roondar]

Originally Posted by geldo79

That also works for me now. But now that the clipping of the bobs work properly, I wonder if this would also work for sprites. I know that i don't have to clip sprites. But what i mean is: If i decide to have a info screen at the bottom, which does not belong to the playfield, i could clip my bobs now so that they don't enter that area. But my sprites will still do. How can i tell the sprites to also clip at that position?

Apart from the method Ross used, there is a 'cheat' of sorts here as well. I use the following:

• Draw the top and/or bottom status panel using colour 1 as background instead of colour 0
• Draw the game play area using colour 0 as background colour as normal
• Use the Copper to change the sprite to playfield priority so that sprites show below the bitplane graphics during the status bar(s)
• Use the Copper to change the sprite priority back to sprites in front of the playfield during the gameplay area

The above works best if you use the Copper to create a colour split between the status panel(s) and the game play area.

This method essentially allows you to forget all about clipping sprites. Do note however that it will only work if sprites are not so big as to need vertical clipping at the top (i.e. if the vertical start coordinate doesn't gets too small for the sprite to display).

[geldo79]

Thanks for your replies! I will play around with these methods.

[mcgeezer]

Originally Posted by roondar

Apart from the method Ross used, there is a 'cheat' of sorts here as well. I use the following:

• Draw the top and/or bottom status panel using colour 1 as background instead of colour 0
• Draw the game play area using colour 0 as background colour as normal
• Use the Copper to change the sprite to playfield priority so that sprites show below the bitplane graphics during the status bar(s)
• Use the Copper to change the sprite priority back to sprites in front of the playfield during the gameplay area

The above works best if you use the Copper to create a colour split between the status panel(s) and the game play area.

This method essentially allows you to forget all about clipping sprites. Do note however that it will only work if sprites are not so big as to need vertical clipping at the top (i.e. if the vertical start coordinate doesn't gets too small for the sprite to display).

Again - this is exactly what I do in Rygar, the top and bottom background colours are not using register 0 but are painted Black. I then change the priorities above the panel to not show sprites, then switch them below the panel to show the sprites.

[geldo79]

That works perfectly....thanks. And, only two additional lines of code!