Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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  
  Xith3D Toolkit addition  (Read 2593 times)
0 Members and 1 Guest are viewing this topic.
Offline Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Posted 2006-06-07 23:55:32 »

hi

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.
Offline arne

Senior Duke




money is the worst drug- we should not let it rule


« Reply #1 - Posted 2006-06-08 12:31:38 »

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 Wink )

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.

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Duke




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


« Reply #2 - Posted 2006-06-08 13:48:33 »

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 Wink )

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.
I'd be very interested if you continued to go toward this goal.. I myself thought about it and committed several classes to the TK to improves usability. (see also : http://www.java-gaming.org/forums/index.php?topic=13977.0)

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.
William gives *pretty easily* Dev access to the tk... For the core, it's another deal

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline arne

Senior Duke




money is the worst drug- we should not let it rule


« Reply #3 - Posted 2006-06-08 14:01:38 »

So - I've looked at the code. It looks good and very useful.

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.

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Duke




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


« Reply #4 - Posted 2006-06-08 14:07:51 »

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.

"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 Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #5 - Posted 2006-06-08 19:08:12 »

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

Wouldn't it make sense to additionally allow .zip/.tar.gz/.tar.bz2/.jar files to be uploaded? Whom could I ask to change that?

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.

I've just sent a PM to Will.
How does this developer access look like? I assume, it is CVS. Never done that before. I think, I can easily integrate this into eclipse, can I?

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.
Offline Amos Wenger

Senior Duke




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


« Reply #6 - Posted 2006-06-09 11:18:43 »

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

Wouldn't it make sense to additionally allow .zip/.tar.gz/.tar.bz2/.jar files to be uploaded? Whom could I ask to change that?
Ask to ChrisM

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.

I've just sent a PM to Will.
How does this developer access look like? I assume, it is CVS. Never done that before. I think, I can easily integrate this into eclipse, can I?
CVS, and very straight-forward to use from Eclipse.
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).
Maybe.
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

"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 Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #7 - Posted 2006-06-09 20:58:38 »

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.

I tied up a new zip package and uploaded it to the initial posting.
Offline Amos Wenger

Senior Duke




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


« Reply #8 - Posted 2006-06-10 10:03:04 »

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 ?

Good work !

"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 Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #9 - Posted 2006-06-11 00:35:12 »

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.

- Why do you use the old picking method ? Use Arne's one : http://www.xith.org/howtos/picking.html

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.

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

- 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

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 creatFullscreen() and all methods : Good ones ! It's much cleaner than my constructors for Scene

Thanks.

- 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  
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.");
    }
}


Qudus

PS: I've changed some things in my coding and attached a new zip file to the initial posting.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Duke




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


« Reply #10 - Posted 2006-06-12 14:24:33 »

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)
- Why do you use the old picking method ? Use Arne's one : http://www.xith.org/howtos/picking.html

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

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  
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.");
    }
}

OK, fair  Smiley

"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 Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #11 - Posted 2006-06-12 15:37:07 »

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.

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.

hmm. OK.


I Just changed a few things in my coding. Watch the changes:
  • splitted the RenderLoop class into two classes having one very basic and one extended with all these scheduler things and listeners.
  • Eliminated some of the synchronized blocks
  • added two more examples
Offline Amos Wenger

Senior Duke




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


« Reply #12 - Posted 2006-06-12 16:22:32 »

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 :
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
package org.oem;

import java.awt.AWTEvent;
import java.awt.Toolkit;
import java.awt.event.AWTEventListener;
import java.util.LinkedList;

public class EventBuffer implements AWTEventListener {

   public LinkedList<AWTEvent> events = new LinkedList<AWTEvent>();

   private LinkedList<AWTEvent> buffer = new LinkedList<AWTEvent>();

   public EventBuffer(long flags) {

      Toolkit.getDefaultToolkit().addAWTEventListener(this, flags);

   }

   public void finalize() {

      Toolkit.getDefaultToolkit().removeAWTEventListener(this);

   }

   public void eventDispatched(AWTEvent event) {

      buffer.add(event);

   }

   public synchronized void swap() {

      synchronized (buffer) {
         synchronized (events) {
            if (!buffer.isEmpty()) {
               events = new LinkedList<AWTEvent>(buffer);
               buffer.clear();
            } else {
               events.clear();
            }
         }
      }

   }

}

"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 Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #13 - Posted 2006-06-12 16:56:27 »

But what do you do, when the picking is to be done? Your code doesn't tell anything about it.
Offline Amos Wenger

Senior Duke




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


« Reply #14 - Posted 2006-06-13 11:51:30 »

But what do you do, when the picking is to be done? Your code doesn't tell anything about it.
Oh sure that's just for AWT events (the code).

For picking, I just call a method : doPicking() then I have access to a Vector<PickResult>

"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 Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #15 - Posted 2006-06-17 15:16:51 »

I just committed my work to the CVS-project.

Synchronize and enjoy. Wink
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.

Longarmx (38 views)
2014-10-17 03:59:02

Norakomi (29 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (28 views)
2014-10-15 16:18:58

TehJavaDev (56 views)
2014-10-14 00:39:48

TehJavaDev (55 views)
2014-10-14 00:35:47

TehJavaDev (46 views)
2014-10-14 00:32:37

BurntPizza (64 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (78 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!