Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (525)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (593)
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 4
1  Java Game APIs & Engines / OpenGL Development / Re: OSX: stuck in full-screen after java exception on: 2011-01-09 12:47:25
Remember in LWJGL, Cmd-Q is actually processed by you not by anything else. You have to explicitly detect it and call System.exit()

Thanks, and well, it looks like I was not totally aware of this fact...
Part of digesting the LWJGL pill I guess Smiley
2  Java Game APIs & Engines / OpenGL Development / Re: OSX: stuck in full-screen after java exception on: 2011-01-09 12:07:08
Thanks, Mr. Gol, for the info but I'm not sure it is relevant.

Right now, the situation with LWJGL on OSX is that the application exits automatically when cmd-Q is pressed.
You don't have to code anything fancy for that, it behaves just like Alt-F4 on Windows...

The problem is when some uncaught exception occurs: cmd-Q is not working anymore.
I was hoping I could bring Eclipse's window to the front by using Alt-Tab, but no: I'm stuck in full-screen and the only way out is to turn off the Mac.

Right now, it seems like there is no magic-trick to solve that situation (i.e. without the need to do some preemptive exception catching...)
3  Java Game APIs & Engines / OpenGL Development / Re: OSX: stuck in full-screen after java exception on: 2011-01-08 19:42:54
The point here is not how to protect users from uncaught exception. It is more like: how to make a developer's life easier, in a world where unpredictable exceptions occur on a daily basis, while developing...

But I see your point: you mean that by putting the "main loop" inside try/catch should catch most of the exceptions and exit gracefully?
Ok, I accept it, but still I wonder what would happen if some exception take place inside another thread (e.g. some http stuff...)

And from a Jogl developer standpoint, it is strange at the first place that cmd-Q cease to work at some point.

Could it be related to the way LWJGL treats full-screen windows on OSX? (and to the point that no "system overlays" appear on top of the screen, e.g. when changing the Mac's volume?...)
4  Java Game APIs & Engines / OpenGL Development / OSX: stuck in full-screen after java exception on: 2011-01-08 18:29:24
Usually, when running full-screen on OSX, it is always possible to leave the app by using cmd-Q.

The problem is when some uncaught Java exception occurs: cmd-Q is not working anymore and the only possibility I found to leave was to shut-down the machine.

Any clues?

Thanks,
Ariel
http://chronotext.org
5  Java Game APIs & Engines / OpenGL Development / Re: Are LWJGL applets supposed to work on Snow Leopard using Firefox? on: 2010-08-02 16:43:14
yes this is the workaround highlighted in the thread linked above and fix for mac issue 3) that i pointed out.
Using "Run Applet in their own process" will make browsers use plugin2 (and hence the new renderer that breaks JOGL/LWJGL applets) and setting it off will switch to plugin1.

I don't know...
Toggling between these 2 options in the Java prefs never had any immediate effect (only some voodoo echo after n restarts...)

Now I'm not sure why its failing for you on firefox, but could you try see if Final Kapster works for you. If so I might have a solution for you.

No, it's not working here in Firefox (same pixel format exception...)

The thread containing the information about apple breaking JOGL/LWJGL Applets can be found here.

arielm: From your description it does not sound like its related to the above problem, since that only effects plugin2 and not plugin1.

Yeah, my "problem" seems to be exactly the contrary of all the mentioned discussions, since everything always works fine in Safari, but almost never in Firefox.
6  Java Game APIs & Engines / OpenGL Development / Re: Are LWJGL applets supposed to work on Snow Leopard using Firefox? on: 2010-08-02 16:24:23
[IN RESPONSE TO CAS - RESPONSE TO KAPTA COMING SOON...]

Strange!

Minecraft worked in Firefox.
And then, the official LWJGL Gears applet started to work as well...

But then, I made a restart and now, none of them are working (the same old "org.lwjgl.LWJGLException: Could not create pixel format"...)

Actually, this kind of voodoo already happened to me yesterday: suddenly, every LWJGL or Jogl applet is working. But then, after a restart: poof, nothing is working again.

My theory?
From time to time, I go to the Java Prefs and I toggle between "Run applets in their own process" and "Run applet within the Browser process".
Then, I restart the browser, but usually: nothing is changing.
But then, eventually, after a restart or two, my "toggle operation in the prefs" is somehow having some positive effect (however, the positive effect in question is only temporary, until the next restart...)

It could be related to the "created and removed symlinks" mentioned in that same old Apple note.

Sounds bad, especially from the end-user standpoint (I guess I'm not the only MacBook pro owner affected...)
7  Java Game APIs & Engines / OpenGL Development / Re: Are LWJGL applets supposed to work on Snow Leopard using Firefox? on: 2010-08-02 15:18:16
Thanks Cas, even though I'm even more confused than before! The thing is that everything works fine, actually in Safari.

The problem is in Firefox: LWJGL and JOGL seem to suffer from the same "can't create pixel format" problem.

And now you say that Safari uses plugin2 while Firefox uses plugin1.
It means that my problem is actually not related to "Apple's recent change in plugin2 architecture".

Doh...
Anyone else affected?
8  Java Game APIs & Engines / OpenGL Development / Re: Are LWJGL applets supposed to work on Snow Leopard using Firefox? on: 2010-08-02 14:33:15
Well, at least it seems to be a problem common to Jogl, namely: the change in "Plugin2 Graphics Rendering" introduced lately by Apple...

However, I still don't get why LWJGL and JOGL are working in Safari but not in FF.

I also don't get why the following is not making any difference on my MacBook pro: going to the Java Prefs and toggling between "Run applets in their own process" and "Run applet within the Browser process", followed by a browser (or even a machine) restart...

Bah, nothing new (Java + OpenGL in the Browser == Quest for the Holy Grail)
9  Java Game APIs & Engines / OpenGL Development / Are LWJGL applets supposed to work on Snow Leopard using Firefox? on: 2010-08-01 14:32:31
I wanted to give LWJGL a try, skipping directly to applets (webstart is not an option anymore for now...)

I'm using the basic Gears demo as a test ( http://lwjgl.org/applet/ )

So far, it works fine on 3 different Windows machines (using FF and Explorer...)

Unfortunately, it's another story on my MacBook Pro (Snow Leopard 10.6.4; Java 1.6.0_20; NVIDIA GeForce GT 330M):

- It does work, using Safari 5.0

- It does not work, using FF 3.6.8, with the following log:

MRJ Plugin for Mac OS X v1.0.1
[starting up Java Applet Security @ Sun Aug 01 16:52:13 IDT 2010]
Sun Aug 01 16:52:14 IDT 2010 JEP creating applet org.lwjgl.util.applet.AppletLoader (http://lwjgl.org/applet/)
org.lwjgl.LWJGLException: Could not create pixel format
   at org.lwjgl.opengl.MacOSXPeerInfo.nChoosePixelFormat(Native Method)
   at org.lwjgl.opengl.MacOSXPeerInfo.choosePixelFormat(MacOSXPeerInfo.java:55)
   at org.lwjgl.opengl.MacOSXPeerInfo.<init>(MacOSXPeerInfo.java:50)
   at org.lwjgl.opengl.MacOSXCanvasPeerInfo.<init>(MacOSXCanvasPeerInfo.java:49)
   at org.lwjgl.opengl.MacOSXDisplayPeerInfo.<init>(MacOSXDisplayPeerInfo.java:48)
   at org.lwjgl.opengl.MacOSXDisplay.createPeerInfo(MacOSXDisplay.java:246)
   at org.lwjgl.opengl.Display.create(Display.java:853)
   at org.lwjgl.opengl.Display.create(Display.java:783)
   at org.lwjgl.opengl.Display.create(Display.java:764)
   at org.lwjgl.test.applet.GearsApplet$1.run(GearsApplet.java:54)
Exception in thread "Thread-9" java.lang.NullPointerException
   at org.lwjgl.opengl.GL11.glClear(GL11.java:585)
   at org.lwjgl.test.applet.GearsApplet.drawLoop(GearsApplet.java:196)
   at org.lwjgl.test.applet.GearsApplet.gameLoop(GearsApplet.java:136)
   at org.lwjgl.test.applet.GearsApplet$1.run(GearsApplet.java:59)

I'm using the "defaults settings" in Java Preferences, since I'm looking for a solution that works "out-of-the-box" for the average user.

Any clues?
Thanks!

Ariel
http://chronotext.org
10  Java Game APIs & Engines / JOGL Development / Re: JOGL Installation on MAC OSX - No Matching Architecture in Universal Wrapper on: 2010-03-31 22:49:16
Happy to hear about the -d32 trick!

I previously tried to send a Jogl 1.x application of mine to someone running Snow Leopard and it didn't work (the well-known "missing architecture" problem...)
Unfortunately, trying to convert the application to Jogl 2 was a nightmare (finally gave up...)

Now, sorry for the ignorance (backed-up by a lack of access to Snow Leopard), but I have this Mac newbie question:

My preferred mean of packaging the application for "easy end-user installation" was to make an executable Jar file.
Now, if have to use a VM argument, the solution is probably to invoke java on the command line.

On window, I would just send a .bat file for the guy to double-click on.

But on Mac, it sounds more complicated, like:

- send a .sh file
- ask the guy to open a terminal
- ask the guy to "sudo su"
- ask the guy to "chmod +x" on the script
- and then only: have him execute the script

Or is there any simpler mean that I hopefully missed?
11  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-11 13:09:35
I've played around with GWT a bit and quite liked it in a way, although I also write JS when I write JS.  Praise be to jQuery, but I digress.

You're not digressing actually...
John Resig, the man behind jQuery is also the man behind Processing.js (which is already proposing some kind of GWT-like magic-transform between Java and JS...)
12  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-10 13:36:51
Indeed. But I think that the actual application of WebGL is probably slightly more limited than people may be making out. It's not like suddenly everyone's going to become a 3D guru overnight. It's quite a specialist sort of field, hard even for ordinary computer scientists, and ordinary computer scientists are already an order of magnitude more cleverer than the web luvvies who currently crank out Flash.

I think your analysis is wrong.
It is not a problem of who is capable to become a 3D guru.

Take a look a the work of Robert Hodgin (aka Flight 404).
How would you define him? Scientist? Graphic Designer? Programmer slash Computer Graphics?

Well, he's all of this at the same time. No need for arbitrary boundaries.
One sure thing is that he started as a Graphic Designer. And then came Flash...

So in a sense, Flash did more for the democratization of programming among creative people than any other platform before.
Then came Processing, which introduced some of these "hybrids" to Computer Graphics in general (and by the same occasion to Java and OpenGL)

In comparison: the average "designer + potentially great programmer" is usually not ready/willing to jump the C/C++ or Java barrier.
Too complicated and not sexy enough...

In that perspective, WebGL have a huge potential, in term of the democratization of Computer Graphics Programming (and we're not talking about games only...)
(Providing you believe that people are smart by nature, but that's a philosophical debate  Wink )
13  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-04 22:24:38
My only hope is that Google will absorb WebGL into GWT and allow me to to program against WebGL via Java.

Makes perfect sense. Be sure that someone is working on the topic out there  Wink

We even don't have to wait that Google propose an Eclipse integrated way of writing Java+OpenGL code automatically translated to JS+WebGL...
The wonder boys of the new JS world (TM) have already reached the required level of wizardry.

If you're not convinced, take a look at Processing.js:
http://processingjs.org

And in particular the Web IDE:
http://processingjs.org/learning/ide

In short:
- They built a small JS + HTML5-Canvas library, which simulates all the 2D stuff that you can do with the "real" Processing.
- In parallel, they have a very simple JS layer which translates code written in the original (Java based) Processing syntax into JS.
14  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-04 14:01:48
All what you say, Cas, makes perfect sense.

There could be a kind of "rebirth and glory" period for Java in the Browser, but it won't last forever.

At some point, browsers (Desktop and Mobile altogether) will become plugin-less, and it will be the end of Flash, and of Java-in-the-browser.
How and why? Ask Google and Apple... They lead (much better than Sun), and the world is following (their visions are simply truly user oriented...)

In that perspective (and for sure it's a matter of long term), WebGL is interesting.
Not especially as a mean to produce 3D games.
But more like a generic Hardware Accelerated Graphics Library for the browser, truly integrated with any aspect of the the web experience.

Then, the following equation for "world domination" suddenly makes sense:

1) Windows, OSX, etc. become Chrome OS
2) Java, C++, etc. become Javascript
3) Direct-X, OpenGL, etc. become WebGL
15  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-04 11:21:23
Javascript is a god awful pile of shit.  And it's slow.  Seriously, I do web development for a living, Javascript is my main language and it's just awful.  I wouldn't code a game in JS unless I was paid to.  And paid A LOT

I know exactly what you mean. I myself did a lot of JS once.
But take a look at the big picture...

Regarding the "development side", no doubt: working on OpenGL projects with Java and tools like Eclipse rocks. It's a developer's nirvana (to which everyone in this forum is addicted...)

Regarding the "deployment side": Java on the Desktop is a failure, for all the reasons already stated in this long thread. The bottom line is that you hardly reach any end-user.

Inversely, on the WebGL side: development  is probably going to be much more painful. But deployment is going to rock. It will take time, but at some point: any web-page out-there will provide OpenGL surfaces mashed-up with web 2.0 live data sources. And this sounds as a much more effective opportunity to reach end-users.

So what is more important? Having fun developing stuff, or end-users having fun with what you developed?


Of course, we would like to have the best of the two worlds. For example, like Spasi previously proposed: a Java applet on one side, communicating inside the browser with a WebGL surface.

Is that the last opportunity to "make it"?
Or is it doomed already (Apple plays an important role in the WebGL initiative, and we know what their opinion on Java is...)
16  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-03 22:25:18
- support for the magic certificate

Was ist das?
good for jogl or lwjgl?
17  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-03 21:43:17
One of the other bits, plugin2, only came recently

What so special about plugin2? (no irony, just one 1 year of Jogl inactivity...)

I understand that applet performance have been enhanced...

How about certificates? Are they still required for OpenGL content?

And the long delay before the first VM launches: is it much shorter than once? Does it still freeze the whole browser (for a second or two ) like once?

18  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-03 18:51:31
It seems like we're getting a bit off topic.  I think it's a waste of effort worrying about other languages gaining on java

Jogl and LWJGL are here for years, but still, the "expected breakthrough" did not happen yet.
Do you think that re-doing "more of the same" is the solution?

In the context of a big reformating, the subjects we have approached are actually very on topic.
I guess it's all about keeping what we like (obviously: Java and OpenGL) while "not missing the right train" this time...
19  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-03 17:55:19
So WebGL is definitely a technology to watch out for.

Yep, and my stack of topics to test is growing and growing :-)

One thing I'd definitely like to check with WebGL is which kind of "low-level" control it provides.
In term of paradigm, is it more like Jogl or Java3D?
20  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-03 15:49:45
As of today: I guess it's possible to state that standard web browser Javascript execution on the Desktop is actually blowing away Java running on any Android device.

And still, many people out there enjoy OpenGL on the Android platform (and it's just a beginning...)

All this to say that Javascript execution speed is not necessarily the main bottleneck.
I'd say it will depend on how smart and open is the WebGL standard, and of course on how much time it will take to be adopted by developers and users...
21  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-03 14:24:09
He's working on WebGL. More reason to sort this situation out and start pushing for Spasi's idea above Smiley

Gosh, the world is moving too fast with Apple and Google in the house!

Javascript (as did Flash's ActionScript over the years) is becoming faster and faster (see it in Chrome...)
Now add OpenGL acceleration (exactly what Flash is still missing): that's it, we're there (i.e. a point where the need for Java can be by-passed...)
22  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-03 12:31:05
The webstart 'download stalled' problem is annoying, but it doesn't happen often in my experience with small 5mb apps.

It happens for me all the time, on tiny apps (a few hundred Ks)

since java6u10 plugin2, applets now work at least as well as webstart. As more and more computers are upgraded to 6u10, applets will only get better

I have to admit that I never gave Applets a chance with Jogl...
I will make a test to see how it works on our "problematic platforms" (namely Macs with Java 1.6 and PCs with Intel GPU's...)

That was such a pity. I wonder what he's working on now?
I hope Ken is working on making OpenGL charged Android apps available on Java enabled desktops Wink
23  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-03 11:41:47
Java is installed on 91% of the desktop computers whereas Flash is installed on 92%

You're quite of an optimist monsieur.
But anyway, user-experience wise, you can't compare the overall "Java on the Desktop" experience with what Flash has to offer...

Java Web Start reflects the state-of-the-art of what Sun is capable / willing to propose on the Desktop.
It's been here for years, it sucks (user-experience wise) and it's broken.
Logical conclusion: it's never going to be better (confirmed by the recent drop of Jogl by Sun...)

Therefore, don't use Java Web Start, nobody forces you to do this

I don't believe in that direction either.
We live in Browser Land, and the future will be even more browser-based (think Chrome OS...)

In my humble opinion, the hope _ in term of Java + OpenGL _ resides in Android. Not exactly as it is today but in the not-so-far future (when Android enabled devices become bigger, with decent GPUs and JIT compiling...)
Let's try not to miss the train this time!
24  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-03 08:58:37
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 Agree...
Fixing JOGL is one thing, but when we look at the overall user-experience of accessing some JOGL/LWJGL content on the web, the situation is almost hopeless:

1) Java is far from being installed everywhere. Many reasons for that:
- poor content offer
- installation is not seamless (as Flash is...)
- lack of clear "Desktop Strategy" from Sun, etc.

2) The "Java Web Start Experience" sucks:
- It takes ages until the JVM is (first) loaded
- The jar downloading process is painful (we all know the "download stalled" issue, regardless of the quality of the connection)
- The need for certificate is a big annoyance both for users and developers (3d content should not require any certificate)

Well, nothing new. People have been discussing these issues for years.
I'm reading here and there that OpenJDK could solve (on the paper) many of these problems, but frankly, I don't believe in a massive world adoption...

Any hope doc?
25  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2009-12-02 12:47:00
1) Direct-J
2) J-Extreme
Smiley
26  Java Game APIs & Engines / Android / Re: Mipmap generation must be done manually?! on: 2009-12-01 15:38:25
Cool!

So when you do
float e = x * x + y * y + z * z + w * w
it implies a gamma factor of 2.0?

I know that the gamma factor varies depending on the kind of screens (notable differences between Macs and PCs...)

In any case, I will definitely test all this on an AMOLED screen (Galaxy) and also on the iPhone, then post the results...
27  Java Game APIs & Engines / Android / Re: Mipmap generation must be done manually?! on: 2009-12-01 15:07:18
This code is slow ( 1 sqrt per pixel ), but takes into account gamma correction

Sounds (and looks) great!
I wonder if gamma correction is helpful for grayscale images?

In any case, I may execute this kind of computing off-line (with Android slow Java VM, "more data to load" should be faster than "more data to compute"...)
28  Java Game APIs & Engines / Android / Re: Mipmap generation must be done manually?! on: 2009-12-01 14:01:29
If your just box filtering, then the previous level is what you want...otherwise it depends on your filter.

What do you mean by box filtering?
My main usage is the manipulation in 3d of photos and text (where each letter is a texture in alpha mode...)

For text, the two fields that matter are:
1- small text (i.e. tiny mipmap levels) should be crisp
2- the transition between levels (i.e. when zooming in/out) should be seamless

I don't mind spending time on computation, as long as the mipmap generation is fine tuned for these needs...
29  Java Game APIs & Engines / Android / Re: Mipmap generation must be done manually?! on: 2009-12-01 12:51:12
Thanks Riven,

It is definitely helpful. If I read well, it is a special case of standard bi-linear interpolation optimized for halving...

While we're at it, what is the common way to solve the following in OpenGL land:

1) Scaling down the subsequent mip-map levels based on the original image
2) Or scaling down using the previously scaled pixels?

Quality wise, my common sense would vote for the first option, but I think that option 2 is the one mostly used.
30  Java Game APIs & Engines / Android / Mipmap generation must be done manually?! on: 2009-12-01 09:54:53
I guess it's not a scoop for most of the people here...

Anyway, I just found out that when running accelerated OpenGL on the Galaxy, glTexParameterx(GL11.GL_TEXTURE_2D, GL11.GL_GENERATE_MIPMAP, GL11.GL_TRUE) will simply not work (black textures...)

Same situation for older hardware like the G1...

It seems that the official workaround is to use GLUtils.texImage2D(...)
I'm planning to test it with RGB, RBG+ALPHA and GRAYSCALE textures.

The thing is that the image data must be passed as a Bitmap. Not a big issue when loading images, but sometimes you need to use your own byte-based data (and then: having to pass through bitmap conversion can be overkill...)

Something in the lines GLU.gluBuild2DMipmaps(...) could be helpful.
What are you guys using?
Pages: [1] 2 3 4
 

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

The first screenshot will be displayed as a thumbnail.

toopeicgaming1999 (67 views)
2014-11-26 15:22:04

toopeicgaming1999 (58 views)
2014-11-26 15:20:36

toopeicgaming1999 (12 views)
2014-11-26 15:20:08

SHC (25 views)
2014-11-25 12:00:59

SHC (24 views)
2014-11-25 11:53:45

Norakomi (30 views)
2014-11-25 11:26:43

Gibbo3771 (24 views)
2014-11-24 19:59:16

trollwarrior1 (37 views)
2014-11-22 12:13:56

xFryIx (76 views)
2014-11-13 12:34:49

digdugdiggy (53 views)
2014-11-12 21:11:50
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
java-gaming.org 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‑gaming.org
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!