Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / JOGL Development / Re: libjogl.jnilib for OSX/x86? on: 2006-01-20 03:24:04
the support for jogl universal binaries is already in the build, so you can build it yourself (provided you have an i386 based Mac).
alternatively, you can grab the universal jogl lib from my home page

Do you really need a i386 based Mac to build a universal binary??  I was under the impression that the intel cross-compiler was included with the latest XCode 2.2.  Am I mistaken?

In general you can build a universal app if you have "MacOSX10.4u.sdk" on either Intel or PPC Mac, however, because of a bug in our (Apple's) JAWT lib, a universal Java library that uses JAWT (such as jogl) will fail to build at link time. We fixed the JAWT library in "J2SE 5.0 Release 4 Developer Preview 4", but the one that is in "MacOSX10.4u.sdk" has not been updated. The workaround for now then is to build jogl on a machine that has a universal Mac OS X, and for the time being that is only the new Intel based Macs.
2  Java Game APIs & Engines / JOGL Development / Re: libjogl.jnilib for OSX/x86? on: 2006-01-19 05:02:39
anybody working on the JOGL JNI lib for OSX/x86?

the support for jogl universal binaries is already in the build, so you can build it yourself (provided you have an i386 based Mac). alternatively, you can grab the universal jogl lib from my home page

3  Java Game APIs & Engines / JOGL Development / universal binaries for Mac OS X on: 2005-10-07 01:56:02
Those of you who are working on jogl based projects that will need to be deployed on both ppc & i386 based Macs, should know that there is now a new target - "macosxfat" that you can use to build a universal binary of jogl  for Mac OS X. You will need either the Transition Development Kit or a universal Mac OS X to compile for that target. You can find an already compiled universal releases of jogl (and joal) on my project page - I have tested those with Jake2 on both ppc and i386 based Macs.

4  Java Game APIs & Engines / JOGL Development / Re: JOGL Leaking Native Memory: Win & Mac, but on: 2004-12-27 17:52:32
JOGL has been working great as a cross-platform way of generating OpenGL contexts for handing off to other native modules.

However Jogl (1.1b07) seems to be leaking about 0.5 or 1.5 MB of native memory for each GLCanvas that is created, used, and destroyed on Win32 and Mac respectively.  Progress can be tracked using "ps" on the Mac and the task manager process list on Windows.  Eventually the process runs out of memory and dies.  The Linux implementation doesn't has this problem...memory usage is constant and the program runs indefinitely.

I've built JOGL on Win32 and activated the DEBUG code to confirm that the destroy methods are being called (destroy & destroyImpl) as expected when the GLCanvases are removed from their containers.  Runtime.getRuntime().totalMemory() and Runtime.getRuntime().freeMemory() also don't grow, hence the basis for my suspicion that itis native memory that's leaking somewhere in the platform-specific implementations...

Before I go through the trouble of boiling this down to a simple test case for a bug report, is anyone already familar with this issue and know of a solution?  Or, is this the expected behavior with no workaround likely?

Are you using ATI hardware?

I know that there was a major memory leak in ATI drivers for every created context. For Mac OS X, it is supposed to be fixed for Tiger (Mac OS X 10.4).

5  Java Game APIs & Engines / JOGL Development / Re: GLSL: Please help me debug - source included! on: 2004-12-15 16:10:53
Sure thing!  I'll put it up in a bit.  In the mean time, gziemski, have you tried running my JOGL version?  What was your result?

Edit:  I am assuming you are running on a Mac, of course!

I run on a Mac indeed. I work at Apple on Java for Mac OS X ;-)

I'll try your test case later today, on both Panther and Tiger. From my experience I know our OpenGL guys will prefer a native test case, so please remember to post it.

6  Java Game APIs & Engines / JOGL Development / Re: GLSL: Please help me debug - source included! on: 2004-12-15 14:42:59
I decided to go the tedious route and write a C implemetation using GLUT and sure enough, I get only a white square.  It looks like the Mac doesn't properly implement the latest shader extensions (Even though both or my OS X cards claim 1.5+ compliance and list all of the required extension strings!).

Can any of you other Mac users out there run the above code and post your results, just so I can get a few more data points to further justify my results?

Could you post your C version of this test case? I would like to forward this to our OpenGL team at Apple and have them look at it.

btw. There were several updates to Mac OS X 10.3 recently, most of them addressing OpenGL in some way. Do you have the latest update installed?

7  Java Game APIs & Engines / JOGL Development / Re: PBuffers on Mac OS X? on: 2004-07-13 23:25:12
Hi Corwin,

This is a thread from the lwjgl forum that might be of a little help.
It looks like they aren't supported on 10.2 and in the thread, they thought they might be in 10.3, but maybe they aren't there yet?

PBuffers are definitively supported in Mac OS X 10.2.

The C examples for Mac OS X using PBuffers can be found here:

The HWShadowmapsSimple in jogl-demos uses pbuffers too.

8  Java Game APIs & Engines / JOGL Development / Re: PBuffers on Mac OS X? on: 2004-07-13 23:18:42
No, they're supported on the OS, and I can write C that demonstrates that.

Also, Render-To-Texture doesn't work either. Has *anybody* gotten these to work?

Does demos.hwShadowmapsSimple.HWShadowmapsSimple work for you? It uses PBuffers and it works for me.

Which demo exactly is the Render-To-Texture?

9  Java Game APIs & Engines / JOGL Development / Re: no glReadPixels on OS X? on: 2004-06-25 19:59:41
If you do:


directly, instead of:

 SwingUtilities.invokeLater(new Runnable() { public void run() { saveAJpeg(); } });
does it work for you? It seems to work for me, don't know yet why that works and why the original code doesn't work.

Also, not directly related to the problem at hand, but there is a pixel layout mismatch: the gl buffers are in GL.GL_RGBA, but your BufferedImage is in BufferedImage.TYPE_INT_ARGB - alpha is in wrong place.

10  Java Game APIs & Engines / JOGL Development / Re: Not able to use GLJPanel in Mac OS X on: 2004-06-21 17:09:45
I note that in the documentation it is mentioned that GLJPanel doesn't work- can anybody tell me what the problem with it is?

Also, how will the performance with this be? I would imagine it would be terrible, but maybe my understanding is incorrect. There's no way to get an actual GL context on the screen with a GLJPanel (since it can't draw in order with all the other Swing components) so it has to do a glReadPixels and then display that image through Swing. Is there something I'm missing, or would this just be excruciatingly slow?



Hmmm, I implemented light weight components using pbuffers for Mac OS X long time ago and it was working then. Something regressed, I'll look into this.

And yes, you're right it is quite slow.

11  Java Game APIs & Engines / JOGL Development / Re: Memory leak when changing scene (renderers) on: 2004-06-20 22:12:01
Cocoa uses object pools for autorelasing objects. On main cocoa thread there is a pool created for you automatically, but other threads need to create their own. It seems that we do things (pretty much anything using cocoa APIs) on a non cocoa thread that needs a release pool.

I'll look into that.

12  Java Game APIs & Engines / JOGL Development / Re: advantages of Jogl on: 2004-06-20 19:58:37
Thank you very much for your replies!

From what you mentioned, i recon that there should actually no comparing Java3D to JOGL, cause they both suit different needs on different levels.
So far, i hope you don't mind if i ask some questions:


5. So far, Java3D is (and i guess it will, cause it is not supported any longerr by sun, or is it again?) only supported on Windows and Solaris. But JOGL is supported on much more platforms. That seems to me like a very big advantage.

Java3D is supported on Mac OS X - see

13  Java Game APIs & Engines / JOGL Development / Re: Fullscreen for Mac OS X: Solution on: 2004-06-20 19:45:08
ohhhhh, thanks for the update Gerard!

So, I suppose the developer update will be made available from the 28th onwards?  Cheesy

In general, how are things going with the implementation of hardware accelerated Java2D commands?  What else are you working on at the moment or aren't I allowed to ask.  Grin



We're making some good progress on Java2D implementation and the underlaying surface/context management. Grab the DP3 once it is out and take it for a spin.

You're allowed to ask anything you want, it's just I'm not allowed to say much ;-)

14  Java Game APIs & Engines / JOGL Development / pbuffers on Mac OS X are now fully supported on: 2004-06-20 16:57:27
hi guys,

The support for pbuffers in Mac OS X port of jogl has been in there for quite a while now (implementation of light weight components), but I just added a mechanism to expose them to jogl apps.

If you don't feel like building jogl yourself to get the pbuffers support, you can grab it from my home page

15  Java Game APIs & Engines / JOGL Development / Re: Fullscreen for Mac OS X: Solution on: 2004-06-20 16:52:31
This solution is just a hack (ie. is not going to be submitted to jogl) for a bug in Apple's Java implementation. Mouse events will not get propageted correctly (dead mouse) and Swing components with AquaL&F will not work.

The real fix is shortly forthcoming from Apple and will be available to developers in the upcoming Java JDK 1.4.2 Developers Preview 3 and then will be available later to the public in Java JDK 1.4.2 update 2.

16  Java Game APIs & Engines / JOGL Development / jogl NeHe tutorials for Mac OS X done on: 2003-11-07 03:48:08
hi guys,

I modified the original jogl NeHe tutorials available at by adding Frame.pack() workaround needed on Mac OS X. I have also removed custom high resolution timer from tutorial 21 and replaced it with System.currentTimeMillis().

The modified jogl NeHe tutorials are available here:

Thanks again to the those of you who have ported them to jogl.

17  Java Game APIs & Engines / JOGL Development / jogl NeHe tutorials need a workaround for Mac OS X on: 2003-11-04 16:20:01
hi guys,

Frame.pack() doesn't work correctly on Mac OS X, so none of the NeHe tutorials available at work on Macs.

Could someone (pepijnve?) please update them with a workaround?

The workaround in this case would be to set the Frame size explicitly. The code in question is in method start(). Just before we make frame visible, or instead of calling Frame.pack(), we need to set Frame size.

I filed a bug against Mac OS X 1.4.x and I'll see that it gets fixed for the next release.

One more thing, the NeHe jar files seem to have duplicate "common" src file directories.

Thanks guys for porting the demos over to jogl, I was doing similar thing porting them over to gl4java a few years ago.

18  Java Game APIs & Engines / JOGL Development / Re: Want to see some Xith3D demos? on: 2003-10-16 16:58:50
The terrain demo works great on Mac OS X, running Panther (slow startup time though), haven't tried the others yet.

Nice work!
19  Java Game APIs & Engines / JOGL Development / PBuffers for Mac OS X done on: 2003-10-12 05:15:31
Require Mac OS X 10.3 - Panther.

20  Java Game APIs & Engines / JOGL Development / Re: JOGL MacOSX 10.2 compatibility Wanted ! on: 2003-08-04 17:06:35

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?
Pages: [1]

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (39 views)
2014-10-17 03:59:02

Norakomi (30 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (28 views)
2014-10-15 16:18:58

TehJavaDev (57 views)
2014-10-14 00:39:48

TehJavaDev (58 views)
2014-10-14 00:35:47

TehJavaDev (48 views)
2014-10-14 00:32:37

BurntPizza (64 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (78 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06 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‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!