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
Comments
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 |
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. |
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. |
That is pretty much what I was asking, yeah. This sounds very useful to me.
…On Thu, Jun 15, 2017 at 3:13 PM, Bruce Pascoe ***@***.***> wrote:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#161 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGcPeHmJqCWPNmRj219j07c9xUrpLHHks5sES3ggaJpZM4Noisn>
.
|
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. |
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. |
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 |
|
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.The text was updated successfully, but these errors were encountered: