Modular Game Engine - Linking Dlls

Started by
4 comments, last by frob 7 years, 8 months ago

Hi Guys,

I've tried searching for a succinct answer but I guess I just don't know how to ask the question succinctly!

Anyway here's my current problem:

I have a project in my solution which is called GameEngine. This is set up to build to a .DLL.

I have another project in my solution called GameWindow. This also compiles to a .DLL.

The GameWindow is responsible for creating a window and anything else which comes with that.

I have created a reference to the GameWindow project in the GameEngine project within VS2015.

Now, I have created a test project which is the entry point(.exe).

Within it's main function I wish to create a window, but I only want this project to know about GameEngine .dll.

I've tried a few different approaches but always end up with linker errors. I guess 1 of the problems is I don't fully understand that process.

But my main question is, how would something like this generally be approached?

Advertisement

Within it's main function I wish to create a window, but I only want this project to know about GameEngine .dll.

How about pimpl? You can hide class GameWindow inside Engine implementation

Within it's main function I wish to create a window, but I only want this project to know about GameEngine .dll.

How about pimpl? You can hide class GameWindow inside Engine implementation

Well that's 1 suggestion I wasn't aware of, but I'm kind of after the answer: This is how it's usually done or you're thinking of this completely wrong etc. Bear in mind this is all in terms of a Modular design.

I think a visual representation of what I'm after will be useful:

-> means "knows about"

App->GameEngine->GameWindow->WindowsWindow

->MacWindow

What kind of structure would I need for "App" to create a GameWindow? i.e. if App includes GameEngine.h which includes GameWindow.h, but GameWindow.h is not linked at that point for App to know about it.

Wait, I've just realised. If I make all of my modules dynamically linked, but then have the main Engine link statically, then that should work right?

I've tried a few different approaches but always end up with linker errors. I guess 1 of the problems is I don't fully understand that process. But my main question is, how would something like this generally be approached?

Features that vary independently go in libraries. If you've got a graphics library you are sharing between games it may be a library. A physics engine shared between games may be a library. Audio is a library.

You are choosing to make a dynamically linked library. That's fine. When you build them it generates both a DLL and a LIB file. You can either use the lib file directly, and if you do the system will automatically load the libraries and bind the function pointers for you. Or you can dynamically load the libraries on your own, binding the function pointers yourself.

It is generally approached by marking the libraries as dependencies in your build chain, they generate .dll and .lib files. If a piece of the program needs to use it, you link that binary to the .lib file that corresponds.

This topic is closed to new replies.

Advertisement