Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (525)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (593)
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  
  Roadmap for Xith3D 0.8  (Read 3797 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Devvie




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


« Posted 2006-04-22 15:36:15 »

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

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

Senior Devvie




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


« Reply #1 - Posted 2006-04-29 10:26:37 »

  • Drop com.xith3d.render.jogl in favor of com.xith3d.render.jsr231
  • Actually update the third-party/jogl.jar file to JSR-231 ^^

These ones have been done for Xith 0.7.1, in addition to a bugfix.

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

Senior Devvie


Projects: 1


Java games will probably rock someday...


« Reply #2 - Posted 2006-04-30 09:37:51 »

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

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Devvie




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


« Reply #3 - Posted 2006-04-30 18:51:31 »

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

improve the toolkit with a set of class to provide easy menus and menu transitions in games...).
The graphic part, right, but for the logic I'd just love to take out the "behavior" thingies out of graphic libs  Angry 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).

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

Senior Devvie




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


« Reply #4 - Posted 2006-05-05 13:12:30 »

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

  • COLLADA loader : David W. Croft's work
Renaming loaders packages name and committing COLLADA is a work in progress.

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

  • Alternate vecmath lib included by default
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 !

"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 kaffiene
« Reply #5 - Posted 2006-05-05 23:15:34 »

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

Junior Devvie




Java, Java, Java


« Reply #6 - Posted 2006-05-06 03:04:08 »

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

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.

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

Senior Devvie




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


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

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

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.


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 ?

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




May the 4th, be with you...


« Reply #8 - Posted 2006-06-25 19:38:00 »

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

Senior Devvie




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


« Reply #9 - Posted 2006-06-26 16:06:02 »

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?
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 !!!!   Lips Sealed )
- 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..

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

Senior Devvie




May the 4th, be with you...


« Reply #10 - Posted 2006-06-26 16:43:10 »

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 Wink). And I would suggest to split some packages in the core into some subpackages to get them more clearly.
Offline Amos Wenger

Senior Devvie




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


« Reply #11 - Posted 2006-06-26 16:47:55 »

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

About the once planned code cleaning: I could do this (well, when my role on the core will be approved Wink). And I would suggest to split some packages in the core into some subpackages to get them more clearly.
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)

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




May the 4th, be with you...


« Reply #12 - Posted 2006-06-26 16:58:24 »

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.

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.

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)

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

Senior Devvie




May the 4th, be with you...


« Reply #13 - Posted 2006-06-26 17:08:13 »

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

Senior Devvie




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


« Reply #14 - Posted 2006-06-26 17:22:42 »

(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... 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?
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  Grin Grin But maybe you're right. But the subpackage spreading is much much more annoying..

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?
Ahem  Lips Sealed 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.

And you also implemented registerTexturePath and registerTextureJarPath in the ExtXith3DEnvironment the same way. Is this correct?
Hm I didn't see much difference in your code between them. If it's incorrect, see if you can fix it.

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




May the 4th, be with you...


« Reply #15 - Posted 2006-06-26 17:58:49 »

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?
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  Grin Grin But maybe you're right. But the subpackage spreading is much much more annoying..

I don't think one had to account for masochistic people Wink.
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?

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?
Ahem  Lips Sealed 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.

Well, that's what I had previous to your changes  Grin. I Had to use TextureLoader1 because TextureLoader2 was abstract (if I remember right). But now I can change this.

And you also implemented registerTexturePath and registerTextureJarPath in the ExtXith3DEnvironment the same way. Is this correct?
Hm I didn't see much difference in your code between them. If it's incorrect, see if you can fix it.

ok.
Offline Amos Wenger

Senior Devvie




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


« Reply #16 - Posted 2006-06-26 18:17:59 »

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?
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  Grin Grin But maybe you're right. But the subpackage spreading is much much more annoying..

I don't think one had to account for masochistic people Wink.
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?
I agree, but hey, waaaait the bad thing with that is we loose all the CVS history !! It's a serious problem.

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




May the 4th, be with you...


« Reply #17 - Posted 2006-06-26 18:57:51 »

I agree, but hey, waaaait the bad thing with that is we loose all the CVS history !! It's a serious problem.

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).
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #18 - Posted 2006-06-26 19:10:15 »

I Had to use TextureLoader1 because TextureLoader2 was abstract (if I remember right). But now I can change this.

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

Senior Devvie




May the 4th, be with you...


« Reply #19 - Posted 2006-06-26 19:14:45 »

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

Senior Devvie




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


« Reply #20 - Posted 2006-06-26 19:22:10 »

I agree, but hey, waaaait the bad thing with that is we loose all the CVS history !! It's a serious problem.

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).
That's OK for me but I don't have Owner access on xith3d so you should wait until yvg or willdenniss comes.

I Had to use TextureLoader1 because TextureLoader2 was abstract (if I remember right). But now I can change this.

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.
check the TextureLoader2.newInstance() method.

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




May the 4th, be with you...


« Reply #21 - Posted 2006-06-26 20:11:09 »

check the TextureLoader2.newInstance() method.

This method seems to have disappered during the least changes. Did it just create a new  instance? So why wasn't the constructor public? Of course this actually won't make sense when the cache bug is fixed.
Offline Amos Wenger

Senior Devvie




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


« Reply #22 - Posted 2006-06-27 13:54:14 »

check the TextureLoader2.newInstance() method.

This method seems to have disappered during the least changes. Did it just create a new  instance? So why wasn't the constructor public? Of course this actually won't make sense when the cache bug is fixed.
I added it recently (yesterday).

It just create a new instance. The constructor wasn't public because of the singleton pattern used. May you investigate about the cache bug ? I think it's a problem at the OpenGL level, which isn't easy to fix.

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




May the 4th, be with you...


« Reply #23 - Posted 2006-06-27 13:59:53 »

May you investigate about the cache bug ? I think it's a problem at the OpenGL level, which isn't easy to fix.

Sorry, I already took too much time besides by learning phase (university). So I can think about such things in two months.
Offline Amos Wenger

Senior Devvie




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


« Reply #24 - Posted 2006-06-27 14:09:32 »

May you investigate about the cache bug ? I think it's a problem at the OpenGL level, which isn't easy to fix.

Sorry, I already took too much time besides by learning phase (university). So I can think about such things in two months.
OK.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
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.

toopeicgaming1999 (67 views)
2014-11-26 15:22:04

toopeicgaming1999 (58 views)
2014-11-26 15:20:36

toopeicgaming1999 (12 views)
2014-11-26 15:20:08

SHC (25 views)
2014-11-25 12:00:59

SHC (24 views)
2014-11-25 11:53:45

Norakomi (30 views)
2014-11-25 11:26:43

Gibbo3771 (24 views)
2014-11-24 19:59:16

trollwarrior1 (37 views)
2014-11-22 12:13:56

xFryIx (76 views)
2014-11-13 12:34:49

digdugdiggy (53 views)
2014-11-12 21:11:50
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!