J’ai quelques conseils pour améliorer l’organisation de GD.
Premièrement, ce serait possible d’enever les debugging symbols des DLL suivantes dans la distribution de GD ?
libboost_serialization-mgw43-mt-1_43.dll
libogg-0.dll
libtheoradec-1.dll
libvorbis-0.dll
sfml--2.dll
wx-custom.dll
Ensuite, saches que sous mon Vista SP2, aucune des DLL du Visual C/C++ runtime n’est chargée par GD et que les manifests ne servent à rien.
Le GDEDITOR.EXE.MANIFEST peut être inclus aux ressources de l’exécutable par un :
1 24 gdeditor.exe.manifest dans les resources (.rc)
Pour wxWidgets, autant les garder car le poids de l’éditeur m’importe pas trop trop et ça peut être utile.
Pour SFML et les dlls liées aux jeux, en effet, je ne pensais pas que les symboles étaient toujours là. Je les ai enlevés pour libogg-0.dll, libtheoradec-1.dll, libvorbis-0.dll et sfml-*-2.dll.
Merci d’avoir signalé ça
Oui, il l’était à l’origine, mais je me rappelle d’un bug ( non lancement de GD ) lié à la présence ou non du manifest.
Depuis, je préfère le garder à l’extérieur.
Sage décision pour le manifest qui n’est en effet pas utilisé correctement sous certaines circonstances (voir MSDN)
cependant, je ne vois pas pourquoi garder les debug symbols de wx en release, puisqu’ils alourdissent l’exécutable, mais en plus, ils le ralentissent considérablement. Tu devrais essayer de te faire une version de GD sans les debug symbols de wx et une version avec, et les utiliser en faisant les mêmes choses. Tu verras que la rapidité devrait être bien améliorée. (PS: Fais ce test en interne, je ne te demande pas de publier ces 2 versions)
D’autre part, j’ai remarqué que les DLL du Runtime MSVC étaient fournies avec GD. Cette pratique n’est pas très recommandée, puisque généralement, les fabricants d’ordinateurs fournissent des versions modifiées de ces DLLs dans les dossiers système. Je te conseille donc de retirer ces DLLs d’ici, et d’inclure à l’installateur de GD l’installation silencieuse du runtime qui ne se fera que si les utilisateurs ne l’ont pas (ce qui est de plus en plus rare étant donné que les dernières versions de Windows l’ intègrent). Il y a beaucoup d’avantages, mais voici les principaux :
Le runtime installé peut servir aux autres applications
Si tu fournis une version récente, elle pourra servir de mise à jour au PC qui sera plus rapide avec un Runtime amélioré
Les versions de windows qui intègrent ce Runtime commandent le chargement de ce Runtime plutôt que celui de GD, du coup, il y a des tas de fichiers inutiles
Et j’en passe…
Au fait, j’avais oublié de te dire comment obtenir ces packages :
Normalement, au bas de la page, tu trouveras également les éditions précédentes (2008,2005). Je te recommande de prendre celle qui correspond à ton compilateur (si tu ne trouves pas la bonne version, je peux t’aider)
Certes, il n’utilise pas un compilateur Microsoft, mais le MSVCRT est utilisé quand même. Premièrement, par les applications jointes à Game Develop (encodeurs).
Ensuite, les Bibliothèques Dynamiques sous windows, c’est bien plus compliqué que ça, ça ne se résume pas à “J’utilise tel compilateur, donc il ne me faut que ses DLLs”. En fait, ça tient principalement du fait que l’on utilise les DLLs de Windows (celles que tout le monde connait : kernel32.dll, shell32.dll et user32.dll) qui sont ELLES compilées avec le compilateur Microsoft. Donc quand tu lances ton programme et qu’il appelle une fonction des DLLs (par exemple, CreateWindowW), alors la fonction est chargée de la DLL, ce qui implique le chargement de la DLL et donc des DLLs avec lesquelles elle est linkée, dont le MSVCRT qui est donc requis et le garder à jour permet l’augmentation des performances.
C’est en fait beaucoup plus compliqué que ça, mais c’est tout ce qu’il faut savoir pour comprendre ça.
