Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (843)
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] 2 3 ... 5
1  Java Game APIs & Engines / JOGL Development / Re: Mac pro & GLSL!!! on: 2010-04-18 13:31:17
you could enforce the discrete graphices chipset and see if that helps.  I'm not sure how smart the graphics rendering switchover in the new MPSs are.  And if you are hitting the embedded intel, well, then good luck with that Wink
2  Java Game APIs & Engines / JOGL Development / Re: WebGL - Interesting development on: 2010-04-06 17:54:48
What about Jake2? Admit it is faster.

Actually I found the startup times to be far slower... Wink

I did try the webstart version of jake2, and it actually failed with an error about self signed certificates.  No idea why since i use a self signed certificate for my own webstart jogl.  I just updated OSX to latest patch, so maybe something to do with that.

Anyway, I'm not convinced that the performance benefit of JOGL is enough to fight off WebGL.  Lets wait for browsers to support WebGL in a production build, and then see where we stand against the upcomming JOGL2.

For me the benefit I see with WebGL is already demonstrated by the jake2 port, and that's the startup speed and simplicity.  If we really can have a common API between JOGL2 ES2 and WebGL ES2, then I'll use the WebGL front end to 'sell' the game and offer a webstart option for those looking for a bit more performance.

3  Java Game APIs & Engines / JOGL Development / Re: WebGL - Interesting development on: 2010-04-04 18:28:43
Wow, that runs very well on Chrome. The only thing that actually limits the game is the lack of mouse capture.

For those who want to try it out, I'm hosting a build here:

around 20-30fps on 3 year old MacBookPro with Safari, more than playable! apart from the controls Smiley

thanks for hosting!
4  Java Game APIs & Engines / JOGL Development / Re: WebGL - Interesting development on: 2010-04-03 12:08:56
jake2/lwjgl and the start of a common es2.0 api between java and webGL?
5  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2010-03-04 05:43:51
the last conversation i had with the guys of one of the mentioned projects is that using JOGL's interfaces was on there plan to investigate and they don't see any showstoppers, but this was around one month ago.

I asked on here about using the JOGL API's and the guys didn't seem to be aware of JOGL at all...

I'm now playing with GWTGL and so far I quite like the approach of keeping a binding and wrapper implementation separate.  This might make adopting JOGL2 API an easier task, but I haven't heard from the guys for a couple of weeks.

PS the OpenCL stuff is looking Very nice!
6  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2010-03-03 05:55:59
We have already answered to these questions as far as I know.

really?  the lack of certificate is news to me, and so is the decision regarding LWJGL.  But both are bad news items Sad  can you point me to the discussion please?

Why do you speak about a binding for WebGL whereas it is already possible to use JOGL 2 in applets
Many reasons I already mentioned, but mostly because it doesn't require a client side plugin(Java), or certificate, and is pretty much instant startup.
7  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2010-02-27 08:46:27
sorry to bump again, but I have a feeling that this thread is still very relevant to the future of JOGL2 and remains mostly unanswered.  (deployment issues, magic certs, LWJGL merge, newt, es2, competing against WebGL?)

Another month has gone by, and there is no clear future laid out for JOGL2.  Sven I appreciate if you are working on this behind the scenes, but is was back in october/november when JOGL was declared alive and kicking after Sun pulled the plug.  I haven't really seen any public progress since then.  Ok I know there is a git repository, but there is no community around that.  We are still sat here on sun bb's waiting for news.

Anyway I've spent the last month playing around with GWT.  Already there are 3 Java bindings down to WebGL.  Is it worth at this point to consider using the same approach for JOGL?  I like the JOGL API's, and I don't see why gluegen couldn't be generating the WebGL ES2 binding for us?  JOGL has the advantage of maturity, and quite a good following...

I just want to get a feeling for the future of Java OpenGL in the browser.  When I see how fast things are progressing with WebGL, it makes me wonder if JOGL2 has any future at all, unless that is the binding changes.
8  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2010-01-12 20:02:22
@gouessej  Did you manage to get any info, or is the lack of activity over the last month an indication of things to come?
9  Java Game APIs & Engines / JOGL Development / Re: WebGL - Interesting development on: 2010-01-07 20:25:09
and another one for anyone keeping count:
10  Java Game APIs & Engines / JOGL Development / WebGL - Interesting development on: 2010-01-02 08:42:48
So we agreed WebGL would be nice if it was Java vs JavaScript, well it seems we are not the only ones thinking this:

Now if only the API was JOGL based...   
or maybe both using EGL for the windowing interface. 
Or maybe we could target JOGL2 ES2 API to match one of the above?
11  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-11 07:11:38
A single threaded Java to Javascript sourcecode transformator that 'almost always works' shouldn't be that hard, and we can move from there. Such a proof of concept might get us some momentum and motivation to continue the effort.

Sounds reasonable. 

Could we maybe make use of GWT for this? That would cover maybe 90% of the job, and then we'd just need to write a wrapper to map the JOGL2 API into WebGL.  This would give users the flexibility of deploying current desktop JOGL2 apps, or WebGL based apps.  Assuming we stick to something simple like ES2.  GWT would give us the benefit of still being able to use standard Java tools and allow for debugging.

12  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-10 19:55:19
omg I forgot how ugly javascript is  Shocked
If you haven't done so already, I recommend to download the firefox nightly and just give a few WebGL demos a test run:

Then you'll really know what we are up against.

For JOGL to reach this level of integration with the browser, I need several things to happen:
* magic certificate
* no applet warning
* plugin2 deployed on macs
* dare I mention startup performance...
* multi-tab fix for firefox - ie the one where the same applet is drawn over every tab content.

Sun haven't managed to solve these issues during the lifetime of JOGL (4 years?), and now it looks even less likely to be solved (at the Java level at least) Sad

So what does WebGL give me:
* all the above issues go away.
* My dependency moves away from a platform specific plug-in (Java), and into a browser dependency. (does IE have WebGL, i doubt it...)
* A browser dependency actually opens up all the none desktop devices, eg: Android, iPhone, Tablet, mids, netbooks, other smart phones etc
* The major browser players are really pushing this tech.  WebGL is already in nightly build for firefox so will probably hit a Q2 release?
* An absolute nightmare porting all my Java to javascript

What I don't get:
* My favorite language - obviously Java Smiley
* My fav development tools - eclipse & yourkit
* Good networking support (although HTML5 WebSockets should also solve this)
* Obfuscated bytecode

So I'm 100% hoping that JOGL can deliver, but the next months are going to be critical from my side.


13  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-09 20:29:01
Thanks for the interesting news Spasi!

btw I just grabbed the latest Firefox nightly to have a play with WebGL, wow!  I'm sorry to say JOGL fans, we are gonna struggle to compete against this!  Running OSX and the page load was just instant, no plugins, no downloads or certificates, just straight in to 3d!   Although for serious development, I'm not sure people are gonna be happy exposing all their javascript code to the world...

14  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-04 19:21:59
Having read a bit more about WebGL today, it's clearly not something we can ignore.  It may not be the answer today, but with this amount of buzz and backing it's hard to imagine it not catching on really fast. 

What has Java on the browser got going for it? sadly not a lot.  Abandoned by Sun and crippled by Apple.  The really sad thing is, it would only take a bit of effort to make it what it should have been.  I guess that's why we hang in pinning our hopes on things like pluggin2, newt, etc.  But lets be realistic, thanks to flash, browser java has just gone out of fashion, and FX has already damaged what little reputation Java browser apps had left.

So the game has already changed.  If we want to focus on desktop then I guess we can continue fighting with plugins and webstart.  But the concept of plugin-less content is going to win out in the end...

Then we need to think about hardware.  Where do you want your app to be run.  It's no longer a choice of which desktop OS's, but also which devices.  For me it's currently the iPhone, but I'm not going to spend months working in objective-c, then switching to java for upcoming Android devices.  Then back to objective-c for the tablet or whatever comes next.  But my point here is that Apple have changed the game by not supporting Java on the iphone.  And you could argue that even Android isn't really supporting Java, they compile down to their own VM.  A full JVM is just too heavy weight... although eventually this could change, but who is driving that?

If you want OpenGL content across all hardware (Desktop and Portable), then the only option is starting to look like WebGL.  So from that side I can fully understand the buzz.  Most of these devices already support ES and JavaScript out of the box, upgrading webkit or other browsers is automatic for most portable devices, and desktop users tend to catchup eventually.

So where does this leave us?  Sadly, we are looking at a bleak future for Java+OpenGL.  I'd love to be proven wrong, but at best it's going to be a niche market in the end (maybe it already is).  For a brighter future we'd need to see manufacturers boasting about Java support in upcomming devices, but I can't remember that last time I saw that as a selling point on anything.

For me the above conclusion is grim.  I loath Javascript as much as every other programmer I've ever worked with.
My only hope is that Google will absorb WebGL into GWT and allow me to to program against WebGL via Java.


[update] And so it begins...
15  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-03 06:22:00
I'd just like to say I'm eternally grateful for the work people have done maintaining GL4Java (Sven/Ken + others) years ago and in turn JOGL. It's helped me to learn loads about OpenGL using my main programming language (Java) without having to get back up to speed in C++ and I've been able to realise a lot of project ideas that were kicking around my head.

Indeed I can fully relate to that.  I have a similar background with GL4Java and I think these guys have done a great job o bring it this far.

I'm especially excited about the new features in JOGL2 like ES2, newt and CL support.  Breaking the AWT tie has to be a good thing too when you look at what's coming up with google os/android based netbooks/laptops/phones etc.  It would be great if JOGL can keep it's very light weight core with all the optional jars approach, and then if the best bits of other libs could live also as optional jars that sit on top, or along side, then that wold make a developers life easy.  As always I'm thinking about deployment issues and I think the focus should not just be on the name of any unified package, but also on how do we compete with flash and silverlight.  Whatever comes out of the process here has to be proffesional/serious enough to contend with these technologies, otherwise we may as well not try.  I don't think FX is the solution to Java on the desktop, I think what we build here could be though!!  The idea of accessig the browser context for direct rendering sounds like it would help alot, but otherwise we need to find a simple way to deploy 'JUMP' components to work on all desktops/OS's.  Then we can start thinking about our own store...!!


16  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-11-27 19:23:49
I can offer some help from the mac side if you like, just tell me what to do.  I got git installed at last, and as long as the build is ant or maven I should be able to offer some help...
17  Java Game APIs & Engines / JOGL Development / Re: How useful is OpenCL? on: 2009-11-15 00:17:12
Sorry to barge in, but is OpenCL - JOCL also migrated to github?
18  Java Game APIs & Engines / JOGL Development / Re: JNLPAppletLauncher on: 2009-11-14 10:16:22
i did a quick test on windows: Invalid result 31 from GLCapabilitiesChooser (should be between 1 and 24)
but it works fine under OSX, very nice feel to the ObjectFilled demo! Smiley

I also had the issue with pluggin2 under OSX (SL).  Apple have had the sources for a long time, and there was a snippet of text on an apple board saying it was included in snow leaopard, but I haven't found anyway to activate/test it yet... Sad

So I think we are in the same boat, please feed back if you find someway to get applets running under both Windows and OSX with the pluggin2.

19  Java Game APIs & Engines / JOGL Development / Re: JOGL is dead. Long live JOGL on: 2009-11-10 19:49:58
Long live JOGL, and sorry for sounding the death bells too soon!  I'm also sorry to hear about your situation Sven, but probably it wouldn't have been much fun working for Oracle if they didn't have the focus on the things you enjoy.  It's really great news though that you are willing to continue putting personal effort into keeping JOGL alive.  I fear it's gonna need a lot of effort to keep the community alive though, having lost official Sun backing.

Of course this change raises many questions:

*Is JOGL the name, licensed or free to use? or are we back to GJ4Java and CL4Java or even LWGLandCL4Java Wink
*will deployed applications referencing the sun hosted binaries continue to work? for how long?
*How do we migrate the community away from here and kenai, it's already getting confusing... and in my opinion the sooner the better for a fresh start.  Maybe the rebrand would help in that case too...
*On the same note will Sun continue to host the JOGL and kenai projects?
*What's the chance of getting the much needed magical jar signatures as a truely open source project?
*And the one the really interests me, the future of NEWT?  Yes I'm still searching for the nivana of simple cross platform browser embedded JOGL games Smiley

Anyway I look forward to seeing what happens next.  I'd like to get more involved, but my speciallity is more Java than OpenGL.  But I'm always willing to do some mac osx testing once we have some binaries!  Come May I gonna be freed up from my current project and could offer more time if required.


PS how about writing a JOGL book as you continue with the migration/changes.  I for one would be interested in supporting your cause in this way Smiley  Same goes for JOCL et al.
20  Java Game APIs & Engines / JOGL Development / Re: JOGL2 Newt future on: 2009-11-06 21:30:27
I think the lack of positive feedback, or 'official' feedback into this thread says it all.  I'm kinda sad today, I had some high hopes of JOGL one day catching up with flash.  The newt deployment option sounded like a good chance to have some simple, super fast cross platform browser embedded 3D apps.  Although the plugin2 under osx seems to have also fallen through the cracks right now. sigh. Is there enough community involvement to keep JOGL alive?  I'm kinda stuck in limbo now wanting to finish & release a small game, but I was really hoping I could go embeded browser rather than webstart again.  The whole applet fallback approach just wasn't working.  Anyone care to have a go at writing a demo gears embeded JOGL app that runs across at least windows and osx?  with descriptions for config and required dependencies from JOLG2... basically the part 2 of the applet blog Sven never got around too...
21  Java Game APIs & Engines / JOGL Development / JOGL2 Newt future on: 2009-10-23 21:22:17
With all the reorganisation/uncertainty at Sun,  are we likerly to see further progress?  Sven's site was down recently and rolled back to exclude the newt blog.  Does that mean work has stopped?  Is someone still driving JOGL or has the focus shifted to FX?  Would be a shame to see things fade again after all the great progress recently.
22  Java Game APIs & Engines / JOGL Development / Re: NEWT widgets on: 2009-09-16 12:58:42
Perfect! that's exactly what I was looking for.  Thanks for the tip.

23  Java Game APIs & Engines / JOGL Development / NEWT widgets on: 2009-09-15 21:31:23
Can someone explain a bit more about NEWT please.  I understand that it can provide JOGL with a native window for drawing into.  Which avoids uglyness around AWT and is probably a lot more performant.  But what more can it offer.  From the javafx package it looks like some key event handling is about all?  So what are people doing for widgets in that case? can swing render into a NEWT window? or are there some NEWT widget libraries? or SWT? or do I need to investigate something pure OpenGL based? I need buttons, textentry, drop downs, dialogs, labels, icons/images and check boxes.  I can live without layout managers Smiley  But it seems like migrating from a swing client might be tricky?  Advice appreciated!
24  Java Game APIs & Engines / JOGL Development / Re: Plugin 2 under OSX Snow Leopard on: 2009-09-15 10:01:48
$ java -version
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)

But you can easily change to 32 bit in the Java Prefferences application.  The above is default under SL, the below is switching to 32bit

$ java -version
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
Java HotSpot(TM) Client VM (build 14.1-b02-90, mixed mode)

Safari doesn't even seem to handle webstart after the update Sad but I had that once before after an update, and I just had to manually install the Java updates from apple... handy.

So my testing is mostly with Firefox, which handles the webstart, but doesn't seem to handle the pluggin2 stuff.  I just get the CompatibilityApplet as coppied from So basically it seems to ignore the <param name="jnlp_href" value="/game/game.jnlp">

If I try to access that jnlp directly with the full URL, the app starts and  I get my JOGL canvas displaying, but all the swing components are missing, argghhh!  plus there is alot of white being drawn/redrawn.

So is this just me, or does someone have a this all working under OSX SL?
25  Java Game APIs & Engines / JOGL Development / Plugin 2 under OSX Snow Leopard on: 2009-09-10 07:19:23
If the rumours are true, there should be plugin 2 support under OSX... Well I upgraded to OSX SL yesterday, nice to have Java 6 at last! but has anyone found the plugin 2 support???
26  Java Game APIs & Engines / JOGL Development / Re: TextureIO creating flipped textures? on: 2009-09-08 20:20:20
I ended up with your idea, thanks! Smiley
BufferedImage image =;
                texture = AWTTextureIO.newTexture(image, true);
27  Java Game APIs & Engines / JOGL Development / Re: understanding removeAll impact on GLCanvas... on: 2009-09-08 18:42:09
It's a bit more than that.  I'm switching between a jpanel with a canvas+jbutton, a jpanel just with only jbuttons, a jpanel with just a canvas, and a few other combinations.  Sounds perfect for cardlayout, apart from they are all different sizes, which leaves me with removeAll as my only choice, or some ugly padding in smaller panels in the cardlayout.

update: I'm starting to suspect my texture code now.  I thought I had textures loading only once, but it seems more like i call TextureIO.newTexture and enable for the first frame in every canvas derivative.  So what's the correct way to share Texture objects? should I be calling disable at some point before using in second contect?
28  Java Game APIs & Engines / JOGL Development / Re: understanding removeAll impact on GLCanvas... on: 2009-09-08 05:47:58
well it was late by the time I got back to the code.  But from what I can tell it's Textures that get lost (I'm now using TextureIO). The geometry seems to render fine still.  Also I use a text renderer which only renders a blank white box after being removeAll'd.  The rest of the scene is unaffected, its only this small side panel that is damaged.

Thanks for the tip with PBuffers, but I already had an issue trying to use these, that many players graphics cards didn't seem to support them, or maybe I was doing something horribly wrong with them...

In general though, should a removeAll work in the way I'm trying to use it?
29  Java Game APIs & Engines / JOGL Development / Re: understanding removeAll impact on GLCanvas... on: 2009-09-07 09:07:48
update. I'm using a shared context between all the canvases, and I wondering if this is related to textures.  I'm gonna have anothe rplay later today and see if I can track down whats going on.
30  Java Game APIs & Engines / JOGL Development / Re: TextureIO creating flipped textures? on: 2009-09-03 09:30:35
I pulled my model and .png back into blender and it looks fine.  So it must be TextureIO class.

update: I just had a look at the method you mentioned getMustFlipVertically().  That's returning true! which I assume means that TextureIO is doing the flipping.  I would expect to see another method to correct this, but can't find anything so far.

The TextureCoords approach won't work for me as far as I can understand it.  I'm multiplying up my texture co-ords to point to different bits of my texture.  I could flip my text coords at that point, but I'd rather have the texture the right way around in the first place.

So what's the best approach for flipping the Texture? or does it have to remain flipped for internal workings?
Pages: [1] 2 3 ... 5
EgonOlsen (37 views)
2018-06-10 19:43:48

EgonOlsen (20 views)
2018-06-10 19:43:44

EgonOlsen (39 views)
2018-06-10 19:43:20

DesertCoockie (186 views)
2018-05-13 18:23:11

nelsongames (122 views)
2018-04-24 18:15:36

nelsongames (121 views)
2018-04-24 18:14:32

ivj94 (861 views)
2018-03-24 14:47:39

ivj94 (122 views)
2018-03-24 14:46:31

ivj94 (758 views)
2018-03-24 14:43:53

Solater (139 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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!