-
Notifications
You must be signed in to change notification settings - Fork 7.1k
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
mouseWheelCallback : different behaviours/events on 'chrome/android/ios' vs firefox #1313
Comments
You should read the property wheelDelta (game.input.mouse.wheelDelta) it will contain the constants for up and down. (Phaser.Mouse.WHEEL_UP and WHEEL_DOWN). A cross browser real delta that gives you an idea of how much up and down is harder to get I guess and you will have to figure out yourself. If you have a good solution make a PR to add to it :) For me (I added this functionality through a PR) knowing a mousewheel up or down happened was enough (used it to switch weapons in a game) |
Hi Wouter, thanks for that! Also, while this might be a pretty unlikely issue to run into(you need a PC, with a touchscreen, and to be using firefox), the other part of the report, ie. Firefox calling the mouseWheelCallback vs onInputDown on touch input, still stands. |
@vorrin The mouse in the PR has been updated to support Wheel events, which have been in FF since version 17 and IE since 9. Both the older Mouse Wheel (scroll in scrollDelta property) and DOM Scroll events (scroll in detail property) are wrapped to support the Wheel event interface if such a fallback is required. Feel free to use either mouse.wheelDelta or event.deltaY (but do not share/use the event past the event handler). Remember to check the deltaMode - 1 is lines (probably the most common), but it could also be 0 (pixels) or 2 (pages). Also, deltaY and wheelDelta have inverted signs. Ref. https://developer.mozilla.org/en-US/docs/Web/Events/wheel |
@pnstickne oh excellent, thanks! That said though, I'm not sure by which change, but I get some really weird display problems with your version, with some sprites and bitmap text being placed in a completely different position on screen, ie. this is bitmap text added to a group together with a couple of sprites: basic version: http://i.imgur.com/oHKeBvx.png your branch: http://i.imgur.com/soZQXNN.png As you can see the bitmap text goes way off in that second one. Not sure if it comes from another change you previously made in your branch or well, what causes it at all. |
@vorrin Uh oh, that's likely from this code, but it does appear to be a problem with the 2.2.x/dev branch - there be some changes with/to the underlying PIXI and graphics as well. Does 2.1.3 or the "vanilla" pre-PR 2.2.x (dev) have the same issues? If so that would be worth posting another bug report for. |
@vorrin As far the actual scroll delta .. that can definitely change. To get a more precise value it may be warranted to have the user "calibrate" a scaling factor/transformation for the device input (or to do so unaware from the user) - assuming that it is capable of reporting a more precise scroll value and deltaMode=0 .. on my desktop, a line (eg. in deltaMode=1) is ~28-33 pixels, depending on browser and various page factors. Ref. http://stackoverflow.com/questions/20110224/what-is-the-height-of-a-line-in-a-wheel-event-deltamode-dom-delta-line for some of the "fun". |
Closing this off as the original issue is resolved. Feel free to open another for the visual issues once I've updated to pixi 2.1 in a few minutes time. |
Hello!
Here's a simple test:
http://jsfiddle.net/J5fUE/92/
when mousewheeling over the canvas, you can see in the console, that the 'event' passed to the callback is very different (ie. the one in firefox, being a DomMouseScroll, does not seem to have deltaY and deltaX, which instead it does have on Chrome).
Am I missing something or is this unexpected? I tried delving a bit further into phaser.js, but from there it looks like a DomMouseScroll listener is assigned in both cases, but in Firefox it ends up being the 'dominant' one.
Also, on firefox, the mousewheel callback is called on touch, as far as I can see.
Any insight on this would be handy, thanks!
The text was updated successfully, but these errors were encountered: