JOGL MacOSX 10.2 compatibility Wanted !

OpenGL Development JOGL Development
#1

I can very well understand there could be a software incompatibility between JOGL and the JRE implementation on MacOSX 10.2, but I have a hard time understanding why compatibility could only be only available with MacOSX 10.3 (that noone has had access to today, except the folks at JavaOne…)

Couldn’t apple upgrade the JRE of MacOSX 10.2 using smartUpdate like they did while moving from Java 1.3 to Java 1.4.1 ?

If Apple wants to push Java gaming, they should offer a market wider than the sole geeks that have paid the bucks required to upgrade to MacOSX 10.3 : having games published is all about getting your investment recovered, and you need a wider market than 10% of the MacOSX users being using 10.3, MacOSX users being, say, 40% of the users of a mac, which is 5% of the total PC users. So if you want to publish a game using JoGL under MacOSX 10.3, you will reach a MAXIMUM potential market of 0.10.40.05= 0.2% of the PC Market, wow ! What a good start for convincing game producers and potential investors to finance a Java retail game for Mac ! This a real warranty to recover your investment ! :wink:

Could Gerard Ziemsky say a word to Apple about this issue ? Could JoGL possibly be made compatible with MacOSX 10.2 with a patch from Apple ? I’m pretty sure this is doable…after all Pather is just the same codebase as Jaguar with a few new features, mostly related to desktop ergonomy…

#2

We all know it is possible with 10.2 because there are plenty of game titles out there under 10.2 The exact issue is between AWT and 10.2, not so much JOGL and 10.2 The current design of JOGL depends on AWT, therefore JOGL won’t work on 10.2. Either we come up with some inventive way to circumvent the issue or we change the architecture of JOGL to no depend on AWT (which I know won’t happen).

But I agree… I have a team member who has a Mac and she can’t develop right now because she can’t get Panther.

#3

I can tell you why this ain’t possible and ain’t going to happen. Apple is changing the way AWT is accessed in Java in 10.3. This may or may not show up in a Java update for 10.2, but at the moment its not going to work on 10.2 and that’s pretty much the deal so all I can really say is guys you’ll just have to deal with it. Its like asking for Microsoft to put DX9 on Windows NT. For the sake of progess and performance they’re doing something - the right thing and what they are doing makes perfect sense. We can’t ask Apple to do what it takes to ‘make it fast’ and then complain because we can’t have it ‘right now’. The changes are in a JDK that you wouldn’t have access to even if it DID run on 10.2 so you’d be in exactly the same boat.

#4

guys,

JOGL could indeed be made to work on 10.2 with some work (ugly hacks). The performance (and stability) of such implementation, however, will not be what it is with 10.3.

I’m a little reluctant to burn cycles on making jogl run with 10.2 - personally I’d rather work on Panther. However, if you guys really really want it, I’m willing to look into that.

Again, please keep in mind, that it does run great with Panther, which you will have soon - if you can wait.

So, do you want me to look into it?

#5

To be honest I’d rather have PBuffer support - but I’ll go with the majority and say yes :slight_smile:

#6

pBuffers here also… i think a HOT version on Panter is the way to go… My MacOSX10.2 dont work these days anyways :slight_smile:

go PANTHER cool working action! - but then u new i would say that dude.

#7

I disagree…they should be working on a good implementation for panther, not some half assed 10.2 implementation. Do it right the first time. I’m going to get panther because Java GUI on 10.2 is so pathetically slow (even on 1.4.1). My 450 MHz W2K box with 1.4.2 kicks my 700 MHz eMac’s ass, badly, when you compare Java GUI performance.

Here’s hoping for a GOOD GOGL implementation on panther!

Mike

#8

The priority could be set on Panther development (one complete development is better than 2 buggy and partial developments), but I really do beleive at some point MacOSX 10.2 compatibility should be implemented.

The end users don’t upgrade their systems at the rate developers do, and especially Mac users : many mac users I know still use system 9 and most of them just don’t even know how to install an operating system, they’ll take whatever OS comes with the next Mac they’ll buy.

If we intend to design video games for Java and for the Apple computers, I think it is mandatory to ensure the largest user base as possible. Video games is a mass market !

I’m aware JoGL is at the step of implementing features rather then ensuring compatibility, but it is very important to keep in mind compatibility should not be forgotten.

Anyway, OpenMind does already uses pBuffers on Win32 and badly needs them on MacOSX. But moving from Gl4Java to JoGL, OpenMind lost MacOS compatibility for the moment. I can’t even test it on my Mac (Jaguar). Could there be an opportunity to get a Panther developer preview ?

Alban

#9

well I suppose you could always checkout the latest copy of the JOGL source and compile it yourself - just a thought.

Will.

#10

Unfortunately, it is not as simple as that ! :-[
JOGL just doesn’t compile on my MacOSX 10.2. It requires some librairies I don’t have and I beleive are present only on 10.3, unless I’m missing some point.

Anyone compiled it successfully on 10.2 ?
Anyone had it run successfully on 10.2 ?

#11

On 10.2 I get:

[javac] /Users/scottpalmer/dev/jogl/src/net/java/games/jogl/impl/macosx/MacOSXOnscreenGLContext.java:243: cannot resolve symbol
[javac] symbol  : method cocoaViewRef ()

Which I think is directly related to the changes in JAWT that were done for Panther.

#12

That’s the error I have too !

#13

I think the problem is that there isn’t a reference to the Cocoa View in the JAWT_MacOSXDrawingSurfaceInfo structure on Java 1.4.1 under OS X 10.2

As I understand it there is a reference to some other structures that would allow you to go digging around to get a CocoaView… but that doing so would be relatively slow.

That’s the only issue that I’m aware of as far as getting it to run on 10.2.
My JAWT_MacOSXDrawingSurfaceInfo struct looks like:

typedef struct JAWT_MacOSXDrawingSurfaceInfo
{
        int     cgWindowID; // CGSConnectionID
        int     cgConnectionID; // CGSWindowID
        int     cgContextRef; // CGContextRef

    int cocoaWindowRef; // NSWindow*

        int     carbonWindowRef; // WindowRef (HIToolbox/MacWindows.h)

        int     windowX; // int
        int     windowY; // int
        int     windowWidth; // int
        int     windowHeight; // int
}
JAWT_MacOSXDrawingSurfaceInfo;

I think the key would be to get a cocoaViewRef from the cocoaWindowRef. But hacking this into the current JOGL codebase would be a bit of a pain, since the GluGen stuff basically builds that accessor function for you.

#14

Yep, that’s specifically the JAWT change that I was referring to. You won’t be able to make it work on anything other than 10.3 - stop beating your heads against the wall :slight_smile: