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.
Is your engine modularized into DLLs? (Poll)
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.
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.
Author
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).
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.
So you will only have an exe that downloads dlls loads them and then calls 1 function start() or something?
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....)
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]
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]
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...
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)!
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
