Input lost...

I’ve got a very basic framework going for developing my first 2d game, but when I push the performance of it (which is badly in need of tuning, but never mind that at this point) I lose all input signals - keypresses, mouse clicks, etc. I’m guessing it’s burning through so much CPU that it’s just locking out all input. Is there a way to raise the priority of my events, or do I need to have my Thread yield or something?

I’m running on 98 right now and when this happens I can’t even Alt-Tab / CTRL-ALT-DEL out of the app… I am forced to shut it down the old way…

Thanks for any advice.

Normally you need a Thread.yield() in your main thread to allow the AWT thread to get a chance to pickup input events.

I always wonder if its safer to use a Thread.sleep(1) or something since Thread.yield() doesn’t perform the same on all platforms.

Kev

wow!

atlast some1 else has encountered this problem!!

I believe it is a problem with the way Java is using DirectDraw and is a problem specific to Win98.

It only occurs when in fullscreen and when using a Page Flipping BufferStrategy.

I’ve got a theory as to the cause,

when bufferStrategy.show() is called, Java waits for a vsync.
While it is waiting for the vsync it the event scheduling Thread is prevented from interrupting it. (this is only logical afterall, if the event thread could interrupt it you would miss the vsync often, which would result in massive loss of FPS)

Ofcourse, the Event Thread should interrupt your render loop while it is executing, so the events should still get serviced.

However, if your render loop executes very quickly, it is likely that the scheduler would never get a chance to interrupt. Hence the Event scheduler would end up never getting any processor time.

I don’t know if this theory is correct; all i can say is that it fits the facts :o

If I am correct, then the following code on Win98 should result in the experienced behaviour.

setFullscreenWindow(this);
createBufferStrategy(2);
BufferStrategy bs = getBufferStrategy();
while(true)
{
   //Graphics g = bs.getDrawGraphics(); 
   //g.dispose();
   //^^ these calls maybe needed for the problem to surface
   bs.show();
}

Thanks for the input folks! I think I figured out what the problem was. The Thread.yield() was not properly yielding to the AWT input. By ensuring that there was at least 1ms sleep between each draw cycle I am getting my input again!

On a side note, I have determined that it is inherently unsafe to System.exit(-1) when in full screen mode, at least in 98. While that may be obvious, it is definitely true.

Thanks again all.

indeed,

always call dispose() on fullscreen frames.

The AWT Thread should always die naturally once you’ve disposed of all awt windows.

(there are however a few exceptions to that rule, if you ever create a Dialog/JDialog using the no parent constructor, it very kindly creates a hidden Frame which is impossible to dispose of <_<)

I think the Thread.yield() vs Thread.sleep(1) thing is to do with the two types of threading (can’t remember the naming right now, is it pre-emptive and co-operative?).

One type supports yield(), it varies on different platforms (including evidently Win98 -> WinXP). Seems like the only safe way is to use Thread.sleep(1).

Kev

If u use Thread.sleep(1) on win98,
your gonna be waiting for 55ms,
limiting your framerate to a pathetic 19fps ::slight_smile:

What we realy need is poll-able input so we can get rid of all the task switching.
(will JInput ever make its way into the core api?)

I thought the 55ms restriction didn’t apply to Thread.sleep()?

One thing I did, slightly different, was change my main thread priorty to MAX_PRIORITY, and in all flavors of Windows it just completey shut out all other threads, denying any input (where as on Linux it game me a little 3-4fps boost with no adverse side effects). Once I turned that off my input thread under windows was just fine.

[quote]I thought the 55ms restriction didn’t apply to Thread.sleep()?
[/quote]
oops, silly me.

w00t, my 300th post!

YAY, im a ‘senior member’ ;D

Now wheres my pension 8)

Ofcourse you can detour around the AWT input loop entirely by using JInput. Or LWJGL’s input.

  • This message brought to you by the project manager of the JInput project *

speaking of… is there any example source available for jinput? I found the compiled examples in the mind2machine build, but no source. Is that planned in the official build release?

Sorry if this might be construed as a tad off topic if the poster isnt considering jinput.

[quote]Ofcourse you can detour around the AWT input loop entirely by using JInput. Or LWJGL’s input.

However, like Abuse put it: "(will JInput ever make its way into the core api?) "
Same applies to Jogl and Joal.

To deploy an Java application with Jogl you already need to provide Jogl-Jars and Jogl-Win-Dlls/Linux-Libs/Maclibs/Sparc-Libs/etc. (Javawebstart is not an option for so many projects.)

Now Jinput?
Next Joal?
What then…?
:slight_smile:

It’s even hard to convince a team / producer of a game to go with Java, let alone when you’ve to tell them: oh well we need to ship a dozen DLLs more.

I see the inclusion of Jogl and other game-core extensions into the J2SE as an very important point.

[quote]will JInput ever make its way into the core api?
[/quote]
If it works, does it really matter? The wrappers are going to be small anyway. The only significant drawback is that to use the native code via webstart or an applet it must be signed.

I think these technologies should be optional packages that can be installed through WebStart’s extension installer mechanism… official builds could be signed by Sun.

Shipping DLLs & libraries in a game is normal with native code… so why would it be a drawback for Java???

[quote]Shipping DLLs & libraries in a game is normal with native code… so why would it be a drawback for Java???
[/quote]
platform independence?

Having to ship a game with DLL’s/libraries for each potencial platform would be pretty lame IMO.

I don’t know how the input events are captured in AWT, but I would have thought JInput could be slotted neatly in there somewhere?

Infact JOGL, JOAL and JInput could all be slotted underneath the existing APIs. Couldn’t they?

You don’t have to ship DLLs that aren’t for the specific platform the user is downloading for (you could build separate installs, or if possible use WebStart).

If distributing on CD these things are tiny and then at install time you still wouldn’t copy them to the user’s hard drive.

There is nothing in AWT to get events for game devices (steering wheels, flight yokes, joysticks, game pads, force feedback controllers, etc…). JInput addresses this. Also AWT is based on an event model, not polling. Much of the events come from the Windows message loop and equivalents on other platforms.

I heard that OpenGL might be used to accelerate graphics on Linux, much like Direct X is used on Windows. It would be cool if that effort ended up pulling JOGL into the core.

Very good points; I 100% agree. :slight_smile:

The main point of Java is platform independency. You take your JAR and it runs on any machine where a Java VM is installed - without Internet.

Well, of course the installation of the JVM has to be as simple as possible for the end user - and also it shouldn’t be my task as Java application deployer.
Needless to say that the need for further DLLs/LIBs/etc for Jogl/Joal/Jinput/etc does complicate the whole process of deployment. If it’s going to be too much then it’s easier to compile with C++ a Win32 only application and ship it. But not willing to do so is a main reason for many Java programmers, isn’t it?

[quote]Of course the installation of the JVM has to be as simple as possible for the end user - and also it shouldn’t be my task as Java application deployer.
Needless to say that the need for further DLLs/LIBs/etc for Jogl/Joal/Jinput/etc does complicate the whole process of deployment.
[/quote]
It actually isn’t that complicated… Install Anywhere would handle things easily… but since I sort of agree with the idea :)…

I think something along the lines of the WebStart extension installation mechanism needs to be built in to the standard (and striped down) JRE. Normal Java Applications would automatically install optional bits of the JRE on demand. This could be triggered by the classloader which, when it doesn’t find a class from the java.* or javax.* packages on the system would query java.sun.com and grab the needed package. If no access to the internet is available it can bail out with a “You need package XYZ to run this program, it can be found at this URL and will be installed automatically if a net connection is available…”

The “Get Java” button is a good start at simplifying the basic JRE install for end users. If you are making Java games and you don’t host “the button” - shame on you ;).

quote
I heard that OpenGL might be used to accelerate graphics on Linux, much like Direct X is used on Windows.
[/quote]
Yes, this has been mentioned some time ago on Java-Developer (?) by somebody from the Java 1.4.x team (?). Basically they wanted to address the topic after Java 1.4.x - AFAIK.

[quote] It would be cool if that effort ended up pulling JOGL into the core.
[/quote]
Yes, this would be really great.