jME 0.7

jME 0.7 is released.

New Features:

Model loading has been revamped. The only model format supported by jME is .jme, it’s internal format. However, there now exists many exporters to convert formats, including: ASE, 3DS, MD2, MD3, Milkshape, and OBJ.

Render Queue has been added. Now scene nodes can be tagged as either opaque objects, transparent objects, or screen objects. The queue will then order the objects for proper rendering. Those tagged as opaque will be rendered first (front to back), those tagged as transparent will be rendered next (back to front), last screen elements will be rendered.

Pixel shader support has been added with the Fragment Program state.

Game UI has been added. Meant as a compliment to the widget library, the UI code allows for quick creation of game menus and in game displays.

Many bug fixes and optimizations have also been made.

Documentation has been improved, javadoc of existing code has been greatly improved. A Starter’s Guide rough draft has been written, to give a very in depth tutorial on the features of jME.

Relevant links:

downloads: https://jme.dev.java.net/servlets/ProjectDocumentList?folderID=0&expandFolder=0&folderID=148

Starter’s Guide: http://www.mojomonkeycoding.com/beginner/Starter.pdf

Javadoc: http://www.mojomonkeycoding.com/doc

Webstart Tech Demos: http://www.mojomonkeycoding.com/index.php?option=content&task=view&id=10&Itemid=33

Linux users, please let me know if you have trouble with the webstart links.

Just an FYI, we are still using LWJGL .9 since 1.0 hasn’t been officially released yet…

  1. Anisotropic worked fine, as did one of the terrain tests (didn’t bother trying them all; they seemed to be working OK) - glad to see the problem with claimed inability to change screen mode has disappeared.

  2. However, the brick wall bumpmapping just crashed, killing the JVM.

Hang on, no - it didn’t. Instead it printed something to stdout and system.exited. You need to fix that! Look what it printed:

jmetest.renderer.state.TestFragmentProgramState simpleInitGame
SEVERE: Your graphics card does not support vertex or fragment programs, and thus cannot run this test.

(time to invest in a popup dialog box methinks!)

  1. STOP STEALING THE MOUSE CURSOR! (perhaps this only happens on linux, but you disable the cursor and then procede to steal all mouse events which is a VERY bad thing to do on a windowed OS…). My guess is that this is just oversight - you didn’t test your app in windowed mode and didn’t realise what would happen to anyone who did ;D.
  1. Great, display settings now only show ones that WILL work on your machine…

  2. Noted.

  3. How would you suggest handling mouse look? Setting the mouse position back to the center is the only way to do this properly. I.e. using a relative mouse rather than absolute.

Sorry, I don’t have an easy answer - it’s something I’ve pondered myself quite often.

However, for these demos, I’d suggest implementing mouse look only during drags, as this is a semi-standard way of doing it - and these demos you generally don’t need to move around much compared to say Quake3 deathmatch :slight_smile: so you can probably happily put up with the click-drag requirement as a user.

PS something that would be very cool in each demo (which I thought you used to have?) would be an info-readout like a HUD, or else a text-message area at one edge, with instructions appearing in it - or just picking messages from a list, and displaying one at a time. I’m just thinking of something where each demo would instantiate a String[] with the messages it wanted to display.

Main reason is to give some reminders of the possible controls for each demo (the title bar approach is nice, but … not very clear when you have large fonts like me, and many people don’t ever look at the titlebars of their apps anyway).

Oh, and because it would look cool ;).

Toggle it on/off with a key press. By default, display the cursor and use the keyboard to rotate the view. If the user wants to activate mouselook they can.