This looks great, thanks for the contribution! I'd probably say, let's go further and more fully integrate it: making a buttoninterface prefab where you set the path and it emits UnityEvents, etc. Replace callbacks with something more native, which appears to be unityevents in this case.

Does this work in Unity 4.6 as well?

A fully integrated ButtonInterface prefab is a great idea. I was recently reading a debate about UnityEvents vs C# delegate events. As far as performance, C# delegates are a lot faster (~38x) than UnityEvents. However, Unity Events have better UI integration and make it very easy to hook events to actions in the editor. My instinct is to do whatever is faster. Performance does matter in our case and button presses can happen frequently, so I would vote for using C# delegates. Would like to hear from more Unity developers about this design decision.
Debate:http://www.reddit.com/r/Unity3D/comments/35sa5h/unityevent_vs_delegate_event_benchmark_for_those/
Debate:http://www.reddit.com/r/Unity3D/comments/35oekm/delegate_events_vs_unityevent_which_one_is/
Good comment about the differences between the two systems:http://www.reddit.com/r/Unity3D/comments/35oekm/delegate_events_vs_unityevent_which_one_is/cr6j4e0

Yes. It was authored in Unity 4.6.

Jeremy Aker

From: Ryan Pavlik [mailto:notifications@github.com]
Sent: Friday, May 29, 2015 1:09 PM
To: OSVR/OSVR-Unity
Cc: Jeremy Aker
Subject: Re: [OSVR-Unity] UnityEvents for button press and release (#44)

This looks great, thanks for the contribution! I'd probably say, let's go further and more fully integrate it: making a buttoninterface prefab where you set the path and it emits UnityEvents, etc. Replace callbacks with something more native, which appears to be unityevents in this case.

Does this work in Unity 4.6 as well?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/44#issuecomment-106873397.

Performance is important, but it's most important for things that affect rendering (so tracking, basically). How do joystick buttons get into Unity? Are they unityevents, C# delegates, C# events, or something else?

Basically by querying the Input class (http://docs.unity3d.com/Manual/ConventionalGameInput.html), but most games would want a more advanced system, from which there are many to choose from. Some query state, some are event based.

In this example, if we're already registering a function (handleButton) to be called when a button is pressed or released, why invoke another event in handleButton? I suppose the answer is to make it easy to see and assign what actions are hooked to the button press in the editor without looking at code. The last step seems unnecessary to me -- if you're going to invoke OnPress and OnRelease in the callback function to call another function, why not register that last function to receive the initial callback and save the time of going through a middleman?

There could be some advantages that I am missing. I haven't used UnityEvent as it's a relatively new feature (4.6).

Is it something that we could provide a UnityEvent button/analog/etc prefab that people can use if they want it, and just use the regular callbacks if they don't? (basically a "don't pay for what you don't use" addition) Estimated amount of maintenance effort in doing something like that? It looks like most of the code can be shared, so I'd think it would be low.

I guess I don't really know what's "idiomatic" for Unity - I'd rather not have too many ways to do the same thing, since that gets confusing, but I would like to have things "native" for each integration, otherwise it's not much of an integration.

What does Cardboard do? (They are a handy Apache 2.0 licensed reference...)

Cardboard doesn't handle input. And yes, we could definitely add this for people who want to use it. Options are good.

I think either approach would be considered idiomatic in Unity, but I was hoping to hear from Unity developers to see if this is the new, "better" way to do things. UnityEvents are serialized and integrate nicely with the Unity editor. Callbacks are native to C# and apparently perform better. I think for me the question is, which approach is the right one for a given task? UnityEvents were introduced at the same time as the new UI system. To me, UnityEvents are perfect for that -- assigning actions to UI clicks. For handling controller input, I'd use a different approach considering the latency hit. Either way works in a simple example.

Cardboard for Unity doesn't support the magnet trigger?

In the editor or if "TapIsTrigger" is enabled, it queries Input.GetMouseButtonUp(0). On the device, callbacks from native code populate a "VREvent" queue that gets processed every frame, one of which is detecting a magnet trigger (https://github.com/googlesamples/cardboard-unity/blob/master/Cardboard/Scripts/VRDevices/VRDevice.cs#L188).
It ends up triggering an event (https://github.com/googlesamples/cardboard-unity/blob/master/Cardboard/Scripts/Cardboard.cs#L344).

For GUI input, they are using the C# delegate/event pattern:
https://github.com/googlesamples/cardboard-unity/blob/master/Cardboard/Legacy/Scripts/CardboardOnGUI.cs#L31