Exigences techniques relatives aux jeux pour Windows : meilleures pratiques pour les jeux sur Windows XP, Windows Vista, Windows 7 et Windows 8

Article
06/03/2023

Cet article fournit les exigences techniques et les meilleures pratiques pour les jeux qui s’exécutent sur Windows. Nous avons rédigé ces exigences techniques et meilleures pratiques principalement pour couvrir Windows Vista et Windows 7, ainsi que le système d’exploitation Windows XP hérité. Ces bonnes pratiques s’appliquent également généralement aux jeux Win32 de bureau 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 commune Xbox 360 pour Windows
Recommandations pour les produits d’intergiciel de jeu
Ressources

Différences pour Windows 8

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

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

Tous les jeux que vous inscrivez avec l’Explorateur de jeux sont exposés sous forme de vignettes dans la nouvelle interface utilisateur Windows, mais la plupart des métadonnées associées au titre ne sont plus visibles. Vous utilisez toujours l’outil Games Definition File Maker (GDFMAKER.EXE), qui est désormais disponible dans le Kit de développement logiciel (SDK) Windows, pour créer les métadonnées. Vous utilisez également les mécanismes existants pour déployer les métadonnées. Continuez à tester votre inscription dans l’Explorateur de jeux à l’aide de Windows 7 et vérifiez que la nouvelle vignette de l’interface utilisateur Windows s’affiche lorsque vous l’installez sur Windows 8 (voir Intégration 1.1 de l’Explorateur de jeux).

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

L’inscription auprès des API Game Explorer continue d’être le mécanisme d’inscription de votre jeu auprès du Contrôle parental Windows

Nous vous recommandons d’exécuter la version du KIT de développement logiciel (SDK) Windows de GDFMAKER sur la version publiée de Windows 8 pour vous assurer qu’elle peut remplir tous les systèmes d’évaluation actuellement pris en charge.

Notes

Cette version de GDFMAKER nécessite .NET 4.0.

Voir 1.2 Prise en charge de la sécurité familiale et des contrôles parentaux.

Il existe désormais trois choix pour utiliser l’API XINPUT en fonction de vos besoins

XINPUT 1.4 est intégré à Windows 8. Les applications du Windows Store et les applications Win32 de bureau peuvent utiliser XINPUT 1.4. Toutes les versions de Windows peuvent utiliser XINPUT 9.1.0 pour les contrôleurs courants simplifiés, mais il n’existe aucun package de redistribution avec XINPUT 9.1.0. Toutes les versions de Windows peuvent également utiliser la version existante du SDK DirectX XINPUT 1.3, qui nécessite le déploiement de DirectSetup.

Consultez la version 1.4 Prise en charge de la manette commune Xbox 360 pour Windows.

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

Les jeux qui s’exécutent sur Windows 7 peuvent et doivent s’exécuter correctement sur Windows 8 plateformes x86 et x64.

Consultez 2.2 Prise en charge des versions windows x64.

Vérifier que toutes les vérifications du système d’exploitation sont effectuées correctement

La version du système d’exploitation Windows 8 est 6.2 . Windows 8 réussit les tests de barre minimale actuels que nous recommandons pour le déploiement de jeux.

Le package DirectX End-User Redistribution s’exécute correctement sur Windows 8, comme sur Windows 7, pour déployer D3DX9, D3DX10, D3DX11, XINPUT 1.3, XAUDIO 2.7, XACTEngine, etc.

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

Consultez 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 (qui nécessite un accès réseau). Toutefois, nous recommandons aux développeurs .NET de passer au runtime .NET 4.0.

Notes

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

Consultez 3.4 Installer correctement les ressources Windows.

L’utilisation d’un exécuteur automatique ou d’une autre technologie de pré-installation qui s’appuie 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 sur Windows 8 par défaut.

Voir 3.7 Prise en charge de l’exécution automatique.

Il existe un vérificateur d’application mis à jour pour Windows 8

Le Kit de développement logiciel (SDK) Windows 8 inclut ce vérificateur d’application mis à jour.

Voir 4.2 Éliminer les échecs du vérificateur d’application.

Informations supplémentaires

Windows 8 et Windows Server 2012 livre de recettes de compatibilité
Où est le kit SDK DirectX ?

Jeux pour Windows

Résumé des conditions requises pour les jeux

Avantages pour les clients

Les jeux sur ordinateur sont une expérience de divertissement clé sur Windows, mais les problèmes de facilité d’utilisation ont provoqué la frustration des 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 (films ou chansons, par exemple). Les innovations, telles que Games Explorer, exposent les jeux de manière cohérente et différente des applications standard. Ces innovations donnent également aux jeux un statut de citoyen de première classe dans Windows, ainsi que Musique et Images. Les exigences suivantes permettent de 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, ils garantissent la compatibilité avec Windows XP.

1.1 Intégration de l’Explorateur de jeux

Exigence

Le jeu doit être visible dans l’Explorateur de jeux (le dossier Jeux ) sur Windows Vista et Windows 7. Lorsqu’il est sélectionné, le jeu doit également afficher des métadonnées correctes, notamment l’éditeur, le développeur, la date de publication, la version, les scores de l’index d’expérience Windows, l’évaluation (le cas échéant) et les liens hypertexte associés.

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

En outre, les programmes d’installation 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 dans tout autre emplacement.
Les tâches et les raccourcis à supprimer ne doivent pas être créés.
Les utilisateurs doivent être en mesure de supprimer le jeu à l’aide de programmes et de fonctionnalités dans Panneau de configuration sur Windows Vista et Windows 7, ou d’ajouter ou de supprimer des programmes dans Panneau de configuration sur Windows XP.

Sur Windows XP et sur les versions précédentes de Windows, le programme d’installation du jeu est libre de créer des groupes de programmes, des icônes de bureau ou des raccourcis en fonction des besoins.

Justification

Le concept de l’Explorateur de jeux Windows est similaire aux dossiers Windows XP Mes documents ou Mes images. L’idée est de centraliser du contenu similaire au même endroit et de faciliter l’organisation et les activités contextuelles. L’Explorateur de jeux étend le concept Mes documents ou Mes images en permettant une organisation et un contrôle plus riches sur les jeux. L’Explorateur de jeux permet aux joueurs d’afficher, d’organiser et d’interagir avec tous les jeux installés sur leurs systèmes. Il permet également aux éditeurs de jeux de communiquer plus efficacement des informations importantes sur les jeux. Le système est piloté par les données, ce qui permet à un éditeur de jeux de mettre à jour facilement les informations du jeu pendant toute la durée de vie du produit.

Informations supplémentaires

L’intégration à l’Explorateur de jeux nécessite la création d’un fichier de définition de jeu (GDF), qui est un fichier texte XML incorporé dans un fichier binaire (fichier exécutable ou DLL) en tant que ressource, ainsi qu’une icône Windows. Le jeu doit ensuite être inscrit auprès de l’Explorateur de jeux. Le GDF permet également d’exposer les informations fournies telles que le titre du jeu, l’éditeur, le développeur, les liens vers des sites web et les tâches facultatives. Notez que les tâches de support ne peuvent être que des liens vers des sites web, mais que les tâches de lecture peuvent également être utilisées pour des tâches de support facultatives.

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

Les détails de l’intégration à l’Explorateur de jeux Windows sont fournis dans le KIT de développement logiciel (SDK) DirectX. Le Kit de développement logiciel (SDK) DirectX inclut un éditeur de fichier de définition de jeu (GDF), ainsi qu’un exemple de GDF inclus dans GDFExampleBinary, un exemple. Un autre exemple, GameUxInstallHelper, fournit des routines pour intégrer les fonctionnalités requises dans les systèmes d’installation existants. Le validateur de fichier de définition de jeu (gdftrace.exe) prend en charge le débogage pour l’évaluation d’un GDF. Consultez également « Intégration de l’Explorateur de jeux Windows » dans la documentation du KIT de développement logiciel (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 la création de tâches de jeu et la prise en charge des notifications de mise à jour, des fournisseurs de services de jeux, des statistiques de jeu et des flux RSS pour les fournisseurs de services de jeux. La dernière version de GameUxInstallHelper gère toute l’inscription et la prise en charge héritée nécessaires pour utiliser un fichier GDF version 2 avec Windows Vista. Utilisez les outils et l’exemple de code du Kit de développement logiciel (SDK) DirectX d’août 2009 ou ultérieur. L’utilisation d’un fichier GDF version 2 est recommandée pour activer la prise en charge des flux RSS, des statistiques de jeu et des notifications de mise à jour. Consultez également les exemples ProviderGDFExampleBinary et GameStatisticsExample.

Sur Windows Vista Business Edition, Windows 7 Professionnel Edition et Êdition Entreprise de Windows Vista et windows 7, le lien Jeux dans le menu Démarrer est masqué. L’Explorateur de jeux est toujours disponible dans le menu Démarrer en cliquant sur Tous les programmes, puis sur Jeux.

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

1.2 Prendre en charge la sécurité familiale et le contrôle parental

Exigence

Les jeux doivent entièrement prendre en charge le contrôle parental Windows en respectant les règles suivantes :

Les jeux ne doivent pas exiger que l’utilisateur dispose d’informations d’identification administratives pour jouer. L’installation, la mise à jour corrective et la suppression peuvent nécessiter des informations d’identification administratives, sous réserve des exigences de la section 3. (En lien avec cette exigence 2.1, suivez les instructions de contrôle de compte d’utilisateur.)
Les jeux évalués par les tableaux d’évaluation pris en charge par Windows, tels que ESRB et PEGI, doivent inclure les informations d’évaluation qui leur sont attribuées dans leur fichier de définition de jeu (GDF). Toutes les données d’évaluation disponibles doivent être incluses dans chaque version localisée du GDF, ainsi que dans la version indépendante de la langue.
Les jeux doivent répertorier leurs exécutables dans le GDF pour fournir une bonne expérience utilisateur pour les restrictions générales d’application, sauf si le jeu utilise une technologie anti-piratage qui crée des exécutables nommés aléatoirement au moment de l’exécution.
Les jeux doivent appeler la méthode VerifyAccess de l’interface De l’Explorateur de jeux au démarrage, si disponible, et quitter si elle retourne *pfHasAccess comme FALSE.

Justification

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 pouvoir surveiller et contrôler l’accès de leurs enfants aux jeux. De plus, de nombreux groupes industriels, gouvernementaux et de défense des droits souhaitent de meilleures façons de permettre aux parents de surveiller et de contrôler les jeux auxquels leurs enfants sont exposés. Parallèlement à l’architecture proposée par Games Explorer, Microsoft fournit aux parents cette possibilité via le contrôle parental Windows.

Même pour les jeux qui ne participent pas à un programme de tableau d’évaluation, l’exigence de privilèges élevés crée une expérience de jeu médiocre pour la majorité des comptes d’utilisateur. C’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 évaluations qu’ils jugent appropriées pour leurs enfants. Le contrôle parental prend en charge de nombreux systèmes d’évaluation dans le monde entier. Le contrôle parental permet également aux parents de restreindre l’accès aux jeux basés sur des descripteurs de contenu (si le système d’évaluation applicable les prend en charge) et d’autoriser ou d’interdire l’accès à des jeux individuels.

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

Informations supplémentaires

Les jeux sans évaluation doivent toujours répondre aux conditions requises pour prendre en charge le jeu en tant qu’utilisateur standard et appeler VerifyAccess. Ces jeux sont par défaut dans la catégorie Non noté, affichent le texte « Aucune évaluation fournie » dans l’Explorateur de jeux et sont soumis au paramètre Restrictions de jeu dans Le contrôle parental pour les jeux non classés. Le paramètre Restrictions par défaut est Autoriser.

Les informations d’évaluation dans le GDF seront ignorées si le binaire contenant n’est pas correctement signé Authenticode. Consultez l’exigence 2.3.

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

Le GDF d’un fournisseur de jeux ne contient généralement aucune information d’évaluation, et il est soumis aux paramètres pour le contenu non classé.

Système d'exploitation	Systèmes d’évaluation pris en charge
Windows Vista	CERO (Japon) ESRB (États-Unis) OFLC (Australie) PEGI (Europe) PEGI Finlande (déconseillé) PEGI Portugal PEGI/BBFC (Royaume-Uni) USK (Allemagne)
Windows Vista avec un Service Pack	Les Service Packs pour Windows Vista prennent en charge les éléments suivants : GRB (Corée du Sud) Descripteurs de contenu variant ESRB « mild »
Windows 7	Windows 7 prend en charge les systèmes d’évaluation 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 d’évaluation 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 met fin à la prise en charge des systèmes suivants désormais déconseillés : PEGI-FI (Finlande) OFLC (Australie)

Notes

Tout titre qui inclut les nouveaux descripteurs de contenu ESRB Windows Vista Service Pack 1 (SP1) s’affiche comme Non classé sur Windows Vista sans Service Pack.

Les données d’évaluation plus récentes sont ignorées sur les versions des systèmes d’exploitation sans prise en charge de celles-ci. La variante PEGI (Finlande) est désormais déconseillée en faveur du système de notation STANDARD PEGI (Europe). 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 utilisateur standard, consultez l’article DirectX User Account Control for Game Developers.

Consultez l’exigence 1.1 pour plus d’informations sur le fichier de définition de jeu (GDF).

1.3 Prendre en charge les jeux enregistrés riches

[Cette exigence a été supprimée]

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

Exigence

Les jeux qui prennent en charge les contrôleurs de manette de commande doivent prendre en charge les manette Xbox 360 pour Windows à l’aide de l’API XInput. Si les périphériques DirectInput sont également pris en charge, DirectInput peut également être utilisé. Toutefois, 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 courants de la manette doivent utiliser les noms Xbox 360. Pour plus d’informations, consultez la liste terminologique de la manette commune Xbox 360 pour Windows .

Les vibrations du contrôleur doivent être désactivées lorsque le jeu est en pause ou suspendu.

Le contrôle souris/clavier ne peut pas être entièrement désactivé à tout moment. Au minimum, une option permettant de revenir aux menus de jeu doit être disponible.

Justification

Cette exigence donne aux joueurs la liberté d’utiliser la manette Xbox 360 ou le clavier et la souris, selon la méthode d’entrée qui est l’interface 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 vous recommandons d’implémenter la navigation dans le menu pour utiliser les boutons de contrôleur standard largement acceptés :

A - Accepter
B - Annuler
Démarrer - Accepter ou suspendre
Back - Annuler, sauvegarder un écran ou monter un niveau de menu

Pour plus d’informations, consultez XInput.

La rubrique XInput et DirectInput traite des problèmes liés à l’utilisation des deux API en même temps.

Il est recommandé de ne pas utiliser DirectInput pour implémenter des contrôles clavier ou souris. Les contrôles clavier et souris doivent uniquement être implémentés à l’aide de messages Windows et d’API Win32. Pour plus d’informations sur l’obtention d’informations de déplacement de souris haute résolution sans utiliser DirectInput, consultez Tirer parti de High-Definition déplacement de la souris.

1.5 Prise en charge de plusieurs proportions et résolutions

Exigence

Le jeu doit prendre en charge au moins les proportions suivantes et les résolutions d’écran associées :

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

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

Le jeu utilise la résolution de bureau de l’appareil d’affichage par défaut s’il s’agit d’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 résolution par défaut différente.
Le jeu doit inviter l’utilisateur à confirmer les nouveaux paramètres d’affichage lorsqu’une modification est apportée. Si l’utilisateur n’accepte pas dans les 15 secondes, l’affichage doit revenir au paramètre précédent.
Le jeu ne doit pas étirer les pixels ni centrer une fenêtre de rendu 4:3 pour prendre en charge les proportions d’écran large. Toutefois, la boîte aux lettres est acceptable.

Justification

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

Prise en charge des affichages détaillés.
Augmentation de la part de marché des moniteurs widescreen.
Déploiements HDTV pour Windows Media Center.
Exigences d’accessibilité.

Informations supplémentaires

Dans l’idéal, le jeu utilise par défaut le rapport d’aspect natif de l’affichage. Toutefois, l’obtention fiable de ces informations peut être un défi, de sorte que, en tant que solution plus générale, le jeu peut supposer que le bureau s’exécute au format d’aspect natif. La résolution de bureau peut être obtenue en appelant EnumDisplaySettings avec ENUM_REGISTRY_SETTINGS.

Pour plus d’informations, consultez les sections Proportion et Widescreen de l’article DirectX Introduction to the 10-Foot Experience for Windows Game Developers.

1.6 Lancement de la prise en charge à partir de Windows Media Center

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

1.7 Prise en charge de Direct3D

Exigence

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

Justification

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

L’utilisation de versions de Direct3D plus récentes que Direct3D 9 est vivement recommandée. Consultez jeux pour Windows Showcase S.1. L’exigence de Direct3D 10 ou Direct3D 11 est entièrement conforme à l’exigence 1.7.

1.8 Activer la prise en charge des ppp élevés

Exigence

Les jeux et leurs programmes d’installation doivent s’exécuter correctement sans problèmes visuels lorsque la mise à l’échelle par point par pouce (PPP) est activée (testée avec une mise à l’échelle de 144 PPP pour une mise à l’échelle 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 qu’il prend en charge les PPP. Pour ce faire, incorporez un élément manifeste : <dpiAware>true<dpiAware> .

Justification

Les moniteurs LCD de haute qualité sont courants en tant qu’écrans d’ordinateur, et ils semblent mieux lorsqu’ils sont pilotés à leurs résolutions natives (généralement 1280 1024, 1600 1200, etc.). Les clients qui ont des difficultés à lire du texte et à voir des images à cette résolution définissent souvent leurs ordinateurs de bureau à une résolution inférieure et souffrent des artefacts visuels de la mise à l’échelle de l’écran LCD. Au lieu de cela, les clients peuvent laisser la résolution à la taille native et modifier le DPI de l’affichage Windows, ce qui augmente l’apparence de l’élément et du texte sans sacrifier la qualité de l’image.

Bien que cette fonctionnalité soit disponible sous une forme quelconque depuis Windows XP, elle est rarement activée par les clients ou par les oem. Aujourd’hui, plus de la moitié de tous les écrans d’ordinateurs sont définis sur une résolution inférieure à la résolution native du moniteur, en fonction des commentaires des clients. Windows 7 rend cette fonctionnalité beaucoup plus visible pour les clients lors de l’installation initiale et lors de la modification des paramètres d’affichage, les encourageant à utiliser la mise à l’échelle DPI plutôt que de modifier la résolution du bureau.

Informations supplémentaires

La fonction SetProcessDPIAware peut être utilisée à la place, si elle est appelée au début du code de démarrage du processus. Il est préférable d’ajouter au manifeste pour vous assurer qu’il n’existe aucune condition de concurrence avec des éléments logiciels (tels que des DLL) qui peuvent s’initialiser avant l’appel du point d’entrée principal. Notez que SetProcessDPIAware est uniquement présent 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 qui contient 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 dpiware.manifest au projet. Vérifiez que l’incorporation du manifeste est définie sur Oui dans les propriétés du projet. Notez que les anciennes versions de l’outil manifeste (Mt.exe) génèrent un avertissement fallacieux avec les éléments de manifeste prenant en charge DPI. Pour résoudre ce problème, mettez à jour Mt.exe vers la dernière version du Kit de développement logiciel (SDK) Windows.

Visual Studio 2010 inclut un paramètre dans les propriétés du projet, nommé Enable DPI Awareness, qui élimine la nécessité d’un fichier comme dpiaware.manifest. Recherchez Activer la reconnaissance DPI en développant l’outilManifeste et propriétés de configuration, puis en sélectionnant Sortie d’entrée&.

Sur Windows, le mode d’affichage traditionnel est défini par défaut sur 96 PPP, ce qui était courant pour les moniteurs CRT.

Bien que les applications en plein écran modifient la résolution d’affichage, elles utilisent souvent des messages et des métriques de fenêtre lors de la configuration des mémoires tampons et des rectangles d’affichage. La virtualisation DPI entraîne l’affichage de ces modes d’affichage plein écran rogné, et la déclaration de la prise en charge de la résolution permet d’éviter ces problèmes. Pour plus d’informations, consultez Écriture DPI-Aware applications Win32.

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 garantissent qu’ils fonctionnent avec Windows sur différentes architectures, sous différentes configurations et dans différents modes.

2.1 Suivre les instructions de contrôle de compte d’utilisateur

Exigence

Chaque fichier exécutable (autrement dit, chaque fichier qui a une extension .exe) doit contenir un manifeste incorporé qui définit son niveau d’exécution en incluant la balise suivante :

            <requestedExecutionLevel>

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

Les fichiers de données utilisateur qui ont des associations de fichiers inscrites 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.)

Justification

L’expérience Windows d’un utilisateur est plus sécurisée si les applications s’exécutent uniquement avec les autorisations nécessaires.

Informations supplémentaires

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

Si les privilèges d’administration ne sont pas requis, le manifeste XML incorporé doit inclure les éléments suivants :

            <?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 des privilèges d’administration sont requis, le manifeste XML incorporé doit inclure les éléments suivants :

            <?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 incorporé en ajoutant simplement un fichier manifeste (.manifest) qui contient l’un des blocs précédents au projet, et en veillant à ce que le manifeste incorporé soit défini sur Oui dans les propriétés du projet pour l’outil Manifeste. Pour Visual Studio 2008 et 2010, les propriétés UAC peuvent être définies directement dans les propriétés du projet pour l’éditeur de liens sur la page Fichier manifeste . Notez que les versions antérieures de l’outil Manifeste (Mt.exe) génèrent un avertissement fallacieux avec les éléments du manifeste UAC. Pour résoudre ce problème, mettez à jour Mt.exe vers la dernière version du SDK Windows.

Consultez la condition 3.1 pour plus d’informations sur les cas spéciaux d’installation, de mise à jour corrective 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, consultez Contrôle de compte d’utilisateur pour les développeurs de jeux.

2.2 Prise en charge des versions Windows x64

Exigence

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

Les titres et les programmes d’installation de titre ne doivent pas contenir de code 16 bits ou s’appuyer sur un composant 16 bits.
Si le jeu dépend des pilotes en mode noyau pour le fonctionnement, les versions x64 de ces pilotes doivent être disponibles. La configuration du jeu doit détecter et installer les pilotes et composants appropriés pour les éditions 64 bits de Windows.

Justification

De nombreux utilisateurs de Windows Vista et Windows 7 exécutent des éditions 64 bits du système d’exploitation pendant toute la durée de vie du produit. Il est donc essentiel que les applications soient compatibles avec ce système d’exploitation.

Informations supplémentaires

Windows sur Windows 64 (WOW64) permet au code 32 bits de s’exécuter sur les éditions 64 bits de Windows. Il n’est donc pas nécessaire que l’application soit du code natif 64 bits sur les éditions 64 bits de Windows. Le code seize bits ne s’exécute pas sur les éditions 64 bits de Windows.

Le maintien de la compatibilité avec Windows XP Professionnel Édition x64 n’est pas obligatoire, mais il est fortement recommandé.

Pour plus d’informations, consultez Programmation 64 bits pour les développeurs de jeux.

2.3 Fichiers de signature

Exigence

Tous les fichiers de code exécutables (généralement 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 timestamp valide pour la signature de production.

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

Justification

La signature d’un fichier permet aux utilisateurs de décider s’ils doivent faire confiance à une application et garantit aux utilisateurs que les fichiers n’ont pas été falsifiés. Il permet également aux applications de s’exécuter correctement dans des environnements verrouillés.

Informations supplémentaires

Pour plus d’informations, consultez Signature Authenticode pour les développeurs de jeux.

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

Nous vous déconseillons de signer les fichiers d’armoire (.cab), sauf s’ils sont relativement petits (moins de 100 Mo).

2.4 Sign Drivers

Exigence

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 disposer d’une signature Microsoft, qui peut être obtenue auprès de Windows Hardware Quality Labs (WHQL) ou du programme SIGNATURE de fiabilité du pilote (DRS).

Justification

Les pilotes mal écrits ou malveillants peuvent affecter gravement 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 stratégie peut également être activée pour les éditions 32 bits de Windows Vista et Windows 7.

Informations supplémentaires

Les versions natives 32 bits et 64 bits de tous les pilotes en mode noyau sont nécessaires par exigence 2.2.

Pour plus d’informations sur les programmes de signature de pilotes Microsoft, consultez le portail des développeurs de matériel Windows.

2.5 Effectuer une vérification de version appropriée

Exigence

Les jeux ne doivent pas échouer à s’exécuter sur les systèmes d’exploitation futurs, comme indiqué par les modifications apportées au numéro de version De Windows, sauf si le Contrat de licence utilisateur final interdit l’utilisation sur les systèmes d’exploitation futurs. Si le jeu est censé échouer, il doit le faire normalement en affichant un message approprié à l’utilisateur.

Si des vérifications de version 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 de version explicites 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 l’installation du runtime DirectX (DirectSetup).

Justification

Lorsque les utilisateurs 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 écrits continuent de créer des problèmes pour les logiciels qui, sinon, fonctionnent correctement sur les versions plus récentes de Windows ou simplement avec l’ajout d’un Service Pack Windows.

Une logique de comparaison de vérification de version fragile pour le runtime DirectX a créé de nombreuses installations ayant échoué lorsqu’il est exécuté sur différentes versions de Windows. Le numéro de version DirectX s’applique uniquement aux composants principaux du système d’exploitation. Elle ne s’applique pas aux composants côte à côte du SDK DirectX qui sont utilisés par de nombreux jeux.

Informations supplémentaires

Il est assez courant que les programmes d’installation recherchent une version minimale du système d’exploitation. Toutefois, cette vérification doit être effectuée avec précaution pour s’assurer qu’elle teste une valeur supérieure ou égale à, plutôt qu’une simple égalité, ce qui se verrouille sur une version spécifique du système d’exploitation. L’utilisation du test HighVersionLie d’Application Verifier est un moyen simple et rapide de déterminer comment votre programme d’installation réagira à une modification significative du numéro de version du système d’exploitation.

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

Pour connaître les meilleures pratiques relatives au déploiement du runtime DirectX, consultez Installation de DirectX pour les développeurs de jeux.

Il est recommandé que les jeux qui prennent en charge Windows XP recherchent un niveau de Service Pack égal ou supérieur à 2, car le Service Pack 2 (SP2) et le Service Pack 3 (SP3) offrent des améliorations significatives en matière de sécurité, une exigence de redistribution du runtime DirectX simplifiée 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 pour Windows - LIVE, etc.).

2.6 Prise en charge des sessions utilisateur simultanées

Exigence

Les jeux qui s’appuient sur des graphiques 3D ne doivent pas fonctionner via une connexion Bureau à distance, mais l’utilisateur doit être averti en cas d’échec du jeu.

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

Les jeux ne doivent pas bloquer l’utilisation de sessions utilisateur simultanées.
Un jeu doit s’exécuter 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 autre session.
Les jeux doivent prendre en charge la commutation rapide des utilisateurs.
Les jeux ne doivent pas tenter de désactiver le basculement de tâche 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 Désactivation des touches de raccourci dans les jeux.

Justification

Les utilisateurs Windows doivent être en mesure d’exécuter des sessions simultanées sans conflit ni interruption. Il s’agit d’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 différente de zéro indique que la session est distante.

Pour plus d’informations, consultez Changement d’utilisateur rapide. Notez que le basculement rapide d’utilisateur se produit si les restrictions de temps du contrôle parental sont activées lorsque le temps de l’utilisateur est terminé. Pour plus d’informations, consultez condition requise 1.2.

2.7 Prendre en charge les noms longs

Exigence

Si un jeu prend en charge l’enregistrement de fichiers, il doit être en mesure d’enregistrer des fichiers qui ont 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 d’entrée utilisateur utilisés pour créer des noms de fichiers ou des chemins d’accès.

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

Justification

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 qui contiennent les valeurs maximales définies dans le Kit de développement logiciel (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 de distribution de composants système officielles. Une expérience d’installation simplifiée offre une expérience prête à l’emploi plus accessible et sans problème pour les jeux.

3.1 Prise en charge installation facile

Exigence

Les jeux doivent fournir un chemin simplifié dans l’interface utilisateur de configuration en implémentant les éléments suivants :

Affiche un maximum d’une invite de CLUF.
Le chemin d’installation par défaut doit ignorer toutes les sélections pour l’installation (telles que les sélections de dossiers d’installation ou de composants), assumer les sélections par défaut, puis exécuter le jeu ou le lanceur en cas d’installation réussie, sans invite supplémentaire. Si vous le souhaitez, une option d’installation personnalisée peut être fournie pour les options de configuration avancées.
Installez tous les composants du système d’exploitation requis (tels que les runtimes DirectX et Visual C) à l’aide des packages de redistribution Microsoft appropriés. L’installation doit être effectuée en mode silencieux, sans invite et sans être protégée par les vérifications de version des composants.
Fournissez la suppression par le biais des programmes et des fonctionnalités dans Panneau de configuration pour l’application de jeu et les fichiers de travail générés. Une option pour supprimer tous les fichiers de données créés par l’utilisateur est recommandée. Le processus de suppression doit s’assurer que tous les fichiers installés sont supprimés et que tous les paramètres (par exemple, les entrées de liste d’exceptions de pare-feu et les clés de Registre) sont effacés. Les composants redistribués du système d’exploitation ne doivent pas être supprimés.
Si le jeu nécessite l’ajout d’exceptions au Pare-feu Windows, le processus d’installation peut inviter à informer les utilisateurs que cette modification est requise. Cette invite doit s’afficher avant le début de l’installation.

L’installation et la suppression peuvent nécessiter des droits d’administration. La mise à jour corrective peut nécessiter une invite d’informations d’identification d’administration, en fonction de la fréquence de mise à jour. Le jeu normal ne doit pas nécessiter de droits d’administration, conformément à l’exigence 2.1 Suivre les instructions de contrôle de compte d’utilisateur.

Justification

L’installation facile est une philosophie de développement de jeux windows qui est conçue pour simplifier et simplifier le processus parfois fastidieux et déroutant d’installation de jeux sur des ordinateurs qui exécutent des systèmes d’exploitation Windows. L’installation facile est possible 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 principaux objectifs sont les suivants :

Réduisez le temps nécessaire pour entrer dans le jeu et commencer à jouer.
Réduisez 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 ont des invites qui autorisent les installations non fonctionnelles, même si l’application semble avoir été correctement installée. Par exemple, un jeu peut exiger qu’un utilisateur accepte un CLUF. Le jeu est ensuite installé, puis le CLUF DirectX s’affiche. Ce CLUF permet aux utilisateurs de refuser et donc d’ignorer l’installation du runtime DirectX. Ce scénario peut entraîner un jeu qui ne parvient pas à s’exécuter en raison de composants manquants.

Informations supplémentaires

Pour plus d’informations sur l’installation de jeux, les techniques d’installation de jeux non traditionnelles, les solutions de mise à jour corrective compatibles avec UAC et la gestion des mises à jour correctives fréquentes, consultez les articles DirectX suivants :

Notes

La suppression des fichiers de données générés spécifiques à l’utilisateur doit être effectuée uniquement pour l’utilisateur actuel et pour les emplacements utilisateur partagés courants. Il n’existe aucun moyen fiable d’analyser le système pour supprimer des fichiers spécifiques à l’utilisateur pour d’autres utilisateurs, même si la suppression nécessite des informations d’identification administratives.

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

Exigence

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 du programme d’installation et du lecteur, même pour les systèmes mono-utilisateur en raison de l’élévation des informations d’identification de l’administrateur. Par conséquent, lorsqu’un jeu s’exécute 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 Exception du Pare-feu Windows ne doit pas s’afficher lorsqu’un utilisateur héberge ou rejoint un jeu multijoueur. Toute configuration requise doit être effectuée au moment de l’installation. Les instructions d’installation doivent informer l’utilisateur que cette opération se produira dans le cadre de l’installation.

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

Si le jeu est lancé par le programme d’installation une fois l’installation terminée, il doit être lancé dans le contexte de l’utilisateur d’origine.

Justification

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

La UAC est active par défaut sur Windows Vista et Windows 7, et la grande majorité des clients (88 % ou plus, selon les commentaires) laissent cette fonctionnalité activée.

Informations supplémentaires

Pour plus d’informations sur la configuration du Pare-feu Windows, consultez l’article DirectX Pare-feu Windows pour les développeurs de jeux et l’exemple FirewallInstallHelper.

Le lancement standard du jeu à la fin du processus d’installation ne répond pas au dernier aspect de cette exigence si l’installation est lancée par un utilisateur standard et si le processus d’installation nécessite des privilèges d’administration (c’est-à-dire, invite à entrer des informations d’identification d’administrateur). Il hérite également des privilèges d’administration, ce qui représente un risque potentiel pour la sécurité. Au lieu de cela, un chargeur de démarrage d’installation doit lancer le jeu après un appel réussi du programme d’installation. Pour plus d’informations, consultez l’article msdn Magazine Teach Your Apps to Play Nicely with Windows Vista User Account Control.

3.3 Installer sur les dossiers corrects

Exigence

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 lors de la première exécution du jeu, et non lors de l’installation.

Justification

Les utilisateurs doivent avoir la possibilité d’installer des applications là où ils en ont besoin. Ils doivent également avoir 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 des fichiers exécutables de prise en charge pour implémenter des scénarios d’installation à la demande et de mise à jour corrective avancés.

Étant donné que l’installation peut nécessiter une élévation vers un autre compte d’utilisateur pendant le processus d’installation de tous les utilisateurs, il n’existe aucun emplacement utilisateur approprié pour stocker les données au moment de l’installation. En outre, si le chiffrement de fichiers est activé, les fichiers chiffrés sont accessibles uniquement par le compte d’utilisateur qui les a créés.

3.4 Installer correctement les ressources Windows

Exigence

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 à l’aide d’un Microsoft Service Pack ou d’un package d’installation approuvé par Microsoft qui contient le composant système. Les composants système ne doivent jamais être reconditionnés.

Justification

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 veillant à ce que les résultats d’une installation soient 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 pour une utilisation exclusive par le système d’exploitation. Les tentatives d’accès aux ressources protégées entraînent généralement une erreur de déni d’accès.

Pour plus d’informations sur les meilleures pratiques lorsque le runtime DirectX est déployé avec un jeu, consultez l’article DirectX Installation de DirectX pour les développeurs de jeux.

3.5 Éviter les redémarrages pendant l’installation

Exigence

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

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

Les boîtes de dialogue Fichiers en cours d’utilisation qui sont inclus dans les packages Windows Installer doivent contenir une option permettant de fermer automatiquement les applications et de tenter de les redémarrer une fois l’installation terminée.

Justification

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, consultez Utilisation de Windows Installer avec le Gestionnaire de redémarrage.

3.6 Utiliser correctement le contrôle de version des fichiers

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

3.7 Prise en charge de l’exécution automatique [Condition requise]

Exigence

Pour les jeux distribués sur CD, DVD ou tout autre support amovible qui prend en charge l’exécution automatique, lorsque le disque est inséré pour la première fois, l’application doit automatiquement exécuter ou inviter l’utilisateur à installer le jeu, sauf si l’utilisateur a désactivé la fonctionnalité d’exécution automatique.

Une fois l’application correctement installée, la réinsérer le disque dans le lecteur ne doit pas entraîner 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 (autrement dit, elle doit avoir asInvoker dans le manifeste, selon l’exigence 2.1, bien qu’elle puisse lancer le programme d’installation ou un autre utilitaire qui nécessite des droits d’administration. L’élévation ne doit se produire que si le jeu n’est pas installé ou si l’utilisateur le sélectionne spécifiquement.

Justification

L’exécution automatique simplifie l’expérience d’utilisation d’applications multimédias distribuées, telles que les jeux qui nécessitent généralement que le disque soit présent dans le lecteur pour pouvoir jouer au jeu.

Informations supplémentaires

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

Pour les jeux distribués sur plusieurs disques, les disques suivants doivent idéalement utiliser la fonctionnalité d’exécution automatique ou poursuivre l’installation sans demander à l’utilisateur d’appuyer sur une touche ou d’effectuer d’autres actions.

Lors de la création d’un programme d’exécution automatique, vérifiez que tous les composants requis sont présents sur les nouvelles installations de Windows. Les applications classiques s’appuient sur les technologies installées par le programme d’installation, mais l’exécution automatique elle-même s’exécute avant qu’une telle installation ne se produise. Un exemple courant est l’échec des programmes d’exécution automatique, car les DLL Visual C Runtime n’ont pas été incluses dans le cadre de l’installation de Windows. Par conséquent, le programme d’exécution automatique doit utiliser le déploiement CRT local de l’application ou doit lier statiquement le CRT.

Les programmes d’exécution automatique écrits pour être utilisés sur des versions de Windows avant Windows Vista ne doivent pas utiliser le runtime .NET, car cette technologie n’est pas incluse dans 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 d’exécution automatique ne peuvent pas nécessiter la présence de composants facultatifs du SDK DirectX côte à côte, tels que D3DX9, D3DX10, D3DX11, XAudio2, X3DAudio, XACT, XINPUT et MDX 1.1.

Pour obtenir un exemple d’exécution automatique, consultez Exemple d’exécution automatique.

Fiabilité

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

Avantages pour les clients

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

4.1 Éliminer les redémarrages inutiles

Exigence

Tous les programmes d’installation d’application doivent tirer parti des API du gestionnaire de redémarrage pour éviter les redémarrages du système (voir condition 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 graphiques graphiques doivent répondre immédiatement (TRUE) en vue d’un redémarrage.
WM_ENDSESSION avec LPARAM = ENDSESSION_CLOSEAPP (0x1): Les applications doivent retourner 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.

Justification

Les redémarrages du système sont une interruption majeure. Elles entraînent une mauvaise expérience utilisateur et doivent être réduites. Certaines opérations, telles que les mises à jour critiques du système, 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 façon, ils peuvent éviter des retards inutiles dans les demandes de redémarrage valides.

Informations supplémentaires

Si un programme d’installation 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, consultez l’article MSDN à propos du Gestionnaire de redémarrage.

4.2 Éliminer les échecs du vérificateur d’application

Exigence

Le jeu ne doit pas générer d’échecs s’exécutant sous Microsoft Application Verifier (AppVerifier), version 4.0 ou ultérieure, dans les tests suivants :

Principes de base : handles, tas, verrous, mémoire, TLS
Divers : DangerousAPIs, DirtyStacks

Justification

AppVerifier teste de nombreux problèmes connus qui provoquent des blocages 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, consultez Application Verifier et Using Application Verifier within your Software Development Lifecycle on MSDN. Vous pouvez télécharger Application Verifier à partir de Détails du téléchargement : Application Verifier sur le Centre de téléchargement Microsoft.

Cette exigence ne s’applique pas aux applications managées pures sans interopérabilité native.

Ces tests doivent être exécutés sur une build de mise en production. Le débogage des builds peut 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 sont toujours détectés, mais ils peuvent être plus difficiles à localiser si vous utilisez uniquement pageHeap partiel.

Si vous utilisez les tests liés à UAC/LUA dans Application Verifier pour répondre aux exigences 2.1 et 3.2 du contrôle de compte d’utilisateur, vous devez utiliser l’analyseur d’utilisateur standard pour passer en revue les résultats. Application Verifier propose également de nombreux autres tests utiles que vous êtes vivement encouragés à utiliser dans le cadre du développement et des tests pour garantir un niveau élevé de compatibilité avec les versions actuelles et futures de Windows. Le test HighVersionLie est utilisé pour vérifier la conformité à l’exigence 2.5.

Visual Studio Team System inclut un sous-ensemble de la fonctionnalité AppVerifier intégrée à l’environnement de débogage. Cela peut s’avérer utile pour le suivi et la résolution des problèmes liés aux tests de base : tas, handles et verrous.

4.3 Prise en charge des informations de Rapport d'erreurs Windows et de version de fichier

Exigence

Pour activer la prise en charge de Rapport d'erreurs Windows, les jeux doivent répondre aux exigences suivantes :

Les jeux doivent gérer uniquement les exceptions connues et attendues. Rapport d'erreurs Windows ne doit pas être désactivé. Si une erreur telle qu’une violation d’accès apparaît dans un jeu, elle doit autoriser Rapport d'erreurs Windows à signaler l’incident.
Tous les fichiers exécutables (par exemple, les fichiers .exe ou dll) doivent contenir un nom de produit, un nom d’entreprise et une version de fichier précis.
La sortie normale du jeu ne doit pas entraîner une erreur d’exception inconnue.

Justification

Les API Rapport d'erreurs Windows fournissent des commentaires essentiels à Microsoft pour la détection des blocages et 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 rapidement.

Informations supplémentaires

Les jeux peuvent inclure des gestionnaires d’exceptions non gérés personnalisés pour effectuer des fonctionnalités de prise en charge et de création de rapports personnalisés, 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 des propriétés Version.

Pour plus d’informations sur les API Rapport d'erreurs Windows et sur l’analyse des vidages sur incident générés lorsque vous utilisez ce service, consultez l’article DirectX Analyse du vidage sur incident.

Terminologie de la manette commune Xbox 360 pour Windows

Nom	Description
Un	Bouton A.
B	Bouton B.
RETOUR	Bouton Retour.
Pare-chocs (droite/gauche)	Bouton situé dans les bords supérieur droit et gauche du contrôleur. Équivalent à un bouton d’épaule.
pavé directionnel	Pavé directionnel du contrôleur.
D-pad	Abréviation acceptée du pavé directionnel.
DP	Abréviation du pavé directionnel et étiquette du contrôleur.
RB, LB	Abréviations des pare-chocs droit et gauche et étiquettes de contrôleur.
RS, LS	Abréviations de stick droit et gauche et étiquettes de contrôleur.
RT, LT	Abréviations de déclencheur droite et gauche et étiquettes de contrôleur.
RSB, LSB	Abréviations de stick droit et gauche et étiquettes de contrôleur.
START	Bouton Démarrer.
(droite/gauche) stick	Stick du contrôleur. Anciennement baguette.
Bouton stick (droite/gauche)	Bouton stick du contrôleur. Anciennement bouton du bâton.
Déclencheur (droite/gauche)	Déclencheur du contrôleur.
Vibration	Retour de gameplay produit par le moteur de la manette. N’utilisez pas rumble.
X	Bouton X.
O	Bouton Y.
manette Xbox 360 pour Windows	Le boîtier de jeu Xbox 360 vendu en tant que référence SKU matérielle PC, y compris un disque de pilote de périphérique Windows.
manette sans fil Xbox 360 pour Windows	Le boîtier de commande sans fil Xbox 360 vendu en tant que référence SKU matérielle PC, y compris un disque de pilote de périphérique Windows.

Recommandations pour les produits d’intergiciel de jeu

Introduction

Pour que les jeux soient éligibles au programme Jeux pour Windows, ils doivent répondre à une liste de conditions techniques. Tous les composants tiers fournis avec un titre (fichiers exécutables, DLL, pilotes, etc.) doivent également répondre à ces exigences pour que le jeu soit éligible. Ce document met en évidence les exigences les plus courantes qui doivent également être remplies par les composants tiers pour que le jeu réussisse les tests de conformité. Les programmes d’installation et les packages complets de moteur de jeu/de production doivent consulter le document complet sur les exigences techniques des jeux pour Windows, car la plupart de ces exigences sont affectées par ces outils.

Autres recommandations

En plus de vous assurer que votre composant prend en charge la création de titres conformes à la configuration requise pour Jeux pour Windows, vous devez prendre en compte un certain nombre d’autres considérations lors de la conception et du déploiement d’une bibliothèque ou d’un utilitaire de prise en charge d’un jeu Windows.

Pour prendre en charge les développeurs travaillant sur des applications x64 natives 64 bits, fournissez des versions natives 32 bits et 64 bits de vos bibliothèques. La version 32 bits doit être compatible 64 bits par version 2.2. Les bibliothèques pour les applications 32 bits ne doivent pas supposer que le bit élevé d’une adresse 32 bits n’est pas utilisé afin de prendre en charge l’utilisation dans les applications LARGEADDRESSAWARE x86.
Si vous fournissez des en-têtes de code natif (C/C++), utilisez la syntaxe d’attribut SAL (Standard Annotation Language) pour décorer vos routines d’API publiques. Cela permettra aux utilisateurs de votre bibliothèque de tirer le meilleur parti de l’utilisation de l’analyse du code statique (/analyse), 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 compilateur du Kit de développement logiciel (SDK) Windows disponibles publiquement.
Si votre produit crée des threads dans le processus de l’utilisateur, veillez à nommer chaque thread afin que les outils de débogage puissent correctement annoter 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 pour faciliter l’identification des goulots d’étranglement à l’aide de PIX pour Windows.

Notes

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 réseau, fournissez des implémentations ip neutres et évitez les routines IPv4 dépréciées uniquement 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’inscrire auprès de l’Explorateur de jeux à l’aide de la version 2 du schéma GDF et utiliser la fonctionnalité RSS pour fournir des actualités liées au service.

Jeux pour Windows Showcases

Introduction

Les présentations de Jeux pour Windows vont bien au-delà de la fourniture d’une expérience de jeu solide sur les PC Windows. En implémentant ces fonctionnalités, les jeux peuvent ajouter plus d’enthousiasme à l’expérience utilisateur sur les dernières plateformes Windows.

Les jeux pour les titres Windows doivent répondre à toutes les exigences techniques répertoriées dans cet article, mais les fonctionnalités de présentation sont facultatives. Ces titres sont libres d’implémenter certaines, aucune ou toutes ces vitrines.

S.1 Exploit Direct3D 11

Exigence

Direct3D 11 est l’API de rendu 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 attrayante sur le 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 fidélité graphique pour Direct3D 11. Cette prise en charge est soumise à la spécification technique 1.7 des jeux pour Windows.

La technologie Direct3D 10level9 peut être utilisée pour prendre en charge le matériel vidéo direct 2.0/3.0 Direct3D 9 sur Windows Vista et Windows 7, plutôt que d’utiliser une implémentation côte à côte de Direct3D 9 pour une prise en charge matérielle étendue. Toutefois, cela n’est pas suffisant pour illustrer cette démonstration.

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

Justification

L’API Direct3D 11 s’appuie sur le modèle WDDM (Windows Display Driver Model) et l’infrastructure Direct3D 10.1 pour prendre en charge de nouvelles fonctionnalités : mise en place du matériel, nuanceurs de calcul, rendu multithread et création de ressources, nouveaux formats de compression de texture et un langage de nuanceur plus flexible. Direct3D 11 offre une prise en charge unifiée du matériel pour les cartes vidéo modernes, y compris les composants Direct3D 11 de dernière génération, toutes les cartes vidéo Direct3D 10 et 10.1 et de nombreuses cartes vidéo Shader Model 2.0/3.0 Direct3D 9, qui est le matériel vidéo minimal requis pour le bureau Aero 3D.

Informations supplémentaires

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

Éliminez toutes les opérations à fonction fixe au profit des nuanceurs programmables.
Mettez à jour tous les nuanceurs existants vers la nouvelle syntaxe du modèle de nuanceur 4.x/5.
Mettez à jour la gestion des ressources pour prendre en charge le nouveau modèle d’affichage.
Convertissez toutes les ressources pour utiliser une nouvelle liste de formats disponibles.
Mettez à jour la gestion de l’état du rendu pour utiliser des blocs d’état immuables et retravailler les constantes du nuanceur en tampons constants.

Cette conversion est essentielle pour activer la présentation Direct3D 11, bien que le résultat ne réponde pas à l’exigence de la présentation de l’exploitation de la nouvelle API.

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

Tirer parti des fonctionnalités matérielles Existantes de Direct3D 10, telles que Geometry Shader, Stream Out, les tableaux de textures et les formats de texture compressé BC4/BC5.
Tirer parti des fonctionnalités matérielles de Direct3D 10.1 existantes, telles que les modes de fusion indépendants par rendu et cible, la lecture en profondeur MSAA, l’accès au nuanceur MSAA par exemple, les tableaux de mappage de cube et le rendu aux formats compressés par blocs (BC).
Implémentation d’algorithmes GPU avancés à l’aide du nuanceur de calcul avec CS4.x sur les cartes vidéo Direct3D 10/10.1 existantes (activées par les pilotes vidéo mis à jour) ou CS 5.0 sur les cartes vidéo Direct3D 11 de nouvelle génération.
Rendu sur plusieurs threads à l’aide de la création de ressources avec threads libres et de plusieurs contextes d’appareil pour améliorer les performances sur les systèmes multicœurs (avec des pilotes vidéo mis à jour). Pour plus d’informations, consultez Jeux pour Windows Showcase S.3.
Utilisant les nouvelles fonctionnalités du matériel vidéo Direct3D de 11 classes, telles que le pavage de matériel avec des nuanceurs de coque et de domaine, le matériel de nuanceur HLSL Modèle 5.0 offre des formats de texture compressés BC6HBC7 et dynamic shader Linkage.

Les techniques qui peuvent être implémentées avec Direct3D 9 (principalement par le biais d’un coût processeur élevé) peuvent être déchargées sur le GPU de manière efficace, libérant ainsi des ressources processeur pour prendre en charge d’autres demandes de jeu.

Les API Direct3D 11, les outils de prise en charge et les exemples sont disponibles dans le Kit de développement logiciel (SDK) DirectX. Consultez également API graphiques dans Windows.

S.2 Exploit x64 Native

Exigence

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

Sur les éditions 64 bits de Windows, l’installation doit toujours configurer la version native 64 bits du jeu en tant que raccourcis par défaut dans l’Explorateur de jeux et Windows XP Professionnel Édition x64. Si une installation double est souhaitée, une tâche de lecture supplémentaire peut être spécifiée pour l’Explorateur de jeux sur Windows Vista et Windows 7 qui pointe vers la version 32 bits, mais la valeur par défaut doit rester la version native 64 bits.

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

Justification

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

Windows XP Professionnel Édition x64 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’activation du système d’exploitation pour l’informatique grand public 64 bits. Avec 2 Go de RAM en standard sur de nombreux nouveaux ordinateurs, d’autres améliorations de la mise à l’échelle de la mémoire ne profiteront pas aux applications individuelles 32 bits qui ne peuvent pas traiter plus de 2 Go de RAM physique. De nombreux jeux d’aujourd’hui sont confrontés à des difficultés à adapter tout le contenu disponible aux contraintes de 2 Go d’espace d’adressage virtuel, en particulier lorsqu’ils sont combinés avec les grandes mémoires vidéo disponibles sur les GPU haut de gamme, et le passage à la technologie x64 augmente considérablement les niveaux de détail supportables.

La compatibilité x64 pour les jeux 32 bits est une exigence technique de Jeux pour 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 possibilité d’accéder directement à plus de 2 Go de mémoire physique et virtuelle. L’espace d’adressage de mémoire virtuelle volumineux permet une utilisation intensive des E/S mappées en mémoire sans se soucier des problèmes d’épuisement de l’espace d’adressage de machine virtuelle répandus 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 du contenu.

Les applications 32 bits existantes peuvent tirer parti des éditions x64 en ayant la possibilité de traiter des adresses avec des données 32 bits complètes lorsqu’elles sont générées avec l’option d’éditeur de liens Activer les grandes adresses (/LARGEADDRESSAWARE). Sur les versions 32 bits de Windows XP, les modes de démarrage spéciaux permettaient à ces applications de traiter jusqu’à 3 Go de RAM, et les éditions x64 fournissent un accès jusqu’à 4 Go de RAM pour les applications LAA (Large Address Aware). Bien que l’utilisation de LAA dans une application 32 bits ne réponde pas à cette exigence de démonstration, cette technologie de pont 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 n’implémentent pas entièrement cette exigence de démonstration.

Pour plus d’informations, consultez Programmation 64 bits pour les développeurs de jeux et LA RAM, VRAM et Plus de RAM : le jeu 64 bits est ici sur le site web game developer.

Notes

L’un des principaux défis de cette présentation est de s’assurer que toutes les bibliothèques ou composants tiers sur lesquels repose votre jeu sont disponibles pour le développement natif 64 bits. De nombreuses API Microsoft héritées ont également été supprimées de l’environnement natif 64 bits, ce qui peut constituer un défi pour les bases de code de moteur contenant des implémentations plus anciennes de systèmes clés.

S.3 Exploit Many-Core Processeurs

Exigence

Le jeu implémente des fonctionnalités qui tirent parti des processeurs multicœurs, avec une mise à l’échelle vers 3, 4 cœurs ou plus, le cas échéant.

Si le jeu prend en charge les systèmes monoprocesseur ou double cœur, une comparaison côte à côte avec un système à quatre cœurs doit démontrer de nouvelles fonctionnalités perceptibles, d’autres effets convaincants, une amélioration de la qualité du contenu et/ou une amélioration des performances.

Étant donné que la mise à l’échelle double cœur est déjà largement prise en charge par les jeux, et qu’elle est automatiquement utilisée par diverses améliorations du pilote Direct3D, la mise à l’échelle double cœur n’est pas suffisante pour illustrer cette démonstration.

Justification

La croissance continue des performances des processeurs est passée de l’amélioration de la fréquence d’horloge à l’ajout de cœurs de calcul. Les feuilles de route AMD et Intel sont basées sur des conceptions multicœurs évolutives. Toutes les plateformes de jeux de nouvelle génération ont des processeurs multicœurs en raison de ce changement fondamental dans l’évolution des processeurs. Les applications monothread ne verront plus de gains significatifs des processeurs de nouvelle génération. Le multithreading simple échoue également à la mise à l’échelle, car le nombre de cœurs d’UC utilisés en commun passe à trois ou plus.

Informations supplémentaires

Notez que le nombre de cœurs n’a pas besoin d’être une puissance de deux. Les jeux doivent donc être mis à l’échelle de façon linéaire et gérer le nombre de cœurs de 3, 4, 5, 6, 7, 8, etc.

La mise à l’échelle en augmentant le nombre de threads dans une application n’offre un retour que si le coût de la communication et de la synchronisation des threads est vérifié. La mise à l’échelle basée sur les fonctionnalités peut s’avérer une solution plus facile à court terme, ce qui permet au jeu de fonctionner normalement sans les threads supplémentaires sur les systèmes monocœurs et de les activer lorsque la puissance processeur supplémentaire est disponible.

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

L’utilisation de la création de ressources à thread libre Direct3D 11 et des contextes d’appareil est utile pour obtenir une scalabilité à plusieurs cœurs dans le rendu et le chargement des ressources graphiques. Consultez Jeux pour Windows Showcase S.1.

Notez que l’utilisation directe de l’instruction d’uc rdtsc, au lieu d’utiliser des API Windows pour calculer le minutage sur des systèmes multicœurs, peut entraîner des problèmes sur certaines configurations matérielles et de système d’exploitation ; consultez Minutage des jeux et processeurs multicœurs dans les articles DirectX.

S.4 Support Games for Windows - LIVE

Jeux pour Windows - LIVE n’est plus pris en charge par Microsoft.

S.5 Prise en charge de Windows Touch

Exigence

Les jeux tactiles Windows sont jouables à l’aide des interactions tactiles et/ou des mouvements sur les ordinateurs exécutant Windows 7 avec un écran tactile. L’entrée au clavier peut également être utilisée, mais l’interface de lecture principale doit être tactile.

L’activation de l’interaction tactile ne doit pas empêcher l’utilisation de la souris ou du contrôleur commun, sous réserve de la condition technique 1.4.

Le programme d’installation du jeu n’est pas censé prendre en charge les fonctionnalités Windows Touch.

Justification

Les écrans multi-tactiles pour ordinateurs sont disponibles pour les ordinateurs portables et les ordinateurs de bureau, et ils représentent une fonctionnalité matérielle clé promue avec la publication de Windows 7. Windows 7 prend en charge Windows Touch dans l’ensemble des interfaces de bureau et de contrôles courants.

Informations supplémentaires

Les applications en code natif peuvent accéder à plusieurs interactions tactiles via les messages WM_TOUCH, en combinaison avec la fonction RegisterTouchWindow . Consultez également l’API Manipulations et inertie.

Windows Presentation Foundation (WPF) 4.0 fournit une solution managée pour les interfaces multi-touch.

Pour plus d’informations, consultez le Kit de développement logiciel (SDK) Windows Touch.

S.6 Prise en charge des couleurs élevées

Exigence

Les jeux qui prennent en charge les couleurs élevées utilisent un format 10:10:10:2 (DXGI_FORMAT_R10G10B10A2, D3DFMT_A2B10G10R10) ou 16:16:16:16 (DXGI_FORMAT_R16G16B16A16, D3DFMT_A16B16G16R16) pour le rendu de la mémoire tampon et du mode d’affichage plein écran.

À l’aide d’une cible de rendu haute couleur, le contenu HDR (Plage de High-Dynamic) peut être rendu avec une gamme étendue ou étendue lors de l’exécution d’un mappage de tonalités vers une plage de 10 bits ou 16 bits.

Justification

Les moniteurs ont été capables d’afficher plus de 256 niveaux de couleurs par canal depuis de nombreuses années, même lorsque les affichages CRT étaient répandus. L’analyse du matériel sur les cartes vidéo a été le facteur de limitation. Les GPU modernes, y compris la plupart du matériel Direct3D à 9 classes et tout le matériel Direct3D à 10 classes et de meilleure qualité, disposent d’un matériel d’analyse capable d’au moins 10 bits par canal, et la capacité matérielle est configurée pour atteindre 16 bits par canal couleur à l’avenir. Les systèmes d’interconnexion tv HD (HDMI, DisplayPort) ont été conçus pour gérer plus de 8 bits par canal, et vga analogique transportera déjà ces signaux.

Informations supplémentaires

Notez que couleur haute, ou couleur Haute, fait historiquement référence au passage d’affichages de couleur 256 (8 bits) à des affichages couleur 15 ou 16 bits. La plupart des systèmes d’affichage sont depuis longtemps passés à La couleur vraie, qui est une couleur 24 bits, ou 8 bits par canal de couleur pour le rouge, le vert et le bleu. Par Couleur élevée, nous entendons ici une nouvelle génération de systèmes d’affichage qui peuvent fonctionner avec plus de 8 bits par canal de couleur individuel. Est également appelé Couleur profonde.

Meilleures pratiques recommandées

Introduction

En plus de répondre aux exigences techniques et d’adopter une ou plusieurs vitrines dans votre titre, il existe un certain nombre de bonnes pratiques qui doivent être suivies pour tous les jeux Windows. Bien que ces recommandations ne soient pas comprises dans le cadre des exigences techniques de base, nous vous encourageons vivement à les utiliser pour tous les jeux pour Windows.

Autres recommandations

Utilisez le compilateur et le runtime Visual Studio les plus récents. 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 du processeur modernes. La mise à jour du compilateur et l’utilisation du dernier runtime C sont un moyen simple de migrer vers des pratiques de codage modernes.
Utilisez la version de bibliothèque de liens dynamiques (DLL) du runtime C, plutôt que la liaison statique, et utilisez Secure CRT. (Des exceptions peuvent être effectuées dans des cas de préinstallation spéciaux, comme pour un programme d’exécution automatique ou pour le programme d’installation lui-même).
Pour l’audio du jeu, utilisez XAudio2, X3DAudio et/ou XACT, plutôt que DirectSound. Pour les moteurs audio qui effectuent toutes les conversions de mixage et de taux de source et qui n’ont besoin que d’une solution à faible latence pour la sortie audio, utilisez DirectSound sur Windows XP (uniquement) et WASAPI sur Windows Vista et Windows 7.
Évitez d’utiliser des API héritées et déconseillées : DirectDraw, DirectSound, DirectPlay, la couche de performances de DirectMusic, DirectPlay Voice et le mode conservé Direct3D. Notez que DirectPlay Voice et le mode conservé Direct3D ne sont pas du tout disponibles sur Windows Vista ou Windows 7. DirectPlay et la couche de performances de DirectMusic ne sont pas disponibles pour les applications natives x64.
Optimisez à l’aide des jeux d’instructions SIMD SSE/SSE2. Consultez l’API DirectXMath dans le Kit de développement logiciel (SDK) Windows en tant que solution multiplateforme pour les opérations mathématiques optimisées pour SIMD.
Utilisez les meilleures pratiques modernes pour la sécurité Windows (y compris les options du compilateur et de l’éditeur de liens comme /NXCOMPAT, /GS, /SAFESEH, /DYNAMICBASE, /SDL, etc.). Pour plus d’informations, consultez Meilleures pratiques de sécurité dans le développement de jeux.
Utilisez les derniers composants et bibliothèques du SDK Windows. Supprimez les dépendances sur les composants directSetup hérités déployés hors bande, tels que D3DX9, D3DX10 et D3DX11. Envisagez d’utiliser DirectXTex ou DirectXTK ou les deux.
Évitez d’utiliser l’ancien compilateur HLSL et utilisez plutôt le compilateur HLSL moderne. Si la prise en charge de Pixel Shader 1.x est requise par votre application, utilisez l’assembly de nuanceur plutôt que HLSL, ou limitez l’utilisation de l’ancien compilateur à ces scénarios.

Ressources

Terme	Description
Jeux pour Windows : Cas de test	Meilleures pratiques pour les jeux sur Windows XP, Windows Vista et Windows 7
Kit de développement logiciel (SDK) Windows	Kits SDK Windows
Instructions relatives au contrôle de compte d’utilisateur	Configuration requise pour le développement d’applications Windows Vista pour la compatibilité du contrôle de compte d’utilisateur
Portail des développeurs DirectX	Centre de développement Directx
Blog sur les jeux pour Windows et le Kit de développement logiciel (SDK) DirectX	Jeux pour Windows et kit de développement logiciel (SDK) DirectX
Articles DirectX supplémentaires	Articles techniques DirectX

Partager via

Exigences techniques relatives aux jeux pour Windows : meilleures 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 de l’Explorateur de jeux

1.2 Prendre en charge la sécurité familiale et le contrôle parental

1.3 Prendre en charge les jeux enregistrés riches

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

1.5 Prise en charge de plusieurs proportions et résolutions

1.6 Lancement de la prise en charge à partir de Windows Media Center

1.7 Prise en charge de Direct3D

1.8 Activer la prise en charge des ppp élevés

Sécurité et compatibilité

2.1 Suivre les instructions de contrôle de compte d’utilisateur

2.2 Prise en charge des versions Windows x64

2.3 Fichiers de signature

2.4 Sign Drivers

2.5 Effectuer une vérification de version appropriée

2.6 Prise en charge des sessions utilisateur simultanées

2.7 Prendre en charge les noms longs

Installation

3.1 Prise en charge installation facile

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

3.3 Installer sur les dossiers corrects

3.4 Installer correctement les ressources Windows

3.5 Éviter les redémarrages pendant l’installation

3.6 Utiliser correctement le contrôle de version des fichiers

3.7 Prise en charge de l’exécution automatique [Condition requise]

Fiabilité

4.1 Éliminer les redémarrages inutiles

4.2 Éliminer les échecs du vérificateur d’application

4.3 Prise en charge des informations de Rapport d'erreurs Windows et de version de fichier

Terminologie de la manette commune Xbox 360 pour Windows

Recommandations pour les produits d’intergiciel de jeu

Introduction

Autres recommandations

Jeux pour Windows Showcases

Introduction

S.1 Exploit Direct3D 11

S.2 Exploit x64 Native

S.3 Exploit Many-Core Processeurs

S.4 Support Games for Windows - LIVE

S.5 Prise en charge de Windows Touch

S.6 Prise en charge des couleurs élevées

Meilleures pratiques recommandées

Introduction

Autres recommandations

Ressources

Commentaires

Commentaires

Ressources supplémentaires