Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (553)
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 goals  (Read 1568 times)
0 Members and 1 Guest are viewing this topic.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Posted 2004-09-16 00:27:51 »

Here is a list of goals that I would like to work towards.


  • Remove unimplemented never-to-be-implemented methods and fields.
  • Create list of "Core" packages and mark them as so in package level javadocs.  Non-core and experimental packages should also be marked as such.
  • Fully javadoc the Core packages and mandate that future changes must be documented as well
  • When OS X LWJGL support exists, promote the LWJGL renderer to an officially supported renderer aiming at 100% compatability for the Core packages with the JOGL renderer.


Yuri has also mentioned some features which would be very nice (ViewPlatform, sterio viewing, shaders, render to texture etc...).

What do people think?  Are there any objections to removing those useless methods and fields?  I understand that some fields were added for Java3d compatability (even though they do nothing in Xith3d).  Any reason to keep them now?

Will.

Offline ap_kelly

Junior Member




Java rocks!


« Reply #1 - Posted 2004-09-16 00:40:49 »

I've not used the Xith3D packages yet, but I wouldn't remove any methods and attributes just yet. I'd simply mark them as depricated (if they're not already).

I come from a pure OO world so the idea of exposed attributes without getters and setters worries me; I don't think you can deprecate a field!

Regards,

Andy.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #2 - Posted 2004-09-16 02:21:20 »

deprecating is an option but rather pointless if nobody uses them anyway.  The methods I speak of are unimplemented (i.e. {});

By "fields" I meant constant fields, i.e. http://xith.org/javadoc/constant-values.html#com.xith3d.scenegraph.TransformGroup.LAST_CAPS_BIT_POSITION

These constant fields and methods are ghosts and existed for Java3D compatibility.  I am testing the water to see if anyone is actually using them or can see a current need for them.  I see more people getting confused ("I was calling this method and don't know why nothing was happening").

Xith3D does follow OO principles.

Will.

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

Senior Member


Medals: 1


Lazy Middle Class Intellectual


« Reply #3 - Posted 2004-09-16 03:53:53 »

I +1 removing everything that is non-implemented. Add it to a todo list or something if it will eventually be added, but for now I think it just causes confusion.

Sacramento Volleyball
"Whitty phrase goes here."
Online kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #4 - Posted 2004-09-16 05:22:52 »

This is a very good idea. +1. If removing an empty method breaks someone's code they can of course simply remove the call since it didn't do anything anyway.

You'd be pushed to implement setters for the fields in question by the way since they're constants Smiley

Kev

Offline Jens

Senior Member




Java for games!


« Reply #5 - Posted 2004-09-16 06:12:02 »

+1 for documenting the core packages. Along with better Javadoc I'd also suggest to introduce official Xith3D code conventions (should be enough to put them in the xith.org docs section). Basically we can adopt the code conventions by Sun and just mention the differences (if any).

Xith3D Getting Started Guide (PDF,HTML,Source)
Online kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #6 - Posted 2004-09-16 06:33:43 »

While I totally agree that specifing exceptions in documentation is a good idea I can't find any reference to it being a convention endorsed my the Sun Conventions?

I'd really like to find the bit since I could use it to club co-workers into fully documenting their methods..

Kev

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #7 - Posted 2004-09-16 11:08:56 »

sounds fine to me -- Sun conventions + exceptions documented.

Eclipse has the lovely Source->Format option which can do everything for us, but it does make it a bit harder to compare one version of Xith3D to another depending on how many formatting changes this would make.

Will.

Offline Jens

Senior Member




Java for games!


« Reply #8 - Posted 2004-09-16 12:22:48 »

Quote
Eclipse has the lovely Source->Format option which can do everything for us, but it does make it a bit harder to compare one version of Xith3D to another depending on how many formatting changes this would make.


I like the Source->Format option. Smiley Source -> Add Javadoc Comment is useful, too. Eclipse also has the advantage that the code conventions can be saved in an xml-file. Version comparing can get a bit more difficult, but as the format will only change once per file (depending how much the files differ from the conventions) it isn't such a big problem and makes the code more readable.

I suggest taking the following simple steps:
  • create a simple "(not yet) official code conventions" page at xith.org
  • write a paragraph in the xith.org docs section linking to this new page
  • create a new thread in this forum where everyone can write down suggestions for exceptions from the Sun code conventions (or more detailed explanations if necessary)
  • after a fixed time span without new suggestions the code conventions become official

Of couse it would also be nice, if people can download code convention files for eclipse (or other IDEs), when they start to differ from Sun conventions for which eclipse has built-in support. Are you happy with this procedure?

Xith3D Getting Started Guide (PDF,HTML,Source)
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #9 - Posted 2004-09-16 22:05:53 »

Quote


  • create a new thread in this forum where everyone can write down suggestions for exceptions from the Sun code conventions (or more detailed explanations if necessary)


done

Will.

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

JGO Coder


Projects: 2


Fire at will


« Reply #10 - Posted 2004-09-17 03:06:44 »

I have now removed most of the unimplemented methods from com.xith3d.scenegraph.

CVS log/diff here:
https://xith3d.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=412

It is certainly much cleaner now they are gone - less chance of error, and less need to look at the source just to see if a method is implemented or not.

If you were inadvertently using one - you may need to comment it out in your code for it to compile.  Interestingly there was one such call in com.xith3d.io - and one call in Odejava (no wounder that code wasn't working!).

Will.

Offline Jens

Senior Member




Java for games!


« Reply #11 - Posted 2004-09-17 07:36:07 »

Added paragraph to xith.org docs section and edited code conventions page. (I like the Wiki. Smiley)

Xith3D Getting Started Guide (PDF,HTML,Source)
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #12 - Posted 2004-09-18 01:52:39 »

The biggest problem with changing the code formatting is that it renders any patches we recieve against the un-formatted version useless (or at least a real pain).  We should take a gradual approach and give people plenty of notice if this is going to go ahead.  Certainly mandating that all new code adher to the standard is a good idea.  This shouldn't really be a burden on developers, as far as I know most IDE's do the formatting for you as you go.

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #13 - Posted 2004-09-18 02:05:15 »

I've now committed a patch to remove most unused constants from the com.xith3d.scenegraph package.  Most had to do with capacity bits, a concept which Xith3D hasn't really implemented (except some in geometry arrays which I did not remove).  This is not to say that capacities are bad - in fact they are very good.  Having a compile feature to collapse unneeded TransformGroups etc would be very good.  Until the time however when this support is added in, these constants only serve to confuse and give the impression that it is supported when indeed it isn't.

The javadocs are becoming a bit more usable now.  All we need are some more comments and we'll be right.
Compare http://xith.org/javadoc/constant-values.html to http://xith.org/javadoc/constant-values2.html  the former only has used constants where as the latter has all the old unused ones as well - needless clutter.

CVS log/diff here: https://xith3d.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=413

I have now removed just about all unused methods and constants from com.xith3d.scenegraph.  I believe this is a step in the right direction to make programming with Xith3D referencing only the javadocs (and not the source) possible.  If you see a method in the javadoc or your IDE autocomplete, you can be 99% sure it isn't a phantom method.

Will.

Offline Bombadil

Senior Member





« Reply #14 - Posted 2004-09-18 12:06:50 »

Do you think you could also remove all the references to the log4j package which isn't used anyway?
To run Xit3d the logj4 jar isn't needed, just to compile it. So I usually tend to remove them from hand...
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #15 - Posted 2004-09-18 22:23:09 »

Log4j is a very powerful (and tiny) library.  I think it would even be better to go the other way and convert Xith3D's log statements to use log4j more.

Will.

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 (24 views)
2014-08-22 19:31:30

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

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

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

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

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

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

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

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

Norakomi (42 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!