It seems that the code overall is quite short, but this can't be the whole source to call for example engine_close() in the dll or ?

I'm missing something like this :

[DllImport("acknex.dll")]
internal static extern void engine_close();

wow, looks complicated. why not use ironpython?
http://secretgeek.net/host_ironpython.asp
with just a few lines of code you get a full scripting engine and for one liners python doesn't look different to c# anyway.

yes, in boo you also need the [DllImport("acknex.dll")]. i left it away in the example snippet.

hmmm, i'll look into ironpython.

Yeh the C# way looks complicated because you have to build assemblies at runtime, and i guess you have to be really comfortable with reflection; which i'm not lol.

WOW ironpython seems powerful. In under 5 mins i had everything set up and running and it worked pretty well. I'll see if i can now call something like "ent_create" from a string...

hmmm, i'm not really sure how to use ironpython. I can use it to change controls at runtime, but i had no success in using it to create engine objects like an ENTITY*.

I did some browsing and learnt what assemblies and functions i needed to create assemblies at runtime and execute my own code. The only requirement is that I pass in required DLLs, so i had to compile the C# wrapper into a single DLL. The result is pretty good. I called "ent_create..." from a string and it created then entity just like as if it had been compiled on the project build.

There will be a slight lag due to memory IO but it should be OK. I dont really need this for my project right now, just thought it would be cool to learn it, but this method has the potential to create a whole new game engine allowing the user to write actions / particles / shaders and test them in real-time without the need for compilation by acknex.

BTW Stromousfall, isn't it easier to compile the Wrapper source files into one DLL and then distribute that?

That's a good idea i would say, thus all internal methods and properties wouldn't be visible from outside, just as they were meant to be. But i will do some research if DLL is at least as fast as plain source code - that's in fact what matters ^^

Well i havent tested it but i'm sure there wouldnt be any performance hit, if not the DLL runs faster. The source files all together occupy around 1.2mb, but the DLL is only around 300kb, so it probably strips down some of the common data or compresses it.

Only thing is, i'm not sure if you can debug inside a DLL. At the moment if we have a crash we can find the method/line inside the wrapper which is causing it and report it to you. I'm not sure how we would do that with a DLL.

Either way the wrapper works fine.

That debug thing makes the point i would say. And creating a dll from the wrapper shouldn't be hard if anyone wants to. Did you have to change much to get it into a dll ?

<<Only thing is, i'm not sure if you can debug inside a DLL. At the moment if we have a crash we can find the method/line inside the wrapper which is causing it and report it to you. I'm not sure how we would do that with a DLL.>>

This makes sense.

It wasn't hard creating the DLL, because they all share the common namespace "AcknexWrapper". I just created a new 'Class Library Project'. Added the AcknexWrapper folder, press build and the DLL is created.

Then to use it in the project just add a reference to it, and all functions remain the same, no problems.

But I think the fact that we can't debug is a disadvantage and so i'm leaving it as it is for the moment. Maybe when you get a rock-solid version that causes no crashes, then maybe a DLL is more suitable.