Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  [SOLVED]Collision Detection Types and which is the best  (Read 2222 times)
0 Members and 1 Guest are viewing this topic.
Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Posted 2013-04-15 21:35:40 »

Hey Guys! Just a question about collision detection here: I know about the simple AABB method but unfortunately that will not be sufficient for my most recent game. And I also know a little about pixel perfect collision although that seems like overkill for a simple game like mine. So I came up with two things: Separating axis theorem or detecting if the polygons overlap. Both would require me to make a polygon out of them otherwise it would just be like AABB. So my question is do you have any recommendations for which one? (It seems like i might use both or they are interchangeable) and any articles or tutorials for these. I have been trying to get some help online but it just makes me more confused than when I started persecutioncomplex So I could use some help from the awesome community! I figured I need help creating polygons (defining vertices? or create triangles (essentially the same)) and then a little with overlapping testing. I have read up on articles about these although the code examples or other help I have found is not to helpful....

EDIT:
Currently I just have images created (different shapes that the full rectangle) and no polygons for a close surrounding area of the thing in the image

EDIT 2:
A thought of how it would work with polygons drawn

Offline UprightPath
« Reply #1 - Posted 2013-04-15 22:05:48 »

Yay, my cents!

AABB vs Polygon: Depends on how close to 'realistic' physics you want. Typically, your player will always be an AABB object with limited physics applied to them. That is: If they're standing on the ground then they're standing on the ground and gravity doesn't matter to them. At most, you'll do some basic 'friction' computations for slopes, differing ground types, etc.

The world: AABB can be good for doing a broad-phase resolution (There are MANY strategies). The only way an AABB agent can collide with something is when their AABBs intersect. After you find out that there MIGHT be a collision, then you go to the narrow-phase where you check the geometries. :3

Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #2 - Posted 2013-04-15 22:08:42 »

In my game (which you can check out in my WIP section) is an rpg based so you are not moving at one level. AABB seems good for a broad phase but the polygon / other type of collision detection is the part where im confused.
EDIT:
the reason im thinking aabb is not suffiecent is that it creates a rectangle and creates possible collision areas which are not exactly close to the player or the object in the image. This is shown in the image of the first post.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 136
Projects: 4
Exp: 3 years



« Reply #3 - Posted 2013-04-15 22:17:47 »

Your polygon strategy isn't going to work for a 2d rpg style game, because then the player will collide with the tree even when the player should be going behind the tree. You should be thinking (red lines)

Like with tiles. Remember, with this type of game, you're faking the height, because the player moves in x/y but you still have the height of the player and the tree.
Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #4 - Posted 2013-04-15 22:20:38 »

Hey that actually makes a lot of sense! It also simplifies a lot of things. My only question now would be how could I change the order that these things are drawn so that it appears behind the tree...? Also I think there are still some objects that you can not pass around like an oddly shaped lake which I would need some type of polygon detection on

Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 136
Projects: 4
Exp: 3 years



« Reply #5 - Posted 2013-04-15 22:33:01 »

Hey that actually makes a lot of sense! It also simplifies a lot of things. My only question now would be how could I change the order that these things are drawn so that it appears behind the tree...? Also I think there are still some objects that you can not pass around like an oddly shaped lake which I would need some type of polygon detection on
I'd have to agree on the lake, AABB would probably not work. For drawing order, maybe just compare y coordinates, if player y > entity y draw entity in front, and if player y < entity y draw player in front (seems pretty primitive)
Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #6 - Posted 2013-04-15 22:34:45 »

Yeah I think the lake must turn in to polygons or something (But i still don't know how ... Sad ) and also I guess I will have to figure out some system to change drawing order that seems a little challenging to figure out

Offline Agro
« Reply #7 - Posted 2013-04-15 22:35:06 »

Use the bottom of the object as their collision mask. For humans it would be feet. For tree, it would be the trunk. And then assign radiuses to those positions and you can use circle circle detection to find it. You can also use AABB for this obviously.

Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #8 - Posted 2013-04-15 22:35:51 »

Thanks Agro thats like what Jimmt just said but i would have a problem with using AABB with something weirdly shaped like a lake

Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 136
Projects: 4
Exp: 3 years



« Reply #9 - Posted 2013-04-15 22:37:38 »

Yeah I think the lake must turn in to polygons or something (But i still don't know how ... Sad ) and also I guess I will have to figure out some system to change drawing order that seems a little challenging to figure out
For drawing order, I guess just have an ArrayList of entities (or whatever storage format you prefer) and shuffle things around. For the lake, a simple hack-ish solution would to have a list of bounding boxes (i. e. make cut the lake up into big and small rectangles) and then check against all if you want to stick to AABB (which i recommend).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #10 - Posted 2013-04-15 22:39:18 »

I guess cutting it into smaller squares would be the simplest way... Hmmm

Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #11 - Posted 2013-04-15 23:31:20 »

Would that be considered the right way to do this? I feel like I have never seen this in other peoples code / examples. Any suggestions on how / what to look into for polygon collision?

Offline ctomni231

JGO Wizard


Medals: 99
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #12 - Posted 2013-04-16 00:35:13 »

I think using the AABB method would be your best solution. To be honest, it'll be the fastest and since your game is kind of tile-based, you'll probably benefit the most by doing your logic in that way. If you complicate your logic with polygons and splitting it up, you'll slow down your game for a feature that most people will not care about. The only way I'd recommend it is if you are doing it as a learning exercise, and in that case... go crazy!

As for your drawing idea, If you want your 2D textures to have depth and appear above and below certain items. If your game is based off of tiles, you want to draw your images ordered from the top to bottom listed from the bottom of each sprite. That way, combined with collision detection, you'd be able to 100% fake the 3-D effect in a 2-D plane.

I hope this makes some sense.

Offline Agro
« Reply #13 - Posted 2013-04-16 00:40:50 »

Also, a lake would be best as having a square. Tile games don't generally make lakes go all random this way and that. So yes, AABB would be your best bet.

Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #14 - Posted 2013-04-16 00:44:19 »

I think using the AABB method would be your best solution. To be honest, it'll be the fastest and since your game is kind of tile-based, you'll probably benefit the most by doing your logic in that way. If you complicate your logic with polygons and splitting it up, you'll slow down your game for a feature that most people will not care about. The only way I'd recommend it is if you are doing it as a learning exercise, and in that case... go crazy!

As for your drawing idea, If you want your 2D textures to have depth and appear above and below certain items. If your game is based off of tiles, you want to draw your images ordered from the top to bottom listed from the bottom of each sprite. That way, combined with collision detection, you'd be able to 100% fake the 3-D effect in a 2-D plane.

I hope this makes some sense.


So your saying you think splitting up complex shapes into rectangles would be the best rather than polygons?

By your drawing suggestion would you recommend changing what is drawn based off of the y coordinate as Jimmt did?

Also, a lake would be best as having a square. Tile games don't generally make lakes go all random this way and that. So yes, AABB would be your best bet.

I'm not too sure if this is tile based, I don't exactly have a tile set created I am just creating images as I go but I suppose you could still call it a tile set> Also a square lake would look very awkward and I don't think I will use that approach

Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 136
Projects: 4
Exp: 3 years



« Reply #15 - Posted 2013-04-16 01:02:21 »

I think Agro is talking about something like this:

See how it's not the entire lake that's made up of a rectangle, but it is in rectangular tiles. That's why it's important to make your tiles the right size.
(The rounded corners in my example are purely graphical, I'm pretty sure collision detection is still handled AABB style).
Offline Agro
« Reply #16 - Posted 2013-04-16 01:08:13 »

Yeah, things also like pokemon. The rounded edges are graphical enhancements, they don't affect its bounding box.

Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #17 - Posted 2013-04-16 01:09:01 »

I like work around. THey make things much easier. I suppose this will have to be the approach I use. Thank you guys for these suggestions

Offline quew8

JGO Coder


Medals: 31



« Reply #18 - Posted 2013-04-16 11:15:49 »

Sorry I'm late. I know you've kind of already decided but if you ever do want to try complex (and convex) polygon vs aabb detection then sax (Separation Axis Theorem) is a good way to go. It works polygon vs polygon but can be optimized if you know one shape is a aabb.
Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #19 - Posted 2013-04-16 14:54:42 »

Any suggestions for polygon tutorials or something?

Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 136
Projects: 4
Exp: 3 years



« Reply #20 - Posted 2013-04-16 16:08:44 »

Any suggestions for polygon tutorials or something?
I thought you were sticking with AABB? Well if that isn't the case then a quick way would be to use (libgdx port of) box2d and Aurelien Ribon's physics body editor (and also here) which can auto-trace shapes and saves to a .json. Box2D is mainly for platformers but you can adapt it to a rpg style game by setting gravity to 0.

If you're going to go this path, also read this on how to separate your collision logic and your rendering.
Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #21 - Posted 2013-04-16 20:16:30 »

I'm pretty sure I'll go with aabb for this but I sure would like to learn about polygon collision. Thanks jimmt

Offline relminator
« Reply #22 - Posted 2013-04-17 08:15:52 »

Any suggestions for polygon tutorials or something?

http://back2basic.phatcode.net/?Issue_%231:2D_Convex_Polygon_Collision_using_SAT

Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #23 - Posted 2013-04-18 01:20:24 »

its articles like that, that confuse me persecutioncomplex

Offline relminator
« Reply #24 - Posted 2013-04-18 02:03:39 »

its articles like that, that confuse me persecutioncomplex

What's confusing about the article?  I mean that sat uses a very simple vector projection (2 muls and 1 add).  You might want to read on vectors first before trying to implement collisions more complex than AABBs.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (36 views)
2014-10-17 03:59:02

Norakomi (28 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (27 views)
2014-10-15 16:18:58

TehJavaDev (52 views)
2014-10-14 00:39:48

TehJavaDev (54 views)
2014-10-14 00:35:47

TehJavaDev (42 views)
2014-10-14 00:32:37

BurntPizza (63 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (77 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!