There are basically three ways to get your custom C code to run in Stingray using a DLL.
NOTE: As of v.1.1, dynamic linking is only possible on Windows, so these approaches can ONLY be used for games that target only Windows. If you want to target other platforms than Windows, you'll need to either a) get source access, link statically and rebuild the engine binaries with your code in it, or b) stay tuned for a future release where we support dynamic linking on more than just Windows.
Option 1: writing an engine-level plugin using the plug-in API described under http://help.autodesk.com/view/Stingray/ENU/?guid=__developer_writing_plugins_html. As of v.1.1, this is only possible with source access. We're hoping to lift that restriction before too long too.
Option 2: using the LuaJIT FFI library. There's a quick summary in the dropbox link given above, and more details in the LuaJIT docs. You make a DLL out of your C code, and place the DLL next to your Stingray engine executable. In a special block within your project's Lua code, you write declarations for the C functions and types that you want to use. Then you load your DLL from Lua using the LuaJIT FFI, and call the C functions you've defined from your Lua code. This way is "easy" because you don't have to write any special binding code in C, and you don't have to worry about compiling your C code against Lua. You can just call your C code as-is from Lua. However, I've personally found it hard to get FFI working with any non-trivial real-world C modules due to complex data type conversions and stuff. YMMV!
Option 3: making a Lua Extension Module by writing your own bindings (in C) that expose your C functions into the Lua environment. Your module needs to have a function called luaopen_<dll_name>, in which you register your C functions. The document on the dropbox link has some information about this, and there's more available on the web. You then compile your C code to a DLL, which you place next to your engine executable. In your project's Lua code (say, in the project.lua file), you put a "require" statement that loads your DLL, and then in your Lua functions you can call whatever functions you've created bindings for on the C side.
For option 3 to work in Stingray v.1.1, I've found that you have to get the version of LuaJIT that matches the one used in Stingray (2.0.0), and link your C code against it dynamically. You have to build the LuaJIT binaries yourself, making sure that you target the right processor (32-bit or 64-bit). Your C code has to include lauxlib.h in order for you to write your bindings, so add the src directory of the LuaJIT distribution to your include directories. Link your code against the lua51.lib that you build from the LuaJIT distribution. The LuaJIT DLL will already be available at runtime, loaded by Stingray (again, as of v.1.1).
It's easy to end up in "DLL hell" doing all this, so start with some simple C code until you get your build and installation working right.
I'm working on making some more official docs for this process, but hopefully this might help get you started.
Extensibility is high on our agenda for both the runtime engine and the editing tools, so keep your eyes on each new upcoming release. If you do give any of these options a shot, let us know what you find.
