Apple has wildly different extensions that your average GL (one of the other reasons for that interface layer I was talking about) so if you require any particular extensions or if not having them would cause an error - it may not run at all.

At a minimum you will need to be running 10.2.6 to catch some bug fixes in the Apple OpenGL code and get OpenGL 1.3 compliance. Machine wise that depends entirely on the content. I'm using a TiBook 667Mhz with 512MB.

The more immediate holdup in input controllers since Apple absolutely screwed up big time when writing that API. As such the OSX will rely on a 3rd party library to enumerate mice, keyboards, gamepads, etc. This library is open source and will be shipped in Framework form with the release.

Mr. Palmer is already stepping up to the plate to handle future releases.

Cas, I could use that test version of Alien Flux.. I'm going to be spending most of tomorrow (Monday) trying to get things working. It is slow going for me because I'm new to Macs and OpenGL... but I can still track down a bogus pointer.. that's basically all I have been doing so far.. running the example code and fixing the crashes that happen.

Yeah, and it's worth mentioning we can't get the win32 CVS source to compile into a working OpenAL either. Something we should one day hassle them with but for now as long as they're doing it for us we don't care.

For some reason I'm getting NULL returned from glGetString with Mac OS X. Does anyone have any idea why that would be and what I can do about it?

I'm trying to run the examples to test the OS X port and am stuck with this problem. It may be an OS X specifc thing that I've got buggered up in the port, but the glXXX function pointers seem to be sane...

HID is a complete and total clusterf**k. Its an elegant design, but so complicated that it obfuscates itself One thing about the OSX port that will be different is that it will function at the input level differently than the sample code we're testing expects.

Just as there is no guarantee of resolutions or graphics cards features, there is absolutely no guarantee of input devices existing or having certain features. By this what I mean is that while its nice to assume that there is always a keyboard and/or mouse attached, they are by no means guaranteed and the sample code should check for the existence of these devices and throw an exception in the event that they aren't present.... especially in the age of wireless controllers

While I'm trying to make it more friendly to LWJGL - the Apple folks kinda got it right. There is a concept of a HID manager. Every device that wants to consider it self as a HID announces that intention to the OS. These can then be enumerated, configured and polled. This is a little different than creating a new keyboard and mouse explicitly as opposed to just asking the system for devices and expect it to cooperate. While the OSX HID API itself is obfuscated - the premise behind it is actually quite sound.

This sounds a lot like Direct X and enumerating devices. However nice as this seems - when I want a keyboard, I want a keyboard!

When you create the Controller, Direct X is actually queried for all Controller compatable devices, and the first one available is returned - likewise with Keyboard and Mouse, we just say to DirectInput that we want the device of type 'GUID_SysMouse' or 'GUID_SysKeyboard' - this ofcourse *can* fail. Most of the sample code (if not all) wrongly assumes that creating a mouse or keyboard will never fail. This will be fixed in a near future.

Not quite. DirectInput device enumeration DEVICECAPs and the information you get back from the HID Manager are wildly different. There is an intersection in what you can get/do, but there is definitely a lot more refinement in the Apple HID Manager. What's I've decided to do is leave the keyboard and mouse as they are. Since that's the way its desired for LWJGL to function, I'll let you guys sort out the myriad details involved with differing keyboard types and key codes on OSX. I'll focus on getting the contoller support up to snuff so you can find controllers. Any device caps which interset with what OSX returns will be filled in and the others will be null.

After working through a double buffering issue with Mr. Palmer, he reports that cool stuff is showing up on the screen and so forth. Input devices are maybe a weekend a way. They are already working in the new framework so I just need to coax that architecture to work with LWJGL.

I was trying to build using the autogen.sh sources, but when I ran ./configure, I got the following:

...checking for JAVA_HOME... /Library/Java/Homechecking for X... nochecking for main in -lX11... noconfigure: error: X11 is requiredbash-2.05a$

So, I'm guessing that a "quartz-like" build from the command line isn't (yet) possible. I found the ProjectBuilder project, but when trying to build it (from the command-line, again), I got "Error: couldn't load project /Users/daniel/GameDev/LWJGL/LWJGL/src/native/projb/lwjglOSX/lwjglOSX.pbproj" which may just be an issue because I'm not at my machine, but rather doing this over an ssh tunnel from my office.

-daniel

There are 10 types of people in this world...those who understand binary, and those who don't.

Having someone handle the whole build script thing is something that appeals to us greatly as swpalmer and I (maybe me moreso) hate Project Builder and its nutty environment. If you want to help out with that, or if you're interested in diving into the OSX source tree - feel free! Send either of us a private message and you can join us on AIM as we finish this puppy up.

Ultimately I would like to fix the whole ANT script to do all of the work (relying on external scripts to build the native parts) - I just need to get myself motivated for it, coz it will most likely be a bit messy... But each time we do a distribution, I am reminded that we neeeeeed to make the ant script better :-/

I agree that some cleanup is needed. I also would like to see everything built by invoking Ant. If I wasn't so new to the Mac programming environment I would take a crack at doing a makefile or something. <rant> I generally HATE Unix for how much it sucks in this area ./configure is a crock of sh*t.. not to mention that it takes longer to configure than it does to actually compile half the time... assuming it works at all. Very often 3/4 through the configure it bails because of some odd-ball library that is not installed or not where it is expected etc.. then i go off to install it.. which may mean compiling it.. which leads to it's ./configure maybe not working.. then even once it is installed, the original ./configure still can't figure it out etc... a total bloody mess quite frankly... One thing I like about the Macs is how they are basically 'all the same'.. Having one vendor for OS, and hardware may keep the prices up, but it also keeps the frustration level down... </rant>

On the HID front I just purchased a USB game controller for my powerbook.. an iShock II... should be good for testing when we get the Mac port to that level.

Does LWJGL support force-feedback controllers? If it doesn't yet, I think it makes sense to add it as a feature for the next release.

Regarding FF. There is a simple reason for no support - I don't have access to a FF controller, nor have I ever used one!I have been very keen to add it though, but there were some issues with linux not supporting it - so I didn't make it high prioriy.

Quote

If it doesn't yet, I think it makes sense to add it as a feature for the next release.

Assuming I can get access to one, fine by me - I was just let to believe that we should stall on the features for the next release, as to let the OS X version get up to par?

As for ant scripts, I will be looking into this ASAP, however we still need native buildscripts to build the native parts. And we need to figure out how to deal with dependencies for those native scripts.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org