Inexplicable Freezing

[Eliwood]

For one user with the following setup, my project worked fine about a month ago. Then the exact same code (he tried the exact same versions, previous versions) did not work. He says that the only thing he did between then and now is a game installation. He tried updating his drivers AFTER the problem occured, and that didn't help either.

The exact problem is that the LWJGL window is created, and then everything stops right there. It doesn't even reach the game code.

Here are his specs. Yes they aren't optimal, but keep in mind that the project ran perfectly fine just a month ago with the exact same code.

Compaq Desktop
500 MHz Athlon K7
128 MB RAM
Voodoo 3 video card
Windows 98
Sound Blaster PCI 128

Sorry if I can't be more specific because this is definitely a user-specific issue if it's this wacky in nature. None of my nearly 50 other testers experience this issue.

[oNyx]

It's most likely the graphics card.

Tell him that he should change the desktop bit depth from 24/32 to 16 or vice versa. Not sure if that will help tho, but it's worth a try, I guess.

[Eliwood]

He started on 32. Switching to 16 has no effect. He has no 24-bit setting.

I just find it utterly odd that the same thing would work a month ago and not work now.

Games published by our own members! Check 'em out!

[Matzon]

somekind of stacktrace or log of where in the java code things stop working would probably help alot.

[Eliwood]

somekind of stacktrace or log of where in the java code things stop working would probably help alot.

I can get the latter. The former is harder since no error is thrown. It just kinda stops for him right after window creation but around display mode selection (this is not the same guy as the one who got 10 second load times).

This is GTGE's code (where the problem is occurring thanks to my output statements).

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32

long start = System.currentTimeMillis();       try {          DisplayMode best = (fullscreen) ?                         getBestDisplay(size) :                         new DisplayMode(size.width, size.height);          if (best == null) {             throw new Exception();          }          Display.setDisplayMode(best);       } catch (Exception e) {          e.printStackTrace();          throw new RuntimeException("LWJGL Error: "+                               "Unable to set desired display " +                               "mode ("+size.width+"x"+size.height+"x"+16+")");       }       try {          Display.setTitle("Stencyl");          Display.setFullscreen(fullscreen);          Display.setVSyncEnabled(vsync);          Display.create();       } catch (Exception e) {          e.printStackTrace();          throw new RuntimeException("LWJGL Error: Unable to initialize display");       }             long end = System.currentTimeMillis();       System.out.println("Display Selection Time = " + (end - start) + "ms"); //DOES NOT REACH HERE

[Matzon]

since Display.create(); has nested calls, it would be a lot easier if you had some idea what specific line was causing the "hang" - something like a stacktrace.
I realise you would need to add some debug info to the lwjgl stuff, but it's pretty much impossible to guess where the error is.
have you tried running with -Dorg.lwjgl.util.Debug=true ?

[Ken Russell]

FYI, you can capture a thread dump of a running Java process using the "jstack" command in the JDK, supplying the process ID of the Java process on the command line. On Windows this is supported first in JDK 6.

[Eliwood]

Turning on the debug flag yielded this interesting tidbit.

Initial Mode: 1024 x 768 x 32 @0Hz
Insufficient Color Precision

What does that mean and why is it 0 Hz?

[Matzon]

0Hz is usually on linux - but then it only has 24bits (alpha is ignored)
At any rate, try to create a default resolution 640x480x16x60Hz - if that works, then its a matter of the drivers not liking one of the modes you select.

[Eliwood]

Did exactly that, and it still doesn't work. I used the example off your site, and when it displays all the display modes, ALL of them are 0 Hz for this user.

So when I force 640x480x16x60 or 640x480x32x60, it just bumps the 60Hz to 0 because none of his display modes are above 0Hz to begin with.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18

protected boolean setDefaultDisplayMode() {    try {        DisplayMode[] dm = org.lwjgl.util.Display.getAvailableDisplayModes(640, 480, -1, -1, -1, -1, 60, 60);        /*org.lwjgl.util.Display.setDisplayMode(dm, new String[] { "width=" + 640, "height=" + 480, "freq=" + 60,        "bpp=" + org.lwjgl.opengl.Display.getDisplayMode().getBitsPerPixel()});*/                org.lwjgl.util.Display.setDisplayMode(dm, new String[] { "width=" + 640, "height=" + 480, "freq=" + 60,              "bpp=16"});        return true;       } catch (Exception e)       {         e.printStackTrace();             }       return false;         }

Games published by our own members! Check 'em out!

[Matzon]

to be honest, I have no clue as to what is going on - however it IS a voodoo3 card... - no telling whats going on, its legacy!

[EgonOlsen]

I wonder that it ever worked. I asked some "retro" guys to test Paradroidz on Voodoo-cards once and the result was, that it didn't work at all, except when you are using a dual monitor setup, start the game on graphics-card 1 (non-Voodoo) and move the Window to the Voodoo.
Abouzt the video mode: A Voodoo3 can't do 32bit in 3D anyway.

[Eliwood]

I wonder that it ever worked. I asked some "retro" guys to test Paradroidz on Voodoo-cards once and the result was, that it didn't work at all, except when you are using a dual monitor setup, start the game on graphics-card 1 (non-Voodoo) and move the Window to the Voodoo.
Abouzt the video mode: A Voodoo3 can't do 32bit in 3D anyway.

Unless he was mistaken, he said that it worked before and pushed 60 FPS. So I take it that there's no solution at all due to hardware limitations?

[Eliwood]

So I asked the user again about the one time it ran properly, and he recalls that it ran properly when he shut off backgrounds, and then it makes sense all of a sudden because none of the other textures are over 256 x 256 in size, and I read somewhere (LWJGL forums?) that voodoo cards supported a small "subset" of OpenGL functionality and only supported textures up to that size, which is fine in a 3D game since low-res textures are the norm, but not fine for a 2D game.

Of course, it's no fun to play a game with no backgrounds, but I guess that the way out of this one unfortunately is to develop some algorithm for slicing any textures that are over 256 x 256 into textures of that size and recombining them. A bit annoying, but that's the only solution I can think of at this point.

Has anybody written code that already does that?

[nva225]

Isn't it true in some cases 4 smaller textures will display faster than one larger texture anyway? (please correct me if I'm wrong, I thought I read problems like this before however)