Sorry your browser is not supported!

How would I go about using pixel by pixel collision with Sprites? I do not want to use the built in function, dbSpriteCollision ().

Hell I would like to figure out pixel by pixel collision anyway I can! I can't get dbSpriteCollision to work at all.

Well, dbSpriteCollision() detects collision between two different sprites.

the way i understood it, the sprite collision functions that are native to GDK actually DO detect the collision pixel by pixel.... at least, i use the native functions to detect when a "mouse cursor sprite" is in contact with a "sprite button" and check if the mouse is being clicked at the same time, by using debug text to display the number of the sprite that is under the mouse cursor sprite, you can see that it is actually detecting it using pixel by pixel detection....

here is some simple debug text code that i use to display which sprite is affecting which other... you need to make sure that the sprites priorities are set correctly aswell, and that they are drawn :



in the above :
isprite_button is just an integer variable with a default value of zero.
imouseclick_holder is an integer that holds the value returned by the mouse clicking(the above 2 variables are defined earlier in my code)
the dbInk commands simply make sure my text is white when its written..(my program uses 2d drawing and changes the ink colour)

the next 2 lines are responsible for displaying the text and the values that are held by the 2 integer variables isprite_button and imouseclick_holder

The bottom line is the one that dispalys the sprite collision...

by calling the command dbSpriteCollision(sprite_num, 0); (in the above code I have used the sprite number 506, which is the number of the sprite representing my mouse cursor in my program) the returned value will be the number of any sprite that the sprite "sprite_num" is colliding with, it will be zero if there is no collision detected... again, a collision is detected exactly when the command is called and if there is ANY kind of pixel crossover between sprites at the same time that are currently drawn and active.. , this means that if you are using a sprite for an entire background or something, it may well show up as "always colliding" with a sprite(you would need to deactivate collision for that sprite or something), which means it wont detect others, as each iteration of the loop, you call the collision command once, and the value it gets is assigned(0 = no collision), the first sprite that it comes into contact with is the one that would be assigned... the way around this is to call the collision commands more than once each loop, each time checking for a specific collision... ie, one for each sprite on the screen that could be collided with... in some situations doing it like that would not be a good idea, such as when you are working with very large numbers of sprites like hundreds at once, although perfectly fine for a small set of 5-10 button sprites on the screen...

( Note that the above snippet was taken from a project in development and the placement values of the text are up in the top right hand part of the screen when the screen is set "dbSetDisplayMode(1024,768,32);" )

It would be possible to write your own pixel by pixel detection code for sprites, i think that you would need to store the values of each sprite's x and y screen coordinates in memblocks or arrays or however you choose to store that data, along with values for their size in pixels, ie, the coordinate of each pixel in the sprite, then you would just need to write code to check those values against each other, write it such that if any of the values are the same, there is a collision detected.(this is an over simplification, the mathematics and logic involved in tracking all of that data for each sprite and actually comparing it would be kinda complex I believe) Again though, i do believe this would be very similar to what the sprite collision system inside GDK is doing(correct me if im wrong please, i would like to know how it works if it not that way)

Thanks for the input, it really helps so far.

I'm planning on writing a game where you are shooting stacking boulders, I was using a sprite as the background and was never getting a proper result from the dbSpriteCollision query. How do you disable the background sprite from collision? I ask because in a few searches I've seen people telling people to do that, but not how to do that.

First try dbHideSprite(ibackground-sprite) before you call the collision detection, then dbShowSprite(ibackdround-sprite) after you have detected collision, but before you call dbSync() .. not sure if that would work, but you can try.. what i mean is :

1. create sprites
2. display sprites
3. draw screen once after creation to show em
4. hide background sprite
5. run collision detection routines
6. show background sprite
7. draw everything( dbSync(); )

If hiding/showing doesnt work, then I would suggest that you try changing the image from being a sprite to something else, and paste it to the screen each time you update the screen (if you are using a sprite for the background image just out of convenience, i mean you dont want to do any of the things to it that you can with sprites(flip, mirror, animate etc), then maybe consider changing it to be a plain image bitmap stored in memory instead of a sprite, especially if its interferring with collision)

I dont think there is any actual function you can call to stop a sprites collision detection once its drawn on the screen, such as dbSetSpriteCollisionOff(val) ... i dont think there is such a command, so we would need to think of a way to either use the image in a way so it does what you want, but isnt a sprite.. so maybe try making it an image or using some bitmap manipulation, and pasting it to the screen each time you update the screen, alternatively, you could write routines to check for individual collision between specific sprites, but this becomes complex when working with lots of sprites and you would need to store their various data elements in an array or something to iterate through it to check for collision


Detecting collision between sprites without using any of the native darkGDK functions, or in means beyond what they were designed for, is very difficult ,would require a bit of planning before attempting to code anything and I imagine there would be a number of different approaches that could be taken aswell..

Lastly, as for the specific code on how to achieve the various things discussed above, like hiding / showing sprites, sprite collision, using bitmaps and storing images in memory etc, please refer to the documentation that came with DarkGDK, and the samples and tutorials that came with it, they have examples of all of those kinds of things and more and are a great starting point for learning how it all works, also search through these forums for specific terms, such as "sprite collision", "bitmap image" etc, and you will find a heap of tips and tricks people have figured out, even the DarkBasic ones are usually fairly easy to code into DarkGDK code and good to learn from, and most of the functions look similar, the DB syntax isnt greatly different from DarkGDK.

Thanks. I used dbPasteImage( ) after loading the image with dbLoadImage( ) with every iteration of the main game loop and it took care of my problem. Thanks so much for the help!

Just a quick note, I have now played around with hiding a largeish background sprite, then detecting collisions etc, and hidden sprites WILL still be detected in collisions, unfortunately, im not sure if this is by design or not, but i think a simple way around it would be to simply move the offending sprite to a position where its top left corner is in the bottom right corner of the screen, then detect collisions, then move the sprite back, then draw everything. Again performance would be an issue moving the sprite like that though, playing with sprite priorities in that case may be an alternative.

Glad you found a solution Good luck with your project.

how about DeleteSprite() insteas of HideSprite()?

That might work, ill have to play with that... although deleting it will delete it from GDK memory, the actual object, and so invoke a little extra overhead as GDK cleans up(destructors are called etc), then the same again to recreate it... im not sure as to how efficient that would be versus just moving it around and/or hiding/showing, its something to play with and try though, in smaller games I dont think it would make a huge difference... although all these techniques(hiding/showing, moving bak and forth, deleteing/re-creating etc) could be nasty in larger games...

Experimentation is the key though i think... there are so many ways to manipulate sprites within the GDK, resulting in so many ways to detect collisions etc, just gotta play with different techniques till you find one that is efficient enough for your purposes and more importantly, works!

Here is my own collision detection which may help some people out. You first need an array of what ever you want to collide with, 1 is solid, 0 is not. Each number will represent a block. If TileSize = 32, the tiles are 32 by 32.

Collision:


Array: