Godot: Input.get_accelerometer() does not work when running from the editor

[ZodmanPerth]

I develop on the Surface Pro (2017), which has an accelerometer. When I run a project from the Godot editor, Input.get_accelerometer() always returns zero. However, if I export to UWP and run on the same device, the function returns correct values.

When developing games/apps that require the accelerometer, being forced to export in order to test all code changes slows down the development experience very much. I expect running my Godot project from the Editor to read the accelerometer if one is present on the device where it is running.

As a workaround I've had to create helper controls to facilitate development. This improves things, but I still hope it possible to have real readings exposed for the best development experience possible.

Godot version:
v3.0.2.stable.official

OS/device including version:
Windows 10 on Surface Pro (2017). This device has an accelerometer.

Issue description:
When I read Input.get_acceleometer() if running from the editor, I always get a zero-valued Vector3 (as the accelerometer is not read).
When I then export the project to UWP and run on the same device, values are returned.

Steps to reproduce:
Unzip the attached Godot project and run. Notice the output is always zero.
Now export to UWP (you'll need to set that up yourself, or just trust me that it works) . The output shows readings from the Accelerometer are working.

Minimal reproduction project:
AccelerometerTest.zip

[vnen]

Well, it's not "from the editor" that is a problem. The thing is that accelerometer is not implemented for Windows desktop platform. If you export to Windows desktop instead of UWP, accelerometer will return nothing as well.

[ZodmanPerth]

Seeing as it's implemented in UWP (which is Windows) but not Windows desktop, does this mean this is a relatively simple to get this working on Windows desktop? Or is Windows desktop a different beast altogether and the fix requires it's own analysis and solution?

[vnen]

@ZodmanPerth I don't know how the APIs compare for sensors, but likely it is a very different thing from UWP. Especially since the Windows desktop port must support Windows 7 at least. So it'll need its own solution.

[Anutrix]

It would be nice if windows could "borrow" accelerometer values from a connected Android device for sensor tests.
Something like this maybe https://github.com/priyankark/PhonePi_SampleServer. IIRC Godot supports web-socket now, so most of the code there could be useful.

[ZodmanPerth]

That would be amazing I agree!

I think serious work would need to happen for Godot to support this natively.

However a Godot app on a device with an accelerometer, posting UDP packets to a local server that a Godot app running on another device can listen to sounds completely feasible and achievable right now.

[GeorgeS2019]

can someone either close this OR assign this to milestone 4.0 just like this and this?

[ZodmanPerth]

I'm not sure of the state of this issue. If I understand correctly, @vnen is saying it is too hard to achieve on Windows native, and to use UWP for testing.

I am happy to close this issue and use UWP export for testing, however #30558 shows that UWP export is also not working. This means there is no way to test accelerometer support on Windows.

30558 is marked down as to be fixed in the 4.0 milestone.

Because this issue is unresolved, I think it either needs to be closed as a "will not fix" or left open with "depends on #30558 being resolved".

[akien-mga]

I'd tend towards closing as "won't fix" for now, as indeed implementing accelerometer support on native Windows does not seem trivial.

It might change in the future, especially if/when we'd decide to take full advantage of UWP for the Windows platform, but there's a lot of work before this can happen, and it's also far from sure that this would even be wanted -- the future of UWP itself seems quite uncertain, at least it's far behind what Microsoft likely envisioned for it in terms of adoption.

[ZodmanPerth]

I support the decision of "won't fix".

As for the future of UWP being uncertain, I disagree. As a UWP developer who's company partners with Microsoft in my day job, I haven't encountered anything to suggest the UWP platform has an uncertain future. I wish Microsoft had clearer messages around the future of the platform to prevent this kind of inference out here in the wild.

[GeorgeS2019]

@ZodmanPerth and @aurodev This is a chicken and egg situation. Many anticipate that there is no interest from Microsoft community on UWP. Microsoft is not in our views pushing the UWP agenda sufficiently. The expertise to understand UWP potential is lacking.

However, based on how Microsoft is driving the next generation hardware for mobility workers (e.g. Surface Pro X, Windows 10X and as u rightly pointed out the Xbox), UWP has many advantages and roles within the up coming .NET5 vision.

Please stay with more feedback and the godot management team's highly agile style approach will lead to right path forwards.

[ZodmanPerth]

I hope so. The game I'm working on is a touch-only interface targeting UWP and Android devices that also contain an accelerometer. There are so many Surface and 3rd party devices in that market that will miss out if Godot doesn't support UWP.