Domande frequenti su DirectX

Assolutamente. La tecnologia x64 è ampiamente disponibile sul mercato. La maggior parte delle nuove CPU vendute negli ultimi anni, e quasi tutte le linee di processore nello sviluppo da AMD e Intel, sono compatibili con x64. Windows XP Professional x64 Edition ha introdotto la tecnologia di abilitazione del sistema operativo per x64 rilasciata nell'aprile del 2005. Poiché le edizioni x64 richiedono una nuova generazione di driver nativi a 64 bit, questa prima versione era limitata alla distribuzione OEM.

Con Windows Vista, i clienti sono liberi di scegliere edizioni a 32 bit o a 64 bit durante l'acquisto di computer basati su Windows e le licenze per Windows Vista sono valide per entrambe le edizioni a 32 bit o a 64 bit del sistema operativo. Inoltre, molti driver a 64 bit sono disponibili nella casella e i produttori di dispositivi sono necessari per fornire driver nativi a 32 bit e a 64 bit come parte del Programma di certificazione Windows.

Tutti questi fattori aumenteranno notevolmente le distribuzioni di edizioni a 64 bit di Windows. Man mano che i nuovi computer iniziano a spedire con più di 2 GB di RAM fisica, l'incentivo a usare un sistema operativo a 32 bit diminuisce notevolmente a favore delle edizioni a 64 bit. La tecnologia a 64 bit supporta completamente il codice nativo a 32 bit, sebbene siano necessarie implementazioni native a 64 bit per sfruttare appieno lo spazio di memoria a 64 bit. Ogni applicazione a 32 bit deve avere compatibilità a 64 bit come requisito minimo di spedizione e soddisfare tale requisito è un requisito di base per la compatibilità di Windows Vista. Le incompatibilità in genere derivano dall'uso di codice a 16 bit progettato per il sistema operativo Windows 3.1 o l'installazione di driver non forniti in moduli nativi a 32 bit e a 64 bit.

Per altri dettagli sulla tecnologia a 64 bit, vedi Programmazione a 64 bit per sviluppatori di giochi.

Non più per due motivi: prestazioni e set di funzionalità.

Se la velocità minima della CPU necessaria per il gioco è 1,2 GHz o superiore (che è più comune per i titoli ad alte prestazioni), la maggior parte dei computer idonei eseguirà Windows XP. Nel momento in cui i computer con velocità di CPU superiori a 1,2 GHz sono stati venduti, Windows XP è stato installato come sistema operativo predefinito da quasi tutti i produttori. Ciò significa che in Windows XP ci sono molte funzionalità che gli sviluppatori di giochi di oggi dovrebbero sfruttare tra cui:

• Multitasking migliorato- che offre un'esperienza migliore e più fluida per video, audio e giochi.
• Modello di driver video più stabile, che consente un debug più semplice, un gioco più fluido e prestazioni migliori.
• Configurazione più semplice per la rete, che consente di accedere più facilmente ai giochi multi-giocatore.
• Supporto per i trasferimenti DMA per impostazione predefinita dai dischi rigidi, che comporta un caricamento più semplice e rapido delle applicazioni.
• Segnalazione errori Di Windows, che comporta un sistema operativo, driver e applicazioni più stabili.
• Supporto Unicode, che semplifica notevolmente i problemi di localizzazione.
• Maggiore sicurezza e stabilità, che comporta esperienze migliori per i consumatori.
• Supporto migliore per l'hardware moderno: la maggior parte delle quali non usa più i driver di Windows 98.
• Miglioramento della gestione della memoria, che comporta una migliore stabilità e sicurezza.
• File system NTFS migliorato, che è più resistente agli errori e offre prestazioni migliori con le funzionalità di sicurezza.

Non più. Oltre ai motivi elencati in Should game developers still be publishing games for Windows 95, Windows 98 or Windows ME?, Windows 2000 does not have these features:

• Windows XP supporta funzionalità avanzate del processore, ad esempio Hyper-Threading, Multi-Core e x64.
• Windows XP supporta componenti side-by-side che riducono significativamente i conflitti di controllo delle versioni delle applicazioni.
• Windows XP supporta la protezione senza esecuzione della memoria che consente di evitare programmi dannosi e può facilitare il debug.
• Windows XP ha migliorato il supporto per le schede video avanzate basate su AGP e PCI Express.
• Windows XP supporta il passaggio rapido degli utenti, desktop remoto e assistenza remota che consente di ridurre i costi di supporto del prodotto.
• Gli strumenti per le prestazioni come PIX (in DirectX Developer SDK) non supportano più Windows 2000.

In breve, Windows 2000 non è mai stato progettato o commercializzato come sistema operativo consumer.

La famiglia Windows Vista include cinque edizioni:

• Windows Vista Home Basic
• Windows Vista Home Premium
• Windows Vista Business
• Windows Vista Enterprise
• Windows Vista Ultimate

Home Basic e Home Premium sono versioni incentrate sul consumer, con funzionalità come Family Cassaforte ty (in precedenza nota come Parental Controls) e Home Premium include Media Center. Business e Enterprise sono edizioni incentrate sull'azienda, con funzionalità come Aggiunta a un dominio e Servizi Desktop remoto/Terminal. L'edizione Ultimate combina tutte le funzionalità delle edizioni consumer e aziendali in una sola versione. Tutte le edizioni sono disponibili sia in edizioni a 32 bit (x86) che a 64 bit (x64) e gli utenti sono liberi di usare lo stesso identificatore di prodotto per entrambe le piattaforme.

La tecnologia sottostante le varie edizioni è identica e hanno tutte la stessa versione del runtime DirectX e di altri componenti. Tuttavia, le edizioni presentano alcune piccole differenze rispetto al gioco:

• Games Explorer esiste in tutte le edizioni, ma il collegamento Giochi sul menu Start è solo in Home Basic, Home Premium e Ultimate. Games Explorer è ancora disponibile in tutte le edizioni (facendo clic su Start, scegliendo Tutti i programmi e quindi facendo clic su Giochi) e sulle funzioni dell'interfaccia IGameExplorer in tutte le edizioni.
• I giochi inclusi in Windows non sono disponibili per impostazione predefinita in Business and Enterprise, ma possono essere abilitati dall'amministratore.
• La famiglia Cassaforte ty e le classificazioni di gioco non visualizzano o hanno alcuna influenza sul comportamento di Business o Enterprise e sono disabilitate in Ultimate quando un dominio viene aggiunto.

Le impostazioni di Controllo account utente hanno le stesse impostazioni predefinite per tutte le edizioni, ma possono essere sostituite dalle impostazioni di Criteri di gruppo per il dominio in Business, Enterprise e Ultimate. Ad esempio, l'impostazione dei criteri Controllo account utente: il comportamento della richiesta di elevazione dei privilegi per gli utenti standard può essere impostato su Nega automaticamente le richieste di elevazione dei privilegi in molte impostazioni aziendali per migliorare la sicurezza e molti utenti in tali ambienti verranno sempre eseguiti come utenti standard senza la possibilità di scegliere di eseguire come Amministrazione istrator. Qualsiasi programma (ad esempio un programma di installazione) che richiede diritti amministrativi, a causa del rilevamento dell'installazione legacy o della presenza di un manifesto che specifica il livello di esecuzione richiesto come "require Amministrazione istrator", non verrà sempre avviato in tali situazioni. Altre impostazioni dei criteri, ad esempio Controllo account utente: solo i file eseguibili firmati e convalidati con privilegi elevati possono impedire al programma di installazione di funzionare se non si firma il file eseguibile usando Authenticode.

Questi tipi di modifiche ai criteri possono essere applicati a qualsiasi edizione di Windows Vista, ma sono più probabili nei computer aggiunti a un dominio.

La maggior parte degli utenti di Windows 7 avrà probabilmente una delle due edizioni: Windows 7 Home Premium, per gli utenti domestici o Windows 7 Professional, per utenti aziendali e sviluppatori. Per le grandi aziende, c'è l'edizione di Windows 7 Enterprise con contratto multilicenza, che include tutte le funzionalità di Windows 7; Windows 7 Ultimate è l'equivalente al dettaglio di tale edizione.

Windows 7 Starter Edition è disponibile a livello mondiale per gli OEM e dovrebbe essere distribuito prima con netbook, computer notebook ultra a basso consumo. Windows 7 Home Basic è disponibile solo nei mercati emergenti.

Si noti che tutte le edizioni di Windows 7 (ad eccezione di Starter Edition) sono disponibili sia per le versioni a 32 bit (x86) che per le versioni a 64 bit (x64) e per tutti i pacchetti finali di Windows 7 sono inclusi supporti per entrambe le versioni. Come per Windows Vista, gli utenti sono liberi di usare lo stesso identificatore di prodotto al dettaglio in entrambe le piattaforme.

La tecnologia sottostante nelle varie edizioni è identica e tutte le edizioni hanno la stessa versione del runtime DirectX e altri componenti. Hanno alcune differenze rispetto alle funzionalità di gioco:

• Games Explorer esiste in tutte le edizioni, ma il collegamento Giochi sul menu Start è nascosto per impostazione predefinita in Windows 7 Professional ed Enterprise. Games Explorer è ancora disponibile nella menu Start (facendo clic su Tutti i programmi e quindi facendo doppio clic su Giochi) e il collegamento diretto Giochi può essere abilitato dall'utente.
• I giochi inclusi in Windows non sono disponibili per impostazione predefinita in Windows 7 Professional ed Enterprise, ma possono essere abilitati dall'amministratore.
• La famiglia Cassaforte ty e le classificazioni dei giochi sono disponibili in tutte le edizioni, ma sono disabilitate in Windows 7 Professional, Enterprise e Ultimate quando il sistema operativo si aggiunge a un dominio. Come per Windows Vista Ultimate, questa funzionalità può essere riabilitata nel computer che ha aggiunto un dominio.

Le impostazioni del controllo dell'account utente possono essere influenzate dalle impostazioni di Criteri di gruppo nelle edizioni Windows 7 Professional, Enterprise e Ultimate, molto simili a Windows Vista. Per altre informazioni, vedere Quali sono le differenze tra le varie edizioni di Windows Vista? Come influiscono sull'applicazione DirectX?

Nr. Windows Vista, che include DirectX 10, include un runtime DirectX aggiornato basato sul runtime in Windows XP SP2 (DirectX 9.0c) con le modifiche per funzionare con il nuovo Windows Display Driver Model (WDDM) e il nuovo stack di driver audio e con altri aggiornamenti nel sistema operativo. Oltre a Direct3D 9, Windows Vista supporta due nuove interfacce quando sono presenti l'hardware e i driver video corretti: Direct3D9Ex e Direct3D10.

Poiché queste nuove interfacce si basano sulla tecnologia WDDM, non saranno mai disponibili nelle versioni precedenti di Windows. Tutte le altre modifiche apportate alle tecnologie DirectX per Windows Vista sono specifiche anche per la nuova versione di Windows. Il nome DirectX 10 è fuorviante in quanto molte tecnologie distribuite in DirectX SDK (XACT, XINPUT, D3DX) non sono incluse in questo numero di versione. Quindi, il riferimento al numero di versione del runtime DirectX nel suo complesso ha perso gran parte del suo significato, anche per 9.0c. Lo strumento di diagnostica DirectX (DXdiag.exe) in Windows Vista segnala DirectX 10, ma questo si riferisce solo a Direct3D 10.

DirectX 11 è integrato in Windows 7 ed è disponibile come aggiornamento per Windows Vista (vedere https://go.microsoft.com/fwlink/p/?linkid=160189). Sono inclusi i livelli di funzionalità Direct3D 11, DirectX Graphics Infrastructure (DXGI) 1.1, 10Level9, Windows Advanced Rasterization Platform (WARP) 10 dispositivi di rendering software, Direct2D, DirectWrite e un aggiornamento all'API Direct3D 10.1 per supportare 10Level9 e WARP 10.

Per gli stessi motivi indicati nella domanda precedente (Sarà disponibile DirectX 10 per Windows XP? ), Direct3D 11 e le API correlate non sono disponibili in Windows XP.

DirectShow è stato rimosso da DirectX SDK a partire da aprile 2005. È possibile ottenere le intestazioni, le librerie, gli strumenti e gli esempi per DirectShow in Windows Software Development Kit (in precedenza noto come Platform SDK). DirectSetup in DirectX SDK continua a supportare la ridistribuzione dei componenti di sistema di DirectShow e i componenti più recenti sono già installati nei sistemi operativi seguenti: Microsoft Windows XP Service Pack 2, Windows XP Professional x64 Edition, Windows Server 2003 Service Pack 1 e Windows Vista.

Le modifiche principali sono state apportate per supportare il nuovo WDDM. Per informazioni dettagliate sul nuovo modello di driver, sugli impatti su Direct3D 9 e sulle due nuove interfacce grafiche, Direct3D 9Ex e Direct3D 10, vedere API grafiche in Windows. Le nuove API grafiche per Windows 7, Direct3D 11, Direct2D, DirectWrite, DXGI 1.1 e Direct3D 10.1 aggiornate, sono disponibili come aggiornamento per Windows Vista (vedere https://go.microsoft.com/fwlink/p/?linkid=160189).

Windows Vista Service Pack 1 include una versione aggiornata del runtime DirectX. Questo aggiornamento estende il supporto di Windows Vista per includere Direct3D 10.1, esponendo nuove funzionalità hardware facoltative. Tutti gli hardware in grado di supportare Direct3D 10.1 supportano completamente tutte le funzionalità di Direct3D 10.

DirectSound è stato aggiornato per esporre le funzionalità del nuovo stack di driver audio di Windows Vista, che supporta buffer software multicanale. L'API modalità mantenuta Direct3D è stata completamente rimossa da Windows Vista. DirectPlay Voice è stato rimosso, nonché l'helper NAT di DirectPlay e l'interfaccia utente action-mapper di DirectInput. Il supporto per le interfacce DirectX 7 e DirectX 8 per Visual Basic 6.0 non è disponibile in Windows Vista.

Windows 7 include tutti i componenti di runtime DirectX disponibili in Windows Vista e aggiunge Direct3D 11, DXGI 1.1, 10Level9 livelli di funzionalità, il dispositivo software WARP10, Direct2D, DirectWrite e un aggiornamento a Direct3D 10.1 per supportare 10Level9 e WARP10. Per altre informazioni, vedere API grafiche in Windows.

Tutti gli altri componenti sono identici a Windows Vista, con l'aggiunta del supporto nativo a 64 bit (x64) per l'API Direct Musica core correlata a MIDI con timestamp. Il livello di prestazioni di Direct Musica rimane deprecato ed è disponibile solo per le applicazioni a 32 bit in Windows 7 per la compatibilità delle applicazioni. Si noti che il supporto nativo a 64 bit di Direct Musica non è disponibile in Windows Vista.

Prima di tutto, verificare di aver controllato i risultati con il rasterizzatore di riferimento. Controllare quindi i risultati con la versione certificata WHQL più recente del driver IHVs. È possibile controllare lo stato WHQL a livello di codice usando il metodo GetAdapterIdentifier() nell'interfaccia IDirect3D9 passando il flag D3DENUM_WHQL_LEVEL.

Probabilmente il percorso di inclusione non è impostato correttamente. Molti compilatori, tra cui Microsoft Visual C++, includono una versione precedente dell'SDK, quindi se il percorso di inclusione cerca prima le directory del compilatore standard, si otterranno versioni non corrette dei file di intestazione. Per risolvere questo problema, assicurarsi che i percorsi di inclusione e di libreria siano impostati per cercare prima i percorsi di inclusione e libreria di Microsoft DirectX. Vedere anche il file dxreadme.txt nell'SDK. Se si installa DirectX SDK e si usa Visual C++, il programma di installazione può facoltativamente configurare i percorsi di inclusione.

I vari GUID usati devono essere definiti una sola volta e una sola volta. La definizione per il GUID verrà inserita se si #define il simbolo INITGUID prima di includere i file di intestazione DirectX. Pertanto, è necessario assicurarsi che questo si verifichi solo per un'unità di compilazione. Un'alternativa a questo metodo consiste nel collegare la libreria dxguid.lib, che contiene definizioni per tutti i GUID DirectX. Se si usa questo metodo (consigliato), è consigliabile non #define mai il simbolo INITGUID.

Nr. Le interfacce DirectX sono interfacce COM. Ciò significa che non è necessario che le interfacce numerate più elevate vengano derivate da quelle numerate inferiori corrispondenti. Pertanto, l'unico modo sicuro per ottenere un'interfaccia diversa per un oggetto DirectX consiste nell'usare il metodo QueryInterface dell'interfaccia. Questo metodo fa parte dell'interfaccia IUnknown standard, da cui devono derivare tutte le interfacce COM.

È possibile combinare liberamente diversi componenti di versione diversa; Ad esempio, è possibile usare DirectInput 8 con Direct3D 9 nella stessa applicazione. Tuttavia, in genere non è possibile combinare versioni diverse dello stesso componente all'interno della stessa applicazione; Ad esempio, non è possibile combinare DirectDraw 7 con Direct3D 9 (poiché questi sono effettivamente lo stesso componente di DirectDraw è stato sottosumato in Direct3D a partire da DirectX 8). Esistono tuttavia eccezioni, ad esempio l'uso di Direct3D 9 e Direct3D 10 insieme nella stessa applicazione, che è consentita.

Sì, è possibile usare queste versioni di Direct3D insieme nella stessa applicazione.

Il valore restituito sarà il conteggio dei riferimenti corrente dell'oggetto. Tuttavia, la specifica COM indica che non è consigliabile basarsi su questo e il valore è generalmente disponibile solo a scopo di debug. I valori osservati potrebbero essere imprevisti perché vari altri oggetti di sistema potrebbero contenere riferimenti agli oggetti DirectX creati. Per questo motivo, non è consigliabile scrivere codice che chiama ripetutamente Release fino a quando il conteggio dei riferimenti non è zero, perché l'oggetto potrebbe quindi essere liberato anche se un altro componente potrebbe ancora farvi riferimento.

Non è importante perché le interfacce COM sono conteggiate. Esistono tuttavia alcuni bug noti con l'ordine di rilascio delle interfacce in alcune versioni di DirectX. Per motivi di sicurezza, è consigliabile rilasciare le interfacce in ordine di creazione inversa, quando possibile.

Un puntatore intelligente è una classe modello C++ progettata per incapsulare la funzionalità del puntatore. In particolare, esistono classi di puntatori intelligenti standard progettate per incapsulare i puntatori di interfaccia COM. Questi puntatori eseguono automaticamente QueryInterface anziché un cast e gestiscono automaticamente AddRef e Release. Se dovresti usarli è in gran parte una questione di gusto. Se il codice contiene molte copie di puntatori all'interfaccia, con più addRefs e versioni, i puntatori intelligenti possono probabilmente rendere il codice più pulito e meno soggetto a errori. In caso contrario, è possibile farlo senza di loro. Visual C++ include un puntatore intelligente Microsoft COM standard, definito nel file di intestazione "comdef.h" (cercare com_ptr_t nella Guida).

Il problema più comune con il debug delle applicazioni DirectX consiste nel tentare di eseguire il debug mentre una superficie DirectDraw è bloccata. Questa situazione può causare un blocco "Win16" nei sistemi Microsoft Windows 9x, che impedisce la pittura della finestra del debugger. Se si specifica il flag di D3DLOCK_NOSYSLOCK durante il blocco della superficie, è in genere possibile eliminarlo. Windows 2000 non soffre di questo problema. Quando si sviluppa un'applicazione, è utile eseguire con la versione di debug del runtime DirectX (selezionata quando si installa l'SDK), che esegue la convalida di alcuni parametri e restituisce messaggi utili all'output del debugger.

Utilizzare le macro SUCC edizione Enterprise DED e FAILED. I metodi DirectX possono restituire più codici di esito positivo e negativo, in modo semplice:

== D3D_OK

o test simili non saranno sempre sufficienti.

Non lo fai! I giochi devono essere in grado di gestire il cambio di attività normalmente, poiché molte cose lo causano: ALT+TAB, connessioni desktop remoto, cambio rapido utente, limiti di utilizzo dei controlli genitori e molti altri eventi.

Allo stesso tempo, due fonti comuni di attivazione accidentale delle attività sui giochi con schemi di controllo incentrati sulla tastiera stanno premendo il tasto logo di Windows e attivando la funzionalità di accessibilità StickyKeys con il tasto MAIUSC. Per risolvere questi casi disabilitando la funzionalità, vedere le tecniche descritte in Disabilitazione dei tasti di scelta rapida nei giochi.

Inside COM by Dale Rogerson, pubblicato da Microsoft Press, è un'eccellente introduzione a COM. Per un'analisi più dettagliata di COM, il libro Essential COM di Don Box, pubblicato da Longman, è anche altamente consigliato.

Il codice gestito è codice che ha l'esecuzione gestita da .NET Framework Common Language Runtime (CLR). Si riferisce a un contratto di cooperazione tra l'esecuzione nativa del codice e il runtime. Questo contratto specifica che in qualsiasi momento di esecuzione, il runtime può arrestare un'esecuzione della CPU e recuperare informazioni specifiche per l'indirizzo di istruzione della CPU corrente. Le informazioni che devono essere in genere in grado di eseguire query riguardano lo stato di runtime, ad esempio registrare o impilare il contenuto della memoria.

Prima dell'esecuzione del codice, il codice viene compilato in codice eseguibile nativo. Inoltre, poiché questa compilazione avviene dall'ambiente di esecuzione gestito (o, più correttamente, da un compilatore in grado di conoscere il runtime che sa come impostare come destinazione l'ambiente di esecuzione gestito), l'ambiente di esecuzione gestito può garantire le operazioni del codice. Può inserire trap e hook di Garbage Collection appropriati, gestione delle eccezioni, sicurezza dei tipi, limiti di matrice e controllo dell'indice e così via. Ad esempio, un compilatore di questo tipo assicura di disporre i frame dello stack e tutto il necessario in modo che il Garbage Collector possa essere eseguito in background su un thread separato, che cammina costantemente nello stack di chiamate attivo, trovando tutte le radici, inseguindo tutti gli oggetti attivi. Inoltre, poiché l'IL ha una nozione di sicurezza dei tipi, il motore di esecuzione manterrà la garanzia di sicurezza dei tipi eliminando un'intera classe di errori di programmazione che spesso portano a fori di sicurezza.

A differenza del mondo non gestito: i file eseguibili non gestiti sono fondamentalmente un'immagine binaria, codice x86, caricato in memoria. Il contatore del programma viene inserito lì ed è l'ultimo che il sistema operativo conosce. Esistono protezioni per la gestione della memoria e l'I/O della porta e così via, ma il sistema non sa effettivamente cosa sta facendo l'applicazione. Di conseguenza, non può garantire ciò che accade quando l'applicazione viene eseguita.

Molti. Tuttavia, i due che sono altamente consigliati sono:

• Programmazione di Windows di Charles Petzold (Microsoft Press)
• Programmazione di applicazioni per Windows di Jeffrey Richter (Microsoft Press)

Microsoft pubblica simboli rimossi per tutte le DLL di sistema (più altre). Per accedervi, aggiungere quanto segue al percorso del simbolo nelle impostazioni del progetto all'interno di Visual Studio:

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

per la memorizzazione nella cache dei simboli in locale, usare la sintassi seguente:

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

Dove c:\cache è una directory locale per la memorizzazione nella cache dei file di simboli.

Domande su Direct3D

Domande generali su Direct3D

Il libro standard sul tema è Computer Graphics: Principles and Practice by Foley, Van Dam et al. È una risorsa preziosa per chiunque voglia comprendere le basi matematiche delle tecniche di geometria, rasterizzazione e illuminazione. Le domande frequenti per il gruppo comp.graphics.algorithms Usenet contengono anche materiale utile.

Dipende. Direct3D dispone di una pipeline di elaborazione dei vertici software completa (incluso il supporto per vertex shader personalizzati). Tuttavia, non viene fornita alcuna emulazione per le operazioni a livello di pixel; le applicazioni devono controllare i bit di estremità appropriati e usare l'API ValidateDevice per determinare il supporto.

Non per le applicazioni per le prestazioni. Viene fornito un rasterizzatore di riferimento per la convalida del driver, ma l'implementazione è progettata per l'accuratezza e non per le prestazioni. Direct3D supporta rasterizzatori software plug-in.

Il tasto colore non è supportato direttamente, ma dovrai usare la fusione alfa per emulare il tasto colore. La funzione D3DXCreateTextureFromFileEx() può essere usata per facilitare questa operazione. Questa funzione accetta un parametro colore chiave e sostituirà tutti i pixel dell'immagine di origine contenente il colore specificato con pixel neri trasparenti nella trama creata.

Sì. La pipeline geometry Direct3D ha diversi percorsi di codice, a seconda del tipo di processore, e utilizzerà le speciali operazioni a virgola mobile fornite da 3DNow! o Le istruzioni SIMD di Pentium III in cui sono disponibili. Ciò include l'elaborazione di vertex shader personalizzati.

È possibile filtrare i pixel con un valore alfa superiore o inferiore a una determinata soglia. È possibile controllare questo comportamento usando gli stati di rendering ALPHATESTENABLE, ALPHAREF e ALPHAFUNC.

Un buffer stencil è un buffer aggiuntivo di informazioni per pixel, molto simile a un buffer z. Infatti, si trova in alcuni dei bit di un buffer z. I formati comuni di stencil/z-buffer sono z a 15 bit e stencil a 1 bit o stencil a 24 bit z e stencil a 8 bit. È possibile eseguire semplici operazioni aritmetiche sul contenuto del buffer degli stencil su base pixel quando viene eseguito il rendering dei poligoni. Ad esempio, il buffer degli stencil può essere incrementato o decrementato oppure il pixel può essere rifiutato se il valore dello stencil non riesce un semplice test di confronto. Ciò è utile per gli effetti che comportano il contrassegno di un'area del buffer di frame e quindi l'esecuzione del rendering solo dell'area contrassegnata (o non contrassegnata). Esempi validi sono effettimetrici come volumi d'ombra.

La chiave per questo e altri effetti del buffer stencil volumetrico, è l'interazione tra il buffer degli stencil e il buffer z. Viene eseguito il rendering di una scena con un volume shadow in tre fasi. Prima di tutto, il rendering della scena senza l'ombreggiatura viene eseguito come di consueto, usando il buffer z. Successivamente, l'ombreggiatura viene contrassegnata nel buffer degli stencil come indicato di seguito. I visi anteriori del volume di ombreggiatura vengono disegnati usando poligoni invisibili, con z-testing abilitato ma z-scritture disabilitate e il buffer degli stencil incrementato a ogni pixel che supera lo z-test. Il rendering delle facce posteriore del volume dell'ombreggiatura viene eseguito in modo analogo, ma decrementando invece il valore dello stencil.

Si consideri ora un singolo pixel. Supponendo che la fotocamera non sia nel volume dell'ombra, ci sono quattro possibilità per il punto corrispondente nella scena. Se il raggio dalla fotocamera al punto non interseca il volume dell'ombreggiatura, non saranno stati disegnati poligoni di ombreggiatura e il buffer degli stencil è ancora zero. In caso contrario, se il punto si trova davanti al volume dell'ombreggiatura, i poligoni shadow verranno memorizzati nel buffer z e lo stencil rimane invariato. Se i punti si trovano dietro il volume dell'ombreggiatura, sarà stato eseguito il rendering dello stesso numero di facce anteriori delle facce posteriore e lo stencil sarà pari a zero, dopo essere stato incrementato il numero di volte in decrementato.

La possibilità finale è che il punto si trova all'interno del volume dell'ombra. In questo caso la faccia posteriore del volume di ombreggiatura verrà memorizzata nel buffer z, ma non la faccia anteriore, quindi il buffer degli stencil sarà un valore diverso da zero. Il risultato è parti del buffer di frame che giace in ombra hanno valore stencil diverso da zero. Infine, per eseguire effettivamente il rendering dell'ombreggiatura, l'intera scena viene lavata con un poligono con fusione alfa per influire solo sui pixel con valore stencil diverso da zero. Un esempio di questa tecnica può essere visto nell'esempio "Volume Shadow" fornito con DirectX SDK.

Questo argomento è descritto in modo completo nella documentazione di Direct3D 9. Tuttavia, il riepilogo esecutivo è che è necessario distorsione delle coordinate dello schermo di -0,5 di un pixel per allinearsi correttamente con i texel. La maggior parte delle schede ora è conforme correttamente alle regole di allineamento dei texel, tuttavia esistono alcune schede o driver meno recenti che non lo fanno. Per gestire questi casi, il consiglio migliore è contattare il fornitore dell'hardware in questione e richiedere driver aggiornati o la soluzione alternativa suggerita. Si noti che in Direct3D 10 questa regola non è più valida.

Usare il flag D3DCREATE_PUREDEVICE durante la creazione del dispositivo per creare un dispositivo puro. Un dispositivo puro non salva lo stato corrente (durante le modifiche dello stato), che spesso migliora le prestazioni; questo dispositivo richiede anche l'elaborazione dei vertici hardware. Un dispositivo puro viene in genere usato quando lo sviluppo e il debug vengono completati e si vuole ottenere prestazioni ottimali.

Uno svantaggio di un dispositivo puro è che non supporta tutte le chiamate API Get*; ciò significa che non è possibile usare un dispositivo puro per eseguire query sullo stato della pipeline. Ciò rende più difficile eseguire il debug durante l'esecuzione di un'applicazione. Di seguito è riportato un elenco di tutti i metodi disabilitati da un dispositivo puro.

• 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 secondo svantaggio di un dispositivo puro è che non filtra alcuna modifica dello stato ridondante. Quando si usa un dispositivo puro, l'applicazione deve ridurre al minimo il numero di modifiche dello stato nel ciclo di rendering; ciò può includere modifiche dello stato di filtro per assicurarsi che gli stati non vengano impostati più volte. Questo compromesso dipende dall'applicazione; se si usano più di 1000 chiamate set per fotogramma, è consigliabile sfruttare i vantaggi del filtro di ridondanza eseguito automaticamente da un dispositivo non puro.

Come per tutti i problemi di prestazioni, l'unico modo per sapere se l'applicazione migliorerà o meno con un dispositivo puro consiste nel confrontare le prestazioni dell'applicazione con un dispositivo puro e non puro. Un dispositivo puro può velocizzare un'applicazione riducendo il sovraccarico della CPU dell'API. Ma fate attenzione! Per alcuni scenari, un dispositivo puro rallenta l'applicazione (a causa del lavoro aggiuntivo della CPU causato da modifiche dello stato ridondanti). Se non si è certi del tipo di dispositivo più adatto per l'applicazione e non si filtrano le modifiche ridondanti nell'applicazione, usare un dispositivo non puro.

L'enumerazione può essere eseguita tramite una semplice iterazione dall'applicazione usando i metodi dell'interfaccia IDirect3D9. Chiamare GetAdapterCount per determinare il numero di schede di visualizzazione nel sistema. Chiama GetAdapterMonitor per determinare a quale monitor fisico è connesso un adattatore (questo metodo restituisce un HMONITOR, che puoi quindi usare nell'API Win32 GetMonitorInfo per determinare le informazioni sul monitoraggio fisico). Determinare le caratteristiche di una particolare scheda di visualizzazione o creare un dispositivo Direct3D su tale scheda è semplice come passare il numero di adattatore appropriato al posto di D3DADAPTER_DEFAULT quando si chiama GetDeviceCaps, CreateDevice o altri metodi.

A partire da Direct3D 9 abbiamo stretto la convalida sulle schede che potevano supportare > solo 2 trame simultanee. Alcune schede meno recenti hanno solo 3 fasi di trama disponibili quando si usa un'operazione di modulare alfa specifica. L'uso più comune usato dalle persone per le 3 fasi è l'urto in rilievo e puoi comunque farlo con D3D9.

Il campo altezza deve essere archiviato nel canale alfa e viene usato per modulare il contributo delle luci, ovvero:

// 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 );
}

Questo esempio, insieme ad altri esempi meno recenti, non viene più fornito nella versione corrente dell'SDK e non verrà fornito nelle versioni future dell'SDK.

Elaborazione geometry (vertice)

Direct3D assembla ogni vertice inserito nella parte di elaborazione della pipeline da uno o più flussi di vertici. La presenza di un solo flusso di vertici corrisponde al vecchio modello pre-DirectX 8, in cui i vertici provengono da una singola origine. Con DirectX 8, diversi componenti dei vertici possono provenire da origini diverse; ad esempio, un buffer dei vertici potrebbe contenere posizioni e normali, mentre un secondo mantiene valori di colore e coordinate di trama.

Un vertex shader è una procedura per l'elaborazione di un singolo vertice. Viene definito usando un semplice linguaggio simile a assembly assemblato dalla libreria di utilità D3DX in un flusso di token accettato da Direct3D. Il vertex shader accetta come input un singolo vertice e un set di valori costanti; restituisce una posizione dei vertici (nello spazio clip) e, facoltativamente, un set di colori e coordinate di trama, che vengono usate nella rasterizzazione. Si noti che quando si dispone di un vertex shader personalizzato, i componenti dei vertici non hanno più alcuna semantica applicata da Direct3D e i vertici sono semplicemente dati arbitrari interpretati dal vertex shader creato.

Nr. Il vertex shader restituisce una coordinata omogenea nello spazio clip per la posizione del vertice trasformato. La divisione della prospettiva e il ritaglio vengono eseguiti automaticamente post-shader.

Un vertex shader non può creare o distruggere vertici; opera su un singolo vertice alla volta, prendendo un vertice non elaborato come input e restituisce un singolo vertice elaborato. Può quindi essere utilizzato per manipolare la geometria esistente (applicando deformazioni o eseguendo operazioni di skinning) ma non può effettivamente generare nuova geometria per se.

Nr. È necessario scegliere uno o l'altro. Se si usa un vertex shader personalizzato, si è responsabili dell'esecuzione dell'intera trasformazione dei vertici.

Sì. Il motore di elaborazione dei vertici software Direct3D supporta completamente vertex shader personalizzati con un livello sorprendentemente elevato di prestazioni.

I dispositivi in grado di supportare vertex shader nell'hardware sono necessari per compilare il campo D3DC piattaforma di strumenti analitici 9::VertexShaderVersion per indicare il livello di versione del vertex shader supportato. Qualsiasi dispositivo che dichiara di supportare un particolare livello di vertex shader deve supportare tutti i vertex shader legali che soddisfano la specifica per tale livello o inferiore.

I dispositivi che supportano vertex shader e 1.0 sono necessari per supportare almeno 96 registri costanti. I dispositivi possono supportare più di questo numero minimo e possono segnalare questo numero tramite il campo D3DC piattaforma di strumenti analitici 9::MaxVertexShaderConst.

L'esempio consueto di questa situazione è un cubo in cui si vuole usare una trama diversa per ogni viso. Purtroppo la risposta è no, non è attualmente possibile indicizzare i componenti dei vertici in modo indipendente. Anche con più flussi di vertici, tutti i flussi vengono indicizzati insieme.

Quando si usa la pipeline geometry software, Direct3D trasforma prima tutti i vertici nell'intervallo inviato, anziché trasformarli "su richiesta" man mano che vengono indicizzati. Per i dati densamente compressi (ovvero, dove viene usata la maggior parte dei vertici), questo è più efficiente, in particolare quando sono disponibili istruzioni SIMD. Se i dati sono compressi in modo sparse( ovvero molti vertici non vengono usati), è possibile prendere in considerazione la riorganizzazione dei dati per evitare troppe trasformazioni ridondanti. Quando si usa l'accelerazione della geometria hardware, i vertici vengono in genere trasformati su richiesta in base alle esigenze.

Un buffer di indice è esattamente analogo a un buffer dei vertici, ma contiene indici da usare nelle chiamate DrawIndexedPrimitive. È consigliabile usare buffer di indice anziché memoria allocata dall'applicazione non elaborata quando possibile, per gli stessi motivi dei buffer dei vertici.

Nr. È necessario controllare il campo D3DC piattaforma di strumenti analitici 9::MaxVertexIndex per determinare il valore di indice massimo supportato dal dispositivo. Questo valore deve essere maggiore di 2 alla 16a potenza -1 (0xffff) affinché i buffer di indice di tipo D3DFMT_INDEX32 siano supportati. Si noti inoltre che alcuni dispositivi possono supportare indici a 32 bit, ma supportano un valore di indice massimo minore di 2 a 32°potenza -1 (0xffffffff); in questo caso l'applicazione deve rispettare il limite segnalato dal dispositivo.

Esiste una pipeline di vertici s/w ottimizzata per x64, ma non esiste per IA64.

Ottimizzazione delle prestazioni

Di seguito sono riportate le aree chiave da esaminare quando si ottimizzano le prestazioni:

Direct3D è ottimizzato per batch di primitive di grandi dimensioni. Più poligoni che possono essere inviati in una singola chiamata, meglio. Una buona regola generale consiste nell'mirare alla media di 1000 vertici per ogni chiamata primitiva. Al di sotto di tale livello, probabilmente non si ottengono prestazioni ottimali, al di sopra di questo e si stanno riducendo i rendimenti e i potenziali conflitti con le considerazioni sulla concorrenza (vedere di seguito).

La modifica dello stato di rendering può essere un'operazione costosa, in particolare quando si modifica la trama. Per questo motivo, è importante ridurre al minimo il più possibile il numero di modifiche di stato apportate per fotogramma. Provare anche a ridurre al minimo le modifiche del vertex o del buffer di indice.

Se è possibile disporre di eseguire il rendering simultaneamente con altre elaborazioni, sarà possibile sfruttare appieno le prestazioni del sistema. Questo obiettivo può essere in conflitto con l'obiettivo di ridurre le modifiche dello stato di rendering. È necessario trovare un equilibrio tra l'invio in batch per ridurre le modifiche di stato e il push dei dati al driver in anticipo per ottenere la concorrenza. L'uso di più vertex buffer in modalità round robin può essere utile per la concorrenza.

Il caricamento di trame nel dispositivo utilizza la larghezza di banda e causa una concorrenza della larghezza di banda con i dati dei vertici. Pertanto, è importante non eseguire il commit della memoria della trama, forzando lo schema di memorizzazione nella cache a caricare quantità eccessive di trame ogni fotogramma.

È consigliabile usare sempre vertex buffer e index buffer anziché blocchi normali di memoria allocata dell'applicazione. Come minimo, la semantica di blocco per i vertex e i buffer di indice può evitare un'operazione di copia ridondante. Con alcuni driver, il vertex o il buffer di indice può essere inserito in una memoria più ottimale (ad esempio in memoria video o AGP) per l'accesso dall'hardware.

Questi sono stati introdotti in DirectX 7.0. Forniscono un meccanismo per registrare una serie di modifiche di stato (incluse le modifiche di illuminazione, materiale e matrice) in una macro, che può quindi essere riprodotta da una singola chiamata. Ciò comporta due vantaggi:

• Ridurre il sovraccarico delle chiamate effettuando una chiamata invece di molte chiamate.
• Un driver con riconoscimento può pre-analizzare e precompilare le modifiche dello stato, rendendo molto più veloce l'invio all'hardware grafico.

Le modifiche di stato possono essere comunque costose, ma l'uso di macro di stato può contribuire a ridurre almeno alcuni dei costi. Usare solo un singolo dispositivo Direct3D. Se è necessario eseguire il rendering su più destinazioni, usare SetRenderTarget. Se si sta creando un'applicazione con finestra con più finestre 3D, usare l'API CreateAdditionalSwapChain. Il runtime è ottimizzato per un singolo dispositivo e si verifica una notevole riduzione della velocità per l'uso di più dispositivi.

Molte mesh rilevate nei vertici delle caratteristiche dei dati reali condivise da più poligoni. Per ottimizzare le prestazioni, è consigliabile ridurre la duplicazione nei vertici trasformati e inviati attraverso il bus al dispositivo di rendering. È chiaro che l'uso di elenchi di triangoli semplici non ottiene alcuna condivisione dei vertici, rendendo il metodo meno ottimale. La scelta consiste quindi nell'usare strip e fan, che implicano una relazione di connettività specifica tra i poligoni e l'uso di elenchi indicizzati. Dove i dati rientrano naturalmente in strisce e ventole, si tratta della scelta più appropriata, poiché riducono al minimo i dati inviati al driver. Tuttavia, la scomposizione di mesh in strisce e fan spesso comporta un numero elevato di pezzi separati, implicando un numero elevato di chiamate DrawPrimitive. Per questo motivo, il metodo più efficiente consiste in genere nell'usare una singola chiamata DrawIndexedPrimitive con un elenco di triangoli. Un ulteriore vantaggio dell'uso di un elenco indicizzato è che un vantaggio può essere ottenuto anche quando i triangoli consecutivi condividono solo un singolo vertice. In sintesi, se i dati rientrano naturalmente in strisce o ventole di grandi dimensioni, usare strisce o ventole; in caso contrario, utilizzare elenchi indicizzati.

IDirect3DDevice9::GetAvailableTextureMem restituisce la memoria totale disponibile, incluso AGP. Allocazione di risorse in base a un presupposto della quantità di memoria video non è un'ottima idea. Ad esempio, cosa accade se la scheda è in esecuzione in un'architettura UMA (Unified Memory Architecture) o è in grado di comprimere le trame? Potrebbe esserci più spazio disponibile di quanto si potrebbe pensare. È consigliabile creare risorse e verificare la presenza di errori di memoria insufficiente, quindi eseguire il ridimensionarsi delle trame. Ad esempio, è possibile rimuovere i primi livelli mip delle trame.

1. Creare un buffer dei vertici usando i flag di utilizzo D3DUSAGE_DYNAMIC e D3DUSAGE_WRITEONLY e il flag del pool di D3DPOOL_DEFAULT. Specificare anche D3DUSAGE_SOFTWAREPROCESSING se si usa l'elaborazione dei vertici software.
2. I = 0.
3. Impostare lo stato (trame, rendering e così via).
4. Controllare se nel buffer è presente spazio, ad esempio I + M <= N? (dove M è il numero di nuovi vertici).
5. In caso affermativo, bloccare la vb con D3DLOCK_NOOVERWRITE. In questo modo, Direct3D e il driver verranno aggiunti vertici e non verranno modificati quelli inseriti in batch in precedenza. Pertanto, se è in corso un'operazione DMA, non viene interrotta. Se no, hai 11 anni.
6. Compilare i vertici M in I.
7. Sbloccare.
8. Call Draw[Indexed]Primitive. Per le primitive non indicizzate usare I come parametro StartVertex. Per le primitive indicizzate, assicurarsi che gli indici puntino alla parte corretta del vertex buffer (potrebbe essere più semplice usare il parametro BaseVertexIndex della chiamata SetIndices per ottenere questo risultato).
9. I += M.
10. Devo 3.
11. Ok, quindi lo spazio è esaurito, quindi iniziamo con una nuova VB. Non si vuole usare lo stesso perché potrebbe essere in corso un'operazione DMA. Comunichiamo a direct3D e al driver bloccando la stessa VB con il flag di D3DLOCK_DISCARD. Ciò che significa è "puoi darmi un nuovo puntatore perché sono fatto con il vecchio e non importa molto del vecchio contenuto."
12. I = 0.
13. Goto 4 (o 6).

A partire da Direct3D 9, la dichiarazione di flusso dei vertici non è più solo una matrice DWORD, è ora una matrice di strutture D3DVERTEXELEMENT9. Il runtime usa le informazioni aggiuntive sulla semantica e sull'utilizzo per associare il contenuto dei flussi dei vertici ai registri/variabili di input dei vertex shader. Per Direct3D 9, le dichiarazioni dei vertici vengono disaccoppiate dai vertex shader, che semplificano l'uso degli shader con geometrie di formati diversi perché il runtime associa solo i dati necessari allo shader.

Le nuove dichiarazioni di vertici possono essere usate con la pipeline di funzioni fisse o con shader. Per la pipeline di funzioni fisse, non è necessario chiamare SetVertexShader. Se tuttavia si vuole passare alla pipeline di funzioni fisse e si è usato in precedenza un vertex shader, chiamare SetVertexShader(NULL). Al termine, sarà comunque necessario chiamare SetFVF per dichiarare il codice FVF.

Quando si usano vertex shader, chiamare SetVertexShader con l'oggetto vertex shader. Chiamare inoltre SetFVF per configurare una dichiarazione di vertice. In questo modo vengono usate le informazioni implicite nella funzione FVF. SetVertexDeclaration può essere chiamato al posto di SetFVF perché supporta dichiarazioni di vertici che non possono essere espresse con un FVF.

Le funzioni del caricatore di file di immagine D3DX supportano i file BMP, TGA, JPG, DIB, PPM e DDS.

Un errore comune quando si usano le funzioni ID3DXFont::D rawText consiste nel specificare un componente alfa zero per il parametro color; con conseguente testo completamente trasparente (cioè invisibile). Per il testo completamente opaco, assicurarsi che il componente alfa del parametro colore sia completamente saturo (255).

DirectX 8.1 SDK ha aggiunto due funzioni alla libreria D3DX specificamente a questo scopo: D3DXSaveSurfaceToFile() e D3DXSaveTextureToFile(). Queste funzioni supportano il salvataggio di un'immagine in un file in formato BMP o DDS. Nelle versioni precedenti dovrai bloccare la superficie e leggere i dati dell'immagine, quindi scriverli in un file bitmap. Per informazioni sulla scrittura di una funzione per archiviare le bitmap, vedi Archiviazione di un'immagine.

In alternativa, GDI+ può essere usato per salvare l'immagine in un'ampia gamma di formati, anche se questo richiede la distribuzione di file di supporto aggiuntivi con l'applicazione.

Esistono tre modi in cui microsoft High Level Shader Language (HLSL) può essere incorporato nel motore di gioco:

• Compilare l'origine shader in un assembly vertex o pixel shading (usando l'utilità della riga di comando fxc.exe) e usare D3DXAssembleShader() in fase di esecuzione. In questo modo anche un gioco DirectX 8 può anche sfruttare la potenza di HLSL.
• Usare D3DXCompileShader() per compilare l'origine dello shader in un flusso di token e in un modulo di tabella costante. In fase di esecuzione caricare il flusso di token e la tabella costante e chiamare CreateVertexShader() o CreatePixelShader() nel dispositivo per creare gli shader.
• Il modo più semplice per diventare operativi consiste nell'sfruttare il sistema D3DX Effects chiamando D3DXCreateEffectFromFile() o D3DXCreateEffectFromResource() con il file dell'effetto.

A partire da dicembre 2006 DirectX SDK, il nuovo compilatore HLSL sviluppato per Direct3D 10 è stato abilitato per le destinazioni Direct3D 9. Il nuovo compilatore non supporta ps_1_x destinazioni ed è ora il compilatore predefinito per tutti gli shader Direct3D HLSL. È possibile usare un flag per la compatibilità con le versioni precedenti per forzare la compilazione delle destinazioni ps_1_x come destinazioni ps_2_0.

Le applicazioni che desiderano usare il compilatore legacy possono continuare a farlo specificando un flag in fase di esecuzione (vedere i flag del compilatore) o fornendo un commutatore quando si usa fxc.

Usare D3DXCreateEffect per creare un ID3DXEffect e quindi usare GetPassDesc per recuperare un D3DXPASS_DESC. Questa struttura contiene puntatori a vertex shader e pixel shader.

Non usare ID3DXEffectCompiler::GetPassDesc. Gli handle vertex e pixel shader restituiti da questo metodo sono NULL.

La funzione intrinseca del rumore genera rumore perlin definito da Ken Perlin. La funzione HLSL può attualmente essere usata solo per riempire le trame negli shader come h/w corrente non supporta il metodo in modo nativo. Gli shader trama vengono usati in combinazione con le funzioni D3DXFill*Texture() utili per generare trame definite in modo procedurale durante il tempo di caricamento.

È possibile usare le funzioni D3DXGetPixelShaderProfile() e D3DXGetPixelShaderProfile() che restituiscono una stringa che determina quale profilo HLSL è più adatto per l'esecuzione del dispositivo.

Tramite l'interfaccia ID3DXConstantTable usata per accedere alla tabella costante. Questa tabella contiene le variabili usate dagli shader e dagli effetti del linguaggio di alto livello.

Sì, per impostare dati privati si chiama SetPrivateData (pReal è l'oggetto trama D3D, pSpoof è l'oggetto trama di cui è stato eseguito il wrapping).

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

Per cercare il puntatore di cui è stato eseguito il wrapping:

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

Probabilmente la mesh non è stata ottimizzata dopo aver definito gli attributi del viso. Se si specificano attributi e quindi si chiama ID3DXMesh::D rawSubset(), questo metodo deve eseguire una ricerca della mesh per tutti i visi contenenti gli attributi richiesti. Inoltre, è probabile che i visi sottoposti a rendering si trovino in un modello di accesso casuale, in modo da non usare la cache dei vertici. Dopo aver definito gli attributi del viso per i subset, chiamare i metodi ID3DXMesh::Optimize o ID3DXMesh::OptimizeInPlace e specificare un metodo di ottimizzazione di D3DXMESHOPT_ATTRSORT o più forte. Si noti che per ottenere prestazioni ottimali è consigliabile ottimizzare con il flag D3DXMESHOPT_VERTEXCACHE, che riordina anche i vertici per un utilizzo ottimale della cache dei vertici. La matrice di adiacenza generata per una mesh D3DX ha tre voci per viso, ma alcuni visi potrebbero non avere facce adiacenti su tutti e tre i bordi. Come viene codificato questo oggetto? Le voci in cui non sono presenti visi adiacenti vengono codificate come 0xffffffff.

PRT è una nuova funzionalità di D3DX aggiunta nell'aggiornamento sdk dell'estate 2003. Consente il rendering di scenari di illuminazione complessi, ad esempio lluminazione globale, ombreggiatura morbida e dispersione della superficie secondaria in tempo reale. L'SDK contiene documentazione ed esempi di come integrare la tecnologia nel gioco. Gli esempi di esempio demo PRT e LocalDeformablePRT illustrano come usare rispettivamente il simulatore per ogni vertice e per ogni scenario di illuminazione pixel. Altre informazioni su questo e altri argomenti sono disponibili anche nella pagina Web di Peter Pike Sloan.

Creare una destinazione di rendering multicampionato usando Direct3DDevice9::CreateRenderTarget. Dopo aver eseguito il rendering della scena in tale destinazione di rendering, StretchRect da esso a una trama di destinazione di rendering. Se si apportano modifiche al testo fuori schermo (ad esempio sfocatura o sbocciamento), copiarlo nuovamente nel buffer nascosto prima di presentarlo().

Probabilmente è stato installato il runtime DirectX di debug. La versione di debug del runtime riempie i buffer con dati statici per consentire agli sviluppatori di rilevare bug con buffer non inizializzati. Non è possibile garantire il contenuto di un buffer DirectSound dopo la creazione; in particolare, non è possibile presupporre che un buffer con zero.

Le modifiche apportate ai parametri di effetto non vengono sempre eseguite immediatamente su DirectX 8. Per un'efficienza, DirectSound elabora 100 millisecondi di dati audio in un buffer, a partire dal cursore di riproduzione, prima che venga riprodotto il buffer. Questa pre-elaborazione avviene dopo tutte le chiamate seguenti:

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

A partire da DirectX 9, un nuovo algoritmo di elaborazione FX che elabora gli effetti just-in-time risolve questo problema e ha ridotto la latenza. L'algoritmo è stato aggiunto alla chiamata IDirectSoundBuffer8::P lay(), insieme a un thread aggiuntivo che elabora gli effetti subito prima del cursore di scrittura. È quindi possibile impostare i parametri in qualsiasi momento e funzionano come previsto. Tuttavia, si noti che in un buffer di riproduzione ci sarà un piccolo ritardo (in genere 100 ms) prima di sentire la modifica del parametro, perché l'audio tra i cursori di riproduzione e scrittura (e un po ' più riempimento) è già stato elaborato in quel momento.

Se non è necessario usare DirectSoundEnumerate() per elencare i dispositivi DSound disponibili, non collegare l'applicazione a dsound.lib e usarla invece tramite COMs CoCreateInstance(CLSID_DirectSound...) inizializzare l'oggetto DSound usando Initialize(NULL). Se è necessario usare DirectSoundEnumerate(), è possibile caricare dinamicamente dsound.dll usando LoadLibrary("dsound.dll"); e accedere ai relativi metodi usando GetProcAddress("DirectSoundEnumerateA/W") e GetProcAddress("DirectSoundCreateA/W") e così via.

Se non riesci a trovare una risposta alla tua domanda nei file della Guida directSound, c'è un buon articolo con altre informazioni disponibili in Multiple Channel Audio Data and WAVE Files.If you't find an answer to your question in the DirectSound help files, there is a good article with more information available at Multiple Channel Audio Data and WAVE Files.

In DirectSound 9.0 quando si duplica un buffer è ora possibile ottenere l'interfaccia IDirectSoundBuffer8 nel buffer duplicato, che consente di accedere al metodo AcquireResources. In questo modo sarà possibile associare un buffer al flag DSBC piattaforma di strumenti analitici_LOCDEFER a una risorsa hardware. È quindi possibile impostare i parametri EAX in questo buffer prima di dover chiamare Play().

Esistono alcuni bug sottili in varie versioni di DirectSound, lo stack audio principale di Windows e i driver audio che rendono le notifiche sulle posizioni del cursore inaffidabili. A meno che non si stia rivolgendo a una configurazione HW/SW nota in cui si sa che le notifiche sono ben comportate, evitare le notifiche di posizione del cursore. Per il rilevamento della posizione GetCurrentPosition() è una tecnica più sicura.

Ogni chiamata GetCurrentPosition() in ogni buffer causa una chiamata di sistema e le chiamate di sistema devono essere ridotte al minimo perché sono un componente elevato del footprint della CPU di DSound. In NT (Win2K e XP) i cursori nei buffer SW (e nei buffer HW in alcuni dispositivi) si spostano in incrementi di 10 ms, quindi la chiamata a GetCurrentPosition() ogni 10 ms è ideale. Chiamandola più spesso di ogni 5 ms, si verificherà una riduzione delle prestazioni.

È possibile eseguire diverse operazioni per migliorare le prestazioni del codice audio:

• Non chiamare Troppo spesso GetCurrentPosition. Ogni chiamata GetCurrentPosition() in ogni buffer causa una chiamata di sistema e le chiamate di sistema devono essere ridotte al minimo perché sono un componente elevato del footprint della CPU di DSound. In NT (Win2K e XP) i cursori nei buffer SW (e nei buffer HW in alcuni dispositivi) si spostano in incrementi di 10 ms, quindi la chiamata a GetCurrentPosition() ogni 10 ms è ideale. Chiamandola più spesso di ogni 5 ms, si verificherà una riduzione delle prestazioni.

• Utilizzare una frequenza di fotogrammi separata e inferiore per l'audio. Al giorno d'oggi molti giochi windows possono superare 100 frame al secondo e non è necessario nella maggior parte dei casi aggiornare i parametri audio 3D alla stessa frequenza di fotogrammi. L'elaborazione dell'audio ogni secondo o terzo fotogramma grafico, o ogni 30 ms o così via, può ridurre significativamente il numero di chiamate audio in tutta l'applicazione senza ridurre la qualità audio.

• Usare DS3D_DEFERRED per gli oggetti 3D. La maggior parte delle schede audio risponde immediatamente alle modifiche ai parametri e in un singolo fotogramma può cambiare molto, soprattutto se si modifica la posizione o l'orientamento del listener. Ciò fa sì che la soundcard/CPU esegua molti calcoli non necessari, quindi un'altra ottimizzazione rapida e universale consiste nel rinviare alcune modifiche ai parametri ed eseguirne il commit alla fine del fotogramma.

  o almeno usare SetAllParameters anziché singole chiamate Set3DParamX nei buffer.

  Analogamente, è consigliabile usare almeno le chiamate SetAllParamenters nei buffer 3D anziché le singole chiamate Set3DParamX. Basta provare a ridurre al minimo le chiamate di sistema quando possibile.

• Non effettuare chiamate ridondanti; archiviare e ordinare un elenco di chiamate di riproduzione. Spesso, in un frame di aggiornamento audio, ci sono 2 richieste per riprodurre nuovi suoni. Se le richieste vengono elaborate man mano che arrivano, il primo nuovo suono potrebbe essere avviato e quindi immediatamente sostituito il secondo suono richiesto. Ciò comporta calcoli ridondanti, una chiamata di gioco non necessaria e una chiamata di arresto non necessaria. È meglio archiviare un elenco di richieste di riproduzione di nuovi suoni, in modo che l'elenco possa essere ordinato, e solo quelle voci che dovrebbero iniziare a suonare, sono effettivamente riprodotte.

  Inoltre, è necessario archiviare copie locali dei parametri 3D e EAX per ogni sorgente audio. Se viene effettuata una richiesta per impostare un parametro su un determinato valore, è possibile verificare se il valore è effettivamente diverso dall'ultimo valore impostato. In caso contrario, non è necessario effettuare la chiamata.

  Anche se il driver della scheda audio rileverà probabilmente questo scenario e non eseguirà di nuovo lo stesso calcolo, la chiamata audio dovrà raggiungere il driver audio (tramite una transizione circolare) e questa è già un'operazione lenta.

Quando si trasmette audio in un buffer sono disponibili due algoritmi di base: After-Write-Cursor (AWC) e Before-Play-Cursor (BPC). AWC riduce al minimo la latenza a costo di glitch, mentre BPC è l'opposto. Poiché in genere non ci sono modifiche interattive al suono trasmesso, questo tipo di latenza è raramente un problema per i giochi e applicazioni simili, quindi BPC è l'algoritmo più appropriato. In AWC, ogni volta che il thread di streaming esegue "top up" i dati nei buffer di ciclo fino a N ms oltre i cursori di scrittura (in genere N=40 o così via, per consentire la pianificazione di Windows jitter). In BPC si scrive sempre il maggior numero possibile di dati nei buffer, riempindoli direttamente ai cursori di riproduzione (o forse 32 byte prima di consentire ai driver che segnalano erroneamente lo stato del cursore di riproduzione).

Usa BPC per mimimizzare glitching e usa buffer di 100 ms o più grandi anche se i tuoi giochi non si verificano problemi nell'hardware di test, si verificherà un problema in alcuni computer là fuori.

La latenza di avvio (diversa dalla latenza di streaming menzionata in precedenza) può essere un problema nel caso di alcuni hardware (la chiamata Play() richiede molto tempo a volte su determinate schede audio. Se vuoi davvero ridurre questa latenza, per i suoni di twitch (colpi di pistola, orme e così via). Un pratico trucco è quello di mantenere alcuni buffer sempre ciclo e suonare il silenzio. Quando è necessario riprodurre un suono twitch, scegliere un buffer libero, vedere dove si trova il cursore di scrittura e inserire il suono nel buffer appena oltre il cursore di scrittura. Alcune schede audio hanno esito negativo QuerySupport per le proprietà posticipate supportate. Esiste una soluzione alternativa? È sufficiente eseguire QuerySupport per le versioni non posticipate delle proprietà e usare comunque le impostazioni posticipate. Anche i driver audiocard più recenti possono risolvere questo problema.

Fare riferimento alla documentazione su Windows Media Encoder all'indirizzo: Windows Media Encoder 9 Series.

DirectSound non supporta in modo nativo la decodifica MP3. È possibile decodificare i file in anticipo (usando un codec ACM di un filtro DirectShow) o semplicemente usare DirectShow stesso, che può eseguire automaticamente la decodifica; è quindi possibile copiare i dati audio PCM risultanti nei buffer DirectSound.

NURBS non è supportato. È possibile convertirli in mesh poligono.

I SUBD non sono supportati. È possibile convertirli in mesh poligono.

La finestra di anteprima non è animata nel senso più rigoroso della questione. Non si sta riproducendo l'animazione, ma si sincronizza con lo stato più recente della scena di Maya. Quando l'animazione viene esportata, le matrici in ogni trasformazione vengono scomposte in componenti di scala, rotazione (quaternione) e traslazione (spesso denominati SRT). Le SRT sono più utili delle matrici perché interpolano bene, forniscono una forma più compatta dei dati e possono essere compresse in modo indipendente. Non tutte le matrici possono suddividere in srt. Se non possono scomporre, i file SRT risultanti saranno sconosciuti, quindi potrebbero essere rilevati piccoli errori nell'animazione. Le due caratteristiche di Maya che spesso causano problemi durante la scomposizione sono shears e rotazioni fuori centro o scale. Se si verifica questo problema, poiché si usano rotazioni fuori centro o scale, è consigliabile aggiungere trasformazioni aggiuntive aumentando il livello di gerarchia.

Dove l'animazione D3DX supporta srt, è simile alla seguente:

[S]x[R]x[T]

Le matrici di Maya sono molto più complesse e richiedono una quantità significativa di processo aggiuntivo, simile al seguente:

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

La pelle rigida di Maya non è attualmente supportata. Si prega di usare Smooth Skin.

I file X non supportano LK. Le soluzioni IK vengono invece inserite nei frame archiviati nel file X.

Le estensioni DirectX per Maya attualmente supportano solo i materiali DirectXShader per l'anteprima e l'esportazione. In una versione futura altri materiali potrebbero essere supportati.

Sì, ma agiscono come lo stesso asse. Non è quindi possibile leggere i trigger in modo indipendente con DirectInput. Usando XInput, i trigger restituiscono valori separati.

Per altre informazioni sul motivo per cui DirectInput interpreta i trigger come un asse, vedere Uso di un controller con DirectInput.

XInput supporta 4 controller collegati alla volta.

No, non lo fa.

Sì, è possibile accedere ai controller comuni tramite DirectInput.

Usare la funzione XInputSetState.

Quando si connette il visore VR, il visore VR del controller funge da dispositivo audio USB standard, quindi quando è connesso, Windows cambia automaticamente per usare questo dispositivo audio USB come impostazione predefinita. Poiché l'utente probabilmente non vuole che tutto l'audio attraversi l'auricolare, dovrà regolarlo manualmente all'impostazione originale.

Le luci sul controller sono predeterminate dal sistema operativo e non possono essere modificate.

Questo pulsante è riservato per un uso futuro.

I driver saranno disponibili tramite Windows Update.

All'avvio di XInput, l'ID viene determinato in modo non deterministico dal motore XInput e dai controller collegati. Se i controller sono collegati durante l'esecuzione di un'applicazione XInput, il sistema assegnerà al nuovo controller il numero disponibile più basso. Se un controller è disconnesso, il numero verrà reso nuovamente disponibile.

Usare la funzione XInputGetDSoundAudioDeviceGuids. Per informazioni dettagliate, vedi l'esempio AudioController.

Se il controller è in uso da un giocatore, è necessario sospendere il gioco fino a quando il controller non viene riconnesso e il giocatore preme un pulsante per segnalare che sono pronti per annullare l'uso.