Mettre à jour le SDK DirectX

Quand j'ai rejoint Bitsquid il y a un mois, quelqu'un a mentionné vouloir mettre à jour le SDK DirectX pour bénéficier de certaines améliorations, mais que nous avions des dépendances qui posaient problème. Je me suis naïvement portée volontaire pour enquêter. J'ai finalement désentortillé tout ce bazar au cours des dix derniers jours, et réussi la mise à jour. Le but ici est de partager ce que j'ai trouvé pour économiser du temps aux prochains malheureux qui tentent la même chose. À noter: les liens dans cet article sont en anglais.

Étape 1: Exploration

Premier arrêt: l'article dédié sur MSDN. J'avais entendu dire que le SDK DirectX était maintenant inclus dans le SDK Windows, mais n'étais pas certaine de ce que ça impliquait. Cet article résume le sujet. Avec un collègue, nous avons parcouru la liste, et noté ce que nous utilisions ou non. Au final, les seuls composants problématiques étaient XInput, XAudio2, et D3DX9Mesh. La majeure partie du code avait déjà été convertie pour ne plus utiliser D3DX, ce qui nous a fait gagner du temps!

Mais quelques petites choses restaient à clarifier. Notre configuration minimale est toujours Windows 7. Est-ce que ça allait marcher? Heureusement, MSDN avait la réponse. Cet article mentionne que le SDK Windows 8.X est disponible sur Windows 7. Il y a plus de détails sur cette page et cette page.

Étape 2: Bon bah on essaie

J'ai changé les références dans nos fichiers de génération de projets, pour pointer vers le SDK Windows. J'ai également ajouté le SDK DirectX de Juin 2010, mais uniquement pour XAudio2 et D3DX9Mesh (pour XInput, voir plus bas). Après avoir résolu les quelques erreurs de compilation, les choses semblaient fonctionner... jusqu'à un crash à l'exécution lié à ID3D11ShaderReflection. De quoi?

Étape 3: GUIDs et #define magique

J'avais à tort supposé que les erreurs de linkage causées par les changements de références venaient de DX9, parce que j'avais lu trop vite. Linker avec (l'ancienne) dxguid.lib les avait fait disparaître, et je n'y avais pas fait plus attention. Mais une grande part de DirectX fonctionne à base de GUIDs, des identifiants uniques en dur dans le code. En déboguant, j'ai remarqué que IID_ID3D11ShaderReflection n'avait pas la bonne valeur, celle du SDK Windows, ce qui causait le crash. J'ai perdu une journée à la chasse au dahu, à tenter de trouver d'où le changement venait, pensant que c'était une #include incorrecte.

Mais par défaut, ces GUIDs sont des variables extern, et reçoivent leur valeur depuis un fichier .lib. Et je linkais avec une vieille version. Mystère résolu! La solution est de #define INITGUID avant d'inclure windows.h. Mes remerciements aux forums Ogre3D qui m'ont menée à la page dont j'avais besoin, puisqu'ils avaient rencontré le même problème. À ce stade tout marchait bien, hormis les machines de build automatique.

Étape 4: d3dcompiler

Le premier problème n'était pas tout jeune. Nous avions jusque là, sans nous en rendre compte, supposé que la DLL pour d3dcompiler était présente dans System32! Vu que System32 est dans le chemin de recherche par défaut des DLLs, cette erreur est facile à manquer, tout particulièrement quand l'installation du SDK DirectX est un prérequis pour les développeurs. Nous dépendions à présent d'une version plus récente, en théorie incluse dans le SDK Windows. Pourtant ça ne marchait pas... car nous n'avions pas de phase d'installation pour DirectX. Je suis retournée dans les fichiers de génération des projets, et ai ajouté une phase de copie pour cette DLL. Pourtant, les machines de build râlaient toujours.

Étape 5: XInput

XInput est disponible en plusieurs versions dans le SDK Windows. 1.4 est la plus récente au moment où j'écris, et est réservée à Windows 8. Pour utiliser XInput sous Windows 7, il faut utiliser la version 9.1.0. La première étape est de s'assurer que la define magique _WIN32_WINNT reçoit la bonne valeur (voir plus haut sur la page en lien). Il faut aussi linker explicitement avec XInput9_1_0.lib et non XInput.lib, sans quoi Windows 7 crashera à l'exécution en tentant de lire XInput1_4.dll, qui n'existe pas sous Windows 7. Dans mon cas, c'est ce qui cassait les tests automatiques sur des machines Windows 7, mais marchait parfaitement sur ma machine Windows 8.

Étape 6: Champagne?

Pour le moment cela semble être tout, mais l'équipe rendering n'a pas encore commencé à pousser les limites. On verra bien ce qui casse quand ils commencent à jouer avec :)

J'espère que cela vous économise un peu de temps si vous faites une mise à jour similaire, ou vous a convaincu de tenter le coup si vous hésitiez.

Mettre à jour WordPress: traduction difficile

Aujourd'hui, j'ai mis à jour WordPress. J'ai également été relativement malpolie sur Twitter, et bien entendu les deux sont liés. Cet article aidera peut-être d'autres malheureux.

La traduction de WordPress est apparement basée sur des chaînes de caractères en dur dans le code, listées dans un fichier .pot avec les noms de fichiers et les numéros de ligne, et ensuite traduites via un fichier .mo et .po. Le fichier .mo est apparement un format binaire quelconque, le .po est similaire au .pot mais avec les traductions.

Et donc, où est le souci? J'utilise le thème Twenty Eleven, car il est simple, il était inclus et je l'aime bien. Raisonnable. Mais ses fichiers de traduction étaient anciennement inclus dans WordPress lui-même. Ceci a (de façon très juste) été jugé peu satisfaisant, et ces fichiers ont été déplacés vers un dossier languages dans le thème lui-même... en tout cas, pour les thèmes récents. Twenty Eleven, étant plus ancien, n'a pas été mis à jour: les fichiers sont simplement manquants. Résultat, comme vous pouvez le constater, la version française de mon site dit tout de même "Posted on".

Une solution est de trouver les fichier de language et de les ajouter, mais une bonne heure de recherche n'a rien donné pour moi. Les fichiers existent dans les versions plus anciennes de WordPress en français, mais ne sont pas compatibles. Puisqu'ils incluent les numéros de lignes du code, ce n'est pas vraiment surprenant! J'ai tenté de mettre à jour lesdits numéros de ligne dans le fichier .po, mais ça ne fonctionnait toujours pas.

Au final j'ai décidé que je pouvais survivre avec ce mélange bizarre. Je n'ai pas le temps ou l'énergie de contourner une conception très moyenne, et changer tout mon thème juste à cause de ce problème semble un peu excessif.

Un autre problème avec la mise à jour est que mon plugin de traduction, qTranslate, n'était plus compatible. Le développement est apparement abandonné, mais heureusement mqTranslate, un fork avec des fonctionnalités pour équipes, a récupéré le flambeau. Il inclut une fonction de conversion de la base de données, et la transition n'a globalement pas posé de problème! J'ai juste dû réactiver le Français et régler l'utilisation des formats de date.

Du x86 sur un système 64-bit avec Scons et MSVC

Comme mentionné précédemment, je suis en train de tenter de me mettre à DirectX 11. Histoire de varier, j’ai choisi la difficulté en n’utilisant pas Visual Studio, mais Sublime Text et Scons. Le tout avec le compilateur MSVC puisque les headers DX11 ne sont pas compatibles avec MinGW (du moins pas "out of the box").

Arrive le moment de linker avec d3d11.lib et autre. Et ... erreur. Impossible de trouver le symbole D3D11CreateDeviceAndSwapChain. Pourtant j’ai bien importé la librairie, bien set LIBPATH pour pointer sur le répertoire x86 ...

Certes. Mais par défaut, Scons utilise la version de MSVC correspondant au système hôte. Donc 64 bit dans mon cas. La solution est d’ajouter TARGET_ARCH='x86' dans l’appel au constructeur de Environment : l’ajouter ensuite par Append n’a pas d’effet.

Sublime Text 2 et SCons

Bon, autant poster ça quelque part au cas où ça aide quelqu'un, et histoire de ne pas l'oublier.

To the point. Un de mes amis (demoscener connu sous le pseudonyme d'xtrium, déjà mentionné sur ce site) travaille sur un moteur 3D, et puisque je vais donner un coup de main il faut bien compiler le projet. Il se sert de SConscript, je voulais tester Sublime Text sans utiliser la "superbe" console Windows. Donc, build personnalisé dans Sublime Text.

Pour ceux qui diront "Installe Linux" ?", je suis plus à l'aise sous Windows et j'aime mes logiciels habituels. Donc, pas de manchot ;)

Bref, voici le fichier sublime-build que j'ai ajouté dans le répertoire Packages/Users pour avoir un système de build SCons. Il se peut que l'encodage ne marche pas sur votre système, je me suis contenté de le faire fonctionner chez moi et n'ai pas cherché plus loin.

{
    "cmd": ["scons.bat"],
    "file_regex": "^(..[^:]*):([0-9]+):?([0-9]+)?:? (.*)$",
    "working_dir": "${project_path:${folder}}",
    "encoding": "cp1252"
}

La première ligne appelle l'exécutable SCons, et part de l'hypothèse que le dossier le contenant est dans le path.

La deuxième permet d'aller à la ligne coupable en double-cliquant sur un message d'erreur. Celle-ci ne fonctionne que pour GCC, j'en ai posté une pour Visual C++ ci-dessous.

La troisième paramètre le répertoire courant durant l'exécution de SCons, et part de l'hypothèse que les SConscripts sont dans le même dossier que le projet Sublime Text.

Quand à la quatrième ligne, elle supprime l'erreur [Decode error - output is not utf-8], du moins sur ma machine (Win7 64 bit, français). Je ne promets rien pour la vôtre.

En espérant que ça serve à quelqu'un !

Edit : Les headers DX11 refusant de compiler avec GCC, j'ai modifié mon environnement Scons pour utiliser Visual C++. Bien sûr, cela change le format du message d'erreur. Voilci donc la nouvelle expression régulière (pas de garantie sur la rigidité) que j'ai utilisée :

"file_regex": "^([^(]+)\\(([0-9]+)\\)() : (.*)$"