Linux & JME

Troubleshooting General Help
1

All,



I’m in process of getting a new linux box set up to work on JME with (I specifically bought the machine for development). Developing in Windows is kind of a pain in the neck… and in general, I want to support the Linux/open-source community by making sure my games will run on Linux.



I saw in the ‘Releases’ forum about 0.7 that jME is not working on Linux right now because of the PropertiesDialog2. (I didn’t want to clutter up the release posts with a question there.)



Can somebody elaborate on that problem and how it affects things?



I think Eric said something about this issue being fixed with Java 5 (1.5)?



Are there any other Linux-specific issues I should know about?



Thanks,



–K

2

I don’t see the dialog box issue on my home linux box ?? have to check if this is because i made a code change some time back and that gets merged in automatically by cvs - update somehow ?? really should RTFM for cvs someday :slight_smile:



Other than that jme runs mostly fine but with somewhat lower fps than reported from the windows users.



Ah and i’d go for an nvidia - graphics card if using 3d on linux as the drivers most of the time worked for me out of the box and with any card since Geforce2.



my machine specs:

AMD XP 1800+ with GeforceFX 5900 XT and 512 MB RAM

linux is SUSE 9.1 Pro and my IDE is NetBeans





regards

Martin

3

Hello,



with the current cvs version, the call to PropertiesDialog2 class would fail on linux (the dialog will crash after you confirm your settings).



there’s a very simple workaround :



edit AbstractGame.java



Find the line 181 :


PropertiesDialog2 dialog = new PropertiesDialog2(properties, dialogImage);



change into :


PropertiesDialog dialog = new PropertiesDialog(properties, dialogImage);



change the import com.jme.system.PropertiesDialog2; line in
import com.jme.system.PropertiesDialog;

and that's ok you are using the old dialog which works on both plateform.

I understand in the 0.7 release topic that Eric knows a better workaround (with modifying dialog2 itself) but i don't know the fix.

for me there's no other pb with linux and jme (i don't run all the test, but those i tried run fine and smooth)

bye,

adenthar.
4

Just at thought, does jME webstarts correctly under linux?



Cause ive heard rumours/speculations that AWT grabs all the input and doesn’t release it to LWJGL.



DP

5
"DarkProphet" wrote:
Just at thought, does jME webstarts correctly under linux?

Cause ive heard rumours/speculations that AWT grabs all the input and doesn't release it to LWJGL.

DP

That is in mac, I think.
6

OK, time for some clarificication:

  • The new style of PropertiesDialog relies on being able to query a list of all supported display modes for the default display device.
  • The getDefaultScreenDevice().getDisplayModes() method in Java 1.4.2 is apparently broken on Linux (and perhaps also Mac), thus wreaking havok with the new dialog.
  • I'm hoping, really hoping, that Java 5 fixes the aforementioned broken method.
  • LWJGL provides the same functionality, which is guaranteed to work cross-platform. Simply change all references to PropertiesDialog2 in AbstractGame to LWJGLPropertiesDialog to use it instead.
  • My suggestion for 0.7 is to use LWJGLPropertiesDialog as it's guaranteed to work and supporting jogl is not a priority now.
  • I'm opposed to reverting to the original dialog since it reintroduces all the problems (detailed elsewhere) the new version has fixed.
    [/list:u]
    Hopefully that sums everything up nicely.
7
My suggestion for 0.7 is to use LWJGLPropertiesDialog as it's guaranteed to work and supporting jogl is not a priority now.


I'm fine with that. If rolling back to the previous version is a worse option than using the LWJGL version, then use the LWJGL version. Just keep your eye on it for the 5 final release and if it's solved. If it's not a decision will have to be made.
8

Thanks for the explanation Eric,



I didn’t see LWJGLPropertiesDialog and didn’t know that PropertiesDialog had some problem ://



i’ve tried LWJGLPropertiesDialog and it works very well.



thanks again,



bye,



Adenthar

9

CVS has now been updated to use the LWJGLPropertiesDialog.



I agree with mojo that this is not a long-term solution. It will undoubtedly need to be reevaluated before 0.8 is released, or when Java 5 hits distribution.

10

Thanks for the explanation, Eric et all.



Regarding the method to query for supported display modes… What happens with that? Does the method just hurl? Would it be possible to just catch a runtime exception, and then pop up a warning that it will be running at 640x480 (since all systems that could possibly run jME should support this resolution… ie, anything built within the past 15 years)?



Not that that’s a great solution either… especially if LWJGL handles it just fine. It’s just a thought.





Ah and i'd go for an nvidia - graphics card if using 3d on linux as the drivers most of the time worked for me out of the box and with any card since Geforce2.


Thanks for the tip, winkman. I did buy a nVidia card specifically because it works better on Linux, particularly with 3D (I did my homework before ordering the parts). This is a good reference for anybody looking at this in the future, though.

My system specs:
Athlon XP 3200+, GeForce 5900XT, 1G RAM, 2x160GB Seagate SATA, on-board sound (from ASUS a7n8x-e deluxe, which has the nForce sound-storm stuff built in, suppoed to be pretty good), dual boot Windows XP / Suse 9.1 Pro. "IDE" will probably just be jEdit, but I won't know until I start using it. (Not a big fan of fancy IDEs.. I feel like they get in the way.)

For anybody considering something similar, be warned that the onboard SATA is kind of a pain in the neck. IMHO, it's really not ready for prime-time yet. (Case in point, I flashed my BIOS which updated the onboard SATA driver, and now I have to re-install Windows. Linux is still happy, though.) Just FYI.

Anyway.. It looks like Java 5 will be officially released pretty soon (within a few months, maybe?), so we'll see then. They've spent a long time on this guy, so hopefully it'll be solid right from the start.


--K
11
"Shmooh" wrote:
Regarding the method to query for supported display modes.. What happens with that? Does the method just hurl?
Unfortunately, the method fails silently. The method simply returns a very abbreviated list of resolutions (usually only the currently active resolution) and no associated colour depths. Attempting to query the desktop colour depth results in the not-so-helpful -1.

This is the worst type of broken: functionally useless, but not quite critically damaged. Grr.
12

Well color depth -1 seems not so bad to me as it is indicating at least that this is not a valid setting - and one could fall back to äh… some fallback in this case.



But i agree that the now choosen lwjgl solution is preferable for now.

13

Ok, i got a clean version from cvs now (i think) and have the following problem with the LWJGLPropertiesDialog:

Screen Resolutions and Colordepths are shown correctly and all runs well in fullscreen but when i choose to run in windowed mode then i get:

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



It’s obviously the same issue as discussed near the bottom of:

http://www.mojomonkeycoding.com/jmeforum/viewtopic.php?p=4389&highlight=#4389

I used mentioned workaround locally and never did a clean checkout from cvs so i never had problems with PropertiesDialogs since then.



If you want to make LWJGLPropertiesDialog runnable on linux without hassles then this has to be fixed in cvs to.

14

Ah, good catch! I had forgotten about that. New version committed to CVS.