English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 04 November 2019, 13:13   #1
geldo79
Registered User
geldo79's Avatar
 
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 39
Posts: 32
clipping problem

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 ?
geldo79 is offline  
Old 04 November 2019, 15:15   #2
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,620
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.
meynaf is offline  
Old 04 November 2019, 15:28   #3
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 481
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)
DanScott is offline  
Old 04 November 2019, 19:39   #4
geldo79
Registered User
geldo79's Avatar
 
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 39
Posts: 32
Quote:
Originally Posted by DanScott View Post
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?
geldo79 is offline  
Old 04 November 2019, 19:51   #5
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 481
Quote:
Originally Posted by geldo79 View Post
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
DanScott is offline  
Old 04 November 2019, 20:18   #6
geldo79
Registered User
geldo79's Avatar
 
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 39
Posts: 32
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?
geldo79 is offline  
Old 05 November 2019, 00:24   #7
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 481
Quote:
Originally Posted by geldo79 View Post
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.

Last edited by DanScott; 05 November 2019 at 00:44.
DanScott is offline  
Old 07 November 2019, 16:13   #8
geldo79
Registered User
geldo79's Avatar
 
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 39
Posts: 32
Quote:
Originally Posted by DanScott View Post
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?
geldo79 is offline  
Old 07 November 2019, 16:22   #9
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,379
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.

Last edited by roondar; 07 November 2019 at 16:39.
roondar is offline  
Old 07 November 2019, 22:47   #10
geldo79
Registered User
geldo79's Avatar
 
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 39
Posts: 32
Quote:
Originally Posted by roondar View Post
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
geldo79 is offline  
Old 07 November 2019, 23:07   #11
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,379
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.

Last edited by roondar; 07 November 2019 at 23:21. Reason: Pressed the button too early :P
roondar is offline  
Old 07 November 2019, 23:25   #12
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,510
In rygar i only clip vertically and i do exactly what roondar has suggested on the horizontal axis.
mcgeezer is offline  
Old 10 November 2019, 12:35   #13
geldo79
Registered User
geldo79's Avatar
 
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 39
Posts: 32
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?
geldo79 is offline  
Old 10 November 2019, 13:43   #14
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,240
Quote:
Originally Posted by geldo79 View Post
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.
ross is offline  
Old 11 November 2019, 10:35   #15
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,379
Quote:
Originally Posted by geldo79 View Post
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).
roondar is offline  
Old 11 November 2019, 14:31   #16
geldo79
Registered User
geldo79's Avatar
 
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 39
Posts: 32
Thanks for your replies! I will play around with these methods.
geldo79 is offline  
Old 11 November 2019, 18:30   #17
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,510
Quote:
Originally Posted by roondar View Post
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.
mcgeezer is offline  
Old 12 November 2019, 10:16   #18
geldo79
Registered User
geldo79's Avatar
 
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 39
Posts: 32
That works perfectly....thanks. And, only two additional lines of code!
geldo79 is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Disable bob clipping at screen edges adrazar Coders. AMOS 15 03 July 2017 14:57
Clipping bobs roondar Coders. General 18 24 September 2015 10:54
Fast Blitter Line Clipping 71M Coders. Asm / Hardware 2 03 March 2014 23:33
Screen right edge clipping issue mark_k support.WinUAE 0 05 January 2014 20:28
Clipping line for blitter fill leonard Coders. Asm / Hardware 12 27 April 2013 13:03

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 20:51.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09618 seconds with 13 queries