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 numerous events and input display example #15

Merged
merged 2 commits into from
Apr 27, 2019

Conversation

jalbert-dev
Copy link
Contributor

#12

This exposes the following additional input::Event variants:

  • TextInput: Triggers on text entry. Contains the character typed as a char.
  • 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 as f32.
  • 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 mirror CursorEntered/CursorLeft.)
  • WindowMoved: Triggers when the game window is moved. Contains the new X and Y coordinates of the window as f32.

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 to Input, there's a lot of passing variables from Game::on_input to Input to Game::interact to Game and finally to Game::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...

Copy link
Owner

@hecrj hecrj left a 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! 😄

examples/input.rs Show resolved Hide resolved
examples/input.rs Show resolved Hide resolved
) => f(Event::Input(input::Event::WindowMoved {
x: x as f32,
y: y as f32,
})),
Copy link
Owner

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!

@hecrj
Copy link
Owner

hecrj commented Apr 26, 2019

A raw input display-style sample like this may not be suited to your engine, either; since Game::draw has no access to Input, there's a lot of passing variables from Game::on_input to Input to Game::interact to Game and finally to Game::draw, so it may be a bit too complex for an example.

This reminded me of a thing! We could use the Game::debug method to draw everything in the example, as it has access to Input and View! We will probably need a way to enable the debug view by default when the application runs instead of having to press the debug key (there is a debug feature already that we can use!), but don't worry about it. I can add that later easily (done!) .

We could also render some text in draw asking the user to enable the debug view by pressing F12, or asking them to enable the debug feature if they used --release.

@jalbert-dev
Copy link
Contributor Author

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.

@hecrj
Copy link
Owner

hecrj commented Apr 26, 2019

I just realized that debug does not have mutable access to the View, so we won't be able to use the Font for rendering text. My bad. Let's render in draw for now, I will think about how to make debug more flexible (edit: I have opened an issue with some ideas).

There's no hurry, take all the time you want 👍

@jalbert-dev
Copy link
Contributor Author

I fixed the issue with not mapping logical->physical coordinates in input::Event::WindowMoved (whoops) and revised the example slightly, as you suggested 🎉 Good practice would probably dictate that I use a dirty flag or something to stop the program from creating a bunch of strings every draw, but oh well

Copy link
Owner

@hecrj hecrj left a 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.
Copy link
Owner

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,
},
)
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👏

@hecrj hecrj merged commit 3e8fd0d into hecrj:master Apr 27, 2019
@jalbert-dev jalbert-dev deleted the feature/additional-events branch April 27, 2019 18:38
@hecrj hecrj added the feature New feature or request label Apr 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants