On Monday, 15 August 2016 at 08:45:07 UTC, Tofu Ninja wrote:
So this is kind of an open ended question, just looking for
advice on doing it in general, if it's possible, and doing it
specifically in D on windows. I am not super familiar with how
shared libraries work so I had some questions.
I would like to attempt to use D to write scripts for a game
engine I am working on. The goal is to have the ability to
externalize the code that is specific to an individual game or
level instead of just compiling it all into the engine it self.
I want to be able to treat them as resources similar to other
asset files such as images or models. A secondary goal is to be
able to reload them at runtime for iteration.
There is another way, you can use a scripting language and "plug"
things you want to use there.
For example with scheme-d:
https://github.com/p0nce/scheme-d/blob/master/examples/repl/repl.d (however: don't use schemed, it's crap)
So with that in mind, my general plan was to compile them into
dll's and load them at runtime. My understanding is that to
make it work, each dll will need to have an entry point that
registers its data with the rest of the engine but I am unclear
of some of the details or even if it is possible.
You can export any function you want with the signature you want.
But usually a C FFI is used with only pointers and plain structs.
Each DLL will have its own D runtime and GC.
You can use the recommended snippets for DllMain:
https://wiki.dlang.org/Win32_DLLs_in_D
I am unsure of how to give the library access to the rest of
the engine. For instance, I have some global data in the
engine. How do I go about making sure the dlls have access to
that data, is there a way to make sure the dll will share the
memory space as the rest of the program,
The DLL will always share the memory space of the rest of the
host program.
or will I need to explicitly pass that data into the dll to
give it access.
Yes because it's bad manner anyway for the DLL to access data in
any way other than through exported functions.
Also I am unsure of how to go about keeping the engine code out
of the dll. I would like to keep the dll as small as possible.
If the dll accesses anything from the engine, how do I keep the
engine code out of the dll?
If it's all D, you can perhaps pass interfaces around.
Idealy I would also like to keep phobos out of the dll as well.
If the dlls get too big then it will probably not be useable.
Then you can make a runtime-less DLL, remove the stuff in
DllMain, but this won't be fun everyday.
