Quick question. I want to make an abstract input class so I can poll the mouse and keyboard from a static context wherever, but I am not 100% sure if I can actually add it as a KeyListener since I can't instantiate it. Would Input.class work or is it not possible?

A singleton eh? I'm not sure if that would work or not. I'll go try right now.

I want to have just a class where I can check the input from anywhere with static methods. So in any one game state I can say Input.isKeyDown and it will work. Not even sure if it is doable but I'm gonna try.

Well I went to go try the singleton idea when I had an epiphany. I made a Keyboard class that implemented KeyListener that held all the key constants and the isKeyDown and isKeyUp methods. Then I can supply Input.keyboard as a listener and when I check inputs.

Unfortunately I think my idea of a static input won't work. I have an array of booleans to represent key states and a list of int constants for each key's spot in the array. Inside keylisteners methods I have a switch statement to check against KeyEvent's constants. Then I can set a certain key in the array to false or true. Finally isKeyDown checks the array for true or false on th key you query it about.

However, it seems there is some lag between the pressing and th query...ill keep at it, i don't think its doable.

Hmm, I would think it would work fine since only one thing is setting the variables so no synchronization problems would occur.

Are you referring "lag" to the delay between key press / poll detection? becuase there will always be a lag when you're polling I guess.

I guess there are so many ways you could design this. I don't think I've ever done polling on key inputs or even polling at all. In cases where I seem to need polling I have used a Thread that does a Object.wait(); and then the code that sets the variable will do a Object.notify();

If you keep having problems with this, I'm sure we can figure something out, I just need to know more about what you are trying to do :-). And then, I'm not the big Java Guru myself :-D.

@sproingieWell the goal was to have a system where no matter where I am in the code I can poll the keyboard without passing objects around or having 8 keylisteners. The most obvious solution to me was an abstract class with static methods.

I have an abstract class called Input. It doesn't extend anything and it doesn't use any interfaces. In it, I have an instance of a Keyboard class as well as an init and getKeyboard method both of which are public static methods.

Keyboard is a keylistener and has a ton of static int constants for key codes as well as an array of booleans that is the same size as the number of key code constants. Basically each array element represents an individual keys being pressed (true) or normal (false). There is a reset method which just sets all the key states to false, an isKeyDown method which returns true if the element of the provided key code is true, and an isKeyUp method which returns true if the element of the provided key code is false.

In the keyPressed method I have a switch statement for the key event's key code and for each case I will set the array element to true with my key constant. As an example, I might have case KeyEvent.VK_ESCAPE: keyboard[KEY_ESC] = true: where KEY_ESC is my constant for the escape key. I do the same thing for keyReleased but I'll set it to false instead because that means they let go of the key.

So say they press Q. KeyPressed will be called and it will prse the switch statement to find case KeyEvent.VK_Q. In that case, I will use my int constant for Q which might have set to 15 or something. I'll use that as my index for my boolean array and set element 15 (in this case KEY_Q I would have set to 15) to true because VK_Q was pressed. That all happens automatically in the EventDispatchThread. Now in my update method, after adding Input.getKeyboard() as a KeyListener, I can say if (Input.getKeyboard().isKeyDown(Keyboard.KEY_Q)) { ... } to detect if Key Q was pressed.

I hope I explained that well enough. Basically the goal was to be able to poll the keyboard from anywhere without needing object passing or registering more than one key listener.

I think you need to refine your sense of object-oriented design. Throwing everything into a static scope just because it's global is not the way you do it. You're supposed to pass objects around, but you can collect several onto one object and pass that around. Worst case is you stick just a few objects into a static scope and use that as the root of your references (see the Gdx class in libgdx for an example of that)

Maybe you need to look into method delegating, where Input is not abstract but holds an ArrayList of InputHandlers (which would be an interface that extends KeyListener), and then Input delegates the events to all attached InputHandlers.

@evilfrenchguy I know that using a static object might not be the way to go, but still I think this should work.

I understand what you want to do, but not how you are doing it. Maybe you could post an example about how you are setting the array variable on keyPressed() and how you are polling the array?

Or you could send me the code (my email's in my profile) - I promise not to keep it :-).

@sproingie You're right that this might be the "ideal" way of doing OO, but I find sometimes there's a compromise between "Generic nice code" and "performing flexible code". I agree that "global" variables should be avoided because it's hell to debug, and it's nice to see on a methods definition which data it depends on.

I use a static Game object in my code though, where I keep states like DAY_CYCLE, so the AI and entities can lookup the time of day. Passing all that data around to every method would make a mess :-).

Well if singleton is bad than its use will also be bad. We can pool input, display's properties and file from anywhere.I don't really question about pattern as long it works, but we can't live with no pattern, world said.

The libraries Gdx keeps a reference to are naturally singletons. Input is a natural singleton too (sort of). I never said singleton is bad by itself, though it's often implemented wrong. Writing your app in a static scope for the convenience of global references is a different thing entirely. And do note that singletons are still instances, not static classes.

yep, having a single instance and there for a singelton of something is a right approach for some stuff.What to be carefull about is that keeping this singelton in global space, cause now you have global state which is bad.Especially in libgdx, were the singoltons aren't even hold in a final reference, but can be changed anytime by any subsystem.Remember its called Singelton pattern, not Globalton.

A right way of doing it would be dependency injection(which is also a pattern). You don't need necessarily a framework like spring or guice for it. A simple application factory can do the object graph setup at the beginning of the program exactly as well.

A right way of doing it would be dependency injection(which is also a pattern). You don't need necessarily a framework like spring or guice for it. A simple application factory can do the object graph setup at the beginning of the program exactly as well.

DI is another great approach, and IMHO is The Right Way to do Singleton. I stayed away from it in this conversation because it's not especially popular in game dev circles. You don't need guice, no, but damn if it isn't handy. Spring I have far less patience with these days. Picocontainer is also a viable option.

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