-
-
Notifications
You must be signed in to change notification settings - Fork 55
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 numerous events and input display example #15
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you again for all your work! I did not imagine having contributors this soon. I really appreciate it! 😄
src/graphics/window/event.rs
Outdated
) => f(Event::Input(input::Event::WindowMoved { | ||
x: x as f32, | ||
y: y as f32, | ||
})), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, Coffee exposes all the positions in physical coordinates. Although this may change soon (check out #6), we should convert this into physical coordinates to stay consistent.
The CursorMoved
event does this and may serve us as a guide. We simply need to add a new window::Event
(we can name it Moved
) and then convert it into an input::Event
using window.dpi()
in the game loop, like we do right here for CursorMoved
.
I am aware this is a bit awkward, but if we end up doing #6 this complexity will go away!
This reminded me of a thing! We could use the We could also render some text in |
Interesting! I hadn't considered how the example would work with high refresh rates. I'll do some tweaking along the lines of what you suggested. Thanks for the feedback. I'll try to work on this a bit later today. |
I just realized that There's no hurry, take all the time you want 👍 |
I fixed the issue with not mapping logical->physical coordinates in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Superb! Thank you 🎉
size: 20.0, | ||
color: Color::from_rgb(255, 0, 0), | ||
}); | ||
// This closure simplifies some of the boilerplate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool! I may copy this for the Debug
key/value feature (#17).
y: position.y as f32, | ||
}, | ||
) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏
#12
This exposes the following additional
input::Event
variants:TextInput
: Triggers on text entry. Contains the character typed as achar
.CursorEntered
/CursorLeft
: Triggers when the mouse cursor enters or leaves the game window, respectively.MouseWheel
: Triggers when the mouse wheel is scrolled. Contains the number of horizontal and vertical lines scrolled asf32
.WindowFocused
/WindowUnfocused
: Triggers when the game window gains or loses focus, respectively. (This was originally 1 event with a bool in winit; I split it into two to mirrorCursorEntered
/CursorLeft
.)WindowMoved
: Triggers when the game window is moved. Contains the new X and Y coordinates of the window asf32
.The naming will probably need updating to match your personal style.
Besides that, I've added an example that displays inputs, but it's pretty roughly written. If this is something you think might be good to have in the repository, I can take some time to refactor it a bit (like reducing all the label drawing by writing a helper, etc.). Currently it draws a red square under the mouse's position, displays pressed/released mouse buttons/keys, scroll wheel scrolls, and has a text buffer at the bottom to test the text entry event (supporting backspace). It's very likely not idiomatic Rust, either (I'm fairly new to the language), so ultimately it's your call whether you want to keep this or drop it.
A raw input display-style sample like this may not be suited to your engine, either; since
Game::draw
has no access toInput
, there's a lot of passing variables fromGame::on_input
toInput
toGame::interact
toGame
and finally toGame::draw
, so it may be a bit too complex for an example.Let me know if there are any other events I should implement, names I should change, fields I should expose...