Java API enhancement request

General Discussions
#1

hey game-devs :slight_smile:

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.

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.

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.

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

#2

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. :-\

#3

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

#4

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.

#5

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.

#6

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

#7

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

#8

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?

#9

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.

#10

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

#11

this has been fixed, i don’t know in which version (jdk6/openjdk6/7) but I saw the report somewhere.

#12

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

Cas :slight_smile:

#13

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

#14

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

#15

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.

#16

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 :slight_smile:

#17

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.

#18

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 :slight_smile:

#19

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

#20

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?