Rene Damm

Hey Daniel :) Been coming round here occasionally to see what's going on with good old Torque. Thought I may as well contribute something, even if it's just random comments. Aside from the benefits you mentioned, engineAPI was mainly meant to hide all the internals of how the interop works (such as the manual string parsing that the old console methods were doing) such that the interop can be done in whatever way you want without changing any of the script methods. The "final" version also supported varargs. What's now in T3D is sort of engineAPI v0.8. We eventually used it from C# without any generator tool. It requires manually adding some interop stuff but .NET makes that very, very easy. Still, once it was set up, the interop generator actually made for a really nice experience. Add something in C++, hit build, and continue writing in C# with VS/ReSharper seeing all the new definitions (and even documentation; we converted the docs added in C++ to XML docs in C#).

engineAPI basically already has all the bits for interfacing Torque to whatever control layer you want. The current implementation making use of the console system is easily replaced with something else. What we did initially was to just purge all the scripting wrappers that engineAPI generates internally and leave only straight DLL export functions for the various DefineEngineMethods etc. We then wrote a small tool in C# that took the XML output generated by engineAPI (there's a public C function that gives you a string in XML format that describes the entire supported API; forgot what it's called) and generated a C# wrapper for it. It simply loaded the DLL, called the function, and then parsed the output. This we hooked into our build chain. I.e. we'd compile the engine DLL, then invoke the tool to generate/update the C# code and then built that into an assembly. However, we later changed to a model where we no longer auto-generated the C# wrapper but rather hand-maintained it. This was because we had an additional abstraction layer in there that allowed to use both Torque's old C++ engine as well as a new XNA-based engine as a backend to the high-level C# code -- the latter being the part that the game developer was actually using (a component-based engine in pure C#).

We (I) ripped it out for Torque 4 (a.k.a. "The Torque That Never Happened v2"). It wasn't a huge pain. We extended the engineAPI stuff and used it to interface to a .NET-based high-level part of the engine.