Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Idea: mouseFreeze, A solution for Browser FPS Games

blog.vjeux.com

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Idea: mouseFreeze, A solution for Browser FPS Games

#11

Post by nitrogen »

antimatter15 wrote: post #8

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.

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.

Re: Idea: mouseFreeze, A solution for Browser FPS Games

#12

Post by jos3000 »

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).

Re: Idea: mouseFreeze, A solution for Browser FPS Games

#13

Post by azakai »

maushu wrote: post #6

I believe you are talking about mouse lock ( http://code.google.com/p/chromium/issues/detail?id=72754 ), something Sirisian and me (but mostly Sirisian) have been trying to push into the browsers (right now chrome and hoping the other browsers catch on). 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.

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

Re: Idea: mouseFreeze, A solution for Browser FPS Games

#15

Post by thristian »

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.

Re: Idea: mouseFreeze, A solution for Browser FPS Games

#17

Post by vjeux »

strager wrote: post #3
sorbus wrote: post #2

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…

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 s…

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.

Re: Idea: mouseFreeze, A solution for Browser FPS Games

#18

Post by icebraining »

jos3000 wrote: post #12

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.

Post reply on HN