Jump to content
  • Advertisement
Sign in to follow this  
Yours3!f

implementing scripting

This topic is 2126 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

 

so I'm trying to implement scripting using runtime-compiled c++ code. Now my problem is that when I load the DLL, it's functions see different memory than the exe's code (so getting a singleton results in a new singleton, rather than getting the exe's singleton).

So I suppose I should implement some sort of interface, so that I can call the exe's functions, and the exe's code is hidden from the gameplay code. This would enable anyone to create a gameplay c++ code or DLL and load it in the exe. I suppose this interface is needed with different script languages like lua too, so there should be a 'usual' way to handle this.
How is this usually handled?

Share this post


Link to post
Share on other sites
Advertisement

Your .EXE is capable of exporting symbols just as your .DLL is.  Just as your (and almost every other) .DLL relies on external symbols from other .DLL files, they may also rely on external symbols from your .EXE.

 

So make your .EXE export whatever symbols you need the .DLL to access the same way you would export symbols from any .DLL, and make the .DLL import those symbols from the .EXE the same way it would import from any .DLL.

 

 

L. Spiro

Share this post


Link to post
Share on other sites

Your .EXE is capable of exporting symbols just as your .DLL is.  Just as your (and almost every other) .DLL relies on external symbols from other .DLL files, they may also rely on external symbols from your .EXE.

 

So make your .EXE export whatever symbols you need the .DLL to access the same way you would export symbols from any .DLL, and make the .DLL import those symbols from the .EXE the same way it would import from any .DLL.

 

 

L. Spiro

 

 

thank you for the reply!

well, I thought it would work the other way around too, but I would be interested in the actual howto on the interface design and such. Or there isn't much magic there, just export some functions and that's it?

Share this post


Link to post
Share on other sites

There is no magic.  It works the same way as any DLL linking to any function in any other DLL.  EXE’s and DLL’s are almost the same thing.

 

 

L. Spiro

Share this post


Link to post
Share on other sites

There is no magic.  It works the same way as any DLL linking to any function in any other DLL.  EXE’s and DLL’s are almost the same thing.

 

 

L. Spiro

 

well, okay thank you :)

Share this post


Link to post
Share on other sites

For communication between DLL's and EXE's using C++ a commonly used technique is to have virtual interfaces to systems, as this way you can pass around a pointer to a structure which holds the pointers to the interface of each sub system. This is the technique we used in Runtime Compiled C++ and it's also how the CryENGINE passes around interfaces using gEnv.

 

For a look at what a system table looks like see this file.

 

Exporting classes without using virtual interfaces is not simple in general, for an overview have a look at this post on codeproject. Using a virtual interface makes things alot easier - they don't have to be pure virtual but this does help to eliminate mistakes. Make sure to define a virtual destructor to prevent the memory created in one module being freed in another.

 

Feel free to use any of the code in RCC++, we use a liberal Zlib license and you can just use which-ever parts you need.

Share this post


Link to post
Share on other sites

For communication between DLL's and EXE's using C++ a commonly used technique is to have virtual interfaces to systems, as this way you can pass around a pointer to a structure which holds the pointers to the interface of each sub system. This is the technique we used in Runtime Compiled C++ and it's also how the CryENGINE passes around interfaces using gEnv.

 

For a look at what a system table looks like see this file.

 

Exporting classes without using virtual interfaces is not simple in general, for an overview have a look at this post on codeproject. Using a virtual interface makes things alot easier - they don't have to be pure virtual but this does help to eliminate mistakes. Make sure to define a virtual destructor to prevent the memory created in one module being freed in another.

 

Feel free to use any of the code in RCC++, we use a liberal Zlib license and you can just use which-ever parts you need.

Thank you,
I'm actually using the rtcc++ (win32 alternate file watcher api, remember?), and I'm now at the implementation stage. I skipped the actual example (simpleexample) code, because it was a bit huge (the consoleexample wasn't though) tongue.png

I've actually read the codeproject article while googling, and I started to do something like that, but this seems a bit more organized.
So I guess I'll look into the SimpleExample now...

Edited by Yours3!f

Share this post


Link to post
Share on other sites

Hi - I thought there might be a connection, but wasn't sure since you'd used different profile names! Thanks once again for the alternate file watcher ;)

 

The SimpleExample is a bit big - keep meaning to change the name to PulseDemo as that's what it morphed into. The sample does show how to pass in a pointer to an interface structure so you can interact with your game engine.

 

In my case with the game Avoyd I'm working on, I'm actually implementing most of the engine using RCC++ as a trial of how that can be made to work better. The new features described in the blog help with that, though I need to get more documentation up on the wiki to help.

Share this post


Link to post
Share on other sites

Hi - I thought there might be a connection, but wasn't sure since you'd used different profile names! Thanks once again for the alternate file watcher ;)

 

The SimpleExample is a bit big - keep meaning to change the name to PulseDemo as that's what it morphed into. The sample does show how to pass in a pointer to an interface structure so you can interact with your game engine.

 

In my case with the game Avoyd I'm working on, I'm actually implementing most of the engine using RCC++ as a trial of how that can be made to work better. The new features described in the blog help with that, though I need to get more documentation up on the wiki to help.

 

Yeah, I use a couple of them :)

I actually took my time today, and looked at it, and got it right. As I noticed I still need to export one function at least to set the system table, but that is fine.

 

I'm working on one too, though it doesn't have a website yet (only youtube channel), I intend to use the scripting to do gameplay, not the whole engine. More docs/wiki would be awesome!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!