Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Running and Distributing in Linux  (Read 6005 times)
0 Members and 1 Guest are viewing this topic.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #30 - Posted 2003-05-05 03:10:07 »

I'm no linux expert here, but the lwjgl libs are for RH8, doesn't that make lwjgl native libs behave erratic on non RH8 platforms?
Could you try it with lwjgl 0.6 ?

Offline elias

Senior Member





« Reply #31 - Posted 2003-05-05 04:00:59 »

Have you got the XVidMode extension on your display? On my machine:

[elias@ip172 elias]$ xvinfo |grep X-Video
X-Video Extension version 2.2

- elias

Offline Mojomonkey

Senior Member




ooh ooh eee eeee


« Reply #32 - Posted 2003-05-05 10:13:18 »

Matzon: I'll get 0.6 downloaded today and let you know if that solves the problem.

Elias: [mpowell@Mulder mpowell]$  xvinfo | grep X-Video
X-Video Extension version 2.2

It appears it's running.

Don't send a man to do a monkey's work.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline psiegel

Junior Member




Adamant about gaming.


« Reply #33 - Posted 2003-05-05 12:59:48 »

Nope, the latest version of that test has not fixed the bug I mentioned.  To reiterate:

1.  When going into full screen mode, I can use the mouse to scroll the desktop away from the 3D scene.
2.  When switching back to windowed mode or quiting from the full screen mode, the app crashes.

Here's a teaser of the output when simply trying to move back to a windowed screen.  This forum won't let me post the full output, as it says it's too long.

$ java -cp .:lwjgl.jar org.lwjgl.test.opengl.FullScreenWindowedTest
Change between fullscreen and windowed mode, by pressing F and W respectively
Move quad using arrowkeys, and change rotation using +/-
java.lang.Exception: Could not load gl libs
       at org.lwjgl.opengl.BaseGL.nCreate(Native Method)
       at org.lwjgl.opengl.BaseGL.doCreate(Unknown Source)
       at org.lwjgl.opengl.GL.doCreate(Unknown Source)
       at org.lwjgl.Window.create(Unknown Source)
       at org.lwjgl.test.opengl.FullScreenWindowedTest.processKeyboard(FullScreenWindowedTest.java:229)
       at org.lwjgl.test.opengl.FullScreenWindowedTest.mainLoop(FullScreenWindowedTest.java:125)
       at org.lwjgl.test.opengl.FullScreenWindowedTest.execute(FullScreenWindowedTest.java:85)
       at org.lwjgl.test.opengl.FullScreenWindowedTest.main(FullScreenWindowedTest.java:342)

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4D05314C
Function=[Unknown.]
Library=(N/A)


Paul Siegel
Adamant Games, Inc.
http://www.adamantgames.com
Offline elias

Senior Member





« Reply #34 - Posted 2003-05-05 15:21:24 »

Quote
Nope, the latest version of that test has not fixed the bug I mentioned.  To reiterate:

1.  When going into full screen mode, I can use the mouse to scroll the desktop away from the 3D scene.



Not really a bug, but follows from the fact that the test doesn't grab the mouse.
[/quote]
2.  When switching back to windowed mode or quiting from the full screen mode, the app crashes.

[/quote]

Not sure what causes this, although I have had problems on glibc version 2.2.3 that rh 9 uses. Could you send me the full dump to naur at odense.kollegienet.dk? Include both cases: fullscreen to windowed and quitting.

- elias

Offline psiegel

Junior Member




Adamant about gaming.


« Reply #35 - Posted 2003-05-05 17:54:40 »

Quote

1.  When going into full screen mode, I can use the mouse to scroll the desktop away from the 3D scene.

Not really a bug, but follows from the fact that the test doesn't grab the mouse.


What really strikes me as buggy about this is that in the full 1280x1024 desktop, the top left 800x600 pixels are where the app is rendering.  However, the screen doesn't necessarily start focused at that top left corner.  In fact, it seems kind of random what portion of the total screen is being rendered.  Sometimes it's directly centered on the destop, other times it's at 0 y, but centered on the x, and sometimes it's correctly alligned at (0, 0).

Quote

2.  When switching back to windowed mode or quiting from the full screen mode, the app crashes.

Not sure what causes this, although I have had problems on glibc version 2.2.3 that rh 9 uses. Could you send me the full dump to <email removed>? Include both cases: fullscreen to windowed and quitting.


E-mail sent.  I wish I had a rh8 box lying around to test on as well and see if it's a rh9 vs. rh8 issue.

-Paul

Paul Siegel
Adamant Games, Inc.
http://www.adamantgames.com
Offline elias

Senior Member





« Reply #36 - Posted 2003-05-06 07:56:46 »

Quote


What really strikes me as buggy about this is that in the full 1280x1024 desktop, the top left 800x600 pixels are where the app is rendering.  However, the screen doesn't necessarily start focused at that top left corner.  In fact, it seems kind of random what portion of the total screen is being rendered.  Sometimes it's directly centered on the destop, other times it's at 0 y, but centered on the x, and sometimes it's correctly alligned at (0, 0).



When an lwjgl app grabs the mouse, the desktop is also centered and locked on the app window. If it doesn't grab it, the desktop centering follows the mouse, and therefore it appears random.

- elias

Offline psiegel

Junior Member




Adamant about gaming.


« Reply #37 - Posted 2003-05-06 09:59:32 »

Ok, I did a bit of mucking with the code and discovered that all the fixes necessary are in the FullScreenWindowedTest class itself.  They are:

1.  Create and destroy the Mouse object at the same time as the Keyboard object.  This causes the screen to be properly aligned in fullscreen mode as Elias mentioned in his last post.

2.  In processKeyboard() when the 'w' key has been pressed, call Display.resetDisplayMode() before gl.destroy().  This was causing a crash when switching from fullscreen to windowed mode.

3.  In cleanup(), call Display.resetDisplayMode() before anything else.  This will ensure the screen is properly reset when quitting the test while in fullscreen mode.

I have a copy of the code with all these fixes incorporated into it if you'd like me to post it somewhere, check it in to cvs, etc.  They're pretty easy fixes if you just want to drop them in yourself.

Paul

Paul Siegel
Adamant Games, Inc.
http://www.adamantgames.com
Offline psiegel

Junior Member




Adamant about gaming.


« Reply #38 - Posted 2003-05-06 10:14:18 »

Gah, I'm brain dead.  #2 doesn't actually work.  The crash still happens.  One shouldn't code this early in the morning.  So, to sum up, initializing the mouse and restoring the display mode in cleanup are great.  However, switching from fullscreen back to windowed mode is still causing a crash.

Paul Siegel
Adamant Games, Inc.
http://www.adamantgames.com
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #39 - Posted 2003-05-06 11:07:29 »

Please send a copy to brian@matzon.dk - I'll verify your findings against windows implementation.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline psiegel

Junior Member




Adamant about gaming.


« Reply #40 - Posted 2003-05-07 11:56:51 »

I tested this on the same machine but in a Windows 2K boot, and it doesn't crash.   Therefore, it must be a linux specific bug.  Has anyone tested this on a RedHat 8 box?  I'd be curious to know if this is because I'm running RedHat 9.

Paul Siegel
Adamant Games, Inc.
http://www.adamantgames.com
Offline elias

Senior Member





« Reply #41 - Posted 2003-05-08 12:55:01 »

I have rh8 and the bug isn't there. However another mysterious one is - if you restart the display (with 'w' or 'f') 20-30 times in a row the app crashes bc. a GLX context cannot be created. Along with the exception, this is printed (from the nvidia drivers?):

   hint: there may be a ulimit restricting the amount of
   virtual memory available to XFree86. It may be a good
   idea to check your startup scripts for something like

   ulimit -v <number>

   and either boost this value or remove the line.


indicating that there's some kind of memory leak in the code.

Because I couldn't find the leak I tried quake 3 - and surprise surprise - the same behaviour! I did a lot of vid_restart in the console and it crashes with the exact same error.

Regarding the rh 9 bug - I had stability problems with the newer glibc from an rh8 up2date, so there might be some weird jdk<->glibc interaction that triggers the error. As soon as I pull myself together and install it I will build a rh 9 version to rule out the issues Matzon mentioned.

- elias

Offline elias

Senior Member





« Reply #42 - Posted 2003-05-11 09:08:34 »

Update: I finally got around to installing rh 9 and yes, lwjgl apps crashes after a few 'w' or 'f' key presses, failing to load GL libs. And like the last time, I tried quake3 again, with exactly the same behaviour again! Quake3 crashes after two vid_restart, and the lwjgl test crashes after two presses on 'w'.

The detailed error from dlopen() is this one:

/usr/lib/tls/libGL.so.1: shared object cannot be dlopen()ed: static TLS memory too small

Indicating som leak in the TLS memory (Thread Local Storage?). So, I'm at a bit of a loss here as to how to fix it. I'm not happy about the fact that quake3 crashes with the same error, ruling out bad interaction between the jvm and native libs.

- elias

Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (45 views)
2014-09-23 14:38:19

radar3301 (28 views)
2014-09-21 23:33:17

BurntPizza (63 views)
2014-09-21 02:42:18

BurntPizza (33 views)
2014-09-21 01:30:30

moogie (41 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!