-
Notifications
You must be signed in to change notification settings - Fork 522
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 sokol_app callback before event queue is iterated (or add an input polling API) #293
Comments
Hi, there's another input-related request here: #283, it's not really closely related, but all in all it looks like the current sokol_app.h input model isn't flexible enough for different usage scenarios... Some thoughts:
...and then once per frame in the frame callback I update the Dear ImGui input state similar to polling: Lines 1151 to 1172 in 9b659b2
Maybe a similar idea makes sense for Nuklear too? |
Yeah I am doing something quite similar for Nuklear already, though like you mentioned (same frame down and up events) there's a number of cases I haven't handled yet. My thought was that maybe the common caching stuff could be extracted if there's multiple targets it would be useful for. It seems Oryol already has such an API. |
For some third-party libraries (right now I'm just thinking about Nuklear) it would be useful to have a callback that is called before the event queue gets processed for the given frame.
E.g. for the win32 implementation:
The reason this would be useful is Nuklear requires you to call
nk_input_begin
before you call its input event hooks, andnk_input_end
afterwards.It is possible to get around this limitation by just calling
nk_input_begin
andnk_input_end
inside yourframe_cb
implementation. But you then need to have a way to query the current state with an input polling API.Other app frameworks (e.g. GLFW) support this input polling style, but sokol_app only supports an event-based push model. You can build your own state cache and implement a polling model on top of sokol_app, but that's more work.
Alternate Proposal
I'm not sure if that proposed callback is going to be possible for MacOS (and other app models that don't seem to require the app implementation to manually pump the event queue - I'm not 100% sure of these, it just looked this way while browsing the sokol_app source code).
If this isn't going to work, an alternate proposal would be to implement an input state cache and polling API to sokol_app.
E.g.
Edit: Also would probably be useful to have
just_pressed
variants, since Nuklear seems to need them to work like that.I don't think this would be very complicated, and I think it would be more likely to work on all app types.
The thing that would prevent it from working is you don't have enough hooks to properly clear state before each frame. It would also require the Sokol API to deal with problems like switching windows while holding a key down, then switching back.
The text was updated successfully, but these errors were encountered: