digitalmars.D.learn - Using shared libraries for external scripts, looking for advice
- 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"
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?
Aug 15 2016
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_DI 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.
Aug 16 2016