I'm using DirectX 10 (in C++) to make a game engine, and a test driver program on top of it.

Now that I've written many messy rough drafts of an engine, I want to make the final (or sorta final) clean version. I choose to follow how I've seen other engines do it, and that's to have all the core nasty messy crap in a DLL, and then you can create games with just a few functions (well, not really :D).

However, I'm unsure of what nasty messy crap to put in that DLL. I don't know about speed restrictions with DLLs. What I've done is put my winproc in the DLL, and have a class that takes the messages, and sends them through to the program using the DLL. Then that program does what it needs to do, and calls a rendering functions back in the DLL that renders everything.

Only problem is it gets very low FPS (2, to be exact...). I've looked through everything, and I don't know if the way I'm using DLLs in causing this, or its something different.

Whether it's the DLLs or not, I still want to know how to use a DLL correctly with a game engine. I like being neat, I hate having to see all those long names of DirectX classes. I use typedef a lot.

2 Answers
2

Your 2 FPS experience is most likely on account of something else in your code rather than use of a DLL. When loaded a DLL is mapped into the same address space as the main process, so a function call into a DLL is really nothing more than transferring execution to another address (with the standard stack work, of course).

Quake II used a DLL for it's renderer back in 1997 and certainly didn't exhibit any of these problems, so neither should you.

The only other thing I can think of is that you might be doing a LoadLibrary/GetProcAddress/make function call/FreeLibrary around each call you make into the DLL. That would certainly generate quite a bit of additional overhead, but - with the caveat that I haven't tested this particular use case - I doubt it would be so extreme.

Time for you to break out the debugger and profiler, and dig a little into what's going on inside your code I think.

Final note. This whole pattern is, I think, a variation on premature optimization. I'll call it "premature cleanliness", but it's just as evil. You know that you want to break out certain functions into a DLL, but you haven't actually sat down and mapped out exactly how you want to go about it yet. That's a pretty important thing to do before you actually start doing it. Ditto with your heavy use of typedefs to mask the D3D names. That's going to impact quite a lot on your ability to use documentation and other examples. You're better off swallowing your distaste and focussing on the end result.

Thank you for the response. This solves my DLL issue. I just figured out how to use the dang things like 3 months ago, and I wanted to make sure I was actually doing it right! My problem with designing an engine is, well I'm a bit lazy. I like to make things easy to use ahead of time than go back and change them later...
–
smoth190Nov 21 '11 at 21:31

You're intent on separation of "nasty" code from "non-nasty" code. That's what OOP encapsulation is for. Classes are as good as you'll ever need, since separation of code is a coding/compile time concern, not a runtime concern as DLLs are.

Not only that, but by factoring/organising your code into classes, you will have a better understanding of how they fit into the bigger picture. Assuming not all of this code comes from the depths of your own mind, it will also force you to understand it marginally better.

PS. Where did you get this idea that different parts of your game need to go into separate DLLs? Don't assume that because eg. graphics and networking libraries you may be making use of, are provided as DLLs, that you have to componentise your game's executable code to this degree as well. That's just misguided.

I only have one DLL, that has all the rendering classes and base entity classes and such in it. I just hate having to work directly with the DirectX library, so I cover everything up.
–
smoth190Nov 21 '11 at 21:34

DLLs do provide another level of separation - only exported symbols can be accessed directly, so it's very difficult to inadvertently expose things. It would be nice if there was a similar feature for static libraries, but there isn't.
–
immibisJan 23 at 0:58