Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (775)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (856)
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  
  Java API enhancement request  (Read 7820 times)
0 Members and 1 Guest are viewing this topic.
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Posted 2008-07-21 22:49:05 »

hey game-devs Smiley

What do you think about the following Java API enhancement?

AWT input handling is hell on earth for games. And since JInput doesn't always fulfill all needs and relies on additional natives and is unfortunately detected as a keylogger by some antivirus tools, I would like to have AWT to be improved for games.

There are three aspects, that would need to be changed/added to make is suitable for gaming-input-handing.

1.
I need to have the possibility to poll for input events rather than listen for them on some AWT input thread. All that would have to be added, is to have a polling framework, that would fire the input events to the existing input listeners from the polling thread. This gets rid of some synchronization efforts and is much simpler to handle. You would still have to possibility to use the AWT input thread and therefore there would be NO backwards incompatibilities. The AWT input thread should be off-switchable.
It would also be nice, if the polling framework would provide a way to directly poll the events instead of pushing them through the listeners.

2.
Key-repeat events must not fire continuous RELEASED/PRESSED events, but just TYPED. On Linux both RELEASED and PRESSED are fired continuously on key-repeat and on Windows only PRESSED is. Both are absolutely unnecessary and and IMHO never wanted. If these events make any sense in some special cases, they would have to be optional by some setting. It is impossible to reliably track PRESSED and RELEASED events when events are coming from a different thread (the AWT input thread) and are fired on key repeat.

3.
There should be a way to activate a mouse-exclusive mode, where the mouse cursor cannot leave the window and in optimal case doesn't even actually move. It would be sufficient to fire delta events, even if this is not that important, since the delta information can be computed from the absolute MOVED-events.

Additionally the the AWT input handling is very GC expensive, which should be solved. One way to solve this, would be the pure polling paradigm.

What do you think? Where is the best place to post this request, so that Sun gets aware of it? Are there any Sun devs out there reading this forum?

Marvin
Offline DragonsRage

Senior Newbie





« Reply #1 - Posted 2008-07-21 23:41:08 »

That would be so awesome, but do think any Sun devs will be interested? I mean this has been a sticking point for while now and yet there haven't been any significant changes. Undecided

Secrets and lies

     () ()
     (O.o)
     (>.<)
Offline Markus_Persson

JGO Wizard


Medals: 19
Projects: 19


Mojang Specifications


« Reply #2 - Posted 2008-07-22 00:01:21 »

I think it's a great idea, and it would solve a lot of issues.

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

JGO Kernel


Medals: 188



« Reply #3 - Posted 2008-07-22 01:04:30 »

I think this can be filed via http://bugs.sun.com/.. The main problem would be to get enough votes for the request, to get taken into account.

Mathias - I Know What [you] Did Last Summer!
Offline DragonsRage

Senior Newbie





« Reply #4 - Posted 2008-07-22 01:49:07 »

I think this can be filed via http://bugs.sun.com/.. The main problem would be to get enough votes for the request, to get taken into account.

It looks like it will only take 60+ votes based on the top 25 bugs, and I think AWT input handling has ruffled more than a few feathers.

Secrets and lies

     () ()
     (O.o)
     (>.<)
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #5 - Posted 2008-07-22 02:00:15 »

Then it was a good idea to post here first. I encourage any user here on JGO to post in this topic. When we have some audience here, I will post on bugs.sun.com and hopefully all users taking part in this discussion will also vote there. Then Sun SHOULD pay attention to it.

PLEASE POST!!!

Marvin
Offline ewjordan

Junior Devvie





« Reply #6 - Posted 2008-07-22 03:51:59 »

(OT) Did anyone else notice that (up until this last post) when Marvin's post count was at 1337 it actually displayed as "leet"?  And now it's gone forever, so you probably think I'm making this up or something...weak.

Yeah, I'm with you guys, though, I've been annoyed at the lack of flexibility and the seeming lack of sense behind AWT's input handling.  Could definitely use an overhaul, though is it actually plausible that someone at Sun will approve an AWT change (particularly one that adds to the public interface of the thing) at this late stage in the game?
Offline DragonsRage

Senior Newbie





« Reply #7 - Posted 2008-07-22 14:53:52 »

is it actually plausible that someone at Sun will approve an AWT change (particularly one that adds to the public interface of the thing) at this late stage in the game?

This is what I am worried about, but I think if there is enough support they may make the changes we want. Was there a reason they designed the input handling with seemingly so little sense? It seems what Marvin has laid out would be simpler both to use and to design than the current implementation Sun has, or is there a major technical difficulty that I am completely missing?

Secrets and lies

     () ()
     (O.o)
     (>.<)
Offline cylab

JGO Kernel


Medals: 188



« Reply #8 - Posted 2008-07-22 15:36:38 »

I would even be happy, if they just manage to reliably send PRESSED/RELEASED events with multiple key presses over the key repeat period. Right now, there are sometimes missing RELEASED events, from which you simply can't recover.

My vote is in.

Mathias - I Know What [you] Did Last Summer!
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #9 - Posted 2008-07-22 18:17:09 »

Was there a reason they designed the input handling with seemingly so little sense? It seems what Marvin has laid out would be simpler both to use and to design than the current implementation Sun has, or is there a major technical difficulty that I am completely missing?

AWT is not designed for games at all. It was designed for GUI systems. Even if I don't like the AWT API very much in general, it does its job pretty well... for GUI systems. For games the suggested changes are pretty obvious.

I am not sure about Sun's current point about supporting Java games. But I hope, they still want to. And if they do, they SHOULD do the above changes.

Additionally there should be onboard Joystick support (with force-feedback). Something I forgot in when I wrote the original posting. Though that's not too important, since JInput does that pretty well... when they've eliminated the key-logger thing for the case that only joysticks are actually used.

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

Senior Devvie




OutOfCoffeeException


« Reply #10 - Posted 2008-07-22 18:47:28 »

I would even be happy, if they just manage to reliably send PRESSED/RELEASED events with multiple key presses over the key repeat period. Right now, there are sometimes missing RELEASED events, from which you simply can't recover.
this has been fixed, i don't know in which version (jdk6/openjdk6/7) but I saw the report somewhere.

Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2008-07-23 08:48:31 »

Surely it'd just be nicer to have JInput built-in to J2SE at some point?

Cas Smiley

Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #12 - Posted 2008-07-23 09:38:40 »

Surely it'd just be nicer to have JInput built-in to J2SE at some point?

Well, yes for the joystick part. There's no need for the keyboard or mouse parts as long as the above changes are applied.

Marvin
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 123
Projects: 15


★★★★★


« Reply #13 - Posted 2008-07-23 11:02:45 »

but with jinput you could avoid using awt altogther and just poll the keyboard and mouse directly.
Offline cylab

JGO Kernel


Medals: 188



« Reply #14 - Posted 2008-07-23 11:08:49 »

This causes several problems, one of them the detection of the keyboard polling as keylogger (for which direct polling indeed can be used) and afaik you also have to change the keyboard device's access rights for polling in linux.

Mathias - I Know What [you] Did Last Summer!
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2008-07-23 11:46:23 »

It should only be detected as a keylogger if it gets access to the keyboard when the application is not focused. And even then, if it's got permission to run - ie. signed and approved - it shouldn't be detected as a keylogger: seems that the detected software is flawed.

Cas Smiley

Offline cylab

JGO Kernel


Medals: 188



« Reply #16 - Posted 2008-07-23 14:09:28 »

I was more refering to the fact, that sun won't include a library in it's core distribution, that would allow to create a keylogger.

Mathias - I Know What [you] Did Last Summer!
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2008-07-23 15:49:05 »

You can pretty much do that with the Robot class I believe can't you? Security is managed with Java's permissions and it works out well.

Cas Smiley

Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #18 - Posted 2008-07-23 17:42:56 »

The Robot just pushes window messages to the system, but never reads them. So: no.

But this leads me to another thing, I forgot to mention. AWT input events should have a flag, that tells, if the event was produced by a Robot action (if this is possible in any way).

JInput doesn't care about a window to be focussed or not. On linux it directly accesses the device nodes, which is totally system-absolute and doesn't have anything to do with a window of what ever application. I don't know, how it is doen on windows, but IIRC it's something about DirectX. But there is an AWT plugin for JInput, which certainly doesn't have this problem. But I was never answered about the question, if you could use the AWT plugin for the mosue and keyboard and the direct access for joysticks, which would solve the problem.

But there's still the problem, that the device nodes' right-bits need to be manually changed after each reboot, which is totally unpracticle for games. It would be much better, if Sun would introduce onboard tools to controller handling without the need to directly access device nodes. Other libraries are able to do this, too. And if Java wants to be up to par for game-development, if must have support like claimed in this thread.

Marvin
Offline ewjordan

Junior Devvie





« Reply #19 - Posted 2008-07-23 20:39:17 »

It should only be detected as a keylogger if it gets access to the keyboard when the application is not focused. And even then, if it's got permission to run - ie. signed and approved - it shouldn't be detected as a keylogger: seems that the detected software is flawed.
Sorry, just checking - you mean that the detection software is flawed, right?  Or are you saying that JInput is actually at fault here and doing something naughty?

I guess I'm just a little confused, having never tried to deal with this stuff myself - are there comparable C++ libraries that have the same functionality but don't get flagged as keyloggers?
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2008-07-23 21:28:18 »

Well, under Windows, DirectInput can be told to only grab the keyboard when the application has focus, for example. Or it can be told to grab it when it hasn't got focus - that's what a keylogger does. Dunno about any other OSes.

But I'd say the detection software's flawed if it flags signed software, or if it throws a wobbler when an application with focus is reading the keyboard.

Cas Smiley

Pages: [1]
  ignore  |  Print  
 
 

 
hadezbladez (13 views)
2018-11-16 13:46:03

hadezbladez (18 views)
2018-11-16 13:41:33

hadezbladez (6 views)
2018-11-16 13:35:35

hadezbladez (6 views)
2018-11-16 13:32:03

EgonOlsen (1880 views)
2018-06-10 19:43:48

EgonOlsen (1904 views)
2018-06-10 19:43:44

EgonOlsen (1261 views)
2018-06-10 19:43:20

DesertCoockie (1706 views)
2018-05-13 18:23:11

nelsongames (1392 views)
2018-04-24 18:15:36

nelsongames (2007 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
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!