Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

BouncePup

What do you think? (Generic programming question)

This topic is 5363 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

Ok here''s my problem, I''m writing a game engine that is split into lots of different sections and I need a way for everyone to access a global variable. In other words... When you use this engine to make a game you write at least one file, game.dll; This file contains the guts of your game, so to speak. What I''d like to do is have a interface class that lets all the modules within the engine access the same data. For example, you want to open the config file ''autoexec.cfg'' you would do this: g_pEngine->ReadConfig("autoexec.cfg"); But I need a way to do that from any mod. As you should know you can''t very well define a extern variable called ''g_pEngine'' in a header file w/o the declaration somewhere within that project; All you''ll get in an unresolved extern variable =) Basically the way I would like it is that the engine EXE creates the variable because it does need to initialize some variables within it (keeping track of the HWND & HINSTANCE, etc) Well if that made some sense (heh), does anyone have some good ideas on my situation? Thanks! Nate btw, I''m in programmer mode and typing about 90WPM so excuse the spelling & grammer.. hehe

Share this post


Link to post
Share on other sites
Advertisement
HL uses a system where your DLL has a function in it which HL calls to populate a series of varibles which give pointers to data or functions or classes depending on the data, which can then be used to call internal engine functions.

Share this post


Link to post
Share on other sites
Yeah, have the engine create the object (statically or dynamically), and get the engine to export a function the DLL can call when it wants the engine to give it a bunch of pointers. One of those pointers is the pointer to the engine class, or however you have it.

Share this post


Link to post
Share on other sites
EDIT: I just read Zipster and the_phantom_'s posts, and mine doesn't make sense, except for the 'function to access that global variable indirectly' bit. [/EDIT]

I've got a hard time understanding your problem, but it may be because it's almost midnight over here.

Anyway, what's the problem with a global variable? You define it in one of your engine cpp files, and write 'extern global_variable' in every other... Yes, it's a pain. Otherwise, you could use a function to access that global variable indirectly.

You could also use a singleton.

Cédric

[edited by - cedricl on September 14, 2002 11:52:01 PM]

Share this post


Link to post
Share on other sites
What he''s saying - or at least how I understood it - is that he needs the DLL to access data created and functions implemented in the executable. Thus he needs to export a function that can pass the function pointers the the DLL.

Half-Life uses such a system to pass engine functions to the SDK DLL, which is why that was mentioned

Share this post


Link to post
Share on other sites
Well I'm already using a simple interface system ( two __declspec(dllexport) functions) to access the actual interface functions within the engine dll files, but can I do that with an exe file...? Since it loads everyone else I could do some kind of callback system I assume, but I want the game.dll to automatically load (Or make it seem so..)

Looking into the lithtech engine code it seems to create a static variable address (Or some such, I'm reading comments mostly) to access their g_pLTClient interface. But from what I gather they use their own COM style system, which is above me.. heh

Thanks for the quick replies!
Nate

[edited by - nstrg on January 20, 2004 12:12:10 AM]

Share this post


Link to post
Share on other sites
I''ve never done DLL programming, but on second thought, a singleton might work:

Header file:

  
class CEngine{
CEngine();
public:
... stuff ...
static CEngine &Instantiate();
};

CEngine.cpp

  
CEngine &CEngine::Instantiate(){
static CEngine eng;
return eng;
}

Game.dll

  
CEngine::Instantiate().ReadFile("autoexec.cfg");


There are probably mistakes and maybe some fatal flaws in my idea; I''ve never implemented a singleton myself. Anyway, if anyone knows why it would not work, say so.

Cédric

Share this post


Link to post
Share on other sites
hm.. So if it was an static variable it might work? btw, your method would have to have some way of telling the compiler it''s calling a function located in the EXE wouldn''t it.....? Or might it work just because it''s all loaded together in the first place..?

Thanks
Nate S.

Share this post


Link to post
Share on other sites
In the exe, you have
struct GameEngineFunctions{
void (*ReadConfig)(char *);
void (*SaveConfig)(char *);
};
void GameReadConfig(char *file) {/*some code*/}
void GameSaveConfig(char *file) {/*some code*/}

Game_Engine_Functions GameFuncs = {GameReadConfig, GameSaveConfig};

void (*Dll_GiveEngineFuncs)(GameEngineFunctions *);
Dll_GiveEngineFuncs = GetProcAddress(GameDllHandle, "Dll_GetEngineFuncs");
Dll_GiveEngineFuncs(&GameFuncs);


In the DLL, you have
struct GameEngineFunctions{
void (*ReadConfig)(char *);
void (*SaveConfig)(char *);
};
Game_Engine_Functions *GameFuncs;

__declspec(dllexport) void Dll_GetEngineFuncs)(GameEngineFunctions *funcs)
{
GameFuncs = funcs;
}

/*...*/
GameFuncs->ReadConfig("autoconfig.cfg");
/*...*/
GameFuncs->SaveConfig("custom.cfg");
/*...*/

Probably not perfect, but its the basic idea of the way Half-Life handles it.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!