Jump to content
  • Advertisement
Sign in to follow this  
cow_in_the_well

[.net] Acessing "legacy" code from .NET

This topic is 4767 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I have an engine already written in pure unmanaged C++ and it compiles down to a DLL. I would like to use this API from C# with little or no modification to the actual engine source (mainly so I can make an editor using Winforms, but I also plan to use C# to drive the high level game logic). The guys over at Artificial Studios (reality engine) have gone down this road, so it's definately possible :P. I have tried using SWIG (generates PInvoke wrappers), and it works very well...for calls INTO the engine. I have not managed to find a good solution for calls from unmanaged to managed code (for stuff like collision event handlers, etc). I tried this http://www.codeproject.com/csharp/Win32_to_NET.asp but I just get an ESP runtime check failure on return from the C# function - mucking around with the PInvoke calling conventions didn't seem to help :(. In any case, I'm not sure how I could integrate that into the SWIG wrapper generation. From what I can gather, Interop is just for COM interfaces (my engine is NOT COM :)). Am I correct? Hmn, just now I had a read through the wx.NET wrapper. It's rather mind boggling to say the least -_- (due to the fact that it's wrapping so much up, it's a little hard to decipher). It has a SWIG folder in it's source full of swig definitions, but is it actually using it??? The wx-c interface seems quite different to what SWIG generates, and there's some funky perl script for parsing C++ code. Any thoughts/and or tips on this topic? Thanks. PS. On a slightly unrelated note, I managed to get the MSVC debugger to step into my C++ code via the C# PInvoke call by turning on the "Enable Unmanaged Debugging" switch in the project options and it works great. But _WHY_ does this make debugger take > 10 seconds to start executing the program? It's rather frustrating to have to twiddle my thumbs while it sits there doing apparently nothing (no HDD activity or CPU activitiy during the wait) :(.

Share this post


Link to post
Share on other sites
Advertisement
I have done this using P/Invoke, and encountered only one problem: The actual callback function must be __stdcall, as you cannot set the calling convention of a delegate.

C++ Engine.dll:
typedef int (__stdcall *CallbackFunc)(int arg); // Notice: Must always be __stdcall.

__declspec(dllexport) void __cdecl SetCallback(CallbackFuncPtr pCallbackFunc); // __cdecl, or whatever you feel like. Must be same in C# below.

__declspec(dllexport) void __cdecl InvokeCallback(); // __cdecl, or whatever you feel like. Must be same in C# below.

C# Application.exe:
class Foo
{
static int CallbackFunction(int arg)
{
return arg + 1;
}

delegate int CallbackDelegate(int arg);

[DllImport("Engine.dll", CallingConvention = CallingConvention.Cdecl)] // Same as you selected above.
private static extern void SetCallback(CallbackDelegate delegate);

[DllImport("Engine.dll", CallingConvention = CallingConvention.Cdecl)] // Same as you selected above.
private static extern void InvokeCallback();

void Test()
{
CallbackDelegate myDelegate = new CallbackDelegate(CallbackFunction);
SetCallback(myDelegate);
InvokeCallback();
}
}

Share this post


Link to post
Share on other sites
Thanks. I managed to get that working now :).

I think I'm going to have to create some unified event management system in the engine, as passing raw function pointers from C# is a bit messy. Something similar to wx's EventListener could work. I'll just have to spend a bit of time designing the swig interface file.

Does anyone have a clue about my last question (the PS). It's starting to drive me nuts >_<.

kthx

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!