Xith3D and JOODE

Game Mechanics
#1

hi, Guys

I’m coming from the Xith3D project trying to understand, how JOODE works.

As you may have been told by Amos Wenger we’re brainstorming, how we can create an abstraction layer for JOODE, which can be included into xith as a JAR without being forced to import the whole JOODE jar.
This has some advantages:

  • The abstraction layer can be cept at a minimum and could only consist of interfaces. This way, we don’t need to worry about JOODE changes and vice versa.
  • We don’t need to ship JOODE JAR if it is not needed. If someone just wants to use Xith, he just doesn’t need to also carry joode with his game
  • We can provide some convenience things directly in your engine to support JOODE usage.

Well, browsing the JOODE examples some things caught my eye:

  • You’re stll using “net.java.dev.joode.” package prefixes. Could you maybe change that to something like “org.joode.”, since it may be disturbing, while you don’t reside on dev.java.net anymore. Even if you don’t have joode.org as your homepage “org.joode.” may be the perfect package naming. We have recently changed package names from “com.xith3d.” to “org.xith3d.”. The change on user’s side is damn simple. So no reason to worry about it.
  • You seem to use an older version of xith. If you switch to the current version, you’ll have a lot of advantages. There’s a handy tool named org.xith3d.utility.canvas.DisplayOptions. This is a startable Swing Frame, that will let you choose the resolution, OpenGLLayer, and Fullscreen-flag. It is meant to be subclassed, which is done by org.xith3d.test.Xith3DTestLauncher. I invite you to port the latter one to your environment. This way you have one start script (doesn’t flood Eclipse with starting configs) and you’re not forced to a resolution of fullscreen-flag.
  • We have something similar to, but very much more powerful than your XithView class in the current version of Xith. It is called Xith3DEnvironment. It contains everything needed for a xith app except canvas creation and render loop. This is done in a very convenient one-line-way by Canvas3DWrapper. And the render loop is handled by a class RenderLoop or ExtRenderLoop, if you want even more features. If you used these classes, you would draw a lot of code out of your project, that doesn’t belong to there.
  • Do you know our Xith3D in a Nutshell (XIN)? Everybody who read it, found it very informative and a good starting point to learn Xith from zero. Could you maybe write something like that for JOODE? I know, it is not done in a second. But it will certainly atttract several new users (it did for xith). And I would really like to understand, how JOODE works, which is quite hard to achive with only the test classes, which are quite wide spread.
  • A very basic test class for the beginning would be great to have. It should contain everything necessary so it shouldn’t be necessary to browse though 10 classes until you’ve seen everything do be done by the user.

What do you think?

Marvin

#2

@Users (if any) : it is a problem for you ? If not, I’ll rename everything soon.

#3

I have built a JOODE binding for jME Physics 2 (only implementation was ODE(Java) previously). Works fine, yay :smiley:

jME Physics 2 also uses a simple method to avoid compile dependency to the implementations. If you still need inspiration have a look at PhysicsSpace.create()…

If I’m considered a JOODE-User :P: I have no objections :slight_smile:

#4

Thanks for the hint. Amos will certainly have a look at it. Even if he told me a few hours ago, that he is almost done.

Thanks.

#5

irrisor, thanks for the hint, Xith3D Physics Abstraction Layer has an “experimental design” somehow… it is subject to change, and probably not the best… :slight_smile: So I’m always open-ears on that kind of things… I’ll have a look at jme-physics SVN… :slight_smile: