Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an API for capturing input focus #161

Closed
fatcerberus opened this issue May 28, 2017 · 8 comments
Closed

Add an API for capturing input focus #161

fatcerberus opened this issue May 28, 2017 · 8 comments

Comments

@fatcerberus
Copy link
Member

In some cases it might be desirable for a component to "take over" input from the rest of the game; the Terminal module would be a good use case for this. Currently that's not possible since input devices are a shared resource and any invocation of, e.g. Keyboard#getKey() from a thread will necessarily steal input from other threads.

What I'm thinking of is some sort of "lock and key" mechanism. One would call .lock() on, say, the keyboard, and receive a token back that would need to be used to read input from that point on. Once exclusive input is no longer needed, the lock would be released, resuming normal operation.

@fatcerberus
Copy link
Member Author

Moving this up to 4.6, since I'm thinking I'll be able to build this on top of the existing Keyboard API. The lock function, whatever it ends up being called, would return a Keyboard object that has exclusive access to the key buffer and key states until the lock is released. Keyboard.Default, if accessed, would just return neutral values for all requests (false for states, null for .getKey())

@DaVince
Copy link

DaVince commented Jun 15, 2017

Would this also be useful for regular in-game use, for example simplifying speech box or menu input, clearly separating one speech box from the next for example? That's always been kinda messy to deal with in old Sphere.

@fatcerberus
Copy link
Member Author

Essentially this would be a way for stateful games to "steal" keyboard focus for a particular element (menu, console, text boxes, etc.) while the normal game logic, like a map engine, could continue to run in the background and even request input, avoding the need for a specific check "is there a menu open now?"

So if I'm interpreting your question correctly, then the answer is yes.

@DaVince
Copy link

DaVince commented Jun 15, 2017 via email

@fatcerberus
Copy link
Member Author

It'd probably be good to implement this for joystick input as well.

The mouse is trickier, since there's no actual neutral value for the pointer location. Anywhere you place the cursor, even in the center of the screen, could potentially interfere with the (non-focused) code reading it back. I guess one way to go about it would be to save the location of the cursor at the time the focus is stolen and just keep returning that until focus is returned.

@fatcerberus
Copy link
Member Author

Having thought about this some more in the past week, I don't think this should be part of the Core API--which is meant to be low-level and closer to the "bare metal" as it were. Instead it will be part of the Sphere runtime (née miniRT).

Not sure on an API just yet; coming up with one will need some more thought.

@fatcerberus fatcerberus modified the milestones: v5.0.0, v4.6.0 Jun 26, 2017
@fatcerberus
Copy link
Member Author

Some version of this will be implemented in miniSphere 5.0. The idea I have right now is to integrate it into the Thread class somehow. That seems like a good fit for this since Thread already has a checkInput() method that can be called (or not) independently of update().

@fatcerberus
Copy link
Member Author

thread.mjs now has the ability for threads to take input focus one at a time by calling thread.takeInput(). The way the API is designed is maybe a bit rigid and worth thinking about altenatives, but the initial work is done, so I'll close the ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants