Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Input lost...  (Read 2916 times)
0 Members and 1 Guest are viewing this topic.
Offline zaphod

Senior Newbie




Java Developer by day, Java Developer by ... hey


« Posted 2003-07-06 05:09:50 »

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.
Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2003-07-06 06:00:21 »

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

Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #2 - Posted 2003-07-06 12:24:47 »

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 Shocked

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

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
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();
}

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zaphod

Senior Newbie




Java Developer by day, Java Developer by ... hey


« Reply #3 - Posted 2003-07-06 14:32:41 »

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.
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #4 - Posted 2003-07-06 14:44:01 »

Quote

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 <_<)

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2003-07-06 14:48:08 »

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

Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #6 - Posted 2003-07-06 16:52:46 »

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

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?)

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline tortoise

Junior Member




<3 Shmups


« Reply #7 - Posted 2003-07-08 11:41:40 »

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.
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #8 - Posted 2003-07-08 14:40:50 »

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


oops, silly me.

w00t, my 300th post!

YAY, im a 'senior member'  Grin

Now wheres my pension Cool

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Jeff

JGO Coder




Got any cats?


« Reply #9 - Posted 2003-07-08 15:23:22 »

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 *


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline SpuTTer

Senior Member


Medals: 1
Exp: 14 years


Lazy Middle Class Intellectual


« Reply #10 - Posted 2003-07-09 04:06:07 »

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.

Sacramento Volleyball
"Whitty phrase goes here."
8: Undefined index: online
File: /home/jgo/public_html/Themes/default/Display.template.php (main sub template - eval?)
Line: 151