Maybe 2 weeks from now.
Quite exciting to hear! I’m curious, do you have more specific info on what the minimum OS required to run will be?
Paul
What’s an OSX? Is that a brand of toaster?
Oooh! Let me know when you need a version of Alien Flux to test it with.
Except of course I don’t know anything about any Apple OpenGL extensions, so it might not run as well as it should…
Cas
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.
'sok, the only WGL extension I even check for is EXT_swap_interval but it would be nice to have the Apple extensions checked into the core library!
Cas
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.
I’am looking forward very much to the day when I can code OpenGL games for Mac, Linux and Windows using Java; that day is almost here.
Write once; Run anywhere!!!
Keep up the good work.
Andy.
When you get the examples all working drop me a line and I’ll try and get you a beta together. I’ve got about 11 days to finish the game 
Cas
Regarding OAL - the binaries on Creatives site doesn’t work? - I mean, why compile it from cvs, if the binary is fine?
http://developer.creative.com/landing.asp?cat=1&sub=31&top=38
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.
Cas
HELP!
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…
Ideas??
Scott
OK fixed that one… GL context was bogus… getting there… slowly…
hehe - nice to see progress!
I see polygons!
Ok, so they are crappy flickering messes of polygons… but hey! Progress!..
The Polygon example puts up a screen with a triangle and a square, but the textures are flickering madly with white/grey garbage.
Just think, when Mr. Pierce gets the input going I might have a way to make them go away too
I suspect this weekend the OS X port will make a significant jump.
HID is a complete and total clusterfuck. 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
[quote]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
[/quote]
In what way?
[quote]…there is absolutely no guarantee of input devices existing or having certain features.
[/quote]
Yup, all code should never expect devices to be available - I will update the examples.
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.
The OSX way sounds identical to the way we do it in DirectX.
The Java API is very simple, which is exactly what we want. If there’s no Keyboard, a call to Keyboard.create() simply throws an Exception and says so. Likewise Mouse and Controller.
Cas