Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Collision issue - any ideas?

Author
Message
Jamesb187
16
Years of Service
User Offline
Joined: 26th Nov 2008
Location:
Posted: 30th Nov 2008 09:04
Hi all,

Noob time again. I'm working on a Space Invaders clone, and am having some problems with detecting collision between shots fired from the base and the aliens. I'm using the following code to draw the alien sprites (sprites 1 to 50) and the shot from the base (sprite 54) - when I run the code, the shot will pass through the first 3 rows of aliens (sprites 20 to 50) and succeed in colliding with (and removing) the aliens in the first 2 rows (sprites 1-20). I can't for the life of me understand why this should be - there's some simple loops through all of the sprites to check for collision in each iteration of the main game loop - so can't work out why it would detect the collision for 20 of the 50 sprites but not the other 30.

As far as I can tell, there is definitely collision between the two sprites when the bullet passes over the lower aliens, as I have tested moving the bullet at 1 pixel per cycle to ensure that it doesn't "jump" the pixels of the alien.

Any thoughts or suggestions would be gratefully received!

steve paul thomas
16
Years of Service
User Offline
Joined: 4th Nov 2008
Location: United Kingdom
Posted: 30th Nov 2008 13:37 Edited at: 30th Nov 2008 14:30
Perhaps it was the images? Since you didn't supply the images or make the code medialess, I knocked up some temporary graphics (which are rubbish, I know) and adjusted your get image coordinates slightly.

I can't seem to find a problem with this now. The code and pictures are attached.

When you fire your "bullet" and hit an alien in the bottom row, it disappears, You can then hit the one behind it, then the one behind him,etc.

Please let me know if the problem is still occuring.

[EDIT]: I changed the code slightly. Have used BLOCK CAPITAL REMARKS to show the changes I made. If you haven't downloaded the zip archive, then do that first.

Save the code below as another file.

Attachments

Login to view attachments
Jamesb187
16
Years of Service
User Offline
Joined: 26th Nov 2008
Location:
Posted: 30th Nov 2008 15:09
Steve,

Thanks so much for the quick reply. Rather than use your code I just changed mine slightly to use the one image that was working for all 5 rows of aliens, and this fixed the bug, so as you suggested it was the images - many thanks!

However, I'm still a little confused as to why my first alien image works and the other 2 don't - they are all 20x20 bmps, with a decent amount of coloured pixels. I've attached the three images, "alien1" is the one that works and the other 2 don't. Any thoughts?

Attachments

Login to view attachments
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 30th Nov 2008 18:49 Edited at: 30th Nov 2008 19:31
What I see a lot of new people doing is using the commands LOAD BITMAP when they are intending to load images. This may not answer your question Jamesb187, but I thought it's worth mentioning to avoid a common mistake and misconception.

One has to change their thinking a bit to understand what DB means by BITMAP. A Bitmap is the screen on which pictures (images if you will)are drawn. Do not confuse this with the picture file format for a DIB that usually ends with the extension .bmp . When you use a command such as load bitmap "alien1.bmp", Alien1 you are creating a hidden drawing area (an extra screen) sized to your file alien1.bmp . Since you are immediately grabbing the image wuth the GET IMAGE command, I am assuming your original intention was to create an image from the file. To do this, use LOAD IMAGE instead of LOAD BITMAP.

This is important because they are two different things and they both take up resources and memory. If you are not deleting the bitmaps after using LOAD BITMAP, they stay around in the background waiting to be drawn to. You'll then have a duplicate of your picture when you are using GET IMAGE. So, to minimize resource usage in this case, use LOAD IMAGE directly.

Also, you are only allowed to use 32 bitmaps (screens) 0 to 31. 0 is the main display screen where everything is displayed. The others are hidden in memory. There can be 65535 images on the other hand. So, to state it flat - BITMAPS are drawing areas, IMAGES are the textures and pictures you will use in your games.

Now don't get me wrong. Often, one will have a page of multiple images. Like a sprite sheet that may have a series of images laid out that represent a simple animation. In this case, one may use LOAD BITMAP to load the entire sheet. Then use get image to select the specific areas from the sheet.

As far as the size of your images,

Quote: "they are all 20x20 bmps"


When you are capturing an area using GET IMAGE, the x2 y2 size always captures 1 pixel less than their values. So logically it seems GET IMAGE alien1,0,0,19,19 would capture 20 pixels (0 - 19), but it only captures 19. You would have to use
GET IMAGE Alien1,0,0,20,20
to capture the full 20 pixels.

One other thing, you can improve performance by capturing your images directly to video memory if you want. Add a ,1 at the end of the GET IMAGE or LOAD IMAGE commands:


DBC automatically copies from SYSTEM memory to VIDEO memory if you don't load your images directly to video memory, but if there are a lot of images, it can hamper performance; especially if they are large images.

Now in answer to your question, it probably has to do with the color of the bullet. There's some sprite collision glitch that can cause problems if the color isn't just right. Each of the color components are compared (red blue green) in the collision. If transparency is on, sometimes a 0 in one of the compnents will be read as transparent and no collision will be detected. Try making the bullet white and see if that makes a difference. Or try making sure all of the images have some measure of red green and blue in them (more than 10 units).

Here. I changed the bullet to a green block with some red and green in it (15 units of each) and it works with all of the aliens:



Enjoy your day.
steve paul thomas
16
Years of Service
User Offline
Joined: 4th Nov 2008
Location: United Kingdom
Posted: 1st Dec 2008 02:44 Edited at: 1st Dec 2008 02:53
@Jamesb187

Try out this program that I made. It demonstrates a possible use for multiple bitmaps (3 in this example, bitmap 0 (the screen) and two off-screen bitmaps).

Read the comments at the top of the code for more info...

Snippets Board:
http://forum.thegamecreators.com/?m=forum_view&t=140836&b=6

I don't Adam and believe it!
Jamesb187
16
Years of Service
User Offline
Joined: 26th Nov 2008
Location:
Posted: 1st Dec 2008 03:02
Latch,
Thanks so much for that tip on the colours - I've changed the bullet to white and it works fine. Those are the kind of bugs that have you pulling your hair out - now I know about that one, it shouldn't trip me up again. Also thanks for the tip on loading images direct rather than via bitmaps, I didn't know you could do that; I've adapted my code and it works a treat.

Steve - thanks for that illustration on the bitmaps, makes it very clear.

These forums are a godsend, as soon as I have some knowledge to impart I'll help out the noobs...
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 1st Dec 2008 15:36
@Jamesb187

Quote: "I've changed the bullet to white and it works fine. Those are the kind of bugs that have you pulling your hair out "


It's a bug in DBC not in your code. One might not find it unless looking for it. Anyway, your bullet doesn't have to be white. I suggested white because it contains full R G and B values. A color is made up of RED GREEN and BLUE with values of each ranging from 0 to 255. If you remade your bullet and wanted it green, it should work if you color it rgb(15,255,15), or even rgb(10,255,10). When checking for collision with sprites and they have a color like rgb(255,0,255) - purple - that 0 in the middle may cause collision not to occur because the sprite is considering the green component transparent. Kinda weird but as long as all 3 colors have some number (10 is pretty good but you should lower it and see what works) collision should detect ok.

Enjoy your day.
Jamesb187
16
Years of Service
User Offline
Joined: 26th Nov 2008
Location:
Posted: 2nd Dec 2008 08:10
Yup, got it - I`ll avoid using any pure colours from now on. I`ll make sure that I`ve got a good mix of rgb in there.

Cheers!
TDK
Retired Moderator
22
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 5th Dec 2008 19:44
I remember going through this process many many years ago and it's down to apparent differences to the way boolean logic works in different screen modes.

What are you using for the bit depth - 16 or 32bit?

If I remember correctly, if you switch to the one you are NOT currently using, the problem goes away without having to alter the colours used in your sprite images..

TDK_Man

Jamesb187
16
Years of Service
User Offline
Joined: 26th Nov 2008
Location:
Posted: 6th Dec 2008 12:17
Well I had the screen set up as 16 bit, and the invader and bullet images as 16 bit too. I'll have a play with the depths and see if it helps. Thanks for the pointer.

Login to post a reply

Server time is: 2025-06-07 17:28:09
Your offset time is: 2025-06-07 17:28:09