Concernant les configuration pour le compilateur, c’est tres clair pour moi:

- Le plus haut niveau de warning possible
- Traiter les warning comme des erreurs

Comme ca, rien ne passe et c’est important de rien laisser lorsqu’on programme en equipe.

Apres on peut toujours jouer du pragma pour ignorer certaines erreurs (warning)

Sinon si tu a cocher la case “enable Shader debugging” dans le panneau de control de DirectX. met ce code:

DWORD dwShaderFlags = D3DXFX_NOT_CLONEABLE;
#if defined( DEBUG ) || defined( _DEBUG )
dwShaderFlags |= D3DXSHADER_DEBUG;
#endif
#ifdef DEBUG_VS
dwShaderFlags |= D3DXSHADER_FORCE_VS_SOFTWARE_NOOPT;
#endif
#ifdef DEBUG_PS
dwShaderFlags |= D3DXSHADER_FORCE_PS_SOFTWARE_NOOPT;
#endif

Et c’eset le 5eme paramètre du create effect.

J’espere que ça t’aidera, et si une autre personne à plus évolué je suis prenneur aussi!

Juste une chose, y’a des trucs pour débugguer les shaders sous VS2005 ? Ou même juste avoir du syntax hilightning ? Visual Assist ne le fait pas, je suis obligé d’utiliser FXComposer qui à aussi le bon goût de vérifier la syntaxe.

En tout cas, merci pour ce blog

Un bouquin! C’est pas une mauvaise idée, mais il sera bigrement gros s’il doit donner plein de conseil
Mais avec une couleur bien choisi, il pourrait devenir un nouveau livre de chevet comme le red book!

@Séà-� : tiens ,t là toi aussi

Merci

Les std:string marchent parce que (me semble t-il) crosoft les a intégré dans l’autoexp.dat depuis … VS2005 ! En revanche, dès que tu encapsules la std:string pour faire ta propre class string, ça ne marche plus et il faut bidouiller l’autoexp.dat pour “faire suivre” la variable membre. Ca prend une ligne, encore faut-il savoir laquelle et savoir que c’est dans ce fichier là que ça se passe. En général, on utilise pas directement les std:string. Enfin je dis en général, y’a rien qui nous en empêche, mais disons plutôt que c’est ce que j’ai constaté dans plusieurs studios et autres codes source ça et là. L’encapsulation a ses avantages, notamment pour ajouter des tas de fonctions helpers, voire pour pouvoir changer la taille des strings sur 8 ou 16 bits en un define sur tout le projet.

Le ,hr est pas mal, je l’avais presque oublié, mais faut dire que je l’utilise plus du tout. En fait j’ai une macro du genre DX_DEBUG(hResult) qui fait:

if(FAILED(hResult))\
{\
TRACE(DXGetErrorString(hResult));\
TRACE(DXGetErrorDescription(hResult));\
ASSERT(SUCCEEDED(hResult));\
}

Du coup quand ça échoue, je sais tout de suite pourquoi, pas besoin de jouer du debugger. Ca marche avec n’importe quel HRESULT issu de DirectX.

J’avoue ne pas trop m’embeter avec autoexp.dat, meme si je devrais surement. J’utilise Visual Studio 2005 depuis la premiere BETA (2003 je crois bien) et 2005 affiche peinard les std::string, avant je les utilisais pas hehe

Un peu en annexe, on a aussi usertype.dat mais il merde chez moi et je sais pas pourquoi :(, j’ai les boules car pour les shaders c’est vraiment bien.

Merci pour le ,wm que je connaissais pas! J’ai oublie de parler du ,hr que je connaissais par contre et qui grosso modo fait la meme chose avec les codes HRESULT des fonctions.

Ha le fameux NULL == myvariable, je le sais j’arrive juste pas a l’appliquer, ca me frustre a lire

PS: je serais ravi de pouvoir faire ce que fait Stephane et d’encadrer une classe de programmeurs… ils apprendraient a vitesse grand V

@Ana : c’est plutot 99% du temps meme! Et je prefere que ca soit mon bug, car c’est BIEN PLUS DUR de changer les libs des autres (comme DirectX) hehe

Lorsque je ferrais l’article suivant je parlerai de .map, thread, debugger temps reel… et pourquoi pas comme le suggerait Stephane des aides au debuggage in-game. Mais bon ca sera pas mon prochain post

Concernant l’autoexp.dat, je suis surpris que tu n’aies jamais mis le nez dedans. C’est un truc de base de debug fondamental, principalement pour les std:string, mais il y a d’autres exemples: si tu peux visionner les structures DirectX, c’est parce que le SDK les ajoute dans l’autoexp.dat à l’installation. Un conseil: faire une sauvegarde avant toute modification. Et ça marche sans redémarrer Visual Studio (il faut seulement redémarrer la session de debug et les modifs sont prises en compte à la volée).

Un autre truc qu’on peut faire dans le genre que tu cites “buffer,5″ est “msg.message,wm” où msg est un message windows (de type MSG donc). Ca va tout simplement “traduire” vers le define qui correspond. Par exemple, au lieu de 0×0200, il y aura WM_MOUSEMOVE. Très pratique pour la programmation Windows. Il y a plein d’autres astuces dans ce genre, mais le ,wm est celui que j’utilise le plus souvent.

Un autre truc qu’on ne sait pas souvent: pourquoi rencontre t-on parfois if(0 == var) au lieu du bien plus lisible et logique if(var == 0) ? Au début je me disais “ils font chier à écrire ça comme ça”, surtout que comme par hasard je rencontrais ça surtout dans les exemples du DirectX SDK… En fait c’est pas pour faire chier le monde, c’est pour éviter un des plus vieux et classiques bugs C/C++ (celui qu’on a tous eu au moins une fois et qui est parfois impossible à voir tellement il est évident). if(0 = var) ne compile pas, alors que if(var = 0) compile et… ne fait pas du tout ce que l’on voulait ! Finalement quand j’ai compris ça, je m’y suis mis. C’est une habitude à prendre, oui c’est moins lisible, oui on peut s’en passer, mais oui ça en vaut la peine.

PS: ne crie pas trop fort que Java est un langage d’assistés, tu risques de te faire entendre

Je suis tout à fait d’accord avec Stéphane au niveau des assertions : à utiliser pour les pré/post-conditions (depuis que je le fais, je passe plus de temps à coder qu’à débugger :D).

Je développe la plupart du temps sous linux, les outils sont pas aussi puissants… bah gdb + emacs, ça vaut toujours pas VS. En attendant que je programme sous windows (sous peu normalement!), je révise les règles de base