Giochi per i requisiti tecnici di Windows: Procedure consigliate per i giochi in Windows XP, Windows Vista, Windows 7 e Windows 8

Articolo
06/03/2023

Questo articolo fornisce requisiti tecnici e procedure consigliate per i giochi eseguiti in Windows. Abbiamo scritto questi requisiti tecnici e procedure consigliate principalmente per coprire Windows Vista e Windows 7, nonché il sistema operativo Windows XP legacy. Queste procedure consigliate si applicano in genere anche ai giochi Win32 desktop in Windows 8.

Questo articolo contiene le sezioni seguenti:

Differenze per Windows 8
- Informazioni aggiuntive
Giochi per Windows
Sicurezza e compatibilità
Installazione
Affidabilità
Terminologia del controller comune xbox 360 per Windows
Linee guida per i prodotti middleware di gioco
Risorse

Differenze per Windows 8

Ecco un riepilogo delle differenze principali quando si applicano questi requisiti tecnici e procedure consigliate a Windows 8.

L'interfaccia utente di Games Explorer non è visibile

Tutti i giochi registrati con Games Explorer vengono visualizzati come riquadri nella nuova interfaccia utente di Windows, ma gran parte dei metadati associati al titolo non è più visibile. Usare ancora lo strumento Games Definition File Maker (GDFMAKER.EXE), ora disponibile in Windows Software Development Kit (SDK) per creare i metadati. Si usano anche i meccanismi esistenti per distribuire i metadati. Continuare a testare la registrazione di Games Explorer usando Windows 7 e verificare che il nuovo riquadro dell'interfaccia utente di Windows venga visualizzato quando lo installi in Windows 8 (vedi Integrazione di Games Explorer 1.1).

Per scaricare Windows 8 SDK, vedere Download per lo sviluppo di app desktop.

La registrazione con le API di Game Explorer continua a essere il meccanismo per la registrazione del gioco con Windows Parental Controls

È consigliabile eseguire la versione di Windows SDK di GDFMAKER nella versione rilasciata di Windows 8 per assicurarsi che possa popolare tutti i sistemi di classificazione attualmente supportati.

Nota

Questa versione di GDFMAKER richiede .NET 4.0.

Vedere 1.2 Support Family Cassaforte ty /Parental Controls.

Sono ora disponibili tre opzioni per l'uso dell'API XINPUT a seconda dei requisiti

XINPUT 1.4 è integrato in Windows 8. Sia le app di Windows Store che le app Win32 desktop possono usare XINPUT 1.4. Tutte le versioni di Windows possono usare XINPUT 9.1.0 per controller comuni semplificati, ma non esiste alcun pacchetto di ridistribuzione con XINPUT 9.1.0. Tutte le versioni di Windows possono anche usare la versione esistente di DIRECTX SDK XINPUT 1.3, che richiede la distribuzione di DirectSetup.

Vedi 1.4 Supportare il controller comune Xbox 360 per Windows.

In Windows RT è supportato solo un set limitato di app Win32 desktop

I giochi eseguiti in Windows 7 possono e devono essere eseguiti correttamente nelle piattaforme Windows 8 x86 e x64.

Vedi 2.2 Supportare le versioni di Windows x64.

Verificare che tutti i controlli del sistema operativo vengano eseguiti correttamente

La versione del sistema operativo Windows 8 è 6.2 . Windows 8 supera i test minimi correnti della barra che è consigliabile per la distribuzione del gioco.

Il pacchetto DirectX End-User Redistribution viene eseguito correttamente in Windows 8, come in Windows 7, per distribuire D3DX9, D3DX10, D3DX11, XINPUT 1.3, XAUDIO 2.7, XACTEngine e così via

Tuttavia, esiste un problema noto con DirectSetup nei sistemi con solo .NET 4.0 installato a causa della gestione della distribuzione degli assembly DirectX 1.1 gestiti legacy. Questo problema si applica sia a Windows 8, fornito con .NET 4.5 per impostazione predefinita, sia ai computer Windows XP aggiornati con il runtime .NET 4.0 installato. Tuttavia, questo problema non si applica ad alcuna versione di .NET prima di .NET 4.0. Anche se Windows 8 ha un comportamento di compatibilità delle applicazioni per risolvere automaticamente questo problema (che richiede l'accesso alla rete), è consigliabile che i giochi che continuano a distribuire l'aggiornamento directSetup nell'SDK DirectX (giugno 2010) aggiornati dei file REDIST. Come sempre, se si usa DirectSetup per il titolo, tagliare il titolo fino al set minimo richiesto di CAB.

Vedere 3.4 Installare correttamente le risorse di Windows.

I giochi che richiedono il runtime compatibile con .NET 2.0 (2.0, 3.0, 3.5) continuano a usare i meccanismi di distribuzione esistenti

Questi giochi attivano un comportamento di compatibilità delle applicazioni in Windows 8 per abilitare automaticamente il runtime .NET 3.5 (che richiede l'accesso alla rete). È tuttavia consigliabile che gli sviluppatori .NET passino al runtime di .NET 4.0.

Nota

Gli assembly DirectX 1.1 gestiti legacy non sono compatibili con il runtime .NET 4.x.

Vedere 3.4 Installare correttamente le risorse di Windows.

Non è consigliabile usare uno strumento di esecuzione automatica o un'altra tecnologia di preinstallazioni che si basa su .NET

Si supponga che solo i runtime compatibili con .NET 2.0 (2.0, 3.0, 3.5) siano presenti in Windows Vista e Windows 7. Solo il runtime compatibile con .NET 4.0 è presente in Windows 8 per impostazione predefinita.

Vedere 3.7 Supportare l'esecuzione automatica.

È disponibile un'applicazione verifier aggiornata per Windows 8

Windows 8 SDK include questo verificatore dell'applicazione aggiornato.

Vedere 4.2 Eliminare gli errori del verificatore dell'applicazione.

Informazioni aggiuntive

Guida di riferimento sulla compatibilità di Windows 8 e Windows Server 2012
Dov'è DirectX SDK?

Giochi per Windows

Riepilogo dei requisiti dei giochi

Vantaggi dei clienti

I giochi per computer sono un'esperienza di intrattenimento chiave in Windows, ma problemi di facilità d'uso hanno causato frustrazione dei clienti nel corso degli anni. Tradizionalmente, i giochi vengono installati come applicazioni, ma vengono utilizzati più come contenuti multimediali di intrattenimento (film o canzoni, ad esempio). Le innovazioni, ad esempio Games Explorer, espongono i giochi in modo coerente e diverso dalle applicazioni standard. Queste innovazioni offrono anche ai giochi lo status cittadino di prima classe in Windows, insieme a Musica e Immagini. I requisiti seguenti consentono di garantire che Windows Vista e Windows 7 forniscano un'esperienza di gioco migliorata, più accessibile e unificata. Allo stesso tempo, garantiscono la compatibilità con Windows XP.

1.1 Integrazione di Games Explorer

Requisito

Il gioco deve essere visibile all'interno di Games Explorer (la cartella Giochi ) in Windows Vista e Windows 7. Se selezionata, il gioco deve anche visualizzare metadati corretti, inclusi publisher, developer, release date, version, Windows Experience Index score, rating (se applicabile) e collegamenti ipertestuali associati.

Se il gioco viene distribuito digitalmente tramite un servizio di gioco online, il provider di servizi dovrebbe essere visualizzato anche in Games Explorer. Per garantire una corretta gestione del provider e per consentire l'uso dei feed RSS, è necessario usare la versione 2 dello schema per i file di definizione del gioco (GDF). Per altre informazioni sui GDF, vedere Informazioni aggiuntive.

Inoltre, i programmi di installazione del gioco devono rispettare le regole seguenti quando vengono eseguiti in Windows Vista e Windows 7:

L'installazione non deve creare un collegamento per avviare il gioco sul desktop, nel menu Start o in qualsiasi altra posizione.
Non è necessario creare attività e collegamenti per la rimozione.
Gli utenti devono essere in grado di rimuovere il gioco utilizzando Programmi e funzionalità in Pannello di controllo in Windows Vista e Windows 7 oppure Installazione applicazioni in Pannello di controllo in Windows XP.

In Windows XP e nelle versioni precedenti di Windows, il programma di installazione del gioco è gratuito per creare gruppi di programmi, icone del desktop o collegamenti in base alle esigenze.

Logica

Esplora giochi di Windows è simile al concetto delle cartelle di Windows XP Documenti o Immagini personali. L'idea è centralizzare contenuti simili in un'unica posizione e consentire attività più semplici per l'organizzazione e le attività sensibili al contesto. Games Explorer estende il concetto Documenti o Immagini personali consentendo un'organizzazione più ricca e il controllo sui giochi. Games Explorer consente ai giocatori di visualizzare, organizzare e interagire con tutti i giochi installati nei propri sistemi. Consente anche agli editori di giochi di comunicare informazioni importanti sul gioco in modo più efficace. Il sistema è basato sui dati, rendendo più semplice per un editore di giochi aggiornare le informazioni sul gioco nel corso della vita del prodotto.

Informazioni aggiuntive

L'integrazione con Games Explorer richiede la creazione di un file di definizione del gioco (GDF), ovvero un file di testo XML incorporato all'interno di un file binario (un file eseguibile o una DLL) come risorsa, insieme a un'icona di Windows. Il gioco deve quindi essere registrato con Games Explorer. La GDF consente anche l'esposizione di informazioni fornite, ad esempio il titolo del gioco, l'editore, lo sviluppatore, i collegamenti ai siti Web e alle attività facoltative. Si noti che le attività di supporto possono essere solo collegamenti a siti Web, ma le attività di riproduzione possono essere usate anche per le attività di supporto facoltative.

Games Explorer può usare un'immagine bitmap di anteprima, ma è consigliabile invece fornire una risorsa icona di Windows con icone di grandi dimensioni (256 256). La risorsa icona deve includere dimensioni dell'immagine di 256 256 48 48, 32 32 e 16 16 in profondità di colore a 24 bit (colore true) e a 8 bit (256). L'editor di icone fornito in Visual Studio 2008 e 2010 supporta questi formati di icone di grandi dimensioni, così come IconWorkshop Lite.

I dettagli sull'integrazione con Esplora giochi di Windows sono disponibili in DirectX SDK. DirectX SDK include un editor GDF (Game Definition File), nonché un esempio di GDF incluso in GDFExampleBinary, un esempio. Un altro esempio, GameUxInstallHelper, fornisce routine per l'integrazione delle funzionalità necessarie nei sistemi di installazione esistenti. Game Definition File Validator (gdftrace.exe) fornisce il supporto per il debug per la valutazione di un GDF. Vedere anche "Integrazione di Esplora giochi di Windows" nella documentazione di DirectX SDK per C++.

Windows 7 introduce il supporto per la seconda versione di uno schema per i file GDF. La nuova versione include un metodo semplificato per la creazione di attività di gioco e il supporto per le notifiche di aggiornamento, i provider di servizi di gioco, le statistiche di gioco e i feed RSS per i provider di servizi di gioco. La versione più recente di GameUxInstallHelper gestisce tutte le registrazioni e il supporto legacy necessari per usare un file GDF versione 2 con Windows Vista. Usare gli strumenti e il codice di esempio di DirectX SDK di agosto 2009 o versione successiva. È consigliabile usare un file GDF versione 2 per abilitare il supporto per feed RSS, statistiche del gioco e notifiche di aggiornamento. Vedere anche gli esempi ProviderGDFExampleBinary e GameStatisticsExample.

In Windows Vista Business Edition, Windows 7 Professional Edition e edizione Enterprise di Windows Vista e Windows 7, il collegamento Giochi nella menu Start è nascosto. Games Explorer è ancora disponibile nella menu Start facendo clic su Tutti i programmi e quindi facendo clic su Giochi.

Per le applicazioni associate installate con il tuo gioco, ma non con i tuoi giochi, puoi creare menu Start gruppi di programmi, collegamenti e icone desktop in tutte le versioni di Windows, tra cui Windows Vista e Windows 7. Tali applicazioni associate devono superare i giochi applicabili per i requisiti di Windows; per informazioni dettagliate, vedi Linee guida per i prodotti middleware del gioco. I servizi di gioco sono invitati a registrarsi con Games Explorer come provider di giochi per Windows 7. 1

1.2 Supporto famiglia Cassaforte ty /Parental Controls

Requisito

I giochi devono supportare completamente Windows Family Cassaforte ty rispettando le regole seguenti:

I giochi non devono richiedere che l'utente disponga delle credenziali amministrative per la riproduzione. L'installazione, l'applicazione di patch e la rimozione possono richiedere credenziali amministrative, soggette ai requisiti della sezione 3. (Correlato a questo requisito 2.1, seguire le linee guida per il controllo dell'account utente.
I giochi valutati dalle schede di classificazione supportate da Windows, ad esempio ESRB e PEGI, devono includere le informazioni sulle classificazioni assegnate nel file di definizione del gioco (GDF). Tutti i dati delle classificazioni disponibili devono essere inclusi in ogni versione localizzata di GDF, nonché nella versione indipendente dalla lingua.
I giochi devono elencare i file eseguibili in GDF per offrire un'esperienza utente ottimale per restrizioni generali dell'applicazione, a meno che il gioco non usi una tecnologia anti pirateria che crea eseguibili denominati in modo casuale in fase di esecuzione.
I giochi devono chiamare il metodo VerifyAccess dell'interfaccia di Games Explorer durante l'avvio, se disponibile, e uscire se restituisce *pfHasAccess come FAL edizione Standard.

Logica

Tutti i giochi devono essere eseguiti nel contesto di un account utente standard per consentire agli account controllati da Windows Parental Controls di giocare. I genitori vogliono poter monitorare e controllare l'accesso dei bambini ai giochi. Inoltre, numerosi gruppi di settore, governo e difesa desiderano modi migliori per consentire ai genitori di monitorare e controllare i giochi a cui sono esposti i loro figli. In combinazione con l'architettura offerta da Games Explorer, Microsoft offre ai genitori questa possibilità tramite i controlli genitori di Windows.

Anche per i giochi che non partecipano a un programma di classificazioni, la necessità di privilegi elevati crea un'esperienza di gioco scarsa per la maggior parte degli account utente. Questo è in particolare il caso in cui i controlli genitori siano abilitati, che richiederebbero all'elemento padre di immettere la password di amministratore ogni volta che viene avviato il gioco.

Il sistema Windows Parental Controls consente ai genitori di selezionare le classificazioni che ritengono appropriate per i propri figli. I controlli genitori supportano molti dei sistemi di classificazione in tutto il mondo. I controlli genitori consentono anche ai genitori di limitare l'accesso ai giochi in base ai descrittori di contenuto (se il sistema di classificazione applicabile li supporta) e di consentire o impedire l'accesso ai singoli giochi.

La scelta predefinita del sistema di classificazione per Windows Parental Controls si basa sull'impostazione delle impostazioni locali del sistema, ma può essere modificata dall'utente in Opzioni internazionali e della lingua in Pannello di controllo. Pertanto, ogni lingua supportata deve fornire tutti i dati sulle classificazioni disponibili in modo che l'utente abbia la libertà di selezionare qualsiasi classificazioni desiderata.

Informazioni aggiuntive

I giochi senza una classificazione devono comunque soddisfare i requisiti per supportare la riproduzione come utente standard e per chiamare VerifyAccess. Tali giochi per impostazione predefinita sono la categoria Non valutato, visualizzano il testo "Nessuna classificazione fornita" in Games Explorer e sono soggetti all'impostazione Restrizioni di gioco in Parental Controls per i giochi senza valutazione. L'impostazione predefinita Restrizioni è Consenti.

Le informazioni di classificazione in GDF verranno ignorate se il file binario contenitore non è firmato correttamente con Authenticode. Vedere il requisito 2.3.

L'editor di file di definizione del gioco in DirectX SDK include tutti i sistemi di classificazione supportati e replica correttamente queste informazioni in tutte le versioni localizzate di GDF, nonché una versione indipendente dalla lingua. Lo strumento GDFTrace decodifica e verifica tutte le informazioni sulle classificazioni presenti. Usare la versione di agosto 2009 o successiva di questi strumenti.

La GDF per un provider di giochi in genere non contiene informazioni di classificazione ed è soggetta alle impostazioni per il contenuto non valutato.

Sistema operativo	Sistemi di classificazione supportati
Windows Vista	CERO (Giappone) ESRB (USA) OFLC (Australia) PEGI (Europa) PEGI Finlandia (deprecato) PEGI Portogallo PEGI/BBFC (Regno Unito) USK (Germania)
Windows Vista con un Service Pack	I Service Pack per Windows Vista aggiungono il supporto per quanto segue: GRB (Corea del Sud) Descrittori di contenuto varianti "Mild" di ESRB
Windows 7	Windows 7 supporta i sistemi di classificazione supportati da Windows Vista e aggiunge il supporto per quanto segue: CSRR (Taiwan)
Windows 8	Windows 8 supporta i sistemi di classificazione precedenti e aggiunge il supporto per quanto segue: COB-AU (Australia) DJCTQ (Brasile) PFB (Sudafrica) OFLC-NZ (Nuova Zelanda) Windows 8 ritira il supporto per i sistemi deprecati seguenti: PEGI-FI (Finlandia) OFLC (Australia)

Nota

Qualsiasi titolo che include i nuovi descrittori di contenuto ESRB Windows Vista Service Pack 1 (SP1) verrà visualizzato come Non valutato in Windows Vista senza un Service Pack.

I dati delle classificazioni più recenti vengono ignorati nelle versioni dei sistemi operativi senza supportarli. La variante PEGI (Finlandia) è ora deprecata a favore del sistema di classificazione PEGI (Europa). Il sistema OFLC è ora deprecato a favore di COB-AU per l'Australia.

Per altre informazioni sulla compatibilità di un gioco con privilegi utente standard, vedere l'articolo Controllo account utente DirectX per sviluppatori di giochi.

Vedi il requisito 1.1 per altri dettagli sul file di definizione del gioco (GDF).

1.3 Supportare giochi avanzati salvati

[Questo requisito è stato ritirato]

1.4 Supportare il controller comune xbox 360 per Windows [requisito condizionale]

Requisito

I giochi che supportano i controller del game pad devono supportare il controller Xbox 360 per Windows usando l'API XInput . Se sono supportate anche le periferiche DirectInput, è anche possibile usare DirectInput. Tuttavia, XInput deve essere l'API predefinita se viene usato un dispositivo compatibile con Xbox 360.

Tutti i riferimenti ai trigger e ai pulsanti comuni del controller devono usare i nomi di Xbox 360. Per informazioni dettagliate, vedi l'elenco Dei controller comuni xbox 360 per Windows .

La vibrazione del controller deve essere disattivata quando il gioco si trova in uno stato sospeso o sospeso.

Il controllo mouse/tastiera non può essere completamente disabilitato in qualsiasi momento. Come minimo, è necessario che sia disponibile un'opzione per tornare ai menu di gioco.

Logica

Questo requisito consente ai giocatori di scegliere di usare il controller Xbox 360 o la tastiera e il mouse, a seconda del metodo di input più naturale e intuitivo.

Informazioni aggiuntive

Questo requisito non si applica ai giochi che usano solo il mouse e/o la tastiera.

È consigliabile implementare lo spostamento tramite menu per usare i pulsanti di controller standard ampiamente accettati:

A - Accetta
B - Annulla
Start - Accetta o sospendi
Indietro - Annulla, torna su una schermata o su un livello di menu

Per altre info, vedi XInput.

L'argomento XInput e DirectInput illustra i problemi relativi all'uso di entrambe le API contemporaneamente.

È consigliabile non usare DirectInput per implementare i controlli della tastiera o del mouse. I controlli della tastiera e del mouse devono essere implementati solo usando i messaggi di Windows e le API Win32. Per informazioni dettagliate su come ottenere informazioni sullo spostamento del mouse ad alta risoluzione senza usare DirectInput, vedi Utilizzo del movimento del mouse ad alta definizione.

1.5 Supportare più proporzioni e risoluzioni

Requisito

Il gioco deve supportare almeno le proporzioni seguenti e le risoluzioni dello schermo associate:

4:3 normale (800 600 o 1024 768)
16:9 widescreen (1280 720)
16:10 widescreen (1152 720 o 1680 1050 o 800 480)

Per la configurazione e il rilevamento della risoluzione dello schermo, il gioco deve rispettare le regole seguenti:

Il gioco usa la risoluzione desktop del dispositivo di visualizzazione per impostazione predefinita se è una risoluzione supportata. Le proporzioni del desktop devono essere usate come criterio di ricerca se il gioco sceglie una risoluzione predefinita diversa.
Il gioco deve richiedere all'utente di confermare le nuove impostazioni di visualizzazione quando viene apportata una modifica. Se l'utente non accetta entro 15 secondi, la visualizzazione deve ripristinare l'impostazione precedente.
Il gioco non deve estendere i pixel o centrare una finestra di rendering 4:3 per supportare proporzioni widescreen. Tuttavia, il letterboxing è accettabile.

Logica

Con il desktop 3D di Windows, non è possibile presumere una particolare proporzione o risoluzione, a causa dei fattori seguenti:

Supporto per le visualizzazioni ad alto dettaglio.
Aumento della quota di mercato dei monitor widescreen.
Distribuzioni DI FRAMEWORK per Windows Media Center.
Requisiti di accessibilità.

Informazioni aggiuntive

Idealmente, il gioco viene impostato per impostazione predefinita sulle proporzioni native dello schermo. Tuttavia, ottenere queste informazioni in modo affidabile può essere una sfida, quindi come soluzione più generale il gioco può presupporre che il desktop sia in esecuzione in base alle proporzioni native. La risoluzione del desktop può essere ottenuta chiamando EnumDisplay Impostazioni con ENUM_REGISTRY_edizione Standard TTINGS.

Per altri dettagli, vedi le sezioni Proporzioni e Widescreen dell'articolo Introduzione all'esperienza a 10 piè di pagina per sviluppatori di giochi Windows.

1.6 Supporto dell'avvio da Windows Media Center

[Questo requisito è stato ritirato.]

Supporto direct3D 1.7

Requisito

Se il gioco usa Direct3D, la versione minima supportata deve essere Direct3D 9 e Direct3D deve essere il renderer predefinito selezionato.

Logica

L'architettura grafica principale di Windows Vista e Windows 7 è progettata intorno a Direct3D. Direct3D 8 e versioni precedenti sono supportati tramite il mapping delle interfacce legacy.

L'uso di versioni di Direct3D più recenti rispetto a Direct3D 9 è fortemente consigliato. Vedi i giochi per Windows Showcase S.1. La richiesta di Direct3D 10 o Direct3D 11 è completamente conforme al requisito 1.7.

1.8 Abilitare riconoscimento DPI elevato

Requisito

I giochi e i programmi di installazione devono essere eseguiti correttamente senza problemi visivi quando il ridimensionamento dei punti per pollice (DPI) è abilitato (testato con 144 DPI per la scalabilità del 150% alla risoluzione dello schermo di 1600 1200) in Windows Vista e Windows 7.

Questo richiede in genere che l'eseguibile del gioco dichiari di essere compatibile con DPI. Questa operazione viene eseguita incorporando un elemento manifesto: <dpiAware>true<dpiAware> .

Logica

I monitor LCD di alta qualità sono comuni come schermi del computer, e sembrano meglio quando sono basati sulle loro risoluzioni native (in genere 1280 1024, 1600 1200 e così via). I clienti che hanno difficoltà a leggere il testo e vedere le immagini a questa risoluzione spesso impostano i desktop del computer su una risoluzione inferiore e subiscono artefatti visivi dal ridimensionamento LCD. Al contrario, i clienti possono lasciare la risoluzione alle dimensioni native e modificare il VALORE DPI della visualizzazione di Windows, rendendo così l'aspetto dell'elemento e del testo più grande senza sacrificare la qualità dell'immagine.

Anche se questa funzionalità è disponibile in qualche modo da Windows XP, è raramente abilitata dai clienti o dagli OEM. Più della metà di tutti i display del computer oggi sono impostati su una risoluzione inferiore rispetto alla risoluzione nativa del monitor, in base al feedback dei clienti. Windows 7 rende questa funzionalità molto più visibile ai clienti durante la configurazione iniziale e quando si modificano le impostazioni di visualizzazione, incoraggiandole a usare il ridimensionamento DPI anziché modificare la risoluzione del desktop.

Informazioni aggiuntive

La funzione SetProcessDPIAware può essere invece usata, se chiamata all'inizio del codice di avvio del processo. L'aggiunta al manifesto è preferibile, per assicurarsi che non siano presenti race condition con elementi software (ad esempio DLL) che potrebbero inizializzare prima che venga chiamato il punto di ingresso principale. Si noti che SetProcessDPIAware è presente solo in Windows Vista e Windows 7.

L'aggiunta dell'elemento manifesto è facile da eseguire con Visual Studio 2005 e 2008; creare un file denominato dpiaware.manifest contenente il testo seguente:

            <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
            <asmv3:application>
            <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
            <dpiAware>true</dpiAware>
            </asmv3:windowsSettings>
            </asmv3:application>
            </assembly>

Quindi, all'interno di Visual Studio, aggiungere dpiware.manifest al progetto. Assicurarsi che l'opzione Incorpora manifesto sia impostata su Sì nelle proprietà del progetto. Si noti che le versioni precedenti dello strumento manifesto (Mt.exe) genereranno un avviso spurio con gli elementi manifesto compatibili con DPI. Per risolvere questo problema, aggiornare Mt.exe alla versione più recente da Windows SDK.

Visual Studio 2010 include un'impostazione nelle proprietà del progetto, denominata Abilita riconoscimento DPI, che elimina la necessità di un file come dpiaware.manifest. Trovare Abilita riconoscimento DPI espandendo Proprietà di configurazione e Strumento manifesto e quindi selezionando Input e output.

In Windows, per impostazione predefinita la modalità di visualizzazione tradizionale è 96 DPI, comune per i monitor CRT.

Mentre le applicazioni a schermo intero modificano la risoluzione dello schermo, spesso usano messaggi e metriche delle finestre durante la configurazione di buffer e rettangoli di visualizzazione. La virtualizzazione DPI causa la visualizzazione di queste modalità di visualizzazione a schermo intero ritagliata e la dichiarazione di riconoscimento DPI impedirà questi problemi. Per altre informazioni, vedere Scrittura di applicazioni Win32 compatibili con DPI.

Sicurezza e compatibilità

Riepilogo dei requisiti di sicurezza e compatibilità

Vantaggi dei clienti

I requisiti seguenti migliorano la sicurezza complessiva dei giochi e garantiscono che funzionino con Windows in architetture diverse, in configurazioni diverse e in modalità diverse.

2.1 Seguire le linee guida per il controllo degli account utente

Requisito

Ogni file eseguibile ,ovvero ogni file con estensione exe, deve contenere un manifesto incorporato che ne definisce il livello di esecuzione includendo il tag seguente:

            <requestedExecutionLevel>

Per requisito 1.2, il gioco principale e l'eseguibile di esecuzione automatica devono avere il livello di esecuzione di asInvoker per supportare i contesti utente standard.

I file di dati utente con associazioni di file registrate con Esplora file devono essere inseriti in una sottocartella della cartella specificata da CSIDL_PERSONAL (denominata anche Documenti o Documenti). Tutti gli altri file di dati utente devono essere archiviati in una sottocartella delle cartelle specificate da CSIDL_LOCAL_APPDATA o CSIDL_COMMON_APPDATA. Queste directory sono nascoste per impostazione predefinita per i singoli utenti e per tutti gli utenti.

Logica

L'esperienza di Windows di un utente è più sicura se le applicazioni vengono eseguite solo con le autorizzazioni necessarie.

Informazioni aggiuntive

Se solo alcune funzionalità di un'applicazione richiedono privilegi amministrativi (ad esempio, un'applicazione che deve configurare un firewall), il processo principale dell'applicazione deve comunque essere eseguito usando privilegi utente standard. Le funzionalità che richiedono privilegi amministrativi devono essere spostate in un processo separato, ad esempio un programma di installazione o un'utilità di configurazione.

Se non sono necessari privilegi amministrativi, il codice XML del manifesto incorporato deve includere quanto segue:

            <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
            <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
            <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
            <ms_asmv2:security>
            <ms_asmv2:requestedPrivileges>
            <ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />
            </ms_asmv2:requestedPrivileges>
            </ms_asmv2:security>
            </ms_asmv2:trustInfo>
            </assembly>

Se sono necessari privilegi amministrativi, il codice XML del manifesto incorporato deve includere quanto segue:

            <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
            <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
            <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
            <ms_asmv2:security>
            <ms_asmv2:requestedPrivileges>
            <ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
            </ms_asmv2:requestedPrivileges>
            </ms_asmv2:security>
            </ms_asmv2:trustInfo>
            </assembly>

Con Visual Studio 2005 questo file è facilmente incorporato aggiungendo semplicemente un file manifesto (manifesto) che contiene uno dei blocchi precedenti al progetto e assicurandosi che Embed Manifest sia impostato su Sì nelle proprietà del progetto per lo strumento manifesto. Per Visual Studio 2008 e 2010, le proprietà di Controllo dell'account utente possono essere impostate direttamente nelle proprietà del progetto per il linker nella pagina File manifesto. Si noti che le versioni precedenti dello strumento manifesto (Mt.exe) generano un avviso spurio con gli elementi manifesto del controllo dell'account utente. Per risolvere questo problema, aggiornare Mt.exe alla versione più recente da Windows SDK.

Per informazioni dettagliate sui casi speciali di installazione, applicazione di patch e rimozione, vedere il requisito 3.1.

Le librerie a collegamento dinamico (DLL) non richiedono tali manifesti.

Per altre informazioni sul controllo dell'account utente, vedere Controllo dell'account utente per sviluppatori di giochi.

2.2 Supportare le versioni di Windows x64

Requisito

Per mantenere la compatibilità con le edizioni a 64 bit di Windows, i giochi devono soddisfare i requisiti seguenti.

I titoli e i programmi di installazione del titolo non devono contenere codice a 16 bit o basarsi su qualsiasi componente a 16 bit.
Se il gioco dipende dai driver in modalità kernel per l'operazione, devono essere disponibili versioni x64 di questi driver. La configurazione del gioco deve rilevare e installare i driver e i componenti appropriati per le edizioni a 64 bit di Windows.

Logica

Molti utenti di Windows Vista e Windows 7 eseguiranno edizioni a 64 bit del sistema operativo nel corso della vita del prodotto, quindi è fondamentale che le applicazioni siano compatibili con questo sistema operativo.

Informazioni aggiuntive

Windows in Windows 64 (WOW64) consente l'esecuzione di codice a 32 bit in edizioni a 64 bit di Windows, quindi non è necessario che l'applicazione sia codice nativo a 64 bit nelle edizioni a 64 bit di Windows. Il codice a 64 bit non viene eseguito in edizioni a 64 bit di Windows.

Non è necessario mantenere la compatibilità con Windows XP Professional x64 Edition, ma è fortemente consigliato.

Per informazioni dettagliate, vedere Programmazione a 64 bit per sviluppatori di giochi.

2.3 File di firma

Requisito

Tutti i file di codice eseguibile (in genere, i file con estensione exe o DLL) devono essere firmati con un certificato Authenticode valido pubblicamente e devono avere un URL del server timestamp valido per la firma di produzione.

Se il gioco usa Windows Installer, i file del pacchetto del programma di installazione (file con estensione msi) devono essere firmati.

Logica

La firma di un file consente agli utenti di decidere se considerare attendibile un'applicazione e assicura agli utenti che i file non sono stati manomessi. Consente anche l'esecuzione corretta delle applicazioni in ambienti bloccati.

Informazioni aggiuntive

Per informazioni dettagliate, vedere Authenticode Signing for Game Developers (Firma authenticode per sviluppatori di giochi).

Se il gioco usa Windows Installer, ti consigliamo di abilitare l'applicazione di patch UAC/LUA, includendo una tabella MsiPatchCertificate. Per altre informazioni, vedere Applicazione di patch al controllo dell'account utente.For more information, see User Account Control (UAC) Patching.

Non è consigliabile firmare file cab (cab), a meno che non siano relativamente piccoli (minori di 100 MB).

2.4 Firma driver

Requisito

Qualsiasi driver in modalità kernel installato dal gioco deve essere firmato con un certificato Authenticode valido pubblicamente.

Qualsiasi driver di dispositivo hardware in modalità kernel installato dal gioco deve avere una firma Microsoft, che può essere ottenuta dal programma Windows Hardware Quality Labs (WHQL) o dal programma Driver Reliability Signature (DRS).

Logica

I driver mal scritti o malware possono influire gravemente sulla stabilità e sulla sicurezza di un sistema. Nelle edizioni a 64 bit di Windows Vista e Windows 7 i driver non firmati non vengono caricati. Questo criterio può essere abilitato anche per le edizioni a 32 bit di Windows Vista e Windows 7.

Informazioni aggiuntive

Sono necessarie sia versioni native a 32 bit che a 64 bit di tutti i driver in modalità kernel per ogni requisito 2.2.

Altre informazioni sui programmi di firma dei driver Microsoft sono disponibili in Windows Hardware Dev Center.

2.5 Eseguire il controllo della versione corretto

Requisito

I giochi non devono non riuscire a essere eseguiti nei sistemi operativi futuri, come indicato dalle modifiche apportate al numero di versione di Windows, a meno che il Contratto di licenza con l'utente finale non impedisca l'uso nei sistemi operativi futuri. Se il gioco deve avere esito negativo, deve farlo normalmente visualizzando un messaggio appropriato all'utente.

Se vengono eseguiti controlli delle versioni di Windows, è necessario usare le API di controllo della versione (GetVersionEx o VerifyVersionInfo) per controllare la versione del sistema operativo. Le chiavi del Registro di sistema non devono essere lette per determinare la versione.

I controlli di versione espliciti per il runtime DirectX non devono essere presenti nel gioco. Questi controlli della versione non devono essere presenti nell'installazione che avvia l'installazione del runtime DirectX (DirectSetup).

Logica

Quando gli utenti di Windows aggiornano i sistemi operativi, non devono essere bloccati per giocare ai giochi correnti semplicemente perché il numero di versione di Windows è aumentato. I controlli delle versioni scritti in modo non corretto continuano a creare problemi per il software che, in caso contrario, funziona correttamente nelle versioni più recenti di Windows o semplicemente con l'aggiunta di un Service Pack di Windows.

La logica di confronto del controllo della versione fragile per il runtime DirectX ha creato numerose installazioni non riuscite quando viene eseguita in versioni diverse di Windows. Il numero di versione DirectX si applica solo ai componenti principali del sistema operativo. Non si applica ai componenti DirectX SDK side-by-side usati da molti giochi.

Informazioni aggiuntive

È piuttosto comune vedere i programmi di installazione verificare la presenza di una versione minima del sistema operativo. Questo controllo, tuttavia, deve essere eseguito con attenzione per assicurarsi che verifichi la presenza di valori maggiori o uguali, anziché di uguaglianza semplice, bloccando così una versione specifica del sistema operativo. L'uso del test HighVersionLie di Application Verifier è un modo rapido e semplice per determinare in che modo il programma di installazione reagisce a una modifica significativa del numero di versione del sistema operativo.

L'uso corretto del pacchetto di ridistribuzione del runtime DirectX (installazione DirectX) comporta sempre l'avvio durante l'installazione, preferibilmente in modalità invisibile all'utente. In questo modo il codice fornito da Microsoft può eseguire eventuali aggiornamenti della versione necessari. Consente inoltre l'installazione di qualsiasi componente DirectX SDK side-by-side facoltativo, ad esempio D3DX, XACT, MDX o XInput.

Per le procedure consigliate per la distribuzione del runtime DirectX, vedere Installazione DirectX per sviluppatori di giochi.

È consigliabile che i giochi che supportano il controllo di Windows XP per un livello di Service Pack di 2 o superiore, perché Service Pack 2 (SP2) e Service Pack 3 (SP3) forniscono miglioramenti significativi per la sicurezza, un requisito di ridistribuzione del runtime DirectX semplificato e una distribuzione estremamente ampia. La maggior parte delle tecnologie Microsoft moderne che supportano Windows XP richiede SP2 o SP3 (XAudio2, Giochi per Windows - LIVE e così via).

2.6 Supporta sessioni utente simultanee

Requisito

I giochi che si basano sulla grafica 3D non sono necessari per lavorare su una connessione desktop remoto, ma l'utente deve essere avvisato quando il gioco ha esito negativo.

I giochi devono supportare scenari multitasking di Windows standard rispettando le regole seguenti:

I giochi non devono bloccare l'uso di sessioni utente simultanee.
Un gioco deve essere eseguito in una nuova sessione utente quando è già in esecuzione in un'altra sessione.
Il suono del gioco in una sessione utente non deve essere sentito quando un altro utente è attivo in una sessione diversa.
I giochi devono supportare fast user switching.
I giochi non devono tentare di disabilitare il cambio di attività standard. I giochi non devono disabilitare i tasti di scelta rapida ALT+TAB. I giochi possono disabilitare i tasti di scelta rapida per l'accessibilità, come descritto in Disabilitazione dei tasti di scelta rapida nei giochi.

Logica

Gli utenti di Windows devono essere in grado di eseguire sessioni simultanee senza conflitti o interruzioni. Si tratta di uno scenario comune per un computer Windows condiviso da una famiglia, da compagni di stanza o da altri.

Informazioni aggiuntive

Per verificare se il gioco viene avviato in una sessione remota, chiamare GetSystemMetrics(SM_REMOTEedizione Standard SSION). Un valore diverso da zero indica che la sessione è remota.

Per altre informazioni, vedere Cambio rapido utente. Si noti che il cambio rapido dell'utente si verifica se le restrizioni temporali dei controlli genitori sono abilitate quando il tempo dell'utente è attivo. Per altri dettagli, vedere il requisito 1.2.

2.7 Supporta nomi lunghi

Requisito

Se un gioco supporta il salvataggio di file, deve essere in grado di salvare i file con nomi e percorsi lunghi. Il gioco deve gestire correttamente i caratteri speciali del file system, ad esempio \ / : * ? " <>, in tutti i campi di input utente usati per creare nomi di file o percorsi.

I giochi devono funzionare correttamente quando un utente ha un nome utente lungo.

Logica

I giocatori sono abituati a usare nomi lunghi su percorsi profondi supportati dal sistema operativo sottostante.

Informazioni aggiuntive

I nomi lunghi vengono definiti come quelli che contengono i valori massimi definiti in Windows SDK.

Installazione

Riepilogo dei requisiti di sicurezza e compatibilità

Vantaggi dei clienti

I clienti possono essere certi che le applicazioni verranno installate in Windows senza degradare il sistema operativo o altre applicazioni se le applicazioni usano metodi di distribuzione ufficiali dei componenti del sistema. Un'esperienza di installazione semplificata offre un'esperienza di installazione più accessibile e senza problemi per i giochi.

3.1 Supporta l'installazione semplice

Requisito

I giochi devono fornire un percorso semplificato nell'interfaccia utente di configurazione implementando quanto segue:

Visualizzare un massimo di un prompt del contratto di licenza.
Il percorso di installazione predefinito deve ignorare tutte le selezioni per l'installazione (ad esempio le selezioni di cartelle di installazione o componenti), presupporre le selezioni predefinite e quindi eseguire il gioco o l'utilità di avvio al termine dell'installazione, senza ulteriori richieste. Se necessario, è possibile specificare un'opzione di installazione personalizzata per le opzioni di configurazione avanzate.
Installare tutti i componenti del sistema operativo necessari, ad esempio i runtime DirectX e Visual C, usando i pacchetti di ridistribuzione Microsoft corretti. L'installazione deve essere eseguita in modo invisibile all'utente, senza chiedere conferma e senza essere sorvegliata dai controlli della versione del componente.
Fornire la rimozione tramite Programmi e funzionalità in Pannello di controllo sia per l'applicazione di gioco che per i file di lavoro generati. È consigliabile eliminare tutti i file di dati creati dall'utente. Il processo di rimozione deve assicurarsi che tutti i file installati vengano rimossi e che tutte le impostazioni (ad esempio, le voci dell'elenco di eccezioni del firewall e le chiavi del Registro di sistema) siano cancellate. I componenti del sistema operativo ridistribuito non devono essere rimossi.
Se il gioco richiede l'aggiunta di eccezioni a Windows Firewall, il processo di installazione può richiedere agli utenti di informare gli utenti che questa modifica è necessaria. Questa richiesta dovrebbe essere visualizzata prima dell'inizio dell'installazione.

L'installazione e la rimozione possono richiedere diritti amministrativi. L'applicazione di patch può richiedere la richiesta di credenziali amministrative, a seconda della frequenza di aggiornamento. Il normale gioco del gioco non deve richiedere diritti amministrativi, in base al requisito 2.1 Seguire le linee guida per il controllo dell'account utente.

Logica

L'installazione semplice è una filosofia di sviluppo di giochi basata su Windows progettata per semplificare e semplificare il processo talvolta noioso e confuso di installazione di giochi su computer che eseguono sistemi operativi Windows. L'installazione semplice è abilitata usando un set di tecnologie e procedure consigliate che riducono la complessità non necessaria e il rischio percepito di installare giochi nei computer Windows.

Gli obiettivi principali sono:

Ridurre la quantità di tempo per accedere al gioco e iniziare a giocare.
Ridurre il numero di finestre di dialogo e scelte a pochissimi, o nessuna, per semplificare l'esperienza di installazione del gioco.

Alcune installazioni tradizionali hanno richieste che consentono installazioni non funzionali, anche se l'applicazione sembra essere installata correttamente. Ad esempio, un gioco può richiedere a un utente di accettare un contratto di licenza. Il gioco viene quindi installato e quindi viene visualizzato il contratto di licenza DirectX. Questo contratto di licenza consente agli utenti di rifiutare e quindi ignorare l'installazione del runtime DirectX. Questo scenario può causare un gioco che non riesce a essere eseguito a causa di componenti mancanti.

Informazioni aggiuntive

Per altre informazioni sull'installazione dei giochi, sulle tecniche di installazione di giochi non tradizionali, sulle soluzioni di applicazione di patch compatibili con controllo dell'account utente e sulla gestione delle patch frequenti, vedere gli articoli seguenti su DirectX:

Nota

La rimozione dei file di dati generati dall'utente deve essere eseguita solo per l'utente corrente e per i percorsi utente condivisi comuni. Non esiste un modo affidabile per analizzare il sistema per rimuovere file specifici dell'utente per altri utenti, anche se la rimozione richiede credenziali amministrative.

3.2 Supportare il controllo dell'account utente per l'installazione

Requisito

Il programma di installazione del gioco non deve presupporre che sia in esecuzione nello stesso contesto dell'utente. Le posizioni specifiche dell'utente saranno diverse dal programma di installazione e dal lettore anche per i sistemi a utente singolo a causa dell'elevazione delle credenziali di amministratore. Pertanto, quando un gioco viene eseguito per la prima volta, deve eseguire attività specifiche dell'utente, separatamente dal processo di installazione.

La finestra di dialogo eccezione di Windows Firewall non deve essere visualizzata quando un utente ospita o partecipa a un gioco multiplayer. Tutte le configurazioni necessarie devono essere eseguite al momento dell'installazione. Le istruzioni di installazione devono informare l'utente che questa operazione verrà eseguita come parte dell'installazione.

Il programma di installazione del gioco deve fornire un manifesto incorporato che designi il livello di esecuzione richiesto, in base al requisito 2.1 Seguire le linee guida per il controllo dell'account utente.

Se il gioco viene avviato dal programma di installazione al termine dell'installazione, deve essere avviato nel contesto dell'utente originale.

Logica

Una delle modifiche più grandi apportate al sistema operativo Windows in Windows Vista è l'aggiunta di Controllo account utente (UAC), che esegue applicazioni con privilegi ridotti per impostazione predefinita. Di conseguenza, i programmi di installazione devono gestire i livelli di privilegio di conseguenza. Windows 7 usa anche ampiamente controllo dell'account utente. Anche se Windows 7 migliora l'esperienza utente di Controllo dell'account utente, i programmi di installazione devono comunque soddisfare gli stessi requisiti di Windows Vista per funzionare correttamente, senza basarsi sul comportamento di virtualizzazione potenzialmente confuso.

Controllo dell'account utente è attivo per impostazione predefinita in Windows Vista e Windows 7 e la maggior parte dei clienti (88% o più, in base al feedback) lascia questa funzionalità abilitata.

Informazioni aggiuntive

Per altre informazioni sulla configurazione di Windows Firewall, vedere l'articolo DirectX Windows Firewall per sviluppatori di giochi e l'esempio FirewallInstallHelper.

L'avvio standard del gioco alla fine del processo di installazione non soddisfa l'ultimo aspetto di questo requisito se l'installazione viene avviata da un utente standard e se il processo di installazione richiede privilegi amministrativi (ovvero richiede credenziali di amministratore). Eredita anche privilegi amministrativi, ovvero un potenziale rischio per la sicurezza. Al contrario, un caricatore bootstrap di installazione dovrebbe avviare il gioco dopo la restituzione da una chiamata corretta del programma di installazione. Per altre informazioni, vedere l'articolo di MSDN Magazine Insegnare alle app a giocare bene con il controllo dell'account utente di Windows Vista.

3.3 Installare nelle cartelle corrette

Requisito

Per impostazione predefinita, i giochi installati per tutti gli utenti devono essere installati nella cartella Programmi. I dati utente devono essere scritti quando il gioco viene eseguito per la prima volta, non durante l'installazione.

Logica

Gli utenti devono avere la flessibilità necessaria per installare le applicazioni in cui sono necessarie. Devono anche avere un'esperienza coerente e sicura con il percorso predefinito dei file.

Informazioni aggiuntive

I giochi possono usare i vari percorsi delle cartelle note (ad esempio quelli specificati da CSIDL_LOCAL_APPDATA e CSIDL_COMMON_APPDATA) per archiviare quantità significative di dati di gioco e file eseguibili di supporto per implementare scenari di installazione su richiesta e applicazione di patch avanzati.

Poiché l'installazione può richiedere l'elevazione dei privilegi per un account utente diverso durante il processo di installazione di tutti gli utenti, non esiste un percorso utente corretto in cui archiviare i dati in fase di installazione. Inoltre, se la crittografia dei file è abilitata, i file crittografati possono essere accessibili solo dall'account utente che li ha creati.

3.4 Installare correttamente le risorse di Windows

Requisito

Le applicazioni non devono tentare di installare file o chiavi del Registro di sistema protette da Windows Resource Protection (WRP). Se l'applicazione richiede versioni più recenti dei componenti di sistema, è necessario aggiornare questi componenti usando un Microsoft Service Pack o un pacchetto di installazione approvato da Microsoft che contiene il componente di sistema. I componenti di sistema non devono mai essere riassemblati.

Logica

Windows Resource Protection (WRP) è progettato per garantire che le risorse di sistema protette vengano aggiornate solo tramite meccanismi di installazione o aggiornamento approvati da Microsoft. WRP migliora l'affidabilità del sistema assicurando che i risultati di un'installazione siano prevedibili.

Informazioni aggiuntive

WRP è il successore di Protezione file di Windows, che protegge la maggior parte dei componenti di sistema installati nella cartella Windows. WRP protegge la maggior parte delle chiavi del Registro di sistema che archivia le impostazioni per la creazione di oggetti COM. Riserva anche alcune cartelle per l'uso esclusivo dal sistema operativo. I tentativi di accesso alle risorse protette comportano in genere un errore di negazione dell'accesso.

Per informazioni dettagliate sulle procedure consigliate quando il runtime DirectX viene distribuito con un gioco, vedere l'articolo DirectX Installation for Game Developers (Installazione DirectX per sviluppatori di giochi).

3.5 Evitare riavvii durante l'installazione

Requisito

Il programma di installazione del gioco non deve presupporre che l'installazione dei componenti di Windows dai pacchetti di ridistribuzione richieda un riavvio, a meno che il riavvio non sia indicato da un risultato restituito o dalla documentazione Microsoft.

Se il programma di installazione del gioco forza sempre un riavvio, questo deve essere approvato da Microsoft.

Le finestre di dialogo dei file in uso incluse nei pacchetti di Windows Installer devono contenere un'opzione per chiudere automaticamente le applicazioni e tentare di riavviarle al termine dell'installazione.

Logica

Il riavvio del sistema dopo un'installazione è un'interruzione scomoda per gli utenti e in genere non è necessario.

Informazioni aggiuntive

Per altre informazioni, vedere Uso di Windows Installer con Gestione riavvio.

3.6 Usare correttamente il controllo delle versioni dei file

Requisito: Il programma di installazione del gioco deve verificare correttamente che le versioni dei file più recenti siano installate. L'installazione di un gioco non deve mai regredire i file che non producono o che sono condivisi dalle applicazioni non prodotte.
Logica: I componenti condivisi e i componenti di sistema vengono spesso aggiornati per le correzioni di sicurezza e le funzionalità espanse. Un'installazione che include una versione precedente dei componenti aggiornati non dovrebbe comportare la perdita di aggiornamenti e correzioni già applicate.

3.7 Supportare l'esecuzione automatica [requisito condizionale]

Requisito

Per i giochi distribuiti su CD, DVD o altri supporti rimovibili che supportano l'esecuzione automatica, quando il disco viene inserito per la prima volta, l'applicazione deve eseguire automaticamente o richiedere all'utente di installare il gioco, a meno che l'utente non abbia disabilitato la funzionalità di esecuzione automatica.

Dopo l'installazione dell'applicazione, il reinserimento del disco nell'unità non deve causare l'avvio automatico dell'installazione. È accettabile chiedere agli utenti se vogliono aggiornare o modificare le scelte di installazione.

L'applicazione di esecuzione automatica non deve richiedere l'elevazione dei privilegi ( ovvero deve avere asInvoker nel manifesto, per requisito 2.1, anche se può avviare il programma di installazione o un'altra utilità che richiede diritti amministrativi. L'elevazione deve verificarsi solo se il gioco non è installato o se l'utente lo seleziona in modo specifico.

Logica

L'esecuzione automatica semplifica l'esperienza di utilizzo di applicazioni distribuite tramite supporti, ad esempio giochi che in genere richiedono che il disco sia presente nell'unità per giocare.

Informazioni aggiuntive

Non è accettabile richiedere all'utente di spostarsi in Esplora file per avviare l'installazione dal CD o DVD.

Per i giochi distribuiti su più dischi, i dischi successivi dovrebbero idealmente usare la funzionalità di esecuzione automatica o continuare l'installazione senza chiedere all'utente di premere un tasto o eseguire altre azioni.

Quando si crea un programma di esecuzione automatica, assicurarsi che tutti i componenti necessari siano presenti nelle installazioni nuove di Windows. Le applicazioni tipiche si basano sulle tecnologie installate dall'installazione, ma l'esecuzione automatica viene eseguita prima che si verifichi tale installazione. Un esempio comune è l'errore dei programmi di esecuzione automatica perché le DLL di Visual C Runtime non sono state incluse come parte dell'installazione di Windows. Il programma di esecuzione automatica, pertanto, deve usare la distribuzione CRT locale dell'applicazione o deve collegare in modo statico il CRT.

I programmi di esecuzione automatica scritti per l'uso nelle versioni di Windows prima di Windows Vista non devono usare il runtime .NET perché questa tecnologia non è inclusa in Windows XP o versioni precedenti di Windows. Windows Server 2003 e Windows Vista sono le prime versioni di Windows per includere il runtime .NET come parte del sistema operativo.

Per motivi simili, i programmi di esecuzione automatica non possono richiedere la presenza di componenti facoltativi di DirectX SDK affiancati, ad esempio D3DX9, D3DX10, D3DX11, XAudio2, X3DAudio, XACT, XINPUT e MDX 1.1.

Per un esempio di utilizzo dell'esecuzione automatica, vedere Esempio di esecuzione automatica.

Affidabilità

Riepilogo dei requisiti di sicurezza e compatibilità

Vantaggi dei clienti

Questi requisiti rendono un'applicazione più affidabile riducendo al minimo il numero di arresti anomali, blocchi e riavvii. I requisiti di affidabilità consentono di garantire che il software sia più prevedibile, gestibile, resiliente e recuperabile.

4.1 Eliminare i riavvii non necessari

Requisito

Tutti i programmi di installazione delle applicazioni devono sfruttare le API di Gestione riavvio per evitare i riavvii del sistema (vedere il requisito 3.5).

I giochi non devono bloccare l'arresto.

Tutte le applicazioni devono rispondere al gestore di riavvio ascoltando e rispondendo ai messaggi di arresto seguenti:

WM_QUERYENDedizione Standard SSION con LPARAM = END edizione StandardSSION_CLOedizione Standard APP (0x1): Le applicazioni GUI devono rispondere immediatamente (TRUE) in preparazione di un riavvio.
WM_ENDedizione Standard SSION con LPARAM = END edizione StandardSSION_CLOedizione Standard APP (0x1): Le applicazioni devono restituire un valore 0 entro 5 secondi e quindi chiudere.
CTRL+C: Le applicazioni console che ricevono questo messaggio devono chiudersi immediatamente.

Logica

I riavvii del sistema sono un'interruzione importante. Portano a un'esperienza utente non valida e devono essere ridotte a icona. Alcune operazioni, ad esempio gli aggiornamenti critici del sistema, possono richiedere riavvii. Ascoltando i messaggi di arresto, il gioco e altre applicazioni possono reagire tempestivamente alle richieste dal gestore di riavvio. In questo modo, possono evitare ritardi inutilmente nelle richieste di riavvio valide.

Informazioni aggiuntive

Se un programma di installazione del gioco usa la tecnologia Windows Installer (MSI) senza azioni personalizzate, questa funzionalità viene fornita automaticamente. I pacchetti di ridistribuzione Microsoft supportano anche Gestione riavvio.

Per altre informazioni su Gestione riavvio, vedere l'articolo MSDN About Restart Manager.For more information about the Restart Manager, see the MSDN article About Restart Manager.

4.2 Eliminare gli errori di verifica delle applicazioni

Requisito

Il gioco non deve generare errori in esecuzione in Microsoft Application Verifier (AppVerifier), versione 4.0 o successiva, nei test seguenti:

Nozioni di base: handle, heap, blocchi, memoria, TLS
Varie: DangerousAPIs, DirtyStacks

Logica

AppVerifier verifica molti problemi noti che causano arresti anomali e blocchi nelle applicazioni Windows, nonché vulnerabilità di sicurezza note.

Informazioni aggiuntive

Per altre informazioni su Application Verifier, vedere Application Verifier and Using Application Verifier within Your Software Development Lifecycle .For more information about Application Verifier, see Application Verifier and Using Application Verifier within your Software Development Lifecycle.

Questo requisito non si applica alle applicazioni gestite pure senza interoperabilità nativa.

Questi test devono essere eseguiti in una build di versione. Il debug delle compilazioni può generare errori falsi. Alcune tecnologie anti-pirateria e anti-truffa possono interferire con l'esecuzione di AppVerifier. Pertanto, questi test devono essere eseguiti senza tecnologie anti-pirateria e anti-inganno abilitate.

Potrebbe essere necessario impostare la proprietà Full del test Basics:Heaps su FAL edizione Standard, perché l'intero pageHeap aumenta notevolmente la pressione di memoria dell'applicazione in esecuzione. Gli errori verranno comunque rilevati, ma potrebbero essere più difficili da rilevare se si usa solo PageHeap parziale.

Se si usano i test correlati a UAC/LUA in Application Verifier per soddisfare i requisiti di controllo dell'account utente 2.1 e 3.2, è consigliabile usare l'analizzatore utente standard per esaminare i risultati. Sono inoltre disponibili numerosi altri test utili forniti da Application Verifier, che si consiglia di usare in fase di sviluppo e test per garantire un elevato livello di compatibilità con le versioni correnti e future di Windows. Il test HighVersionLie viene usato per verificare la conformità con il requisito 2.5.

Visual Studio Team System include un subset della funzionalità AppVerifier integrata nell'ambiente di debug. Ciò può risultare utile per tenere traccia e risolvere i problemi relativi ai test di base: heap, handle e blocchi.

4.3 Supporto Segnalazione errori Windows e informazioni sulla versione dei file

Requisito

Per abilitare il supporto di Segnalazione errori Windows, i giochi devono soddisfare i requisiti seguenti:

I giochi devono gestire solo le eccezioni note e previste. Segnalazione errori Windows non deve essere disabilitato. Se un errore, ad esempio una violazione di accesso, viene visualizzato in un gioco, deve consentire Segnalazione errori Windows di segnalare l'arresto anomalo.
Tutti i file eseguibili (ad esempio, file con estensione exe o DLL) devono contenere un nome di prodotto, un nome della società e una versione del file accurati.
L'uscita normale del gioco non deve generare un errore di eccezione sconosciuto.

Logica

Le API Segnalazione errori Windows forniscono feedback vitale a Microsoft per rilevare arresti anomali e blocchi diffusi nelle applicazioni. Ciò consente a Microsoft e ai suoi partner di rilevare e risolvere rapidamente i problemi di sistema e driver che generano rapidamente errori dell'applicazione.

Informazioni aggiuntive

I giochi possono includere gestori di eccezioni non gestiti personalizzati per eseguire funzionalità personalizzate di supporto e creazione di report, ma devono passare qualsiasi errore alle funzioni ReportFault o WerReportSubmit .

Le informazioni sulla versione del file appropriate possono essere verificate visualizzando le proprietà del file nell'interfaccia utente desktop di Windows e controllando la pagina delle proprietà Version.

Per altre informazioni sulle API Segnalazione errori Windows e su come analizzare i dump di arresto anomalo del sistema generati quando si usa questo servizio, vedere l'articolo DirectX Crash Dump Analysis.

Terminologia del controller comune xbox 360 per Windows

Nome	Descrizione
Un	Pulsante A.
G	Pulsante B.
INDIETRO	Pulsante Indietro.
(destro/sinistro) paraurti	Pulsante in alto a destra e a sinistra del controller. Equivale a un pulsante a spalla.
riquadro direzionale	Riquadro direzionale del controller.
D-pad	Abbreviazione accettata del riquadro direzionale.
Punto di distribuzione (DP)	Abbreviazione del riquadro direzionale e etichetta del controller.
RB, LB	Abbreviazioni del paraurti destro e sinistro e etichette del controller.
RS, LS	Abbreviazioni delle levette destra e sinistra e etichette del controller.
RT, LT	Abbreviazioni dei trigger destro e sinistro e etichette del controller.
RSB, LSB	Abbreviazioni delle levette destra e sinistra e etichette del controller.
AVVIA	Pulsante Start.
(levetta destra/sinistra)	Stick del controller. In precedenza levetta.
(pulsante a destra/sinistra)	Pulsante della levetta del controller. In precedenza il pulsante della levetta.
(trigger destro/sinistro)	Trigger del controller.
Vibrazione	Feedback di gioco prodotto dal motore del controller. Non usare rumble.
X	Pulsante X.
Y	Pulsante Y.
Controller Xbox 360 per Windows	Il game pad Xbox 360 venduto come SKU hardware del PC, incluso un disco del driver di dispositivo Windows.
Controller wireless Xbox 360 per Windows	Il game pad wireless Xbox 360 venduto come SKU hardware del PC, incluso un disco del driver di dispositivo Windows.

Linee guida per i prodotti middleware di gioco

Introduzione

Per qualificare i giochi per il programma Giochi per Windows, devono soddisfare un elenco di requisiti tecnici. Tutti i componenti di terze parti forniti con un titolo (file eseguibili, DLL, driver e così via) devono soddisfare anche questi requisiti per qualificare il gioco. Questo documento evidenzia i requisiti più comuni che devono essere soddisfatti anche dai componenti di terze parti per il gioco per superare i test di conformità. I programmi di installazione e i pacchetti completi di motore di gioco/produzione devono esaminare il documento completo Sui giochi per i requisiti tecnici di Windows, perché molti di questi requisiti sono interessati da questi strumenti.

Consigli aggiuntive

Oltre a garantire che il componente supporti la creazione di titoli conformi ai requisiti per Giochi per Windows, esistono alcune altre considerazioni da tenere in considerazione quando si progetta e si distribuisce una libreria o un'utilità di supporto per un gioco Di Windows.

Per supportare gli sviluppatori che lavorano su applicazioni x64 native a 64 bit, fornire versioni native a 32 bit e a 64 bit delle librerie. La versione a 32 bit deve essere compatibile a 64 bit per 2.2. Le librerie per le applicazioni a 32 bit non devono presupporre che il bit elevato di qualsiasi indirizzo a 32 bit non sia usato per supportare l'uso all'interno di applicazioni LARGEADDRESSAWARE x86.
Se si forniscono intestazioni di codice nativo (C/C++), usare la sintassi dell'attributo SAL (Standard Annotation Language) per decorare le routine API pubbliche. Ciò consentirà agli utenti della libreria di ottenere il massimo vantaggio dall'uso dell'analisi statica del codice (/analisi), che fa parte di Visual Studio Team System 2005, Visual Studio Team System 2008, Visual Studio 2010 Premium e Visual Studio 2010 Ultimate, nonché degli strumenti del compilatore Di Windows SDK disponibili pubblicamente.
Se il prodotto crea thread all'interno del processo dell'utente, assicurarsi di denominare ogni thread in modo che gli strumenti di debug possano annotare correttamente i thread in esecuzione.
Se scrivi routine destinate a essere chiamate all'interno del ciclo principale di un gioco, usa le routine D3DX D3DPERF_BeginEvent/EndEvent e D3DPERF_SetMarker per annotare le operazioni di alto livello per facilitare l'identificazione dei colli di bottiglia usando PIX per Windows.

Nota

Per la funzionalità di diagnostica grafica di Visual Studio 2012, queste routine D3DX e PIX vengono sostituite dall'interfaccia ID3DUserDefinedAnnotation .
Per le librerie di rete, fornire implementazioni indipendenti da IP ed evitare routine IPv4 deprecate solo per supportare le tecnologie IPv6 e Teredo in Windows XP con Service Pack 2, Windows Vista e Windows 7.
I provider di servizi di gioco devono registrarsi con Games Explorer usando la versione 2 dello schema GDF e usare la funzionalità RSS per fornire notizie correlate al servizio.

Giochi per le vetrine di Windows

Introduzione

I giochi per Windows vanno oltre a offrire un'esperienza di gioco solida nei PC Windows. Implementando queste funzionalità, i giochi possono aggiungere più entusiasmo all'esperienza utente nelle piattaforme Windows più recenti.

I giochi per i titoli di Windows devono soddisfare tutti i requisiti tecnici elencati in questo articolo, ma le funzionalità di presentazione sono facoltative. Questi titoli sono liberi di implementare alcuni, nessuno o tutte queste vetrine.

S.1 Exploit Direct3D 11

Requisito

Direct3D 11 è l'API di rendering di nuova generazione per Windows Vista e Windows 7. I giochi che sfruttano Direct3D 11 usano contenuti ottimizzati, tecniche di rendering avanzate e nuove funzionalità hardware per creare un'esperienza accattivante sull'hardware che supporta 10, 10.1 e 11.

Se il gioco implementa anche Direct3D 9, un confronto affiancato dovrebbe dimostrare un miglioramento comprensibile della qualità del contenuto, della fedeltà visiva, delle prestazioni, della complessità della scena e di altre aree di fedeltà grafica per Direct3D 11. Questo supporto è soggetto ai Giochi per Windows Technical Requirement 1.7.

La tecnologia Direct3D 10level9 può essere usata per supportare l'hardware video direct3D 2.0/3.0 Direct3D a 9 classi in Windows Vista e Windows 7, invece di usare un'implementazione Direct3D 9 side-by-side per un ampio supporto hardware. Tuttavia, questo non è sufficiente per dimostrare questa presentazione.

Nei computer che eseguono Windows Vista o Windows 7 con Direct3D 11 installato, per impostazione predefinita il gioco deve usare Direct3D 11.

Logica

L'API Direct3D 11 si basa sull'infrastruttura WDDM (Windows Display Driver Model) e Direct3D 10.1 per supportare nuove funzionalità: tassellatura hardware, shader di calcolo, rendering multithreading e creazione di risorse, nuovi formati di compressione delle trame e un linguaggio shader più flessibile. Direct3D 11 fornisce supporto hardware unificato per le schede video moderne, incluse le parti direct3D 11 di ultima generazione, tutte le schede video Direct3D 10 e 10.1 e molte schede video del modello shader 2.0/3.0 Direct3D 9, ovvero l'hardware video minimo necessario per il desktop Aero 3D.

Informazioni aggiuntive

La migrazione di un motore di rendering Direct3D 9 per l'uso della nuova interfaccia Direct3D 11 è un'attività ben definita:

Eliminare tutte le operazioni a funzione fissa a favore degli shader programmabili.
Aggiornare tutti gli shader esistenti alla nuova sintassi del modello shader 4.x/5.
Aggiornare la gestione delle risorse per supportare il nuovo modello di visualizzazione.
Convertire tutti gli asset per usare un nuovo elenco di formati disponibili.
Aggiornare la gestione dello stato di rendering per usare blocchi di stato non modificabili e rielaborare le costanti shader in buffer costanti.

Questa conversione è essenziale per abilitare la presentazione di Direct3D 11, anche se il risultato non soddisfa il requisito di presentazione di sfruttare la nuova API.

La nuova API e il modello di programmazione HLSL associato offrono molte opportunità per contenuti avanzati:

Sfruttando le funzionalità hardware Direct3D 10 esistenti, ad esempio Geometry Shader, Stream Out, matrici di trame e formati di trama compressi BC4/BC5.
Sfruttando le funzionalità hardware esistenti di Direct3D 10.1, ad esempio modalità di fusione indipendenti per destinazione di rendering, profondità MSAA, accesso msaa per shader per campione, matrici di mappe cubi e rendering in formati con compressione a blocchi (BC).
Implementazione di algoritmi GPU avanzati tramite Compute Shader con CS4.x nelle schede video Direct3D 10/10.1 esistenti (abilitate dai driver video aggiornati) o CS 5.0 nelle schede video Direct3D 11 di nuova generazione.
Rendering su più thread usando la creazione di risorse a thread libero e più contesti di dispositivo per migliorare le prestazioni nei sistemi multicore (con driver video aggiornati). Per altre informazioni, vedere Giochi per Windows Showcase S.3.
Utilizzo di nuove funzionalità di hardware video di classe Direct3D 11, ad esempio tassellatura hardware con hull shader e domain shader, Shader Model 5.0 HLSL shader hardware funzionalità BC6HBC7 formati di trama compressi e Collegamento di Dynamic Shader.

Le tecniche che possono essere implementate con Direct3D 9 (in gran parte tramite un costo elevato della CPU) possono essere scaricate nella GPU in modo efficiente, liberando così risorse CPU per supportare altre richieste di gioco.

Le API Direct3D 11, gli strumenti di supporto e gli esempi sono disponibili in DirectX SDK. Vedere anche API grafiche in Windows.

S.2 Exploit x64 Native

Requisito

Il gioco include un eseguibile nativo a 64 bit che offre una nuova esperienza interessante abilitata dalle edizioni x64 di Windows in esecuzione su hardware con supporto x64. Un confronto affiancato con la versione a 32 bit del gioco dovrebbe mostrare un miglioramento comprensibile della complessità dei contenuti, riduzione dei tempi di caricamento complessivi e delle prestazioni.

Nelle edizioni a 64 bit di Windows, l'installazione deve sempre configurare la versione nativa a 64 bit del gioco come impostazione predefinita per i collegamenti in Games Explorer e Windows XP Professional x64 Edition. Se si desidera un'installazione doppia, è possibile specificare un'attività di riproduzione aggiuntiva per Esplora giochi in Windows Vista e Windows 7 che punta alla versione a 32 bit, ma il valore predefinito deve rimanere la versione nativa a 64 bit.

Tieni presente che il gioco dovrebbe supportare le edizioni a 64 bit di Windows Vista e Windows 7 per soddisfare questa raccomandazione di presentazione. Il supporto per Windows XP Professional x64 Edition è consigliato, ma non obbligatorio.

Logica

La tecnologia x64 offre funzionalità di indirizzamento a 64 bit per i mercati consumer e server che includono la velocità completa a 32 bit per le applicazioni esistenti. x64 è una parte fondamentale della roadmap per AMD (AMD64) e Intel (EMT64) e, ad eccezione delle CPU ultra-mobili, supporta la tecnologia per tutti i processori di generazione correnti e futuri.

Windows XP Professional x64 Edition è stato il primo sistema operativo Windows orientato al consumer per supportare la tecnologia x64 e Windows Vista e Windows 7 espandono notevolmente la disponibilità dell'abilitazione del sistema operativo per il consumer computing a 64 bit. Con 2 GB di RAM come standard in molti nuovi computer, ulteriori miglioramenti nel ridimensionamento della memoria non trarranno vantaggio dalle singole applicazioni a 32 bit che non sono in grado di gestire più di 2 GB di RAM fisica. Molti giochi oggi si trovano ad affrontare sfide che adattano tutti i contenuti disponibili ai vincoli di 2 GB di spazio di indirizzi virtuali, soprattutto se combinati con le grandi memorie video disponibili su GPU di fascia alta e il passaggio alla tecnologia x64 aumenta notevolmente i livelli di dettaglio supportabili.

La compatibilità x64 per i giochi a 32 bit è un requisito tecnico di Giochi per Windows (2.2), ma sfruttare appieno le nuove tecnologie richiede un'implementazione nativa a 64 bit.

Informazioni aggiuntive

Il vantaggio principale dell'indirizzamento a 64 bit è la possibilità di accedere direttamente a più di 2 GB di memoria fisica e virtuale. Lo spazio di indirizzi della memoria virtuale di grandi dimensioni consente un uso esteso di I/O mappato alla memoria senza problemi di esaurimento dello spazio degli indirizzi della macchina virtuale prevalente nella programmazione a 32 bit. I giochi possono sfruttare il nuovo spazio per migliorare notevolmente i tempi di caricamento o, in alcuni casi, per eliminare le pause per il caricamento del contenuto.

Le applicazioni a 32 bit esistenti possono trarre vantaggio dalle edizioni x64 grazie alla possibilità di elaborare gli indirizzi con dati completi a 32 bit quando compilati con l'opzione del linker Enable Large Addresses (/LARGEADDRESSAWARE). Nelle versioni a 32 bit di Windows XP, le modalità di avvio speciali hanno consentito a tali applicazioni di gestire fino a 3 GB di RAM e le edizioni x64 offrono l'accesso a un massimo di 4 GB di RAM per app laA (Large Address Aware). Sebbene l'uso di LAA in un'applicazione a 32 bit non soddisfi questo requisito di presentazione, questa tecnologia bridge è un modo estremamente utile per offrire vantaggi di scalabilità aggiuntivi nelle versioni x64 di Windows per coloro che non implementano completamente questo requisito di presentazione.

Per altre informazioni, vedere Programmazione a 64 bit per sviluppatori di giochi e RAM, VRAM e Altro RAM: giochi a 64 bit è qui nel sito Web per sviluppatori di giochi.

Nota

Una sfida fondamentale per questa presentazione è garantire che tutte le librerie o i componenti di terze parti su cui si basa il gioco siano disponibili per lo sviluppo nativo a 64 bit. Molte API Microsoft legacy sono state eliminate anche dall'ambiente nativo a 64 bit, che può dimostrare una sfida per le codebase del motore contenenti implementazioni precedenti dei sistemi chiave.

S.3 Exploit Many-Core Processors

Requisito

Il gioco implementa funzionalità che sfruttano i processori multicore, il ridimensionamento a 3, 4 o più core, quando disponibile.

Se il gioco supporta sistemi a processore singolo o dual core, un confronto affiancato con un sistema quad-core deve dimostrare nuove funzionalità, effetti interessanti aggiuntivi, miglioramento della qualità del contenuto e/o prestazioni migliorate.

Poiché il ridimensionamento dual core è già ampiamente supportato dai giochi, così come usato automaticamente da vari miglioramenti dei driver Direct3D, la scalabilità dual-core non è sufficiente per dimostrare questa presentazione.

Logica

La continua crescita delle prestazioni per le CPU è passata dai miglioramenti della frequenza di clock all'aggiunta di core di calcolo. Entrambe le roadmap AMD e Intel sono basate su progettazioni multicore scalabili. Tutte le piattaforme di gioco di nuova generazione hanno CPU multicore a causa di questo cambiamento fondamentale nell'evoluzione dei processori. Le applicazioni a thread singolo non vedranno più vantaggi significativi dalle CPU di nuova generazione. Il multithreading semplice non riuscirà anche a ridimensionarsi man mano che il numero di core CPU in uso comune cresce fino a tre o più.

Informazioni aggiuntive

Si noti che i conteggi dei core non devono essere una potenza di due, quindi i giochi devono essere ridimensionati in modo lineare e gestire i conteggi dei core di 3, 4, 5, 6, 7, 8 e così via.

Il ridimensionamento aumentando il numero di thread in un'applicazione restituisce solo se il costo della comunicazione e della sincronizzazione dei thread viene mantenuto in controllo. Il ridimensionamento basato sulle funzionalità può dimostrare una soluzione più semplice a breve termine, consentendo al gioco di funzionare normalmente senza i thread aggiuntivi nei sistemi a core singolo e abilitandoli quando è disponibile la potenza aggiuntiva della CPU.

Per altre informazioni, vedi Codifica per più core in Xbox 360 e Microsoft Windows e Considerazioni sulla programmazione senza blocchi per Xbox 360 e Microsoft Windows negli articoli DirectX, nonché l'utilità DXUTLockFreePipe e l'esempio CoreDetection.

L'uso della creazione di risorse a thread libero Direct3D 11 e dei contesti di dispositivo è utile per ottenere una scalabilità molti core per il rendering e il caricamento delle risorse grafiche. Vedi Giochi per Windows Showcase S.1.

Si noti che l'uso diretto dell'istruzione CPU rdtsc, invece di usare le API Windows per calcolare i tempi nei sistemi multicore, può causare problemi in alcune configurazioni hardware e del sistema operativo; vedere Game Timing and Multicore Processors (Tempi dei giochi e processori multicore) negli articoli directX.

S.4 Support Games for Windows - LIVE

Giochi per Windows - LIVE non è più supportato da Microsoft.

S.5 Supporta Windows Touch

Requisito

I giochi con supporto per il tocco di Windows sono riproducibili tramite tocco e/o movimenti nei computer che eseguono Windows 7 con un touchscreen. È anche possibile usare l'input da tastiera, ma l'interfaccia di riproduzione principale deve essere basata sul tocco.

L'abilitazione del tocco non deve impedire l'uso del mouse o del controller comune, soggetto al requisito tecnico 1.4.

Il programma di installazione del gioco non dovrebbe supportare la funzionalità Windows Touch.

Logica

Gli schermi con supporto per il tocco per i computer sono disponibili per portatili e desktop e rappresentano una funzionalità hardware chiave promossa con il rilascio di Windows 7. Windows 7 supporta Windows Touch in tutte le interfacce desktop e controlli comuni.

Informazioni aggiuntive

Le applicazioni di codice nativo possono accedere al multitocco tramite i messaggi WM_TOUCH, in combinazione con la funzione RegisterTouchWindow. Vedere anche l'API Manipulations and Inertia (Manipolazioni e inerzia).

Windows Presentation Foundation (WPF) 4.0 offre una soluzione gestita per le interfacce multitocco.

Per altre informazioni, vedere Windows Touch SDK.

S.6 Supporta il colore elevato

Requisito

I giochi che supportano il colore elevato usano un formato 10:10:10:2 (DXGI_FORMAT_R10G10B10A2, D3DFMT_A2B10G10R10) o 16:16:16:16 (DXGI_FORMAT_R16G16B16A16, D3DFMT_A16B16G16R16) per il rendering back-buffer e la modalità schermo intero.

Usando una destinazione di rendering a colori elevato, il rendering del contenuto HDR (High-Dynamic Range) può essere eseguito con una gamma estesa o estesa quando si esegue il mapping del tono a un intervallo a 10 bit o a 16 bit.

Logica

I monitor sono stati in grado di visualizzare più di 256 livelli di colore per canale per molti anni, anche quando i display CRT erano prevalenti. L'hardware di scansione nelle schede video è stato il fattore di limitazione. Gpu moderne, tra cui la maggior parte dell'hardware direct3D di classe 9 e di tutti i componenti hardware direct3D 10 e migliori, hanno hardware di scansione in grado di almeno 10 bit per canale e la funzionalità hardware è impostata per crescere a 16 bit per canale colore in futuro. I sistemi di interconnessione HD TV (HDMI, DisplayPort) sono stati progettati per gestire anche più di 8 bit per canale e VGA analogico conterrà già tali segnali.

Informazioni aggiuntive

Si noti che il colore elevato, o Hi Color, storicamente si riferisce allo spostamento da 256 (8 bit) colori visualizzati a colori a 15 o a 16 bit. La maggior parte dei sistemi di visualizzazione è passata a True Color, ovvero a 24 bit, o a 8 bit per canale di colore per rosso, verde e blu. Per High Color qui si intende una nuova generazione di sistemi di visualizzazione che possono funzionare con più di 8 bit per singolo canale di colore. Viene anche definito colore profondo.

Procedure consigliate

Introduzione

Oltre a soddisfare i requisiti tecnici e ad adottare una o più vetrine nel tuo titolo, ci sono una serie di procedure consigliate che devono essere seguite per tutti i giochi di Windows. Anche se questi consigli non rientrano nell'ambito dei requisiti tecnici di base, è consigliabile usarli per tutti i giochi per i titoli di Windows.

Consigli aggiuntive

Usare il compilatore e il runtime di Visual Studio più recenti. Le versioni più recenti del compilatore implementano miglioramenti significativi per la qualità del codice generato e per i problemi di sicurezza e usano strategie di ottimizzazione del processore moderne. L'aggiornamento del compilatore e l'uso della versione più recente di C Runtime è un modo semplice per eseguire la migrazione alle procedure di codifica moderne.
Usare la versione DLL (Dynamic Link Library) del runtime C, anziché il collegamento statico e usare Secure CRT. (Le eccezioni possono essere effettuate in casi speciali di preinstallazione, ad esempio per un programma di esecuzione automatica o per il programma di installazione stesso).
Per l'audio del gioco, usare XAudio2, X3DAudio e/o XACT, anziché DirectSound. Per i motori audio che eseguono tutte le operazioni di combinazione e conversione della frequenza di origine e richiedono solo una soluzione a bassa latenza per l'output audio, usare DirectSound su Windows XP (solo) e WASAPI in Windows Vista e Windows 7.
Evitare di usare API legacy e deprecate: DirectDraw, DirectSound, DirectPlay, Direct Musica livello di prestazioni, DirectPlay Voice e Modalità mantenuta Direct3D. Si noti che DirectPlay Voice e Direct3D Modalità mantenuta non sono disponibili in Windows Vista o Windows 7. Il livello di prestazioni di DirectPlay e Direct Musica non sono disponibili per le applicazioni native x64.
Ottimizzare l'uso di set di istruzioni SIMD S edizione Standard/S edizione Standard 2. Vedi l'API DirectXMath in Windows SDK come soluzione multipiattaforma per operazioni matematiche ottimizzate per SIMD.
Usare le procedure consigliate moderne per la sicurezza di Windows (incluse le opzioni del compilatore e del linker come /NXCOMPAT, /GS, /SAFE edizione Standard H, /DYNAMICBA edizione Standard, /SDL e così via). Per altre informazioni, vedere Best Security Practices in Game Development.For more information, see Best Security Practices in Game Development.
Usare i componenti e le librerie più recenti di Windows SDK. Rimuovere le dipendenze dai componenti legacy DirectSetup distribuiti fuori banda, ad esempio D3DX9, D3DX10 e D3DX11. Prendere in considerazione l'uso di DirectXTex o DirectXTK o entrambi.
Evitare di usare il compilatore HLSL precedente e usare invece il compilatore HLSL moderno. Se il supporto per Pixel Shader 1.x è richiesto dall'applicazione, usare l'assembly shader anziché HLSL o limitare l'uso del compilatore precedente solo a tali scenari.

Risorse

Termine	Descrizione
Giochi per Windows: Test Case	Procedure consigliate per i giochi in Windows XP, Windows Vista e Windows 7
Windows SDK	SDK di Windows
Linee guida per il controllo dell'account utente	Requisiti di sviluppo dell'applicazione Windows Vista per la compatibilità del controllo dell'account utente
Portale per sviluppatori DirectX	Centro per sviluppatori Directx
Blog di Giochi per Windows e DirectX SDK	Giochi per Windows e DirectX SDK
Articoli aggiuntivi su DirectX	Articoli tecnici DirectX

Condividi tramite

Giochi per i requisiti tecnici di Windows: Procedure consigliate per i giochi in Windows XP, Windows Vista, Windows 7 e Windows 8

Differenze per Windows 8

Informazioni aggiuntive

Giochi per Windows

1.1 Integrazione di Games Explorer

1.2 Supporto famiglia Cassaforte ty /Parental Controls

1.3 Supportare giochi avanzati salvati

1.4 Supportare il controller comune xbox 360 per Windows [requisito condizionale]

1.5 Supportare più proporzioni e risoluzioni

1.6 Supporto dell'avvio da Windows Media Center

Supporto direct3D 1.7

1.8 Abilitare riconoscimento DPI elevato

Sicurezza e compatibilità

2.1 Seguire le linee guida per il controllo degli account utente

2.2 Supportare le versioni di Windows x64

2.3 File di firma

2.4 Firma driver

2.5 Eseguire il controllo della versione corretto

2.6 Supporta sessioni utente simultanee

2.7 Supporta nomi lunghi

Installazione

3.1 Supporta l'installazione semplice

3.2 Supportare il controllo dell'account utente per l'installazione

3.3 Installare nelle cartelle corrette

3.4 Installare correttamente le risorse di Windows

3.5 Evitare riavvii durante l'installazione

3.6 Usare correttamente il controllo delle versioni dei file

3.7 Supportare l'esecuzione automatica [requisito condizionale]

Affidabilità

4.1 Eliminare i riavvii non necessari

4.2 Eliminare gli errori di verifica delle applicazioni

4.3 Supporto Segnalazione errori Windows e informazioni sulla versione dei file

Terminologia del controller comune xbox 360 per Windows

Linee guida per i prodotti middleware di gioco

Introduzione

Consigli aggiuntive

Giochi per le vetrine di Windows

Introduzione

S.1 Exploit Direct3D 11

S.2 Exploit x64 Native

S.3 Exploit Many-Core Processors

S.4 Support Games for Windows - LIVE

S.5 Supporta Windows Touch

S.6 Supporta il colore elevato

Procedure consigliate

Introduzione

Consigli aggiuntive

Risorse

Commenti e suggerimenti

Commenti e suggerimenti

Risorse aggiuntive