Eh? What am I missing, Jeff? On my SUSE 9.3 laptop with an ATI 9700 gfx card with the ATI drivers installed and with a 1.5.0_03 VM only one display mode is available according to the program you pasted (the current display mode, 1280x800). And the “Set Display” button is grayed out, indicating that isDisplayChangeSupported() returns false, as I said. And this machine does LWJGL display mode switching fine btw (since this is my main development machine).
Thats odd.
I have an NVidia chip on my system and I get a full range of mode options.
I dont suppose you have an NVidia system with the same kernel version as your ATI system to compare to?
How recent are your drivers? NVidia has generaly had better OGL drivers then ATI on Linux. (Though why yo ushould get it from lwjgl and not AWT is odd. Id be curious to comapre where theya re getting their infor from… )
I tried it on an NVIDIA system with upgraded drivers but the results were the same. LWJGL does switch mode correctly on that system, btw. Are you running a Mustang VM?
Display mode switching has nothing to do with OpenGL, so that’s why jogl and lwjgl differ in this aspect. They share the opengl code (GLX interface), but jogl relies on the AWT abilities, while LWJGL implements its own direct interface to the Xlib API+extensions.
Yeah Iam, how about you?
Im wondering if it has to do with display managers. Im running KDE. I can try spinning up gnome and do the same experiment…
JK
[quote][quote]Are you running a Mustang VM?
[/quote]
Yeah Iam, how about you?
[/quote]
Isn’t it more likely to be that then? From earlier in the thread:
So, mode switching is unavailable on linux on anything but pre-release JREs?
Missed the post.
So its a bug. and a bug thats fixed in Mustang.
That solves the question and gives the final answer: If you need it for older VMs, then due to the bug it looks like you need to go around (either with LWJGL’s native code or your own.) If you dont need to support older VMs then Mustang is out there now and AFAIHS works fine even if its pre-release. And I woudl guess it will be release by next J1 if not before.
But keep in mind that “older” VMs (<= 1.5.0) are the only ones you can distribute to your customers. So unless you’re a researcher, Mustang is not an option until it is released (of course, you can develop on mustang and hope it is released when your application is done).
[quote=“Jeff,post:26,topic:24486”]
Yes, because we all know how good Sun’s track record is with new major versions of the VM. 1.5.0 was a particularly sucessful release. :
They’re not the only ones that cock up… I just for my iMac last night and the Java 5.0 download from Apple is actually corrupted. Anyone know where I can get it from, and why it’s not fixed?
Cas
If I’m following this trail correctly, JOGL should be able to handle resolution swapping on Linux as well as it does on Windows if running a 1.5+ JVM, but is crippled on 1.4, correctl? Hmmm…
My only “anti-LWGL” concern is that it is hardware-only rendering. About 75% - 90% of my game is being designed really as just a standard 2D strategy game with only a couple parts that may take advantage of 3D capabilities. I know that most machines in the public hands now do perform accelerated 3D as hardware rendering and that by early next year it will be an even higher percentage, but, for example, the laptop I’m working on now does it’s 3D for Linux in software. Since 3D is not even the biggest feature of the game I hate to limit a target audience by requiring that. If this was a fast-paced shooter that’s an understandable target, but a trun-based simulation is very different story.
-Lawrence
There’s a flag you can set to allow LWJGL to not filter out non-HW display modes. It’s described in the ‘hidden switches.txt’ in the build IIRC.
no, it’s 1.6+ !
LWJGL supports software mode fine - we just fail unless you explicitly enable it via the [quote]-Dorg.lwjgl.opengl.Display.allowSoftwareOpenGL=true
[/quote]
VM property
Curse you, Orangy Tang! As soon as I think I found a technical reason to help me make my decision I am presented with a work around!!!
I guess I just need to set down this weekend and try some raw LWJGL stuff to see if it works on my three environments ( W2K and JDK 1.4, Linux w/ hardware acceleration and JDK 1.5, and Linux without hardware JDK 1.5 ).
-L
And curse you too, Matzon! 
-L
The two biggest differenes AFAIK between the APIs are these:
(1) JOGL requires AWT and is buitl with AWT more in mind. LWJGL does nto require AWT and may not integrate as well with it if you want that. (To be fair most games dont)
(2) LWJGL gies you a single integrated package with OGL, OpenAL support and input support. JOGL is designed to be used with OpenAL or Jinput if you want those, or any other chpice you make for those functions.
Note that recent LWJGL versions have got the AWTGLCanvas class to bridge AWT and LWJGL, and it works similar to the JOGL canvas. We don’t have the swing equivalent of GLJPanel, so the support is not as complete as jogl. In return you get to choose between SWT, AWT and the LWJGL internal implementation of fullscreen/windowed + pbuffer drawables.