Roadmap for Xith3D 0.8

Engines, Libraries and Tools Xith3D Forums
#1

That’s kind of my personal list, but if you feel like an item is “just your job”, please do !

And also, if you want a specific feature, please post, and we’ll see what is possible. This is also a wishlist.

  • One-file installer, using IzPack. I did some for my old games, and it works really well.
  • Source code cleaning : removing useless imports, correcting indentation (done automatically by Eclipse)
  • Javadoc completion : if possible, javadoc’d everything. I have no idea how big is the work to be done, but I’ve already began.
  • COLLADA loader : David W. Croft’s work
  • Separation of the Collision Detection code to xith-collision.jar (I need William’s help here, I don’t know much of Ant buildfiles)
  • Alternate vecmath lib included by default
  • Drop com.xith3d.render.jogl in favor of com.xith3d.render.jsr231
  • Actually update the third-party/jogl.jar file to JSR-231 ^^

Other ideas ? Criticisms ? Don’t be afraid to post ^^

#2

[quote="<MagicSpark.org [ BlueSky ]>,post:1,topic:27059"]

  • Drop com.xith3d.render.jogl in favor of com.xith3d.render.jsr231
  • Actually update the third-party/jogl.jar file to JSR-231 ^^
    [/quote]
    These ones have been done for Xith 0.7.1, in addition to a bugfix.
#3

I’ll post my wish list later (not enough time to really think about it : right now I’d say having shadows working, and improve the toolkit with a set of class to provide easy menus and menu transitions in games…).

Lilian

#4

This shouldn’t be hard, because they were working before : http://www.cokeandcode.com/node/341

The graphic part, right, but for the logic I’d just love to take out the “behavior” thingies out of graphic libs >:( it’s definitely not their place. I prefer having a 20Ko jar file which do it’s job and do it’s well, seperated from a scenegraph (just as I think collision detection stuff has nothing to do in xith3d.jar, which I should fix, too).

#5

[quote="<MagicSpark.org [ BlueSky ]>,post:1,topic:27059"]

  • One-file installer, using IzPack. I did some for my old games, and it works really well.
  • Source code cleaning : removing useless imports, correcting indentation (done automatically by Eclipse)
  • Javadoc completion : if possible, javadoc’d everything. I have no idea how big is the work to be done, but I’ve already began.
    [/quote]
    These one are delayed to 0.9, we have more important things to do before, if you consider features more important than doc, ease of installation & cl

[quote="<MagicSpark.org [ BlueSky ]>,post:1,topic:27059"]

  • COLLADA loader : David W. Croft’s work
    [/quote]
    Renaming loaders packages name and committing COLLADA is a work in progress.

[quote="<MagicSpark.org [ BlueSky ]>,post:1,topic:27059"]

  • Separation of the Collision Detection code to xith-collision.jar (I need William’s help here, I don’t know much of Ant buildfiles)
    [/quote]
    As I mentioned, I need William’s help here. Can you do that ?

[quote="<MagicSpark.org [ BlueSky ]>,post:1,topic:27059"]

  • Alternate vecmath lib included by default
    [/quote]
    Yuri VI. Gushchin, you were talking of this alternate vecmath lib which generated much less garbage… Do you know where I can download it ?

Xith3D is collaborative work, I see it’s not going soo bad as some people want to tell and I’d like to thanks all people who contributes to it ! Great job !

#6

When the Collada loader is done, will you be able to use models with bones and skinning via Collada and Xith 0.8?

#7

The Whoola Xith COLLADA Loader does not support bones and skinning yet. I heard a rumor that a company is going to release an Open Source COLLADA Loader for JME that will support skinning.

#8

Someone proposed me to do/improve a port of Cal3D in pure Java. He thought I could do the Xith3D support and I accepted. Maybe skeletal animation system could be shared between Java-Cal3D and Collada loader ?

#9

Previous to a 0.8 release the following things should be done:

  • reorganize loaders packages like this: http://www.java-gaming.org/forums/index.php?topic=14170.msg112479#msg112479
  • provide a shadowing test example
  • extract demos from the test packages like Amos suggested (put demos in a separate project/jar or in a new package e.g. org.xith3d.demos)
    I would prefer to put all tests into the tk (including the ones from the core) and all demos into a separate project.
  • review all tests (e.g. TarrainTest doesn’t work for me)
  • rename the org.xith3d.test.jcd to something that you know what it is (I don’t know)
  • put net.jtank.input.InputAdapter and net.jtank.input.InputListener from xith-tk into the HIAL project and delete the package from xith-tk.
  • What about MouseWheel support in HIAL? Is in in there? I it is, please tell me. Then I will add appropriate code to net.jtank.input.InputAdapter and net.jtank.input.InputListener

And what about the the package name in xith3d core. Shouldn’t we rename com.xith3d to org.xith3d in the core, too, in the near future?

#10

I :

  • reorganized many many packages e.g. I moved DisplayOptions to the tk, I also moved the Ase loader to the toolkit
  • I don’t like the idea to reduce model loaders to scene implementation I didn’t changed the package names it’s not clearer as it’s suggested
  • I moved all demos to the tk
  • org.xith3d.test.jcd stands for “Java Cool Dude” test’s it’s someone named Abdul Bezrati’s who was doing cool demos some months ago
  • about HIAL there’s no project on dev.java.net and I don’t have the source so… I will leave it in here until we found a solution
  • I removed completely OldLoader and changed all code using it (HUGE work !!! :-X )
  • I removed all the .bat files and the runtest.bat & runtest.sh files which are useless now with JWS (and it’s too much hassle to maintain each of them)
  • And also some others things which I can’t remember…
#11

Good job. but…

  • Did you recognize the lwjgl tests are broken now?
  • There’s no TextureLoader.flipImageVertical method anymore. By what has this one been replaced?

About the once planned code cleaning: I could do this (well, when my role on the core will be approved ;)). And I would suggest to split some packages in the core into some subpackages to get them more clearly.

#12

Please update your CVS repository.
The TextureLoader.flipImageVertical() method has been moved in the com.xith3d.image.ImageUtils class, created especially for this. The apps using it have been fixed accordingly.

OK, but once I wanted to split the com.xith3d.scenegraph package and some were clearly opposed to that, arguing to keep the high cohesion / low coupling concept (or something like that). If they are so touchy about that, they might be right. (And it’s really a pain in the ass of users if we change that, as to renaming all com.xith3d packages to org.xith3d)

#13

[quote="<MagicSpark.org [ BlueSky ]>,post:12,topic:27059"]
Please update your CVS repository.
The TextureLoader.flipImageVertical() method has been moved in the com.xith3d.image.ImageUtils class, created especially for this. The apps using it have been fixed accordingly.
[/quote]
Yes, sorry. I already found it.

And what about the lwjgl tests? They are caused by the missing of org.lwjgl.opengl.Display and org.lwjgl.input.Keyboard.

hmm… But it’s only a matter of one text replace for this com.xith3d->org.xith3d. And about the subpackage spreading. I think it is good for the project. So we should really change that. Maybe it’s worth a poll?

#14

Another thing concerning the TextureLoader. I saw you made changes in ExtXith3DEnviroment, which is good. But I took one TextureLoader instance for each Environment for a certain reason: When you have more than one Universe at a time (I do have such a case), there was a bug in the cache that caused the engine to take more and more memory after using one cached Texture instance in two universes. That’s why I stayed with TextureLoader1.

Is this bug solved?

And you also implemented registerTexturePath and registerTextureJarPath in the ExtXith3DEnvironment the same way. Is this correct?

#15

(I’m uploading the releases files and writing the news at this time so it’s too late to include anything more for 0.8.0 I’m open to any suggestion for 0.8.1)

Hmm yeah I agree but sometimes it seems that people uses vim to edit their .java files so it’s hard for them to have a project-wide find/replace ;D ;D But maybe you’re right. But the subpackage spreading is much much more annoying…

Ahem :-X no it isn’t I guess we have to fix it rapidly… Maybe just having one TextureLoader2 instance per ExtXith3DEnvironment would fix that bug ? I hope that’s not a problem for your right now cause you can fix the CVS and I don’t know other people using the ExtXith3DEnvironment. So in 0.8.1 it’ll be included.

Hm I didn’t see much difference in your code between them. If it’s incorrect, see if you can fix it.

#16

[quote="<MagicSpark.org [ BlueSky ]>,post:15,topic:27059"]

Hmm yeah I agree but sometimes it seems that people uses vim to edit their .java files so it’s hard for them to have a project-wide find/replace ;D ;D But maybe you’re right. But the subpackage spreading is much much more annoying…
[/quote]
I don’t think one had to account for masochistic people ;).
But for the spreading you may be right. But I really think, this should be done pre 1.0. And since it was never done, if we said “we will do this some time pre 1.0”, it should be done resently. Don’t you agree?

[quote="<MagicSpark.org [ BlueSky ]>,post:15,topic:27059"]

Ahem :-X no it isn’t I guess we have to fix it rapidly… Maybe just having one TextureLoader2 instance per ExtXith3DEnvironment would fix that bug ? I hope that’s not a problem for your right now cause you can fix the CVS and I don’t know other people using the ExtXith3DEnvironment. So in 0.8.1 it’ll be included.
[/quote]
Well, that’s what I had previous to your changes ;D. I Had to use TextureLoader1 because TextureLoader2 was abstract (if I remember right). But now I can change this.

[quote="<MagicSpark.org [ BlueSky ]>,post:15,topic:27059"]

Hm I didn’t see much difference in your code between them. If it’s incorrect, see if you can fix it.
[/quote]
ok.

#17

I don’t think one had to account for masochistic people ;).
But for the spreading you may be right. But I really think, this should be done pre 1.0. And since it was never done, if we said “we will do this some time pre 1.0”, it should be done resently. Don’t you agree?
[/quote]
I agree, but hey, waaaait the bad thing with that is we loose all the CVS history !! It’s a serious problem.

#18

[quote="<MagicSpark.org [ BlueSky ]>,post:17,topic:27059"]
I agree, but hey, waaaait the bad thing with that is we loose all the CVS history !! It’s a serious problem.
[/quote]
We could simply start a second branch on CVS. The longer we wait, the bigger the problem becomes. I would anyway suggest to give me an additional separate CVS branch on the core assumed I will get dev role on the core. So I could change things like I imagine them to be, you and others could have a lokk at it, and then we could see, if it is committed to the main branch (or parts of it).

#19

TextureLoader2, which is now TextureLoader is not abstract but the constructor is hidden. So it cannot be instantiated anyway. So I cannot solve the problem in my case except for making the contructor visible in my local copy of xith3d code. This is ok for the moment. Since i won’t have too much time during the next weeks to further develop my game, I won’t hit the problem again too soon.

#20

Is there a way to load textures from jar using the new TextureLoader?