Add support for the accelerometer sensor to Input.get_accelerometer() for Windows Desktop export

[ZodmanPerth]

Describe the project you are working on:
A game whose core design requires both touch screen input and the earth's gravity vector (via the accelerometer sensor on the device). The game will not run on devices that does not provide support for both touch input and the accelerometer sensor.
The game's target platforms are Android and Windows.

Describe the problem or limitation you are having in your project:
Firstly, the Android export is working fine and is not an issue. The issue is Windows does currently not have any working export that supports both touch input and the accelerometer (specifically the gravity vector).

In earlier releases of Godot 3 I was successfully using the UWP Export to run my game on the Windows platform with support for both touch and the accelerometer. However in more recent versions of Godot 3 the UWP export has stopped working.

Reference: gototengine/godot issue #30558 - Does UWP export works?

In community conversations it has been stated that due to current issues with the way the UWP technology is evolving it is unlikely that the UWP export will be fixed. This only leaves Windows Desktop as a valid export target for the Windows platform. While touch input currently works correctly with Windows Desktop export, this export does not support the accelerometer on devices that contain such a sensor. In other words Godot now has a regression issue with the Input.get_accelerometer() GDScript feature on the Windows platform.

In other community conversations it has been questioned why Windows Desktop should support the accelerometer sensor.
The Surface line (Surface Hybrid and Surface Hub) has created a market of devices that run Windows Desktop with touch and accelerometer sensors. Hybrid devices from multiple manufacturers compete in this space. An evolving market such as this is ripe for establishing games that support touch and accelerometer sensors. This is the driving reason for the requirements of the game design in the first place.

Note this proposal was originally raised as gototengine/godot issue #41303 - Input.get_gravity() and Input.get_accelerometer() are not supported on Windows Desktop export, however @Calinou recommended this proposal be created to have the problem addressed instead.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
This would be an enhancement to the existing Input.get_accelerometer() feature on the Windows Desktop export. The export would need to add code to check if the accelerometer sensor was present on the device, and wire the sensor up to the existing Input.get_accelerometer() function in Godot (GDScript). If the accelerometer sensor is not present on the device, calls to Input.get_accelerometer() should return the zero vector (as it currently does).

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
The Windows Desktop Export would be enhanced to search for the accelerometer sensor and marshal data from the sensor through calls to the existing Input.get_accelerometer() feature in Godot (GDScript).

(Perhaps code from the UWP export can be utilised to provide this feature for the Windows Desktop export?)

If this enhancement will not be used often, can it be worked around with a few lines of script?:
This issue cannot be worked around. The Windows Desktop Export needs to be modified to ensure the Windows Platform supports devices with touch input and an accelerometer sensor.

Is there a reason why this should be core and not an add-on in the asset library?:
Implementing this proposal restores the regressed Input.get_accelerometer() feature on the Windows Platform. This is already a core feature in Godot which has become unavailable on the Windows Platform due to the circumstances described above.

[Xrayez]

In earlier releases of Godot 3 I was successfully using the UWP Export to run my game on the Windows platform with support for both touch and the accelerometer. However in more recent versions of Godot 3 the UWP export has stopped working.

In other words Godot now has a regression issue with the Input.get_accelerometer() GDScript feature on the Windows platform.

Note this proposal was originally raised as gototengine/godot issue #41303 - Input.get_gravity() and Input.get_accelerometer() are not supported on Windows Desktop export, however Calinou recommended this proposal be created to have the problem addressed instead.

Yeah, when you say "regression", I expect this feature to be working in the previous versions of Godot, but I'd be careful using this word for something which wasn't supported in the first place (Windows Desktop), else it's a bug indeed, yet the original report godotengine/godot#41303 sounded like it wasn't a regression. Perhaps you imply a regression for UWP here? But it wouldn't make sense since UWP export doesn't work in the first place, as you mentioned. Sorry for nitpicking. Anyways, I'm afraid not everyone in the Godot community has such a device to test this unfortunately...

godotengine/godot#41303 (comment): I think the term "usually" got downgraded with the creation of the Surface line, and subsequent hybrids. That's now a mature model that should be considered.

I know that it may not meet your expectations, but I believe those kind of devices (specifically with Windows installed) are still quite rare to see on people's hands nowadays (maybe in some countries, but certainly not where I live). I think this is one of the reasons why you were suggested to create a proposal anyway, because Godot tries to cater most common community needs first and foremost, unless a contributor with enough incentive is willing to work on something like this of course.

Note that I'm not against the proposal at all and the use cases are quite valid, I'm just trying to setup correct expectations and strive to eliminate any confusion.

Perhaps there's a way to distinguish between desktop/mobile/laptop Windows devices via feature tags, but not sure if tags would be needed in the first place.

Linking Sensor API which could be used to implement this feature in Windows Desktop I think.

[ZodmanPerth]

Sorry for the confusion. It's been a long running issue which has taken a few turns along the way. I will try to clarify.

Yeah, when you say "regression", I expect this feature to be working in the previous versions of Godot...

The original issue was not the #41303 issue you focused on, but #30558. Support for the accelerometer sensor was working on UWP export in Godot 3 previously, however the entire UWP export (where it was supported) no longer works.

The UWP export was the only export on Windows where both touch input and the accelerometer sensor were supported.

It was suggested in #30558 that I use the Windows Desktop export instead which I am happy to do. However I discovered the Windows Desktop export only supports touch input, not the accelerometer sensor. Both features are required in my game design.

There is now no longer any Godot export on Windows that supports both touch input and the accelerometer sensor, whereas there used to be. This is why I use the word "regression"; a core feature that was previously available for Windows is now no longer available.

I realise we usually only use the word "regression" in terms of code bases, and that different exports can be thought of as different code bases. I am using this word in the context of the Windows platform, not the different export code bases. I do this to highlight the seriousness of the issue.

Note that I'm not against the proposal at all and the use cases are quite valid, I'm just trying to setup correct expectations and strive to eliminate any confusion.

I hear what you are saying.

The difficulty here is that the framework for Godot to determine if proposals are worth pursuing appears to use the size of the community being affected as the main tool for measuring if the proposal should move ahead. In order to attract core developers to work on this problem, they need to see past this normal way of evaluation and see a different bigger picture.

My game is currently unable to target the Windows platform, yet it used to be able to. This means I can no longer reach many potential consumers. From an economic standpoint this is not a good story for anyone:

• As an engine, Godot needs to show stability in the platforms it targets to attract developers. One of the reasons I chose Godot for my game is because I could create a Windows version because it supports touch and the accelerometer. That support has now changed, and I'm left wondering if choosing Godot was the right decision.
• For Microsoft, with a vested interest in developing a new market for hybrid devices, they need success stories to attract people to develop for the market. I strongly believe there are untapped opportunities in this market, and I want to showcase some of those that I see. One of the reasons I began my project is to specifically highlight the opportunities within this market. My concern is that without enough successful software in this market, the market will be discontinued.

I know that it may not meet your expectations, but I believe those kind of devices (specifically with Windows installed) are still quite rare to see on people's hands nowadays ...

This is always the case with emerging technologies. It is extremely difficult to create something new. However Godot was able to support this market at one point, and now it doesn't. I hope people realise what an important issue this is.

My hope is that this proposal isn't too much work to implement. I hope the way the UWP export supports the accelerometer sensor can be lifted and placed into the Windows Desktop export. I realise that there may be technical difficulties with this approach; we won't know until someone actually investigates.

Linking Sensor API which could be used to implement this feature in Windows Desktop I think.

That looks promising.

Prior to using Godot I was developing my game on own engine using C#. I was targeting this Accelerometer API, however this is provided by the windows.devices.sensors namespace which is part of the UWP platform. It is unlikely that is able to be used in the Windows Desktop export, but things may have changed.

Perhaps there's a way to distinguish between desktop/mobile/laptop Windows devices via feature tags, but not sure if tags would be needed in the first place.

I don't believe there is. I think Godot should only be targeting Windows 10 as the platform, used by millions of devices, with a mixture of touch and accelerometer capabilities. I believe the Godot export would need to dynamically check for these capabilities at runtime..

Conclusion

I'm trying to create something unique that highlights the best of Microsoft and Godot. Developers always hope their games are successful just for themselves; I'm hoping to achieve create something unique that brings success not just to my game but to Godot and the hybrid device market as well.

I've invested many years on my project and plan to continue. As a Windows developer I want to give something back to the platform that supports my career. It pains me to feel that opportunity could be taken by something as "simple" as hooking up a sensor.

(I know this isn't "simple", but in the context of the story of my journey so far I struggle to find an appropriate word for it).

I love the Godot engine and I love our community. I really appreciate the people who contribute their time and effort to it. I actively advocate and support our community, and devote all the time I have available to create using Godot. I am deeply invested. I hope this proposal is seriously considered, not dismissed as a marginal requirement by a transient user of the engine.

[akien-mga]

Can we stay on topic of adding support for accelerometer data on Windows Desktop for devices that support it?

[ZodmanPerth]

If there's anything I can do to help develop or test this let me know. I don't have the skill to do it on my own, but perhaps I can pair with a core developer to help make it happen.