Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
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  
  Why is there no circle class? What do you use?  (Read 2510 times)
0 Members and 1 Guest are viewing this topic.
Offline Ryonik

Senior Newbie


Medals: 1



« Posted 2012-08-16 02:11:49 »

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.  Pointing
Offline davedes
« Reply #1 - Posted 2012-08-16 02:17:47 »

Ellipse

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #2 - Posted 2012-08-16 02:26:20 »

 Grin

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

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ryonik

Senior Newbie


Medals: 1



« Reply #3 - Posted 2012-08-16 02:42:48 »


Doesn't the ellipse class technically use an underlying Rectangle? it says so on the API. It's still not a perfect circle.

Grin

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?
Offline coltonoscopy

Junior Member


Medals: 2



« Reply #4 - Posted 2012-08-16 03:21:36 »


Doesn't the ellipse class technically use an underlying Rectangle? it says so on the API. It's still not a perfect circle.

Grin

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?

Straight flippin.
Online Jimmt
« League of Dukes »

JGO Kernel


Medals: 128
Projects: 4
Exp: 3 years



« Reply #5 - Posted 2012-08-16 03:42:17 »

Nope, you're right. That's why there's also no Square class. Because there's no need.
Offline coltonoscopy

Junior Member


Medals: 2



« Reply #6 - Posted 2012-08-16 03:43:36 »

Nope, you're right. That's why there's also no Square class. Because there's no need.
Well then, I would say that solves that dilemma! Cheesy

Straight flippin.
Offline Ryonik

Senior Newbie


Medals: 1



« Reply #7 - Posted 2012-08-16 05:55:44 »

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?
Offline coltonoscopy

Junior Member


Medals: 2



« Reply #8 - Posted 2012-08-16 06:05:49 »

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.

Colton

Straight flippin.
Offline philfrei
« Reply #9 - Posted 2012-08-16 07:01:27 »

Quote
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).

"Greetings my friends! We are all interested in the future, for that is where you and I are going to spend the rest of our lives!" -- The Amazing Criswell
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline coltonoscopy

Junior Member


Medals: 2



« Reply #10 - Posted 2012-08-16 07:02:55 »

Quote
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! Cheesy

Straight flippin.
Offline philfrei
« Reply #11 - Posted 2012-08-16 07:37:28 »

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?

"Greetings my friends! We are all interested in the future, for that is where you and I are going to spend the rest of our lives!" -- The Amazing Criswell
Offline coltonoscopy

Junior Member


Medals: 2



« Reply #12 - Posted 2012-08-16 08:06:13 »

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.  Wink 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.

Colton

Straight flippin.
Offline Ryonik

Senior Newbie


Medals: 1



« Reply #13 - Posted 2012-08-16 19:22:43 »

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.
Offline Best Username Ever

Junior Member





« Reply #14 - Posted 2012-08-17 01:35:20 »

It's really easy to work with circles even if you don't have an existing collision detection library to work with. For example:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
public boolean circleHitTest(double cx, double cy, double x, double y, double r)
{
  double dx = x - cx, dy = y - dy;
  return dx * dx + dy * dy < r * r;
}

public boolean twoCircleCollisionTest(double x1, double y1, double r1, double x2, double y2, double r2)
{
  double dx = x1 - x2, dy = y1 - y2, d = r1 + r2;
  return dx * dx + dy * dy < d * d;
}


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.
Offline Ryonik

Senior Newbie


Medals: 1



« Reply #15 - Posted 2012-08-18 06:20:17 »

It's really easy to work with circles even if you don't have an existing collision detection library to work with. For example:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
public boolean circleHitTest(double cx, double cy, double x, double y, double r)
{
  double dx = x - cx, dy = y - dy;
  return dx * dx + dy * dy < r * r;
}

public boolean twoCircleCollisionTest(double x1, double y1, double r1, double x2, double y2, double r2)
{
  double dx = x1 - x2, dy = y1 - y2, d = r1 + r2;
  return dx * dx + dy * dy < d * d;
}


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.
Offline Best Username Ever

Junior Member





« Reply #16 - Posted 2012-08-19 18:59:57 »

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.
Glad to help. You can appreciate that post if you want Wink
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.

Riven (9 views)
2014-07-29 12:53:52

Dwinin (7 views)
2014-07-29 10:59:34

E.R. Fleming (23 views)
2014-07-29 03:07:13

E.R. Fleming (9 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (51 views)
2014-07-17 23:47:54
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!