Résolution des problèmes (Direct3D 9)

Cette rubrique répertorie les catégories courantes de problèmes que vous pouvez rencontrer lors de l’écriture d’applications Direct3D, et comment les éviter.

Création d’appareils

Si votre application échoue lors de la création de l’appareil, case activée pour les erreurs courantes suivantes.

• Veillez à case activée les fonctionnalités de l’appareil, en particulier les profondeurs de rendu.
• Examinez le code d’erreur. D3DERR_OUTOFVIDEOMEMORY est toujours possible.
• Utilisez les bibliothèques de liens dynamiques DirectX (DLL) de débogage et passez en revue les messages de sortie sous le débogueur.

Utilisation de sommets lumineux

Les applications qui utilisent des sommets allumés doivent désactiver le moteur d’éclairage Direct3D en définissant l’état de rendu D3DRS_LIGHTING sur FALSE. Par défaut, lorsque l’éclairage est activé, le système définit la couleur de tout sommet qui ne contient pas de vecteur normal sur 0 (noir), même si le vertex d’entrée contenait une valeur de couleur différente de zéro. Étant donné que les sommets lumineux ne contiennent pas, par nature, une normale de vertex, toutes les informations de couleur transmises à Direct3D sont perdues pendant le rendu si le moteur d’éclairage est activé.

De toute évidence, la couleur de vertex est importante pour toute application qui effectue son propre éclairage. Pour empêcher le système d’imposer les valeurs par défaut, veillez à définir D3DRS_LIGHTING sur FALSE.

Si votre application s’exécute mais que rien n’est visible, case activée pour les erreurs courantes suivantes.

• Assurez-vous que vos triangles ne sont pas dégénérés.
• Assurez-vous que vos triangles ne sont pas abattus.
• Assurez-vous que vos transformations sont cohérentes en interne.
• Vérifiez les paramètres de la fenêtre d’affichage pour vous assurer qu’ils permettent à vos triangles d’être visibles.

Débogage

Le débogage d’une application Direct3D peut être difficile. Essayez les techniques suivantes, en plus de vérifier toutes les valeurs de retour, un conseil particulièrement important dans la programmation Direct3D, qui dépend d’implémentations matérielles très différentes.

• Basculez vers les DLL de débogage.
• Forcez un appareil logiciel uniquement, désactivant l’accélération matérielle même lorsqu’il est disponible.
• Forcer les surfaces dans la mémoire système.
• Créez une option à exécuter dans une fenêtre afin de pouvoir utiliser un débogueur intégré.

Les deuxième et troisième options de cette liste peuvent vous aider à éviter le verrou Win16, ce qui peut entraîner le blocage de votre débogueur.

Essayez également d’ajouter les entrées suivantes à Win.ini.

[Direct3D] 
debug=3 
[DirectDraw] 
debug=3 

Initialisation Floating-Point Borland

Les compilateurs de Borland signalent des exceptions à virgule flottante d’une manière incompatible avec Direct3D. Pour résoudre ce problème, incluez un gestionnaire d’exceptions _matherr comme suit :

// Borland floating point initialization 
#include <math.h>
#include <float.h>

void initfp(void)
{
    // Disable floating point exceptions
    _control87(MCW_EM,MCW_EM);
}

int _matherr(struct _exception  *e)
{
    e;               // Dummy reference to catch the warning
    return 1;        // Error has been handled
}

Validation des paramètres

Pour des raisons de performances, la version de débogage du mode immédiat Direct3D effectue plus de validation des paramètres que la version commerciale, qui n’effectue parfois aucune validation du tout. Cela permet aux applications d’effectuer un débogage robuste avec le composant d’exécution de débogage plus lent avant d’utiliser la version commerciale plus rapide pour le réglage des performances et la version finale.

Bien que plusieurs méthodes Direct3D Immediate Mode imposent des limites sur les valeurs qu’elles peuvent accepter, ces limites ne sont souvent vérifiées et appliquées que par la version de débogage du temps d’exécution du mode immédiat Direct3D. Les applications doivent être conformes à ces limites, ou des résultats imprévisibles et indésirables peuvent se produire lors de l’exécution sur la version commerciale de Direct3D. Par exemple, la méthode IDirect3DDevice9::D rawPrimitive accepte un paramètre (PrimitiveCount) qui indique le nombre de primitives que la méthode rendra. La méthode peut accepter uniquement des valeurs comprises entre 0 et D3DMAXNUMPRIMITIVES. Dans la version de débogage de Direct3D, si vous passez plus de primitives D3DMAXNUMPRIMITIVES, la méthode échoue correctement, l’impression d’un message d’erreur dans le journal des erreurs et le retour d’une valeur d’erreur à votre application. À l’inverse, si votre application émet la même erreur lorsqu’elle s’exécute avec la version commerciale de l’exécution, le comportement n’est pas défini. Pour des raisons de performances, la méthode ne valide pas les paramètres, ce qui entraîne un comportement imprévisible et complètement situationnel lorsqu’ils ne sont pas valides. Dans certains cas, l’appel peut fonctionner, et dans d’autres cas, il peut provoquer une erreur de mémoire dans Direct3D. Si un appel non valide fonctionne de manière cohérente avec une configuration matérielle particulière et une version de DirectX, il n’y a aucune garantie qu’il continuera à fonctionner sur d’autres matériels ou avec des versions ultérieures de DirectX.

Si votre application rencontre des échecs inexpliqués lors de l’exécution avec le fichier d’exécution Direct3D de vente au détail, testez la version de débogage et examinez attentivement les cas où votre application réussit des paramètres non valides. Utilisez l’applet du panneau de configuration DirectX, basculez vers le runtime de débogage si nécessaire et case activée l’option « Arrêt sur D3DError ». Cette option force le runtime à utiliser la méthode Windows DebugBreak afin de forcer l’application à s’arrêter lorsqu’un bogue d’application est détecté.

Rubriques connexes

Conseils de programmation