Game Engine Library

[wdenslow]

When creating my game engine library, what type of project should I make? A class library? Im looking to link Ogre with Angelscript, OIS, PysX and MyGui.

[jacmoe]

If you're only starting out, don't worry about that - add your game engine classes directly to your project.
Only if your game engine classes grows into groups of closely related classes, you can put them in one or more DLL projects.
My two cents.

[wdenslow]

Thanks again jacmoe! Right now I'm creating a game engine like Unity3d. A reusable, multifunctional game engine. Would your advice be applicable in this situation?

[MrD]

Personally, I'm not a great fan of DLLs. I can see their uses (like being able to patch updates for certain DLLs separately, or create plug-in systems), and for LGPL code they are really your only option if you want to retain control of your product license. I still prefer to build and link against static libraries for my own libraries as it lets your compiler/linker do the optimisation step of stripping out any code you don't use, which is not something you can do with a DLL since you have to include the whole thing (which can be quite large).

[wdenslow]

Hey MrD! So your saying the best way would be to link static libs? Because right now I have a project filled with all of the header files of angelcode and most of my other libraries that I was going to build it to a Dll. to use in my engine.

thanks for the help so far.

[MrD]

Well, static libraries are easier if you've not made libraries before, since with DLLs you have to export the code that you want to be accessible from the DLL (ie, anything you want to use in your own code) so that you can link to it.

As an aside, DLLs themselves are not cross-platform. So if this is for a multi-platform release you would need to create different shared-library things (DLL on Windows, SO on Linux, not a clue for OS X) for each platform, and then handle loading them correctly on each platform, like the OGRE plug-in manager does. That said, I'm not sure how it works when those libraries are implicitly loaded at runtime rather than explicitly loaded from code, maybe when they are implicitly loaded they "just work" providing they were build correctly, like static libraries do (which incidentally are also packaged differently on different platforms; lib on Windows, a on Linux, once again no clue for OS X).

[wdenslow]

Well, static libraries are easier if you've not made libraries before, since with DLLs you have to export the code that you want to be accessible from the DLL (ie, anything you want to use in your own code) so that you can link to it.

As an aside, DLLs themselves are not cross-platform. So if this is for a multi-platform release you would need to create different shared-library things (DLL on Windows, SO on Linux, not a clue for OS X) for each platform, and then handle loading them correctly on each platform, like the OGRE plug-in manager does.

Ahh, gotcha. Well then I think I'll go with static libraries then. So just to get this straight - I need to build my different libraries to static libraries, then link them in a project.

[MrD]

Yes, you would build your code to a static library, then you would have to link that library (and any dependencies of that library that were not linked with it) into your executable project else you would get linker errors.

I just checked how SO libraries work in Linux, seems they aren't too bad.

[jacmoe]

Of course, dynamic libraries are cross-platform - what nonsense!
As a matter of fact, dynamic libraries are easier to use on *nix than on Windows because you can link to them directly instead of using import libraries like you do on Windows (using Visual C++).
But, it would be a good idea to look up the pros and cons of static versus dynamic libraries.

<edit>Yes, MrD: SO's are dynamic libraries (shared objects) </edit>

[MrD]

I never said dynamic/shared libraries weren't cross platform, I simply stated that the DLL format used by Windows isn't. I know you can create shared libraries on Linux, but I have never done so; having looked at how it is done it looks a lot simpler than the DLL method due to not needing to explicitly export code.

I have used DLLs in the past, and I can say that for people starting with library creation they are certainly more confusing than doing it using a static library due to the export business (and more importantly getting the export business right). Once as a test I wrote a game engine that built to an executable and was then extended by loading games from DLLs... just a bit of fun

[wdenslow]

Thanks a lot for the insight, you've really helped me out here MrD (once again I might add!). One more thing however (sorry if I'm being a pain in the butt ) - If I wanted to build Ogre to a static lib, what header files would I need?

Thanks again.

[MrD]

Just to clarify, do you mean you want to build OGRE itself into a static library instead of its usual DLL; or do you mean you want to use OGRE in your static library? If it is the second, then it's just a case of you using the headers you need for the classes you need access to, just like you normally would.

[jacmoe]

I wouldn't worry about that compiling Ogre statically. Don't.
You can use static and dynamic libraries together - so just keep Ogre as it is.
Also because DLLs allows you to load/unload Ogre plugins easily.
You can do whatever you want within your game engine (within reason )

[jacmoe]

@wdenslow:
In your case, I'd recommend that you just start programming, add class by class directly to your project.
Then later, turn them into static utility libraries when you realise that the classes/functions are reusable.
There's just too many programmers here who think they can just sit down and write a game engine, even without having lots of reusable code in their arsenal.
Instead, let it evolve.

MrD seem to have written an excellent framework, however.

[jacmoe]

Write Games, Not Engines

[MrD]

MrD seem to have written an excellent framework, however.

Wow, I feel somewhat honoured if you've actually looked at it.

It's true what jacmoe says, libraries tend to grow from evolution. Taking me as an example, the ICL and the Insimnax Framework were previous all in the same library, but I started to need to use some of the functionalities (like the class factories) in other projects, but without the tie to OGRE; to this end the common code was split into the ICL, and the rest was left in the Insimnax Framework which grew over time.

All in all, I probably spent 5 months on the Insimnax Framework before I released it and re-wrote the core API several times; parts of the ICL (like the class factories) are taken from some even older code of mine and have been around for probably a year and a half. I created it because I needed it, and used it for my AI assignment demo, and am still using it for my dissertation work; I released it because I thought it might be useful, and I know of one other person on my degree who is using it for their dissertation after they got fed up trying to get OGRE to work themselves.

Edit
Should probably point out that those time estimates are not 9 am - 5 pm working estimates. They are disparate "a bit at a time, when I feel like it" estimates; plus it sometimes takes me a while to think about how I want to solve a problem before I actually start work on it, that's why I like the "a bit at a time, when I feel like it" programming model despite its general lack of productivity.

[xavier]

Write Games, Not Engines

+1

[syedhs]

Talking about static linking, how I wish if all of the LGPL-ed Ogre projects/addons can be converted into the same license. Just because only one of them is LGPL-ed, then you can forget about static linking. Because how can those libraries are linked to Ogremain.lib?

Another advantage of static linking is you can statically link your msvcrtx.dll too so no longer you have to distribute and run the vsredist_x86.exe. You can pretty much ensure that your app will run on many diverse machine.