Choisir entre les librairies statiques et les libs/plugins dynamiques?

Question

J'ai jeté des choses ensemble dans un petit jeu de test au cours des 6 derniers mois, et maintenant tout est dans le même projet. Je voudrais en savoir plus sur la création d'un «moteur» pour la réutilisation et j'essaie de trouver la meilleure façon de le faire.

Les bibliothèques statiques sont évidemment un peu plus rapides, car elles sont compilées au lieu d'être chargées au moment de l'exécution, mais cela ne m'importe vraiment pas. Les avantages des DLL sur les bibliothèques statiques semblent plutôt importants. Je me demande donc quelle est la meilleure approche/approche la plus utilisée pour un "moteur de jeu". J'utilise Ogre3D (moteur de rendu) qui supporte les plugins dll qu'il charge et non, mais je voudrais écrire mes dll où je pourrais les utiliser n'importe où. Donc, mon meilleur pari serait d'écrire des DLL individuelles pour chaque partie de mon exemple de moteur, comme sound.dll, gui.dll, etc? Ou serais-je mieux servi en créant une grande DLL, jugée engine.dll ou quelque chose? Je suppose que la meilleure approche serait d'écrire quelque chose comme ... engine.dll pour la structure générale, puis le composer d'autres DLL telles que sound/gui/input/etc.

Serait-il stupide de ma part d'écrire mes DLLs indépendamment du système Plugin d'Ogre? My Sound repose sur la bibliothèque FMOD, mon interface graphique repose sur la bibliothèque CEGUI, etc. Je veux principalement créer mon moteur à un point où il est facilement utilisable avec les fonctions dont j'ai besoin dans les différentes bibliothèques.

Answer 1

Si vous créez des DLL pour la réutilisation, il est logique de les diviser en unités autonomes de fonctions. Ainsi, si vous avez une bibliothèque de sons générale qui, par exemple, lit des fichiers wav, elle pourrait être séparée en sound.dll si vous pensez que beaucoup d'autres programmes pourraient utiliser cette bibliothèque particulière. De même pour tout ce que vous pensez serait réutilisable ailleurs.

Cependant, si c'est surtout le cas que les seules personnes utilisant vos routines sonores sont celles qui chargeront aussi le reste de votre moteur de jeu (ou la plus grande partie) dll, je vois peu d'intérêt à avoir autant de bibliothèques séparées . Je peux voir le sens d'avoir engine.dll de sorte que de nombreux jeux peuvent être créés à partir d'un seul moteur, mais pas de diviser le reste inutilement.