LWJGL 0.9 released!

OpenGL Development
#1

LWJGL 0.9 has been released.

http://www.lwjgl.org/

stuff changed from 0.89 of the top of my head:

  • bug fixes
  • setGrabbed support for grabbing cursor, or showing OS cursor
  • Software OpenGL support via flag (mental note, document these)
  • win32 cursor animation (still only 1 bit cursor transparency on win32, will fix soon)
  • input now accumulates over multiple Window.updates
  • more extensions
  • automatic read of input, now you only need to call Window.update

Please follow: http://64.5.48.50/forums/viewtopic.php?p=3810 for comments on the 0.9 release

#2

Ah great :slight_smile:

Already thought about pushing that old 0.9 thread again, because 0.9 should be out somewere around easter. Heh. And there it is :wink:

#3

YES!
Thank You!

You have no idea how long I have awaited this release.
I’m so happy I could make love to you.

Though I do wish there was more documentation.

My previous LWJGL work doesn’t work in the current version.
My previous work was done in 0.8.

I have fixed up nearly everything since there was a lot of changes.
I love the new changes which split all the things out nicely so now navigation throughout the classes within the libraries is easier to follow.

After I get it sorted out it will be fine.

GL.glMatrixMode(GL.GL_PROJECTION); doesn’t work.

I cannot find the alternatives. I assumed they were under GL15 but it was not.

Just found it, it’s under GL11.

Since glMatrixMode is needed why not include other similar needed functions under a standard GL library rather than under a specific library version name?

#4

Cool, just installed it.

Pretty painless update for me, (but it’s not as if I’m taxing its capabilities), noticed the window disposal is a lot cleaner now. Cool though, hardly had to change a thing :slight_smile:

Great work guys ;D

#5

LWJGL 0.9 doesn’t work under Win NT 4. When i’m trying to create a window, everything seems to be fine (i.e. no Exceptions) but there’s simply no window visible and you can’t create textures or the keyboard. It worked fine in 0.8.

#6

hmm, we changed the detection of modes for 0.9 to be more failsafe - might have introduced a compatibility issue… I’ll just look around for an NT box - could you try outputting the number of modes found in the mean time?

#7

[quote]could you try outputting the number of modes found in the mean time?
[/quote]
I’ll do that tomorrow at work :wink: (If a trainstation is where the train stops, what’s a workstation? ;D)

#8

Here are the results: A lot of modes but still no window…not in fullscreen and not in windowed mode.


mode: 320/240/16/75
mode: 1024/768/32/120
mode: 1024/768/16/72
mode: 512/384/16/70
mode: 640/400/32/70
mode: 1600/1200/32/60
mode: 640/400/32/75
mode: 320/240/32/70
mode: 1280/1024/16/70
mode: 640/480/16/75
mode: 1024/768/32/85
mode: 1280/960/16/72
mode: 1280/960/32/75
mode: 800/600/32/70
mode: 1280/960/16/60
mode: 800/600/16/85
mode: 480/360/32/72
mode: 400/300/32/60
mode: 1024/768/16/75
mode: 320/200/32/72
mode: 800/600/32/100
mode: 800/600/32/120
mode: 800/600/16/72
mode: 1600/1200/16/75
mode: 1280/1024/16/75
mode: 1280/960/16/70
mode: 400/300/16/70
mode: 1280/1024/32/85
mode: 1280/960/16/100
mode: 1024/768/32/60
mode: 400/300/32/72
mode: 800/600/32/60
mode: 1600/1200/16/85
mode: 320/240/32/60
mode: 1280/1024/32/60
mode: 1600/1024/32/85
mode: 1152/864/32/120
mode: 1600/1200/16/100
mode: 1152/864/16/72
mode: 1600/1024/16/72
mode: 1600/1024/16/85
mode: 1280/960/32/85
mode: 320/200/32/70
mode: 640/480/32/100
mode: 800/600/16/75
mode: 640/480/32/120
mode: 640/480/16/72
mode: 1600/1200/32/70
mode: 640/400/32/72
mode: 640/400/16/120
mode: 320/240/16/72
mode: 1024/768/16/70
mode: 1280/1024/32/100
mode: 640/480/32/70
mode: 1280/1024/32/120
mode: 1280/1024/16/100
mode: 1280/1024/16/72
mode: 1152/864/32/100
mode: 1600/1200/32/75
mode: 1600/1024/16/75
mode: 1152/864/32/85
mode: 512/384/32/75
Current mode:512 x 384 x 32 @75Hz
OpenGL renderer initialized
Software renderer disposed
org.lwjgl.LWJGLException: No window.
        at org.lwjgl.input.Keyboard.nCreate(Native Method)
        at org.lwjgl.input.Keyboard.create(Unknown Source)
        at JPCTDemo.switchOptions(JPCTDemo.java:770)
        at JPCTDemo.gameLoop(JPCTDemo.java:683)
        at JPCTDemo.<init>(JPCTDemo.java:433)
        at JPCTDemo.main(JPCTDemo.java:181)
#9

" Software renderer disposed "
software mode???
We don’t support software mode, and afaik haven’t done so for quite a long time… - but you have a radeon 9700 pro?- or is that just at home?
You can force allowance of software mode by setting the allowSoftwareOpenGL to true:
-Dorg.lwjgl.opengl.Window.allowSoftwareOpenGL=true

I noticed you run it from within JPCT, does any of the tests in org.lwjgl.test.* work?
Are you creating the keyboard before the window?
could you do a full output using -Dorg.lwjgl.Sys.debug=true

#10

“Software renderer” is jPCT’s own software mode. It has nothing to do with LWJGL, so don’t worry. This machine has GF2MX. I’m creating the keyboard after the window. As mentioned, this code worked fine in 0.8 and so it does under 2k und XP. Just not under NT4.

Edit: The debug output:

mode: 1152/864/32/100
mode: 1600/1200/32/75
mode: 1600/1024/16/75
mode: 1152/864/32/85
mode: 512/384/32/75
Current mode:512 x 384 x 32 @75Hz
Window registered
Failed to create directinput - Old Version
Releasing DC
Destroy window
Could not locate symbol glBindBufferARB
NOTICE: <ARBBufferObject> disabled because of missing driver symbols
Could not locate symbol glProgramStringARB
Could not locate symbol glLoadProgramNV
#11

bump

#12

To me, the “Failed to create directinput - Old Version” is the key. NT4’s DirectInput version is probably too old (it has version 3 per default if I remember correctly). I’m not sure why it worked in .8 though - maybe Matzon can explain why.

I committed a change so that the failure to create directinput will result in an exception, not just a debug warning.

  • elias
#13

[quote]NT4’s DirectInput version is probably too old (it has version 3 per default if I remember correctly). I’m not sure why it worked in .8 though - maybe Matzon can explain why.
[/quote]
Aha! - I think elias is spot on here.

LWJGL 0.8 used DirectX 3, because of a bug. This rendered controllers useless, since they rely on DirectX 5. This was fixed in 0.9. Now, as the DX version is a compile flag, I think we have to choose. As I see it NT isn’t really something I think we should support as such, given that even MS thinks its too old. That said, it would be nice to be able to use lwjgl on NT sans controllers.

EgonOlsen, how would you suggest we solve this best?

I am leaning towards using DX 5, ignoring NT - and then provide a secondary build (or preferably let people build themselves) for NT, using DX3 - and thus no Controllers.

#14

Can’t it be determined at run-time?

#15

Rather than linking with dinput.lib and calling DirectINputCreate, it’s possible to create any version of the DirectInput interface you want via COM using CoCreateInstance. Using this approach, you can either detect the OS version and load the appropriate interface, or attempt to load the latest available and fallback down whichever is present.

With most of the DX libraries this is painless, but doing so with DInput has one caveat - you can’t use the default data formats since you aren’t linking with the lib (i.e. c_dfDIKeyboard). This means you have to define your own for each device. In that case, you can peek at SDL to see how it’s done (it’s a bit confusing what all the df fields are for and to what values they should be set at first glance).

#16

I don’t like the idea of two builds…especially if i have to build the NT version myself. I’m with erikd on this one: If it’s somehow possible to determine this at runtime, i think that’s the way to go.
Ignoring NT is the worst solution IMHO. Microsoft may think it’s old (which it is…) but a lot of people are still using it especially at work…including myself.

Edit: On the other hand, dropping NT would make jPCT’s software renderer even more usefull… ;D

#17

EgonOlsen, could you just try this build?, it’s 0.9+ compiled with dx3 switch.
http://matzon.dk/brian/lwjgl/builds/lwjgl-2004-05-05.rar

AFAIK, we cannot choose to use either dx3 or dx5 at runtime, because the controller uses dx5 methods, so it won’t even compile. The reason we use dx5, is becasue controllers aren’t supported in DX before version 5 (there is another multimedia api that can control joysticks on version prior to dx5 - but it sucks - and would require us to maintain 2 controller backends).

#18

[quote]EgonOlsen, could you just try this build?, it’s 0.9+ compiled with dx3 switch.
[/quote]
Works as expected!

#19

Can’t controller simply make a runtime check for the interface version (must be >= 5) and if that succeeds, cast the lpdi directinput pointer to a directx 5 version?

  • elias
#20

Or even better: Is it possible to create more than one DirectInput object? one at version 3 for Mouse and Keyboard and one at version 5 for Controller?

  • elias