Has anyone managed to get this working? I’m not a programmer and it seems you need a programmer to get this working. I’m a sound designer on a project and my programmers don’t seem to understand the gravity of the fact that I can’t insert my FMOD events into Unity. I understand there is a workaround (aptly) called FMODUnity by Squaretangle but yet again it seems one must have programming experience to use this. Any ideas?
- grammo106 asked 7 years ago
Not only do you need a programmer, you actually need a fairly competent hacker to get this to work properly.
Since I’m on the free version, I got a license error any time I tried to use the SquareTangle DLL, so that wasn’t an option for me. Interestingly enough, Unity does not complain if you go straight to a native DLL. It only complains if you try to reference a C# plugin. shrug
Anyway, if you look at the SquareTangle stuff, you’ll see that all they’ve done is compile the FMOD-provided C# files into a .NET DLL. Also, the versions they’re using are not fully up-to-date. So, if you want the latest and greatest, you can go the route of compiling your own version of that DLL with the latest files.
Or, you can do what we did, and use FMOD’s c# interface natively.
First, you have to get the latest version of FMOD and place it into the Plugins directory. Next, rename fmodex.dll to fmode2.dll. Then, open up fmod_event.dll and fmod_event_net.dll in a hex editor and find any references to fmodex.dll and rename them to fmode2.dll.
Copy FMOD’s C# files into your Unity project’s resources directory. In all of fmod’s c# files (fmod.cs, etc.) change them to point at Plugins/fmodex instead of just fmodex.
When you make a final build, you’ll have to copy the DLLs by hand out of the data directory into a new Plugins/ directory parallel to the executable. There’s some way of automating this, but it’s poorly-documented, and, since we’re dropping Unity as soon as we finish our current project, I am uninspired to figure this out.
Anyway, then, you need to create a new static class SoundSystem (or something like that) and do all of your normal FMOD initialization there.
Just like in any game, you’ll have to get some mechanism for hooking up Events to things, but once that’s been set up once, you shouldn’t need any programmer support from there.
The only thing that I couldn’t get to work is profiling, but I think that’s because of some incompatibility with Unity’s version of FMOD. Maybe it’s using the same port; I haven’t experimented with it to figure it out.
Easy? No. Took me two full days just to figure out as much as I’ve written down here. And, of course, because you’re using native DLLs, you’ve lost the ability to do web deployment.
Oh, and all of this is assuming Windows. I don’t have or develop on a Mac, so, while I have heard anecdotally that this procedure can be modified to work on the Mac, I cannot attest to its functionality nor provide instruction.
If you don’t do things Unity’s way, then they make it very difficult for you.
Thanks a lot. I found some example scripts from someone who has been using FMOD in Unity on this Assembla blog. You should check it out. The scripts didn’t work for me but, as I said, I’m not exactly a programmer so couldn’t really work out what was wrong.
When you say put FMOD in the Plugins, what file do you mean. I’m assuming you don’t mean the .exe file. Also when you say all of FMODs .cs files do you mean the api ones, the fmoddesignerapi ones or both?
Sorry, I meant the DLL files. You’ll need fmodex.dll (renamed to fmode2.dll), fmod_event.dll (hacked), and, if you’re using the Audition feature, you’ll need fmod_event_net.dll (also hacked).
As for the .cs files, you’ll need the fmod.cs, fmod_dsp.cs, fmod_errors.cs, and fmod_memoryinfo.cs files from the api directory, as well as fmod_event.cs (and, optionally, fmod_event_net.cs) from the fmoddesignerapi directory. Do [i:2ak38nv7]not[/i:2ak38nv7] include fmodp.cs.
We’ve got it working sufficiently for our needs right now, but as I said, Unity is going away as fast as humanly possible once we’ve finished this project (which is coming up soon).
Ok cool, that’s what I thought. As for running the C# interface natively, how do you do this? Do you attach these scripts to an empty object? Once you have done that is it straightforward getting events into Unity?
I know what you mean about Unity, I wish I could drop it too but unfortunately my programmers swear by it.
It’s not as simple as just attaching scripts to an object, unfortunately.
Once you have done all of the set up steps that I described, the end result is that gives you access to the FMOD API from within Unity. That means that you (or, more likely, one of your programmers :)) would need to write some code to initialize FMOD’s EventSystem, update it regularly (probably on your FixedUpdate), shut it down when the app stops, pass parameters to your Events, etc.
Most of that is a one-time programming cost. In our case, I created a static class SoundSystem, which has Init(), Update(), and Shutdown() functions, along with PlayEvent(), SetListener(), and a few others. From there, I call the Init, Update, and Shutdown functions in a single location, call SetListener() at the player’s location, and do PlayEvent()s wherever I need them. That’s all stuff that, if you’re not comfortable programming in C#, you’ll need a programmer to set up.
The rest, though, is really project-specific, so I can’t give very good guidance. In our case, I’ve been working closely with the sound designer to figure out where sounds need to be hooked up, and put in PlayEvent() calls by hand. If your world is very laid-out, you (or your programmers) could create a MonoBehaviour which plays an Event in the world. Again, that’s a one-time programming cost, because once the behavior is written, you can add it wherever you want.
You ask whether it’s straightforward; I can’t answer that, because once all of this work is done, it’s only as straightforward as you’ve made it. All of the work that I described before is just to get you to the [i:2zhxd4vc]starting[/i:2zhxd4vc] point that you would be at if you were using a different engine. My experience has been that, once you get some of the initial setup out of the way, the process of getting Events into the game is usually straightforward.
[quote:1lctrcxt]First, you have to get the latest version of FMOD and place it into the Plugins directory. Next, rename fmodex.dll to fmode2.dll. Then, open up fmod_event.dll and fmod_event_net.dll in a hex editor and find any references to fmodex.dll and rename them to fmode2.dll.[/quote:1lctrcxt]
Glad to see people using those "hacks" we helped develop. You actually don´t have to place the native DLLs in the plugins directory just the managed wrapper. I like the project root, before the assets directory, a lot more as it´s the default location for dll lookup. When built, the dll should be copied to the same folder as the executable. If you place it in the plugins folder it might be copied automatically, dunno.
Unity3D 3.0 won´t need the hex hacking as they renamed their fmod dll and it won´t conflict anymore.
[quote:1lctrcxt]Oh, and all of this is assuming Windows. I don’t have or develop on a Mac, so, while I have heard anecdotally that this procedure can be modified to work on the Mac, I cannot attest to its functionality nor provide instruction.[/quote:1lctrcxt]
Mac is easier as you don´t have to hack anything.
Recompile the wrapper pointing to the dylibs and drop it at the plugins folder. (you can´t point to both dlls and dylibs @ the same time as it´s defined at compile time).
Place the Dylibs in the same folder your "game.app" is. I haven´t found any other solution for the dylibs placement besides that.
Here´s my fmod.cs target defines:
[code:1lctrcxt]public class VERSION
public const int number = 0x00043200;
#if DEBUG public const string dll = "fmodexL.dll"; #elif MAC public const string dll = "libfmodex.dylib"; #else public const string dll = "fmode2.dll"; #endif }[/code:1lctrcxt]
[quote:1lctrcxt]Most of that is a one-time programming cost. In our case, I created a static class SoundSystem, which has Init(), Update(), and Shutdown() functions, along with PlayEvent(), SetListener(), and a few others.[/quote:1lctrcxt]
Mostly the same here. We wrapped the core initialization in one component.
We mimicked Unity´s AudioSouce with a component that wraps a FMod Event and uses some statics like "play@object", "play@position" and so on. This component updates the position, heading and everything the event needs. It also has many accessors for parameters, properties and whatsoever. Most fmod´s functionality is exposed to our C# code that way.
We had some problems with crashes, but they were mostly NPEs being passed to the native dll. 😳
- JoseCastro answered 7 years ago
As far as I know the it should still work, I beleive I read somewhere that Unity have renamed their internal fmodex.dll so that now you don’t have to. However I did come across this thread [url=http://forum.unity3d.com/threads/60482-Unity3-breaks-FMOD-Ex-Usage:2u25igmt]Unity3 breaks FMOD Ex Usage[/url:2u25igmt]. The integration is supported by the guys at [url=http://www.squaretangle.com/FMODUnity.html:2u25igmt]SquareTangle[/url:2u25igmt] so you would have to ask them to be sure.
I think that the reason it’s failing in that thread is because of the Profile option – if the existing FMOD integration is already using the port, then the init will fail. I believe that there’s an option to change the port in the AdvancedSettings structure.
Of course, that’s just psychic debugging based on incomplete data.
Yes, System::init will fail if FMOD_INIT_ENABLE_PROFILE is specified and there is already an instance of FMOD running with the profiler enabled. Just call System::init without that flag and it should be fine. I was under the impression that there was an issue with output initialization FMOD_ERR_OUTPUT_INIT which may be a bit tricker. If that is the error, then you might need to try other output modes.
Please login first to submit.