Crates.io | bevy_wasm_touch_fix |
lib.rs | bevy_wasm_touch_fix |
version | 0.1.2 |
source | src |
created_at | 2023-11-10 19:46:01.790488 |
updated_at | 2023-11-11 00:13:23.563449 |
description | For Bevy >=0.12, a plugin that fixes the issues of incorrect touch positions in wasm |
homepage | |
repository | https://github.com/bilowik/bevy_wasm_touch_fix |
max_upload_size | |
id | 1031430 |
size | 107,853 |
A plugin to fix the issue with touch inputs in web-embedded Bevy applications where touch input positions are relative to the web page's viewport and not the canvas. Fixes both UI elements and when reading TouchInput events or the Touches resource.
Add the plugin and ensure the canvas id in the html where the bevy app is rendered matches
the one set in the WindowPlugin and in the PrimaryCanvasId resource. The default for this
value in the resource is main-canvas
For example, in the html where the bevy app is rendered, specify the id of the canvas:
<canvas id="main-canvas"></canvas>
Then you need to configure the Window plugin to render to that ID as well:
App::new()
.with_plugins(DefaultPlugins.set(WindowPlugin {
primary_Window: Some(Window {
canvas: Some(String::from("#main-canvas")),
..default()
}),
..default()
}))
// ...
and if you utilize a different ID than the default main-canvas
, you will need to change the
PrimaryCanvasId resource.
//...
.insert_resource(PrimaryCanvasId(String::from("#my-custom-id")));
//...
My testing of this has been limited to very basic web pages. I'm pretty certain this isn't the case,
but is possible that the web-sys::Element::get_bounding_client_rect
alone may not be all that is
needed to calculate an accurate offset for complex web pages.
In the case that additional adjustments are needed on your end, you should utilize the [AdditionalTouchOffset] resource and add any additional offset there that is needed and it will be included in the offsetting of the touch events.
I also do not know the exact implications (if any) of pulling off the events and pushing them back on. I guaranteed that both a and b queues remain the same (+ the offset of course) before and after the offsetting, but the event count will increment twice as fast.