Path: chuka.playstation.co.uk!news From: "Rikki Prince" Newsgroups: scee.yaroze.beginners Subject: Re: Collision Detection!.....(Joy) Date: Fri, 18 Jun 1999 17:06:09 +0100 Organization: PlayStation Net Yaroze (SCEE) Lines: 103 Message-ID: <7kdqqp$4fj15@chuka.playstation.co.uk> References: <7kdntq$4fj13@chuka.playstation.co.uk> NNTP-Posting-Host: th-gt145-001.pool.dircon.co.uk X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Scott Ward wrote in message news:7kdntq$4fj13@chuka.playstation.co.uk... > I've been looking for different ways of achieving quality collision > detection and I saw a method on the Sony FAQ page which copies images into > main memory and then uses bitwise 'and' to test for collision. Although this > method is supposedly very slow it is pixel perfect when it comes to accuracy > so I really wouldn't mind giving it a whirl. > > I got in touch with James Russell at Sony who provided me with some more > information but I'm still unsure of how to do it. Here's a snippet of what > he sent me: > > >Firstly you do trivial rejection - if the horizontal and vertical > boundaries of > >the two sprites don't cross in any way, then there is no detection. If they > do > >cross, then you clear a buffer that is the same size as the screen > (although it > >only has to have a 2 bit resolution). Then you copy the first mask into > that > >buffer, shifting the bits as necessary so that the mask is in the same > position > >it's in on the screen. Then you do the same for the second mask, except > instead > >of copying the mask into the buffer, you and it with the buffer and test > the > >result. If any bit is one, then there was a collision. > > Right, I'm still pretty new to this games coding business so whilst this > message may seem reasonably straight forward to you lot it has me a little > baffled. > > I'd get back in touch with James but I feel this may take some time to sort > out so instead of me hounding the good people at Sony I'd rather someone > offered their time to help me out. To save space on the newsgroup I'll try > to ask as many questions on this one note. Here goes: > > 1) Although I understand the concept of creating a mask of a sprite how do > you make one? At first I thought that you probably just create an identical > sprite with lower resolution but then, as far I know, 4-bit sprites are the > lowest resolution you can load into the frame buffer. How do you make a > 2-bit mask? > I'm not too sure about this, as I haven't done anything I'm going to talk about, but I've heard of most of it. I think, just by copying the area of the sprite to the main memory it might do the conversion into 2 bit. I can't be certain, but possibly in the main memory, the bits of memory are only on/off or 2bit. This would also imply that the Video RAM can support higher bits. As I say, I'm not too knowledgeable in memory concepts, so this is just a guess. > 2)When James refers to a buffer, does this mean in the frame buffer or a > buffer in memory? If it means create a buffer in memory then I definately > need help. :o\ > I think he means a buffer in the main memory. When people talk about a buffer in computing terms, it is just a storage area in memory. So initialising a variable is just making a buffer. For this case, you could initialise an array (not sure what of, probably int's), or use malloc() passing the size in bytes you want, and it returns a pointer to the place in memory that you've just allocated. You need this pointer in whatever copy function you use, though I don't know which one you need to use. [Added note: I know believe it to be StoreImage that you want.] > 3)Copying the first mask into the buffer. What form does the mask take? Is > it an image in the frame buffer or is it stored in memory as a series of > bytes? > It should be a series of bytes in the frame buffer, indicating whether each byte is on/off. It is each of these bytes that you check against those in the other image, to see whther they're colliding. > 4)If all this done in the frame buffer then I have no bother moving stuff > about but if it's done in memory how would you go about 'shifting the bits' > and how would you know where to shift them to? > I don't quite understand this either, I think its to make one image relative to the other, as it is in the screen image. For example rather than checking byte 0 of image 1 against byte 0 of image 2 (unless they're on top of each other like that - unlikely if your collision detection is working!), you might need to chek byte 0 of image 1 against byte 37 of image 2. > > I know this question(s) must seem a bit daunting but even if you can only > answer one of the questions or you think you have a rough idea then I'd be > grateful if you'd get in touch. > Does that mean e-mail you? Whoops sorry! > Cheers, > > Scott "stuck again.....what a surprise" Ward. >