GUI for jME

Hi all,

on Sunday I needed gui again: 1.) nui - it has nice ideas, but it’s neither maintained any more, nor rather complete. 2.) looked into bui - shrug c coding style - More complete in some areas, but…

So, I simply started to put something together… viola :smiley: - have a look yourself

Download this and save it into your jME folder (don’t extract).

Then start

java -Djava.library.path=./lib -jar

(jme jars must have been built to target folder)

Tell me what you think :) - do you like the theme?
I know it's not on the roadmap but any interests in making a jmex package from it?

That looks pretty good. I'm all for an official GUI in jME, but as you know, two previously have failed to be maintained. If you can get this one stable and feature rich, I have no problem putting it in.

What do you think are the minimums needed for a GUI?

My list:

-Buttons (looks to be started)

-Checkbox (looks to be started)

-Combo box

-Progress bar

-Text Area (looks to be started)

-Panels for management (looks to be started)

-Easily set look and feel

-Scroll Pane

Also, it failed on my linux machine: JMEFrame.draw threw a OpenGLException (Invalid value: 1281)

I like it. Keep going.

I haven't looked at it yet, but I'm for an official jME GUI with the same reservations as Mark.  My only additional suggestion is that we keep it quiet and out of cvs until has a decent feature set.

Other things (may sorta be covered under mark's list)

  • Radiobuttons
  • Sliders
  • Tabbed panes (can be done with buttons and panels)

    Also, I believe our UI should be completely skinnable in every way including border colors, textures, fonts, etc.  In tribal trouble they use a single graphics file with all of the UI elements painted on it which seems like a great idea to me (just drop in another file to reskin.)  Of course, allowing for greater customization if possible.

    Finally, if we could configure with XML, that would be great.  I'd love to create a RenGUIEditor down the road.  :slight_smile:

:smiley: all the controls were already in yesterday. And when you look at the following screenshot you most probably know why: screenshot

As you can see, look and feels are there, too  :wink:

It’s bed time for me again, but I will tell you how it’s done (with two days work!) tomorrow - if you care . . .

Ok, you may have noticed the file size (45k) - no bitmaps or something in there… it is a Swing-adapter for jME!

It consists of three files at this time: JMEFrame, ImageGraphics and LWJGLImageGraphics which is an implementation of ImageGraphics (most of the files in the jar are the additional l&f). JMEFrame is a quad with a texture that displays the contents of a JDesktopPane. ImageGraphics is used as Graphics2D to allow Swing to draw on jME image data. In the update(Texture) method the dirty regions of the offscreen image are copied into a texture.

I have updated the file to show a button for changing the l&f and for showing the additional components. It also contains the source now. The strange l&f that shows a little bit of text only is a Synth l&f described by this xml snippet:

      <style id="button">
        <font name="Monospaced" size="24" style="BOLD"/>
        <state value="MOUSE_OVER">
          <font name="Serif" size="48" style="ITALIC"/>
      <bind style="button" type="region" key="Button"/>

We could use Synth to define a l&f to support bui themes...

The obvious drawback of using Swing is that it creates a lot of garbage that has to be collected. So you might decide to avoid encouraging users to use it. But it really saves us many hours of work for creating a gui...

Ah, nearly forgot the error - Mark, could you please execute the new file and send me part of the output (especially the lines with "Error updating dirty region: …"

I guess it is because the driver for the card in that system does not support certain sizes of subtextures that are updated.

Amazing… I did something simulair in the past (painting a JInternalFrame on a Texture using BufferImage). I never went as far as solving the input problem though, didn't have transparancy, no optimized drawing, etc. (it was in my early jME days and I was just trying some things).

I definatly think this is the way forward for a GUI. Finally Sun's lightweight widgets seem to be good for something after all.

While it might be a bit slow for a GUI (it was on my old machine, like most Swing GUIs), I think for a gaming GUI it's more than ok. Also, if someone would really want to, they could write a jME optimized Graphics2D implementation. Swing of course is extremly flexible for themes. You can write one from scratch, or use existing ones that support simple skinning, or oyoaha which is vector based and thus well matched for use on different screen resolutions. Plus most people already know Swing.

Also I wouldn't worry too much about the garbage… The only thing that will generate a lot of garbage are the mouse listeners, and in most cases you won't really need those (only when you click). And even if you do use them, for a game with a "mouse pointer" GUI a very constant and high framerate is not the most important thing anyway.

How does this affect us in terms of reliance on things we are trying to avoid reliance on like awt?  I like the reusability of knowledge already held in Swing, but are we prepared to tie our core to Swing?  At the least we'll still need to keep it in jmex.

Ah, nearly forgot the error - Mark, could you please execute the new file and send me part of the output (especially the lines with "Error updating dirty region: ..."
I guess it is because the driver for the card in that system does not support certain sizes of subtextures that are updated.

irrisor, I didn't see anything about updating dirty region, but here's the complete output. It will give you a line number at least.

mpowell@Dellbert:~/jme$ java -Djava.library.path=lib -jar
Oct 19, 2005 9:22:02 AM start
INFO: Application started.
Oct 19, 2005 9:22:03 AM com.jme.system.PropertiesIO <init>
INFO: PropertiesIO created
Oct 19, 2005 9:22:03 AM com.jme.system.PropertiesIO load
INFO: Read properties
Oct 19, 2005 9:22:03 AM com.jme.input.joystick.lwjgl.LWJGLJoystickInput <init>
WARNING: Initalizing joystick support failed: org.lwjgl.LWJGLException: Failed to initialise controllers
Oct 19, 2005 9:22:03 AM com.jme.system.lwjgl.LWJGLDisplaySystem <init>
INFO: LWJGL Display System created.
Oct 19, 2005 9:22:05 AM com.jme.renderer.lwjgl.LWJGLRenderer <init>
INFO: LWJGLRenderer created. W:  640H: 480
Oct 19, 2005 9:22:05 AM com.jme.renderer.AbstractCamera <init>
INFO: Camera created.
Oct 19, 2005 9:22:05 AM com.jme.util.lwjgl.LWJGLTimer <init>
INFO: Timer resolution: 1000 ticks per second
Oct 19, 2005 9:22:05 AM com.jme.scene.Node <init>
INFO: Node created.
Oct 19, 2005 9:22:05 AM com.jme.scene.Node <init>
INFO: Node created.
Oct 19, 2005 9:22:05 AM com.jme.scene.Node attachChild
INFO: Child (FPS label) attached to this node (FPS node)
Oct 19, 2005 9:22:06 AM com.jme.scene.Node attachChild
INFO: Child (test frame) attached to this node (rootNode)
Oct 19, 2005 9:22:07 AM com.jme.scene.Node attachChild
INFO: Child (spinning box) attached to this node (rootNode)
org.lwjgl.opengl.OpenGLException: Invalid value (1281)
        at org.lwjgl.opengl.Util.checkGLError(
        at com.jmex.swingquad.LWJGLImageGraphics.update(
        at com.jmex.swingquad.ImageGraphics.update(
        at com.jmex.swingquad.JMEFrame.draw(
        at com.jme.scene.Spatial.onDraw(Unknown Source)
        at com.jme.scene.Node.draw(Unknown Source)
        at com.jme.scene.Spatial.onDraw(Unknown Source)
        at com.jme.renderer.lwjgl.LWJGLRenderer.draw(Unknown Source)
        at Source)
        at Source)
        at jmetest.swingquad.TestJMEFrame.main(
Oct 19, 2005 9:22:08 AM cleanup
INFO: Cleaning up resources.
Oct 19, 2005 9:22:08 AM start
INFO: Application ending.

Yes, I would definately vote for a jmex package if it goes into jME. And we would rely on swing only for the gui - instead of having no gui (or only third party).

Btw. we still have awt dependencies in the core (Image, Canvas, Dialogs)

Concerning the error: that's strange - the check before upload of the image data fails. This most probably means the texture setup fails - unsupported format, or size… strange  :?

Image is 1024x512, texture object creation looks like this:

        texture = new Texture( 0.4f );
        texture.setCorrection( Texture.CM_PERSPECTIVE );
        texture.setFilter( Texture.FM_LINEAR );
        texture.setImage( graphics.getImage() );
        texture.setMipmapState( Texture.MM_NONE );
        texture.setWrap( Texture.WM_WRAP_S_WRAP_T );

Can that be a problem (e.g. specifying aniso level) ?

Yeah, I mentioned that we needed to eval and move those in another thread regarding my creation of jmex.awt

Regarding aniso, am I remembering right that aniso is only 1, 2, 4, etc?

renanse said:

Regarding aniso, am I remembering right that aniso is only 1, 2, 4, etc?

um, well, that would definately explain it. Windows should have complained, too...

I have removed the parameter - please test again, Mark.

I like the screenshot btw, reminds me of Sun's lookingglass project.  (  We might even get a few more interested folks from Sun if we put a demo or two together that looked similar :slight_smile:

Still failed on my linux box, this time on line 109 instead of 110. So, guess it's not the ansio.

I have intensively tested the gui stuff on some linux boxes and it works well. Seems to be a problem with the specific card  :expressionless:

This brings me to another point: I'd like to put it in CVS somewhere - should I create a separate project or do you want it in jME CVS? (I have no problem with making a separate project, but I would like to keep it seperated once it was in an own CVS.) After I have checked it in somewhere I people could test it to get it stable.

Btw. my students will use this swing binding in their project this term so it should get quite usable…

why don't we put it under com.jmex.awt ?

I don't have a problem with it being put into CVS if it's not working on all machines yet. We can work out those little issues before 0.10 is out.

awt makes sense to me.

OK, created an issue to commit against.

The important class would be named com.jmex.awt.swingui.JMEDesktop which has a method getJDesktop().

Any better ideas?

Sounds good.  How functional is it?  (Sorry, too lazy/busy to play with the jar)  Can you interact with Swing's action listeners and such?