Spécifications techniques des jeux pour Windows : bonnes pratiques pour les jeux sur Windows XP, Windows Vista, Windows 7 et Windows 8

Article
08/07/2024

Cet article fournit les exigences techniques et les bonnes pratiques pour les jeux fonctionnant sur Windows. Nous avons rédigé ces exigences techniques et ces bonnes pratiques principalement pour couvrir Windows Vista et Windows 7, ainsi que le système d’exploitation Windows XP. Ces bonnes pratiques s’appliquent également aux jeux de bureau Win32 sur Windows 8.

Cet article contient les sections suivantes :

Différences pour Windows 8
- Informations supplémentaires
Jeux pour Windows
Sécurité et compatibilité
Installation
Fiabilité
Terminologie de la manette Xbox 360 pour Windows
Directives pour les produits middleware de jeux
Ressources

Différences pour Windows 8

Voici un résumé des principales différences lors de l’application de ces exigences techniques et bonnes pratiques à Windows 8.

L’interface utilisateur de l’Explorateur de jeux n’est pas visible

Tous les jeux que vous enregistrez avec l’Explorateur de jeux apparaissent sous forme de tuiles dans la nouvelle interface utilisateur de Windows, mais une grande partie des métadonnées associées au titre n’est plus visible. Vous utilisez toujours l’outil de création de fichier de définition de jeux (GDFMAKER.EXE), désormais disponible dans le kit de développement logiciel Windows (SDK), pour créer les métadonnées. Vous utilisez également les mécanismes existants pour déployer les métadonnées. Continuez à tester votre enregistrement à l’Explorateur de jeux en utilisant Windows 7, et vérifiez que la tuile de la nouvelle interface utilisateur Windows apparaît lorsque vous l’installez sur Windows 8 (veuillez consulter la section 1.1 Intégration à l’Explorateur de jeux).

Pour télécharger le SDK Windows 8, consultez Téléchargements pour le développement d’applications de bureau.

L’enregistrement avec les API de l’Explorateur de jeux reste le mécanisme pour enregistrer votre jeu avec le contrôle parental Windows

Nous vous recommandons d’exécuter la version Windows SDK de GDFMAKER sur la version publiée de Windows 8 pour vous assurer qu’elle peut peupler tous les systèmes de notation actuellement pris en charge.

Remarque

Cette version de GDFMAKER nécessite .NET 4.0.

Veuillez consulter la section 1.2 Prise en charge de la sécurité familiale / Contrôle parental.

Il existe maintenant trois choix pour utiliser l’API XINPUT selon vos besoins

XINPUT 1.4 est intégré à Windows 8. Les applications du Windows Store et les applications de bureau Win32 peuvent utiliser XINPUT 1.4. Toutes les versions de Windows peuvent utiliser XINPUT 9.1.0 pour les manettes simplifiées, mais il n’y a pas de package de redistribution avec XINPUT 9.1.0. Toutes les versions de Windows peuvent également utiliser la version existante XINPUT 1.3 du SDK DirectX, qui nécessite DirectSetup pour le déploiement.

Veuillez consulter la section 1.4 Prise en charge de la manette Xbox 360 pour Windows.

Seul un ensemble limité d’applications de bureau Win32 est pris en charge sur Windows RT

Les jeux qui fonctionnent sur Windows 7 peuvent et doivent fonctionner correctement sur les plateformes Windows 8 x86 et x64.

Veuillez consulter la section 2.2 Prise en charge des versions Windows x64.

Assurez-vous que toutes les vérifications du système d’exploitation sont correctement effectuées

La version du système d’exploitation Windows 8 est 6.2. Windows 8 satisfait aux tests minimums actuels que nous recommandons pour le déploiement des jeux.

Le package de redistribution de l’utilisateur final DirectX fonctionne correctement sur Windows 8, tout comme sur Windows 7, pour déployer D3DX9, D3DX10, D3DX11, XINPUT 1.3, XAUDIO 2.7, XACTEngine, etc.

Cependant, un problème connu existe avec DirectSetup sur les systèmes ayant uniquement .NET 4.0 installé en raison de la gestion du déploiement des assemblages Managed DirectX 1.1 hérités. Ce problème s’applique à la fois à Windows 8, qui est livré avec .NET 4.5 par défaut, et aux ordinateurs Windows XP neufs avec le runtime .NET 4.0 installé. Cependant, ce problème ne s’applique à aucune version de .NET antérieure à .NET 4.0. Bien que Windows 8 dispose d’un comportement de compatibilité d’application pour résoudre ce problème automatiquement (ce qui nécessite un accès réseau), nous recommandons aux jeux qui continuent à déployer DirectSetup de mettre à jour les fichiers REDIST de la version actualisée du SDK DirectX (juin 2010). Comme toujours, si vous utilisez DirectSetup pour votre titre, réduisez votre titre à l’ensemble minimum de CABs requis.

Veuillez consulter la section 3.4 Installer correctement les ressources Windows.

Les jeux qui nécessitent le runtime compatible .NET 2.0 (2.0, 3.0, 3.5) continuent d’utiliser les mécanismes de déploiement existants

Ces jeux déclenchent un comportement de compatibilité d’application sur Windows 8 pour activer automatiquement le runtime .NET 3.5 (ce qui nécessite un accès réseau). Cependant, nous recommandons aux développeurs .NET de passer au runtime .NET 4.0.

Remarque

Les assemblages Managed DirectX 1.1 hérités ne sont pas compatibles avec le runtime .NET 4.x.

Veuillez consulter la section 3.4 Installer correctement les ressources Windows.

L’utilisation d’un autorun ou d’une autre technologie de pré-installation reposant sur .NET n’est pas recommandée

Vous pouvez supposer que seuls les runtimes compatibles .NET 2.0 (2.0, 3.0, 3.5) sont présents sur Windows Vista et Windows 7. Seul le runtime compatible .NET 4.0 est présent par défaut sur Windows 8.

Veuillez consulter la section 3.7 Prise en charge de l’autorun.

Il existe une version mise à jour de l’Application Verifier pour Windows 8

Le SDK Windows 8 inclut cette version mise à jour de l’Application Verifier.

Veuillez consulter la section 4.2 Éliminer les échecs de l’Application Verifier.

Informations supplémentaires

Compatibilité Windows 8 et Windows Server 2012
Où est le kit SDK DirectX ?

Jeux pour Windows

Résumé des conditions requises pour les jeux

Avantages pour les clients

Les jeux vidéo sur PC sont une expérience de divertissement clé sur Windows, mais les questions relatives à la facilité d’utilisation ont été une cause de frustration chez les clients au fil des ans. Traditionnellement, les jeux sont installés comme des applications, mais ils sont utilisés plus comme des médias de divertissement (comme les films ou les chansons, par exemple). Des innovations, telles que l’Explorateur de jeux, exposent les jeux de manière cohérente, différente des applications standard. Ces innovations donnent également aux jeux un statut de premier ordre dans Windows, aux côtés de la musique et des images. Les exigences suivantes aident à garantir que Windows Vista et Windows 7 offrent une expérience de jeu améliorée, plus accessible et unifiée. En même temps, elles garantissent la compatibilité avec Windows XP.

1.1 Intégration à l’Explorateur de jeux

Prérequis

Le jeu doit être visible dans l’Explorateur de jeux (le dossier Jeux) sous Windows Vista et Windows 7. Lorsqu’il est sélectionné, le jeu doit également afficher des métadonnées correctes, incluant l’éditeur, le développeur, la date de sortie, la version, les scores de l’indice de performance Windows, la notation (si applicable), et les hyperliens associés.

Si le jeu est distribué numériquement via un service de jeux en ligne, alors le fournisseur de services doit également apparaître dans l’Explorateur de jeux. Pour assurer une gestion correcte du fournisseur et permettre l’utilisation des flux RSS, la version 2 du schéma des fichiers de définition de jeux (GDF) doit être utilisée. (Pour plus d’informations sur les GDF, veuillez consulter Informations supplémentaires).

De plus, les installateurs de jeux doivent respecter les règles suivantes lorsqu’ils s’exécutent sur Windows Vista et Windows 7 :

L’installation ne doit pas créer de raccourci pour lancer le jeu sur le bureau, dans le menu Démarrer ou à tout autre endroit.
Les tâches et raccourcis pour la suppression ne doivent pas être créés.
Les utilisateurs doivent pouvoir supprimer le jeu en utilisant Programmes et fonctionnalités dans le Panneau de configuration sur Windows Vista et Windows 7, ou Ajouter ou supprimer des programmes dans le Panneau de configuration sur Windows XP.

Sur Windows XP, et sur les versions précédentes de Windows, l’installateur du jeu est libre de créer des groupes de programmes, des icônes de bureau ou des raccourcis selon les besoins.

Rationale

L’Explorateur de jeux Windows est similaire en concept aux dossiers Mes Documents ou Mes Images de Windows XP. L’idée est de centraliser le contenu similaire en un seul endroit et de permettre une organisation plus facile et des activités contextuelles. L’Explorateur de jeux étend le concept de Mes Documents ou Mes Images en permettant une organisation plus riche et un contrôle des jeux. L’Explorateur de jeux permet aux joueurs de visualiser, organiser et interagir avec tous les jeux installés sur leurs systèmes. Il permet également aux éditeurs de jeux de communiquer des informations importantes sur les jeux de manière plus efficace. Le système est piloté par les données, ce qui facilite la mise à jour des informations sur les jeux par un éditeur de jeux tout au long de la vie du produit.

Informations supplémentaires

L’intégration à l’Explorateur de jeux nécessite que vous créiez un fichier de définition de jeu (GDF), qui est un fichier texte XML intégré dans un fichier binaire (un fichier exécutable ou une DLL) en tant que ressource, accompagné d’une icône Windows. Le jeu doit ensuite être enregistré dans l’Explorateur de jeux. Le GDF permet également l’exposition des informations fournies telles que le titre du jeu, l’éditeur, le développeur, les liens vers des sites Web et les tâches optionnelles. Notez que les tâches de support peuvent être uniquement des liens vers des sites Web, mais les tâches de jeu peuvent également être utilisées pour des tâches de support optionnelles.

L’Explorateur de jeux peut utiliser une image bitmap miniature, mais il est recommandé de fournir plutôt une ressource d’icône Windows avec des icônes de grande taille (256 x 256). La ressource d’icône doit inclure des tailles d’image de 256 x 256, 48 x 48, 32 x 32, et 16 x 16 dans des profondeurs de couleur de 24 bits (True Color) et 8 bits (256) couleurs. L’éditeur d’icônes fourni dans Visual Studio 2008 et 2010 prend en charge ces formats d’icônes de grande taille, tout comme IconWorkshop Lite.

Des détails sur l’intégration avec l’Explorateur de jeux Windows sont fournis dans le SDK DirectX. Le SDK DirectX inclut un éditeur de fichier de définition de jeu (GDF), ainsi qu’un exemple de GDF inclus dans GDFExampleBinary, un échantillon. Un autre échantillon, GameUxInstallHelper, fournit des routines pour intégrer la fonctionnalité requise dans les systèmes d’installation existants. Le Validateur de fichier de définition de jeu (gdftrace.exe) fournit une assistance au débogage pour évaluer un GDF. Veuillez également consulter la section « Intégration de l’Explorateur de jeux Windows » dans la documentation du SDK DirectX pour C++.

Windows 7 introduit la prise en charge de la deuxième version d’un schéma pour les fichiers GDF. La nouvelle version inclut une méthode simplifiée pour créer des tâches de jeu et une prise en charge des notifications de mise à jour, des fournisseurs de services de jeux, des statistiques de jeux et des flux RSS pour les fournisseurs de services de jeux. La dernière version de GameUxInstallHelper gère tous les enregistrements et la prise en charge héritée nécessaires pour utiliser un fichier GDF version 2 avec Windows Vista. Utilisez les outils et le code source d’exemple du SDK DirectX à partir d’août 2009 ou plus tard. L’utilisation d’un fichier GDF version 2 est recommandée pour permettre la prise en charge des flux RSS, des statistiques de jeux et des notifications de mise à jour. Veuillez également consulter les exemples ProviderGDFExampleBinary et GameStatisticsExample.

Sur Windows Vista Édition Professionnelle, Windows 7 Édition Professionnelle et les éditions Entreprise de Windows Vista et Windows 7, le lien Jeux dans le menu Démarrer est caché. L’Explorateur de jeux est toujours disponible dans le menu Démarrer en cliquant sur Tous les programmes, puis en cliquant sur Jeux.

Pour les applications associées qui sont installées avec votre jeu, mais qui ne sont pas elles-mêmes des jeux, vous êtes libre de créer des groupes de programmes, des raccourcis et des icônes de bureau dans le menu Démarrer sur toutes les versions de Windows, y compris Windows Vista et Windows 7. Ces applications associées doivent respecter les exigences applicables aux jeux pour Windows ; pour plus de détails, veuillez consulter les Directives pour les produits middleware de jeux. Les services de jeux sont encouragés à s’enregistrer auprès de l’Explorateur de jeux en tant que fournisseur de jeux pour Windows 7. 1

1.2 Prise en charge de la sécurité familiale / Contrôle parental

Prérequis

Les jeux doivent entièrement prendre en charge la sécurité familiale Windows en respectant les règles suivantes :

Les jeux ne doivent pas nécessiter que l’utilisateur dispose de privilèges administratifs pour jouer. L’installation, le patching et la suppression peuvent nécessiter des privilèges administratifs, sous réserve des exigences de la section 3. (Relatif à cela, l’exigence 2.1, Respecter les directives du contrôle de compte utilisateur).
Les jeux notés par des organismes de notation pris en charge par Windows, tels que l’ESRB et le PEGI, doivent inclure leurs informations de notation attribuées dans leur fichier de définition de jeu (GDF). Toutes les données de notation disponibles doivent être incluses dans chaque version localisée du GDF, ainsi que dans la version neutre en langue.
Les jeux doivent répertorier leurs exécutables dans le GDF pour offrir une bonne expérience utilisateur pour les restrictions d’application générale, sauf si le jeu utilise une technologie anti-piratage qui crée des exécutables nommés de manière aléatoire à l’exécution.
Les jeux doivent appeler la méthode VerifyAccess de l’interface Explorateur de jeux au démarrage, si elle est disponible, et quitter si elle renvoie *pfHasAccess comme FAUX.

Rationale

Tous les jeux doivent s’exécuter dans le contexte d’un compte d’utilisateur standard pour permettre aux comptes contrôlés par le contrôle parental Windows de jouer au jeu. Les parents veulent avoir la possibilité de surveiller et de contrôler l’accès de leurs enfants aux jeux. De plus, de nombreux groupes industriels, gouvernementaux et de défense souhaitent de meilleures méthodes pour permettre aux parents de surveiller et de contrôler les jeux auxquels leurs enfants sont exposés. En conjonction avec l’architecture offerte par l’Explorateur de jeux, Microsoft offre cette possibilité aux parents via le contrôle parental Windows.

Même pour les jeux qui ne participent pas à un programme d’organismes de notation, exiger des privilèges élevés crée une mauvaise expérience de jeu pour la majorité des comptes d’utilisateurs. Cela est particulièrement le cas si le contrôle parental est activé, ce qui obligerait le parent à entrer le mot de passe administrateur chaque fois que le jeu est lancé.

Le système de contrôle parental Windows permet aux parents de sélectionner les notations qu’ils jugent appropriées pour leurs enfants. Le contrôle parental prend en charge de nombreux systèmes de notation mondiaux. Le contrôle parental permet également aux parents de restreindre l’accès aux jeux en fonction des descripteurs de contenu (si le système de notation applicable les prend en charge) et de permettre ou d’interdire l’accès à des jeux individuels.

Le choix par défaut du système de notation pour le contrôle parental Windows est basé sur le paramètre de locale du système, mais peut être modifié par l’utilisateur dans Options régionales et linguistiques dans le Panneau de configuration. Par conséquent, chaque langue prise en charge doit fournir toutes les données de notation disponibles afin que l’utilisateur ait la liberté de sélectionner l’organisme de notation qu’il désire.

Informations supplémentaires

Les jeux sans notation doivent toujours respecter les exigences pour prendre en charge le jeu en tant qu’utilisateur standard et appeler VerifyAccess. Ces jeux par défaut appartiennent à la catégorie Non noté, affichent le texte "Aucune notation fournie" dans l’Explorateur de jeux et sont soumis au paramètre Restrictions de jeu dans le contrôle parental pour les jeux non notés. Le paramètre par défaut des Restrictions est Autoriser.

Les informations de notation dans le GDF seront ignorées si le binaire contenant n’est pas correctement signé par Authenticode. Veuillez consulter l’exigence 2.3.

L’éditeur de fichier de définition de jeu dans le SDK DirectX inclut tous les systèmes de notation pris en charge et répliquera correctement ces informations dans toutes les versions localisées du GDF, ainsi qu’une version neutre en langue. L’outil GDFTrace décode et vérifie toutes les informations de notation présentes. Utilisez la version d’août 2009 ou ultérieure de ces outils.

Le GDF pour un fournisseur de jeux ne contient généralement aucune information de notation et est soumis aux paramètres pour le contenu non noté.

Système d’exploitation	Systèmes de notation pris en charge
Windows Vista	CERO (Japon) ESRB (USA) OFLC (Australie) PEGI (Europe) PEGI Finlande (déprécié) PEGI Portugal PEGI/BBFC (Royaume-Uni) USK (Allemagne)
Windows Vista avec un service pack	Les service packs pour Windows Vista ajoutent la prise en charge des éléments suivants : GRB (Corée du Sud) Descripteurs de contenu variant « Mild » ESRB
Windows 7	Windows 7 prend en charge les systèmes de notation pris en charge par Windows Vista et ajoute la prise en charge des éléments suivants : CSRR (Taiwan)
Windows 8	Windows 8 prend en charge les systèmes de notation précédents et ajoute la prise en charge des éléments suivants : COB-AU (Australie) DJCTQ (Brésil) PFB (Afrique du Sud) OFLC-NZ (Nouvelle-Zélande) Windows 8 retire la prise en charge des systèmes dépréciés suivants : PEGI-FI (Finlande) OFLC (Australie)

Remarque

Tout titre qui inclut de nouveaux descripteurs de contenu Windows Vista Service Pack 1 (SP1) ESRB s’affichera comme Non noté sur Windows Vista sans un service pack.

Les nouvelles données de notation sont ignorées sur les versions de systèmes d’exploitation sans prise en charge pour elles. La variante PEGI (Finlande) est maintenant dépréciée en faveur du système de notation PEGI (Europe) standard. Le système OFLC est maintenant déprécié en faveur de COB-AU pour l’Australie.

Pour plus d’informations sur la compatibilité d’un jeu avec les privilèges d’utilisateur standard, veuillez consulter l’article DirectX Contrôle de compte utilisateur pour les développeurs de jeux.

Veuillez consulter l’exigence 1.1 pour plus de détails sur le fichier de définition de jeu (GDF).

1.3 Prise en charge des sauvegardes de jeux enrichies

[Cette exigence a été retirée]

1.4 Prise en charge de la manette Xbox 360 pour Windows [Exigence conditionnelle]

Prérequis

Les jeux qui prennent en charge les manettes de jeu doivent prendre en charge le contrôleur Xbox 360 pour Windows en utilisant l’API XInput. Si les périphériques DirectInput sont également pris en charge, alors DirectInput peut également être utilisé. Cependant, XInput doit être l’API par défaut si un appareil compatible Xbox 360 est utilisé.

Toutes les références aux déclencheurs et boutons du contrôleur commun doivent utiliser les noms Xbox 360. Veuillez consulter la liste Terminologie du contrôleur Xbox 360 pour Windows pour plus de détails.

La vibration du contrôleur doit être désactivée lorsque le jeu est en pause ou en veille.

Le contrôle par souris/clavier ne peut jamais être complètement désactivé. Au minimum, une option pour revenir aux menus du jeu doit être disponible.

Rationale

Cette exigence donne aux joueurs la liberté de choisir d’utiliser soit le contrôleur Xbox 360, soit le clavier et la souris, selon la méthode d’entrée la plus naturelle et intuitive.

Informations supplémentaires

Cette exigence ne s’applique pas aux jeux qui utilisent uniquement la souris et/ou le clavier.

Nous recommandons que la navigation dans les menus soit implémentée en utilisant les boutons standard du contrôleur largement acceptés :

A : Accepter
B : Annuler
Start : Accepter ou pause
Back : Annuler, revenir d’un écran ou d’un niveau de menu en arrière

Pour plus d’informations, veuillez consulter XInput.

La rubrique XInput et DirectInput aborde les problèmes liés à l’utilisation simultanée des deux API.

Il est recommandé de ne pas utiliser DirectInput pour implémenter les contrôles de clavier ou de souris. Les contrôles de clavier et de souris doivent uniquement être implémentés en utilisant les messages Windows et les API Win32. Pour plus de détails sur l’obtention d’informations de mouvement de souris haute résolution sans utiliser DirectInput, veuillez consulter Tirer parti du mouvement de souris haute définition.

1.5 Prise en charge de multiples ratios d’aspect et résolutions

Prérequis

Le jeu doit prendre en charge au moins les ratios d’aspect et résolutions suivants :

4:3 normal (800 600 ou 1024 768)
16:9 écran large (1280 720)
16:10 écran large (1152 720 ou 1680 1050 ou 800 480)

Pour la configuration et la détection de la résolution d’écran, le jeu doit respecter les règles suivantes :

Le jeu utilise par défaut la résolution du bureau de l’appareil d’affichage si celle-ci est une résolution prise en charge. Le rapport d’aspect du bureau doit être utilisé comme critère de recherche si le jeu choisit une autre résolution par défaut.
Le jeu doit demander à l’utilisateur de confirmer les nouveaux paramètres d’affichage lorsqu’un changement est effectué. Si l’utilisateur n’accepte pas dans les 15 secondes, l’affichage doit revenir à la configuration précédente.
Le jeu ne doit pas étirer les pixels ou centrer une fenêtre de rendu 4:3 pour prendre en charge les rapports d’aspect écran large. Cependant, le letterboxing est acceptable.

Rationale

Avec le bureau 3D de Windows, un rapport d’aspect ou une résolution particulière ne peut pas être supposé, en raison des facteurs suivants :

Support des écrans haute définition.
Part de marché accrue des moniteurs écran large.
Déploiements HDTV pour Windows Media Center.
Exigences d’accessibilité.

Informations supplémentaires

Idéalement, le jeu utilise par défaut le rapport d’aspect natif de l’écran. Cependant, obtenir cette information de manière fiable peut être un défi, donc, comme solution plus générale, le jeu peut supposer que le bureau fonctionne avec le rapport d’aspect natif. La résolution du bureau peut être obtenue en appelant EnumDisplaySettings avec ENUM_REGISTRY_SETTINGS.

Pour plus de détails, veuillez consulter la section Aspect Ratio and Widescreen des articles DirectX Introduction to the 10-Foot Experience for Windows Game Developers.

1.6 Lancement depuis le Windows Media Center

[Cette exigence a été retirée.]

1.7 Prise en charge de Direct3D

Prérequis

Si le jeu utilise Direct3D, alors la version minimale prise en charge doit être Direct3D 9, et Direct3D doit être le moteur de rendu par défaut sélectionné.

Rationale

L’architecture graphique principale de Windows Vista et Windows 7 est conçue autour de Direct3D. Direct3D 8 et les versions antérieures sont prises en charge par remappage des interfaces héritées.

L’utilisation de versions de Direct3D plus récentes que Direct3D 9 est fortement encouragée. Veuillez consulter le Games for Windows Showcase S.1. Exiger Direct3D 10 ou Direct3D 11 est entièrement conforme à l’exigence 1.7.

1.8 Activer la prise en charge DPI élevé

Prérequis

Les jeux et leurs installateurs doivent fonctionner correctement sans problèmes visuels lorsque le redimensionnement des points par pouce (DPI) est activé (testé avec 144 DPI pour un redimensionnement de 150 % à une résolution d’affichage de 1600 1200) sur Windows Vista et Windows 7.

Cela nécessite généralement que l’exécutable du jeu déclare être conscient du DPI. Cela est accompli en incorporant un élément manifeste : <dpiAware>true<dpiAware>.

Rationale

Les moniteurs LCD de haute qualité sont courants en tant qu’écrans d’ordinateur, et ils donnent le meilleur rendu lorsqu’ils fonctionnent à leurs résolutions natives (typiquement 1280 1024, 1600 1200, etc.). Les clients qui ont du mal à lire le texte et à voir les images à cette résolution règlent souvent leurs bureaux d’ordinateur à une résolution inférieure et subissent des artefacts visuels dus au redimensionnement LCD. Au lieu de cela, les clients peuvent laisser la résolution à la taille native et changer le DPI de l’affichage Windows, rendant ainsi l’apparence des éléments et du texte plus grande sans sacrifier la qualité de l’image.

Bien que cette fonctionnalité soit disponible sous une certaine forme depuis Windows XP, elle est rarement activée par les clients ou les OEM. Plus de la moitié de tous les écrans d’ordinateur aujourd’hui sont réglés à une résolution inférieure à la résolution native du moniteur, selon les retours des clients. Windows 7 rend cette fonctionnalité beaucoup plus visible pour les clients lors de la configuration initiale et lors du changement des paramètres d’affichage, les encourageant à utiliser le redimensionnement DPI plutôt que de changer la résolution du bureau.

Informations supplémentaires

La fonction SetProcessDPIAware peut être utilisée à la place, si elle est appelée tôt dans le code de démarrage du processus. L’ajout au manifeste est préféré, pour s’assurer qu’il n’y a pas de conditions de concurrence avec les éléments logiciels (comme les DLL) qui pourraient s’initialiser avant le point d’entrée principal. Notez que SetProcessDPIAware n’est présent que sur Windows Vista et Windows 7.

L’ajout de l’élément manifeste est facile à faire avec Visual Studio 2005 et 2008 ; créez un fichier nommé dpiaware.manifest contenant le texte suivant :

            <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>

Ensuite, dans Visual Studio, ajoutez dpiaware.manifest au projet. Assurez-vous que Embed Manifest est réglé sur Yes dans les propriétés du projet. Notez que les anciennes versions de l’outil Manifest (Mt.exe) généreront un avertissement fallacieux avec les éléments de manifeste conscients du DPI. Pour résoudre ce problème, mettez à jour Mt.exe à la dernière version du SDK Windows.

Visual Studio 2010 inclut un paramètre dans les propriétés du projet, nommé Enable DPI Awareness, qui élimine le besoin d’un fichier tel que dpiaware.manifest. Trouvez Enable DPI Awareness en développant Configuration Properties et Manifest Tool, puis en sélectionnant Input & Output.

Sous Windows, le mode d’affichage traditionnel est par défaut réglé à 96 DPI, ce qui était courant pour les moniteurs CRT.

Bien que les applications plein écran changent la résolution d’affichage, elles utilisent souvent des messages de fenêtre et des métriques lors de la configuration des tampons et des rectangles d’affichage. La virtualisation du DPI fait apparaître ces modes d’affichage plein écran rognés, et déclarer la prise en charge du DPI empêchera ces problèmes. Pour plus d’informations, veuillez consulter Écriture d’applications Win32 prenant en charge la résolution DPI.

Sécurité et compatibilité

Résumé des exigences de sécurité et de compatibilité

Avantages pour les clients

Les exigences suivantes améliorent la sécurité globale des jeux et aident à garantir qu’ils fonctionnent avec Windows sur différentes architectures, sous différentes configurations et dans différents modes.

2.1 Respecter les directives du contrôle de compte utilisateur

Prérequis

Chaque fichier exécutable (c’est-à-dire chaque fichier ayant une extension .exe) doit contenir un manifeste intégré qui définit son niveau d’exécution en incluant la balise suivante :

            <requestedExecutionLevel>

Conformément à l’exigence 1.2, le jeu principal et l’exécutable Autorun doivent avoir le niveau d’exécution de asInvoker pour prendre en charge les contextes de l’utilisateur standard.

Les fichiers de données utilisateur qui ont des associations de fichiers enregistrées avec Explorateur de fichiers doivent être placés dans un sous-dossier du dossier spécifié par CSIDL_PERSONAL (également appelé Documents ou Mes Documents). Tous les autres fichiers de données utilisateur doivent être stockés dans un sous-dossier des dossiers spécifiés par CSIDL_LOCAL_APPDATA ou CSIDL_COMMON_APPDATA. (Ces répertoires sont masqués par défaut pour les utilisateurs individuels et pour tous les utilisateurs).

Rationale

L’expérience Windows d’un utilisateur est plus sécurisée si les applications ne fonctionnent qu’avec les autorisations nécessaires.

Informations supplémentaires

Si seules quelques fonctionnalités d’une application nécessitent des privilèges administratifs (par exemple, une application qui doit configurer un pare-feu), le processus principal de l’application doit toujours être exécuté en utilisant les privilèges de l’utilisateur standard. Les fonctionnalités qui nécessitent des privilèges administratifs doivent être déplacées dans un processus séparé, tel qu’un installateur ou un utilitaire de configuration.

Si les privilèges administratifs ne sont pas requis, le manifeste XML intégré doit inclure ce qui suit :

            <?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>

Si les privilèges administratifs sont requis, le manifeste XML intégré doit inclure ce qui suit :

            <?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>

Avec Visual Studio 2005, cela est facilement intégré en ajoutant simplement un fichier manifeste (.manifest) contenant l’un des blocs précédents au projet, et en s’assurant que Embed Manifest est réglé sur Yes dans les propriétés du projet pour l’outil Manifest. Pour Visual Studio 2008 et 2010, les propriétés UAC peuvent être définies directement dans les propriétés du projet pour le linker sur la page Manifest File. Notez que les anciennes versions de l’outil Manifest (Mt.exe) génèrent un avertissement erroné avec les éléments de manifeste UAC. Pour résoudre ce problème, mettez à jour Mt.exe à la dernière version du SDK Windows.

Veuillez consulter l’exigence 3.1 pour plus de détails sur les cas particuliers d’installation, de mise à jour et de suppression.

Les bibliothèques de liens dynamiques (DLL) ne nécessitent pas de tels manifestes.

Pour plus d’informations sur le contrôle de compte d’utilisateur, veuillez consulter la rubrique Contrôle de compte d’utilisateur pour les développeurs de jeux.

2.2 Prise en charge des versions Windows x64

Prérequis

Pour maintenir la compatibilité avec les éditions 64 bits de Windows, les jeux doivent répondre aux exigences suivantes.

Les titres et les installateurs de titres ne doivent contenir aucun code 16 bits ni dépendre d’un composant 16 bits.
Si le jeu dépend de pilotes en mode noyau pour fonctionner, des versions x64 de ces pilotes doivent être disponibles. L’installation du jeu doit détecter et installer les pilotes et composants appropriés pour les éditions 64 bits de Windows.

Rationale

De nombreux utilisateurs de Windows Vista et Windows 7 exécuteront des éditions 64 bits du système d’exploitation au cours de la vie du produit, il est donc crucial que les applications soient compatibles avec ce système d’exploitation.

Informations supplémentaires

Windows on Windows 64 (WOW64) permet au code 32 bits de fonctionner sur les éditions 64 bits de Windows, il n’est donc pas nécessaire que l’application soit un code 64 bits natif sur les éditions 64 bits de Windows. Le code 16 bits ne fonctionne pas sur les éditions 64 bits de Windows.

Maintenir la compatibilité avec Windows XP Professional x64 Edition n’est pas requis, mais fortement encouragé.

Pour plus de détails, veuillez consulter la rubrique Programmation 64 bits pour les développeurs de jeux.

2.3 Signer les fichiers

Prérequis

Tous les fichiers de code exécutable (typiquement, les fichiers avec l’extension .exe ou .dll) doivent être signés avec un certificat Authenticode valide publiquement, et doivent avoir une URL de serveur d’horodatage valide pour la signature de production.

Si votre jeu utilise Windows Installer, les fichiers du package d’installation (.msi) doivent être signés.

Rationale

Signer un fichier aide les utilisateurs à décider s’ils doivent faire confiance à une application, et assure aux utilisateurs que les fichiers n’ont pas été altérés. Cela permet également aux applications de fonctionner correctement dans des environnements verrouillés.

Informations supplémentaires

Pour plus de détails, veuillez consulter la rubrique Signature Authenticode pour les développeurs de jeux.

Si votre jeu utilise Windows Installer, nous vous recommandons d’activer la mise à jour UAC/LUA, en incluant une table MsiPatchCertificate. Pour plus d’informations, veuillez consulter la rubrique Mise à jour du contrôle de compte d’utilisateur (UAC).

Nous ne recommandons pas de signer les fichiers cabinet (.cab), sauf s’ils sont relativement petits (moins de 100 Mo).

2.4 Signer les pilotes

Prérequis

Tout pilote en mode noyau installé par le jeu doit être signé avec un certificat Authenticode valide publiquement.

Tout pilote de périphérique matériel en mode noyau installé par le jeu doit avoir une signature Microsoft, qui peut être obtenue auprès des Windows Hardware Quality Labs (WHQL) ou du programme Driver Reliability Signature (DRS).

Rationale

Les pilotes mal écrits ou malveillants peuvent gravement affecter la stabilité et la sécurité d’un système. Sur les éditions 64 bits de Windows Vista et Windows 7, les pilotes non signés ne se chargent pas. Cette politique peut également être activée pour les éditions 32 bits de Windows Vista et Windows 7.

Informations supplémentaires

Des versions natives 32 bits et 64 bits de tous les pilotes en mode noyau sont nécessaires selon l’exigence 2.2.

Plus d’informations sur les programmes de signature de pilotes Microsoft peuvent être trouvées sur le Centre de développement matériel Windows.

2.5 Effectuer une vérification correcte des versions

Prérequis

Les jeux ne doivent pas échouer à fonctionner sur les futurs systèmes d’exploitation comme indiqué par les changements dans le numéro de version de Windows, à moins que le contrat de licence de l’utilisateur final n’interdise l’utilisation sur les futurs systèmes d’exploitation. Si le jeu est censé échouer, il doit le faire de manière gracieuse en affichant un message approprié à l’utilisateur.

Si des vérifications de version de Windows sont effectuées, les API de vérification de version (GetVersionEx ou VerifyVersionInfo) doivent être utilisées pour vérifier la version du système d’exploitation. Les clés de registre ne doivent pas être lues pour déterminer la version.

Les vérifications explicites de version pour le runtime DirectX ne doivent pas être présentes dans le jeu. Ces vérifications de version ne doivent pas être présentes dans l’installation qui lance le programme d’installation du runtime DirectX (DirectSetup).

Rationale

Lorsque les utilisateurs de Windows mettent à niveau leurs systèmes d’exploitation, ils ne doivent pas être empêchés de jouer aux jeux actuels simplement parce que le numéro de version de Windows a augmenté. Les vérificateurs de version mal conçus continuent de créer des problèmes pour les logiciels qui, autrement, fonctionnent bien sur des versions plus récentes de Windows ou simplement avec l’ajout d’un service pack de Windows.

La logique fragile de comparaison des versions pour le runtime DirectX a créé de nombreuses installations échouées lorsqu’elle est exécutée sur différentes versions de Windows. Le numéro de version de DirectX s’applique uniquement aux composants principaux du système d’exploitation. Il ne s’applique pas aux composants SDK DirectX en mode côte-à-côte qui sont utilisés par de nombreux jeux.

Informations supplémentaires

Il est assez courant de voir des installateurs vérifier une version minimale du système d’exploitation. Cette vérification, cependant, doit être faite avec soin pour s’assurer qu’elle teste une version supérieure ou égale, plutôt qu’une simple égalité, verrouillant ainsi une version spécifique du système d’exploitation. Utiliser le test HighVersionLie d’Application Verifier est un moyen rapide et facile de déterminer comment votre installateur réagira à un changement significatif du numéro de version de l’OS.

Une utilisation appropriée du package de redistribution du runtime DirectX (DirectX Setup) consiste à le lancer toujours pendant l’installation, de préférence en mode silencieux. Cela permet au code fourni par Microsoft d’effectuer toutes les mises à jour de version requises. Cela permet également l’installation de tous les composants SDK DirectX optionnels en mode côte-à-côte, tels que D3DX, XACT, MDX ou XInput.

Pour les bonnes pratiques de déploiement du runtime DirectX, veuillez consulter la section Installation de DirectX pour les développeurs de jeux.

Il est recommandé que les jeux qui prennent en charge Windows XP vérifient un niveau de service pack de 2 ou supérieur, car Service Pack 2 (SP2) et Service Pack 3 (SP3) apportent des améliorations significatives en matière de sécurité, une exigence simplifiée de redistribution du runtime DirectX, et un déploiement extrêmement large. La plupart des technologies Microsoft modernes qui prennent en charge Windows XP nécessitent SP2 ou SP3 (XAudio2, Games for Windows - LIVE, etc.).

2.6 Prise en charge des sessions utilisateur concurrentes

Prérequis

Les jeux qui reposent sur des graphismes 3D ne sont pas tenus de fonctionner via une connexion de bureau à distance, mais l’utilisateur doit être alerté lorsque le jeu échoue.

Les jeux doivent prendre en charge les scénarios de multitâche standard de Windows en respectant les règles suivantes :

Les jeux ne doivent pas bloquer l’utilisation de sessions utilisateur concurrentes.
Un jeu doit fonctionner dans une nouvelle session utilisateur lorsqu’il est déjà en cours d’exécution dans une autre session.
Le son du jeu dans une session utilisateur ne doit pas être entendu lorsqu’un autre utilisateur est actif dans une session différente.
Les jeux doivent prendre en charge le basculement rapide entre utilisateurs.
Les jeux ne doivent pas tenter de désactiver le basculement de tâches standard. Les jeux ne doivent pas désactiver le raccourci clavier ALT+TAB. Les jeux sont autorisés à désactiver les raccourcis clavier d’accessibilité, comme décrit dans la section Désactivation des touches de raccourci dans les jeux.

Rationale

Les utilisateurs de Windows doivent pouvoir exécuter des sessions concurrentes sans conflit ni interruption. C’est un scénario courant pour un ordinateur Windows partagé par une famille, des colocataires ou d’autres personnes.

Informations supplémentaires

Pour tester si le jeu est lancé dans une session à distance, appelez GetSystemMetrics(SM_REMOTESESSION). Une valeur non nulle indique que la session est distante.

Pour plus d’informations, veuillez consulter la section Passer rapidement d’un utilisateur à un autre utilisateur. Notez que le basculement rapide entre utilisateurs se produit si les restrictions de temps de contrôle parental sont activées lorsque le temps de l’utilisateur est écoulé. Veuillez consulter l’exigence 1.2 pour plus de détails.

2.7 Prise en charge des noms longs

Prérequis

Si un jeu prend en charge l’enregistrement de fichiers, il doit être capable de sauvegarder des fichiers avec des noms et des chemins longs. Le jeu doit gérer correctement les caractères spéciaux du système de fichiers, tels que \ / : * ? " <>, dans tous les champs de saisie utilisateur utilisés pour créer des noms de fichiers ou des chemins.

Les jeux doivent fonctionner correctement lorsqu’un utilisateur a un nom d’utilisateur long.

Rationale

Les joueurs sont habitués à utiliser des noms longs sur des chemins profonds pris en charge par le système d’exploitation sous-jacent.

Informations supplémentaires

Les noms longs sont définis comme ceux contenant les valeurs maximales définies dans le SDK Windows.

Installation

Résumé des exigences de sécurité et de compatibilité

Avantages pour les clients

Les clients peuvent être sûrs que les applications s’installeront sur Windows sans dégrader le système d’exploitation ou d’autres applications si les applications utilisent des méthodes officielles de distribution des composants du système. Une expérience d’installation simplifiée fournit une expérience hors de la boîte plus accessible et sans problème pour les jeux.

3.1 Prise en charge d’une installation facile

Prérequis

Les jeux doivent fournir un chemin simplifié dans l’interface utilisateur d’installation en mettant en œuvre les éléments suivants :

Afficher un maximum d’une invite EULA (Conditions générales d’utilisation).
Le chemin d’installation par défaut doit contourner toutes les sélections pour l’installation (telles que le dossier d’installation ou les sélections de composants), supposer les sélections par défaut, puis exécuter le jeu ou le lanceur après une installation réussie, sans invites supplémentaires. Si vous le souhaitez, une option d’installation personnalisée peut être fournie pour les options de configuration avancées.
Installez tous les composants requis du système d’exploitation (tels que les runtimes DirectX et Visual C) en utilisant les packages de redistribution Microsoft appropriés. L’installation doit être effectuée en mode silencieux, sans invite et sans être protégée par des vérifications de version des composants.
Fournissez une suppression via Programmes et fonctionnalités dans le Panneau de configuration pour l’application de jeu et les fichiers de travail générés. Une option pour supprimer les fichiers de données créés par l’utilisateur est recommandée. Le processus de suppression doit garantir que tous les fichiers installés sont supprimés et que tous les paramètres (par exemple, les entrées de la liste des exceptions de pare-feu et les clés de registre) sont effacés. Les composants du système d’exploitation redistribués ne doivent pas être supprimés.
Si le jeu nécessite que des exceptions soient ajoutées au pare-feu Windows, le processus d’installation peut demander à informer les utilisateurs que ce changement est nécessaire. Cette invite doit apparaître avant le début de l’installation.

L’installation et la suppression peuvent nécessiter des droits administratifs. Le patching peut nécessiter une demande d’identifiants administratifs, selon la fréquence de mise à jour. Le jeu normal ne doit pas nécessiter de droits administratifs, conformément à l’exigence 2.1 Suivre les directives de contrôle de compte utilisateur.

Rationale

L’installation facile est une philosophie de développement de jeux centrée sur Windows conçue pour simplifier et rationaliser le processus parfois fastidieux et déroutant d’installation de jeux sur des ordinateurs exécutant des systèmes d’exploitation Windows. L’installation facile est activée en utilisant un ensemble de technologies et de bonnes pratiques qui réduisent la complexité inutile et le risque perçu de l’installation de jeux sur des ordinateurs Windows.

Les objectifs clés sont de :

Réduire le temps nécessaire pour entrer dans le jeu et commencer à jouer.
Réduire le nombre de boîtes de dialogue et de choix à très peu, voire aucun, afin de simplifier l’expérience d’installation du jeu.

Certaines installations traditionnelles comportent des invites permettant des installations non fonctionnelles, même si l’application semble être installée avec succès. Par exemple, un jeu peut exiger qu’un utilisateur accepte des Conditions générales d’utilisation. Le jeu est ensuite installé, puis les Conditions générales d’utilisation de DirectX apparaissent. Ces Conditions générales d’utilisation permettent aux utilisateurs de refuser, et ainsi de sauter l’installation du runtime DirectX. Ce scénario peut entraîner l’échec du jeu en raison de composants manquants.

Informations supplémentaires

Pour plus d’informations sur l’installation des jeux, les techniques d’installation non traditionnelles des jeux, les solutions de patching compatibles UAC et la gestion des patchs fréquents, veuillez consulter les articles DirectX suivants :

Remarque

La suppression des fichiers de données générés par l’utilisateur spécifique doit être effectuée uniquement pour l’utilisateur actuel et pour les emplacements partagés communs des utilisateurs. Il n’existe aucun moyen robuste de scanner le système pour supprimer les fichiers spécifiques aux utilisateurs pour d’autres utilisateurs, même si la suppression nécessite des droits administratifs.

3.2 Prise en charge du contrôle de compte utilisateur pour l’installation

Prérequis

Le programme d’installation du jeu ne doit pas supposer qu’il s’exécute dans le même contexte que l’utilisateur. Les emplacements spécifiques à l’utilisateur seront différents pour l’installateur et le joueur, même pour les systèmes à utilisateur unique, en raison de l’élévation des identifiants administrateur. Par conséquent, lorsqu’un jeu est exécuté pour la première fois, il doit effectuer des tâches spécifiques à l’utilisateur, séparément du processus d’installation.

La boîte de dialogue d’exception du Pare-feu Windows ne doit pas apparaître lorsqu’un utilisateur héberge ou rejoint une partie multijoueur. Toute configuration requise doit être effectuée au moment de l’installation. Les instructions de configuration doivent informer l’utilisateur que cette opération aura lieu dans le cadre de la configuration.

Le programme d’installation du jeu doit fournir un manifeste intégré désignant le niveau d’exécution requis, conformément à l’exigence 2.1 Suivre les directives de contrôle de compte d’utilisateur.

Si le jeu est lancé par l’installateur après la fin de l’installation, il doit être lancé dans le contexte de l’utilisateur d’origine.

Rationale

L’un des plus grands changements apportés au système d’exploitation Windows dans Windows Vista est l’ajout du contrôle de compte d’utilisateur (UAC), qui exécute les applications avec des privilèges réduits par défaut. Par conséquent, les installateurs doivent gérer les niveaux de privilège en conséquence. Windows 7 utilise également largement l’UAC. Bien que Windows 7 améliore l’expérience utilisateur de l’UAC, les installateurs doivent toujours répondre aux mêmes exigences que sur Windows Vista pour fonctionner correctement, sans compter sur un comportement de virtualisation potentiellement déroutant.

L’UAC est activé par défaut sur Windows Vista et Windows 7, et la grande majorité des clients (88 % ou plus, selon les retours) laisse cette fonctionnalité activée.

Informations supplémentaires

Pour plus de détails sur la configuration du Pare-feu Windows, veuillez consulter la section Windows Firewall pour les développeurs de jeux et l’exemple FirewallInstallHelper.

Le lancement standard du jeu à la fin du processus d’installation ne respecte pas le dernier aspect de cette exigence si l’installation est lancée par un utilisateur standard, et si le processus de configuration nécessite des privilèges administratifs (c’est-à-dire, demande des identifiants administrateur). Il hérite également des privilèges administratifs, ce qui constitue un risque potentiel pour la sécurité. Au lieu de cela, un chargeur de démarrage de configuration devrait lancer le jeu après un retour réussi de l’appel de l’installateur. Pour plus d’informations, veuillez consulter l’article de MSDN Magazine intitulé MSDN Magazine Teach Your Apps to Play Nicely with Windows Vista User Account Control.

3.3 Installer dans les dossiers corrects

Prérequis

Les jeux installés pour tous les utilisateurs doivent être installés par défaut dans le dossier Program Files. Les données utilisateur doivent être écrites lorsque le jeu est exécuté pour la première fois, et non pendant l’installation.

Rationale

Les utilisateurs doivent avoir la flexibilité d’installer les applications là où ils en ont besoin. Ils doivent également bénéficier d’une expérience cohérente et sécurisée avec l’emplacement par défaut des fichiers.

Informations supplémentaires

Les jeux peuvent utiliser les différents emplacements de dossiers connus (tels que ceux spécifiés par CSIDL_LOCAL_APPDATA et CSIDL_COMMON_APPDATA) pour stocker des quantités importantes de données de jeu et de fichiers exécutables de support afin de mettre en œuvre des scénarios avancés d’installation à la demande et de correction.

Comme l’installation peut nécessiter une élévation à un autre compte utilisateur lors du processus d’installation pour tous les utilisateurs, il n’y a pas d’emplacement utilisateur correct pour stocker les données au moment de l’installation. De plus, si le chiffrement des fichiers est activé, seuls les fichiers chiffrés peuvent être accessibles par le compte utilisateur qui les a créés.

3.4 Installer correctement les ressources Windows

Prérequis

Les applications ne doivent pas tenter d’installer des fichiers ou des clés de registre protégés par la protection des ressources Windows (WRP). Si l’application nécessite des versions plus récentes des composants système, elle doit mettre à jour ces composants en utilisant un Service Pack Microsoft ou un package d’installation approuvé par Microsoft contenant le composant système. Les composants système ne doivent jamais être reconditionnés.

Rationale

La protection des ressources Windows (WRP) est conçue pour garantir que les ressources système protégées sont mises à jour uniquement à l’aide de mécanismes d’installation ou de mise à jour approuvés par Microsoft. WRP améliore la fiabilité du système en garantissant que les résultats d’une installation sont prévisibles.

Informations supplémentaires

WRP est le successeur de la protection des fichiers Windows, qui protège la majorité des composants système installés dans le dossier Windows. WRP protège la plupart des clés de registre qui stockent les paramètres de création d’objets COM. Il réserve également certains dossiers à l’usage exclusif du système d’exploitation. Les tentatives d’accès aux ressources protégées aboutissent généralement à une erreur de refus d’accès.

Pour connaître les bonnes pratiques lors du déploiement du runtime DirectX avec un jeu, veuillez consulter la section Installation de DirectX pour les développeurs de jeux.

3.5 Éviter les redémarrages pendant l’installation

Prérequis

Le programme d’installation du jeu ne doit pas supposer que l’installation de composants Windows à partir de packages de redistribution nécessite un redémarrage, à moins que le redémarrage ne soit indiqué par un résultat de retour ou par la documentation Microsoft.

Si le programme d’installation du jeu force toujours un redémarrage, cela doit être approuvé par Microsoft.

Les boîtes de dialogue de fichiers en cours d’utilisation incluses dans les packages du programme d’installation Windows doivent contenir une option permettant de fermer automatiquement les applications et de tenter de les redémarrer une fois l’installation terminée.

Rationale

Le redémarrage du système après une installation est une interruption gênante pour les utilisateurs et est généralement inutile.

Informations supplémentaires

Pour plus d’informations, veuillez consulter la section Utilisation de Windows PowerShell avec Resource Manager.

3.6 Utiliser correctement la gestion des versions de fichiers

Prérequis: Le programme d’installation du jeu doit vérifier correctement que les dernières versions des fichiers sont installées. L’installation d’un jeu ne doit jamais régresser des fichiers que vous ne produisez pas ou qui sont partagés par des applications que vous ne produisez pas.
Rationale: Les composants partagés et les composants système sont souvent mis à jour pour des correctifs de sécurité et des fonctionnalités étendues. Une installation incluant une version antérieure des composants mis à jour ne doit pas entraîner la perte des mises à jour et des correctifs qui ont déjà été appliqués.

3.7 Prise en charge de l’autorun [Exigence conditionnelle]

Prérequis

Pour les jeux distribués sur CD, DVD ou autres supports amovibles prenant en charge l’exécution automatique, lorsque le disque est inséré pour la première fois, l’application doit se lancer automatiquement ou inviter l’utilisateur à installer le jeu, à moins que l’utilisateur n’ait désactivé la fonction d’exécution automatique.

Une fois l’application installée avec succès, la réinsertion du disque dans le lecteur ne doit pas provoquer le redémarrage automatique de l’installation. Il est acceptable de demander aux utilisateurs s’ils souhaitent mettre à jour ou modifier leurs choix d’installation.

L’application d’exécution automatique ne doit pas demander d’élévation (c’est-à-dire qu’elle doit avoir asInvoker dans le manifeste, conformément à l’exigence 2.1), bien qu’elle puisse lancer le programme de configuration ou un autre utilitaire nécessitant des droits administratifs. L’élévation ne doit se produire que si le jeu n’est pas installé ou si l’utilisateur le sélectionne spécifiquement.

Rationale

Autorun simplifie l’expérience d’utilisation des applications distribuées sur des supports, telles que les jeux qui nécessitent généralement que le disque soit présent dans le lecteur pour jouer.

Informations supplémentaires

Il n’est pas acceptable de demander à l’utilisateur de naviguer dans l’Explorateur de fichiers pour lancer l’installation à partir du CD ou du DVD.

Pour les jeux distribués sur plusieurs disques, les disques suivants devraient idéalement utiliser la fonctionnalité Autorun ou continuer l’installation sans demander à l’utilisateur d’appuyer sur une touche ou de prendre une autre action.

Lors de la création d’un programme Autorun, assurez-vous que tous les composants requis sont présents sur les installations neuves de Windows. Les applications typiques dépendent des technologies installées par le programme d’installation, mais Autorun s’exécute avant que ce programme d’installation ne se produise. Un exemple courant est l’échec des programmes Autorun parce que les DLL Visual C Runtime n’étaient pas incluses dans le programme d’installation de Windows. Le programme Autorun doit donc utiliser le déploiement local CRT de l’application ou lier statiquement le CRT.

Les programmes Autorun écrits pour être utilisés sur les versions de Windows antérieures à Windows Vista ne doivent pas utiliser le runtime .NET car cette technologie n’est pas incluse avec Windows XP ou les versions antérieures de Windows. Windows Server 2003 et Windows Vista sont les premières versions de Windows à inclure le runtime .NET dans leur système d’exploitation.

Pour des raisons similaires, les programmes Autorun ne peuvent pas nécessiter la présence des composants optionnels côte à côte du SDK DirectX tels que D3DX9, D3DX10, D3DX11, XAudio2, X3DAudio, XACT, XINPUT et MDX 1.1.

Pour un exemple d’utilisation d’Autorun, veuillez consulter la section AutoRun Sample.

Fiabilité

Résumé des exigences de sécurité et de compatibilité

Avantages pour les clients

Ces exigences rendent une application plus fiable en minimisant le nombre de plantages, de blocages et de redémarrages. Les exigences de fiabilité peuvent aider à garantir que les logiciels soient plus prévisibles, maintenables, résilients et récupérables.

4.1 Éliminer les redémarrages inutiles

Prérequis

Tous les installateurs d’application doivent tirer parti des API du gestionnaire de redémarrage pour éviter les redémarrages du système (voir l’exigence 3.5).

Les jeux ne doivent pas bloquer l’arrêt.

Toutes les applications doivent répondre au gestionnaire de redémarrage en écoutant et en répondant aux messages d’arrêt suivants :

WM_QUERYENDSESSION avec LPARAM = ENDSESSION_CLOSEAPP (0x1): Les applications GUI doivent répondre (TRUE) immédiatement en préparation d’un redémarrage.
WM_ENDSESSION avec LPARAM = ENDSESSION_CLOSEAPP (0x1): Les applications doivent renvoyer une valeur 0 dans les 5 secondes, puis se fermer.
CTRL+C: Les applications console qui reçoivent ce message doivent se fermer immédiatement.

Rationale

Les redémarrages système sont une perturbation majeure. Ils entraînent une mauvaise expérience utilisateur et doivent être minimisés. Certaines opérations, telles que les mises à jour système critiques, peuvent nécessiter des redémarrages. En écoutant les messages d’arrêt, le jeu et d’autres applications peuvent réagir rapidement aux demandes du gestionnaire de redémarrage. De cette manière, ils peuvent éviter des retards inutiles dans les demandes de redémarrage valides.

Informations supplémentaires

Si un installateur de jeu utilise la technologie Windows Installer (MSI) sans aucune action personnalisée, cette fonctionnalité est fournie automatiquement. Les packages de redistribution Microsoft prennent également en charge le gestionnaire de redémarrage.

Pour plus d’informations sur le gestionnaire de redémarrage, veuillez consulter la section À propos de Restart Manager.

4.2 Éliminer les échecs de l’Application Verifier

Prérequis

Le jeu ne doit générer aucun échec lors de l’exécution sous Microsoft Application Verifier (AppVerifier), version 4.0 ou ultérieure, dans les tests suivants :

Basics : Handles, Heaps, Locks, Memory, TLS
Miscellaneous : DangerousAPIs, DirtyStacks

Rationale

AppVerifier teste de nombreux problèmes connus qui causent des plantages et des blocages dans les applications Windows, ainsi que des vulnérabilités de sécurité connues.

Informations supplémentaires

Pour plus d’informations sur Application Verifier, veuillez consulter la section Application Verifier et Utilisation d’Application Verifier au sein de votre cycle de vie de développement logiciel.

Cette exigence ne s’applique pas aux applications purement gérées sans interopérabilité native.

Ces tests doivent être exécutés sur une version de build. Les builds de débogage peuvent générer de faux échecs. Certaines technologies anti-piratage et anti-triche peuvent interférer avec l’exécution d’AppVerifier. Par conséquent, ces tests doivent être effectués sans que les technologies anti-piratage et anti-triche soient activées.

Il peut être nécessaire de définir la propriété Full du test Basics:Heaps sur FALSE, car le PageHeap complet augmente considérablement la pression mémoire de l’application en cours d’exécution. Les échecs seront toujours détectés, mais ils peuvent être plus difficiles à localiser si vous utilisez uniquement le PageHeap partiel.

Si vous utilisez les tests liés à UAC/LUA dans Application Verifier pour répondre aux exigences du contrôle de compte d’utilisateur 2.1 et 3.2, vous devez utiliser le Standard User Analyzer pour examiner les résultats. Il existe également de nombreux autres tests utiles fournis par Application Verifier que vous êtes fortement encouragés à utiliser lors du développement et des tests pour garantir un haut niveau de compatibilité avec les versions actuelles et futures de Windows. Le test HighVersionLie est utilisé pour vérifier la conformité avec l’exigence 2.5.

Visual Studio Team System inclut un sous-ensemble de la fonctionnalité AppVerifier intégré dans l’environnement de débogage. Cela peut être utile pour localiser et résoudre les problèmes avec les tests Basics : Heaps, Handles et Locks.

4.3 Prise en charge du rapport d’erreurs Windows et des informations de version de fichier

Prérequis

Pour activer la prise en charge de Windows Error Reporting, les jeux doivent répondre aux exigences suivantes :

Les jeux doivent gérer uniquement les exceptions connues et attendues. Windows Error Reporting ne doit pas être désactivé. Si une faute telle qu’une violation d’accès apparaît dans un jeu, elle doit permettre à Windows Error Reporting de signaler le crash.
Tous les fichiers exécutables (par exemple, les fichiers .exe ou DLL) doivent contenir un nom de produit, un nom de société et une version de fichier précis.
La sortie normale du jeu ne doit pas entraîner une faute d’exception inconnue.

Rationale

Les API Windows Error Reporting fournissent des commentaires vitaux à Microsoft pour détecter les plantages et les blocages généralisés dans les applications. Cela permet à Microsoft et à ses partenaires de détecter et de résoudre rapidement les problèmes de système et de pilote qui entraînent des défaillances d’application.

Informations supplémentaires

Les jeux peuvent inclure des gestionnaires d’exceptions non gérées personnalisés pour effectuer des fonctionnalités de support et de reporting personnalisées, mais ils doivent transmettre toute erreur aux fonctions ReportFault ou WerReportSubmit.

Les informations de version de fichier appropriées peuvent être vérifiées en affichant les propriétés du fichier dans l’interface utilisateur du bureau Windows et en vérifiant la page de propriété Version.

Pour plus d’informations sur les API Windows Error Reporting et sur la façon d’analyser les vidages sur incident générés lorsque vous utilisez ce service, veuillez consulter l’article DirectX Crash Dump Analysis.

Terminologie de la manette Xbox 360 pour Windows

Nom	Description
A	Le bouton A.
G	Le bouton B.
RETOUR	Le bouton Retour.
(gâchette droite/gauche)	Le bouton situé sur le bord supérieur droit et gauche de la manette. Équivalent à une gâchette haute.
pavé directionnel	Le pavé directionnel de la manette.
D-pad	Abréviation acceptée pour le pavé directionnel.
DP	Abréviation du pavé directionnel et étiquette de la manette.
RB, LB	Abréviations de la gâchette droite et gauche et étiquettes de manette.
RS, LS	Abréviations de stick droit et gauche et étiquettes de manette.
RT, LT	Abréviations de gâchette droite et gauche et étiquettes de manette.
RSB, LSB	Abréviations de stick droit et gauche et étiquettes de manette.
START	Le bouton Start.
(stick droit/gauche)	Le stick de la manette. Autrefois appelé joystick.
(bouton de stick droit/gauche)	Le bouton du stick de la manette. Autrefois appelé bouton du joystick.
(gâchette droite/gauche)	La gâchette de la manette.
Vibration	Retour de jeu produit par le moteur de la manette. Ne pas utiliser rumble (vibration de la manette).
X	Le bouton X.
Y	Le bouton Y.
Manette Xbox 360 pour Windows	La manette Xbox 360 vendue comme matériel PC SKU, incluant un disque de pilote pour appareil Windows.
Manette Xbox 360 sans fil pour Windows	La manette Xbox 360 sans fil vendue comme matériel PC SKU, incluant un disque de pilote pour appareil Windows.

Directives pour les produits middleware de jeux

Introduction

Pour que les jeux se qualifient pour le programme Games for Windows, ils doivent répondre à une liste d’exigences techniques. Tous les composants tiers qui sont livrés avec un titre (fichiers exécutables, DLL, pilotes, etc.) doivent également répondre à ces exigences pour que le jeu soit qualifié. Ce document met en évidence les exigences les plus courantes que doivent également respecter les composants tiers pour que le jeu passe les tests de conformité. Les installateurs et les packages complets de moteurs de jeu/production doivent consulter le document complet des exigences techniques de Games for Windows, car de nombreuses exigences sont affectées par ces outils.

Recommandations supplémentaires

En plus de garantir que votre composant prend en charge la création de titres conformes aux exigences de Games for Windows, il y a un certain nombre d’autres considérations que vous devriez prendre en compte lors de la conception et du déploiement d’une bibliothèque ou d’un utilitaire de support pour un jeu Windows.

Pour soutenir les développeurs travaillant sur des applications natives x64 64 bits, fournissez des versions natives 32 bits et 64 bits de vos bibliothèques. La version 32 bits doit être compatible 64 bits selon 2.2. Les bibliothèques pour les applications 32 bits ne doivent pas supposer que le bit haut de toute adresse 32 bits est inutilisé afin de prendre en charge l’utilisation dans des applications LARGEADDRESSAWARE x86.
Si vous fournissez des en-têtes de code natif (C/C++), utilisez la syntaxe des attributs du Standard Annotation Language (SAL) pour décorer vos routines d’API publiques. Cela permettra aux utilisateurs de votre bibliothèque de tirer le maximum de bénéfices de l’utilisation de l’analyse de code statique (/analyze), qui fait partie de Visual Studio Team System 2005, Visual Studio Team System 2008, Visual Studio 2010 Premium et Visual Studio 2010 Ultimate, ainsi que des outils de compilation SDK Windows disponibles publiquement.
Si votre produit crée des threads dans le processus de l’utilisateur, assurez-vous de nommer chaque thread afin que les outils de débogage puissent annoter correctement les threads en cours d’exécution.
Si vous écrivez des routines destinées à être appelées dans la boucle principale d’un jeu, utilisez les routines D3DX D3DPERF_BeginEvent/EndEvent et D3DPERF_SetMarker pour annoter les opérations de haut niveau afin de faciliter l’identification des goulots d’étranglement en utilisant PIX pour Windows.

Remarque

Pour la fonctionnalité de diagnostic graphique de Visual Studio 2012, ces routines D3DX et PIX sont remplacées par l’interface ID3DUserDefinedAnnotation.
Pour les bibliothèques de mise en réseau, fournissez des implémentations neutres en termes d’IP et évitez les routines IPv4 uniquement obsolètes pour prendre en charge les technologies IPv6 et Teredo dans Windows XP avec Service Pack 2, Windows Vista et Windows 7.
Les fournisseurs de services de jeux doivent s’enregistrer auprès de Games Explorer en utilisant la version 2 du schéma GDF, et utiliser la fonctionnalité RSS pour fournir des nouvelles liées au service.

Vitrines des jeux pour Windows

Introduction

Les vitrines Games for Windows vont au-delà de la simple fourniture d’une solide expérience de jeu sur PC Windows. En mettant en œuvre ces fonctionnalités, les jeux peuvent ajouter plus d’excitation à l’expérience utilisateur sur les dernières plateformes Windows.

Les titres Games for Windows doivent remplir toutes les exigences techniques énumérées dans cet article, mais les vitrines sont facultatives. Ces titres sont libres de mettre en œuvre certaines, aucune ou toutes ces vitrines.

S.1 Exploiter Direct3D 11

Prérequis

Direct3D 11 est l’API de rendu de nouvelle génération pour Windows Vista et Windows 7. Les jeux exploitant Direct3D 11 utilisent du contenu optimisé, des techniques de rendu avancées et de nouvelles fonctionnalités matérielles pour créer une expérience captivante sur du matériel prenant en charge les versions 10, 10.1 et 11.

Si le jeu implémente également Direct3D 9, une comparaison côte à côte doit démontrer une amélioration perceptible de la qualité du contenu, de la fidélité visuelle, des performances, de la complexité des scènes et d’autres domaines de la fidélité graphique pour Direct3D 11. Ce support est soumis à l’exigence technique 1.7 de Games for Windows.

La technologie Direct3D 10level9 peut être utilisée pour prendre en charge le matériel vidéo Direct3D 9 de classe Shader Model 2.0/3.0 sur Windows Vista et Windows 7, plutôt que d’utiliser une implémentation côte à côte de Direct3D 9 pour un support matériel large. Cependant, cela ne suffit pas pour démontrer cette vitrine.

Sur les ordinateurs exécutant Windows Vista ou Windows 7 avec Direct3D 11 installé, le jeu doit par défaut utiliser Direct3D 11.

Rationale

L’API Direct3D 11 repose sur le modèle de pilote d’affichage Windows (WDDM) et l’infrastructure Direct3D 10.1 pour prendre en charge de nouvelles capacités : tessellation matérielle, shaders de calcul, rendu multithread et création de ressources, nouveaux formats de compression de texture et un langage de shader plus flexible. Direct3D 11 fournit un support matériel unifié pour les cartes vidéo modernes, y compris les dernières pièces Direct3D 11, toutes les cartes vidéo Direct3D 10 et 10.1, et de nombreuses cartes vidéo Direct3D 9 Shader Model 2.0/3.0, qui sont le minimum requis pour le matériel vidéo pour le bureau 3D Aero.

Informations supplémentaires

Migrer un moteur de rendu Direct3D 9 pour utiliser la nouvelle interface Direct3D 11 est une tâche bien définie :

Éliminer toutes les opérations à fonctions fixes en faveur des shaders programmables.
Mettre à jour tous les shaders existants vers la nouvelle syntaxe du Shader Model 4.x/5.
Mettre à jour la gestion des ressources pour prendre en charge le nouveau modèle d’affichage.
Convertir tous les actifs pour utiliser une nouvelle liste de formats disponibles.
Mettre à jour la gestion de l’état de rendu pour utiliser des blocs d’état immuables, et remanier les constantes des shaders en tampons de constantes.

Cette conversion est essentielle pour permettre la démonstration Direct3D 11, bien que le résultat ne réponde pas à l’exigence de démonstration d’exploiter la nouvelle API.

La nouvelle API et le modèle de programmation HLSL associé offrent de nombreuses opportunités pour un contenu amélioré :

Exploiter les fonctionnalités matérielles Direct3D 10 existantes, telles que Geometry Shader, Stream Out, tableaux de textures, et les formats de textures compressées BC4/BC5.
Exploiter les fonctionnalités matérielles Direct3D 10.1 existantes, telles que les modes de fusion indépendants par cible de rendu, la lecture de profondeur MSAA, l’accès aux shaders par échantillon MSAA, les tableaux de cartes cubiques, et le rendu vers des formats compressés par blocs (BC).
Implémenter des algorithmes GPU avancés en utilisant Compute Shader avec CS4.x sur des cartes vidéo Direct3D 10/10.1 existantes (activés par des pilotes vidéo mis à jour) ou CS 5.0 sur des cartes vidéo Direct3D 11 de prochaine génération.
Rendre sur plusieurs threads en utilisant la création de ressources multi-threads et plusieurs contextes de périphériques pour améliorer les performances sur les systèmes multicœurs (avec des pilotes vidéo mis à jour). Pour plus d’informations, veuillez consulter les Jeux pour Windows Showcase S.3.
Utiliser les nouvelles fonctionnalités du matériel vidéo de classe Direct3D 11, telles que la tessellation matérielle avec les shaders de coque et de domaine, les fonctionnalités matérielles des shaders HLSL Shader Model 5.0, les formats de textures compressées BC6H/BC7, et le Dynamic Shader Linkage.

Les techniques qui peuvent être implémentées avec Direct3D 9 (principalement à travers un coût CPU élevé) peuvent être déchargées sur le GPU de manière efficace, libérant ainsi les ressources CPU pour soutenir d’autres demandes du jeu.

Les API Direct3D 11, les outils de support, et les exemples sont disponibles dans le SDK DirectX. Veuillez également consulter les API graphiques de Windows.

S.2 Exploiter x64 Native

Prérequis

Le jeu inclut un exécutable natif 64 bits qui offre une nouvelle expérience convaincante activée par les éditions x64 de Windows fonctionnant sur du matériel compatible x64. Une comparaison côte à côte avec la version 32 bits du jeu devrait montrer une amélioration perceptible de la complexité du contenu, des temps de chargement réduits, et des performances.

Sur les éditions 64 bits de Windows, l’installation devrait toujours configurer la version native 64 bits du jeu par défaut pour les raccourcis dans Games Explorer et Windows XP Professional x64 Edition. Si une double installation est souhaitée, une tâche de jeu supplémentaire peut être spécifiée pour Games Explorer sur Windows Vista et Windows 7 pointant vers la version 32 bits, mais la version native 64 bits devrait rester la version par défaut.

Notez que le jeu doit prendre en charge les éditions 64 bits de Windows Vista et Windows 7 pour répondre à cette recommandation de démonstration. La prise en charge de Windows XP Professional x64 Edition est encouragée, mais pas obligatoire.

Rationale

La technologie x64 fournit des capacités d’adressage 64 bits pour les marchés grand public et serveur qui incluent une compatibilité complète en vitesse avec les applications 32 bits existantes. La x64 est une partie clé de la feuille de route pour AMD (AMD64) et Intel (EMT64), et, à l’exception des CPU ultra-mobiles, prend en charge la technologie pour tous les processeurs de génération actuelle et future.

Windows XP Professional x64 Edition a été le premier système d’exploitation Windows orienté consommateur à prendre en charge la technologie x64, et Windows Vista et Windows 7 étendent considérablement la disponibilité de l’OS pour l’informatique grand public 64 bits. Avec 2 Go de RAM en standard sur de nombreux nouveaux ordinateurs, les améliorations supplémentaires de la mise à l’échelle de la mémoire ne profiteront pas aux applications individuelles 32 bits qui ne peuvent pas adresser plus de 2 Go de RAM physique. De nombreux jeux aujourd’hui sont confrontés à des défis pour intégrer tout le contenu disponible dans les contraintes de 2 Go d’espace d’adresse virtuel, surtout lorsqu’il est combiné avec les grandes mémoires vidéo disponibles sur les GPU haut de gamme, et passer à la technologie x64 augmente considérablement les niveaux de détail supportables.

La compatibilité x64 pour les jeux 32 bits est une exigence technique pour les Games for Windows (2.2), mais tirer pleinement parti des nouvelles technologies nécessite une implémentation native 64 bits.

Informations supplémentaires

Le principal avantage de l’adressage 64 bits est la capacité d’accéder directement à plus de 2 Go de mémoire physique et virtuelle. Le grand espace d’adresse de mémoire virtuelle permet une utilisation extensive des E/S mémoire-mappée sans souci des problèmes d’épuisement de l’espace d’adresse VM courants dans la programmation 32 bits. Les jeux peuvent tirer parti du nouvel espace pour améliorer considérablement les temps de chargement ou, dans certains cas, pour éliminer les pauses de chargement de contenu.

Les applications 32 bits existantes peuvent bénéficier des éditions x64 en ayant la capacité de traiter des adresses avec des données complètes 32 bits lorsqu’elles sont construites avec l’option de l’éditeur de liens Enable Large Addresses (/LARGEADDRESSAWARE). Sur les versions 32 bits de Windows XP, des modes de démarrage spéciaux permettaient à de telles applications d’adresser jusqu’à 3 Go de RAM, et les éditions x64 permettent d’accéder jusqu’à 4 Go de RAM pour les applications Large Address Aware (LAA). Bien que l’utilisation de LAA dans une application 32 bits ne réponde pas à cette exigence de démonstration, cette technologie de transition est un moyen extrêmement utile de fournir des avantages supplémentaires de mise à l’échelle sur les versions x64 de Windows pour ceux qui ne mettent pas pleinement en œuvre cette exigence de démonstration.

Pour plus d’informations, veuillez consulter Programmation 64 bits pour les développeurs et RAM, VRAM, and More RAM: 64-Bit Gaming Is Here sur le site Web Game Developer.

Remarque

Un défi clé pour cette démonstration est de s’assurer que toutes les bibliothèques ou composants tiers dont dépend votre jeu sont disponibles pour le développement natif 64 bits. De nombreuses API Microsoft héritées ont également été éliminées de l’environnement natif 64 bits, ce qui peut poser un défi pour les bases de code des moteurs contenant d’anciennes implémentations de systèmes clés.

S.3 Exploiter les processeurs multicœurs

Prérequis

Le jeu implémente des fonctionnalités qui tirent parti des processeurs multicœurs, en s’adaptant à 3, 4 ou plus de cœurs, lorsque disponibles.

Si le jeu prend en charge les systèmes à processeur unique ou double cœur, une comparaison côte à côte avec un système quadri-cœur devrait démontrer des fonctionnalités nouvelles perceptibles, des effets supplémentaires convaincants, une amélioration de la qualité du contenu, et/ou des performances améliorées.

Étant donné que la mise à l’échelle double cœur (dual-core) est déjà largement prise en charge par les jeux, ainsi qu’automatiquement utilisée par diverses améliorations de pilotes Direct3D, la mise à l’échelle double cœur n’est pas suffisante pour démontrer cette vitrine.

Rationale

La croissance continue des performances des CPU est passée des améliorations de fréquence d’horloge à l’ajout de cœurs de calcul. Les feuilles de route d’AMD et d’Intel sont basées sur des conceptions multicœurs évolutives. Toutes les plateformes de jeu de nouvelle génération ont des CPU multicœurs en raison de ce changement fondamental dans l’évolution des processeurs. Les applications monothreadées ne verront plus de gains significatifs avec les CPU de prochaine génération. Le multithreading simple ne pourra également pas évoluer à mesure que le nombre de cœurs CPU en utilisation courante augmentera à trois ou plus.

Informations supplémentaires

Notez que le nombre de cœurs n’a pas besoin d’être une puissance de deux, donc les jeux devraient évoluer de manière linéaire et gérer des nombres de cœurs de 3, 4, 5, 6, 7, 8, etc.

La mise à l’échelle en augmentant le nombre de threads dans une application ne fournit un retour que si le coût de la communication et de la synchronisation des threads est maintenu sous contrôle. La mise à l’échelle basée sur les fonctionnalités peut s’avérer une solution plus facile à court terme, permettant au jeu de fonctionner normalement sans les threads supplémentaires sur les systèmes à cœur unique et de les activer lorsque la puissance CPU supplémentaire est disponible.

Pour plus d’informations, veuillez consulter Codage pour plusieurs cœurs sur Xbox 360 et Microsoft Windows et Considérations relatives à la programmation sans verrou pour Xbox 360 et Microsoft Windows dans les articles DirectX, ainsi que l’utilitaire DXUTLockFreePipe et l’exemple CoreDetection.

Utiliser la création de ressources multi-threads et les contextes de périphériques Direct3D 11 est utile pour atteindre une évolutivité multicœur dans le rendu et le chargement des ressources graphiques. Veuillez consulter les Jeux pour Windows Showcase S.1.

Notez que l’utilisation directe de l’instruction CPU rdtsc, au lieu d’utiliser les API Windows pour calculer le timing sur les systèmes multicœurs, peut entraîner des problèmes sur certaines configurations matérielles et OS ; veuillez consulter la section Timing des jeux et processeurs multicœurs dans les articles DirectX.

S.4 Prise en charge de Games for Windows - LIVE

Games for Windows - LIVE n’est plus pris en charge par Microsoft.

S.5 Prise en charge Windows Touch

Prérequis

Les jeux compatibles avec le tactile sous Windows sont jouables en utilisant le tactile et/ou les gestes sur des ordinateurs équipés de Windows 7 avec un écran tactile. L’entrée au clavier peut également être utilisée, mais l’interface principale de jeu doit être basée sur le tactile.

L’activation du tactile ne doit pas empêcher l’utilisation de la souris ou d’un contrôleur classique, sous réserve de l’Exigence Technique 1.4.

Il n’est pas attendu que l’installateur du jeu prenne en charge la fonctionnalité tactile de Windows.

Rationale

Des écrans multi-tactiles pour ordinateurs sont disponibles pour les ordinateurs portables et de bureau, et ils représentent une caractéristique matérielle clé promue avec la sortie de Windows 7. Windows 7 prend en charge Windows Touch à travers le bureau et les interfaces de contrôles communs.

Informations supplémentaires

Les applications en code natif peuvent accéder au multi-tactile via les messages WM_TOUCH, en combinaison avec la fonction RegisterTouchWindow. Veuillez consulter également l’API Manipulations and Inertia.

Windows Presentation Foundation (WPF) 4.0 fournit une solution gérée pour les interfaces multi-tactiles.

Pour plus d’informations, consultez le SDK Windows Touch.

S.6 Prise en charge de High Color

Prérequis

Les jeux qui supportent High Color utilisent un format 10:10:10:2 (DXGI_FORMAT_R10G10B10A2, D3DFMT_A2B10G10R10) ou 16:16:16:16 (DXGI_FORMAT_R16G16B16A16, D3DFMT_A16B16G16R16) pour la mémoire tampon de rendu et le mode d’affichage plein écran.

En utilisant une cible de rendu High Color, le contenu à Haute Dynamique de Plage (HDR) peut être rendu avec un gamut étendu ou large lors du mappage de tons à une plage de 10 bits ou 16 bits.

Rationale

Les moniteurs sont capables d’afficher plus de 256 niveaux de couleurs par canal depuis de nombreuses années, même lorsque les écrans CRT étaient courants. Le matériel de sortie sur les cartes vidéo a été le facteur limitant. Les GPU modernes, y compris la plupart des matériels de classe Direct3D 9 et tous les matériels de classe Direct3D 10 et supérieurs, possèdent un matériel de sortie capable d’au moins 10 bits par canal, et la capacité matérielle est destinée à atteindre 16 bits par canal de couleur dans le futur. Les systèmes de connexion HDTV (HDMI, DisplayPort) ont été conçus pour gérer plus de 8 bits par canal également, et le VGA analogique peut déjà transporter de tels signaux.

Informations supplémentaires

Notez que High Color, ou Hi Color, se réfèrent historiquement au passage des affichages en couleur 256 (8 bits) aux affichages en couleur 15 ou 16 bits. La plupart des systèmes d’affichage sont depuis longtemps passés à True Color qui sont des couleurs en 24 bits, ou 8 bits par canal de couleur pour le rouge, le vert et le bleu. Par couleurs élevées, nous entendons ici une nouvelle génération de systèmes d’affichage capables de fonctionner avec plus de 8 bits par canal de couleur individuel. Cela est également appelé Deep Color.

Bonnes pratiques recommandées

Introduction

En plus de satisfaire aux exigences techniques et d’adopter un ou plusieurs Showcase pour votre titre, il existe un certain nombre de bonnes pratiques à suivre pour tous les jeux Windows. Bien que ces recommandations soient hors du cadre des exigences techniques principales, il est fortement encouragé de les appliquer à tous les titres de jeux pour Windows.

Recommandations supplémentaires

Utilisez le compilateur et le runtime les plus récents de Visual Studio. Les versions plus récentes du compilateur implémentent des améliorations significatives pour la qualité du code généré et pour les problèmes de sécurité, et elles utilisent des stratégies d’optimisation modernes pour les processeurs. Mettre à jour le compilateur et utiliser le Runtime C le plus récent est un moyen facile de migrer vers des pratiques de codage modernes.
Utilisez la version bibliothèque de liens dynamiques (DLL) du Runtime C, plutôt que la liaison statique, et utilisez le Secure CRT. (Des exceptions peuvent être faites dans des cas spéciaux de pré-installation, comme pour un programme Autorun ou pour l’installateur lui-même).
Pour l’audio des jeux, utilisez XAudio2, X3DAudio et/ou XACT, plutôt que DirectSound. Pour les moteurs audio qui effectuent tout le mixage et la conversion de taux de source et qui ont seulement besoin d’une solution à faible latence pour la sortie audio, utilisez DirectSound sur Windows XP (seulement) et WASAPI sur Windows Vista et Windows 7.
Évitez d’utiliser les API obsolètes et dépréciées : DirectDraw, DirectSound, DirectPlay, la couche de performance de DirectMusic, DirectPlay Voice, et le mode conservé de Direct3D. Notez que DirectPlay Voice et le mode conservé de Direct3D ne sont pas disponibles sur Windows Vista ou Windows 7. DirectPlay et la couche de performance de DirectMusic ne sont pas disponibles pour les applications natives x64.
Optimisez en utilisant les ensembles d’instructions SIMD SSE/SSE2. Veuillez consulter l’API DirectXMath dans le SDK Windows comme solution multiplateforme pour les opérations mathématiques optimisées SIMD.
Appliquez les bonnes pratiques modernes pour la sécurité Windows (y compris les options du compilateur et du lieur comme /NXCOMPAT, /GS, /SAFESEH, /DYNAMICBASE, /SDL, etc.). Pour plus d’informations, consultez les Bonnes pratiques de sécurité dans le développement de jeux.
Utilisez les composants et bibliothèques les plus récents du SDK Windows. Éliminez les dépendances sur les composants hérités déployés hors bande de DirectSetup comme D3DX9, D3DX10 et D3DX11. Envisagez d’utiliser DirectXTex ou DirectXTK voire les deux.
Évitez d’utiliser l’ancien compilateur HLSL, et utilisez plutôt le compilateur HLSL moderne. Si le support pour Pixel Shader 1.x est requis par votre application, utilisez l’assemblage shader plutôt que HLSL, ou limitez l’utilisation de l’ancien compilateur à ces seuls scénarios.

Ressources

Terme	Description
Jeux pour Windows : Cas pratique de test	Bonnes pratiques pour les jeux sur Windows XP, Windows Vista et Windows 7
SDK Windows	Windows SDKs
Instructions de contrôle des comptes d’utilisateur	Exigences de développement d’application Windows Vista pour la compatibilité avec le contrôle de compte utilisateur
Developer Portal de DirectX	Centre de développement Directx
Blog sur les jeux pour Windows et le SDK DirectX	Jeux pour Windows et le SDK DirectX
Articles supplémentaires sur DirectX	Articles techniques sur DirectX

Partager via

Spécifications techniques des jeux pour Windows : bonnes pratiques pour les jeux sur Windows XP, Windows Vista, Windows 7 et Windows 8

Différences pour Windows 8

Informations supplémentaires

Jeux pour Windows

1.1 Intégration à l’Explorateur de jeux

1.2 Prise en charge de la sécurité familiale / Contrôle parental

1.3 Prise en charge des sauvegardes de jeux enrichies

1.4 Prise en charge de la manette Xbox 360 pour Windows [Exigence conditionnelle]

1.5 Prise en charge de multiples ratios d’aspect et résolutions

1.6 Lancement depuis le Windows Media Center

1.7 Prise en charge de Direct3D

1.8 Activer la prise en charge DPI élevé

Sécurité et compatibilité

2.1 Respecter les directives du contrôle de compte utilisateur

2.2 Prise en charge des versions Windows x64

2.3 Signer les fichiers

2.4 Signer les pilotes

2.5 Effectuer une vérification correcte des versions

2.6 Prise en charge des sessions utilisateur concurrentes

2.7 Prise en charge des noms longs

Installation

3.1 Prise en charge d’une installation facile

3.2 Prise en charge du contrôle de compte utilisateur pour l’installation

3.3 Installer dans les dossiers corrects

3.4 Installer correctement les ressources Windows

3.5 Éviter les redémarrages pendant l’installation

3.6 Utiliser correctement la gestion des versions de fichiers

3.7 Prise en charge de l’autorun [Exigence conditionnelle]

Fiabilité

4.1 Éliminer les redémarrages inutiles

4.2 Éliminer les échecs de l’Application Verifier

4.3 Prise en charge du rapport d’erreurs Windows et des informations de version de fichier

Terminologie de la manette Xbox 360 pour Windows

Directives pour les produits middleware de jeux

Introduction

Recommandations supplémentaires

Vitrines des jeux pour Windows

Introduction

S.1 Exploiter Direct3D 11

S.2 Exploiter x64 Native

S.3 Exploiter les processeurs multicœurs

S.4 Prise en charge de Games for Windows - LIVE

S.5 Prise en charge Windows Touch

S.6 Prise en charge de High Color

Bonnes pratiques recommandées

Introduction

Recommandations supplémentaires

Ressources

Commentaires

Ressources supplémentaires