• Advertisement
Sign in to follow this  

Is your engine modularized into DLLs? (Poll)

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

I'm curious how many people here writing their game engines are actually modularizing their engine, such as having the renderer in a separate DLL that gets loaded at runtime. How is that working out for you? I currently have my renderer running as a separate module, but am running into continual issues because of the isolation of the renderer from the rest of the engine features, having to bend over backwards to do things that would normally be trivial in a non-modular setup. So I'm interested to hear how this sort of system is working for other people, if you encountered any such integration issues, and how you resolved them in your design.

Share this post


Link to post
Share on other sites
Advertisement
No, my engine is a single dylib that I drop in. I should probably turn it into a Framework.

I only support one renderer (OpenGL) for the majority of platforms so I don't see much of a reason to modularize it out. I could, but I don't develop primarily on Windows.

Share this post


Link to post
Share on other sites
I'm building an DLL based engine right now. It all fits together nicely thanks to the .NET framework. I've split my engine into an GUI, Generic Graphics, Engine Specific, and a Managed DirectX 1.1 dll so far.

Basically I defined a bunch of Interfaces/Abstract classes in my generic graphics dll, then in my Managed DirectX 1.1 dll i've been wrapping all of the DirectX stuff up. The worst part is that the wrapping is time consuming. We hope to possibly support both TAO and MDX 1.1 (In the future there maybe XNA support too).

My last project was monolithic and non resuable. This time, I'm setting out to build myself a complete reusable framework for multiple projects.

- Bill

Share this post


Link to post
Share on other sites
Yeah, my engine is in DLLs. Of course I'm working in managed code, so DLL splitting is a trivially simple and clean process that requires little or no extra coding work.

Share this post


Link to post
Share on other sites
Nope, also one lib here, but I also support multiple renderers. Not as hard as one might think to do it this way. I don't see, for me personally, a reason to go with DLLs. Getting C++ to work nicely with them is not easy unless you're using managed code which we're not.

Share this post


Link to post
Share on other sites
Multiple DLLs here. The nice thing about the DLLs is that if you know that you have made a mistake somewhere in the middle of one of these DLLs, all you have to do is drop in the newly compiled DLL and, if done properly, everything should run as planned. There are pros and cons to using a DLL over a static Lib. Just depends on what your needs are.

Share this post


Link to post
Share on other sites
Monolithic .EXE here, aside from a couple of libraries that are loaded as DLLs.

Off topic, I would posit that if you're having difficulty because of splitting your engine into different regions, your design may be suspect. That is, of course, unless you're using C++, which has a masochistically broken compilation/execution model [smile]

Share this post


Link to post
Share on other sites
Out of interest, what is your actual aim in splitting your game up into multiple dlls? Runtime switching of components? Faster compilation times? Something else?

Share this post


Link to post
Share on other sites
Main App framework that can load the 3d-renderer (DX8,DX9,OpenGL), 2d-renderer (DX8,DDraw), sound player (DX8), music player (DX8) and input (DX7, Win32) as seperate DLLs. I made it because i felt like it :)

It also lets me separate the dependencies from the main game to the DLLs. No missing DLLs popups from my app.

It's also quite an interesting challenge to get the interfaces in a clean state to power different APIs.

The main driving behind the framework was to be able to drop in a shader driven renderer (for example) if others fail for some reason.

Share this post


Link to post
Share on other sites
Modularization: Source and binary code is isolated, easy to browse, easy to replace.

Reusability: If needed you can use the same shared library among diferent programs.

Versatility: You can choose which shared library you want to use at run-time.

Along with a well designed interface model, it makes things easier to manage (maybe harder to debug), at least for me. But I've changed my mind so many times about how to do things that I can't say this is the definitive aproach I'll use forever.

Share this post


Link to post
Share on other sites
Yep I'm using C++, hence the complications. Initially, I went with a DLL design so that I could allow different renderers and such to be selected at run-time. Now, I'm wondering if that alone is worth the extra work. Monolithic would be easier, but it might lock me into a less-portable, less-reusable code base (both of which are important to me).

Share this post


Link to post
Share on other sites
My engine is currently being designed and nothing has been really coded yet. However I am going to be using a .dll for my engine and probably another dll for the game. I will then use a exe to link them together. I am doing it this way because it allows you to do an online patch very easily, through an update client. I might also just combine the engine and game in one dll, in different namespaces to make things easier for myself. This way I can easily apply a patch since everything that needs an update is in the dll(s) and all the exe would do is check for a patch, download, then load the dlls. It is very useful to have a .dll from past experiences for a multi-player game since there will always be a new patch.

Share this post


Link to post
Share on other sites
So you will only have an exe that downloads dlls loads them and then calls 1 function start() or something?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Nairou
I'm curious how many people here writing their game engines are actually modularizing their engine, such as having the renderer in a separate DLL that gets loaded at runtime. How is that working out for you?

I currently have my renderer running as a separate module, but am running into continual issues because of the isolation of the renderer from the rest of the engine features, having to bend over backwards to do things that would normally be trivial in a non-modular setup. So I'm interested to hear how this sort of system is working for other people, if you encountered any such integration issues, and how you resolved them in your design.




The rendering code and everything else.... (network, AI/scripting, input processing, memory management, file management, Service framework, sound/voice ...)

So much is intertwined in my Simulation App, including inter-server communications(distributed derver), that trying to interface back and forth to DLL(s) would be inefficient (and the applications has enough to do without more overhead -- Ive seen applications made incredbly slow by too many internal layers/interface).

Modularizing when not needed is just extra work (my App isnt an Engine really -- its an entire integrated system AND one that has high performance requirements).

High performance (for real AI) is needed so I actually am doing the 'scripting' in Native Code -- which might yet be a candidate for DLLs, but external modability isnt a requirement (as yet), and recompiling and linking isnt slow (I wonder what people do to their code that it takes minutes to recompile the entire App....)




Share this post


Link to post
Share on other sites
Right now my engine is a single EXE that has a static lib linked in (libJPEG).

The engine and client are well-separated, I don't much want to separate them more for the time-being. I'm more interested in making things look pretty. [smile]

Share this post


Link to post
Share on other sites
Quote:
Original post by OrangyTang
Out of interest, what is your actual aim in splitting your game up into multiple dlls? Runtime switching of components? Faster compilation times? Something else?


Well I split mine up for two reasons. One, this is the third time I've built a GUI from scratch. I would prefer this time to make it modular so that it can be ported to other applications even if I decide not to use my current engine.

The other reason was to support multiple rendering API's. I also envision an modable engine, where the main game.dll can be replaced by another that implements the necassary interfaces from my engine.dll.

A good portion of the engine functionality will be hidden in the main exe. Stuff that can we be reusable has been shifted to engine.dll...

Share this post


Link to post
Share on other sites
Quote:
Original post by ronkfist
So you will only have an exe that downloads dlls loads them and then calls 1 function start() or something?


Basically yes, as far as planned. Once start() or whatever is called from the exe it should not be used again for engine or game stuff (if all goes well)!

Share this post


Link to post
Share on other sites
I've tried it. It used to cause stupid problems with intellisense and such, and I likes my intellisense, so I didn't generally do it.

Now that I have 2005 and intellisense is much better in DLL's, I've began writing various modules, which allow me to change things easily like adding/removing renderers, etc.

Share this post


Link to post
Share on other sites
It's a single DLL that links to a bunch of other third-party libs(Newton,Cal3D,DevIL...). It also has to ability to run Python modules, which basically uses for defining rendering techniques and AI behaviour.

[Edited by - mikeman on July 9, 2006 1:52:22 PM]

Share this post


Link to post
Share on other sites
I haven't worked much with DLLs but is it anything like scripting languages where you could rewrite a function and just drop it in? If I'm missing anything please let me know.

Share this post


Link to post
Share on other sites
If someone can tell me that dynamic linking is easy to do cross-platform with minimal fuss (in c++), I'd probably do it. Monolithic .EXE for the moment.

Share this post


Link to post
Share on other sites
Quote:
Original post by _goat
If someone can tell me that dynamic linking is easy to do cross-platform with minimal fuss (in c++), I'd probably do it. Monolithic .EXE for the moment.


I'm not sure about Windows, but *nix systems can use .dylib files which are dynamic library files. Aside from that, using static .a or .lib library files is the only real cross platform solution.

Personally, I just use whatever works on the specific platform. My current project uses Ogre, OgreNewt, and Newton as of now. On Windows, the game links using DLLs. On Mac, I use a standard library for Newton and OgreNewt and the Framework for Ogre.

Share this post


Link to post
Share on other sites
I have my current engine in a single, statically linked lib. Eventually I'd like to get around to making it cross platform (its currently using DirectX & win32), at which point it will almost definitely be dll'd.

Share this post


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

  • Advertisement