Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (482)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
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  
  A Few Issues  (Read 2392 times)
0 Members and 1 Guest are viewing this topic.
Offline kevglass

JGO Kernel


Medals: 153
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Posted 2006-06-05 03:35:25 »

The MD2 post made me attempt to setup a Xith3D build environment to try stuff out. Some problems came up while I was doing this:

- Though the source is 1.4 compatible the build thats available has been built using 1.5 source compatibility. Unfortunately this means I can't use it against a 1.4 VM out of the box (since you get a class version in compatibilty) - just an irritation - have to rebuild everything Sad

- I wanted to use the JOGL based renderer - however the JSR 231 jogl libraries arn't included in the dependencies bundle from the website.

- I then tried to use the LWJGL renderer which simply failed on the first render loop with:

1  
2  
3  
4  
5  
6  
7  
8  
9  
java.lang.NullPointerException
   at org.lwjgl.opengl.GL11.glGetInteger(GL11.java:1799)
   at com.xith3d.render.lwjgl.CanvasPeerImpl.renderStart(CanvasPeerImpl.java:285)
   at com.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:868)
   at com.xith3d.render.lwjgl.CanvasPeerImpl.render(CanvasPeerImpl.java:1035)
   at com.xith3d.scenegraph.View.renderOnce(View.java:616)
   at com.xith3d.scenegraph.View.renderOnce(View.java:549)
   at MD2Test.run(MD2Test.java:144)
   at java.lang.Thread.run(Thread.java:595)


Which I believe means the display isn't created when you're attempting to make GL11 calls.

- The userinterface package seems to be broken (or its changed significantly since the MD2Test was written, entirely possible). However, I got no compile errors, everything looked fine. Only failed when calling setComponent(). If its not supported it any more I guess the examples using it should be removed?

Is Xith using an issue tracker that I can log these things in outside of that evil java.net thing?

Incidently, up and running now with fresh downloads of the JOGL libs. Refreshing to find the model loads happily and displayed exactly as I remember it Smiley Oh, Marvin the Martian, how I love you Smiley

Kev

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #1 - Posted 2006-06-05 11:50:36 »

Smiley Oh, Marvin the Martian, how I love you Smiley

  Cheesy

Offline Amos Wenger

Senior Member




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


« Reply #2 - Posted 2006-06-05 11:53:26 »

- Though the source is 1.4 compatible the build thats available has been built using 1.5 source compatibility. Unfortunately this means I can't use it against a 1.4 VM out of the box (since you get a class version in compatibilty) - just an irritation - have to rebuild everything Sad
Sorry about that, we decided switching to 1.5 some time ago and even if the core doesn't use any 1.5 feature the toolkit does (Arne's picking code use generics)

- I wanted to use the JOGL based renderer - however the JSR 231 jogl libraries arn't included in the dependencies bundle from the website.
I thought I fixed that in 0.7.1... are you sure you have it ? 0.7.0 didn't include them, was my fault. (In 0.7.1 these are in the jogl directory, it's not called jsr231 or whatever).

- I then tried to use the LWJGL renderer which simply failed on the first render loop with:

1  
2  
3  
4  
5  
6  
7  
8  
9  
java.lang.NullPointerException
   at org.lwjgl.opengl.GL11.glGetInteger(GL11.java:1799)
   at com.xith3d.render.lwjgl.CanvasPeerImpl.renderStart(CanvasPeerImpl.java:285)
   at com.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:868)
   at com.xith3d.render.lwjgl.CanvasPeerImpl.render(CanvasPeerImpl.java:1035)
   at com.xith3d.scenegraph.View.renderOnce(View.java:616)
   at com.xith3d.scenegraph.View.renderOnce(View.java:549)
   at MD2Test.run(MD2Test.java:144)
   at java.lang.Thread.run(Thread.java:595)

Which I believe means the display isn't created when you're attempting to make GL11 calls.
I don't know if the LWJGL renderer is still supported..

- The userinterface package seems to be broken (or its changed significantly since the MD2Test was written, entirely possible). However, I got no compile errors, everything looked fine. Only failed when calling setComponent(). If its not supported it any more I guess the examples using it should be removed?
The Swing UI package still works, I use it successfully. By "failed" you mean it throw an exception ? Here's the code I use :
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  
48  
49  
50  
      // Window manager
     windowMgr = new UIWindowManager(graphic.getCanvas());
      UIEventAdapter eventAdapter = new UIEventAdapter(windowMgr);
      graphic.getCanvas().get3DPeer().getComponent().addKeyListener(eventAdapter);
      graphic.getCanvas().get3DPeer().getComponent().addMouseListener(eventAdapter);
      graphic.getCanvas().get3DPeer().getComponent().addMouseMotionListener(
            eventAdapter);
      graphic.getCanvas().get3DPeer().getComponent().setFocusable(true);
      graphic.getLocale().addBranchGraph(windowMgr);

      // Creates a new UIPanel
     UIPanel uiPanel = new UIPanel();

      // create a double buffered JPanel
     panel = new JPanel(true);
      panel.setLayout(new GridLayout(1, 0));
      panel.setSize(new Dimension(width, height));
      panel.setOpaque(false);
     
      // title
     JLabel titleLabel = new JLabel("Stratagem");
      titleLabel.setForeground(Color.WHITE);
      panel.add(titleLabel);
     
      // FPS
     FPSlabel = new JLabel("FPS = ");
      FPSlabel.setForeground(Color.WHITE);
      panel.add(FPSlabel);
     
      // include the exit button if it's wanted
     if (includeExitButton) {
         JButton exitButton = new JButton();
         exitButton.setText("Capituler");
         exitButton.addActionListener(new ActionListener() {
            public void actionPerformed(ActionEvent e) {
               System.exit(0);
            }
         });
         panel.add(exitButton);
      }

      // specify the root component of the UI window
     uiPanel.setRoot(panel);

      // in the main loop
     while(true) {
            // ...
           windowMgr.newFrame(scene.getView().getTransform());
            // ...
     }


Is Xith using an issue tracker that I can log these things in outside of that evil java.net thing?
I'm afraid there's not.. However if there is a cool Joomla! module for Issue Tracking I'll set it up happily.

Incidently, up and running now with fresh downloads of the JOGL libs. Refreshing to find the model loads happily and displayed exactly as I remember it Smiley Oh, Marvin the Martian, how I love you Smiley
Hmm.. I spent some time fixing path issues in the OBJ/3DS/MD2 loaders.. at least it works now  Cheesy (there had some problems with absolute/relative path, "\" or "/" separators, loading from jars, classpath and all these tricks..).

"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 kevglass

JGO Kernel


Medals: 153
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2006-06-05 15:02:21 »

Quote
I thought I fixed that in 0.7.1... are you sure you have it ? 0.7.0 didn't include them, was my fault. (In 0.7.1 these are in the jogl directory, it's not called jsr231 or whatever).

http://xith.org/download/third-party/jogl/jogl.jar isn't JSR 231. Nor is the one in the package of dependencies.

If the LWJGLRenderer is no longer supported - remove it. If it is intended to be and it doesn't work then it needs to be noted somewhere - and possible removed from the formal builds until it does? (leave it in the nightly builds)

Quote
I'm afraid there's not.. However if there is a cool Joomla! module for Issue Tracking I'll set it up happily.

Does that mean nothing outside of java.net ? Or nothing at all?

Quote
Hmm.. I spent some time fixing path issues in the OBJ/3DS/MD2 loaders.. at least it works now  Cheesy (there had some problems with absolute/relative path, "\" or "/" separators, loading from jars, classpath and all these tricks..).

As far as I'm aware the loaders have always simply read from input streams. If someone added a layer wrapping that with an incorrect file handling - meh. The point is the MD2Test.java that I downloaded from the newdawn site needed:

1) The package names changing
2) The rendering peer changing
3) The UI stuff removing

And then ... it just worked .... which is a lovely state to be in Smiley

Kev

Offline kevglass

JGO Kernel


Medals: 153
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #4 - Posted 2006-06-05 15:23:01 »

<shitty post incoming>

Oh, one other thing - as I come to do proper changes for this loader thing - I'm looking at this file:

http://xith.org/showsrc.php?src=src/org/xith3d/loaders/md2/MD2Loader2.java

What sort of an abomination of a source format is that? Never since I worked with C++ military applications have I seen something that makes it so hard to read and maintain code.

The code appears to be just cut and pastes of things within the original MD2Loader but refactored into the loading interface - which of course makes sense. However, my eyes go funny just trying to read it - wheres the javadoc? Whats the point of all these imposed lines of slahes? Wheres in the inline doc? Wheres the param tags, return tags etc? Why is it all tabbed in one space? Why is it formatted to a 80 character width - most people don't use fix width editors these days? More than anything - why didn't it just defer to MD2Loader - so we'd only have one place to maintain.

I'd almost got up the enthusiasm to get involved with Xith again but things like this just make me think I'd spend more time fighting whats already there. The only way I am able to navigate this is have eclipse do all the donkey work for me - not particularly pleasent.

I thought at one point (maybe some years ago now) - Xith had aggreed to just use the Sun standards for coding like everyone else in the Java world?

Kev

PS. The source on the website seems to be one version out of date with whats in the build also.
PPS. Still thank god for William's showsrc tool - thats one handy script Smiley

Offline kevglass

JGO Kernel


Medals: 153
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2006-06-05 15:29:48 »

Hmm, actually the standard LoaderBase also doesn't really make sense at all for MD2s since you'll always want to specify a skin to go along with your model - hence the need for the addition of the non-standard methods:

1  
2  
3  
 public String  getTextureFilename ( )

 public void  setTextureFilename ( String  textureFilename )


Why comply to the interface (no, not a java one, just the interface of the class) when it doesn't fit and ends up making the loading process more convoluted?

Kev

Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #6 - Posted 2006-06-05 15:35:03 »

Hopefully this is not yet generalized

at least the core Xith follows Sun's coding conventions... except that javadoc is usually crappy (but that's not new).

Please don't walk away... it's nice to see you again in this board ! and there are so many things to contribute to...

Lilian Smiley

Offline croft

Junior Member




Java, Java, Java


« Reply #7 - Posted 2006-06-05 22:01:16 »

What sort of an abomination of a source format is that? Never since I worked with C++ military applications have I seen something that makes it so hard to read and maintain code.

I wrote that code.  I was trained to write code while I was in the military and that is indeed a derivative of the military style.  Funny that you should make that connection.

Supposedly it should make code much easier to read and maintain.  At least that's why the military uses it.

David Wallace Croft / www.CroftSoft.com / (214) 636-3790 m / Advanced Java Game Programming
Offline kevglass

JGO Kernel


Medals: 153
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #8 - Posted 2006-06-06 01:21:32 »

I think (at least from my experience at a 2 large UK defense companies) that this sort of style is easy to read when you've been taught it from day one. Its a learned readability. I personally learnt with a completely different style to this one and the java conventions - however, I found the Sun standard Java conventions natural and clear. Obviously its only opinion - but given the breadth of developers that could contribute to Xith its nice to see that an open standard has been adopted for the core.

Kev

Offline Amos Wenger

Senior Member




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


« Reply #9 - Posted 2006-06-06 10:56:01 »

Quote
I thought I fixed that in 0.7.1... are you sure you have it ? 0.7.0 didn't include them, was my fault. (In 0.7.1 these are in the jogl directory, it's not called jsr231 or whatever).

http://xith.org/download/third-party/jogl/jogl.jar isn't JSR 231. Nor is the one in the package of dependencies.
Ah, forgot this one. And in xith3d-0.7.1.tar.gz, directory third-party/jogl/ should contain JSR-231. But the third-party.tar.gz file doesn't contain JSR-231, either. I'm sorry this will be fixed soon I still have to get more familiar with Xith build process.

If the LWJGLRenderer is no longer supported - remove it. If it is intended to be and it doesn't work then it needs to be noted somewhere - and possible removed from the formal builds until it does? (leave it in the nightly builds)
Hmm. It's intended to be supported it's just a bit old I may take time to debug it.
Quote
I'm afraid there's not.. However if there is a cool Joomla! module for Issue Tracking I'll set it up happily.
Does that mean nothing outside of java.net ? Or nothing at all?
That does mean there is nothing outside java.net (see https://xith3d.dev.java.net/servlets/ProjectIssues) and that does mean also that I can commit time to add a Joomla! extension (see http://extensions.joomla.org) if it's interesting.
Quote
Hmm.. I spent some time fixing path issues in the OBJ/3DS/MD2 loaders.. at least it works now  Cheesy (there had some problems with absolute/relative path, "\" or "/" separators, loading from jars, classpath and all these tricks..).

As far as I'm aware the loaders have always simply read from input streams. If someone added a layer wrapping that with an incorrect file handling - meh. The point is the MD2Test.java that I downloaded from the newdawn site needed:

1) The package names changing
2) The rendering peer changing
3) The UI stuff removing

And then ... it just worked .... which is a lovely state to be in Smiley
About the UI stuff, I'd like to see your old code (when it wasn't working) cause it works perfectly for me so there's no reason it shouldn't work for you.

"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 Amos Wenger

Senior Member




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


« Reply #10 - Posted 2006-06-06 11:05:38 »

<shitty post incoming>

Oh, one other thing - as I come to do proper changes for this loader thing - I'm looking at this file:

http://xith.org/showsrc.php?src=src/org/xith3d/loaders/md2/MD2Loader2.java

What sort of an abomination of a source format is that? Never since I worked with C++ military applications have I seen something that makes it so hard to read and maintain code.

The code appears to be just cut and pastes of things within the original MD2Loader but refactored into the loading interface - which of course makes sense. However, my eyes go funny just trying to read it - wheres the javadoc? Whats the point of all these imposed lines of slahes? Wheres in the inline doc? Wheres the param tags, return tags etc? Why is it all tabbed in one space? Why is it formatted to a 80 character width - most people don't use fix width editors these days? More than anything - why didn't it just defer to MD2Loader - so we'd only have one place to maintain.

I'd almost got up the enthusiasm to get involved with Xith again but things like this just make me think I'd spend more time fighting whats already there. The only way I am able to navigate this is have eclipse do all the donkey work for me - not particularly pleasent.

I thought at one point (maybe some years ago now) - Xith had aggreed to just use the Sun standards for coding like everyone else in the Java world?

Kev

PS. The source on the website seems to be one version out of date with whats in the build also.
PPS. Still thank god for William's showsrc tool - thats one handy script Smiley

You're right, that'd be cool if croft adopted Sun coding standards like "everyone" else. However if he won't, I'm not willing to refuse to include its contributions just because of the source code conventions. I'd rather refactor the whole source files myself than miss the Collada loader.

Hmm, actually the standard LoaderBase also doesn't really make sense at all for MD2s since you'll always want to specify a skin to go along with your model - hence the need for the addition of the non-standard methods:

1  
2  
3  
 public String  getTextureFilename ( )

 public void  setTextureFilename ( String  textureFilename )


Why comply to the interface (no, not a java one, just the interface of the class) when it doesn't fit and ends up making the loading process more convoluted?
Yeah that's one problem with Scene and LoaderBase and all that stuff. It's not designed for animated or skinnable thingies... I cannot imagine how it would be doable to port Cal3Dj to Xith3D complying to LoaderBase.

at least the core Xith follows Sun's coding conventions... except that javadoc is usually crappy (but that's not new).
About javadoc.. I saw that there has been differences between the old builds (when it was numbered like 20050823) and the CVS. I think some has magically appeared. I complete some when I've got no other very important things to do. Now can we copy/adapt/paste the javadoc from Java3D when it's applicable ? (I didn't do that, it's just do know).

Please don't walk away... it's nice to see you again in this board ! and there are so many things to contribute to...
Indeed. I join to c_lilian for this demand.

"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 croft

Junior Member




Java, Java, Java


« Reply #11 - Posted 2006-06-06 13:17:27 »

Yeah that's one problem with Scene and LoaderBase and all that stuff. It's not designed for animated or skinnable thingies... I cannot imagine how it would be doable to port Cal3Dj to Xith3D complying to LoaderBase.

I was able to get COLLADA animations to work with LoaderBase by converting the animations to Java 3D API Behavior classes.

David Wallace Croft / www.CroftSoft.com / (214) 636-3790 m / Advanced Java Game Programming
Offline Amos Wenger

Senior Member




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


« Reply #12 - Posted 2006-06-06 13:33:29 »

Yeah that's one problem with Scene and LoaderBase and all that stuff. It's not designed for animated or skinnable thingies... I cannot imagine how it would be doable to port Cal3Dj to Xith3D complying to LoaderBase.

I was able to get COLLADA animations to work with LoaderBase by converting the animations to Java 3D API Behavior classes.
Hmm.. what about performances ? And do you have to call an update() method each step yoursefl ?

"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 croft

Junior Member




Java, Java, Java


« Reply #13 - Posted 2006-06-06 13:37:49 »

Hmm.. what about performances ? And do you have to call an update() method each step yoursefl ?

I'm hitting my target frame rate.

Yes to the update() question.  For more info, see
http://earth.whoola.com:8080/javadoc/xith-tk/org/xith3d/behaviors/package-summary.html#package_description

David Wallace Croft / www.CroftSoft.com / (214) 636-3790 m / Advanced Java Game Programming
Offline kevglass

JGO Kernel


Medals: 153
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #14 - Posted 2006-06-06 15:34:17 »

Quote
You're right, that'd be cool if croft adopted Sun coding standards like "everyone" else. However if he won't, I'm not willing to refuse to include its contributions just because of the source code conventions. I'd rather refactor the whole source files myself than miss the Collada loader.

Well,  its in the toolkit - so there isn't any refusual of code anyway? Either way its was an observation of something that might be making it hard for people to get involved (I'm still struggling to understand why there don't seem to be many hands to "all" the work round Xith at the moment).

Kev

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.

CopyableCougar4 (14 views)
2014-08-22 19:31:30

atombrot (28 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38
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!