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.

AppGameKit Classic Chat / So, what do you guys do for collision detection?

Author
Message
basicFanatic
6
Years of Service
User Offline
Joined: 7th Jun 2017
Location:
Posted: 13th Jul 2018 20:01
I found this: Pixel-perfect sprite collision Looks great, but doesn't work with animation or rotation. So I need a way to make do with the build-in stuff. So I'm wondering, do you have any hacks or best practice when it comes to collision detection?

My only hack is to remember that the player is much more forgiving when the error is to his benefit. If the player walk too close to the lava, and it fails to hurt him, he won't mind this much. But if the lava hurts him without him touching him, this is a really serious flaw.
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 13th Jul 2018 21:53
I think it depends on the sprite and what collusion is needed. If it's a small sprite then a little inaccuracy may not be an issue. If it's a bigger sprite, can you make it out of smaller ones? Such as arms separately etc? Then you can collision check each of the individual sprites?
Bengismo
6
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 13th Jul 2018 22:28 Edited at: 14th Jul 2018 00:09
There is the basic collision routines but there are also some pretty great newer features...

You can use multiple sprite shapes ....this allows you to add many many shapes up to make up the shape of your sprite while still keeping the sprite collision fairly quick. Basically, you can take some fairly complex character shapes and get it very close to being pixel perfect by making multiple collision shapes. There isnt much limit for this. Ive not found an easy way to configure the shapes for complex characters yet though so its time consuming to make them. This works pretty well....

Moving on to a more advanced way...You can combine sprite shapes with pixel checking...

You can use GetPhysicsCollision() so you can then that there is an intersection and loop through the intersection points with GetPhysicsCollisionWorldX/Y()
If not using physics then GetSpriteCollision and GetSpriteDistancePoint1() does a similar job to get coordinates

Then you can get pixel perfect collision checking....use GetSpriteXFromWorld( iSpriteIndex, x, y ) to get which pixel actually collided and check an colour/alpha value. This could even be include animation by checking the current animations frame.

This is a bit long winded and probably needs examples to make sense but this then allows fully rotatable collision detection in world space. This is a bit advanced and is really only needed if your absolutely need pixel perfect which is rarely needed.

EDIT:
Quick example for a non animated object
Phaelax
DBPro Master
20
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 14th Jul 2018 03:41
I'm confident I can support animations in my pixel collision system. Rotation, however, I'm still researching. I feel there is a simple method of being able to take my pixel data and add a rotational transform matrix to it but I haven't worked out how yet.
Tiled TMX Importer V.2
XML Parser V.2
Base64 Encoder/Decoder
Purple Token - Free online hi-score database
Legend of Zelda

"I like offending people, because I think people who get offended should be offended." - Linus Torvalds
IronManhood
9
Years of Service
User Offline
Joined: 6th Feb 2015
Location: US
Posted: 14th Jul 2018 09:40
I made this tool to speed up setting multiple complex shapes for sprites. SetSpriteShape v1
Bengismo
6
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 17th Jul 2018 00:54 Edited at: 17th Jul 2018 01:32
Quote: "I made this tool to speed up setting multiple complex shapes for sprites. SetSpriteShape v1"


Thats pretty cool...it certainly speeds up the generation of sprite shapes. Thanks for that.

Quote: "I'm confident I can support animations in my pixel collision system. Rotation, however, I'm still researching. I feel there is a simple method of being able to take my pixel data and add a rotational transform matrix to it but I haven't worked out how yet."


I can support pixel collision detection with rotation of the two sprites but not tried with animation yet....as that then makes the sprite image area a small subset of the image it is showing. Ive never actually tried adding animation support with the function I wrote. It might actually work with animation if i add a few lines to convert from sprite pixel x/y to uv x/y based on the current frame? I can post the function that works with rotation if it helps



.....The other issue I have is that each collision check between 2 sprites that are each 64x64 takes 0.5-1ms which is sllloooww. It generates iamge memblocks on every collision check which makes it slow and thes should be genrated once and kept. This algorithm really needs doing in the C source code rather than interpreted basic as to check 10 sprites for pixel perfect collision takes approx 8ms and so is a bit slow to do for lots of sprites. Its pre-checking for a collision between the sprite shapes too so theres not to much i can do to speed it up other than keep copies of image memblocks and that only helps a bit. I wouldnt use this for checking large sprites!!

Sprite shapes is by far the fastest way...pixelcollision is only good for low res sprites or...teir 2
Phaelax
DBPro Master
20
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 17th Jul 2018 14:31
I'll definitely take a look at your rotation stuff.

Quote: "check between 2 sprites that are each 64x64 takes 0.5-1ms which is sllloooww"

My method builds a collision mask up front, using only 1 bit per pixel, so no memblocks. A 64x64 image would only use up an additional 512 bytes to store this info, so the memory tradeoff is negligible.
Here's my thread, along with a tutorial explaining my process:
https://forum.thegamecreators.com/thread/219444

And here's the original thread on pixel collision that sparked the whole thing: https://forum.thegamecreators.com/thread/219346
Tiled TMX Importer V.2
XML Parser V.2
Base64 Encoder/Decoder
Purple Token - Free online hi-score database
Legend of Zelda

"I like offending people, because I think people who get offended should be offended." - Linus Torvalds
Bengismo
6
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 17th Jul 2018 14:47 Edited at: 17th Jul 2018 14:48
The mask already exists as alpha in the image so... i felt no need to remake as 1bpp really. (Alpha of 0 = 0 and any other value is 1.0.)

With no rotation its very easy and is just comparing two pixel alpha values and my nonrotaion pixel checking is super quick....Its rotation and the conversion between sprite pixels that slows it down.

This is doable in a GLSL shader including rotation too which would be much much quicker I think. As I dont need t right now, im not gonna try write that!

Login to post a reply

Server time is: 2024-03-28 11:05:03
Your offset time is: 2024-03-28 11:05:03