+1

Amos Wenger has been doing a really good job recently with the project, he now manages the community web site as well.

Hope everything is going well!   

Will.

Cool - thanks.  My sf username is 'divzero'

Cheers,
Will

Nice one.

As far as I know there are no non-ASCII characters in the repositories, so that should be fine.

When the new one is setup, ideally you want the standard (but not enforced) "trunk" and "branches" SVN layout so that you can easily branch the code for releases/stable versions.

I've emailed you my phone number (in case you didn't already have it).

Cheers,
Will

History is valuable if you do manage to get it.  The java.net project may get deleted if it is not updated for a while too.  Hopefully the admins get back to you...

SourceForge is good as they let you download a repository snapshot, and SVN is definitally well worth the pain.

How much does CollabNet want for the SVN repository dump?  I'm sure you'd be able to raise it if it wasn't excessive.

Cheers,
Will

Very good thanks hawkwind - yourself?  Work is keeping my very busy and will for some time to come.  That said, I'm not complaining at all as it is game development   Can't wait to share what I have been working on, but that won't happen till next year when it's finished.

It's great to see that Xith3D's being maintained and new projects like JOODE getting some attention.

Cheers,
Will

Xith3D isn't designed to be multi-threaded, so unless you are changing that I would not worry at all.

Anyone using Xith3d will have to keep all of their Xith3D calls in the one thread.

Reducing garbage is essential.  C++ console games are designed so that there is NO garbage created during the game loop and there's no reason why this can't be done in Java, or at least minimised (stack-local objects in future versions of Java should help with this goal).

Cheers,
Will

Good plan. 

SVN is so much better than CVS.

Personally I think it is good API design to keep the core small and have optional modules that people can use or not (so long as each of the modules list their dependancies clearly).  This also provides some QA - commits to the core can be more heavily scrutinised.

It would be good to support JOODE for Physics/Collision when that is usable (not sure if it is or not - havn't checked for a while).

Cheers,
Will

JavaCoolDude (Abdul Bezrati) got a job in the games industry I believe.

I the thread linked to from http://www.xith.org/pages/java_cool_dude_demos.html may have had links to source.  Not sure where that is now (but I'm sure it could be found on the new forums somewhere).  There's some source on the xith.org JavaCoolDude directory.  One or two examples were committed to the xith-tk IIRC.  Best bet would be to track down that thread.

Cheers,
Will.

Topics unstickied.

Cheers,
Will.

Ant can also be used to automate the otherwise painful release process.  Being able to create a release (with all the various components) by a single command means there is no reason not to release new versions often.

Will.

Well I am a big fan of Ant, even though I used to use Eclipse to compile anyway.  It just means that anyone can build the project simply by typing "ant", regardless of IDE.  Some people do use other IDE's like NetBeans too.  Maintaining ant has never been an issue for me (what needs to be changed? only changing dependancies and version numbers normally). 

We're not using C++ here where everyone is using Visual Studio - keeping things IDE neutral is good practice in the java world.  IMHO.

Will.

Kev's advise is good.  It can be easy to lose focus on actually creating games...

Will.

In this particular case, backwards compatiability is preserved by simply deprecating the entire previous listener API and providing a new one.  Personally, I feel if this is the case - anyone really wanting to keep using the old API can by simply not upgrading.  This is different to say backward compatability where new features are added while preserving existing ones (deprecating only a method or two).

I'd suggest re-releasing 1.5 (maybe as 1.51) where there is a single version (with no '2' suffix).  Either keeping backwards compatability by not renaming the methods, or not by adopting the new names instead (I believe Marvin prefers the latter which is fine by me).  I don't think the implications of either actually matter that much since most people are probably using the implementations such as KeyArrayListener (isPressed() method) and not the raw listener interfaces anyway.

Marvin, sorry for not getting on to this sooner - I've been very busy and only just got a chance to have a look.  Thank you for maintaining the API.  I'll contact you about getting the new version up on http://input.jtank.net/

Amos, regarding your comment - I would suggest not forking Xith3D.  You can gain valuable experiance (and exposure) by maintaining a public API and helping its userbase.  Sure it's easier when you're not answerable to other users of your API, but unless you plan never to work in a larger group it's worthwhile to get experiance with this.  Also, a public API can have new people contributing new ideas and work which you can benifit from if you're still using it.

Cheers,
Will

As far as I know the junit stuff never really worked, and it's certainly not up to date, I'd probably just toast it.  This is not saying that junit is bad - just that that folder is basically useless in it's current form.

I think the web site probably already has all the contents of that www folder, so I'd probably just remove it.

Regarding third-party vs ext, I think there's something to be said for sticking with the standards that are in place.  If everyone just did things their own way it would get very messy fast.  If the standard needs to be changed, then there should be good reason and a discussion, the result of which should be adopted across the board.  But that's just my 2 cents.

Cheers,
Will

Hi David,

Great to hear from you, I hope life has been treating you well.

I ended up working on a project named Lineriders with Philip Worthington that used Xith3D and Odejava.  It was a fun project and was part of a show last year in London at the Royal College of Art.  It also helped me get a job in the games industry where I am now working.

I havn't been active on Xith3D recently due to work taking most of my attention, but still lurk in the forum from time to time.  It's certainly great that there are still people (some new, some old) putting energy into the project and taking it forward.

Cheers,
Will

Hey BlueSky,

Thanks for your recent efforts to the project, I will approve owner access for xith-tk.  Last month I tried to email you a couple of times several days apart but they bounced with mailbox full errors.  I'm guessing the address I was using was an old one - can you please email me (will -at- tanksoftware.com) so I've got your current address?

Cheers,
Will

A little late, but here's my answer anyway:  What you were looking at was a simple Enum design pattern before they were part of the language.  The main reason for avoiding int constants when this class was coded is that it allows some errors to be picked up at compile time, much the same reason why ints are still avoided today.   I certainly don't have any objections to changing it to be a real enum, thanks for updating the code!

Cheers,
Will

 theany mis compiler doesn't pick up mistakes at comp is that the compiler doesn't pick up errors it up when

Great effort!

Now that Java3D is revitalised (and remembering that it was basically on it's death bed when Xith3D was started), I see less of a reason for promoting the similarities.  People who want Java3D can use it.  Keeping the API similaritiy I agree is a good thing, but I think Xith3D should seek to differentiate itself from the alternatives and promote these differences, not just the fact that it has a more open license (although that would be a factor for some people no doubt).

I would describe Xith3D more as inspired by Java3D, but with a different focus (i.e. highly optimised) rather than as a Java3D implementation.

Just my $0.02

Cheers,
Will.

When I coded that class the language didn't have enums

Will.

IIRC David's example loaded one of Id's official Q3 levels, though I can't be totally sure.

GtkRadient can be used to create Q3 levels.  It's a fairly nice editor, I have used it to make a Q3 map in the past.  I don't know of any other code examples.

Cheers,
Will

the user 'qudus' is a Developer on the xith-tk project.  If you don't have write access you may need to contact the java.net admins (years ago I believe you had to fax a form to get write access - I'm not sure if this is still the case).

Cheers,
Will

This topic appears constructive to me, it creates an open discussion on a particular feature of Xith3D, with one person prepared to commit time to the idea if enough people would benifit.  Seems fair enough.  Post count?  Big deal...

+1 for starting discussions
+1 for this feature - Cell shading is a cool tech, and it would be nice to see better support in Xith3D

Cheers,
Will

Looks like a useful tool, have you been using it?

Will.

Damn - sorry guys.  Yes it exceeded 6GB last month - impressive!  I've upped the quota to 10GB.  I'll keep a closer eye on it and can increase it more if needed.

It wasn't due to abuse, just more visitors than normal - a record 3746 unique visitors last month making 5383 visits, and generating 121121 hits - would have been more had the bandwidth not been exceeded.  It looks like the JWS demo's are rather popular (which is where the bandwidth goes).

BTW, do email me if the site is down, just in case I am too busy to check in on the forums.

Cheers,
Will

Thanks for the kind words!  Java One would have been sweet, pity we missed it.

As for future plans, Philip might be taking it further, but I probably won't.  I'm pretty happy with how it turned out though, it was fun to work on and helped me get a job in the game dev industry.

Cheers,

Will.

By all means, please do.

Would be cool to see XODE support in JOODE too.

Will.

I also implemented fractal based terrain, and used GeomTriMesh's.  The Terrain thing was a patch to ODE that was not commented or documented and didn't work.  GeomTriMesh is a more generic case, but should work well for terrain.

Will.

Some documentation at least was created in that time

http://www.java-gaming.org/forums/index.php?topic=12150.0

Will.

looking good, thanks

Cheers,
Will.