Enabled pointer lock to capture the pointer when the canvas is clicked

[michael-j-green]

The code was already in place, but was restricted to only running on the NDS (for testing I assume?). This PR removes that check to make pointer capture available for all cores.

This functionality is useful for many platforms that use a mouse as a primary input device.

[allancoding]

I think it was because NDS had mouse support.

[ethanaobrien]

The code was already in place, but was restricted to only running on the NDS

It was restricted to nds because that was the only system I was aware of that needs the mouse to be locked.

I don't think we should lock for every system. If a system consistently across every game needs to lock, we should lock the cursor for that system, but if only a few games need it, they should enable an option to enable locking. From my point of view this can be confusing to the user and feels unclean to lock your cursor to do nothing with it

[michael-j-green]

I think there's arguments for both sides.

For a system like Gaseous where EJS is used for multiple platforms, it would be more consistent from a UX point of view to have the same behaviour for all - plus it telegraphs to the user that input is going to EJS.

Perhaps a compromise of it being enabled by a variable would be a good idea? Doing it this way means that projects can set it how they want. This would also mean that we don't have to account for every use case in code as that could get ugly. We don't want to prevent those 5 users from using a mouse with their SNES ROMs after all :D https://en.wikipedia.org/wiki/Super_NES_Mouse

The variable would enable or disable the pointer lock, but would be ignored on touch devices as it currently is.

[ethanaobrien]

I do think that's the best idea, a config option you can enable to lock the pointer (with disabled by default)

Maybe this should be put in the settings menu rather than its own global variable option?

[michael-j-green]

Perhaps both?

If defined by the global option, we hide it from the settings menu. Otherwise show it and allow the user to set it.

[ethanaobrien]

That works too, only end difference would be hiding it if it's forced enabled since if it's in the settings menu it can be set via default options

[michael-j-green]

Added Settings menu item to enable or disable pointer capture:

• Removed the platform test - as this only affected NDS
• Removed the platform test from the exit pointer lock function - we're exiting, who cares which platform it's on?
• The touch test remains - pointer capture will not be enabled while on a touch only device

[michael-j-green]

Something I haven't been able to work out is how to detect if we're on a touch platform when we're building the menu. If we're on a touch platform, I'd like to hide the "Capture Pointer" menu item from Settings as it's not relevant - and wouldn't do anything anyway.

[ethanaobrien]

Removed the platform test - as this only affected NDS

Can we set any systems that consistently have a need for pointer lock to have this setting enabled by default?

Something I haven't been able to work out is how to detect if we're on a touch platform when we're building the menu. If we're on a touch platform, I'd like to hide the "Capture Pointer" menu item from Settings as it's not relevant - and wouldn't do anything anyway.

From what Ive seen theres no true way to tell if the user has a mouse plugged in, and they could at any time just plug one in.

[michael-j-green]

Can we set any systems that consistently have a need for pointer lock to have this setting enabled by default?

I'm sure we can. Though that might make the UX a bit inconsistent. Lets say I want to play Sonic on Mega Drive, there would be no mouse capture. Then I want to play Super Frog on Amiga, there would be a mouse capture. The behaviour being slightly different during gameplay might be a bit off putting.

Perhaps an "Auto" option in addition to Enabled and Disabled? Then the user can select the behaviour they want.

The bigger issue is how do we define which systems support it? I'd love to get away from magic values in the code (like the removed "if core is NDS" condition).

I really need to come up with a JSON structure in the build project to define core capabilities, file types, etc.

From what Ive seen theres no true way to tell if the user has a mouse plugged in, and they could at any time just plug one in.

I don't think there would be too much issue with just detecting if we're on a mobile device or not at start up. Granted it's not as clean as "plug mouse into an iPad and now the option appears", but it's not totally ugly either :D

[ethanaobrien]

The behaviour being slightly different during gameplay might be a bit off putting.

I guess I could understand that. I thought it felt fine before though, because from my point of view it makes sense to lock based on whether or not the console needs it, and locking for a console that will never use it is confusing, from my point of view. While it may appear inconsistent, it's consistently inconsistent

The bigger issue is how do we define which systems support it? I'd love to get away from magic values in the code (like the removed "if core is NDS" condition).

We could just define an array and check if the core is in that array, and set it to enabled based on that.

Perhaps an "Auto" option in addition to Enabled and Disabled? Then the user can select the behaviour they want.

I think this would cause confusion in the long run.

I don't think there would be too much issue with just detecting if we're on a mobile device or not at start up

Issue with this is we can't check for emulators/chromeos's android subsystem/waydroid

[michael-j-green]

I have an idea for managing this. I've removed the reviewers for the time being, and will convert this to a draft PR.

[michael-j-green]

Logic to implement: #816 (comment)

Thinking we do this:

• provide an option to enable mouse capture on canvas click - this option should have a corresponding variable exposed to the host page (default false)
• if that first option is enabled, then provide another option to enable auto-capture - this option should have a corresponding variable exposed to the host page (default false)

Mouse capture is a requirement for many platforms, and mouse capture means that we don't have to do any funky scaling to match the host mouse movements to the emulation.