JOGL app failure rate

OpenGL Development JOGL Development
#1

Warning: This long message will wear you down and make you cry and beat you into submission, and for all the work of reading it, you won’t learn any cool opengl tricks for making reflective quantum bump mapping VBP’s (that’s a VB0++).

I spent a good amount of time building a game using jogl, and while I am definitely glad that I can now work with open gl, and I feel my games concept is pretty solid, but the thing that kills me the most is I seem to have a problem where the game only runs on about half the machines that try to run it, as a webstart program the fail rate went up at least a little bit (I think webstart has that old flaw from the JVM where it uses a lot of d3d devices instead of re-using a single one which was hell on ATI cards among other problems). A typical problem is the dreaded white screen which happens on some computers when going to full screen mode (no errors are generated, and my code is still running).

Is it possible I’m losing the GL context somehow, I read in a nehe tutorial (31 on milkshape loading) something about changing display mode causes the opengl context to be lost, and init to be called again… but texture files might have to be loaded all over. Is it possible this type of behavior would cause a screen to go all white (keeping in mind that I use colors and textures… so even if the textures didn’t load, I’d still have colored objects and lighting should also exist). I do not keep references to the GL variables (though I’m using a textureloader posted in this forum and it keeps a reference, but I don’t think this is an issue since it’s created in init which if the gl context is lost should be called again… and textures are loaded in display methods only and in init… I’m altering the textureloader to not keep a reference to gl anymore too). My rendering loop is setup to print out opengl error’s and has a catchall for any throwable that is uncaught in the code (which causes some strange things to happen when there is an exception but at least I get a real error instead of the meaningless one that gets printed if an exception propagates up to jogl). So far no one who has a problem running it seems to be getting any errors at all, this is hard to verify though because most people probably aren’t familiar enough with their computers to be walked through turning on the console and logging.

I have to admit I’m using the oldest jogl files as I know in at least one case the newer ones wouldn’t work, anyone have success stories about using the newer jogl binaries instead of the originals? All of the binaries seem to work fine on my computer.

Basically I’m facing two big disasters, the important one is the failure to run ratio which I believe is tied to jogl… and then the other one that seems to be an issue is the warning on webstart apps… sun should consider toning that down a bit, to approximately the same level as IE for downloading an exe file, I mean seriously, if I had a nickel for every time I read a story about how someone couldn’t get their own mother to run their webstart app because of that warning, I’d have at least 10 cents.

#2

Your latest JNLP works fine on my system!

Not really answering your questions, but do you use JInput to poll the mouse position?

On the whole, it would be nicer if the game were a bit faster - maybe introduce incremental speed increases over time. All scenes/levels were smooth and free of any opengl errors (I ran the app in windowed mode).

#3

I’m actually using standard MouseListeners and KeyListeners, you think this could be a problem? I read up on JInput and it seemed that the biggest value there was being able to support hardware like joysticks and maybe headsets, nothing I have placed value on.

The game speed is much faster on normal difficulty and hard, but the game defaults to easy (which is SUPER easy), I’m assuming that’s what you meant by speed. (To change the difficulty start a new game). I’m going to change the starting difficulty to normal though I probably won’t update the webstart unless I think I’ve figured out a way to get the game to run on more computers.

EDIT Meant to say I don’t think my JNLP file has any problems anymore, it’s just something that is wrong with webstart that causes additional problems with JOGL (I don’t really have numbers to support this since I only know of one sure case where webstart stopped it from working where the application ran fine). I also don’t have solid numbers on how many people just fail to run the game in general so it’s kind of hard.

#4

failed going full screen on my laptop. ati m9 video card

app was still running, but the windowed screen was white and my back ground wqas every where else

nathan

#5

So, have you developed a sort of polling system within your mouseMoved method so that you only listen to the movement input if the distance delta is greater than x or if a specific time delta has elapsed?

Game difficulty: Yes, i forgot about the other difficulty levels - much faster arcade style action! ;D

Remember, WebStart is installed by default on OS X!

#6

nlmueng: That’s one of the problems my sister hit on her laptop, it also had an m9 vid card I think (it was intel I think). This was a problem only when the display mode was changed, which kind of points to my theory that the opengl context is lost and it’s messing up something. Would you try running it again, switch to fullscreen and back and see how many times you see init: in the console (it should print init:1 and if it gets called again init:2)?

#7

About my mouse handling, I actually just move the paddle every time the mouse triggers a movement event. I have a formula I worked up that tells me where on the screen the mouse is…

Global Vars
canvas is a class that implements GLEventListener.
scene.MAX_BOUNDS = 5f;
scene.MIN_BOUNDS = -5f;
The min and max bounds are the edges of the screen, I have translated away the exactly amount of space so that this is true (I think I translate -6.5).

Local Vars
incX and incY is how far each pixel of movement by the mouse translates in the scene. Basically 10f / bounds.width - bounds.x (window width - window insets).
mouseX and mouseY are the translated values, the x and y coordinates of the mouse multiplied by incX and incY + the min_bounds (-5) since the left edge of the screen is -5… The * -1 is to flip the y since openGL coords are different than the coords used through most of java (or to compensate for some really stupid math I probably did somewhere else but who knows, it’s not broken and I won’t fix it).

And probably the most important thing to learn from this… is I think gluUnProject will give you mouse coordinates somehow too, which is probably slow (since it would be asking opengl for info instead of just telling it stuff)… but would probably work regardless of how much of your scene fills the screen…

#8

i get this error, did not notice it last time, it was behind the game window:

java.lang.IllegalArgumentException: Invalid display mode
at sun.awt.Win32GraphicsDevice.setDisplayMode(Unknown Source)
at com.gufbal.dan.breakout.CustomAnimator.run(CustomAnimator.java:94)
at java.lang.Thread.run(Unknown Source)

i tried hitting the menu item to switch back to windowed but it did not do anything, could be because of above error

nathan

#9

The video mode it tries to set is 640x480x32 color unknown refresh rate, I’m assuming that mode is supported by your card (just like my sisters laptop)? She never told me of any console errors though but if you close the game the console exits too so maybe she just never saw the console after going full screen.

My code does not do any checking to see if the 640x480x32 mode is available, it only checks for fullscreen support and mode change… which is kind of naughty on my part, but like I said, a mode test reports the mode as available. Have you been able to run any other JOGL apps that use fullscreen on your lap top (I um, don’t actually know of any off hand, I think the xith games use JOGL so if you tried survivor successfully I think that’d count).

#10

yeah, i have written/run different jogl apps that go full screen fine on my laptop.

nathan

#11

Sorry for not responding earlier.

Given that you are specifying the system property sun.java2d.noddraw=true in your JNLP file, I think the issue must be in JOGL, probably either the OpenGL context management when a window is created / destroyed / recreated or the pixel format selection code, which is most problematic on older machines.

A fairly significant bug fix to the OpenGL context handling code was recently put back into the JOGL source tree on java.net which should hopefully fix the first set of issues. The second issue, choosing a good pixel format in more situations, is still open. Mojang Specifications contributed a new GLCapabilitiesChooser algorithm a couple of months ago but it hasn’t been reviewed for possible checkin yet. This code is pretty fragile; I think several applications broke when the JOGL 1.1 betas were released, and I think that most of the reported issues are still present. I believe that LWJGL may do a better job choosing a valid pixel format / visual than JOGL does, at least in some cases, though I’ve heard of failures choosing a valid pixel format with both libraries.

If you have a chance to try downloading and compiling the current JOGL source tree and could try it out on some of the machines where you’re seeing failures, please post and let us know whether the current sources are more stable and work in more configurations. They should. I’ll also try to post a new JOGL 1.1 beta in a couple of days containing all of the recent bug fixes.

By the way, your JNLP file works fine on my system and your game looks pretty cool. We should set up a JOGL applications page on java.net and link off to all of these nifty applications and games. Does anybody have some spare time to help set this up?

#12

I solved the “white screen of death” by following Mithrandir’s warning about not attaching the glCanvas until after the frame is visible.

[quote]You may have run into a higher level problem with the code initialisation order. JOGL requires some very specific ordering of instructions otherwise a lot of stuff just fails to even get going. For example, don’t try to add the GLCanvas before the main Frame has been made visible, etc. What this ends up translating to is that the GLContext may be available on one card before it is on another, so code that works on one machine doesn’t work on another.
[/quote]
I hope you’re also following my thread on “Uncontrolled flicker” where we’re also dealing with app failures in the newer releases of jogl.

#13

The video mode it tries to set is 640x480x32 color unknown refresh rate.

Uhm… some cards only offer 24bit (which is actually the same - there is no alpha). So check all 640x480 modes and pick the one with the highest bpp.

#14

I was adding the canvas before the frame was visible, is this considered a bug or is this just something we need to know to avoid a problem that can’t be fixed in the api?

I haven’t been working on this game for a while, I had started a simpler game idea (well, basically a 2d game, cause it’s hard to get simpler than the game here) so I haven’t really done anything with the breakout game lately, I think in the systems where there has been a problem it’s actually a result of using refreshrate unknown and not the color depth. refreshrate unknown (aka 0). I assumed that an unknown refresh rate would just accept whatever the default refresh rate was or possibly the preferred refresh rate of the card or something, when it actually is a specific video mode. I have not built in a chooser for a graphics mode yet, which is next step to fixing the problem.

When I go back to updating my breakout game I will try any new binaries that are released, compiling from source isn’t really my cup of tea (and I lack the tools to compile anything other than java).

#15

Hi,

I am looking at the Gears demo source code from https://jogl-demos.dev.java.net/source/browse/jogl-demos/src/demos/gears/Gears.java and it looks to me like the GLcanvas is being added before the frame is visible. By “visible” I take it you mean that the show() method has been called? Or do you mean “displayable”?

Abridged gears init code below:


public static void main(String[] args) {
    Frame frame = new Frame("Gear Demo");
    GLCanvas canvas = GLDrawableFactory.getFactory().createGLCanvas(new GLCapabilities());
    canvas.addGLEventListener(new GearRenderer());
    frame.add(canvas);
    frame.setSize(300, 300);
    final Animator animator = new Animator(canvas);
    frame.addWindowListener(...);
    frame.show();
    animator.start();
  }

I have tried adding the canvas after the show() and various other combinations, but unless the “frame.add(canvas)” appears before the “frame.show()” all I get is the white screen of death.

I have another large JOGL app live on the 'net that follows the same pattern as the gears demo, and it works for the vast majority of cases (the rest are Intel and ATI problems discussed in the “uncontrolled flicker” thread).

What gives?

#16

Issues like application hangs due to slightly different orders of instantiation of GLCanvases and starting of Animators should be considered bugs in JOGL. Please file issues you find in these areas and attach test cases. The JOGL 1.1 beta 4 release may behave better in this area.

#17

Is there something wrong with adding them to JGF? Right now the auto-generated JOGL page is showing a mere four games that use it (Wurm, S-Type, Martian Madness and Survivor - the last two using JOGL as the renderer for Xith).

If you want games added, it’s only a couple of minutes effort to send a description + screenshot + some info.

Or is this a political thing, that you don’t want the JOGL games list to be on a non-Sun website? Sounds crazy, but I’m surprised you had no idea about JGF’s game-listing ???

PS: the last Sun-sanctioned volunteer for anything similar was Gregory Pierce (sp?), and despite my efforts to co-operate with him I don’t believe he’s made any progress since February (due to being too busy with dayjob AFAICS)

#18

[quote]Or is this a political thing, that you don’t want the JOGL games list to be on a non-Sun website? Sounds crazy, but I’m surprised you had no idea about JGF’s game-listing ???
[/quote]
No, it’s just ignorance on my part. Where is this list kept?

#19

Link is in his signature:

http://grexengine.com/sections/externalgames

If you go to technologies and JOGL, you should see what he’s talking about.

#20

Oops. Obviously, we need a new marketing dept :wink: :P. I suppose one marketing person would be an improvement ::slight_smile:

FYI, each technology’s page is auto-generated as a standalone page (I know that some people link to the individual techs because it shows up in the referrer logs), and the FAQ has the same dedicated-page thing going on - so you can jump directly into whatever info we have on JOGL here:

http://grexengine.com/sections/externalgames/tech-page-JOGL.html

(and, BTW, if you have any more information to add on JOGL I’d love to update that description - it was taken from the official page on java.net a while back, and is looking a bit too brief compared to some of the other techs which have lots of description…)

PS the games are supposedly sorted alphabetically, but I’m having problems with XSLTproc at the moment…)