Ken - I saw your StarGauge speed problem.. I think

Vorax · May 23, 2005, 5:24am

Hi Ken,

I think I saw the problem you were having with StarGauge. You said that it was running very fast - to fast to be able to hit the enemy.

I am working on implementing the GUI for the game, and while I was testing out changing the options, I tried turning on VSync (I always run with it off). Everything seemed normal until the game started. Everything was running at an incredible rate. I was flying very fast and the enemy ships were buzzing around at incredible speeds. My controls were also moving very fast.

Is that what you saw?

Everything in the game is controlled by the engine operation thread, which is capped (supposed to be) at 62fps. It is based off of System.currentTimeMillis(). Something happened that messed with the time reporting from System.currentTimeMills()

I changed the options to run in 1600x1024, fullscreen when it happened. The way my code works is that if VSync is on, wglSwapIntervalEXT() is never called.

Could this be a bug in Java? A bug in JOGL? A bug in my nVidia drivers (v71.84 - GeforceFX 5500)?

I had no errors on the console. I have never seen it do this before, and I haven’t been able to reproduce it.

kbr · May 23, 2005, 1:24pm

No, I just found that in general the ships moved too quickly to respond to. I just tried your latest version and the FPS and engine FPS were locked at 100.0. I was able to get a couple of shots in on the enemy ships this time though didn’t actually blow one up.

A couple of points: as of JOGL 1.1 b11 there is a new GL.setSwapInterval(int interval) call which provides portable VSync control. Also, you should either inform the user that you’re writing files to the local disk, or use getClass().getClassLoader().getResourceAsStream() to open your music files at runtime directly from the Java Web Start jar cache.

Vorax · May 23, 2005, 2:51pm

[quote]No, I just found that in general the ships moved too quickly to respond to. I just tried your latest version and the FPS and engine FPS were locked at 100.0.
[/quote]
Hmm…ok, must have been an fluke then.

To blow one up, just unload some missles (right click) on your locked target, they are self guiding. The next version will allow you to adjust mouse sensitivity, which should solve it for you.

Great, i’ll switch to setSwapInterval(). What OpenGL version is that? If it’s not OpenGL but a Java workaround, does it fall back to wglSwapIntervalEXT() for windows? Any dangers for multithreaded code?

I’ll add a message about the file writing. I won’t be switching to getResourceAsStream() because I am using FMOD and it loads the sounds/music by file name. I could switch to play from memory, but there is no point to the effort for me because the final version of the game isn’t going to be launched by webstart, it will be installed via an installer. I am also going to have to write several other things to the drive, such as the configuration (which it’s now doing, but not released yet).

I am only using Webstart to make life easier for the testers on this board.

kbr · May 23, 2005, 3:56pm

[quote]Great, i’ll switch to setSwapInterval(). What OpenGL version is that? If it’s not OpenGL but a Java workaround, does it fall back to wglSwapIntervalEXT() for windows? Any dangers for multithreaded code?
[/quote]
Check the javadoc. Basically there are no guarantees about its effects; if the necessary OpenGL extension is present on the particular platform then it will take effect. You need to call the method from within your GLEventListener’s callbacks, preferably init(), so any multithreading issues are handled internally by JOGL’s existing mechanisms.