Input methodology, LWJGL Keyboard or jME inputManager?

Are raw calls to LWJGL’s static Keyboard class more computationally efficient than using inputManager and listeners?



I really enjoy LWJGL, but I finally need something more robust. jME is the obvious solution- as I was looking through the tuts and specifications to get an idea of how jME implementations work, I suddenly realized I have no idea how input handling works.



Okay, so- setActionCommand (I’m assuming that inputManager.addMapping uses setActionCommand internally), for a listener, allows multiple actions to reside in a single actionListener- but accessing a block inside of that listener requires a String comparison, which is IMO dumb. I don’t want string comparisons handling my input in a game. On the other hand, a Listener is sleeping in its own thread (right?) until it’s told to wake up, which seems better than running a bunch of input tests in the update loop-- except for when input actually does take place (supposing it happens a LOT- like, all the time… it is a game after all >.>), then there is ultimately no difference in the amount of updating that each methodology utilizes (unless no key is pressed, but in any game where computational cycles actually matter, there’s usually always input). My guess here is that Keyboard is better-- unless maybe you have a different listener for every pertinent key, then you don’t have to have any comparisons, and then it should have the same runtime or be faster than Keyboard, right? Having a lot of listeners feels sketch.



Now, suppose that inputManager could use enumerated types, and then we could just have constants instead of names and switches instead of string comparisons (that is, without some ghetto solution, like wrapping an integer as a string and parsing it to be used in a switch), then it should be more computationally efficient than using LWJGL’s Keyboard and prettier than a Listener per key (which sounds like an inherently awful idea), correct?



Any thoughts? Anybody else wonder about this or know how this junk works?

Thanks!

I think the java string operations should be pretty effective, I dont think this is much of a slowdown.

Well, without extreme optimizations, a series of string comparison blocks is O(n+1) * C, where n is the length of the longest string and C is the number of strings to compare against- whereas a switch should be O(1) regardless of the number of cases (excluding the memory cost of caching the jump table, but that’s going to be far less than a whole bunch of strings- plus, the JVM optimizes the block at runtime). It isn’t much of a slowdown, but an enumerated type and switch would be an optimization, which can be helpful when there’s a lot going on physics-wise. The only way to get that functionality with actionCommand is using integers-as-strings, which isn’t that costly really.



So, I guess I’m really wondering if jME’s inputManager does anything different from normal listener management, and if anyone happens to know how that compares to the LWJGL Keyboard class.

Sure it’s a bit slow, but how much input is really happening at any point of time? A few keys might be pressed. This is really no big deal.


Okay, so- setActionCommand (I’m assuming that inputManager.addMapping uses setActionCommand internally)

I never heard of this "setActionCommand", and it is not used in the InputManager.

a Listener is sleeping in its own thread (right?)

No, a listener runs in the thread that executed it.

but in any game where computational cycles actually matter, there’s usually always input

Input is nothing, actually. What a game does most of the time:

  • Processing the scene graph, sorting hundreds of objects for rendering in the render queues.

  • Updating said hundreds of objects for physics, this involves solving differential equations for said objects and traversing collision trees spanning the entire scene.

  • Updating skinning, particles, other animations for objects

  • AI + Pathfinding

  • Decoding audio files such as SFX and music

I understand how trivial input is in a computational sense, I just think micro-optimizations are appropriate for complex game loops, especially when there is no difference in the amount of work done to code it. Rationalizing the arbitrariness of it isn’t a convincing argument for me to use a more complex technique that is less efficient. LWJGL/jInput’s Keyboard class is super easy to use and really fast-- I’m just trying to see if there are any advantages to using jME’s inputManager.







Err… setActionCommand lets you assign a string/tag to an object that is firing an action Listener (it’s an inherited method from something- then you use getActionCommand in the listener to get that string… it might just be swing related, IDK)-- I was more or less curious whether or not this method was used internally, or whether the inputManager could be modified to used an enumerated type (without using a string as a wrapper technique).

I understand how trivial input is in a computational sense, I just think micro-optimizations are appropriate for complex game loops, especially when there is no difference in the amount of work done to code it.

You can't use enums for this since the user will have to define his own and that won't cooperate with other enums.
The point in using strings is that you can avoid conflict between various systems that use input. For example all the inputs used by the FlyByCamera start with FLYCAM so there are no conflicts.

Rationalizing the arbitrariness of it isn’t a convincing argument for me to use a more complex technique that is less efficient. LWJGL/jInput’s Keyboard class is super easy to use and really fast– I’m just trying to see if there are any advantages to using jME’s inputManager.

The point of jME's InputManager is that input is abstracted, you can use keyboard, mouse, and joystick(controller) with one interface.

If you want to directly access input using LWJGL's classes, thats fine. Nobody is forcing you to use InputManager if you feel its "too slow" for your needs.