Actually 2 questions, but let's start with the more global one; is it a good idea to put math functionality in a separate library (Windows DLL) - performance wise?

I'm trying to split up my huge game application into smaller chunks, DLL's. One of those chunks would be a generic math library, with mainly vector functions. Now normally I don't care tóóó much about performance, but vector-functions are called LOT's of times each cycle. And if I remember well -but correct me if I'm wrong!- calling a function from an external library adds a little bit overhead.

So Instead of calling DLL functions, I could just as well just attach the code files to my other libraries that make use of it, if performance is really an issue. But I found the DLL way more elegant. The smaller each library, the better maintainable. Any idea how modern game engines handle this?

For the info- I'm making this math library with either native C++ or Pascal (Delphi XE). Thus not .NET or the likes.

Second, and this might be a bit C++ or Delphi specific, I'd like to keep things OOP. Now with .NET you can import a DLL and use its classes. But if I'm right this is not (directly) possible with C++ or Delphi based libraries. AFAIK, you can only export functions, structs (with functions / operator overloading??), and "Interfaces".

The latter, Interfaces, would more or less allow to export an "object" with functions. But yet again, I'm not sure if this is wise to do, when caring about performance. A typical example would be sharing "Entities" amongst multiple DLL's. An entity could be a game object, such as the player, a lightsource, or a crate. Several DLL's could be interested in using (read looping through / reading / writing / calling a lot) these entities. AI, Rendering, Physics, Game-rules , ...

First of all, thanks for your time! Second, what exactly do you mean with a "Static library"? I know the term, but since its used in so many (slight) different ways. I suppose you mean the code from libraryX (a *.lib file? or *.a in Linux?) is actually "baked" into the "host" executable (thus no DLL or other files that are linked after starting the EXE). Basically just one big program? Never really tried that for some reason, but it makes perfect sense.

As for the same compilers, most likely that will be the case. The whole game/engine is made in Delphi7 (including a couple of DLL's written in Delphi7 and C++/VS2008). Delphi7 is ancient though, so I'll have to migrate sooner or later. Likely DelphiXE will give me a smoother transition, otherwise I would have to rewrite the whole thing in C++. Then again splitting up in modules and doing a big clean sweep won't hurt.

I've been using DLL's written in various languages quite some time, but not really consequently game-engine wise. Re-usability of code is nice, but splitting up in libraries/modules or whatever is especially nice as it *forces* you to think (better) about the design and architecture. When dealing with one huge program, roles and functionality often get blurry after a while. Who does what, what is depending on which...

Memory management is always a b*tch. I'm trying to avoid creating and destroying "stuff" on the fly as much as possible. Instead of building everything on demand whenever needed, I try to provide a collection of available objects. And yeah, you're right; if programA desroys stuff while DLL-X is still expecting it, errors get nasty. And probably it gets even worse when involving multi-threading and such.

Thanks again!

Usually there are a thousand ways to Rome, but judging on your anwers (which make perfect sense), Static Libraries will be the way for me then.