0
0

Hello Brett, in my programs, C++ Interface is better than C interface with my Borland C++builder6 compiler.
How can I do to export the fmodex.dll symbols for the C++Builder6 compiler.
I hope really that it’s possible.
Even if it’s complicated, I’m ready to do this.

Thanks for all!!!

  • You must to post comments
0
0

With what version of Visual C++ is the fmodex_vc.lib compiled? Maybe I’m missing it, but I don’t see that key piece of information in the documentation.

  • You must to post comments
0
0

[quote="brett":ajth19wd]you cant use C++ interface on the non MS compilers.
The C++ symbols in the DLL for C++ are mangled in a way that cannot be compatible, becausee there is no standard like there is with simple C stdcall name mangling.
To fix it we would have to change our API to make the C++ interface a wrapper of the C interface, with extra call overhead and I don’t want to do this. The other compilers just aren’t popular enough compared to msvc/.net. You can still use the C interface though.[/quote:ajth19wd]Hello Brett, it’s a pity, but I’m very happy for Fmod Ex.
Thanks for all!!!

  • You must to post comments
0
0

Hi everybody,

I think there is a solution to this problem. Since FmodEx is not object oriented it is object based code (no object creation by the user and no inheritance). This is good, because someone can write a wrapper to this. You just need to write the same class wrapper as it exits for C# in C++ and the it’s compilable with every C++ compiler even with visual C++ too ๐Ÿ˜‰ The basic principle behind the c# interface is to encapsulate the pointer to the c-structs in new C++ objects. With this technique you can get the exactly the same interface as it is with Visual C++.

best regards
Sl@jaR

  • You must to post comments
0
0

What the heck is the point of libfmodex.a then? Obviously I’m missing something here

  • You must to post comments
0
0

[quote="Electron":gvsomc6w]
Or you could provide a version of the dll compiled with mingw. Considering that fmod.dll is under 300 kb, this would hardly increase download size.
[/quote:gvsomc6w]
[quote="brett":gvsomc6w]there are about 4 or 5 compilers out there, mingw isnt the only one so it would be a real pain for us to maintain and support 8-10 dlls[/quote:gvsomc6w]

We could do that for you :)
For example i use FLTK to start a new cross-platform music player using F-Ex and i would love to see a GCC compiled version on X11, Win32 and OSX

  • You must to post comments
0
0

[quote="Electron":1zdw97bm]What the heck is the point of libfmodex.a then? Obviously I’m missing something here[/quote:1zdw97bm]It lets you use FMod Ex?

  • You must to post comments
0
0

So, if i can’t use the C++ interface from the .chm’s tutorial i have to use the C interface.
Do you have a tutorial for me like the one in the .chm?
Or just an example of initalising the System and playing a Soundfile?

[edit]
Well ok, no i found out that the functions of the C interface have the same name like the C++ interface methods have. So if you have an object of FMOD::System in C++ you need a FMOD_SYSTEM in C.
Then the code for the tutorials first example look like:
[code:22zhdy5h]
/* deklaration */
FMOD_RESULT result;
FMOD_SYSTEM *system;

/* create the system /
result = FMOD_System_Create(&system);
if (result != FMOD_OK)
{ /
check for an error */
printf("FMOD error! (%d) %s\n", result, FMOD_ErrorString(result));
exit(-1);
}

/* init the system (fourth parameter at first place to pass the system!) /
result = FMOD_System_Init(system, 100, FMOD_INIT_NORMAL, 0);
if (result != FMOD_OK)
{ /
check for an error */
printf("FMOD error! (%d) %s\n", result, FMOD_ErrorString(result));
exit(-1);
}
[/code:22zhdy5h]
Right? So i wonder if the rest differs much more then this…

At least, I just always get this:
[quote:22zhdy5h]`FMOD_ErrorString’ undeclared[/quote:22zhdy5h]
And I can’t find my mistake, where is this function deklared or defined?

  • You must to post comments
0
0

I apolgize for my stupidity. I did not realize there still was a C api, there is virtually no mention of it in fmodex.chm. Imho, it would be a good idea for the Platform Specific Issues section of the chm to mention, in the section discussing which library to use, that the C++ API is not accessible from mingw or Borland and that there still is a C API containing full functionality. Admittedly, I would have known that a C api still exists if I had read the Introduction page of the chm, so that is clearly my fault. The fact that mingw and Borland users cannot access the C++ api is not mentioned anywhere in the doc that I could find (please let me know if I’m missing I’m being unobservant again), and is not in the least obvious. Since a .a library was provided, I assumed that there was full support for mingw. If you do not wish to provide full mingw support it would be nice if the fact were better documented.

[quote:3jam86d2]To fix it we would have to change our API to make the C++ interface a wrapper of the C interface, with extra call overhead and I don’t want to do this. [/quote:3jam86d2]
Or you could provide a version of the dll compiled with mingw. Considering that fmod.dll is under 300 kb, this would hardly increase download size.

Anyway, thanks for providing fmod. I aplogize for my tone. Discovering that I can’t link the project I ported from fmod 3 to fmodex c++ api is just kinda frustrating.

  • You must to post comments
0
0

that is a helper function, it is in fmod_errors.h

  • You must to post comments
0
0

[quote="brett":il3d2urc]To fix it we would have to change our API to make the C++ interface a wrapper of the C interface, with extra call overhead and I don’t want to do this.[/quote:il3d2urc]

Umm… I just realized this, but why would there be any more overhead than there is now? I’m guessing based on the way you’re talking about it that the C interface is currently a wrapper for the C++ interface–changing it around so that the C interface is the native one and the C++ one wraps it wouldn’t add any extra overhead. If it’s currently the other way around (C++ wraps C), then fixing the issue is child’s play–just move the wrapper classes into fmod.hpp.

I mean, I can’t imagine that you duplicated (i.e. copied & pasted) every function in the C API that’s implemented in the C++ API–that would be a maintenence nightmare!

Of course, the issue doesn’t affect me personally because I use Visual C++ (and besides the fact, I’m using the C API because I’m more comfortable with it); I’m just saying. Of course, if C++ name mangling was standardized, nobody would have this problem in the first place…

[b:il3d2urc]Edit:[/b:il3d2urc] I just read somewhere that Visual C++ 2005 changes the name mangling rules compared to VC6/7. Yet another reason to make the C++ interface universal–if you can’t even support all versions of the [i:il3d2urc]same[/i:il3d2urc] compiler, something should be changed.

  • You must to post comments
0
0

[quote="brett":28jejx3v]You can still use the C interface though.[/quote:28jejx3v]

Sorry to be such a newb but where can i find information on how to use the c interface?

Thanks a bunch!

  • You must to post comments
0
0

[quote="brett":2bj9mrxu]you cant use C++ interface on the non MS compilers.
The C++ symbols in the DLL for C++ are mangled in a way that cannot be compatible, becausee there is no standard like there is with simple C stdcall name mangling.[/quote:2bj9mrxu]

Hello, Borland C++ Builder 2006 is about to be released, so i’m wondering if this C++ interface will be compatible with it, even “one day” (i mean… the interface of the DLL of course).

Thanks, thats a great work anyway.

  • You must to post comments
0
0

[quote:3tqae0m0]Sorry to be such a newb but where can i find information on how to use the c interface?[/quote:3tqae0m0]

Nobody can inform you more about Fmod than FMOD itself.
Just open your "fmod.h" file and note down all important functions , typedefs with arguments they take and the values they return .
Read the documentation (c++ only) and make out the slight differences
which appear when using c and c++ exposures

  • You must to post comments
0
0

Ah, okay. Yeah, I guess it would be a pain to change the “native” interface at this stage–not to mention it would break binary compatibility. I was actually under the impression that the exported C++ classes simply called the C API internally (since FMOD 3 was all C functions); I didn’t realize that the actual FMOD code was in the classes.

This is the primary reason C is still in widespread use–platform independence. It’s why so many cross-platform libraries are written in C (or at the very least, export C-compatible APIs). Since C++ name mangling is not standardized–and there doesn’t appear to be any intention to do so–C++ is unsuitable for cross-platform APIs.

None of this means I hold anything against FMOD, of course–more of a grudge against C++. Just keep this post in mind for the next major rewrite of FMOD (assuming there will be another one).

  • You must to post comments
0
0

[quote="tictactouc":126fdage]Hello Brett, in my programs, C++ Interface is better than C interface with my Borland C++builder6 compiler.
How can I do to export the fmodex.dll symbols for the C++Builder6 compiler.
I hope really that it’s possible.
Even if it’s complicated, I’m ready to do this.
Thanks for all!!![/quote:126fdage]

way 1, reliable:
create C++ wrapper with inline functions, like:

[code:126fdage]
namespace FMOD
{
class System
{
inline FMOD_RESULT playSound(
FMOD_CHANNELINDEX channelid,
FMOD::Sound * sound,
bool paused,
FMOD::Channel ** channel)
{
FMOD_System_PlaySound(
reinterpret_cast<FMOD_SYSTEM *>(this),
channelid,
reinterpret_cast<FMOD_SOUND *>(sound),
static_cast<FMOD_BOOL>(paused),
reinterpret_cast<FMOD_CHANNEL **>(channel));
}
};
);

}
[/code:126fdage]

way 2:
in .def file you can rename functions from MSVC mangling
?playSound@System@FMOD@@QAG?AW4FMOD_RESULT@@W4FMOD_CHANNELINDEX@@PAVSound@2@_NPAPAVChannel@2@@Z
to GCC magling.
I’m not expert in .DEF files, so you need MSDN/google for documentation :)
and try read c:\MinGW\info\ about GCC-tools dlltools.exe, reimp.exe

calling convention ( F_API – _stdcall ) is the same in MinGW and MSVC, so renaming in .DEF file should be enough

  • You must to post comments
0
0

[quote="rolkA":1n07k8a4][quote="brett":1n07k8a4]you cant use C++ interface on the non MS compilers.
The C++ symbols in the DLL for C++ are mangled in a way that cannot be compatible, becausee there is no standard like there is with simple C stdcall name mangling.[/quote:1n07k8a4]

Hello, Borland C++ Builder 2006 is about to be released, so i’m wondering if this C++ interface will be compatible with it, even “one day” (i mean… the interface of the DLL of course).

Thanks, thats a great work anyway.[/quote:1n07k8a4]

So i guess the answer is “no” ? thats a pity ๐Ÿ˜ฅ

  • You must to post comments
0
0

[quote="Winnie":3780g4lo]way 2:
in .def file you can rename functions from MSVC mangling
?playSound@System@FMOD@@QAG?AW4FMOD_RESULT@@W4FMOD_CHANNELINDEX@@PAVSound@2@_NPAPAVChannel@2@@Z
to GCC magling.
I’m not expert in .DEF files, so you need MSDN/google for documentation :)
and try read c:\MinGW\info\ about GCC-tools dlltools.exe, reimp.exe

calling convention ( F_API – _stdcall ) is the same in MinGW and MSVC, so renaming in .DEF file should be enough[/quote:3780g4lo]
It’s not just the name mangling that’s different between GCC and MSVC++. They use a different Application Binary Interface (ABI) structure, which basically means that how the object is represented in memory is different. Worse, some parts of the MSVC++ ABI are patented, so they will never be implemented in GCC.

See [url=http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Interoperation.html#Interoperation:3780g4lo]the GCC manual[/url:3780g4lo] for more information.

It’s probably just easier to wrap up the FMOD C interfaces in your own objects, the same way as you (probably) do with OpenGL and SDL.[/url]

  • You must to post comments
0
0

Hmm i did try by modifying fmod.hpp

Changed all
[code:dq7ghpqd]FMOD_RESULT F_API[/code:dq7ghpqd]
into
[code:dq7ghpqd]virtual FMOD_RESULT[/code:dq7ghpqd]

But any function call after the System_Create() fails ๐Ÿ˜ฅ

  • You must to post comments
0
0

Hi,
I use DevCpp and C++ QT librairies for the GUI.
I want to play short song when I click on a pushbutton, but I don’t know where to put the fmod code. Should I put it within a member function or within the ‘main’ function? ๐Ÿ˜•

  • You must to post comments
0
0

[quote="brett":4ubx6jb6]why did you do that?[/quote:4ubx6jb6]
You are using C++ classes in the dll and I know you can’t mix C++ classes between vendors due to the different name mangling and object creation schemes that prevent this.

So instead i was trying to explicitly call them based on the following resources i’ve read.

http://www.codeguru.com/Cpp/W-P/dll/imp … e.php/c123
http://www2.linuxjournal.com/article/3687

I’ve made an example by building database wrappers.
The DLL’s are compiled using MSVC 6 and i’ve compiled 2 executables (1 MSVC and 1 BCB 4)
The class inside the dll worked in both cases thanks the to the [b:4ubx6jb6]virtual[/b:4ubx6jb6] keyword to allow derived classes.

Shure i know you could override virtual functions but it was the only way for me to build a C++ Classes workspace with dynamic dll’s
This solution provided me a huge flexibility in my musicplayer application to offer several database engines and not having the overhead to be bound to have them all installed and loaded. Afterall you’re only using one database anyway.

  • You must to post comments
Showing 20 results
Your Answer

Please first to submit.