Any chance windowed mode will learn to play nice?

OpenGL Development
#1

Right now I can write stuff in LWJGL using the windowed mode and everything works fine. However, the two input classes Mouse and Keyboard do not behave as you would expect a windowed mode app to behave. The keyboard isn’t so terrible, since it does let go if you switch focus to another window. The mouse, however, is a total hog. Once the LWJGL app has grabbed mouse input, the only way to switch focus to another window is with alt-f4. I don’t know if this is hard coded or system dependent (ie. if I change my settings in Gnome to change window focus with control q, will that work?) but either way it’s still not the greatest method.

Is there no way to make LWJGL share mouse input with the rest of the system? I know it was originally designed only for fullscreen mode with windowing only for debugging, but would it detriment the library to make a nice windowed version going forward?

#2

The windows key or alt-tab will happily switch focus and give me my mouse back in WinXP, so maybe its just a linux specific thing? Maybe an API addition to release the focus might be a handy addition…?

#3

Currently alt+tab is hardcoded to release focus on linux. The reason I can’t do better is because on linux every key event is grabbed while on win32 special combinations are caught by the OS - like alt+tab, the window key press etc.

Alternatively you can use native cursors. Then the mouse will not be confined to the window in windowed mode. But that’s only available in X 4.3 however.

  • elias
#4

Yeah, I thought it might be hard coded. That’s not so terrible in Windows, but aweful in Linux. It would be really nice if in Linux LWJGL would allow the system to process keyboard events as well.

But more so, I’d love to see a native cursor in Windows. I understand you’ve got this working in Linux elias, but is there any effort under way to do this in Windows as well? Or are you just leaving this to Cas, who seems happy to leave it as supporting full screen only? (Meant as a friendly jab Cas, I swear!) :slight_smile:

I’m more than willing to look into this myself, I just don’t want to duplicate any work someone on the official team might already be doing.

Paul

#5

Why sure - you’re in luck in fact. I always implement new features on both win32 and linux. If I didn’t, I wouldn’t consider it a real lwjgl feature (and supporting two platforms make it harder for cas and matzon to throw the features out again ;).

So native is there, along with the linux support. A few quirks is worth noticing though - animations are not supported in win32 and you can only do 1 bit transparency. But that will be revealed from the getNativeCursorCaps() call.

  • elias
#6

Wow, nice! Do I have to grab and build the libraries from cvs to see this feature? I haven’t tried to build binaries for lwjgl yet. Is it intuitive? Well, is there at least some kind of documentation? Perhaps another post where this is discussed you can point me at?

Paul

#7

You can have my last AF build of LWJGL if you use glibc ver >= 2.3 (rh 8&9). Or else you’ll have to download current cvs and compile it.

Basic instructions:

  1. Do an “ant package” in the lwjgl root directory and you’ll get a lwjgl.jar in lib/
  2. Goto src/native
  3. Do “./autogen.sh && ./configure && make” to get an liblwjgl.so.0.0.0 in src/native/.libs (notice the dot in front of libs).
  4. Rename it to liblwjgl.so. It should work, along with an libopenal.so of course (I build those from openal cvs but you could probably use those from your distro just as well).

If you want a debug build, add -D_DEBUG to CPPFLAGS and CFLAGS in src/native/configure.in and rename the lib to liblwjgl_d.so. I know, I know, it’s a little awkward, but I’m not all that into fixing our build scripts at the moment.

  • elias
#8

What about building in Windows?

#9

Aren’t you a fast responder?

Well, the windows deal is a little bit trickier. First and foremost you’ll need a C++ compiler - I have only tried VC++ 6. Then you will create a project with all c and cpp files from common/ and win32/ included to build a dll. You’ll need to fetch OpenAL and EAX headers from creative and you’ll need to include certain .lib files, like dinput etc.

I even had to find myself a total Win32 SDK update from microsoft because some calls are too new for VC 6.

All in all, my VC6 setup “just works” because I took the time to make it work months ago. But that won’t help you much so maybe cas or matzon want to jump in and help me out here?

  • elias
#10

Well, if someone would be so kind as to just chuck me some dlls and jars, I’d be delighted. But I’m not afraid to do the work myself.

I tried setting up a project in Visual Studio .NET, and I can try VC 6 as well. I got to a point where my errors are mostly complaining about missing OpenAL, EAX, and glext.h. That last one I scoured the web for and found a website where the author says the zip is corrupted and won’t be fixed until Monday!

I’ll try now to track down the OpenAL and EAX headers. Some links would be really helpful if you have them. But it looks like I may be stymied by this glext.h issue, at least until Monday.

Which is a shame, as being a programmer I naturally have no life and was looking forward to getting this code done over the weekend.

Paul

#11

I have native builds at

linux: http://odense.kollegienet.dk/~naur/lwjgl-AF-04062003.tar.bz2

win32:
http://odense.kollegienet.dk/~naur/lwjgl-AF-06062003-win32.zip

The last one is stolen from cas’ build of LWJGL to AF.

for windows compile you’ll need the headers from the SDKs from around here:

http://developer.creative.com/landing.asp?cat=1&sub=31

Not sure about the glext header though. Which file needs that one? If you mean extgl.h it’s in common/ along with the implementation in extgl.c (one of the only straight C files).

  • elias
#12

Hmm, you’re right, it is extgl.h. And now that I look at it, it’s complaining about missing a whole bunch of files from the common directory, despite the fact that I’ve included them in the project. Weird.

Well, perhaps the binaries will work and I won’t need any of this. But it’s quitting time now. Hopefully I’ll get a chance to play with this over the weekend.

#13

I’ve always got a bang-up-to-date version ready and compiled for Windows. Pop in at the puppygames forums and ask. Or just grab the beta of AF and pinch the DLL.

Cas :slight_smile:

#14

I’m getting this error in Windows:

run:
[java] java.lang.UnsatisfiedLinkError: nCreateCursor
[java] at org.lwjgl.input.Cursor.nCreateCursor(Native Method)
[java] at org.lwjgl.input.Cursor.(Unknown Source)

Looks like maybe the dll you gave me isn’t as up to date as you expected?

Cas, I scoured your site and don’t see the beta anywhere (perhaps it’s a closed beta, and I’m not in the know?) BTW, your site is looking pretty slick these days. Nice job. So is this a desperate plea to get more people writing on your forums? Ok, I’m begging for code updates anyway, I’ll bite.

Getting the correct binaries aside, I do have a question. When you create a cursor, it asks for an address to the image. Should this be the address of an OpenGL texture? If not, is it expecting it in some other format? Got any sample code of this being done that I can look at?

Thanks for all the help.

Paul

#15

This one is homebrewed:

http://odense.kollegienet.dk/~naur/lwjgl-07062003-win32.zip

The javadoc comment in the Cursor constructorstate how your format should be - ARGB packed in ints. For an example see org.lwjgl.test.input.HWCursorTest

  • elias
#16

[quote]Cas, I scoured your site and don’t see the beta anywhere (perhaps it’s a closed beta, and I’m not in the know?) BTW, your site is looking pretty slick these days. Nice job. So is this a desperate plea to get more people writing on your forums? Ok, I’m begging for code updates anyway, I’ll bite.
[/quote]
Desperate! Pah! Actually it’s already quite a busy site surprisingly and we haven’t even released the game! And LWJGL is going to go and live there soon too, so it should get quite a bit busier. Ah yes - and it’s a closed beta. I’ll add you in. I’d appreciate it if you could have a go with the Java version on your Linux game rig.

[quote]Getting the correct binaries aside, I do have a question. When you create a cursor, it asks for an address to the image. Should this be the address of an OpenGL texture? If not, is it expecting it in some other format? Got any sample code of this being done that I can look at?
[/quote]
I haven’t, but no, it’s not a GL texture. GL textures don’t have addresses, only handles, which you can’t use for anything else; and the HW cursor isn’t a GL feature anyway! Just pass it a pointer (eg. buffer address) to some image. I don’t know if Elias has made it clear that you should then discard the image data or not after that (in GL, you throw away your data after it’s uploaded to the GL).

Cas :slight_smile:

#17

Oh yes that’s not clear in the docs - the constructor copies the cursor image(s) so you can throw it away afterwards.

  • elias
#18

Thanks guys, I finally got this working last night. The HWCursorTest example was very helpful. It now works in both windows and linux. One interesting thing I noticed while working with this was that in linux, my min cursor size was reported as 1, and max cursor size as 64. However, if I tried to set the native cursor to an image less than 32 x 32 pixels, it wouldn’t show up and instead reverted to the system default cursor. I still got all my mouse input events, only my custom image didn’t show up. Very odd.

Cas, I will try to give the Alien Flux beta a whirl as soon as possible. Right now I’m in a bit of cruch time myself, so it may take me a couple days to get to it. How long is the beta running for?

Paul

#19

AF beta has 2 days left. :stuck_out_tongue: