PropertiesDialog Update

I’ve overhauled the PropertiesDialog and committed a preliminary implementation to CVS. It’s currently bound to lwjgl but a renderer agnostic version is coming soon. So, what’s new?

  • all supported resolutions and accompanying bit depths and refresh rates are listed
  • tighter controls on display mode selection; prevents a user from selecting a mode that is invalid
  • running in windowed mode verifies that the requested bit depth is lesser than or equal to the desktop's current bit depth
  • code has been cleaned up and refactored
    Comments? Suggestions? Ideas? I' love to hear 'em!

    For the future, I'm thinking of adding a "debug" tab to the dialog for advanced options. Things like enabling anti-aliasing, VBO, and other effects. Perhaps also control over brightness, contrast and gamma.

Currently the settings dialog is only about setting display properties. I have written my own setup dialog, since I needed more things like assigning keys to actions and (later, when it is available) setting sound options. Is it a good idea to have things like key assignment to actions and sound settings centralized in a setup dialog, too? The syntax for the key assignments should be fixed then and there should probably be a class which can interpret the assignments from the property and place them in the KeyBindingManager.

In general, the properties thing could be something extendable.

Another thing, you are now displaying all possible resolutions. I personally do not want to have resolutions below 800x600 available in my game since I would have to provide more textures and layouts for my menus. Would it be a good idea to have a low (and high) watermark for resolutions? Same is true for depth btw.

As I said on IM, I think this is a great addition. I’m anxious to hear reports on how well it works in Linux and Mac. As for other additions, I think it would be great if the dialog worked as a pluggable container for jME and custom written config panels. The basic, out of the box panel would be as you have it, and jME could include other panels, like the debug one you mention, an audio one, etc. which could be added as desired by the developer to the basic dialog. Similarly, the developer could put together their own panels and add in those.

my two cents…

You know what would be absolutely fantastic? a little TextArea to display all those LoggingSystem.getLogger().log calls. Just like MoH. :slight_smile:


I’ve updated the PropertiesDialog to be completely renderer agnostic. It now relies on Java 1.4 features to query available display modes instead of lwjgl. Also, the dialog will ignore any bit depths below 16 as they are incorretly reported to Java as being valid.

Here comes the linux report :frowning:

(suse 9.1 with todays cvs)

On the select display settings dialog i only get one choice for resulution (the currently active) and no choice (emty box) for color depth.

I try to run in windowed mode which was no problem with various resolutions with the old dialog.

Choosing OK with this gives me:

02.07.2004 21:41:57 start

INFO: Application started.

02.07.2004 21:41:57 com.jme.system.PropertiesIO <init>

INFO: PropertiesIO created

02.07.2004 21:41:57 com.jme.system.PropertiesIO load

INFO: Read properties


at com.jme.system.PropertiesDialog2.verifyAndSaveCurrentSelection(Unknown Source)

at com.jme.system.PropertiesDialog2.access$100(Unknown Source)

at com.jme.system.PropertiesDialog2$2.actionPerformed(Unknown Source)

at javax.swing.AbstractButton.fireActionPerformed(

at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(

at javax.swing.DefaultButtonModel.fireActionPerformed(

at javax.swing.DefaultButtonModel.setPressed(

at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(

at java.awt.Component.processMouseEvent(

at java.awt.Component.processEvent(

at java.awt.Container.processEvent(

at java.awt.Component.dispatchEventImpl(

at java.awt.Container.dispatchEventImpl(

at java.awt.Component.dispatchEvent(

at java.awt.LightweightDispatcher.retargetMouseEvent(

at java.awt.LightweightDispatcher.processMouseEvent(

at java.awt.LightweightDispatcher.dispatchEvent(

at java.awt.Container.dispatchEventImpl(

at java.awt.Window.dispatchEventImpl(

at java.awt.Component.dispatchEvent(

at java.awt.EventQueue.dispatchEvent(

at java.awt.EventDispatchThread.pumpOneEventForHierarchy(

at java.awt.EventDispatchThread.pumpEventsForHierarchy(

at java.awt.EventDispatchThread.pumpEvents(

at java.awt.EventDispatchThread.pumpEvents(


Blast and bother. I had a sinking feeling it’d come to this.

Could you do me a favour winkman? Grab the latest files from CVS, and change the reference to PropertiesDialog2 in to LWJGLPropertiesDialog. You’ll also need to appropriately alter the import statement. That done, try again! :slight_smile: See if it works correctly at that point.

If the LWJGL version works correctly, it is the fault of GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDisplayModes() not returning correct values. Hmm… though I may have a solution. Once my Fedora Core 2 box is properly configured I can test at home.

Did it and you are right, when PropertiesDialog2 is changed to PropertiesDialog then all behavior is as ever was.

Strange LWJGLPropertiesDialog was not found ??

Okay this was a typo so i rechecked this and found that LWJGLPropertiesDialog too has an issue.

It shows lots of resolutions which look reasonable to me and it only presents the correct bit-depht (24) but wenn i click ok for windowed mode i get the message that i cant select a mode other than my current desktop mode (which is 24)

Fullscreen works well.

EDIT: sorry the exact message was:

"Cannot choose a higher bit depth in windowed mode than your current desktop bit depth"

Great, thanks for the information. It pretty much confirms my fears that GraphicsEnvironment.getLocalGraphicsEnvironment().blah is completely and utterly broken under Linux. Grr.

If you want to remove that bit depth check for windowed mode, in com.jme.system.LWJGLPropertiesDialog remove the if(!fullscreen){} block in verifyAndSaveCurrentSelection(). It should then work perfectly under Linux if you prefer the new dialog - which I hope you do! :slight_smile:

I suppose I’ll now need an alternative for querying the possible display modes in Linux (and perhaps Mac as well!). I’d appreciate any suggestions! The only requirement is that it does not rely on any external library.

I noticed that the bit-depth returned from …getDisplayModes().getDepth() ? always seem to be -1 on my box ?

So maybe a workaround for the moment could be to present the old Dialog with few but working choices if the result of …getDisplayModes() seem to be not reasonable until there is a better solution (maybe it works in java 1.5 ?)