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

MouseButton input bug when captured #1009

Closed
nic96 opened this issue Dec 6, 2020 · 6 comments
Closed

MouseButton input bug when captured #1009

nic96 opened this issue Dec 6, 2020 · 6 comments
Labels
A-Input Player input via keyboard, mouse, gamepad, and more C-Bug An unexpected or incorrect behavior

Comments

@nic96
Copy link
Contributor

nic96 commented Dec 6, 2020

Bevy version
Commit: 1398d78

Operating system & version

Linux
I have a high DPI display which may or may not be relevant.

What you did

When mouse is captured if you move the mouse to one side mouse button input quits working.

I made an example where whenever you click the ClearColor changes
The first time you click you're mouse will also get captured

Here's a reproducible example:

use bevy::prelude::*;

fn main() {
    App::build()
        .add_resource(ClearColor(Color::rgb_u8(100, 30, 30)))
        .add_resource(ClickCount(0))
        .add_plugins(DefaultPlugins)
        .add_system(capture_mouse_system)
        .add_system(change_color_system)
        .run();
}

struct ClickCount(pub u32);

fn capture_mouse_system(
    keyboard_input: Res<Input<KeyCode>>,
    mouse_input: Res<Input<MouseButton>>,
    mut windows: ResMut<Windows>,
) {
    if let Some(window) = windows.get_primary_mut() {
        if window.cursor_visible() {
            if mouse_input.just_pressed(MouseButton::Left) {
                window.set_cursor_visibility(false);
                window.set_cursor_lock_mode(true);
            }
        } else {
            if keyboard_input.just_pressed(KeyCode::Escape) {
                window.set_cursor_visibility(true);
                window.set_cursor_lock_mode(false);
            }
        }
    }
}

fn change_color_system(
    mut clear_color: ResMut<ClearColor>,
    mouse_input: Res<Input<MouseButton>>,
    mut click_count: ResMut<ClickCount>,
) {
    let colors = [
        Color::rgb_u8(100, 30, 30),
        Color::rgb_u8(30, 100, 30),
        Color::rgb_u8(30, 30, 100),
    ];

    if mouse_input.just_pressed(MouseButton::Left) {
        click_count.0 += 1;
    }

    clear_color.0 = colors[click_count.0 as usize % colors.len()];
}

What you expected to happen

MouseButton input should work no matter how far you move the mouse.

What actually happened

When moving the mouse too far to the side MouseButton input quits working.

@nic96
Copy link
Contributor Author

nic96 commented Dec 6, 2020

I just realized it only quits working when moving the mouse too far to the left. Other directions don't cause the problem
And it's window size dependent so It might be related to the high DPI rounding errors in #1003

@Moxinilian Moxinilian added C-Bug An unexpected or incorrect behavior A-Input Player input via keyboard, mouse, gamepad, and more labels Dec 6, 2020
@nic96
Copy link
Contributor Author

nic96 commented Dec 7, 2020

I was able to workaround it be setting the cursor position every frame. I think it could possibly be an X11, KDE Plasma, or perhaps winit bug, but I haven't narrowed it down yet. For now I'm fine with just setting the cursor position.

Edit: and it doesn't happen full screen. Only when the window is on the left side of the screen so maybe it has something to do with KDE's cursor screen edge detection.

@Aceeri
Copy link
Member

Aceeri commented Dec 5, 2022

I don't think this is necessarily a bug, since it is more expected behavior that the window shouldn't get mouse events when it leaves the window, in games you might want to lock the cursor using .set_cursor_grab_mode(CursorGrabMode::Locked) or by manually setting cursor position as you said.

@tim-blackbird
Copy link
Contributor

Their example does lock the cursor

@Aceeri
Copy link
Member

Aceeri commented Dec 5, 2022

Ah true, I'm not entirely sure then, I'm guessing that the locking might've been erroring out for whatever reason, I don't think we really logged that before or that was overlooked in the logs?

@nic96
Copy link
Contributor Author

nic96 commented Jul 10, 2023

A bit late but the issue no longer exists with cursor CursorGrabMode::Locked so closing the issue.

@nic96 nic96 closed this as completed Jul 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Input Player input via keyboard, mouse, gamepad, and more C-Bug An unexpected or incorrect behavior
Projects
None yet
Development

No branches or pull requests

4 participants