• Tofu Ninja (32/32) Aug 15 2016 So this is kind of an open ended question, just looking for
• Guillaume Piolat (17/46) Aug 16 2016 There is another way, you can use a scripting language and "plug"

Tofu Ninja <joeyemmons yahoo.com> writes:

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.

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.

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, or will I need to explicitly pass that 
data into the dll to give it access.

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? 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.

Is this even possible currently? Is this a terrible idea or am I 
severely misunderstanding things? I think I heard that remedy 
games did something similar, anyone know the specifics of how 
they did it?

Guillaume Piolat <first.last gmail.com> writes:

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.