Skip to content

Conversation

@Rene-Damm
Copy link
Contributor

@Rene-Damm Rene-Damm commented Oct 19, 2021

Description

Add a new RacingWheel generic device class.

Checklist

Before review:

  • Changelog entry added.
    • Explains the change in Changed, Fixed, Added sections.
    • For API change contains an example snippet and/or migration example.
    • FogBugz ticket attached, example ([case %number%](https://issuetracker.unity3d.com/issues/...)).
    • FogBugz is marked as "Resolved" with next release version correctly set.
  • Tests added/changed, if applicable.
    • Functional tests Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
    • Performance tests.
    • Integration tests.
  • Docs for new/changed API's.
    • Xmldoc cross references are set correctly.
    • Added explanation how the API works.
    • Usage code examples added.
    • The manual is updated, if needed.

During merge:

  • Commit message for squash-merge is prefixed with one of the list:
    • NEW: ___.
    • FIX: ___.
    • DOCS: ___.
    • CHANGE: ___.
    • RELEASE: 1.1.0-preview.3.

/// Base class for racing wheels.
/// </summary>
[InputControlLayout(stateType = typeof(RacingWheelState), displayName = "Racing Wheel", isGenericTypeOfDevice = true)]
public class RacingWheel : InputDevice
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Biggest question for me is how we want this to relate to Gamepad. I think pretty much any wheel out there has controls (such as the face and shoulder buttons) to allow it to function mostly like a gamepad. But not every API (same GameInput) defines wheels that way.

So, guess the question is how much we want to put in here in the abstract definition.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likely shouldn't be a gamepad, but rather dpad from racing wheel should participate in navigation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering about additional controls, though. Seems most sensible to add them here, too. Don't think the wheel should separately be represented as a gamepad but it should probably have ABXY face buttons and shoulder buttons instead of just the narrow set that's currently on the device.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree any additional face buttons should exist with the race wheel device.

/// </code>
/// </example>
/// </remarks>
public struct RacingWheelState : IInputStateTypeInfo
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We likely don't need state struct, rather only RacingWheel device class, so users can write code against that, as device structs will come with platform specific devices. And HID already has it's own thing anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My experience has been that every time we tried to hide the state struct or do away with this, it just ended up being painful because you had no way to send input to the device without using the tedious APIs that write values through individual controls.

It's like GamepadState. Gamepad has many different variations and possible states but just being able to spawn a gamepad and directly feed it input is quite useful. IMO better to treat all devices the same way there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So let's say PS4/PS5 code will need more state, e.g. it will be like DualShock gamepad vs Gamepad, how would that work?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as for the current DualShock support. I.e. it'd just come up with its own state format.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok but then it's questionable, e.g. you will not able to queue RacingWheelState into device that is racing wheel but implements it's own state format.

/// <summary>
/// Button to shift gears up.
/// </summary>
public ButtonControl gearUp { get; protected set; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any idea how https://www.logitechg.com/en-us/products/driving/driving-force-shifter.941-000119.html is exposed on HID layer? Not sure if gear lever needs more work here or not

Copy link
Contributor Author

@Rene-Damm Rene-Damm Oct 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My assumption is this would use the gear control and not the gearUp/gearDown button controls corresponding to the commonly found levers/buttons on the wheel. But not sure.

Also not sure how it's exposed at the HID layer. My very limited experience so far with Logitech wheels has been that they masquerade as plain XInput devices and have no interesting properties whatsoever as HIDs and need interfacing through the Logitech SDK to get to the advanced stuff. But no clue about the gear shifters.

@ShaunHewitt
Copy link

How will the haptics (Force Feedback) side of things be handled?

Will it be similar to how Gamepad derives from IDualMotorRumble, maybe having IRaceWheelHaptics?

@Rene-Damm
Copy link
Contributor Author

How will the haptics (Force Feedback) side of things be handled?

Will it be similar to how Gamepad derives from IDualMotorRumble, maybe having IRaceWheelHaptics?

Good question. My assumption is that wheel effects will not as readily fit into as simple a box as gamepad rumble. I'm thinking the best way might be to ignore them for now and then take it on as part of the bigger discussion around what to do with haptics. Without some more sophisticated API in place, trying to cast wheel haptics into some IDualMotorRumble style interface will probably lead to some pretty poor result, I'd think.

@ShaunHewitt
Copy link

ShaunHewitt commented Oct 21, 2021

Without some more sophisticated API in place, trying to cast wheel haptics into some IDualMotorRumble style interface will probably lead to some pretty poor result, I'd think.

Agreed. IDualMotorRumble isn't doing too well for controllers with more than 2 motors atm.

@Rene-Damm
Copy link
Contributor Author

Probably makes sense to close this one.

@unity-cla-assistant
Copy link

unity-cla-assistant commented Jun 28, 2022

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


Rene Damm seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You have signed the CLA already but the status is still pending? Let us recheck it.

@jfreire-unity jfreire-unity added the waiting-for-review The issue is scheduled to be reviewed by the Unity maintainers label Mar 3, 2023
@ekcoh
Copy link
Collaborator

ekcoh commented Oct 21, 2025

If work would be resumed on this PR it needs to updated with latest changes from develop to not cause CI issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

waiting-for-review The issue is scheduled to be reviewed by the Unity maintainers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants