Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (563)
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  
  Need odejava tweaking help  (Read 4394 times)
0 Members and 1 Guest are viewing this topic.
Offline frdfsnlght

Senior Newbie




Trying to understand


« Posted 2004-03-25 17:29:34 »

I've successfully integrated odejava into my project, but I'm having a hell of a time tuning the physics to get what I consider to be believable behavior. Here's what I have:

I've created a GeomTriMesh from a fractal terrain mesh to represent terrain. I've also created a simple box geometry to represent the user. The tri-mesh is added to the Space, the box is added to a body, which is added to the world. (BTW, the odejava API is pretty good, but it needs a ton more docs).

I've also, of course, created visual representations of all this using Java3D. The visual geometries exactly match the geometries I'm feeding odejava.

When I turn everything on (after setting the box's body position to be a couple of meters above the terrain), the box falls as expected and contacts the terrain. Then the box jitters a little (as I would expect) as things settle down. If I wait long enough, the box will start to slide down one of the tilted triangles it's landed on. That's cool too. But as the simulation continues, the box doesn't seem to behave very realistically, and eventually will flip completely over for no apparent reason. I've read the ODE docs and understand the issues concerning precision and instability, but I can't seem to get the system to behave nicely.

I think I need some guidelines on what setting values to feed to ODE. For instance, here's how I set up the world:

1  
2  
3  
4  
5  
odeWorld = new World();
odeWorld.setGravity(0, -9, 0);
odeWorld.setStepInteractions(2);
Ode.setSurfaceMu(4);
Ode.dWorldSetCFM(odeWorld.getId(), 1);


On each frame of rendering, I do this:

1  
2  
3  
4  
5  
odeWorld.setStepSize(frameTimeSeconds);
odeCollision.collide(odeSpace);
odeCollision.applyContacts();
odeWorld.stepFast();
odeConnection.updateAll();


Notice I'm using the DisplayBin class for the odeConnection variable (that whole API works quite nicely, BTW). Notice also that I'm not changing any of the contact collisions.

Am I doing anying fundamentally wrong here? Can anyone suggest better values or other settings for the world? Should I be doing something with the contact collisions?

-Tab
Offline Jani Laakso

Junior Member




Do it with Java!


« Reply #1 - Posted 2004-03-25 17:58:59 »

Quote
(BTW, the odejava API is pretty good, but it needs a ton more docs).


I agree, for High Level API you cannot even use ODE's own documention directly.

Quote

1  
odeWorld.setStepInteractions(2);



This 2 is very small number, try increasing it to e.g. 10.

What is your stepsize? Try e.g. 0.05 for starters.

You can use World.step() instead of stepFast() but it's notiecable slower and consumes more resources.

By the way, I noticed that you're calling directly some methods from Ode class. How about using these methods like this:
1  
2  
3  
4  
5  
// Set default surface parameters
           collision.setSurfaceMu(1000f);
            collision.setSurfaceBounce(0.14f);
            collision.setSurfaceBounceVel(0.1f);
            collision.setSurfaceMode(Ode.dContactBounce | Ode.dContactApprox1);

See e.g. org.odejava.test.car.CarTerrain.java example.

Quote

Should I be doing something with the contact collisions?


It is not required to read/write contact information, you can use them if you wish but it is not mandatory.

One other thing. Odejava is still missing auto disable / enable feature. I've done it a month ago about but haven't committed it to the CVS yet. This also helps things to "calm" down for objects that have small angular or linear velocity. All objects that are moving very little are automatically disabled, note that all disabled objects will be automatically enabled if they come in contact with any enabled object. This speeds up complex simulations and adds moer realism on certain places. Auto disable/enabling has some issues but it's a nice feature anyway. Have to commit it..

If you still have problems or questions, shoot them out..

Cheers, Jani!
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #2 - Posted 2004-03-25 20:30:08 »

Maybe you can't use the docs directly - but it's still fairly intuitive I think at least from a setting attribute point of view.

Guess what?  I have some time today *shock*.  I'm going to begin my Odejava/Xith3D guide.

Cheers,

Will.

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

Senior Newbie




Trying to understand


« Reply #3 - Posted 2004-03-25 22:00:11 »

Jani,

Thanks for the info. I hadn't explored the JavaCollision class; I just grabbed it's use from one of the simple tests.

My step size is based on the frame rate, so it's typically around 0.0125 (and I believe small is good?), but is set on a per frame basis.

I bumped the interactions up to 10 (I don't understand exactly what this number implies, or how it relates to anything in the simulation), and I set the collision defaults as you posted, but the simulation is even worse. When the box initially falls, it hits the terrain and bounces uncontrollably into the air.

I added a bunch of leading zeros in to the collision's bounce and bounceVel settings (hoping to imply less bounce?) and it's just as bad.

That surfaceMu of 1000 seems very high to me, but what do I know? The ODE docs talk about Mu and the two modes ODE can use with it, but it's not clear how you set either mode. Is that one of the bit values you set in the surfaceMode property? If so, how do I know which mode I'm selecting (there's nothing in the docs for odejava or ODE)?

I'm pulling my hair out with this. I wouldn't think it's this hard to get something that resembles reality. Isn't there some set of recommended nominal values for all these things that result in something useful?

-Tab
Offline Jani Laakso

Junior Member




Do it with Java!


« Reply #4 - Posted 2004-03-26 03:45:41 »

Quote

My step size is based on the frame rate, so it's typically around 0.0125 (and I believe small is good?), but is set on a per frame basis.


Your stepsize sounds small. The smaller, the better simulation but slower.

How big triangles are you using on your terrain? If your triangles are a lot smaller than e.g. the box colliding into it, then the box can tend to fall through the whole terrain. Generally speaking, you can use large triangles on a terrain but small triangles can be problematic, size related to all other objects of course.

Does the org.odejava.test.simple.TriMesh demo on Odejava work for you properly? You can test it by running org.odejava.xith3d.test.TriMeshExample (needs Xith), or you can convert it to Java3D by copying the relevant lines from org.odejava.test.simple.TriMesh (just the TriMesh geom part). You can test the CarTerrain demo aswell, it's bigger demo than plain TriMesh.

I assume your triangle index is defined clockwise, if it's in other way then your collisions wouldn't work at all. How are you importing your terrain to Odejava, are you using e.g. ASE export from MAX?

Quote

I bumped the interactions up to 10 (I don't understand exactly what this number implies, or how it relates to anything in the simulation), and I set the collision defaults as you posted, but the simulation is even worse.


This problem sounds pretty wierd.. If you raise interactions, you will get better simulation for sure.

ODE 0.39 should be pretty stable both in linux and windows, but e.g. the collision part of code (OPCODE for trimeshes) acts a bit differently beetween different platforms.

I do not know when new version of ODE is coming out, but I feel that we should not go to ODE CVS head at this point, ODE's own CVS head is under development and sometimes broken.

Are you using linux or windows version?

If you want, send your project to me by zip/tgz package and I can test it on my own development machine.

Quote

I added a bunch of leading zeros in to the collision's bounce and bounceVel settings (hoping to imply less bounce?) and it's just as bad.


The default values should be ok for your simulation (simple box colliding with terrain). I've simulated hundreds of objects (boxes, spheres) with a large terrain, it works quite well but it has it's issues.

Quote

That surfaceMu of 1000 seems very high to me, but what do I know? The ODE docs talk about Mu and the two modes ODE can use with it, but it's not clear how you set either mode.


There's Collision.setMode(), look previous email that set's it. See ODE's own documentation for various modes that can be used.

Quote

Is that one of the bit values you set in the surfaceMode property? If so, how do I know which mode I'm selecting (there's nothing in the docs for odejava or ODE)?


Check ODE's own documentation, section "7.3.7. Contact". All modes are listed here.
Here's the URL:
http://opende.sourceforge.net/ode-0.039-userguide.html#ref53

Quote

I'm pulling my hair out with this. I wouldn't think it's this hard to get something that resembles reality. Isn't there some set of recommended nominal values for all these things that result in something useful?


As I said, you can send your testcase to me, I can check it out.

Default values act pretty ok for me for simpler simulation sets. You need to tamper with surface parameters when you need that something extra, like real looking driving on a car.
Offline frdfsnlght

Senior Newbie




Trying to understand


« Reply #5 - Posted 2004-03-26 12:22:27 »

Jani,

First of all, I really appreciate your help with this.

I don't import my terrain, but rather generate it during app startup. I'm sure the triangles are created in correct vertex order, because I do get collisions, they just seem to be out of control.

My traingles are 4 units on a side, and the box is 2 units square (xz) and 0.5 units high (y). The terrain is laid out in the xz plane in a regular grid and it's height points (y) are based on a height map.

I'm running all this on Windows XP Pro.

I haven't tried any of the non-console tests since I don't have Xith installed. Maybe I can try those out today.

I'll take another poke at my code today and take a look at the ODE docs again (a good night's sleep sometimes helps). If I still can't get satisfactory behavior, I'll try to get the code in some shape for you look at. My code uses Java3D and the j3d library. Would any of that be a problem for you?

-Tab
Offline Jani Laakso

Junior Member




Do it with Java!


« Reply #6 - Posted 2004-03-27 05:28:00 »

Quote

I'll take another poke at my code today and take a look at the ODE docs again (a good night's sleep sometimes helps). If I still can't get satisfactory behavior, I'll try to get the code in some shape for you look at. My code uses Java3D and the j3d library. Would any of that be a problem for you?


Your setup sounds good, it should act very reasonable. I have a hunch that there's something wierd in the terrain generation part of your code but this is all that I can come up for now..

I think it's easiest if you send a working project to me as a zip package straight to my email account. I also use mostly Windows XP on my work and freetime projects.

Java3D is not a problem, I have done some simple projects with it.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #7 - Posted 2004-03-27 21:24:12 »

I believe there are some current issues with collissions between the box geometry and TriMesh.

My generated terrain also has issues (only with boxes - not spheres) and so does the CarTerrainExample by Jani which is a loaded terrain.

I am using Odejava in Linux.

Will.

Offline frdfsnlght

Senior Newbie




Trying to understand


« Reply #8 - Posted 2004-03-27 22:23:34 »

Will, that might explain some of the behavior I'm seeing.

I'm working on reducing the complecity of my simulation in an attempt to better understand some of the settings, but I'm running into some fundamental questions (that I seemed to have made assumptions about in my original testing, which may be causing me my headaches).

My main problem at the moment: what's the correct way to position/orient multiple geoms with respect to each other and the body's reference point, in the same body? Specifically, I want a box with 4 spheres, 1 at each of the "bottom" corners of the box. I've been doing that like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
body = new Body(world);
Geom g;

g = new GeomBox(WIDTH, HEIGHT, DEPTH);
g.setPosition(0, 0, 0); // I suppose this isn't really necessary
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(-HALFWIDTH, -(RADIUS + HALFHEIGHT), -HALFDEPTH);
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(HALFWIDTH, -(RADIUS + HALFHEIGHT), -HALFDEPTH);
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(-HALFWIDTH, -(RADIUS + HALFHEIGHT), HALFDEPTH);
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(HALFWIDTH, -(RADIUS + HALFHEIGHT), HALFDEPTH);
body.addGeom(g);


Is that the correct way to do it? The ODE docs talk about adding the extra geoms under a transform (sort of like a scene-graph maybe?), but there's no transform object that I can find.

And as long as I'm asking questions, here's some more:

1) The ODE docs talk about the ability to have nested spaces to optomize collision detection. That seems like it might be useful, especially when using a large TriMesh for terrain. In a similar fashion, my Java3D terrain scene-graph uses a hierchical structure (with some 1024 Shape3D leafs) to achieve better rendering speed. Does odejava support nested Spaces?

2) The ODE docs say:

Quote
Triangle meshes can interact with spheres, boxes and rays.


This implies you can't collide a TriMesh with a TriMesh. Is that really true? That could be a huge problem.

3) I don't get the idea of setting my body's mass to 1. Why can't I set it to the "real" mass of the body (e.g., 2000 kg). I tried, and bad things happened. Doesn't this mean all my bodies will have the same mass? Doesn't this screw up collisions? Mass is directly related to inertia, so how can ODE accurately model the reactions when bodies collide, if all the bodies have the same mass (when they're not supposed to)?

Those are the questions bugging me right now. Unless my understanding of physics or how ODE works is completely wrong, I'm beginning to think ODE may not be a suitable basis for modeling physics. But I'm willing to be enlightened.

-Tab
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #9 - Posted 2004-03-28 03:46:48 »

TriMesh - TriMesh collision isn't supported by ODE yet (at least not in the official release).  I think I remember some discussions about it (but that may have been another API).

Are you sure you can't work around this issue?  Even if it had that support it may be rather slow.  Personally, I am appoximating my vehicles with box geom.

Multi-geom per Body support is only just now being added to Odejava.  Some of my recent changes made this more possible - but there are still a few more to be made before it is more usable.

Just to make sure you are up to date: are you using Odejava from CVS (and have run cvs update recently) and does your project compile with no deprecated warnings?  Hopefully you can answer yes to both.

Will.

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

Junior Member




Do it with Java!


« Reply #10 - Posted 2004-03-28 05:25:24 »

Quote
I believe there are some current issues with collissions between the box geometry and TriMesh.

My generated terrain also has issues (only with boxes - not spheres) and so does the CarTerrainExample by Jani which is a loaded terrain.


I do not have any issues with TriMesh + other objects, they work fine.

But I haven't updated to latest CVS (Williams changes). I'll try to snatch some time and check what's the problem.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #11 - Posted 2004-03-29 00:52:57 »

I do not believe any of my changes could have affected the collision mechanism - but it's worth looking at I guess.

I have now made an Issue on this bug so we can track it publicly.

https://odejava.dev.java.net/issues/show_bug.cgi?id=1

Complete with a test case and screen shot.

Will.

Offline frdfsnlght

Senior Newbie




Trying to understand


« Reply #12 - Posted 2004-03-29 15:43:41 »

I can work around trimesh/trimesh collisions for now, but it could be a big issue later on. It seems that having a method to take a soup of triangles and convert it into a bunch of boxes would be a good thing for this purpose. That might sidestep the problem, but it depends on...

Multi geom per body: are there plans to get this done? I mean, are there some tricky issues, or is it just a matter of having enough time to code it?

It's good to hear I'm not the only one having box/trimesh problems. I may be able to keep my sanity.

I did some reading on the ODE mailing list archives and discovered that ODE doesn't handle dynamic friction, which I assumed it did. I found the methods for inducing drag and that may help some of my problems too.

I won't be able to test anything for a liitle while though. It seems it's time to reformat my drive and reinstall Windows so I can reliably use my network again. Long, painful story.

BTW, I'm using a version of odejava from CVS about 7 days old now. When my dev box is back up, I'll update and recompile to make sure I have the latest stuff.

-Tab
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #13 - Posted 2004-03-29 20:49:43 »

please keep your sanity - I know it's often hard with young API's as you don't know where the fault lies Smiley  For this problem we really have no clue.  I'd appreciate it if you could run my test case (issue #1) though.

I am coding the multi-geom support and it is just a matter of time.

Tell me what do _you_ need for your multi-geom support?  Bascially some way of constructing a Geom which is relitive to a second geom is that correct?

Will.


Offline frdfsnlght

Senior Newbie




Trying to understand


« Reply #14 - Posted 2004-03-30 01:38:01 »

Yes. I basically need the ability to create multiple geoms, each with its own transform to specify its position/orientation with respect to the body's reference point.

I suppose ideally, if you could create a scene-graph like tree with nested transform groups and geoms, that would great. But I'd understand if that's beyond the scope of your implementation. And I don't have have a need for that complexity (at least not yet  Smiley ).

My poor dev box is taking a bit more time than expected to come back. When it does, I'll give your issue test a try.

Oh, as I'm rebuilding my box, I've remembered I've been running Java 1.4.1_01. I'll be installing 1.4.2 on the new box. I'm not sure if that makes a difference in any of this, but I'd thought I'd throw it out there.

-Tab
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #15 - Posted 2004-03-30 09:45:04 »

1.4.2 is the minimum requirement for JOGL - this could be why your textures are strange.

Will.

Offline frdfsnlght

Senior Newbie




Trying to understand


« Reply #16 - Posted 2004-03-30 13:32:27 »

But I don't use JOGL. I'm been using Java3D for DirectX exclusively. But I'll probably need JOGL for your test.

-Tab
Offline frdfsnlght

Senior Newbie




Trying to understand


« Reply #17 - Posted 2004-03-31 16:31:01 »

Will,

I'm back up and running now. I download and installed xith and got your car terrain test working. I don't see any box/trimesh issues at all, especially the one in your issue. Again, for reference, I'm on Windows XP Pro, SP1+, Java 1.4.2_04, latest odejava source from CVS as of the time of this post (actually about 30 minutes before). I was using Xith3D from the 2004-02-29_cvs snapshot.

As it relates to my project, the car terrain test is amazing. My code behaves nothing like that test, leading me to believe I'm doing something significantly wrong. I'll have a close look at the test code and see if I can get better behavior.

-Tab
Offline frdfsnlght

Senior Newbie




Trying to understand


« Reply #18 - Posted 2004-03-31 18:47:11 »

I'm still stuck. Here's some code you can try:

http://www.bennedum.org/files/ODETest.zip

It includes a simple ant script, a single source file, and a batch file to run the test. Run ant with no arguments to build the test. The build script assumes a "lib" directory at the same level as the entire archive file. It assumes Java3D is installed into the Java SDK.

When you run the test, it will open a 1024x768 frame with a simple scene. The "terrain" is a single triangle (GeomPlane for odejava. The "traveler" (the thing you can control) is a simple box (GeomBox). The controls are:

Escape - quits
Up arrow - forward
Down arrow - reverse
Left arrow - turn left
Right arrow - turn right
V - change view (above and behind, left side, 1st person)

I'd like you to observe the behavior without touching the controls. For me, the box falls to the "ground", then bounces much more than I'd expect. If you let it run, within a few seconds, the box will out of control, spinning wildly.

What I want is: the box should fall to the ground, bounce a little and settle down.

Any idea what I'm doing wrong here? Is this behavior "normal" and I'm just expecting too much? I can't seem to tweak things to get decent behavior.

-Tab
Offline Jani Laakso

Junior Member




Do it with Java!


« Reply #19 - Posted 2004-04-01 01:27:04 »

Quote
I'm still stuck. Here's some code you can try:

http://www.bennedum.org/files/ODETest.zip



I download it and try to check it tomorrow (friday evening).
Offline frdfsnlght

Senior Newbie




Trying to understand


« Reply #20 - Posted 2004-04-05 20:11:02 »

Jani, any luck with my code?

I asked this before, but I never got an answer. Why does ODE want masses to be specified in such a narrow range (e.g., 0.5 to 1.5)? Isn't this unrealistic? How am I supposed to model the interactions between a North African swallow and and an M1 tank (for instance)? If I could specify the correct masses, I would expect the bird to bounce off the tank without the tank moving (perceptively). Or am I missing something?

-Tab
Offline Jani Laakso

Junior Member




Do it with Java!


« Reply #21 - Posted 2004-04-06 06:27:08 »

Quote
Jani, any luck with my code?


Sorry, I got extremely busy schedule on my work and didn't got time to check your code this weekend Sad I really try to check it out this weekend.

Quote

I asked this before, but I never got an answer. Why does ODE want masses to be specified in such a narrow range (e.g., 0.5 to 1.5)? Isn't this unrealistic?


The masses are not based on any real world units like kilograms or such.

See:
http://opende.sourceforge.net/ode-latest-userguide.html#ref110
And especially:
http://hook.org/pipermail/ode/

The mailing list is full of ideas and explanations of various things that haven't got into the ODE documentation yet.

I've seen mails that propose using some kind of formula (square based) for calculating masses for very big objects (truck) and small objects (human). All in all, the mass does not seem to act in linear way. Tweaking mass for a tank and lighter objects like humans should not be too big of a problem.

Offline frdfsnlght

Senior Newbie




Trying to understand


« Reply #22 - Posted 2004-04-06 15:35:48 »

So basically, it's all relative. With a possibly non-linear relationship between any 2 masses.

That's kind of what I figured, just not what I hoped. Oh well, more tweaking.

-Tab
Offline Fuseboy

Junior Newbie




Java games rock!


« Reply #23 - Posted 2004-04-15 01:49:43 »

This thread is a little bit disturbing!  ODE documentation (at least for ODE 0.039) implies that trimesh collision works, but I'm experiencing some odd things.  My small trimesh falls straight through an ODE box, a sphere, and a plane, which is a little weird.

What version of ODE is incorporated into odejava?  Is it one with the "old" collision code, which apparently doesn't support TriMesh?
Offline Jani Laakso

Junior Member




Do it with Java!


« Reply #24 - Posted 2004-04-19 15:32:29 »

Quote
This thread is a little bit disturbing!  ODE documentation (at least for ODE 0.039) implies that trimesh collision works, but I'm experiencing some odd things.  My small trimesh falls straight through an ODE box, a sphere, and a plane, which is a little weird.


Stationary TriMesh is supported, not moving TriMesh objects.

Does the CarTerrain test work for you? It has a big TriMesh terrain on it, one car and several boxes + spheres on it.

Quote

What version of ODE is incorporated into odejava?  Is it one with the "old" collision code, which apparently doesn't support TriMesh?


ODE release 0.39 which is very little tweaked (API changes only) so it compiles nicely under Swig.

Odejava has always supported TriMesh. It does not use "old" collision code, it uses OPCODE and "new" collision code.

New ODE (straight from the ODE's own CVS)  is something that I need to test before adding it to Odejava. I try to add it as "experimental" so people can use both older ODE 0.39 and newer ODE same time with Odejava.
Offline Jani Laakso

Junior Member




Do it with Java!


« Reply #25 - Posted 2004-04-19 16:20:59 »

Quote
This thread is a little bit disturbing!  ODE documentation (at least for ODE 0.039) implies that trimesh collision works, but I'm experiencing some odd things.  My small trimesh falls straight through an ODE box, a sphere, and a plane, which is a little weird.


By the way, please do another CVS update. If you are using linux, then linux native library had too high optimization level for OPCODE (this brokes TriMesh support) for a while. William committed new version couple weeks ago.
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.

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

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

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

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

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

BurntPizza (30 views)
2014-09-19 03:14:18

Dwinin (47 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
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!