I wrote a piece of code, that I would like to see in the toolkit. There're some lines of code very most Xith3D-Applications will probably have the same. So I think, it should be on the toolkit where you can use it if you want.

These classes save a lot of codelines for the xith-game-developer. It offers mechanisms to

automatically animate/rotate objects

schedule operations to be done by the render thread (like picking)

easily integrate a Canvas3D into a swing gui

create a standalone Canvas3D on a more comfortable way

manage one texture loader for each xith-universe

ease the startup of coding Xith3D

limit the FPS

An example is included.

Please tell me, if you like it or not, and what you think about it. Suggestions and the like are welcome of course.

Greetings, Qudus

Remark: The attachment actually is a zip file. Just rename it for easy extraction.

Remark: The attachment is actually is a zip file. Since I was not allowed to upload zips, i renamed it. I hope you are not angry about it. But I don't know how to distribute my code in another way and it's no evil code.

It's some kind of standart trick to upload code - so - no we're not angry (at least I'm not )

I'll look, where we can put it into the xith-tk. If you want to make more contributions, you can also ask Will to give you developer access to the xith-tk.

Remark: The attachment is actually is a zip file. Since I was not allowed to upload zips, i renamed it. I hope you are not angry about it. But I don't know how to distribute my code in another way and it's no evil code.

It's some kind of standart trick to upload code - so - no we're not angry (at least I'm not )

I'll look, where we can put it into the xith-tk. If you want to make more contributions, you can also ask Will to give you developer access to the xith-tk.

You seem to have coded your own kind of behavior system (for animations), it looks pretty good - we should see how that fits into the behavior classes, that currently exist ( => croft, could you please look at the code)

I also like it, that you've combined all those steps for setting up the universe.

About Transform3D - yes, those final methods are disturbing, if setting the Transform3d of a TransformGroup should also change other stuff (e.g. if you have Boneanimations - and the vertices are only effected by a percentage of the bones' transformation.) But on the other hand this would also be a bit dirty, because intuitively a "set" method should only change the object itself and not do other stuff.

You seem to have coded your own kind of behavior system (for animations), it looks pretty good - we should see how that fits into the behavior classes, that currently exist ( => croft, could you please look at the code)

Oh, I didn't know these insterfaces/classes. Unfortunately these interfaces are quite big and I don't need most of the methods. I've moved my animation classes into the behaviors package (in my branch), so this could be committed as is. But I think, we really should get it under one super interface. Since my Animatable interface is very basic, I think it could be some kind of super interface (maybe with a few additions/renamings).

...But on the other hand this would also be a bit dirty, because intuitively a "set" method should only change the object itself and not do other stuff.

No. One of the main reasons for the guideline to only use getters/setters and not public fields is, that you know necessary maintenance things are done with the set or get. So I don't think it's dirty, but exactly what is possible and meant to be done with the getters/setters. I don't say, that you should do expensive things with a set or get, but you could not only merge a scale into the matrix but save it in a private field to use it for later calculations.

Hey Qudus.. you did exactly the same thing as my org.xith3d.scenegraph.Scene with your environment ^^ Just that CanvasAdder and CanvasReviver thingy is intriguing.

Thanks. But I don't know and can't find this class. Is it only in CVS? Or didn't you commit this class? Maybe you have done some things more or better as I may have done with others. So we could possibly merge the features. Could you send me a copy of your class?

I just realized, that this CanvasAdder and -Revivier thingy ist unnecessary, because in any case I have to access the Canvas list on a sychronized way. So the detour over these ScheduledOperations is just a waste of time. I've changed this and uploaded a new zip.

Qudus

PS: I've changed some things in my coding and attached a new zip file to the initial posting.

You seem to have coded your own kind of behavior system (for animations), it looks pretty good - we should see how that fits into the behavior classes, that currently exist ( => croft, could you please look at the code)

Oh, I didn't know these insterfaces/classes. Unfortunately these interfaces are quite big and I don't need most of the methods. I've moved my animation classes into the behaviors package (in my branch), so this could be committed as is. But I think, we really should get it under one super interface. Since my Animatable interface is very basic, I think it could be some kind of super interface (maybe with a few additions/renamings).

Hey Qudus.. you did exactly the same thing as my org.xith3d.scenegraph.Scene with your environment ^^ Just that CanvasAdder and CanvasReviver thingy is intriguing.

Thanks. But I don't know and can't find this class. Is it only in CVS? Or didn't you commit this class? Maybe you have done some things more or better as I may have done with others. So we could possibly merge the features. Could you send me a copy of your class?

I just realized, that this CanvasAdder and -Revivier thingy ist unnecessary, because in any case I have to access the Canvas list on a sychronized way. So the detour over these ScheduledOperations is just a waste of time. I've changed this and uploaded a new zip.

It is only in CVS and will be in any release after 0.7.1. OK for the update, will take a look later

Hey Qudus.. you did exactly the same thing as my org.xith3d.scenegraph.Scene with your environment ^^ Just that CanvasAdder and CanvasReviver thingy is intriguing.

I found your class through the web CVS. I assume, this is the most resent version. Looks cool and simple to use.

I took some of the ideas from your class and adepted them into my coding (I put your name to the @author javadoc attribute.). Watch the new Canvas3DWrapper class, which should be merged into the original Canvas3D class as I think.

Some more comments :- What's wrong with Xith Behavior System ? You could make Animatable / Rotatable extends Behavior.. or just implement a RotationalBehavior- Why do you use the old picking method ? Use Arne's one : http://www.xith.org/howtos/picking.html- I just don't like this PickListener thing.. make me thing of AWT/Swing which is not the best suited for a games.. However some others may find it useful- Do you use HIAL (http://www.xith.org/articles/using_an_input_abstraction_layer.html) for your Mouse/Keyboard Listeners ? It's abstract so it's best suited for that- About the creatFullscreen() and all methods : Good ones ! It's much cleaner than my constructors for Scene- About the RenderLoop : that means you can't control rendering anymore ? You do everything through the use of Animatable objects ?

Some more comments :- What's wrong with Xith Behavior System ? You could make Animatable / Rotatable extends Behavior.. or just implement a RotationalBehavior

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.

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

- I just don't like this PickListener thing.. make me thing of AWT/Swing which is not the best suited for a games.. However some others may find it useful

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.

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.

- About the RenderLoop : that means you can't control rendering anymore ? You do everything through the use of Animatable objects ?

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:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

publicclassTestRenderLoopextendsRenderLoop{/** * 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 */protectedvoidloopIteration(longgameTime) {System.out.println("I say hello each loop iteration."); }}

Qudus

PS: I've changed some things in my coding and attached a new zip file to the initial posting.

Some more comments :- What's wrong with Xith Behavior System ? You could make Animatable / Rotatable extends Behavior.. or just implement a RotationalBehavior

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.

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

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)

- I just don't like this PickListener thing.. make me thing of AWT/Swing which is not the best suited for a games.. However some others may find it useful

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.

OK, fair.My approach is to return a Vector<PickResult> 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.

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.

- About the RenderLoop : that means you can't control rendering anymore ? You do everything through the use of Animatable objects ?

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:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

publicclassTestRenderLoopextendsRenderLoop{/** * 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 */protectedvoidloopIteration(longgameTime) {System.out.println("I say hello each loop iteration."); }}

OK, fair.My approach is to return a Vector<PickResult> or to provide getter to the PickResult instead of having eventDispatched()-like methods. But it's just as well.

But isn't it correct that picking must be done by the rendering thread? So you would have to implement some kind of callback system.

Yes indeed, but I do have just a single thread for everything (excepted the AWT-event thread, which I double-buffer for convenience : I call a swap() method each rendering step).See my AWT EventBuffer class :

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