Yes, I could. But there are that many methods to implement with the Behavior Interface, that I just don’t need. See my Animatable interface. It has only 4 methods to come around with. This makes it much easier for the coder to use it.
And in the Behavior interface there is no method like my animate(long gameTime), that is hardly needed by interpolated animations.
So I think, my Animatable interface definitly has a right to exist in the behaviors package.
I changed the Animatable interface so that it extends scheduledOperation. That way I safe one synchronized inner loop in the RenderLoop. I think it’s good. Had to fight with a deadly deadlock. But solved it. Now it looks fine.
[/quote]
OK. Just wanted to make sure it’s not code duplication (and effort fragmentation)
Hmm… I didn’t know that one. I got the picking howto from the “Getting started guide”. Have a look here: http://xith.org/tutes/GettingStarted/html/picking.html
But I switched to the new picking system. Seems to be much more efficient. But since I use the org.xith3d.geometry.Quad class in my current game and want to pick it, I had to extend the PickingLibrary class to make it able to pick Quads. I also extended the PickResult class and gave it a public getShape() method.
I’ll contribute these two changes to CVS when I have access.
[/quote]
About the GSG, it’s pretty out-of-date and in the process of being replaced by something new… (I won’t delete the GSG but I think it will fall in non-use by default)
Picking is done by the rendering thread (RenderLoop in my case). So you need some kind of callback to notify the picking requester. This listener is not implemented like in AWT/Swing. The picking code doesn’t iterate over a list of listeners, but only calls the callback method of the listener when picking is done.
So I think, since such a mechanism is necessary in some way, this is a somewhat convenient way. And it is good for games, too. Why not?
This kind of picking system is not obligatory with my system. So if someone doesn’t like it, just don’t use it and use your own coding in the loopIteration method. I think this is fair and free.
[/quote]
OK, fair.
My approach is to return a Vector or to provide getter to the PickResult instead of having eventDispatched()-like methods. But it’s just as well.
I don’t use any imput system in my current state. But this one looks good. It isn’t part of the Xith3D branch, is it? So I don’t think it makes sense to integrate it into my classes. But it will be easy to use it with them.
[/quote]
It makes perfect sense to integrate it into your classes since it’s included by default with Xith3D. It’s being developed separately by WillDenniss but I’m sure he’s/I’m willing to keep it up-to-date.
nope. There’re methods to override exaclty for that purpose. There’s one method named “loopIteration” which is exactly for that what you mean. When you want to do picking differently, just use this method in an extension of RenderLoop. I just changed this method and made it empty in the “RenderLoop base”.
Watch that one:
public class TestRenderLoop extends RenderLoop
{
/**
* This method is called each loop iteration.
* It does nothing.
* Override this method if you want something to be done each iteration.
*
* @param gameTime the current game time
*/
protected void loopIteration(long gameTime)
{
System.out.println("I say hello each loop iteration.");
}
}
[/quote]
OK, fair 
)