Hi,
I’ve made a change locally to the fmod.cs bindings in order to solve AOT warnings and potential issues.
I’d like to share them so they can be upstreamed, or can be used to fix upstream.
The core part:
- replace the likes of
get { return nonblockcallback_internal == IntPtr.Zero ? null : (SOUND_NONBLOCK_CALLBACK)Marshal.GetDelegateForFunctionPointer(nonblockcallback_internal, typeof(SOUND_NONBLOCK_CALLBACK)); }
with get { return nonblockcallback_internal == IntPtr.Zero ? null : (SOUND_NONBLOCK_CALLBACK)Marshal.GetDelegateForFunctionPointer<SOUND_NONBLOCK_CALLBACK>(nonblockcallback_internal); }
(using Generics instead of passing Type)
- Using generics version of Marshal.SizeOf() and Marshal.PtrToStructure().
Is there anywhere I can send this, or another way I can help getting this change upstreamed?
EDIT: Ah I see now it says “Use the old syntax (non-generic) to ensure maximum compatibility (especially with Unity) ignoring the warnings”. This can break AOT builds that do not use Unity. Any way to solve this, maybe with two generated cs versions?
Hi,
Thank you for sharing the fix to address the AOT warning!
I have tried to switch the scripting backend to IL2CPP and used the Unity Burst for AOT compilation.
Unfortunately, I was not able to reproduce the warning message you mentioned above, could you please let me know the version number of the Unity and FMOD Unity integration plugin you are using?
Would it be possible to share the logs and elaborate a bit more about how to reproduce the issue?
I was not clear before:
I am not using Unity but a bespoke C# solution with dotnet 8 (Core). This has AOT support, which is not IL2CPP.
AOT has some requirements or warnings around trimming of code.
I see the current c# code is tailored for the Unity users. For the core-aot users, generics need to be employed so trimming does not cause issues.
If you make a new c# console app, add the fmod cs file, enable aot and build it you’ll get the warnings.
Thank you for the detailed information!
I have managed to reproduce the warnings and workaround it with your method, I can clearly see how useful this solution is, and I will pass it on to our development team to look into further.
In the meantime, please feel free to modify the scripts and let me know if you have any further questions.
If it isn’t too much trouble or work, could you export your fixes as a *.patch and upload it here for the rest of us.