• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

HTML5 Device Input Coordinates are Incorrect

mimusic

Member
I'm working on a custom touchscreen extension to use with my GMS projects when exporting them through HTML5 but I've run into a strange set of issues. My intention is to track the position of each finger within a resolution-defined layer that acts like a GUI layer, but Device 0 is returning coordinates differently than Device 1, 2, ... Device N. To summarize the issues:
  • device_mouse_x/y are the only functions that behave consistently across all inputs, which isn't a viable option because this variable is dependent upon view properties like location, scale, etc...
  • device_mouse_x/y_to_gui works for input 0, but anything beyond that is awkwardly translated, as if the input coords are not scaling with the layer, despite the GUI itself having a defined resolution. Strangely, when an input begins on the canvas/viewport and is dragged off, it's correct when it's off the canvas. Realistically, this is the function I should be able to rely on just giving me coordinates relative to [0,0] on the GUI layer. This is the one I would really like an explanation for.
  • device_mouse_raw_x/y are not working independent of the view. Tested on a game where I'm using a 3D camera vs a game where I have a stationary 2D camera, and even though the code used is exactly the same, the input coordinate behavior differs. Perhaps I'm misunderstanding the docs when claiming that this function is independent of view and scaling, but either way this is once again a case where the first input device works differently from all devices after. First input works as expected.
Tried to find a solution for any of these problems, but nothing's coming up via Google or MantisBT, and the docs aren't very helpful on explaining this behavior. All I can say is that these problems are exhibited across both Safari and Chrome for iOS, as well as Chrome on Android.

Worst comes to worst, I'll just trigger the touch events in JS and send that info back to GMS via extension, but I would really rather not have to do that just because something isn't behaving as expected. If it's confirmed that the functions are indeed working incorrectly, I'll report the bug properly.

Any help on this issue is greatly appreciated!

- - - - -

Images demonstrating the issues:
white circles are where GM thinks the input is. Green blobs are (roughly) where I was actually touching the screen. Transparent green lines are drawn to show which blob corresponds to which circle.
sc1.png

sc2.png

sc3.png

sc4.png
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Sounds like a bug to me... The raw values should be returned using screen space, the GUI should be GUI space and the regular ones should be room space... all regardless of the device being used for the input.
 

mimusic

Member
Sounds like a bug to me... The raw values should be returned using screen space, the GUI should be GUI space and the regular ones should be room space... all regardless of the device being used for the input.
Yep, this is what I had figured. Unfortunate that it's the case, but I'm always happy to unearth bugs. I spent the evening working on a JS extension that sends touch input back to GML just to confirm that it wasn't the JS Touch API itself behaving weirdly, and my extension is working just fine, so it must be something about how GMS is retrieving touch information. I also threw a couple of breakpoints into the JS-ified game maker code for handling the device_mouse_* functions, and it's just as I suspected -- when the device ID is 0, the function simply grabs standard cursor coords. Anything greater than an ID of 0, it gets the coords via some other method. This is why device 0 functions as expected, it's always being treated like a plain ol' mouse.

I'll try to find sometime this week to make a simplified version of my multi-touch project so that the incorrect behavior can be observed in real time and issues can be addressed accordingly.
 
Top