you would think it being such a simple geometrical object, it would be within the java.awt.geom package along with Rectangle. And I've noticed a lot of people use it for collision checking. I find it that on certain occasions it might be preferable to use a circle for collision checking. So what do people use other than Rectangle? Since I needed to do collision checking with circles I kind of just went and made my own Circle class. But I'm curious as to what people use.

Also circles are so simple I generally wouldn't use the geom versions anyway. Same goes for rects.

So you don't use classes from the geom package for collisions? What do you use?

Correct me if I'm wrong, but a circle is a type of ellipse that just happens to be symmetrical from its center to any point lying on its edge. Also, a square is just a rectangle that has all equal sides. Therefore, it shouldn't matter, should it?

well an ellipse is an ellipse because its got two foci points and therefore it doesn't have a radius. Whereas a circle only has one focus point and it does have radius where any distance from the focus point to any point in the circumference of the circle would be constant. Now a square is a square because its width and height are equivalent.You can't just say a rectangle is technically a square and an ellipse is technically a circle. They're all different else they wouldn't have different names and mathematical explanations of what they represent.

But other then that... what do you guys use for collisions besides rectangles? or do you use the Geom package at all?

well an ellipse is an ellipse because its got two foci points and therefore it doesn't have a radius. Whereas a circle only has one focus point and it does have radius where any distance from the focus point to any point in the circumference of the circle would be constant. Now a square is a square because its width and height are equivalent.You can't just say a rectangle is technically a square and an ellipse is technically a circle. They're all different else they wouldn't have different names and mathematical explanations of what they represent.

But other then that... what do you guys use for collisions besides rectangles? or do you use the Geom package at all?

Nobody's saying that squares and rectangles are the same and that ellipses and circles are the same. A circle falls under the category of ellipse, just as a square falls under the category of rectangle. They're both special instances of each category, much like how ellipses and rectangles fall under the category of shape. You could go even more generic with rectangles and say they stem from parallelograms but differ in that their angles all must be right. A line from Wikipedia to clarify the definition of a circle as related to an ellipse is the following:

"A circle may also be defined as a special ellipse in which the two foci are coincident and the eccentricity is 0."

That's basically a rehashing of what I said previously.

Now, if you want to know how to do collisions with circles.... well, just use the distance formula. It's easier than dealing with ellipses, thanks to the fact that there's only one focus, essentially.

But other then that... what do you guys use for collisions besides rectangles? or do you use the Geom package at all?

One can use the equations for a rectangle, or square, or circle directly, without involving the Geom package. When doing a circular check, I like using Point2D objects and the distance() method. Other folks here probably have more efficient ways of calculating distance between two locations, but the distance() method is pretty good, too. When using rectangular or shape bounds, I have to admit I am kind of lazy and like to use the contains() method that is in many Graphics2D shapes.

You could also use a mapping method, no math involved whatsoever! But I am the only person I know playing around with that. I have an app where I place links to the object occupying a space into the 2D array slot that corresponds to that space. The rule is that only one object can occupy the given space, so the space on the screen that corresponds to that array point has to be pretty small. (The array becomes perhaps as big as the display, or a quarter size if you work with units of 4 pixels.) A single object can thus occupy a couple dozen array spaces. It makes moving the objects more cumbersome, but collision checking (which can grow geometrically) becomes trivial as a result. It is a tradeoff that might work well in special cases (e.g., lots and lots of small objects possibly colliding).

"We all secretly believe we are right about everything and, by extension, we are all wrong." W. Storr, The Unpersuadables

But other then that... what do you guys use for collisions besides rectangles? or do you use the Geom package at all?

One can use the equations for a rectangle, or square, or circle directly, without involving the Geom package. When doing a circular check, I like using Point2D objects and the distance() method. Other folks here probably have more efficient ways of calculating distance between two locations, but the distance() method is pretty good, too. When using rectangular or shape bounds, I have to admit I am kind of lazy and like to use the contains() method that is in many Graphics2D shapes.

You could also use a mapping method, no math involved whatsoever! But I am the only person I know playing around with that. I have an app where I place links to the object occupying a space into the 2D array slot that corresponds to that space. The rule is that only one object can occupy the given space, so the space on the screen that corresponds to that array point has to be pretty small. (The array becomes perhaps as big as the display, or a quarter size if you work with units of 4 pixels.) A single object can thus occupy a couple dozen array spaces. It makes moving the objects more cumbersome, but collision checking (which can grow geometrically) becomes trivial as a result. It is a tradeoff that might work well in special cases (e.g., lots and lots of small objects possibly colliding).

That actually sounds a lot familiar to something that Cas described to me, whereby entities are kept track of in a grid-like system. Seems like that's the latest trend these days!

is it? Cool. It makes sense to me. I was rethinking this after writing a brute force collision algorithm (every item against each other) and feeling like there had to be a better way. So I tried to forget about programming and envision the situation in the "real world". What happens when two items collide? There is no searching for neighbors and testing of boundaries. The collision occurs in the space itself. So why not replicate/model "space" (only one thing can occupy a space and the thing itself is in that space).

It seems to me a clear case can be made that scaling up is linear--the test remains the same no matter how many objects there are. The only thing that increases in cpu cycles is that each object takes a bit more effort to move and track. But again, scaling is linear, yes? The task of moving item A is the same no matter how many other items are in the model.

My guess is if the method is not used, it is because it is kind of anti-intuitive. Who wants to go to all the extra trouble managing the "space" model, especially with shapes that are kind of large and complex?

"We all secretly believe we are right about everything and, by extension, we are all wrong." W. Storr, The Unpersuadables

is it? Cool. It makes sense to me. I was rethinking this after writing a brute force collision algorithm (every item against each other) and feeling like there had to be a better way. So I tried to forget about programming and envision the situation in the "real world". What happens when two items collide? There is no searching for neighbors and testing of boundaries. The collision occurs in the space itself. So why not replicate/model "space" (only one thing can occupy a space and the thing itself is in that space).

It seems to me a clear case can be made that scaling up is linear--the test remains the same no matter how many objects there are. The only thing that increases in cpu cycles is that each object takes a bit more effort to move and track. But again, scaling is linear, yes? The task of moving item A is the same no matter how many other items are in the model.

My guess is if the method is not used, it is because it is kind of anti-intuitive. Who wants to go to all the extra trouble managing the "space" model, especially with shapes that are kind of large and complex?

I agree, it makes more sense than having a brute-force method that checks each entity against every other entity in the game space. That, and it's somewhat elegant. It seems all the best algorithms and ways of doing things are fairly simple compared to what most people would think of. Recursion, for example, tends to be so beautiful and simple compared to the ways in which you would have to implement the same algorithms using alternative methods.

well, when I made that circle class, I gave it much of what the rectangle class has such as contains() and intersects() but using GeneralPath to create a polygon that with just 20-24 vertices forms a circle. its got a intersects() for checking against rectangles and another one for checking against instances of the same circle class. I implemented the distance method that you mentioned for checking between those of the circle class. So I'm well aware of that method and how to use it.But instead of checking that circle/entity against all others I simply created a circular range of view around the smaller circle. And sort of like a radar it checks if there is anything within range and then I have other methods that handle what to do on each situation.

And going with what philfrei said about how things would happen in real life. I'm looking more from a organism perspective in that we check before we move. So I'm thinking if an instance is constantly checking its path ahead of time before it moves its also an alternative.

You probably should avoid using geom classes for physics related things in games. Circle collisions are easy enough to implement that they can be incorporated into an existing class with hardly any code. If you already have a class that handles game objects you can store its data in private fields. Its position can be stored in public or private double x, y fields instead of a Point class; store its boundaries as private static final double leftOffset, rightOffset, topOffset, bottomOffset instead of in a Rectangle class (for AABB tests, circle collisions would only need to store private static final double radius); and collisions can be handled in an update() method. There are no absolute rules, but why write your game around the geom classes?

The two "best" options are probably to 1) implement your own collision tests inline with the rest of your code or as static methods in utility classes - if you have a final plan in mind and want that level of control or 2) use existing libraries - if you plan to create a more complicated game physics system that relies on multiple generic forms of collision detection (and most collision detection libraries are object oriented and polymorphic), then a library dedicated to that purpose is likely suitable and easier to use.

You probably should avoid using geom classes for physics related things in games. Circle collisions are easy enough to implement that they can be incorporated into an existing class with hardly any code. If you already have a class that handles game objects you can store its data in private fields. Its position can be stored in public or private double x, y fields instead of a Point class; store its boundaries as private static final double leftOffset, rightOffset, topOffset, bottomOffset instead of in a Rectangle class (for AABB tests, circle collisions would only need to store private static final double radius); and collisions can be handled in an update() method. There are no absolute rules, but why write your game around the geom classes?

The two "best" options are probably to 1) implement your own collision tests inline with the rest of your code or as static methods in utility classes - if you have a final plan in mind and want that level of control or 2) use existing libraries - if you plan to create a more complicated game physics system that relies on multiple generic forms of collision detection (and most collision detection libraries are object oriented and polymorphic), then a library dedicated to that purpose is likely suitable and easier to use.

again, thanks for the great insight. I gotta admit that I followed the crowd on this one. I started out doing collision checking with my own code. Using simple mathematical formulas I had the program doing some calculations (sort of like what you have there in that piece of code) to do all the collision checking I needed. Then reading a few posts in some forums, and in some tutorials I noticed that all those people were using the geom package (more specifically the Rectangle class) for collision checking. And that didn't involve any processing of my mathematical filters/calculation of formulas for the program, and that intersects() method seemed to get the job done and possibly better. So i thought using geom was a better way to go at it. So what exactly is wrong with using geom? Does it actually require more processing then what I was doing prior to using it?

btw, thanks for that bit of code there, gonna implement them and see how they work.

So i thought using geom was a better way to go at it. So what exactly is wrong with using geom? Does it actually require more processing then what I was doing prior to using it?

It's not "wrong", it's just not the ideal tool for the job. Those classes are intended for use with graphics. A lot of useful operations for game programming are missing. Moving objects, for example, might require that you know the time, location, and portions of the shape involved in a collision. There is no support for that in the geom classes and you would end up having to rewrite large portions to accomplish game specific details in many cases. That doesn't mean there's necessarily something wrong with the algorithms they do implement. You can make use of them by reading the source code and using that information as a reference. For example, you can rewrite Rectangle2D's intersects method as a static function with 8 parameters instead of a separate object and 4 parameters.

Quote

again, thanks for the great insight. ... btw, thanks for that bit of code there, gonna implement them and see how they work.

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