xith.org updates

Engines, Libraries and Tools Xith3D Forums
#21

I agree its currently sufficient, I was more thinking from the point of view of future expansion. If you get all your users here, and then want to switch over at a later time you’ve got alot more people to move.

I’m sure its not that difficult, but I guess its a matter of priorities. Appointing a moderator for a forum that effects 10’s of people probably doesn’t match up well against promoting Java Gaming to the rest of the world (only guessing of course).

Also, I think theres going to be rejig of the moderators across the board so I guess he’s waiting to do it all in one fair swoop.

Kev

#22

It is very true that we might outgrow these forums, and also possible they might outgrow us (if it is seen that dedicated API’s do not belong, ref: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=suggestions;action=display;num=1065066684)

If people want a forum, I can have one on xith.org in a matter of minutes, it is a trivial matter.

I was originally going to suggest we have our own forum back in the days of the single JOGL thread but at the time I thought too that one here would be better as general java-gaming.org people would find it more easily and I think that we certainly reaped the benefits of having it hosted here.

pros

  • we can make as many mods as we want
  • we can have several different areas
  • not tied to java-gaming.org and whatever fates may be in store for it
  • we can have good features such as file uploading

cons

  • it’s yet another board to check - if you are a member of both the dedicated Xith3D one and the java-gaming.org
  • currently it is easy to attract new Xith3D users who are using the other java-gaming.org forums
  • Xith3D threads are split into two places (like LWJGL).

The longer we wait however - the more annoying the move becomes.

Essentially the decision lies with Xith3D users. If the majority of people call for our own dedicated place (and also only if the major players want in as well) then it can be so.

I will give it my +1 if enough people want it for the simple reason that I think Xith3D is gaining a lot of momentum and will continue to do so.

Will.

EDIT: just fixing up a url that got mangled

#23

Finally, we’ve got a moderator. :smiley:

#24

yeah that is great and it was not even problem if one asks nicely :wink: - but at the same time did you see all those stars around Dave’s icon? …that means we have knock before entering , bow down and then behave like angels ;D

#25

looks like we got our wish, he is a moderator now :slight_smile:

Will.

#26

There is new stuff in the Getting Started Guide. I just finished converting the tutorial More Fun with textures written by hawkwind. It extends the already existing texture tutorials. (@hawkwind: Drop me a line if something isn’t OK.) Will contributed a tutorial about Using RenderOptions. Besides this I made some minor content and layout changes.

#27

Alpha8 uploaded: http://xith.org/download/builds/12-Oct-2003_Alpha8/

Will.

#28

Will wrote a tutorial on Deploying Xith3D games with Java Web Start. He made all the apps in the Getting Started Guide webstartable. I added webstart links everywhere in the GSG (all in all it is very comfortable for the reader now).

The whole structure of the GSG has changed. All apps now belong to org.xith3d.gsg. The directory structure has been cleaned up and an ant script is used to generate the zip, jar, html and pdf files. The guide is ready to be committed to CVS, if the xith-tk project is created.

#29

http://xith.org/download/builds/
I think foldernames should follow YYYY-MM-DD_xyz naming convension to be sorted properly. Currently, builds folder is very hard to see whether there are new downloads avail.
Especially non-native english people have sometimes difficulties to put three-char month names listed.

#30

I agree. Use ISO 8601 convention for dates… it is the only numeric date format that makes any sense. International standards are good.

#31

yes I normally prefer yyyy-mm-dd too - dunno why I didn’t do it.

Of course you can order by creation date which is what http://xith.org/download.php does (http://xith.org/download/builds/?M=D).

The big quesion is - how many people are actually using the community builds anyway?

I will keep them up todate but I need to know how frequentally to do it. If only people who are trialing Xith (and switching to CVS if they continue using it) are using them then I will just do it once every month else if there is demand I can update them every time a significant feature is added / bug is fixed.

I may also start to remove old releases which were not flagged as a significient milestone (eg. Alpha5). Any objections to that?

Will.

#32

Hello everyone.

I’m new to this forum but I’ve been watching your progress for the last 2 months.
You’re doing a great job! :wink:

Now, back to the thread.
I think it will be good to keep the builds up to date frequently (twice a month may be) because I think there’s people who are hidden behind firewalls and it is very difficult (impossible for me) to get CVS working.
Now if I’m the only one, then un update every month will do.

DJ

#33

I think a new build should be released once approx. a month has passed or there is a larger update. Larger updates are Behaviors, collision detection/avoidance etc. The criteria should be that every app presented at xith.org can be run with the latest community build. I think there’s no need for you to release a new build for every solved issue or minor update. A download link for the current Javadoc could be handy for some people.

Besides this I think that there should be a either a new official release or a link from the Xith3D home to the community builds. I know of two people who tried to run apps using the official release, which doesn’t work in most cases, because it’s too old.

#34

I guess for the people using releases will also want to see the changelogs to check what has been changed.

Yuri

#35

I found it alot easier to do a full xith + third party stable install from xith.org than from cvs.
The release.jar on xith.home is also not quite up to date

I would vote for updating the download on feature adds as this should occur less frequently as mature versions emerge.

btw:
A link from xith.home (xith.dev.java.net) to xith.org could help direct newbees to the stuff

and: thanks for maintaining xith.org anyway :slight_smile:

regards
Martin

#36

Thanks for the feedback, I shall update the community builds more often now that I know people are using them :slight_smile:

Snapshot of todays CVS: http://xith.org/download/builds/2003-11-01_cvs/

Just a quick word as I am about to go out - if anyone wants FTP access to be able to upload builds - just email me. To create a community build it’s as simple as “ant cbuild”. A ChangeLog is a good idea - why don’t we make a sticky ChangeLog/Release thread in these forums?

As for the official xith project home page I think a link to xith.org would be good for new users.

Will.

#37

[quote]http://xith.org/download/builds/
I think foldernames should follow YYYY-MM-DD_xyz naming convension to be sorted properly. Currently, builds folder is very hard to see whether there are new downloads avail.
Especially non-native english people have sometimes difficulties to put three-char month names listed.
[/quote]
I have updated it. http://xith.org/download/builds/?N=D

“_cvs” indicates that the build is a snapshot and is not nessesarily tested or relyable. “_alpha8” or somthing similar means that it is a milestone build and should be slightly more dependable.

Regarding the ChangeLog - the options that I see are:

  • ChangeLog file in CVS
  • ChangeLog thread in the forums
  • ChangeLog file on some web site.

the CVS options is probably the best I think.

I think a sticky “releases” thread is probably a good idea for when community builds are updated.

Will.

#38

third-party libraries updated (xith utilities removed, hurrah)

http://xith.org/installing.php updated.

We are now adopting the policy that xith3d.jar should NOT belong in jre/lib/ext (see the above tute for explanation). The cons far oughtweigh the pros (the only real pro is conveniance but infact it is very inconveniant in some situations).

Will.

#39

I’m happy to announce a new section in the Getting Started Guide about Swing Integration.

The app is a framerate counter with an (optional) exit button. It uses the hidden high-resolution-timer of JRE 1.4.2 (because of the lack of an official timer in Java) and shows the use of UIWindow. An advantage of the tutorial is, that you can plug the counter in your existing games/demos by adding just one line. It’s a long tutorial, so you need some free minutes to read through it.

This is also the first time the Getting Started Guide is build directly from xith-tk CVS, so a lot of things have changed internally. If you notice mistakes, please inform me. (You may have to clear the GSG demos from your webstart cache, if webstart doesn’t work.)

Don’t know if this issue was already noticed, but there are problems with the MouseListener, when the window is resized. You can test this by starting the webstart version of the tutorial and clicking on the exit button.

#40

I hope no comments means everything is fine.

Another GSG Update: The section about interaction now explains why the scenegraph should not be modified from the AWT event thread directly.