0
0

This is a very odd problem. I’m using LoadLibrary and GetProcAddress to dynamically load the FMOD functions (I’m making an FMOD-based game engine DLL, and I don’t want the fmod.dll to be required), but when I try to call an FMOD function from a function pointer, the VC++ debug library gives me an error and tells that I used the wrong calling convention…

I have a structure to hold all my FMOD function pointers, and this is how I’ve defined it:

typedef struct _FMODFUNCTIONS {
signed char (_stdcall* Initialize) (int,int,unsigned int);
signed char (_stdcall* StreamClose) (void*);
void* (_stdcall* StreamOpen) (const char*,unsigned int,int);
signed char (_stdcall* StreamPause) (int,signed char);
int (_stdcall* StreamPlay) (int,void*);
signed char (_stdcall* StreamStop) (void*);
void (_stdcall* Terminate) (void);
} FMODFUNCTIONS;

I imagine if FMOD is usable in VB, then _stdcall must be correct. Yet VC++’s debugger is still telling me I’m using the wrong calling convention at run-time, and my app will crash if compiled in release mode and then run.

I must admit, I had another problem involving FMOD dynamic linking in the past–GetProcAddress returned NULL some of the time, and other times was fine. That problem has mysteriously vanished, but now this one pops up. Could it have anything to do with the weird function numbers in fmod.dll (i.e. “_FSOUND_Init@12”)?]

By the way, the debugger error I get when calling FMOD’s functions from my function pointers is as follows…

[i:271kcyxs]The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.[/i:271kcyxs] And like I said, when gafas.dll is compiled as a release build, my app simply crashes.

  • You must to post comments
Showing 0 results
Your Answer

Please first to submit.