New code in CVS - jME 1.0 release candidate 1 is around the corner

Hi folks,

If you update from CVS today you'll find a number of updates which may or may not affect you.  These updates have been made in preparation for the upcoming jME 1.0rc1 release (probably Monday).  Because we are moving towards a final 1.0 release, a number of older, unmaintained parts of the code have been removed.  Most of these parts were deprecated or have had replacements posted for one or two releases at least.

Here's a list of removed sections:

  1. com.jmex.sound.*  -  This section has long been abandoned by its original author and was replaced in the last release with  Because only uses OpenAL (for now), the fmod libs have also been removed from jme/lib.  You will probably need to update your build path and remove the fmod jar listing to make your IDE happy.  StandardGame has also been ported to using  For information on porting to, see tests and tests like HelloIntersection and AppletTestSounds which have been ported to use
  2. com.jmex.model.XMLParser.* - The model converters are now in jmex.model.converters, everything else like JmeBinaryReader/Writer and the XMLToBinary, etc. have been dropped.  JBR was a bunch of spaghetti code, requiring constant modification whenever the slightest changes to scene code were made.  Worse, it could not handle user created classes.  Files were often made unreadable by small code changes.  For at least two releases we have had the BinaryImporter and BinaryExporter classes, providing us with a solid, faster and more compact replacement (not to mention complete.)  The only downside to dropping this section is that we no longer have an XML solution.  The newer Importer/Exporter framework would make an excellent base for such a solution though, so pushing away from the older format should provide some push to get someone writing that.
  3. TextureKey.LocationOverride - This interface is gone - replaced with the ResourceLocator and ResourceLocatorTool.  See below for more details.
  4. com.jme.util.LoggingSystem and com.jme.util.ErrorManager - These classes have been replaced by MrCoders recent work unifying the logging calls in jME.
  5. Also a ton of old data files were removed in jme/data.  CVS syncing and checkouts should now be faster.

    Ok, so new additions and changes:

  6. Texture.anisoLevel - is now a percent (0.0f -> 1.0f) representing a range from no aniso filtering up to the max aniso level supported by the user's card.  Additionally, you can now change aniso level after creating your texture if you so choose.
  7. Texture parameters now use the various unit caps (fixed, fragment texs, fragment coords, etc.) to determine which texture calls are allowed to be called on a given card.  This change should result in less errors when using several textures at once on older cards.  See jmetest.renderer.state.TestShaderTexturing for an example that uses 5 textures at once.
  8. TextureKeys do not hold filter settings anymore.  Filter settings can be changed at any time now, so they are no longer unique texture identifiers.
  9. com.jme.util.resource - A new set of util classes for making resource locating easier has been added to jme core.  Simply put, it allows you to register locator objects that describe where you want jME to look for specific resource types.  You can define your own custom types and your own custom locators if the provided ones do not suit you.  Look for another posting with more details.  One nice effect of this addition is that all model loaders now use it, so lost model textures can now be a thing of the past.
  10. Just to reiterate, all of the old ways of specifying a texture directory to a model loader are now replaced with the use of ResourceLocatorTool.  So read up on it, or check the jmetests to see what you need to change in your code.

    There will no doubt be questions about going from old systems to new, so please speak up.  We'll be releasing a "release candidate" soon so even if you do not use cvs, you'll be able to try things out and help us iron out bugs on the way to a final jME 1.0!

Way to go!  :lol:

With the advent of how to keep the forums maintainable threads, I was going to suggest a deprecation of many packages/classes to avoid many repeating questions (many of those asked by myself  ). This, however, is even better news, if we could just keep this info in the much-discussed FAQ so that n00bs and not-so-n00bs could have a starting point for the standard way of doing things, would be great.

Again, thanks a lot for these magnificent news.  :smiley:

renanse said:

The only downside to dropping this section is that we no longer have an XML solution.

:'( So that's the end of the blender xml exporter. I'll update the tutorials etc., so people are not trying to use it any more.
But I am looking ahead to updating later today, I have read about some performance increases elsewhere :D, let's see what those can do for my project!

Well, an XMLImporter/Exporter based on JmeImporter/Exporter would help there :slight_smile:

People that still want to use it can always add the needed files to their project, just cause they're removed from jME HEAD doesn't mean they blinked out of existance…

or am I missing something here? (I believe the old style xml/binary import/export code was completly independent of the rest of the code, no?)

Yes, that's true.  They may have to dust it off a little to make it work though.  (logging changes or something like that.)

Actually, you can still nab it from the nightly currently.