Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  New Version of Phys2D  (Read 7691 times)
0 Members and 1 Guest are viewing this topic.
Offline kevglass

JGO Kernel


Medals: 166
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Posted 2007-02-14 19:59:36 »

New version of Phys2D available including:

- Several Bug Fixes
- New Joint contribution - SpringJoint
- New Demo

http://www.cokeandcode.com/phys2d

Kev

Offline gideon

Senior Newbie





« Reply #1 - Posted 2007-02-14 22:30:59 »

I have started working on collision detection for convex polygons. Since someone else is (or was) already working on non-convex I chose this as a compromise. If both are finished the library's users have more choice. Maybe I'll also write a simple partitioning algorithm to break any polygon into convex ones when the need arises. When writing this I ran into what seems to me a design error in the library. This occurs when a test is needed between two Shapes. A visitor pattern is used as follows:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
public interface Shape {
    public abstract Collider getCollider(Shape other);

    public abstract Collider getColliderFor(Box box);
    public abstract Collider getColliderFor(Circle circle);
}

public class Box implements Shape {
    public Collider getCollider(Shape other) { return other.getColliderFor(this); }

    public Collider getColliderFor(Box box) { return new BoxBoxCollider(); }
    public Collider getColliderFor(Circle circle) { return new CircleBoxCollider(); }
}

public class Circle implements Shape { ... }


The upside of this use of the visitor patter obviously is the absence of casts and instanceof if-else constructs. However, there is a big problem with it as well: when I add a new shape, I have to edit not only Shape but also all classes that implement Shape. This basically makes extension of the library by the user impossible without editing the library itself. Furthermore, in the current setup it is difficult to follow due to the indirections.

I would propose to use a factory class to retrieve the correct collider. The factory method should be a singleton rather than rely on static methods because the user should be able to override it.

What do you think?


The towship's adventures
Offline kevglass

JGO Kernel


Medals: 166
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #2 - Posted 2007-02-14 23:29:51 »

It was originally a factory and got moved to being this way. So moving it back, if it's really required sure. As long as it doesn't introduce any reflection (or pseudo reflection, i.e. getClass()) then it's cool with me. If you want the API to support users plugging in their own shapes and colliders then it might be better just to make a central registry that you can register shape pairs with a collider or something?

Singleton vs Static methods - I'd really rather not go down this discussion, it rarely seems to get anywhere. Which you use is up to you.

Kev

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gideon

Senior Newbie





« Reply #3 - Posted 2007-02-15 09:14:11 »

Well, I'm not quite sure about wether or not users would add new colliders, but it would be nice I suppose. You really dislike reflection that much? Maybe there's some caveats I'm unaware of? In these cases I usually just choose the simplest solution. What I dislike most about most uses of instanceof, is the fact that, in most situations, you still need to cast the object. I suppose I prefer C++'s way of dealing with it. But well, in my eyes both java's and c++'s typing systems are quite primitive anyway.

Anyways, from the top of my head I don't really see a solution without reflexion. Any ideas?

The towship's adventures
Offline kevglass

JGO Kernel


Medals: 166
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #4 - Posted 2007-02-15 17:24:18 »

I'm not keen on reflection mostly through old habbits when it was a performance issue to be calling the methods regularly. I'm not entirely sure if there's still an issue - worth trying performance of getting a type ID against getClass() or something - if all's fine just ignore me Smiley

Kev

Offline gideon

Senior Newbie





« Reply #5 - Posted 2007-02-20 17:12:20 »

I have made quite a lot of progress. Convex colliders are implemented and I expect to have support for non-convex object very soon as well. If anyone would like to have a look at the code, check out the svn repository of towship: http://sourceforge.net/svn/?group_id=117163.

@kevglass
I will send you a patch as soon as things have advanced some more, but if you can spare the time to have a look at what I've done.. I would appreciate any comments.

There is one problem for which a solution is not entirely trivial though: I have to find an accurate penetration depth for collisions. The current algorithm only finds the intersecting faces from which I can get the intersection point and normal, but penetration is not as simple. Does anyone have any ideas how to solve this?

The towship's adventures
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #6 - Posted 2007-02-20 18:09:41 »

I'm not keen on reflection mostly through old habbits when it was a performance issue to be calling the methods regularly. I'm not entirely sure if there's still an issue - worth trying performance of getting a type ID against getClass() or something - if all's fine just ignore me Smiley

Kev

I'm not sure about instanceof but the rest of Reflection is still pretty slow.

Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #7 - Posted 2007-02-20 18:35:56 »

I'm not sure about instanceof but the rest of Reflection is still pretty slow.

I recently ran a speed test for instanceof and it was as fast as an int type identifyer check.

Marvin
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #8 - Posted 2007-02-20 23:49:21 »

Quote
There is one problem for which a solution is not entirely trivial though: I have to find an accurate penetration depth for collisions. The current algorithm only finds the intersecting faces from which I can get the intersection point and normal, but penetration is not as simple. Does anyone have any ideas how to solve this?

You can do a greedy search with your vertex-edges pairs, starting at your intersection point. Its optimal for convex polyhedra.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline gideon

Senior Newbie





« Reply #9 - Posted 2007-02-21 09:30:56 »

I might give that a try, but I'll have to find an approximation method as well for non-convex polygons.

The towship's adventures
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline irrisor

Junior Member





« Reply #10 - Posted 2007-02-21 09:39:41 »

I'm not sure about instanceof but the rest of Reflection is still pretty slow.
That's not true in all cases. E.g. using a final field containing a Method object and call this is only slower by about factor 3. Which is not that bad. It's never as fast as a direct call, of course.
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #11 - Posted 2007-02-21 14:02:55 »

That's not true in all cases. E.g. using a final field containing a Method object and call this is only slower by about factor 3. Which is not that bad. It's never as fast as a direct call, of course.

That's alright for individual calls, but if you want performance, that is a huge hit.  I have a project that I started out using reflection with.  I had a lot of method calls in a loop and it was bad.  I didn't think it would work, but I tried it anyway because it was cleaner that having a huge if...else.

Offline irrisor

Junior Member





« Reply #12 - Posted 2007-02-21 15:22:57 »

ok, but compared to, i.e., jdk1.3 or similar, where it was factor 300 and up, it's fast now Smiley
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #13 - Posted 2007-02-21 16:15:11 »

this is the part where I wish java had function pointers  Roll Eyes

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #14 - Posted 2007-02-21 16:52:33 »

this is the part where I wish java had function pointers  Roll Eyes

Yes.  There are times where that would come in handy.

@irrisor:  That's for sure.

Offline gideon

Senior Newbie





« Reply #15 - Posted 2007-02-23 12:26:17 »

Well, I personally think that in this case the, apparently not so expensive, use of typeof won't give any measurable performance hit because it will happen only a very limited number of times per frame. Let's see, the number of narrow phase collision checks times two to be exact. So that's peanuts compared the actual collision check. Not that the discussion isn't interesting.

I really mis on the fly construction of (anonymous) functions, like lambda's in functional languages. Of course you can make an anonymous class in java, but I'd like to have access to variables in the scope without making things final. C# allows those kind of functions to be created. But I suppose this concept is only very distandly related to function pointers Wink so I'll stop ranting.

The towship's adventures
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #16 - Posted 2007-02-24 16:01:52 »

I was looking at the API for Phys2D and I note the collision system is very similar to JOODE's. I am trying to implement some 2D functionality for JOODEat the moment and I was wondering whether you would mind me intergrating your Geoms, Space and colliders into JOODE (in about a months time).

Tom

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #17 - Posted 2007-02-24 17:05:48 »

He doesn't mind (bsd license). Smiley

弾幕 ☆ @mahonnaiseblog
Offline kevglass

JGO Kernel


Medals: 166
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #18 - Posted 2007-02-24 17:44:18 »

What he said - have to note that gideon is doing some work for polygons at the moment which may effect the geoms. If JOODE could be stuck in 2D mode I'd be tempted just to use that anyway (though I haven't looked at the code at all yet Smiley)

Kev

Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #19 - Posted 2007-02-24 18:25:08 »

Its not quite ready to force into 2D mode yet, but soon...

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline gideon

Senior Newbie





« Reply #20 - Posted 2007-02-24 18:36:22 »

I think it's a great idea to have proper support for 2d in JOODE. All my work on phys2d is under the phys2d license as well so you can copy whatever you need. However, isn't there something to be said for a small 2d collision detection library as well? I mean, suppose JOODE has all the functionality for 2d that phys2d has at some point, would there still be a reason to maintain phys2d?

I was also wondering whether there is/will be a lot of shared code in the 2d and 3d stuff of JOODE, other than general math (vectors/matrices) and containers (hashmaps/lists). If there is not that much overlap, wouldn't it be good to have two separate libraries?

Then a small update on my progress. I've made significant progress for the convex polygon collisions. It seems to be working completely (also with lines, circles and boxes), but I have not thoroughly tested it yet and some optimizations remain. As I said before the methods I employ should work for non-convex polygons just as well (a little less efficiently though). I'll give that a try tomorrow or tonight.

I'm also in the process of allowing lines to be moving colliders, but haven't quite finished that. Unfortunately it means I will have to dive into the old code which is, imho, ugly and unreadable (not just because it's not my code).

The towship's adventures
Offline kevglass

JGO Kernel


Medals: 166
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #21 - Posted 2007-02-24 20:24:35 »

The line shape was a dirty hack in place of proper polygon support. Might be best to just rip it out altogether and only replace it if it's actually required for your project. Most things I want to do with the library won't need lines if polygon support is in there.

EDIT: Finally got around to looking at the code - looks great. I wonder if the collider factory might be tidier has a mapping table between pairs of shape classes to collider instances - less methods and comparisons that way. Just look up the pair, it could handle subclasses of shapes using the equals method of the pair wrapper also. Can't wait to see this running.

Kev

Offline biggeruniverse

Senior Newbie




That's just peanuts to space.


« Reply #22 - Posted 2007-02-26 02:38:25 »

I like the idea of sharing code between the projects for the time being. I hope sincerely that Phys2D keeps simplicity and speed, while I'd like to see JOODE become highly configurable and full-featured, with several choose-able integrators and a priori detection. Both projects can benefit from going down slightly different paths.
Offline gideon

Senior Newbie





« Reply #23 - Posted 2007-02-27 12:02:00 »

I hope sincerely that Phys2D keeps simplicity and speed, while I'd like to see JOODE become highly configurable and full-featured, with several choose-able integrators and a priori detection. Both projects can benefit from going down slightly different paths.

Seems like a good idea. I'll have to keep that in mind, since I have the more or less natural tendency to keep adding features/complexity it will be difficult Smiley for me.

Again a small update, I have colliding polygons now, but I discovered some bugs in the process. Some of which are very nasty, especially finding the collision 'features' proves to be a royal pain. These features are the entry and exit point of one polygon into the other. These can be simple, i.e. where the first polygon just penetrates the other's hull or complex when the first polygon goes all the way through the other polygon.

Not only does the contact point stabilization depend on these collision pairs but also the penetration depth calculation.

Hmm, who exactly am I explaining this to? Grin .. Well at least you know I'm still working on it.

The line shape was a dirty hack in place of proper polygon support. Might be best to just rip it out altogether and only replace it if it's actually required for your project. Most things I want to do with the library won't need lines if polygon support is in there.to see this running.

I'll see what I'll do with the lines, my first thought is to leave them in because they can be a lot more efficient in some cases, for example when polygons have very different sizes like walls colliding with objects. Also because the current implementation of polygons doesn't allow non-closed polygons, I'd leave them in. Maybe it's an idea to simplify them a little (the Line class I mean).

Then finally I have one question. I really need some containers here an there, sorted and otherwise. So far I've managed to restrict myself to a HashSet from the standard library. In the end however, these dependencies need to be cut. Does anyone have some good util classes under a BSD compatible licence?

--gideon

The towship's adventures
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #24 - Posted 2007-02-27 12:29:08 »

Then finally I have one question. I really need some containers here an there, sorted and otherwise. So far I've managed to restrict myself to a HashSet from the standard library. In the end however, these dependencies need to be cut. Does anyone have some good util classes under a BSD compatible licence?

 Huh Why do you need to not depend on the standard Java libraries?
Offline gideon

Senior Newbie





« Reply #25 - Posted 2007-02-28 16:52:38 »

I've got the polygon support more or less ready. There are still many bugs to find/fix, optimizations to be made and code to be cleaned up and better documented (although it is quite alright). Bottom line, no patch yet but you can get the current stuff from my project's svn server (which I mentioned in some earlier post in this thread).

To tease you, here's a picture of a nice demo (yes, it really runs perfecty):
Click to Play


Is there really no good BSD licenced util package out there? Because I've had to use some more standard java stuff.
Huh Why do you need to not depend on the standard Java libraries?
Well it wasn't really my choice, but Kevin put some effort into making it independent so I suppose I should keep it that way. There are some very clear advantages to having less dependencies though:
- no problems when the java api changes and the library will work with any java api
- it should be fairly easy to make a stand alone package which is light weight
- you don't have to deal with someone else's bugs (which is a minor issue with the standard libraries)
- .. probably more..

The towship's adventures
Offline kevglass

JGO Kernel


Medals: 166
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #26 - Posted 2007-02-28 18:13:48 »

Indepenent of AWT only - most of the rest of the JDK is fine.

Infact dragging in an additional library for containers etc would be more of an issue to me - it's about distribution size and ability to compile with GCJ and cut down JDKs..

Kev

EDIT: Looks frickin amazing btw Smiley Any ideas when the patch will be available - obviously it makes phys2d a much more viable project if polygon support is added.

Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #27 - Posted 2007-02-28 20:24:34 »

yeah. bring on the poly support!

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #28 - Posted 2007-03-01 19:44:32 »

*Really* impressive man. I'll be looking forward to have some release quality code so that I can provide support for Phys2D from Xith3D (efforts from physics are currently being made).

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Eliwood

Junior Member




Stencyl


« Reply #29 - Posted 2007-03-01 22:02:52 »

Wow, the more I see this unfold, the more I'm tempted to make the jump to this! But I can't at this point...

Nevertheless, great job. I look forward to seeing this in action. Smiley

Pages: [1] 2
  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.

Pippogeek (35 views)
2014-09-24 16:13:29

Pippogeek (28 views)
2014-09-24 16:12:22

Pippogeek (17 views)
2014-09-24 16:12:06

Grunnt (40 views)
2014-09-23 14:38:19

radar3301 (23 views)
2014-09-21 23:33:17

BurntPizza (59 views)
2014-09-21 02:42:18

BurntPizza (29 views)
2014-09-21 01:30:30

moogie (34 views)
2014-09-21 00:26:15

UprightPath (47 views)
2014-09-20 20:14:06

BurntPizza (51 views)
2014-09-19 03:14:18
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!