LWJGL

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Disable OpenGL temporarily for testing  (Read 2842 times)

molzb

  • Newbie
  • *
  • Offline Offline
  • Posts: 8
Disable OpenGL temporarily for testing
« on: January 31, 2011, 16:02:34 »

Hi!

My applet (2D and 3D, 2D can run separately without 3D) has a
printing feature. In case the graphics card doesn't support
OpenGL, I would like to disable printing (i.e. making an Image object
with the OffScreenRenderer) and degrade gracefully.

What is the preferred way to disable OpenGL temporarily?
So I can check where I have to make changes when there
is a graphics card with no OpenGL.

If there's a flag which I can set to disable OpenGL would be
perfect. I don't want to remove my graphics driver or worse.

Thanks and regards,
Bernd
Logged

kappa

  • Administrator
  • Nerdus Imperius
  • *****
  • Offline Offline
  • Posts: 1194
Re: Disable OpenGL temporarily for testing
« Reply #1 on: January 31, 2011, 16:07:03 »

yes its possible, see hidden switches page.

So you'd want to use the VM parameter -Dorg.lwjgl.opengl.Display.allowSoftwareOpenGL=true to allow software mode.
Logged

Fool Running

  • Nerdus Imperius
  • *****
  • Offline Offline
  • Posts: 828
Re: Disable OpenGL temporarily for testing
« Reply #2 on: January 31, 2011, 18:00:27 »

So you'd want to use the VM parameter -Dorg.lwjgl.opengl.Display.allowSoftwareOpenGL=true to allow software mode.
That will only allow a fallback to the software renderer if a hardware renderer is not found (by default it will throw an exception, I think). In molzb's case, he wants to force LWJGL into thinking that there is not a hardware accelerated renderer which I don't think you can do through LWJGL.
You might be able to set the acceleration of your graphics to be none (in the control panel in Windows) assuming you aren't using Linux/Mac.
Another idea is to try a virtual machine with no hardware acceleration turned on. ;D

Otherwise, just force your software to take the different code path.
Logged
Programmers will, one day, rule the world... and the world won't notice until its too late.Just testing the marquee option ;D

molzb

  • Newbie
  • *
  • Offline Offline
  • Posts: 8
Re: Disable OpenGL temporarily for testing
« Reply #3 on: February 01, 2011, 08:37:15 »

So you'd want to use the VM parameter -Dorg.lwjgl.opengl.Display.allowSoftwareOpenGL=true to allow software mode.
That will only allow a fallback to the software renderer if a hardware renderer is not found (by default it will throw an exception, I think). In molzb's case, he wants to force LWJGL into thinking that there is not a hardware accelerated renderer which I don't think you can do through LWJGL.
You might be able to set the acceleration of your graphics to be none (in the control panel in Windows) assuming you aren't using Linux/Mac.
Another idea is to try a virtual machine with no hardware acceleration turned on. ;D

Otherwise, just force your software to take the different code path.

Thanks to you both. This is leading into the right direction.

Software mode works for me, I saw it because in my applet
there was no antialiasing any more (in hardware mode there
is antialiasing).

Which leads to the question: If no hardware renderer is found,
can I just set
System.setProperty("org.lwjgl.opengl.Display.allowSoftwareOpenGL", "true")
and force software rendering?
Is there a subtle way to find out if a hardware renderer is existing
other than catching an exception?

We are making tests to run our LWJGL applet on a linux netbook
without hardware acceleration. But I am programming on Windows
and want to emulate that case.

Ok, I'm gonny try it out now.

Bernd
Logged

kappa

  • Administrator
  • Nerdus Imperius
  • *****
  • Offline Offline
  • Posts: 1194
Re: Disable OpenGL temporarily for testing
« Reply #4 on: February 01, 2011, 10:32:52 »

don't think there is a way to check whether there is a hardware renderer without catching an exception. LWJGL explicitly disables the software renderer fallback as it is pretty useless in most cases.

You best bet is to do a Display.create() inside a try catch and when it fails with a pixel format error, set Software Mode and try Display.create() again.
Logged