I’ve got a very strange situation with a Native plugin I’m working on. I’ve seen similar (but not exact) posts, and am hoping someone might have some info on this.
I’m writing a native plugin that talks to the Logitech Gaming SDK so that I can bind to a specific input device without worrying about windows’ internal ID’s. I’ve got the functionality working, and in a dedicated WPF test application, everything works flawlessly.
When I go to Unity, things start to get weird. First off, in a build, everything works perfectly. In the editor is where things get tricky.
First, the Logitech SDK uses DirectInput, so I get an uncatchable unhandled exception if my current window is not the calling window for the controller bind. I’ve worked around this by making a button in the game window to initialize and destroy my plugin functionality (basically, allocating my controller information and releasing the controller). The challenge is that we can’t use this in our final product. We can work around it by initializing the plugin on demand, and make sure the user has clicked something in the game window before trying to use it. It’s not ideal (we’d like the controller to bind on load and unbind on shutdown), but it works.
It seems the editor doesn’t put the focus on the game window anymore when you click the play button. That’s the cause of that issue–as I said, it’s minor.
What’s not minor is that the editor crashes when I click the stop button. I suspect that even though I’ve shutdown all of the resources within my native dll, the editor is holding onto something.
Interestingly enough, this is the exact reason I started building my own native DLL in the first place. The Logitech Gaming SDK that’s on the asset store does the exact same thing when you set properties on the device. So, it’s not just me. And this all seems new to Unity 5 (it was working flawlessly in Unity 4).
If you want to see this behavior, you can load the default Logitech Gaming Software asset in a blank project, attach the sample steering wheel code to a blank gameobject, and run the scene. If you hit PgUp while running the scene, everything will work, until you hit stop–at which point Unity will crash.
I suspect that some process is binding to DirectInput and holding onto some memory in the scene somewhere, but there’s no crash logs or anything along those lines to find out. Moreover, if I try to debug the process, it tells me that there’s an Access Violation (0xC00000005) in mono.dll, but I can’t get any further, because obviously I don’t have the source files with the mono exceptions to connect to. This could be related to the core functionality of the Logitech SDK, but as I mentioned earlier, it works flawlessly in a WPF project using C#, so I suspect the issue is somewhere in Mono’s handling of the DllImport.
What I’m hoping to find is if I’m doing something wrong in my Native DLL, or better yet if there’s unsupported functionality of P/Invoke that I need to be aware of and work around, as the documentation’s a little bit lacking.
What I’ve found so far:
In my WPF test app, I call:
[DllImport( "G27Plugin.dll", CallingConvention = CallingConvention.Cdecl )]
private static extern bool UpdateG27 ();
In my Unity code, I call:
[DllImport( "G27Plugin" )]
private static extern bool UpdateG27 ();
As I said, I’ve got everything working, and in a build, it’s just fine. This is only an in-editor problem. But, it’s kind of a showstopper if we’re guaranteed to crash the editor every time we try to test something (and input is such a core functionality we can’t just test it from time to time).
Will check out.