FMOD API

What do the C++ headers look like? I don't have FMOD, but with more info about the header I could probably tell you what's going on.

You might be right about it being written or C, but it might be the other way around. They may have made a C-like C++ implementation to make it easier to put a C wrapper around their C++ code.

The typedef lets them avoid typing "struct FMOD_SYSTEM" everywhere. In C you cannot leave off struct in the type name unless you do a typedef. Without struct FMOD_SYSTEM defined, it's an incomplete type. Anything without the definition of what's inside the struct can only refer to it with a pointer. It's the C version of encapsulation.

I've been through adding a C++ library to a C program, and incomplete types are very useful in this situation. The C header may have its functions implemented in a C++ file, and that incomplete C struct could contain a C++ object inside, wherever it is actually defined. Or, they might never define it, and just force cast the pointer to whatever they use internally.

Are you using the official FMOD SDK? The Windows version contains .c and .cpp files for both C and C++ respectively which are both in the same folder for all the individual project files. In the SDK version that I have there is only C code in the .c file and the headers included both have .h extensions.

In the .cpp file both of the headers have .hpp extensions.

I double checked just now to confirm this, for me there is no mixing and matching between either formats. It's either C or C++, not both.

Incidentally, if you are using MingW/GCC you will have to use the C code. The library has a bug that causes what appear to be linker errors if you try to build the C++ version using the aforementioned compiler. That'll really drive you batty since the errors are completely unrelated to the problem.

Thanks for the replies!

I've been through adding a C++ library to a C program, and incomplete types are very useful in this situation. The C header may have its functions implemented in a C++ file, and that incomplete C struct could contain a C++ object inside, wherever it is actually defined. Or, they might never define it, and just force cast the pointer to whatever they use internally.

Yep - that seems to be what they're doing. I can't tell whether they use a C++ object internally or it really is implemented in C. I guess they could have done this for compatibility reasons. They actually define the C++ factory function to call the C function below. Although FMOD_SYSTEM is an incomplete struct type.

inline FMOD_RESULT System_Create(System **system) { return FMOD_System_Create((FMOD_SYSTEM **)system); }

Are you using the official FMOD SDK? The Windows version contains .c and .cpp files for both C and C++ respectively which are both in the same folder for all the individual project files. In the SDK version that I have there is only C code in the .c file and the headers included both have .h extensions.

I have the public SDK, which doesn't include the source code.

Is there any advantage to implementing a library like this using a C API, and then adding non-virtual C++ wrappers? I can't imagine many people want to use the C API, although I could be wrong. Possibly performance?

Thanks!

Although FMOD_SYSTEM is an incomplete struct type.

It's an opaque struct. These can be declared and used as pointers because the size of the struct need not be known at compile time. It's a way of hiding the implementation of the struct. It's a common C idiom. In C++, these are called forward references.

// foo.h
typedef struct foo_s foo_t;
 
foo_t* make_foo( void ); // this is ok
foo_t make_foo2( void ); // this will fail to compile

// foo.c
// implementation is not part of the public API and is hidden from the user.
struct foo_s {
   int bar;
   float baz;
};
 
foo_t* make_foo( void ) {
    foo_t *foo = malloc( sizeof foo_t );
    foo->bar = 10;
    foo->baz = 2.0f;
    return foo;
}

Is there any advantage to implementing a library like this using a C API, and then adding non-virtual C++ wrappers? I can't imagine many people want to use the C API, although I could be wrong. Possibly performance?

The C++ classes in the header

I'm so confused by this. I don't see a single class in the fmod.h file???

I see lots of C++ syntax in the comments but nothing in the actual code.

To my unsophisticated eye it looks like they just used their C++ comments in both the C and C++ headers to save the trouble of generating two sets of reference.

That's what you get for learning both C and C++ side by side. Aside from classes and a few other little details, I can't seem to tell which is which. oh well.

Brett here from FMOD.

FMOD is written in C++ not C! :)

Here is the code we use. The C++ interface is the native interface, and the C header is actually a wrapper for the C++ interface. FMOD_SYSTEM is an opaque type that can be used interchangeably with the FMOD::System type. Its correct that having the C interface allows the DLL to export STDCALL symbols that any language can hook into. This is how we supported mingw/gcc/delphi/visual basic/C# etc.

FMOD_RESULT F_API FMOD_System_CreateSound(FMOD_SYSTEM *system, const char *name_or_data, FMOD_MODE mode, FMOD_CREATESOUNDEXINFO *exinfo, FMOD_SOUND **sound)
{
    FMOD::System *_system = (FMOD::System *)system;

    return _system->createSound(name_or_data, mode, exinfo, (FMOD::Sound **)sound);
}

FMOD_RESULT System::createSound(const char *name_or_data, FMOD_MODE mode, FMOD_CREATESOUNDEXINFO *exinfo, Sound **sound)
{
    FMOD_RESULT result;
    SystemI *systemi;


    result = SystemI::validate(this, &systemi);
    if (result != FMOD_OK)
    {
        return result;
    }
    else
    {
        return systemi->createSound(name_or_data, mode, exinfo, (SoundI **)sound);
    }
}

FMOD_RESULT SystemI::validate(System *system, SystemI **systemi)
{
    FMOD::SystemI *sys = (FMOD::SystemI *)system;
    
    if (!system || !systemi)
    {
        return FMOD_ERR_INVALID_PARAM;
    }


    if (!FMOD::gGlobal->gSystemHead->exists(&sys->mNode))
    {
        return FMOD_ERR_INVALID_HANDLE;
    }
    
    *systemi = sys;


    return FMOD_OK;
}

another trick we do is use reference counted integers for FMOD::Channel/FMOD_CHANNELs. People declare them as FMOD::Channel *, but they're not actually pointers to memory.

This allows us to error check the handle, and reference count it, so if it gets stolen by another channel, it will become invalid and channel functions will start returning FMOD_ERR_CHANNEL_STOLEN errors .. Like above , the ChannelI::validate function takes the base type in (the integer), and gives an implementation object out (FMOD::ChannelI). The validate function dissasembles the handle bitfield and looks up a table to get the correct FMOD::ChannelI object for internal use.

We have had support emails in the past about why our pointers look so strange, so we had to juggle some bits around so it looked more 'pointery'.

cool. You wouldn't happen to be Brett Paterson, CEO, Firelight Technologies, would you?

yes that is I :)

Thanks for clearing this up for us.

on a side note...

When people who make money for the first time off something that uses FMOD, would you expect to be paid upfront, or would it be alright to pay up after the title has made enough money to justify doing so?

For instance,

(i) I decide to publish and charge $1.00.

(ii) I pay Firelight $500.00 for the no-budget, super welfare license.

(iii) I lose money on this one because the only copy that sold was purchased by my mom.

or

Would you be willing to accept payment from welfare budget software only after it's proven to not be a total loss?...

generally we think of fmod as a tool, say like the commercial version of visual studio. You would buy it up front typically.

That being said if you sign for the license up front, we are flexible on payment terms. If after a month its not looking good let us know and we can convert you back to a free license, if it looks like noone is going to buy the product (and you would technically have to make your product free as well).