gl.create() problems - mode not supported

I’ve copied code nearly exactly from several of the tutorials I’ve seen on this site. The only problem is anytime I try to do a gl.create() I get the following exception:

java.lang.Exception: Mode not supported by hardware
      at org.lwjgl.opengl.BaseGL.nCreate(Native Method)
      at org.lwjgl.opengl.BaseGL.doCreate(Unknown Source)
      at org.lwjgl.opengl.GL.doCreate(Unknown Source)
      at org.lwjgl.Window.create(Unknown Source)
      at com.rn.artillery.Tutorial.initialize(Tutorial.java:37)
      at com.rn.artillery.Tutorial.execute(Tutorial.java:23)
      at com.rn.artillery.Tutorial.main(Tutorial.java:245)

Here’s the relevant code:

  private void initialize()
  {
    try
    {
      mode=findDisplayMode(800,600,16);

      System.out.println(mode.width+","+mode.height+","+mode.bpp+","+mode.freq);
      
      gl=new GL("Test", 50,50,mode.width,mode.height,mode.bpp,0,0,0);
      gl.create();
      glu=new GLU(gl);

      glInit();

      Keyboard.create();
      quadPosition = new Vector2f(100f,100f);
      quadVelocity = new Vector2f(1.0f,1.0f);
    }
    catch (Exception e)
    {
      e.printStackTrace();
    }
  }

  private DisplayMode findDisplayMode(int width, int height, int bpp)
  {
    DisplayMode[] modes = Display.getAvailableDisplayModes();
    for(int loop=0; loop<modes.length; loop++)
    {
      if(modes[loop].width==width
        && modes[loop].height==height
        && modes[loop].bpp>=bpp
        && modes[loop].freq==60)
          return modes[loop];
    }
    return null;
  }

Any help anybody? I KNOW the particular mode IS supported, so I don’t think that’s it. Sorry for a newless clewbie type question, but this has got me stumped.

Hm thats just pain odd…
platform?
whats the output from using the -ea switch?
Whats the output from:

  System.out.println(mode.width+","+mode.height+","+mode.bpp+","+mode.freq ); 

?

Well, here’s raw output for you: with the -ea switch:

Removed 0 duplicate displaymodes
800,600,16,60  //That's my System.out.println you were asking about
java.lang.Exception: Mode not supported by hardware
      at org.lwjgl.opengl.BaseGL.nCreate(Native Method)
      at org.lwjgl.opengl.BaseGL.doCreate(Unknown Source)
      at org.lwjgl.opengl.GL.doCreate(Unknown Source)
      at org.lwjgl.Window.create(Unknown Source)
      at com.rn.artillery.Tutorial.initialize(Tutorial.java:37)
      at com.rn.artillery.Tutorial.execute(Tutorial.java:23)
      at com.rn.artillery.Tutorial.main(Tutorial.java:245)
Selecting NT display mode check
Querying Real 3D Starfighter device
Querying NetMeeting driver device
Found 49 displaymodes
Window registered
Created window
Pixel format is 4
Destroying directinput
Releasing DC
Destroy window
Destroyed window
Debugger disconnected from local process.
Process exited with exit code 0.

Helpful?

-Nate

I noticed this line:

Querying NetMeeting driver device

Do you have net meeting running? Net meeting will disable Hardware acceleration, which may be what is causing the Display Mode not to be found.

Thats not the problem - it is always being queried - all devices are. I am looking into it…

Can you run the tests from the distribution?

[quote]Do you have net meeting running?
[/quote]
Not that I know of. I don’t even know what that is. This is a work computer, so they could have anything on it. rolls eyes Just kind of playing around with this stuff on lunch hours to prep for the REAL development at home.

Yeah . . . that’s what I’m doing. :wink:

Seriously, though. Went through the list of services and the ‘NetMeeting Remote’ service wasn’t running.

Also forgot platform. I’m running Win2k on a box with . . . 600+MB RAM, and even though the case is stamped with a Pentium III logo, I think it’s a P2 . . . couldn’t tell you what speed, and a piece of crap graphics card that streteches the definition of “accelleration”

Here’s output from WindowCreationTest.class

Removed 0 duplicate displaymodes
Found 49 display modes
java.lang.Exception: Mode not supported by hardware
      at org.lwjgl.opengl.BaseGL.nCreate(Native Method)
      at org.lwjgl.opengl.BaseGL.doCreate(Unknown Source)
      at org.lwjgl.opengl.GL.doCreate(Unknown Source)
      at org.lwjgl.Window.create(Unknown Source)
      at org.lwjgl.test.WindowCreationTest.main(Unknown Source)Display created

Then it hangs. :-/ I have to kill it manually.

(edited to add —)
FullScreenWindowedTest.class has similar output I can post that if you need it.

lol - wtf is going on - You do have a Graphics card installed? ;D

I am think that this has something to do with it:

[quote]and a piece of crap graphics card that streteches the definition of “accelleration”
[/quote]
Does it run OpenGL applications at all?
Try this application:
http://www.realtech-vr.com/glview/

does that shed some light on the issue?

Okay . . . I’m saved from feeling like a COMPLETE idiot . . .

Tested OpenGL . . . saw the nifty spinning cube and everything. I KNEW I’d used OpenGL stuff before.

But that was for OpenGL1.1 interfaces. When it got to 1.2 interfaces it freaked out.

In the report section it says: “No Hardware Support”

Is that mandatory for LWJGL to run?

Here’s all the stuff my system DOESN’T support.

-No hardware support
-No compiled vertex array.
-No 8bit palette texture support.
-No multitexturing extension.
-No secondary color support.
-No S3TC compression support.
-No Texture Edge Clamp extension.
-No vertex program extension found
-No Fragment program extension found.
-No ICD Registry Entry.
-Few texture units found.

Like I said . . . crappy, but I’m positive I’ve at least done BASIC openGL stuff before . . . I think. I’m gonna feel like a twit if this is really the problem. (Mebbe it was D3D . . . hmm)

(edited to add --)
Hmm . . . looks like it might be defaulting to some standard Microsoft software OpenGL renderer . . . which would explain why that spinning cube was rendering at a whopping 3 fps. ::slight_smile:

Who needs fast . . . and if it doesn’t work at all . . . well . . . so be it. I’ll wait 'til Sept. when we get new workstations.

heh - AFAIK, it should fail gracefully. But I have never tested it - my hardware is to new 8)

In any event, the error message could be much more constructive - I’ll see what we can do about it… in the mean time, do you have any other somewhat similar workstations, you could test?

If I am not mistaking, shouldn’t all windows implementations have a SW GL mode? ponder

[quote]in the mean time, do you have any other somewhat similar workstations, you could test?
[/quote]
Unfortunately no. I’ve been pushing hard for better equipment . . . at LEAST a dual monitor setup . . . but to no avail (I’m the ONLY developer w/o one >:( ). Fortunately, we FINALLY get to requisition new stuff in June, but then there’s a mandatory 90 day delay. Damn the state budgets. >:(

As for hijacking someone else’s computer for a bit . . . mebbe, but doubtful. IS Dept would freak already if they saw half the stuff I have installed on THIS one. One of the perks of being a developer . . . they rarely check. :slight_smile:

Lemme know if there’s any other info you need.

-Nate

This is a graceful failure! It says exactly what the problem is in the exception - the mode’s not supported by hardware and LWJGL is a hardware acceleration API only!

So you’re stuffed :slight_smile: Sorry!

Cas :slight_smile:

[quote]LWJGL is a hardware acceleration API only!
[/quote]
Truly?! Why . . . how could I have missed that? :frowning:

Okay . . . that sux. Are there PLANS to extend to software rendering? Maybe . . . pleeeeease.

sigh Mebbe I’ll just switch to GL4Java or something . . . at least if they support software rendering I might. Or maybe I’ll use GL4J for software and LWJGL for hardware.

:’(

LWJGL is a hardware acceleration API only!

Can you say exactly what you mean here Cas? I know that LWJGL was intentionally only written for games, etc… but shouldn’t it just be able to use whatever OpenGL driver is installed? As long as the driver is fully functional there shouldn’t be any problems - well, except that you’ll get slow rendering…

For example, shouldn’t I be able to use LWJGL with Mesa software rendering? If not, why not?

God bless,
-Toby Reyelts

It was a deliberate filter on Win32 to barf on modes that it claimed were allowed but which would give you 3fps. You might ask for a stencil buffer for example and it would happily give you one but punt you back to software rendering which is exactly what you don’t want - for a game library.

Cas :slight_smile:

Hmm, if this is a work computer we’re talking about maybe you’ve got matlab installed?

I had problems with my opengl disappearing when “matlabs webserver” was running (auto-run sigh) - when I stopped that service (and all other matlab related background services) everything worked ™ again ;D

Not sure if this is any help to you - but I thought there is a small chance :-/

[quote]It was a deliberate filter on Win32 to barf on modes that it claimed were allowed but which would give you 3fps.
[/quote]
Well, that makes sense, but would it make sense to simply set flags that indicate feature X is not available in hardware, then leave it up to the programmer to actually pay attention? That way, dudes like me, who are just using OpenGL for 2D stuff have more portability options. Personally, I don’t like Java2D. Using LWJGL would be really nice, but if by default I can only run my simple non-processor-intensive games on hardware accellerated boxes, suddenly I’m having to look at other alternatives.

Yes, that’s what programming’s all about, I realize that, but adding that feature seems to keep with the ‘lightweight’ spirit of what you all are doing while adding a potentially useful feature . . . software only rendering.

It’s just a thought, though.

And a thought it shall remain :slight_smile:
We mustn’t lose our focus which is for a high performance Java games platform. On Win32 this means hardware acceleration as the only alternative is Microsoft’s stunningly slow GL implementation. You can barely do a couple of sprites with it before it’s too slow to be worth using.

If it’s really so important to use software GL then recompile the native lib and take out the check. But for normal purposes it’s not going to help anyone deliver what they want to deliver, which is fast graphics. Which is why you’re using LWJGL in the first place, right?

Cas :slight_smile:

But for normal purposes it’s not going to help anyone deliver what they want to deliver, which is fast graphics. Which is why you’re using LWJGL in the first place, right?

No, people might want to be using LWJGL simply because it’s the most up-to-date Java binding for OpenGL.

Addendum: As an example, DirectDraw/Direct3D’s sole purpose is as a high-performance graphics API, yet it allows you to perform capability queries against the driver.

God bless,
-Toby Reyelts

[quote]We mustn’t lose our focus which is for a high performance Java games platform.
[/quote]
Ah, to have such attitudes here where I work. Every day is a new adventure in atrocious planning, mangled code and major rewrites. God forbid the whole PURPOSE of each project might actually stay the same from day to day. It’s always “MORE FUNCTIONALITY! WOOHOO!”

I truly admire such a focused effort as y’all are putting into this. So . . . I guess hardware only, it is! :’(

-Nate