Hrm, the OpenGL subsystem should be rendering everything in parallel to you passing it commands. I’d guess swapBuffers is the time it sits there waiting for a vertical blank?
Yes, that could be the problem. I know that it shouldn’t but it somehow is on my machine. Swing in combination with fullscreen LWJGL results in a crash, if i’m NOT going to windowed LWJGL-mode first (see the thread i mentioned for more details). ???
Hmmm, in lwjgl 0.4 when I first created a swing component before going to fullscreen in openGL, I got the openGL-screen-behind-all-other-windows problem. All went well when I didn’t create a swing thing.
0.6 fixed that for me.
Dunno if this relates, though…
[quote]Hrm, the OpenGL subsystem should be rendering everything in parallel to you passing it commands. I’d guess swapBuffers is the time it sits there waiting for a vertical blank?
[/quote]
Hrmyes, good point…
- back to reading *
Could Swing’s use of DirectDraw for rendering be interfering? Graphics drivers are notorious for doing dumb stuff with DirectDraw.
[quote]Could Swing’s use of DirectDraw for rendering be interfering? Graphics drivers are notorious for doing dumb stuff with DirectDraw.
[/quote]
That would make starting any openGL app while a swing window is open a useful test, wouldn’t it?
(hint, hint ;))
Tried this on windows 2000:
Java Web Start 1.4.2-beta Konsol, startades Fri Jun 06 16:42:06 GMT 2003
Java 2 Runtime Environment: Version 1.4.2-beta av Sun Microsystems Inc.
Loggar till filen: c:\javaws.log
Game starting.
Maybe selecting mode 800x600x16 @120
Maybe selecting mode 800x600x32 @150
/data/txtr14-256.jpg
/data/txtr13-256.jpg
/data/fireblurred.jpg
/data/disp02.png
/data/glass1.png
/data/glass2.png
/data/space30s.jpg
/data/wall.png
/data/smoke5.png
/data/flare2.png
/data/expl_0.png
/data/expl_1.png
/data/expl_2.png
/data/expl_3.png
/data/expl_4.png
/data/expl_5.png
/data/expl_6.png
/data/expl_7.png
/data/expl_8.png
/data/expl_9.png
/data/19x16Lucida.png
/data/txtr12-256.jpg
Loop ended.
killWLWindow()
Mouse destroyed.
Keyboard destroyed.
GL destroyed.
Game Ended.
Not good :o (150 is waaay to much for my graphics card and screen to handle 
)
[quote]Not good (150 is waaay to much for my graphics card and screen to handle )
[/quote]
Oops, lemme fix that. I have to fix the display mode selecting anyways 
I guessed the OS/driver/whatever would’ve filtered out the modes that the monitor can’t display, but I guess it doesn’t… Maybe setting the windows option ‘hide modes this monitor can’t display’ helps (display properties/settings/advanced/monitor).
Unfortunately I won’t be able to upload the changes until next tuesday. I don’t have the key here to sign the changed jar.
Already tried that
Not sure why/how lwjgl still can get values not supported though!(?)
Maybe it returns all modes the video card supports, regardless of the monitor, or it may be your video drivers that are messing up.
Maybe a LWJGL dev can answer that better.
Erik
Well, it’s actually kind of fun to have game work on linux but not on windows (in my case) ;D
[quote]Maybe a LWJGL dev can answer that better.
[/quote]
You rang sir? ;D
The code in question ought to validate against the monitor:
//enumerate all displays, and all of their displaymodes
while(EnumDisplayDevices(NULL, i++, &DisplayDevice, 0) != 0) {
while(EnumDisplaySettingsEx(DisplayDevice.DeviceName, j++, &DevMode, 0) != 0) {
if (DevMode.dmBitsPerPel > 8) {
AvailableModes++;
}
}
}
EnumDisplaySettingsEx:
[quote]dwFlags
[in] This parameter can be the following value.
EDS_RAWMODE If set, the function will return all graphics modes reported by the adapter driver, regardless of monitor capabilities. Otherwise, it will only return modes that are compatible with current monitors.
[/quote]
I have no idea why the 150 Hz would be available though…
Say, any chance that Cosmic Trip can render in software? I have a crappy video card (ATI mach64 2MB) :-[ . My video card can run Half-Life smoothly in software mode. Shouldn’t Cosmic Trip be able to do that too? (since the graphics aren’t at the “blow-me-away” stage?)
Half-life (and most games from that era) have a specially created software renderer, with much hand-crafted assembly language to speed things up. Cosmic Trip being LWJGL (and therefore OpenGL) based, its pretty much hardware only.
There are some software implementations of OpenGL (Mesa is about the best) but typically if your computer is fast enough to run that, you’ll have a good enough video card anyway…
[quote]since the graphics aren’t at the “blow-me-away” stage?
[/quote]
You bastard, you create the software renderer!
Erik 
Just uploaded a little update.
You can now press F10 to toggle scenery rendering (buildings and such) and press F11 to toggle the smoke tail rendering from the player ship.
This should help if it runs too slow on your machine.
I also added backface culling (simply used the openGL function), but that didn’t really make a difference.
There’s still F12 to save a screenshot, but that one was already in there but never mentioned
I also updated the code to select the video mode so that it will only select a video refresh rate <90 and if it fails to find a suitable mode, it falls back to the 1st supported video mode it can find before bailing out.
Erik
[quote]You bastard, you create the software renderer!
[/quote]
I wasn’t insulting the graphics at all. By “blow-me-away” I meant graphics such as the ones in Deus Ex Invisible War, etc. etc.
I am looking forward to playing it once I get my Geforce 4 MX440 128MB card from some computer show in the summer. 
[quote]I wasn’t insulting the graphics at all. By “blow-me-away” I meant graphics such as the ones in Deus Ex Invisible War, etc. etc.
[/quote]
Don’t worry, I was just kidding
I know the graphics are not quite at that level.
Erik
[quote][…]press F11 to toggle the smoke tail rendering from the player ship.[…]
[/quote]
:
:-*
(Seriously. This isn’t spam.)