Idea: mouseFreeze, A solution for Browser FPS Games(blog.vjeux.com)
blog.vjeux.com
Idea: mouseFreeze, A solution for Browser FPS Games
http://blog.vjeux.com/2011/javascript/idea-mousefreeze-a-solution-for-browser-fps-games.html
17 comments
Thanks for doing this. It would be great if this stuff takes off!
For completeness here is the Firefox bug tracking this: https://bugzilla.mozilla.org/show_bug.cgi?id=633602
For completeness here is the Firefox bug tracking this: https://bugzilla.mozilla.org/show_bug.cgi?id=633602
Thanks for pointing out the bug report, this is great to see that this issue is being worked on. I hope that my proposal will help you model the API.
This should probably be a browser API, with a standardized "do you want this page to steal your cursor" and "press escape to release cursor" interface.
This could be a browser permission based feature, like location is at the moment. The app asks the browser to prompt the user to give permission for this domain to "Control your mouse pointer". The cursor should always be released when you alt-tab away or press the ESC key (maybe the would need to be a time limit within which the mouse couldn't be captured again).
>maybe the would need to be a time limit within which the mouse couldn't be captured again
Why not re-capture only when the user clicks on the game again? In fact, I don't think the permission bar is needed at all, it would be implicitly given by clicking.
Of course, ESC should always work. Which would actually work fine for most games, since ESC presents a menu where the pointer isn't supposed to be frozen anyway.
Why not re-capture only when the user clicks on the game again? In fact, I don't think the permission bar is needed at all, it would be implicitly given by clicking.
Of course, ESC should always work. Which would actually work fine for most games, since ESC presents a menu where the pointer isn't supposed to be frozen anyway.
So you go to a malicious website and it's able to move your mouse around or lock it in place. That would not be a good situation to be in, especially for the segment of the population that doesn't understand keyboard shortcuts (which would, presumably, allow escape from this). Even if it's not used maliciously, it seems very plausible that it would be used to make advertisements harder to avoid (on websites like Hulu that run ads during a video, preventing most users from being able to go elsewhere during them could be a tempting idea).
I get why something with this effect is necessary if we are to have FPS games running in the browser, I just don't think that it's a good idea to allow websites to do so without explicit user permission. Admittedly, there are few things I hate as much as programs moving my mouse around, so I'm a bit biased.
I get why something with this effect is necessary if we are to have FPS games running in the browser, I just don't think that it's a good idea to allow websites to do so without explicit user permission. Admittedly, there are few things I hate as much as programs moving my mouse around, so I'm a bit biased.
The article's suggestion does not say the mouse would be moved or locked by the web program. The program would be able to hide the cursor (which it can already do) and receive 'virtual' mouse coordinates.
My main concern is number overflow for long-running applications, but I seriously doubt this will be a problem for anyone.
I don't see any security problems with the proposed solution (though I don't claim to be a security expert!).
My main concern is number overflow for long-running applications, but I seriously doubt this will be a problem for anyone.
I don't see any security problems with the proposed solution (though I don't claim to be a security expert!).
I may be hugely misreading the article, but when it says "The mouse will be anchored to that position and the mousemove events are going to set a virtual position" and "Everytime the user moves the mouse ... the cursor is moved to the center of the screen" I find it difficult to interpret that in any way that doesn't effectively mean that a website is able to move or lock the cursor. I admit that I use cursor and mouse interchangeably, when they're actually not the exact same thing, however.
Okay, I missed "The mouse will be anchored to that position" part. I really disagree with this part of the proposal. Thanks for pointing it out.
However, the comment about the cursor moving to the centre of the screen is an implementation detail. At least on Windows, you need to centre the mouse cursor for something like this because the OS won't (easily) give you actual virtual coordinates.
However, the comment about the cursor moving to the centre of the screen is an implementation detail. At least on Windows, you need to centre the mouse cursor for something like this because the OS won't (easily) give you actual virtual coordinates.
Javascript can hold full precision integers up to 2^53. Let's say you can mouve by 1024 pixels per seconds. It would take 2^53 / (3600 * 24 * 365.25) ~= 280 000 years to get beyond the limit.
I think we are pretty safe on that part, even for veery long running app.
I think we are pretty safe on that part, even for veery long running app.
It sounds like there's two main use-cases here:
- Infinite dragging of a particular element; for example, scrolling in Google Maps or the sort of 'click and drag' UI of a typical billiards or mini-golf game.
- Relative movement events in general, as used for 'mouse-look' in FPS games.
For the first use-case, it should be pretty easy to deal with. Add a property to the 'mousedown' event called 'relativeMode' (or whatever), initially set to false. If the event-handler sets 'relativeMode' to true, then instead of sending the usual string of 'mousemove' events to elements the cursor moves over, the browser should capture ("freeze") the mouse, hide the cursor, and deliver 'mousedelta' events to the original element (whose x and y properties contain the movement delta from the location of the original mousedown event). When the user lets go of the mouse button, the browser releases the capture and shows the cursor. There's no security issue, because the user is in control of the capture at all times, and can just release the mouse button whenever they want.
The second use-case is a bit more troublesome, but as the Chrome bug linked elsewhere in this thread mentions, "web-pages in full-screen mode effectively own the cursor anyway". Perhaps a similar 'relativeMode' property could be added to the 'fullscreen' event.
- Infinite dragging of a particular element; for example, scrolling in Google Maps or the sort of 'click and drag' UI of a typical billiards or mini-golf game.
- Relative movement events in general, as used for 'mouse-look' in FPS games.
For the first use-case, it should be pretty easy to deal with. Add a property to the 'mousedown' event called 'relativeMode' (or whatever), initially set to false. If the event-handler sets 'relativeMode' to true, then instead of sending the usual string of 'mousemove' events to elements the cursor moves over, the browser should capture ("freeze") the mouse, hide the cursor, and deliver 'mousedelta' events to the original element (whose x and y properties contain the movement delta from the location of the original mousedown event). When the user lets go of the mouse button, the browser releases the capture and shows the cursor. There's no security issue, because the user is in control of the capture at all times, and can just release the mouse button whenever they want.
The second use-case is a bit more troublesome, but as the Chrome bug linked elsewhere in this thread mentions, "web-pages in full-screen mode effectively own the cursor anyway". Perhaps a similar 'relativeMode' property could be added to the 'fullscreen' event.
I think a much simpler idea would to have a onmousedelta event which fires whenever the mouse moves and that tab has focus (including outside window boundary) and includes a .deltaX and .deltaY event property.
That way, the user has full control over their mouse and you can also develop fps games.
That way, the user has full control over their mouse and you can also develop fps games.
It's unlikely that the operating system's standard mouse events will continue to report mouse movement when the cursor runs into the edge of the screen. Plus it would be very distracting to have a mouse cursor running around outside the active window.
What happens when the user moves the cursor outside the window, and then clicks? Or moves the cursor into a hot corner of the screen, activating something like a screen saver?
Deltas are necessary but are only part of the solution.
Deltas are necessary but are only part of the solution.
Anyone seriously considering the web browser as a platform for future 3d gaming is, of course, in a state of sin.
(stolen from Jon Von Neumann's famous random number quote)
(stolen from Jon Von Neumann's famous random number quote)
There are many problems regarding this idea, specially security for the user, this is why it's hard to convince the people of the benefits for RTS and FPS games.