Anyone built the OSX version lately?

[gregorypierce]

I was working with Cas on an experiment with the GLContext stuff for 0.9 and my plan was to update LWJGL OSX to be 0.9 compliant but it doesn't even build. What I have is a giant confused mass of automake madness Anyone have any idea what the OSX version in CVS would require in order to build?

[apply] source='extgl.cpp' object='extgl.lo' libtool=yes \
    [apply] depfile='.deps/extgl.Plo' tmpdepfile='.deps/extgl.TPlo' \
    [apply] depmode=gcc3 /bin/sh ../depcomp \
    [apply] /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -Wall -D_AGL -fpascal-strings -I/System/Library/Frameworks/JavaVM.framework/Headers -c -o extgl.lo `test -f 'extgl.cpp' || echo './'`extgl.cpp
    [apply] g++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -D_AGL -fpascal-strings -I/System/Library/Frameworks/JavaVM.framework/Headers -c extgl.cpp -MT extgl.lo -MD -MP -MF .deps/extgl.TPlo  -fno-common -DPIC -DPIC -o extgl.o
    [apply] extgl.cpp: In function `void* extgl_GetProcAddress(const char*)':
    [apply] extgl.cpp:722: error: `kCFAllocatorNULL' undeclared (first use this function)
    [apply] extgl.cpp:722: error: (Each undeclared identifier is reported only once for 
    [apply]    each function it appears in.)
    [apply] make[3]: *** [extgl.lo] Error 1
    [apply] make[2]: *** [all-recursive] Error 1
    [apply] make[1]: *** [all-recursive] Error 1
    [apply] make: *** [all] Error 2
    [apply] strip: can't open file: .libs/liblwjgl.0.0.0 (No such file or directory)


    [apply] Result: 1

[gregorypierce]

I've fixed that problem. Seems the constant that was being used was incorrect so I changed it to one that actually exists. Now I'm onto some new ones in extgl. I somewhat doubt this stuff will actually run since it doesn't build at the moment  :wink:

[Matzon]

Afaik, no one has compiled Mac for a couple of weeks. I'll try and get access to a mac tonight (or at least as soon as possible) and make it run again.

[gregorypierce]

Cool man. I'll be floating around so if you need some help with something post here and I'll take a look. One thing I noticed is that you went the carbon AGL route which probably isn't the best route to go if you plan to support both windowed and fullscreen rendering. I have a solution in some custom code, but it would require writing the Mac portions in Objective-C which is likely to only cause you additional problems.

[elias]

I went the Carbon way because there were simply too much trouble with doing Cocoa. My current idea is now simply to use JOGL style AWT-with-a-glcontext-ontop, and having mouse+keyboard handling through the AWT window. The (currently disabled) HID code can take care of joysticks etc. What are your comments on that plan (does fullscreen mode switching work with AWT for example)?

- elias

[Matzon]

damn, I can't get access to a mac untill tomorrow or the weekend :/

[princec]

Me either I will ask my minion to bring his iMac in on Monday and see what we can do. Although we're pretty busy at work.

Cas

[gregorypierce]

I went the Carbon way because there were simply too much trouble with doing Cocoa. My current idea is now simply to use JOGL style AWT-with-a-glcontext-ontop, and having mouse+keyboard handling through the AWT window. The (currently disabled) HID code can take care of joysticks etc. What are your comments on that plan (does fullscreen mode switching work with AWT for example)?

- elias

Yeah... cocoa is a pain until you understand how objective C works.

In terms of input stuff, you may want to take a look at the work I did for JInput which is in CVS with Sun. I can help you out with any of that pretty easily. I may even have some time next weekend to update your Input core with HID if I can get past the graphics stuff. HID is very fast on OSX - much much faster than AWT events - especially on CPU limited machines (which describes pretty much 50% of the Macs out there).

Provided I can get the binding mode I'm working on to work - I will donate you a Mac display layer which does both windowed, fullscreen, and GLCanvas style rendering. We just updated our own core libraries here to do that since JOGL/JInput isn't the idea way to go from a purely architectural standpoint. Its pretty obvious that there were different people working on JOGL,JOAL, and JInput to the extent where it is just goofy to maintain for us.

[elias]

That sounds great! You probably know this already, but since cocoa can be programmed from java, we shouldn't have any trouble with obj-c? I already coded a preliminary HID driver for keyboard and mouse, but it isn't used at the moment because of the need to translate key presses to unicode characters, which is not a part of HID. Nevertheless, I suspect your HID code is much  more feature complete :-)

- elias

[gregorypierce]

I've gotten the OSX build to the point where is actually builds for lwjgl0.8 based off the current CVS tree. Dunno if it works yet, but I've got it to build and that allows me to move onto the next stage of the experiment that I've been discussing a little with Cas.

Basically what I was looking at was building a separation between the actual OpenGL binding and the various APIs which use it. Currently there is a reasonable coupling between LWJGL and the openGL engine that you guys use. What would be nice is if the OpenGL specific stuff would build as a library all its own (libjopengl). This would essentially be a Java binding to all of the the openGL commands. Then it would be an APIs responsibility to deal with context management, creating windows, talking to phones, etc. The APIs could change at a layer right above the GL API:

Xith3D, core, etc.
----------------------
JOGL, LWJGL, etc.
----------------------
jOpenGL

jopengl would therefore be pretty much universal and any API, library, etc. now or in the future could simply talk to it. The APIs above would deal with making contexts current and all that domain specific stuff.

Currently what I'm testing is my component (a subclass of Canvas for the moment) making the context current and then just loading lwjgl's library exclusively for the purpose of calling gl functions. This is similar to the role that I would imaging jOpenGL having. More than willing to help make that happen if you guys are interested in making that a project with a life of its own - though really the only thing necessary is a change in the make files. Major kudos on your ant scripts. The automake stuff is a bit much though

[gregorypierce]

That sounds great! You probably know this already, but since cocoa can be programmed from java, we shouldn't have any trouble with obj-c?

Yes and no. You have access to some cocoa functionality which Apple has chosen to port to java - but Apple didn't do a full cocoa binding for all of the OS functionality - unfortunately.

I already coded a preliminary HID driver for keyboard and mouse, but it isn't used at the moment because of the need to translate key presses to unicode characters, which is not a part of HID. Nevertheless, I suspect your HID code is much  more feature complete :-)

Once I get through with the experiment I'll take a look and help out where I can. The need to convert the key presses to unicode characters may take a bit of doing, but I'm sure there is an API call somewhere that can do that. With OSX, the problem is that there is an API call that does just about everything somewhere - just a matter of finding it.

[Matzon]

should compile now - though I can't test it :/ (only have ssh access to the box)
changes take 24 hours to propagate to the anonymous cvs server.
most were small changes, though one was a bit bigger, and I might have broken something...
I commented out the

if (!extgl_InitAGL(env, ext_set)) {
		throwException(env, "Could not load agl symbols");
		return;
	}

and

if (!extgl_Initialize(env, ext_set)) {
		destroy(env, clazz);
		throwException(env, "Could not load gl function pointers");
		return;
	}

from Window.nCreate, since the ext_set isn't passed any more. But it would seem to me that this would break something..., but I don't know about the recent movement of the extgl_ stuff. Elias, you have a hint?

[gregorypierce]

I was able to get it to build, but now its generating a liblwjgl.jnilib that is apparently linking to some other .0 file that doesn't exist anywhere. I'm going to take a look at the makefiles *shudder* tonight since I'm going to experiment with culling the actual GL engine from LWJGL for this test. The biggest problem with the whole affair is that the only way you can get the GL system to initialize it to create a window using nCreate. If all of the calls to

extgl_Open()
extgl_InitAGL()
extgl_Initialize()

were put somewhere that wasn't dependent on the window - you could build a library purely with the OpenGL binding code - which is what this little experiment calls for. I'm sure I can get past this tonight and have a nice separate gl binding from lwjgl that can be integrated with anything. Then I can replace the entire core of the autogenerated GL stuff in my JOGL branch - test how it works and then start integrating that into my little glcanvas tests.

[elias]

extgl_InitAGL must have ext_set removed, extgl_Initialize should not be called anymore (GLContext does that). I'll fix it asap.

- elias

[elias]

extgl_Initialize and extgl_Open are the ones needed for getting at the gl pointers, and it is in fact called by GLContext now, and not the current window. I updated the mac code to not include the initialize call (still needs Open to facilitate InitAGL though)

- elias