Forum aux questions sur DirectX

Absolument. La technologie x64 est largement disponible sur le marché. La majorité des nouveaux processeurs vendus au cours des dernières années, et presque toutes les lignes de processeur en développement à partir d’AMD et Intel, sont compatibles x64. Windows XP Professional x64 Edition a introduit la technologie d’activation du système d’exploitation pour x64 publiée en avril 2005. Étant donné que les éditions x64 nécessitent une nouvelle génération de pilotes natifs 64 bits, cette première version était limitée à la distribution OEM.

Avec Windows Vista, les clients sont libres de choisir des éditions 32 bits ou 64 bits lors de l’achat d’ordinateurs Windows, et les licences pour Windows Vista sont valides pour les éditions 32 bits ou 64 bits du système d’exploitation. De plus, de nombreux pilotes 64 bits sont disponibles dans la boîte, et les fabrications d’appareils sont requises pour fournir des pilotes natifs 32 bits et 64 bits dans le cadre du programme de certification Windows.

Tous ces facteurs augmenteront considérablement les déploiements d’éditions 64 bits de Windows. À mesure que les nouveaux ordinateurs commencent à expédier avec plus de 2 Go de RAM physique, l’incitation à utiliser un système d’exploitation 32 bits diminue considérablement en faveur des éditions 64 bits. La technologie soixante-quatre bits prend entièrement en charge le code natif 32 bits, bien que les implémentations natives 64 bits soient requises pour tirer pleinement parti de la nouvelle espace mémoire 64 bits. Chaque application 32 bits doit avoir une compatibilité 64 bits comme condition minimale d’expédition et répondre à cette exigence est une exigence de base pour la compatibilité de Windows Vista. Les incompatibilités proviennent généralement de l’utilisation de code 16 bits conçu pour le système d’exploitation Windows 3.1 ou l’installation de pilotes qui ne sont pas fournis dans les formulaires natifs 32 bits et 64 bits.

Pour plus d’informations sur la technologie 64 bits, consultez la programmation 64 bits pour les développeurs de jeux.

Plus pour deux raisons : performances et ensemble de fonctionnalités.

Si la vitesse minimale du processeur requise pour votre jeu est de 1,2 GHz ou supérieure (ce qui est plus courant pour les titres hautes performances), la grande majorité des ordinateurs éligibles exécutent Windows XP. Au moment où les ordinateurs avec des vitesses de processeur supérieures à 1,2 GHz étaient vendus, Windows XP a été installé comme système d’exploitation par défaut par presque tous les fabricants. Cela signifie qu’il existe de nombreuses fonctionnalités trouvées dans Windows XP que les développeurs de jeux d’aujourd’hui doivent tirer parti de l’inclusion :

• Amélioration de la multitâche , ce qui entraîne une meilleure expérience plus fluide pour la vidéo, l’audio et le jeu.
• Modèle de pilote vidéo plus stable, qui permet un débogage plus facile, un jeu plus fluide et de meilleures performances.
• Configuration plus facile pour la mise en réseau, ce qui permet d’accéder plus facilement aux jeux multi-joueurs.
• Prise en charge des transferts DMA par défaut à partir de disques durs, ce qui entraîne un chargement plus fluide et plus rapide des applications.
• Rapports d’erreurs Windows , qui entraînent un système d’exploitation, des pilotes et des applications plus stables.
• Prise en charge Unicode, ce qui simplifie considérablement les problèmes de localisation.
• Meilleure sécurité et stabilité, ce qui entraîne de meilleures expériences des consommateurs.
• Meilleure prise en charge du matériel moderne : la plupart d’entre elles n’utilisent plus les pilotes Windows 98.
• Amélioration de la gestion de la mémoire, ce qui entraîne une meilleure stabilité et une meilleure sécurité.
• Système de fichiers NTFS amélioré, qui est plus résistant aux défaillances et offre de meilleures performances avec les fonctionnalités de sécurité.

Plus maintenant. Outre les raisons répertoriées dans Les développeurs de jeux doivent-ils toujours publier des jeux pour Windows 95, Windows 98 ou Windows ME ?, Windows 2000 n’a pas ces fonctionnalités :

• Windows XP prend en charge les fonctionnalités avancées du processeur telles que Hyper-Threading, Multi-Core et x64.
• Windows XP prend en charge les composants côte à côte qui réduisent considérablement les conflits de version des applications.
• Windows XP prend en charge la protection de la mémoire sans exécution, ce qui permet d’empêcher les programmes malveillants et de faciliter le débogage.
• Windows XP a amélioré la prise en charge des carte vidéo avancées basées sur AGP et PCI Express.
• Windows XP prend en charge le basculement rapide des utilisateurs, le Bureau à distance et l’assistance à distance, ce qui peut contribuer à réduire les coûts de prise en charge des produits.
• Les outils de performances tels que PIX (dans le Kit de développement logiciel (SDK)) DirectX ne prennent plus en charge Windows 2000.

En bref, Windows 2000 n’a jamais été conçu ou commercialisé en tant que système d’exploitation grand public.

La famille Windows Vista comprend cinq éditions :

• Windows Vista Édition Familiale Basique
• Windows Vista Édition Familiale Premium
• Windows Vista Professionnel
• Windows Vista Entreprise
• Windows Vista Édition Intégrale

Home Basic et Home Premium sont des versions axées sur le consommateur, avec des fonctionnalités telles que Family Safety (anciennement Contrôle parental), et Home Premium inclut Media Center. Les éditions Business et Entreprise sont axées sur l’entreprise, avec des fonctionnalités telles que la jonction de domaine et les services Bureau à distance/Terminal Services. L’édition Intégrale combine toutes les fonctionnalités des éditions consommateur et d’entreprise en une seule version. Toutes les éditions sont fournies dans les éditions 32 bits (x86) et 64 bits (x64), et les utilisateurs sont libres d’utiliser le même identificateur de produit pour les deux plateformes.

La technologie sous-jacente aux différentes éditions est identique, et toutes ont la même version du runtime DirectX et d’autres composants. Toutefois, les éditions présentent quelques différences mineures en ce qui concerne les jeux :

• Games Explorer existe sur toutes les éditions, mais le raccourci Jeux sur le menu Démarrer est uniquement dans Home Basic, Home Premium et Intégrale. L’Explorateur jeux est toujours disponible sur toutes les éditions (en cliquant sur Démarrer, pointant sur Tous les programmes, puis sur Jeux), et les fonctions d’interface IGameExplorer sur toutes les éditions.
• Les jeux inclus dans Windows ne sont pas disponibles par défaut sur Business et Entreprise, mais ils peuvent être activés par l’administrateur.
• Les évaluations de Family Safety et de jeu ne s’affichent pas ou n’ont aucune influence sur le comportement d’entreprise ou d’entreprise, et elles sont désactivées sur Intégrale lorsqu’un domaine est joint.

Les paramètres de contrôle de compte d’utilisateur ont les mêmes valeurs par défaut sur toutes les éditions, mais ils peuvent être remplacés par les paramètres de stratégie de groupe pour le domaine sur Business, Enterprise et Intégrale. Par exemple, le paramètre de stratégie contrôle de compte d’utilisateur : le comportement de l’invite d’élévation pour les utilisateurs standard peut bien être défini pour refuser automatiquement les demandes d’élévation dans de nombreux paramètres métier afin d’améliorer la sécurité, et de nombreux utilisateurs de ces environnements s’exécutent toujours en tant qu’utilisateurs standard sans même choisir d’exécuter en tant qu’Administrateur. Tout programme (tel qu’un programme d’installation) qui requiert des droits d’administration, soit en raison de la détection d’installation héritée, soit d’un manifeste qui spécifie le niveau d’exécution demandé comme « requireAdministrator », ne démarre pas toujours dans de telles situations. D’autres paramètres de stratégie, tels que le contrôle de compte d’utilisateur : élever uniquement les exécutables signés et validés, peuvent également empêcher votre programme d’installation de fonctionner si vous ne signez pas votre fichier exécutable à l’aide d’Authenticode.

Ces types de modifications de stratégie peuvent être appliqués à n’importe quelle édition de Windows Vista, mais sont plus susceptibles sur les ordinateurs joints à un domaine.

La majorité des utilisateurs de Windows 7 auront probablement l’une des deux éditions suivantes : Windows 7 Édition Familiale Premium, pour les utilisateurs domestiques ou Windows 7 Professionnel, pour les utilisateurs professionnels et les développeurs. Pour les grandes entreprises, il existe l’édition Windows 7 Entreprise sous licence en volume, qui inclut toutes les fonctionnalités de Windows 7 ; Windows 7 Édition Intégrale est l’équivalent commercial de cette édition.

Windows 7 Édition Starter est disponible à l’échelle mondiale pour les fabricants OEM, et il est prévu d’être déployé de manière primaire avec des miniportables, des ordinateurs portables ultra-à-faible puissance. Windows 7 Édition Familiale Basique est disponible uniquement sur les marchés émergents.

Notez que toutes les éditions de Windows 7 (à l’exception de Édition Starter) sont disponibles pour les versions 32 bits (x86) et 64 bits (x64), et tous les packages de vente au détail de Windows 7 incluent des supports pour les deux versions. Comme avec Windows Vista, les utilisateurs sont libres d’utiliser le même identificateur de produit de vente au détail sur l’une ou l’autre plateforme.

La technologie sous-jacente dans les différentes éditions est identique, et toutes les éditions ont la même version du runtime DirectX et d’autres composants. Ils ont certaines différences par rapport aux fonctionnalités de jeu :

• Games Explorer existe dans toutes les éditions, mais le raccourci Jeux sur le menu Démarrer est masqué par défaut dans Windows 7 Professionnel et Enterprise. Games Explorer est toujours disponible sur le menu Démarrer (en cliquant sur Tous les programmes, puis en double-cliquant sur Jeux), et le raccourci direct Jeux peut être activé par l’utilisateur.
• Les jeux inclus dans Windows ne sont pas disponibles par défaut sur Windows 7 Professionnel et Entreprise, mais ils peuvent être activés par l’administrateur.
• Family Safety et les évaluations de jeu sont disponibles sur toutes les éditions, mais elles sont désactivées sur Windows 7 Professionnel, Enterprise et Intégrale lorsque le système d’exploitation rejoint un domaine. Comme avec Windows Vista Intégrale, cette fonctionnalité peut être réactivé sur l’ordinateur qui a rejoint un domaine.

Les paramètres de contrôle de compte d’utilisateur (UAC) peuvent être affectés par les paramètres de stratégie de groupe sur les éditions Windows 7 Professionnel, Enterprise et Intégrale, comme Windows Vista. Pour plus d’informations, consultez Quelles sont les différences entre les différentes éditions de Windows Vista ? Comment ont-ils un impact sur mon application DirectX ?

Nombre Windows Vista, qui a DirectX 10, inclut un runtime DirectX mis à jour basé sur le runtime dans Windows XP SP2 (DirectX 9.0c) avec des modifications pour fonctionner avec le nouveau modèle WDDM (Windows Display Driver Model) et la nouvelle pile de pilotes audio, et avec d’autres mises à jour dans le système d’exploitation. En plus de Direct3D 9, Windows Vista prend en charge deux nouvelles interfaces lorsque le matériel vidéo et les pilotes appropriés sont présents : Direct3D9Ex et Direct3D10.

Étant donné que ces nouvelles interfaces s’appuient sur la technologie WDDM, elles ne seront jamais disponibles sur les versions antérieures de Windows. Toutes les autres modifications apportées aux technologies DirectX pour Windows Vista sont également spécifiques à la nouvelle version de Windows. Le nom DirectX 10 est trompeur dans le fait que de nombreuses technologies d’expédition dans le Kit de développement logiciel (SDK) DirectX (XACT, XINPUT, D3DX) ne sont pas comprises par ce numéro de version. Par conséquent, la référence au numéro de version du runtime DirectX dans son ensemble a perdu beaucoup de signification, même pour 9.0c. L’outil de diagnostic DirectX (DXdiag.exe) sur Windows Vista signale DirectX 10, mais cela ne fait vraiment référence qu’à Direct3D 10.

DirectX 11 est intégré à Windows 7 et il est disponible en tant que mise à jour pour Windows Vista (voir https://go.microsoft.com/fwlink/p/?linkid=160189). Cela comprend l’API Direct3D 11, DirectX Graphics Infrastructure (DXGI) 1.1, les niveaux de fonctionnalités 10Level9, le dispositif de rendu logiciel Windows Advanced Rasterization Platform (WARP) 10, Direct2D, DirectWrite, et une mise à jour de l'API Direct3D 10.1 pour prendre en charge 10Level9 et WARP 10.

Pour les mêmes raisons que celles indiquées dans la question précédente (DirectX 10 sera-t-il disponible pour Windows XP ? ), Direct3D 11 et les API associées ne sont pas disponibles sur Windows XP.

DirectShow a été supprimé du Kit de développement logiciel (SDK) DirectX depuis avril 2005. Vous pouvez obtenir les en-têtes, les bibliothèques, les outils et les exemples pour DirectShow dans le Kit de développement logiciel Windows (anciennement appelé SDK de plateforme). DirectSetup dans le Kit de développement logiciel (SDK) DirectX continue de prendre en charge la redistribution des composants système de DirectShow, et les derniers composants sont déjà installés sur les systèmes d’exploitation suivants : Microsoft Windows XP Service Pack 2, Windows XP Professional x64 Edition, Windows Server 2003 Service Pack 1 et Windows Vista.

Les modifications principales ont été apportées pour prendre en charge le nouveau WDDM. Pour plus d’informations sur le nouveau modèle de pilote, sur les impacts sur Direct3D 9 et sur les deux nouvelles interfaces graphiques, Direct3D 9Ex et Direct3D 10, consultez les API Graphiques dans Windows. Les nouvelles API graphiques pour Windows 7 (Direct3D 11, Direct2D, DirectWrite, DXGI 1.1 et Direct3D 10.1 mis à jour ) sont disponibles sous forme de mise à jour pour Windows Vista (voir https://go.microsoft.com/fwlink/p/?linkid=160189).

Windows Vista Service Pack 1 inclut une version mise à jour du runtime DirectX. Cette mise à jour étend la prise en charge de Windows Vista pour inclure Direct3D 10.1, exposant de nouvelles fonctionnalités matérielles facultatives. (Tout le matériel capable de prendre en charge Direct3D 10.1 prend également entièrement en charge toutes les fonctionnalités de Direct3D 10.)

DirectSound a été mis à jour pour exposer les fonctionnalités de la nouvelle pile de pilotes audio Windows Vista, qui prend en charge les mémoires tampons logicielles multicanal. L’API en mode conservé Direct3D a été complètement supprimée de Windows Vista. DirectPlay Voice a également été supprimé, ainsi que l’interface utilisateur d’action-mappeur NAT de DirectPlay et DirectInput. La prise en charge des interfaces DirectX 7 et DirectX 8 pour Visual Basic 6.0 n’est pas disponible sur Windows Vista.

Windows 7 inclut tous les composants du runtime DirectX trouvés dans Windows Vista et ajoute Direct3D 11, DXGI 1.1, 10Level9, l’appareil logiciel WARP10, Direct2D, DirectWrite et une mise à jour vers Direct3D 10.1 pour prendre en charge 10Level9 et WARP10. Pour plus d’informations, consultez les API Graphics dans Windows.

Tous les autres composants sont identiques à Windows Vista, avec l’ajout de la prise en charge native 64 bits (x64) de l’API DirectMusic principale liée au MIDI horodaté. La couche de performances de DirectMusic reste déconseillée et elle est disponible uniquement pour les applications 32 bits sur Windows 7 pour la compatibilité des applications. Notez que la prise en charge native 64 bits de DirectMusic n’est pas disponible sur Windows Vista.

Tout d’abord, vérifiez que vous avez vérifié les résultats avec le module de rastérisation de référence. Vérifiez ensuite les résultats avec la dernière version certifiée WHQL du pilote IHVS. Vous pouvez vérifier par programmation l’état WHQL à l’aide de la méthode GetAdapterIdentifier() sur l’interface IDirect3D9 en passant l’indicateur D3DENUM_WHQL_LEVEL.

Vous ne disposez probablement pas correctement de votre chemin d’accès Inclure. De nombreux compilateurs, y compris Microsoft Visual C++, incluent une version antérieure du Kit de développement logiciel (SDK). Par conséquent, si votre chemin d’accès inclut les répertoires du compilateur standard, vous obtiendrez d’abord des versions incorrectes des fichiers d’en-tête. Pour résoudre ce problème, vérifiez que le chemin d’accès et les chemins de bibliothèque inclure sont définis pour rechercher d’abord les chemins d’accès Microsoft DirectX inclure et bibliothèque. Consultez également le fichier dxreadme.txt dans le Kit de développement logiciel (SDK). Si vous installez le Kit de développement logiciel (SDK) DirectX et que vous utilisez Visual C++, le programme d’installation peut éventuellement configurer les chemins d’accès inclure pour vous.

Les différents GUID que vous utilisez doivent être définis une seule et unique fois. La définition du GUID est insérée si vous #définissez le symbole INITGUID avant d’inclure les fichiers d’en-tête DirectX. Par conséquent, vous devez vous assurer que cela se produit uniquement pour une unité de compilation. Une alternative à cette méthode consiste à établir un lien avec la bibliothèque dxguid.lib, qui contient des définitions pour tous les GUID DirectX. Si vous utilisez cette méthode (qui est recommandée), vous ne devez jamais #définir le symbole INITGUID.

Nombre Les interfaces DirectX sont des interfaces COM. Cela signifie qu’il n’est pas nécessaire que les interfaces numérotées supérieures soient dérivées des interfaces numérotées correspondantes. Par conséquent, le seul moyen sûr d’obtenir une autre interface à un objet DirectX consiste à utiliser la méthode QueryInterface de l’interface. Cette méthode fait partie de l’interface IUnknown standard, à partir de laquelle toutes les interfaces COM doivent dériver.

Vous pouvez combiner librement différents composants de la version différente ; par exemple, vous pouvez utiliser DirectInput 8 avec Direct3D 9 dans la même application. Toutefois, vous ne pouvez généralement pas combiner différentes versions du même composant au sein de la même application ; par exemple, vous ne pouvez pas combiner DirectDraw 7 avec Direct3D 9 (car il s’agit effectivement du même composant que DirectDraw a été subsumé dans Direct3D à partir de DirectX 8). Toutefois, il existe des exceptions, telles que l’utilisation de Direct3D 9 et Direct3D 10 dans la même application, qui est autorisée.

Oui, vous pouvez utiliser ces versions de Direct3D ensemble dans la même application.

La valeur de retour correspond au nombre de références actuel de l’objet. Toutefois, la spécification COM indique que vous ne devez pas vous appuyer sur cela et que la valeur est généralement disponible uniquement à des fins de débogage. Les valeurs que vous observez peuvent être inattendues, car d’autres objets système peuvent contenir des références aux objets DirectX que vous créez. Pour cette raison, vous ne devez pas écrire de code qui appelle à plusieurs reprises Libérer jusqu’à ce que le nombre de références soit égal à zéro, car l’objet peut ensuite être libéré même si un autre composant peut toujours le référencer.

Cela ne doit pas être important, car les interfaces COM sont comptabilisées. Toutefois, il existe certains bogues connus avec l’ordre de publication des interfaces dans certaines versions de DirectX. Pour plus de sécurité, vous êtes invité à libérer des interfaces dans l’ordre de création inverse lorsque cela est possible.

Un pointeur intelligent est une classe de modèle C++ conçue pour encapsuler les fonctionnalités de pointeur. En particulier, il existe des classes de pointeur intelligente standard conçues pour encapsuler des pointeurs d’interface COM. Ces pointeurs effectuent automatiquement QueryInterface au lieu d’un cast et gèrent AddRef et Libérer pour vous. Que vous deviez les utiliser ou non est en grande partie une question de goût. Si votre code contient beaucoup de copie de pointeurs d’interface, avec plusieurs AddRefs et versions, les pointeurs intelligents peuvent probablement rendre votre code moins susceptible d’entraîner des erreurs. Sinon, vous pouvez le faire sans eux. Visual C++ inclut un pointeur intelligent Microsoft COM standard, défini dans le fichier d’en-tête « comdef.h » (recherchez com_ptr_t dans l’aide).

Le problème le plus courant lors du débogage d'applications DirectX est la tentative de débogage alors qu'une surface DirectDraw est verrouillée. Cette situation peut entraîner un « verrouillage Win16 » sur les systèmes Microsoft Windows 9x, ce qui empêche la fenêtre du débogueur de peindre. La spécification de l’indicateur de D3DLOCK_NOSYSLOCK lors du verrouillage de la surface peut généralement l’éliminer. Windows 2000 ne souffre pas de ce problème. Lors du développement d’une application, il est utile d’exécuter avec la version de débogage du runtime DirectX (sélectionnée lorsque vous installez le Kit de développement logiciel (SDK)), qui effectue une validation de paramètre et génère des messages utiles pour la sortie du débogueur.

Utilisez les macros SUCCEEDED et FAILED. Les méthodes DirectX peuvent retourner plusieurs codes de réussite et d’échec, donc un simple :

== D3D_OK

ou un test similaire ne suffit pas toujours.

Il n’y en a pas ! Les jeux doivent être en mesure de gérer le changement de tâche correctement, car de nombreuses choses l’entraînent : ALT+TAB, connexions bureau à distance, changement rapide d'utilisateur, limites d’utilisation du contrôle parental et bien d’autres événements.

En même temps, deux sources courantes de basculement de tâches accidentelles sur des jeux avec des schémas de contrôle centrés sur le clavier sont appuyer sur la touche de logo Windows et activer la fonctionnalité d’accessibilité StickyKeys avec la touche Maj. Pour résoudre ces cas en désactivant les fonctionnalités, consultez les techniques décrites dans Désactivation des touches de raccourci dans Jeux.

Inside COM par Dale Rogerson, publié par Microsoft Press, est une excellente introduction à COM. Pour une présentation plus détaillée de COM, le livre Essential COM by Don Box, publié par Longman, est également fortement recommandé.

Le code managé est du code qui a son exécution gérée par le Common Language Runtime (CLR) du .NET Framework. Il fait référence à un contrat de coopération entre l’exécution native du code et le runtime. Ce contrat spécifie qu’à tout moment de l’exécution, le runtime peut arrêter un processeur en cours d’exécution et récupérer des informations spécifiques à l’adresse d’instruction de l’UC actuelle. Les informations qui doivent être en mesure d’effectuer des requêtes se rapportent généralement à l’état d’exécution, telles que le contenu de l’inscription ou de la mémoire de la pile.

Avant l’exécution du code, le niveau d'intégrité est compilé en code exécutable natif. Et, étant donné que cette compilation se produit par l’environnement d’exécution managé (ou, plus correctement, par un compilateur prenant en charge le runtime qui sait comment cibler l’environnement d’exécution managé), l’environnement d’exécution managée peut garantir ce que le code va faire. Il peut insérer des interruptions et des hooks de collection de déchets appropriés, la gestion des exceptions, la sécurité des types, les limites de tableau et la vérification d’index, etc. Par exemple, un tel compilateur s'assure que les frames de pile et tout le reste sont bien disposés afin que le collecteur de déchets puisse fonctionner en arrière-plan sur un thread séparé, en parcourant constamment la pile d'appels active, en trouvant toutes les racines, en chassant tous les objets vivants. En outre, puisque le niveau d'intégrité a une notion de sécurité de type, le moteur d’exécution maintient la garantie de sécurité de type éliminant toute une classe d’erreurs de programmation qui mènent souvent à des trous de sécurité.

Contrairement au monde non managé : les fichiers exécutables non managés sont essentiellement une image binaire, du code x86, chargé en mémoire. Le compteur de programme est placé à cet endroit et c'est la dernière chose que le système d'exploitation sait. Il existe des protections en place autour de la gestion de la mémoire et des E/S de port, et ainsi de suite, mais le système ne sait pas réellement ce que l’application fait. Par conséquent, il ne peut pas garantir ce qui se passe quand l’application s’exécute.

Beaucoup. Toutefois, les deux qui sont fortement recommandées sont les suivantes :

• Programmation de Windows par Charles Petzold (Microsoft Press)
• Programmation d’applications pour Windows par Jeffrey Richter (Microsoft Press)

Microsoft publie des symboles supprimés pour toutes les DLL système (plus quelques autres). Pour y accéder, ajoutez les éléments suivants à votre chemin de symbole dans les paramètres du projet dans Visual Studio :

srv*https://msdl.microsoft.com/download/symbols

pour la mise en cache des symboles localement, utilisez la syntaxe suivante :

srv*c:\cache*https://msdl.microsoft.com/download/symbols

Où c :\cache est un répertoire local pour la mise en cache des fichiers de symboles.

Questions Direct3D

Questions générales sur Direct3D

Le livre standard sur le sujet est Computer Graphics : Principles and Practice by Foley, Van Dam et al. Il s’agit d’une ressource précieuse pour toute personne souhaitant comprendre les fondements mathématiques de la géométrie, de la rastérisation et des techniques d’éclairage. Le FAQ pour le groupe Comp.graphics.algorithms Usenet contient également des éléments utiles.

Cela dépend. Direct3D dispose d’un pipeline de traitement de vertex logiciels complet (y compris la prise en charge des nuanceurs de vertex personnalisés). Toutefois, aucune émulation n’est fournie pour les opérations de niveau pixel ; les applications doivent vérifier les bits de limite appropriés et utiliser l’API ValidateDevice pour déterminer la prise en charge.

Non pour les applications de performances. Un module de rastérisation de référence est fourni pour la validation du pilote, mais l’implémentation est conçue pour la précision et non pour les performances. Direct3D prend en charge les rastériseurs logiciels de plug-in.

La touche de couleur n’est pas directement prise en charge, au lieu de cela, vous devez utiliser le mélange alpha pour émuler la touche de couleur. La fonction D3DXCreateTextureFromFileEx() peut être utilisée pour faciliter cette opération. Cette fonction accepte un paramètre de couleur clé et remplace tous les pixels de l’image source contenant la couleur spécifiée par des pixels noirs transparents dans la texture créée.

Oui. Le pipeline géométrie Direct3D a plusieurs chemins de code différents, en fonction du type de processeur, et il utilisera les opérations spéciales à virgule flottante fournies par le 3DNow ! ou les instructions SIMD Pentium III où elles sont disponibles. Cela inclut le traitement des nuanceurs de vertex personnalisés.

Vous pouvez filtrer les pixels avec une valeur alpha supérieure ou inférieure à un seuil donné. Vous contrôlez ce comportement à l’aide des renderstates ALPHATESTENABLE, ALPHAREF et ALPHAFUNC.

Un tampon stencil buffer est une mémoire tampon supplémentaire d’informations par pixel, comme tampon z-buffer. En fait, il réside dans certains des bits d’un tampon z-buffer. Les formats stencil/z-buffer courants sont des gabarits 15 bits z et 1 bits, ou 24 bits z et 8 bits. Il est possible d’effectuer des opérations arithmétiques simples sur le contenu du tampon stencil buffer sur une base par pixel, car les polygones sont rendus. Par exemple, le tampon stencil buffer peut être incrémentée ou décrémentée, ou le pixel peut être rejeté si la valeur du gabarit échoue à un test de comparaison simple. Cela est utile pour les effets qui impliquent de marquer une région de la mémoire tampon d’images, puis d’effectuer le rendu uniquement de la région marquée (ou non marquée). De bons exemples sont des effets volumétriques comme les volumes d’ombre.

La clé de cet effet et d'autres effets volumétriques du tampon stencil buffer est l'interaction entre le tampon stencil buffer et le tampon z-buffer. Une scène avec un volume d’ombres est rendue en trois étapes. Tout d’abord, la scène sans l’ombre est rendue comme d’habitude, à l’aide du tampon z-buffer. Ensuite, l’ombre est marquée dans le tampon stencil buffer comme suit. Les visages avant du volume d’ombre sont dessinés à l’aide de polygones invisibles, avec z-testing activé, mais les écritures z désactivées et le tampon stencil buffer incrémenté à chaque pixel passant le test z. Les faces arrière du volume d’ombre sont rendues de la même façon, mais décrémentant la valeur du gabarit à la place.

À présent, considérez un pixel unique. En supposant que la caméra n’est pas dans le volume d’ombre, il existe quatre possibilités pour le point correspondant dans la scène. Si le rayon de la caméra jusqu’au point ne croise pas le volume d’ombre, aucun polygone d’ombre n’a été dessiné là et le tampon stencil buffer est toujours égal à zéro. Sinon, si le point se trouve devant le volume d’ombre, les polygones d’ombre sont mis en mémoire avec tampon z-buffer et le stencil reste inchangé. Si les points se trouvent derrière le volume de l’ombre, le même nombre de visages d’ombre avant que les visages arrières ont été rendus et le stencil sera égal à zéro, ayant été incrémenté autant de fois que décrémenté.

La dernière possibilité est que le point se trouve à l’intérieur du volume d’ombre. Dans ce cas, le visage arrière du volume d’ombre est mis en mémoire tampon z-buffer, mais pas le visage avant, de sorte que le tampon stencil buffer sera une valeur non nulle. Le résultat est une partie du tampon de trame qui se trouve dans l’ombre avec une valeur de stencil non nulle. Enfin, pour afficher réellement l’ombre, la scène entière est nettoyée avec un polygone alpha mélangé défini pour affecter uniquement les pixels avec une valeur de stencil non nulle. Vous trouverez un exemple de cette technique dans l’exemple « Shadow Volume » fourni avec le Kit de développement logiciel (SDK) DirectX.

Cela est expliqué entièrement dans la documentation Direct3D 9. Toutefois, le résumé exécutif est que vous devez biaiser vos coordonnées d’écran de -0,5 d’un pixel pour s’aligner correctement avec les texels. La plupart des cartes se conforment désormais correctement aux règles d’alignement du texel, mais il existe des cartes ou des pilotes plus anciens qui ne le font pas. Pour gérer ces cas, le meilleur conseil consiste à contacter le fournisseur de matériel en question et à demander des pilotes mis à jour ou leur solution de contournement suggérée. Notez que dans Direct3D 10, cette règle ne contient plus.

Utilisez l’indicateur D3DCREATE_PUREDEVICE lors de la création de l’appareil pour créer un appareil pur. Un appareil pur n’enregistre pas l’état actuel (pendant les modifications d’état), ce qui améliore souvent les performances ; cet appareil nécessite également un traitement de vertex matériel. Un appareil pur est généralement utilisé lorsque le développement et le débogage sont terminés, et vous souhaitez obtenir les meilleures performances.

L’un des inconvénients d’un appareil pur est qu’il ne prend pas en charge tous les appels d’API Get* ; cela signifie que vous ne pouvez pas utiliser un appareil pur pour interroger l’état du pipeline. Cela rend plus difficile le débogage lors de l’exécution d’une application. Vous trouverez ci-dessous la liste de toutes les méthodes désactivées par un appareil pur.

• IDirect3DDevice9::GetClipPlane
• IDirect3DDevice9::GetClipStatus
• IDirect3DDevice9::GetLight
• IDirect3DDevice9::GetLightEnable
• IDirect3DDevice9::GetMaterial
• IDirect3DDevice9::GetPixelShaderConstantF
• IDirect3DDevice9 ::GetPixelShaderConstantI
• IDirect3DDevice9::GetPixelShaderConstantB
• IDirect3DDevice9::GetRenderState
• IDirect3DDevice9::GetSamplerState
• IDirect3DDevice9::GetTextureStageState
• IDirect3DDevice9::GetTransform
• IDirect3DDevice9::GetVertexShaderConstantF
• IDirect3DDevice9::GetVertexShaderConstantI
• IDirect3DDevice9::GetVertexShaderConstantB

Un deuxième inconvénient d’un appareil pur est qu’il ne filtre pas les modifications d’état redondantes. Lorsque vous utilisez un appareil pur, votre application doit réduire au minimum le nombre de modifications d’état dans la boucle de rendu ; cela peut inclure le filtrage des modifications d’état pour vous assurer que les états ne sont pas définis plusieurs fois. Ce compromis dépend de l’application ; si vous utilisez plus de 1 000 appels définis par trame, vous devez envisager de tirer parti du filtrage de redondance effectué automatiquement par un appareil non pur.

Comme pour tous les problèmes de performances, la seule façon de savoir si votre application fonctionne mieux avec un appareil pur consiste à comparer les performances de votre application avec un appareil pur et non pur. Un appareil pur peut accélérer une application en réduisant la surcharge du processeur de l’API. Mais soyez prudent ! Pour certains scénarios, un appareil pur ralentit votre application (en raison du travail supplémentaire du processeur provoqué par des modifications d’état redondantes). Si vous ne savez pas quel type d’appareil fonctionne le mieux pour votre application et que vous ne filtrez pas les modifications redondantes dans l’application, utilisez un appareil non pur.

L’énumération peut être effectuée via une itération simple par l’application à l’aide de méthodes de l’interface IDirect3D9. Appelez GetAdapterCount pour déterminer le nombre d’adaptateurs d’affichage dans le système. Appelez GetAdapterMonitor pour déterminer le moniteur physique auquel une carte est connectée (cette méthode retourne un HMONITOR, que vous pouvez ensuite utiliser dans l’API Win32 GetMonitorInfo pour déterminer les informations sur le moniteur physique). La détermination des caractéristiques d’une carte d’affichage particulière ou la création d’un appareil Direct3D sur cette carte est aussi simple que de passer le numéro d’adaptateur approprié à la place de D3DADAPTER_DEFAULT lors de l’appel de GetDeviceCaps, CreateDevice ou d’autres méthodes.

À partir de Direct3D 9, nous avons renforcé la validation sur les cartes qui ne pouvaient prendre en charge que > 2 textures simultanées. Certaines cartes plus anciennes n’ont que 3 étapes de texture disponibles lorsque vous utilisez une opération alpha modulante spécifique. L’utilisation la plus courante pour laquelle les utilisateurs utilisent les 3 étapes est emboss bumpmapping, et vous pouvez toujours le faire avec D3D9.

Le champ de hauteur doit être stocké dans le canal alpha et est utilisé pour moduler la contribution des lumières, c’est-à-dire :

// Stage 0 is the base texture, with the height map in the alpha channel
m_pd3dDevice->SetTexture(0, m_pEmbossTexture );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_TEXCOORDINDEX, 0 );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLOROP,   D3DTOP_MODULATE );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_DIFFUSE );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_ALPHAOP,   D3DTOP_SELECTARG1 );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE );
if( m_bShowEmbossMethod )
{
 // Stage 1 passes through the RGB channels (SELECTARG2 = CURRENT), and 
 // does a signed add with the inverted alpha channel. 
 // The texture coords associated with Stage 1 are the shifted ones, so 
 // the result is:
 //    (height - shifted_height) * tex.RGB * diffuse.RGB
   m_pd3dDevice->SetTexture( 1, m_pEmbossTexture );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_TEXCOORDINDEX, 1 );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_COLOROP, D3DTOP_SELECTARG2 );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_COLORARG1, D3DTA_TEXTURE );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_COLORARG2, D3DTA_CURRENT );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_ALPHAOP, D3DTOP_ADDSIGNED );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_ALPHAARG1, D3DTA_TEXTURE|D3DTA_COMPLEMENT );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_ALPHAARG2, D3DTA_CURRENT );

   // Set up the alpha blender to multiply the alpha channel 
   // (monochrome emboss) with the src color (lighted texture)
   m_pd3dDevice->SetRenderState( D3DRS_ALPHABLENDENABLE, TRUE );
   m_pd3dDevice->SetRenderState( D3DRS_SRCBLEND,  D3DBLEND_SRCALPHA );
   m_pd3dDevice->SetRenderState( D3DRS_DESTBLEND, D3DBLEND_ZERO );
}

Cet exemple, ainsi que d’autres exemples plus anciens, ne sont plus expédiés dans la version actuelle du Kit de développement logiciel (SDK) et ne seront pas expédiés dans les futures versions du SDK.

Traitement géométrie (vertex)

Direct3D assemble chaque vertex qui est alimenté dans la partie de traitement du pipeline à partir d’un ou plusieurs flux de vertex. Avoir un seul flux de vertex correspond à l’ancien modèle pré-DirectX 8, dans lequel les sommets proviennent d’une seule source. Avec DirectX 8, différents composants de vertex peuvent provenir de différentes sources ; par exemple, un tampon vertex peut contenir des positions et des normales, tandis qu’une seconde contient des valeurs de couleur et des coordonnées de texture.

Un nuanceur de vertex est une procédure permettant de traiter un seul sommet. Il est défini à l’aide d’un langage de type assembly simple qui est assemblé par la bibliothèque utilitaire D3DX dans un flux de jetons accepté par Direct3D. Le nuanceur de vertex prend comme entrée un seul sommet et un ensemble de valeurs constantes ; il génère une position de vertex (dans l’espace clip) et éventuellement un ensemble de couleurs et de coordonnées de texture, qui sont utilisées dans la rastérisation. Notez que lorsque vous disposez d’un nuanceur de vertex personnalisé, les composants de vertex n’ont plus de sémantiques appliquées par Direct3D et les sommets sont simplement des données arbitraires interprétées par le nuanceur de vertex que vous créez.

Nombre Le nuanceur de vertex génère une coordonnée homogène dans l’espace clip pour la position de vertex transformée. La division et la capture de perspective sont effectuées automatiquement après le nuanceur.

Un nuanceur de vertex ne peut pas créer ou détruire des sommets ; il fonctionne sur un seul vertex à la fois, en prenant un vertex non traité comme entrée et en sortant un seul vertex traité. Il peut donc être utilisé pour manipuler la géométrie existante (en appliquant des déformations ou en effectuant des opérations de skinning), mais ne peut pas générer de nouvelle géométrie en tant que telle.

Nombre Vous devez choisir l’un ou l’autre. Si vous utilisez un nuanceur de vertex personnalisé, vous êtes responsable de l’exécution de la transformation complète du vertex.

Oui. Le moteur de traitement de vertex du logiciel Direct3D prend entièrement en charge les nuanceurs de vertex personnalisés avec un niveau de performances étonnamment élevé.

Les appareils capables de prendre en charge les nuanceurs de vertex dans le matériel sont nécessaires pour remplir le champ D3DCAPS9::VertexShaderVersion pour indiquer le niveau de version du nuanceur de vertex qu’ils prennent en charge. Tout appareil prétendant prendre en charge un niveau particulier de nuanceur de vertex doit prendre en charge tous les nuanceurs de vertex juridiques qui répondent à la spécification de ce niveau ou inférieur.

Les appareils prenant en charge les nuanceurs de vertex 1.0 sont requis pour prendre en charge un minimum de 96 registres de constantes. Les appareils peuvent prendre en charge plus de ce nombre minimal et le signaler via le champ D3DCAPS9::MaxVertexShaderConst.

L’exemple habituel de cette situation est un cube dans lequel vous souhaitez utiliser une texture différente pour chaque visage. Malheureusement, la réponse n’est pas possible, il n’est actuellement pas possible d’indexer les composants de vertex indépendamment. Même avec plusieurs flux de vertex, tous les flux sont indexés ensemble.

Lors de l’utilisation du pipeline de géométrie logicielle, Direct3D transforme d’abord tous les sommets de la plage que vous avez envoyée, plutôt que de les transformer à la demande au fur et à mesure qu’ils sont indexés. Pour les données denses (c’est-à-dire, où la plupart des sommets sont utilisés), cela est plus efficace, en particulier lorsque des instructions SIMD sont disponibles. Si vos données sont partiellement emballées (autrement dit, de nombreux sommets ne sont pas utilisés), vous pouvez envisager de réorganiser vos données afin d’éviter un trop grand nombre de transformations redondantes. Lors de l’utilisation de l’accélération géométrique matérielle, les sommets sont généralement transformés à la demande, car ils sont nécessaires.

Une mémoire tampon d’index est exactement analogue à une mémoire tampon de vertex, mais elle contient plutôt des index à utiliser dans les appels DrawIndexedPrimitive. Il est vivement recommandé d’utiliser des mémoires tampons d’index plutôt que de mémoire allouée par l’application brute lorsque cela est possible, pour les mêmes raisons que les tampons vertex.

Nombre Vous devez vérifier le champ D3DCAPS9::MaxVertexIndex pour déterminer la valeur d’index maximale prise en charge par l’appareil. Cette valeur doit être supérieure à 2 à la 16e puissance -1 (0xffff) pour que les mémoires tampons d’index de type D3DFMT_INDEX32 soient prises en charge. Notez également que certains appareils peuvent prendre en charge des index 32 bits, mais qu’ils prennent en charge une valeur d’index maximale inférieure à 2 à la 32e puissance -1 (0xffffffff) ; dans ce cas, l’application doit respecter la limite signalée par l’appareil.

Il existe un pipeline de vertex optimisé s/w pour x64, mais il n’existe pas pour IA64.

Réglage des performances

Voici des domaines clés à examiner lors de l’optimisation des performances :

Direct3D est optimisé pour les lots volumineux de primitifs. Plus les polygones peuvent être envoyés dans un seul appel, mieux c’est. Une bonne règle empirique consiste à viser une moyenne de 1000 sommets par appel de primitive. En dessous de ce niveau, vous n’obtenez probablement pas de performances optimales, au-dessus de cela et vous êtes en train de diminuer les retours et les conflits potentiels avec les considérations d’accès concurrentiel (voir ci-dessous).

La modification de l’état de rendu peut être une opération coûteuse, en particulier lors de la modification de la texture. Pour cette raison, il est important de réduire autant que possible le nombre de modifications d’état apportées par image. Essayez également de réduire les modifications de mémoire tampon vertex ou d’index.

Si vous pouvez organiser le rendu simultanément avec d’autres traitements, vous tirerez pleinement parti des performances du système. Cet objectif peut entrer en conflit avec l’objectif de réduire les modifications de renderstate. Vous devez trouver un équilibre entre le traitement par lots pour réduire les modifications d’état et envoyer des données au pilote dès le début pour vous aider à atteindre la concurrence. L’utilisation de plusieurs mémoires tampons vertex à la mode tourniquet peut vous aider à utiliser la concurrence.

Le chargement de textures sur l’appareil consomme de la bande passante et provoque une concurrence de bande passante avec les données de vertex. Par conséquent, il est important de ne pas dépasser la mémoire de texture de validation, ce qui force votre schéma de mise en cache à charger des quantités excessives de textures chaque image.

Vous devez toujours utiliser des mémoires tampons vertex et d’index, plutôt que des blocs simples de mémoire allouée à l’application. Au minimum, la sémantique de verrouillage pour les mémoires tampons vertex et d’index peut éviter une opération de copie redondante. Avec certains pilotes, la mémoire tampon vertex ou d’index peut être placée dans une mémoire plus optimale (peut-être en mémoire vidéo ou AGP) pour l’accès par le matériel.

Ceux-ci ont été introduits dans DirectX 7.0. Ils fournissent un mécanisme permettant d’enregistrer une série de modifications d’état (y compris l’éclairage, le matériau et les modifications de matrice) dans une macro, qui peut ensuite être relue par un seul appel. Ceci présente deux avantages :

• Vous réduisez la surcharge des appels en effectuant un appel au lieu de plusieurs.
• Un pilote conscient peut pré-analyser et précompiler les modifications d’état, ce qui accélère considérablement l’envoi au matériel graphique.

Les modifications d’état peuvent toujours être coûteuses, mais l’utilisation de macros d’état peut aider à réduire au moins certains des coûts. Utilisez un seul appareil Direct3D. Si vous devez effectuer un rendu sur plusieurs cibles, utilisez SetRenderTarget. Si vous créez une application fenêtré avec plusieurs fenêtres 3D, utilisez l’API CreateAdditionalSwapChain. Le runtime est optimisé pour un seul appareil et il existe une pénalité de vitesse considérable pour l’utilisation de plusieurs appareils.

De nombreux maillages rencontrés dans des sommets de caractéristiques de données réelles qui sont partagés par plusieurs polygones. Pour optimiser les performances, il est souhaitable de réduire la duplication dans les sommets transformés et envoyés dans le bus vers l’appareil de rendu. Il est clair que l’utilisation de listes de triangles simples n’obtient aucun partage de vertex, ce qui en fait la méthode la moins optimale. Le choix consiste ensuite entre l’utilisation de bandes et de ventilateurs, ce qui implique une relation de connectivité spécifique entre les polygones et l’utilisation de listes indexées. Là où les données tombent naturellement dans des bandes et des ventilateurs, il s’agit du choix le plus approprié, car ils réduisent les données envoyées au pilote. Toutefois, la décomposition de maillages en bandes et ventilateurs entraîne souvent un grand nombre de pièces distinctes, ce qui implique un grand nombre d’appels DrawPrimitive. Pour cette raison, la méthode la plus efficace consiste généralement à utiliser un seul appel DrawIndexedPrimitive avec une liste de triangles. Un avantage supplémentaire de l’utilisation d’une liste indexée est qu’un avantage peut être gagné même si des triangles consécutifs partagent uniquement un seul sommet. En résumé, si vos données tombent naturellement dans de grandes bandes ou ventilateurs, utilisez des bandes ou des ventilateurs ; sinon, utilisez des listes indexées.

IDirect3DDevice9::GetAvailableTextureMem retourne la mémoire disponible totale, y compris AGP. L’allocation de ressources en fonction d’une hypothèse de la quantité de mémoire vidéo que vous avez n’est pas une bonne idée. Par exemple, que se passe-t-il si le carte s’exécute sous une architecture de mémoire unifiée (UMA) ou peut compresser les textures ? Il peut y avoir plus d’espace disponible que vous n’avez peut-être pensé. Vous devez créer des ressources et rechercher des erreurs « hors mémoire », puis effectuer un scale-back sur les textures. Par exemple, vous pouvez supprimer les niveaux mip supérieurs de vos textures.

1. Créez une mémoire tampon vertex à l’aide des indicateurs d’utilisation D3DUSAGE_DYNAMIC et D3DUSAGE_WRITEONLY et de l’indicateur de pool D3DPOOL_DEFAULT. (Spécifiez également D3DUSAGE_SOFTWAREPROCESSING si vous utilisez le traitement du vertex logiciel.)
2. I = 0.
3. Définir l’état (textures, renderstates, etc.).
4. Vérifiez s’il y a de l’espace dans la mémoire tampon, c’est-à-dire I + M <= N ? (Où M est le nombre de nouveaux sommets).
5. Si c’est le cas, verrouillez le VB avec D3DLOCK_NOOVERWRITE. Cela indique à Direct3D et au pilote que vous allez ajouter des sommets et ne modifie pas ceux que vous avez précédemment mis en lots. Par conséquent, si une opération DMA était en cours, elle n’est pas interrompue. Si non, accédez à 11.
6. Remplissez les sommets M à I.
7. Déverrouiller.
8. Appel de Draw[Indexed]Primitive. Pour les primitives non indexées, utilisez I comme paramètre StartVertex. Pour les primitives indexées, assurez-vous que les index pointent vers la partie correcte de la mémoire tampon vertex (il peut être plus simple d’utiliser le paramètre BaseVertexIndex de l’appel SetIndices pour atteindre cela).
9. I += M.
10. Accédez à 3.
11. Ok, donc nous sommes en dehors de l’espace, donc commençons par un nouveau VB. Nous ne voulons pas utiliser le même, car il peut y avoir une opération DMA en cours. Nous communiquerons avec cela à Direct3D et au pilote en verrouillant le même VB avec l’indicateur de D3DLOCK_DISCARD. Cela signifie que « vous pouvez me donner un nouveau pointeur parce que j'en ai fini avec l'ancien et que je ne me soucie plus vraiment de son contenu ».
12. I = 0.
13. Accédez à 4 (ou 6).

À partir de Direct3D 9, la déclaration de flux de vertex n’est plus qu’un tableau DWORD, il s’agit désormais d’un tableau de structures D3DVERTEXELEMENT9. Le runtime utilise les informations de sémantique et d’utilisation supplémentaires pour lier le contenu des flux de vertex aux registres/variables d’entrée des nuanceurs de vertex. Pour Direct3D 9, les déclarations de vertex sont découplées des nuanceurs de vertex, ce qui facilite l’utilisation des nuanceurs avec des géométries de différents formats, car le runtime lie uniquement les données dont le nuanceur a besoin.

Les nouvelles déclarations de vertex peuvent être utilisées avec le pipeline de fonction fixe ou avec des nuanceurs. Pour le pipeline de fonction fixe, il n’est pas nécessaire d’appeler SetVertexShader. Si toutefois, vous souhaitez basculer vers le pipeline de fonction fixe et avoir précédemment utilisé un nuanceur de vertex, appelez SetVertexShader(NULL). Une fois cette opération effectuée, vous devez toujours appeler SetFVF pour déclarer le code FVF.

Lorsque vous utilisez des nuanceurs de vertex, appelez SetVertexShader avec l’objet nuanceur de vertex. En outre, appelez SetFVF pour configurer une déclaration de vertex. Cela utilise les informations implicites dans la FVF. SetVertexDeclaration peut être appelé à la place de SetFVF, car il prend en charge les déclarations de vertex qui ne peuvent pas être exprimées avec une FVF.

Les fonctions de chargeur de fichiers image D3DX prennent en charge les fichiers BMP, TGA, JPG, DIB, PPM et DDS.

Une erreur courante lors de l’utilisation des fonctions ID3DXFont::DrawText consiste à spécifier un composant alpha zéro pour le paramètre de couleur ; ce qui entraîne une transparence totale (c’est-à-dire invisible) du texte. Pour le texte entièrement opaque, assurez-vous que le composant alpha du paramètre de couleur est entièrement saturé (255).

Le SDK DirectX 8.1 a ajouté deux fonctions à la bibliothèque D3DX spécifiquement à cet effet : D3DXSaveSurfaceToFile() et D3DXSaveTextureToFile(). Ces fonctions prennent en charge l’enregistrement d’une image dans un fichier au format BMP ou DDS. Dans les versions précédentes, vous devez verrouiller l’aire et lire les données d’image, puis l’écrire dans un fichier bitmap. Pour plus d’informations sur l’écriture d’une fonction pour stocker des bitmaps, consultez Stockage d’une image.

Vous pouvez également utiliser GDI+ pour enregistrer l’image dans un large éventail de formats, bien que cela nécessite des fichiers de support supplémentaires à distribuer avec votre application.

Il existe trois façons d’incorporer le langage HLSL (Microsoft High Level Shader Language) dans votre moteur de jeu :

• Compilez votre source de nuanceur en assembly de trame de vertex ou de pixels (à l’aide de l’utilitaire de ligne de commande fxc.exe) et utilisez D3DXAssembleShader() au moment de l’exécution. De cette façon, même un jeu DirectX 8 peut même tirer parti de la puissance du HLSL.
• Utilisez D3DXCompileShader() pour compiler votre source de nuanceur dans le flux de jetons et le formulaire de table constante. Au moment de l’exécution, chargez le flux de jetons et la table constante et appelez CreateVertexShader() ou CreatePixelShader() sur l’appareil pour créer vos nuanceurs.
• Le moyen le plus simple d’être opérationnel consiste à tirer parti du système D3DX Effects en appelant D3DXCreateEffectFromFile() ou D3DXCreateEffectFromResource() avec votre fichier d’effet.

À compter du SDK DirectX de décembre 2006, le nouveau compilateur HLSL développé pour Direct3D 10 a été activé pour les cibles Direct3D 9. Le nouveau compilateur n’a aucune prise en charge des cibles ps_1_x et est désormais le compilateur par défaut pour tous les nuanceurs HLSL Direct3D. Un indicateur de compatibilité descendante peut être utilisé pour forcer ps_1_x cibles à compiler en tant que cibles ps_2_0.

Les applications qui souhaitent utiliser le compilateur hérité peuvent continuer à le faire en fournissant un indicateur au moment de l’exécution (voir indicateurs du compilateur) ou en fournissant un commutateur lors de l’utilisation de fxc.

Utilisez D3DXCreateEffect pour créer un ID3DXEffect, puis utilisez GetPassDesc pour récupérer un D3DXPASS_DESC. Cette structure contient des pointeurs vers des nuanceurs de vertex et de pixels.

N’utilisez pas ID3DXEffectCompiler::GetPassDesc. Les poignées de nuanceur de vertex et de pixels retournées par cette méthode sont NULL.

La fonction intrinsèque de bruit génère le bruit perlin tel que défini par Ken Perlin. La fonction HLSL ne peut actuellement être utilisée que pour remplir des textures dans des nuanceurs de textures, car h/w actuel ne prend pas en charge la méthode en mode natif. Les nuanceurs de texture sont utilisés dans la conjuction avec les fonctions D3DXFill*Texture() qui sont des fonctions d’assistance utiles pour générer des textures définies de manière procédurale pendant le temps de chargement.

Vous pouvez utiliser les fonctions D3DXGetPixelShaderProfile() et D3DXGetPixelShaderProfile() qui retournent une chaîne déterminant le profil HLSL le mieux adapté à l’appareil en cours d’exécution.

Via l’interface ID3DXConstantTable utilisée pour accéder à la table constante. Ce tableau contient les variables utilisées par les nuanceurs de langage de haut niveau et les effets.

Oui, pour définir des données privées que vous appelez SetPrivateData (pReal est l’objet de texture D3D, pSpoof est l’objet de texture encapsulé).

hr = pReal->SetPrivateData(IID_Spoof, &pSpoof, 
            sizeof(IDirect3DResource9*), 0)));

Pour rechercher le pointeur encapsulé :

    IDirect3DResource9* pSpoof;
    DWORD dwSize = sizeof(pSpoof);
    hr = pReal->GetPrivateData(IID_Spoof, (void*) &pSpoof, &dwSize);

Vous n’avez probablement pas optimisé le maillage après avoir défini les attributs de visage. Si vous spécifiez des attributs, puis appelez ID3DXMesh::DrawSubset(), cette méthode doit effectuer une recherche du maillage pour tous les visages contenant les attributs demandés. En outre, les visages rendus sont probablement dans un modèle d’accès aléatoire, ce qui n’utilise pas le cache de vertex. Après avoir défini les attributs de visage pour vos sous-ensembles, appelez les méthodes ID3DXMesh::Optimize ou ID3DXMesh::OptimizeInPlace et spécifiez une méthode d’optimisation de D3DXMESHOPT_ATTRSORT ou plus forte. Notez que pour optimiser les performances, vous devez optimiser avec l’indicateur de D3DXMESHOPT_VERTEXCACHE, qui réorganise également les sommets pour optimiser l’utilisation du cache de vertex. Le tableau d’adjacence généré pour un maillage D3DX a trois entrées par visage, mais certains visages peuvent ne pas avoir de visages adjacents sur les trois bords. Comment est-ce encodé ? Les entrées où il n’y a pas de visages adjacents sont encodées en tant que 0xffffffff.

PRT est une nouvelle fonctionnalité de D3DX ajoutée dans la mise à jour du SDK d’été 2003. Il permet de rendre en temps réel des scénarios d'éclairage complexes tels que l'illumination globale, l'ombrage doux et la diffusion sous la surface. Le Kit de développement logiciel (SDK) contient de la documentation et des exemples d’intégration de la technologie dans votre jeu. Les exemples de démonstration PRT et LocalDeformablePRT illustrent respectivement comment utiliser le simulateur pour les scénarios d’éclairage par vertex et par pixel. Pour plus d’informations sur ce sujet et d’autres sujets, consultez la page Web de Peter Pike Sloan.

Créez une cible de rendu multisamplée à l’aide de Direct3DDevice9::CreateRenderTarget. Après avoir rendu la scène à cette cible de rendu, StretchRect de celui-ci vers une texture cible de rendu. Si vous apportez une modification au texte hors écran (par exemple, flou ou floraison), recopiez-le dans la mémoire tampon arrière avant de le présenter().

Vous avez probablement installé le runtime DirectX de débogage. La version de débogage du runtime remplit les mémoires tampons avec des mémoires tampons statiques afin d’aider les développeurs à intercepter les bogues avec des mémoires tampons non initialisées. Vous ne pouvez pas garantir le contenu d’une mémoire tampon DirectSound après la création ; en particulier, vous ne pouvez pas supposer qu’une mémoire tampon avec zéro est supprimée.

Les modifications apportées aux paramètres d’effet n’ont pas toujours lieu immédiatement sur DirectX 8. Pour plus d’efficacité, DirectSound traite 100 millisecondes de données sonores dans une mémoire tampon, en commençant au curseur de lecture, avant la lecture de la mémoire tampon. Ce prétraitement se produit après tous les appels suivants :

IDirectSoundBuffer8::SetCurrentPosition
IDirectSoundBuffer8::SetFX
IDirectSoundBuffer8::Stop
IDirectSoundBuffer8::Unlock

À compter de DirectX 9, un nouvel algorithme de traitement FX qui traite les effets juste-à-temps résout ce problème et a réduit la latence. L’algorithme a été ajouté à l’appel IDirectSoundBuffer8::Play(), ainsi qu’un thread supplémentaire qui traite les effets juste avant le curseur d’écriture. Vous pouvez donc définir des paramètres à tout moment et ils fonctionneront comme prévu. Toutefois, notez que, sur une mémoire tampon de lecture, il y aura un petit délai (généralement 100 ms) avant d’entendre le changement de paramètre, car l’audio entre les curseurs de lecture et d’écriture (et un peu plus de remplissage) a déjà été traité à ce moment-là.

Si vous n’avez pas besoin d’utiliser DirectSoundEnumerate() pour répertorier les appareils DSound disponibles, ne liez pas votre application avec dsound.lib et utilisez-la plutôt via coMs CoCreateInstance(CLSID_DirectSound...) puis initialisez l’objet DSound à l’aide d’Initialize(NULL). Si vous devez utiliser DirectSoundEnumerate(), vous pouvez charger dynamiquement dsound.dll à l’aide de LoadLibrary(« dsound.dll ») ; et accéder à ses méthodes à l’aide de GetProcAddress(« DirectSoundEnumerateA/W ») et GetProcAddress(« DirectSoundCreateA/W ») et ainsi de suite.

Si vous ne trouvez pas de réponse à votre question dans les fichiers d’aide DirectSound, vous trouverez un bon article avec plus d’informations disponibles sur les fichiers AUDIO multiples et WAVE.

Dans DirectSound 9.0 lorsque vous dupliquez une mémoire tampon, il est désormais possible d’obtenir l’interface IDirectSoundBuffer8 sur la mémoire tampon dupliquée, ce qui vous donnera accès à la méthode AcquireResources. Cela vous permet d’associer une mémoire tampon à l’indicateur DSBCAPS_LOCDEFER à une ressource matérielle. Vous pouvez ensuite définir vos paramètres EAX sur cette mémoire tampon avant d’avoir à appeler Play().

Il existe quelques bogues subtils dans différentes versions de DirectSound, la pile audio Windows principale et les pilotes audio qui rendent les notifications de position de curseur non fiables. À moins que vous ne visiez une configuration HW/SW connue sur laquelle vous savez que les notifications se comportent bien, évitez les notifications de position du curseur. Pour le suivi de position GetCurrentPosition() est une technique plus sûre.

Chaque appel GetCurrentPosition() sur chaque mémoire tampon provoque un appel système et les appels système doivent être réduits, car ils constituent un composant important de l’empreinte processeur de DSound. Sur NT (Win2K et XP), les curseurs dans les mémoires tampons SW (et les mémoires tampons HW sur certains appareils) se déplacent par incréments de 10 ms, de sorte que l’appel de GetCurrentPosition() toutes les 10 ms est idéal. L’appel de celui-ci plus souvent que toutes les 5 ms entraîne une dégradation des performances.

Vous pouvez effectuer plusieurs opérations pour améliorer les performances de votre code audio :

• N’appelez pas GetCurrentPosition trop souvent. Chaque appel GetCurrentPosition() sur chaque mémoire tampon provoque un appel système et les appels système doivent être réduits, car ils constituent un composant important de l’empreinte processeur de DSound. Sur NT (Win2K et XP), les curseurs dans les mémoires tampons SW (et les mémoires tampons HW sur certains appareils) se déplacent par incréments de 10 ms, de sorte que l’appel de GetCurrentPosition() toutes les 10 ms est idéal. L’appel de celui-ci plus souvent que toutes les 5 ms entraîne une dégradation de la perf.

• Utilisez une fréquence d’images distincte et inférieure pour l’audio. De nos jours, de nombreux jeux Windows peuvent dépasser 100 images par seconde et il n’est pas nécessaire dans la plupart des cas de mettre à jour vos paramètres audio 3D à la même fréquence d’images. Le traitement de votre audio chaque seconde ou troisième image graphique, ou toutes les 30 ms, peut réduire considérablement le nombre d’appels audio dans toute votre application sans réduire la qualité audio.

• Utilisez DS3D_DEFERRED pour les objets 3D. La plupart des cartes sonores répondent immédiatement aux modifications de paramètres et, dans une seule image, peuvent changer, en particulier si vous modifiez la position ou l’orientation de l’écouteur. Cela oblige la carte son / le processeur à effectuer de nombreux calculs inutiles. Une autre optimisation rapide et universelle consiste à différer certains changements de paramètres et à les valider à la fin de la trame.

  ou utilisez au moins SetAllParameters plutôt que des appels Set3DParamX individuels sur des mémoires tampons.

  De même, vous devez utiliser au moins les appels SetAllParamenters sur des mémoires tampons 3D plutôt que les appels Set3DParamX individuels. Essayez simplement de réduire les appels système dans la mesure du possible.

• N’effectuez pas d’appels redondants ; stockez et triez une liste d’appels de lecture. Souvent, dans une trame de mise à jour audio, il y a 2 demandes de lecture de nouveaux sons. Si les demandes sont traitées à mesure qu’elles arrivent, le premier nouveau son peut être démarré, puis immédiatement remplacé le deuxième son demandé. Cela entraîne des calculs redondants, un appel de lecture inutile et un appel d’arrêt inutile. Il est préférable de stocker une liste de demandes de nouveaux sons à lire, afin que la liste puisse être triée, et seulement les voix qui devraient commencer à jouer, sont réellement jouées.

  En outre, vous devez stocker des copies locales des paramètres 3D et EAX pour chaque source sonore. Si une demande est effectuée pour définir un paramètre sur une valeur particulière, vous pouvez vérifier si la valeur est réellement différente du dernier jeu de valeurs. Si ce n’est pas le cas, l’appel n’a pas besoin d’être effectué.

  Bien que le pilote de carte audio détecte probablement ce scénario et n’effectue pas de nouveau le calcul (même), l’appel audio doit atteindre le pilote audio (via une transition en anneau) et il s’agit déjà d’une opération lente.

Lors de la diffusion audio en continu dans une mémoire tampon, il existe deux algorithmes de base : After-Write-Cursor (AWC) et Before-Play-Cursor (BPC). AWC réduit la latence au coût de glitching, tandis que le BPC est l’inverse. Étant donné qu’il n’existe généralement aucune modification interactive du son diffusé en continu, ce type de latence est rarement un problème pour les jeux et les applications similaires, de sorte que le BPC est l’algorithme plus approprié. Dans AWC, à chaque fois que votre thread de streaming s'exécute, vous « complétez » les données dans vos tampons de bouclage jusqu'à N ms au-delà de leurs curseurs d'écriture (typiquement N=40 environ, pour tenir compte de l'instabilité de la programmation de Windows). Dans CSP, vous écrivez toujours autant de données dans les mémoires tampons que possible, en les remplissant directement jusqu’à leurs curseurs de lecture (ou peut-être 32 octets avant d’autoriser les pilotes qui signalent incorrectement leur progression du curseur de lecture).

Utilisez BPC pour minimiser le glitching, et utilisez des buffers de 100ms ou plus, même si votre jeu ne glitch pas sur votre matériel de test, il glitchera sur une machine quelconque.

La latence de démarrage (qui est différente de la latence de diffusion en continu mentionnée ci-dessus) peut être un problème dans le cas d’un certain matériel (l’appel Play() prend juste beaucoup de temps parfois sur certaines cartes audio). Si vous souhaitez vraiment réduire cette latence, pour les sons de secousses (tirs d’arme, bruits de pas, etc.) une astuce pratique consiste à garder certaines mémoires tampons toujours en boucle et en jouant le silence. Lorsque vous devez lire un son secousse, choisissez une mémoire tampon libre, voyez où se trouve son curseur d’écriture et placez le son dans la mémoire tampon juste au-delà du curseur d’écriture. Certaines cartes son ne répondent pas à la question QuerySupport pour des propriétés différées dont je sais qu'elles sont prises en charge. Existe-t-il une solution de contournement ? Vous pouvez simplement QuerySupport pour les versions non différées des propriétés et utiliser les paramètres différés de toute façon. Les pilotes de carte de son les plus récents peuvent également résoudre ce problème.

Reportez-vous à la documentation sur l’encodeur Windows Media à l’adresse : Série Windows Media Encoder 9.

DirectSound ne prend pas en charge le décodage MP3 en mode natif. Vous pouvez décoder les fichiers à l’avance (à l’aide d’un codec ACM d’un filtre DirectShow), ou bien simplement utiliser DirectShow lui-même, qui peut effectuer le décodage pour vous ; vous pouvez ensuite copier les données audio PCM obtenues dans vos mémoires tampons DirectSound.

NURBS n’est pas pris en charge. Vous pouvez les convertir en maillages de polygones.

Les SUBDs ne sont pas pris en charge. Vous pouvez les convertir en maillages de polygones.

La fenêtre d’aperçu n’est pas animée au sens le plus strict de la question. Il ne joue pas d’animation, mais se synchronise à la place avec l’état le plus actuel de la scène Maya. Lorsque l’animation est exportée, les matrices à chaque transformation sont décomposées en échelle, rotation (quaternion) et composants de traduction (souvent appelés SRT). Les SRT sont plus souhaitables que les matrices, car elles interpolent bien, fournissent une forme plus compacte des données et peuvent être compressées indépendamment. Toutes les matrices ne peuvent pas se décomposer en SRT. S’ils ne peuvent pas décomposer, les SRT résultants sont inconnus, de sorte que de petites erreurs dans l’animation peuvent être détectées. Les deux caractéristiques de Maya qui provoquent le plus souvent des problèmes lors de la décomposition sont des distorsions et des rotations ou des échelles hors centre. Si vous rencontrez ce problème, car vous utilisez des rotations ou des échelles hors centre, envisagez d’ajouter des transformations supplémentaires augmentant votre niveau de hiérarchie.

Où l’animation D3DX prend en charge les SRT, elle ressemble à ceci :

[S]x[R]x[T]

Les matrices de Maya sont beaucoup plus complexes et nécessitent une quantité importante de processus supplémentaire, ce qui ressemble à ceci :

[SpInv]x[S]x[Sh]x[Sp]x[St]x[RpInv]x[Ro]x[R]x[Rp]x[Rt]x[T]

L’apparence rigide de Maya n’est pas prise en charge pour l’instant. Utilisez Apparence lisse.

Les fichiers X ne prennent pas en charge IK. Au lieu de cela, les solutions IK sont intégrées aux images stockées dans le fichier X.

Actuellement, les extensions DirectX pour Maya prennent uniquement en charge les matériaux DirectXShader pour la préversion et l’exportation. Dans une version ultérieure, d’autres matériaux peuvent être pris en charge.

Oui, mais ils agissent comme le même axe. Vous ne pouvez donc pas lire les déclencheurs indépendamment avec DirectInput. À l’aide de XInput, les déclencheurs retournent des valeurs distinctes.

Pour plus d’informations sur la raison pour laquelle DirectInput interprète les déclencheurs comme un axe, consultez Utilisation d’un contrôleur avec DirectInput.

XInput prend en charge 4 contrôleurs branchés à la fois.

Non, ce n'est pas le cas.

Oui, vous pouvez accéder aux contrôleurs courants via DirectInput.

Utilisez la fonction XInputSetState.

Lors de la connexion du casque, le casque du contrôleur agit comme un périphérique audio USB standard. Par conséquent, lorsqu’il est connecté, Windows change automatiquement pour utiliser ce périphérique audio USB comme valeur par défaut. Étant donné que l’utilisateur ne souhaite probablement pas que tout l’audio passe par le casque, il devra l’ajuster manuellement au paramètre d’origine.

Les lumières sur le contrôleur sont prédéterminées par le système d’exploitation et ne peuvent pas être modifiées.

Désolé... Ce bouton est réservé à une utilisation ultérieure.

Les pilotes seront disponibles via Windows Update.

Au démarrage de XInput, l’ID est déterminé de manière non déterministe par le moteur XInput et les contrôleurs connectés. Si les contrôleurs sont branchés pendant l’exécution d’une application XInput, le système attribue au nouveau contrôleur le numéro disponible le plus bas. Si un contrôleur est déconnecté, son numéro sera à nouveau disponible.

Utilisez la fonction XInputGetDSoundAudioDeviceGuids . Pour plus d’informations, consultez l’exemple AudioController.

Si le contrôleur était en cours d’utilisation par un joueur, vous devez suspendre le jeu jusqu’à ce que le contrôleur soit reconnecté et que le joueur appuie sur un bouton pour signaler qu’ils sont prêts à se remettre en route.