Juegos para Windows Requisitos técnicos: Procedimientos recomendados para juegos en Windows XP, Windows Vista, Windows 7 y Windows 8

  • Artículo
  • Tiempo de lectura: 64 minutos

En este artículo se proporcionan requisitos técnicos y procedimientos recomendados para juegos que se ejecutan en Windows. Hemos escrito estos requisitos técnicos y procedimientos recomendados principalmente para cubrir Windows Vista y Windows 7, así como el sistema operativo Windows XP heredado. Estos procedimientos recomendados también se aplican generalmente a los juegos win32 de escritorio en Windows 8.

Estos artículos contienen estas secciones:

Diferencias de Windows 8

Este es un resumen de las diferencias clave al aplicar estos requisitos técnicos y procedimientos recomendados para Windows 8.

La interfaz de usuario del Explorador de juegos no está visible

Todos los juegos que registras con el Explorador de juegos se muestran como iconos en la nueva interfaz de usuario de Windows, pero gran parte de los metadatos asociados al título ya no son visibles. Sigues usando la herramienta Games Definition File Maker (GDFMAKER.EXE), que ahora está disponible en el kit de desarrollo de software (SDK) de Windows para crear los metadatos. También se usan los mecanismos existentes para implementar los metadatos. Sigue probando el registro de Games Explorer con Windows 7 y comprueba que el nuevo icono de interfaz de usuario de Windows aparezca al instalarlo en Windows 8 (consulta 1.1 Games Explorer Integration).

Para descargar el SDK de Windows 8, consulte Descargas para desarrollar aplicaciones de escritorio.

El registro con las API de Game Explorer sigue siendo el mecanismo para registrar el juego con Windows controles parentales

Se recomienda ejecutar la versión del SDK de Windows de GDFMAKER en la versión publicada de Windows 8 para asegurarse de que puede rellenar todos los sistemas de clasificación admitidos actualmente.

Nota

Esta versión de GDFMAKER requiere .NET 4.0.

Véase 1.2 Apoyar la seguridad familiar / Controles parentales.

Ahora hay tres opciones para usar la API XINPUT en función de sus requisitos

XINPUT 1.4 está integrado en Windows 8. Tanto las aplicaciones de la Tienda Windows como las aplicaciones win32 de escritorio pueden usar XINPUT 1.4. Todas las versiones de Windows pueden usar XINPUT 9.1.0 para controladores comunes simplificados, pero no hay ningún paquete de redistribución con XINPUT 9.1.0. Todas las versiones de Windows también pueden usar la versión existente del SDK de DirectX XINPUT 1.3, que requiere que DirectSetup se implemente.

Consulta 1.4 Compatibilidad con el controlador común de Xbox 360 para Windows.

Solo se admite un conjunto limitado de aplicaciones Win32 de escritorio en Windows RT

Los juegos que se ejecutan en Windows 7 pueden y deben ejecutarse correctamente en Windows 8 plataformas x86 y x64.

Consulte compatibilidad con la versión 2.2 Windows versiones x64.

Asegúrese de que las comprobaciones del sistema operativo se realizan correctamente.

La versión del sistema operativo Windows 8 es 6.2. Windows 8 supera las pruebas de barras mínimas actuales que recomendamos para la implementación de juegos.

El paquete de redistribución de DirectX End-User se ejecuta correctamente en Windows 8, como lo hace en Windows 7, para implementar D3DX9, D3DX10, D3DX11, XINPUT 1.3, XAUDIO 2.7, XACTEngine, etc.

Pero existe un problema conocido con DirectSetup en sistemas con solo .NET 4.0 instalado debido al control de implementación de los ensamblados de DirectX 1.1 administrados heredados. Este problema se aplica a ambos Windows 8, que viene con .NET 4.5 de forma predeterminada, y a equipos Windows XP nuevos con el entorno de ejecución de .NET 4.0 instalado. Pero este problema no se aplica a ninguna versión de .NET anterior a .NET 4.0. Aunque Windows 8 tiene un comportamiento de compatibilidad de aplicaciones para resolver este problema automáticamente (lo que requiere acceso a la red), se recomienda que los juegos que sigan implementando la actualización de DirectSetup en la versión actualizada del SDK de DirectX (junio de 2010) de los archivos REDIST. Como siempre, si usa DirectSetup para el título, recorte el título hasta el conjunto mínimo necesario de CAB.

Consulte 3.4 Instalación de recursos de Windows correctamente.

Los juegos que requieren el entorno de ejecución compatible con .NET 2.0 (2.0, 3.0, 3.5) siguen usando los mecanismos de implementación existentes.

Estos juegos desencadenan un comportamiento de compatibilidad de aplicaciones en Windows 8 para habilitar el entorno de ejecución de .NET 3.5 automáticamente (lo que requiere acceso a la red). Sin embargo, se recomienda que los desarrolladores de .NET pasen al entorno de ejecución de .NET 4.0.

Nota

Los ensamblados de DirectX 1.1 administrados heredados no son compatibles con el entorno de ejecución de .NET 4.x.

Consulte 3.4 Instalación de recursos de Windows correctamente.

No se recomienda el uso de un autorrunner u otra tecnología de preins instalación que se base en .NET.

Puede suponer que solo los entornos de ejecución compatibles con .NET 2.0 (2.0, 3.0, 3.5) están presentes en Windows Vista y Windows 7. Solo el entorno de ejecución compatible con .NET 4.0 está presente en Windows 8 de forma predeterminada.

Consulte 3.7 Compatibilidad automática.

Hay un comprobador de aplicaciones actualizado para Windows 8

El SDK de Windows 8 incluye este comprobador de aplicaciones actualizado.

Consulte 4.2 Eliminar errores del comprobador de aplicaciones.

Información adicional

guía de Windows 8 y compatibilidad de Windows Server 2012
¿Dónde está el SDK de DirectX?

Juegos para Windows

Resumen de los requisitos de los juegos

Ventajas del cliente

Los juegos de ordenador son una experiencia de entretenimiento clave en Windows, pero los problemas de facilidad de uso han causado frustración del cliente a lo largo de los años. Tradicionalmente, los juegos se instalan como aplicaciones, pero se usan más como medios de entretenimiento (películas o canciones, por ejemplo). Las innovaciones, como Games Explorer, exponen juegos de una manera coherente que es diferente de las aplicaciones estándar. Estas innovaciones también dan a los juegos de primer nivel de estado ciudadano en Windows, junto con Música e Imágenes. Los siguientes requisitos ayudan a garantizar que Windows Vista y Windows 7 proporcionan una experiencia de juego mejorada, más accesible y unificada. Al mismo tiempo, garantizan la compatibilidad con Windows XP.

1.1 Integración del Explorador de juegos

Requisito

El juego debe estar visible en el Explorador de juegos (la carpeta Juegos) en Windows Vista y Windows 7. Cuando se selecciona, el juego también debe mostrar los metadatos correctos, que incluyen los metadatos publicadores, desarrolladores, fecha de lanzamiento, versión, Windows puntuaciones de Índice de experiencia, clasificación (si procede) y hipervínculos asociados.

Si el juego se distribuye digitalmente a través de un servicio de juego en línea, el proveedor de servicios también debería aparecer en el Explorador de juegos. Para garantizar el control adecuado del proveedor y habilitar el uso de fuentes RSS, se debe usar la versión 2 del esquema para los archivos de definición de juego (GDF). (Para obtener más información sobre los GDF, vea Información adicional).

Además, los instaladores de juegos deben cumplir las siguientes reglas cuando se ejecutan en Windows Vista y Windows 7:

  • La instalación no debe crear un acceso directo para iniciar el juego en el escritorio, en el menú Inicio o en cualquier otra ubicación.
  • No se deben crear tareas ni accesos directos para la eliminación.
  • Los usuarios deben poder quitar el juego usando programas y características en Panel de control en Windows Vista y Windows 7, o agregar o quitar programas en Panel de control en Windows XP.

En Windows XP, y en versiones anteriores de Windows, el instalador del juego es gratuito para crear grupos de programas, iconos de escritorio o accesos directos según sea necesario.

Fundamento

Windows Games Explorer es similar en concepto a las carpetas Windows XP Mis documentos o Mis imágenes. La idea es centralizar contenido similar en un solo lugar y permitir actividades más fáciles de organización y contextuales. El Explorador de juegos amplía el concepto Mis documentos o Mis imágenes al permitir una organización más enriquecida y controlar los juegos. El Explorador de juegos permite a los jugadores ver, organizar e interactuar con todos los juegos instalados en sus sistemas. También permite a los editores de juegos comunicar información importante del juego de forma más eficaz. El sistema está controlado por datos, lo que facilita que un editor de juegos actualice la información del juego durante la vida útil del producto.

Información adicional

La integración con Games Explorer requiere que cree un archivo de definición de juego (GDF), que es un archivo de texto XML incrustado en un archivo binario (un archivo ejecutable o un archivo DLL) como un recurso, junto con un icono de Windows. A continuación, el juego debe registrarse con el Explorador de juegos. La GDF también permite la exposición de información proporcionada, como el título del juego, el publicador, el desarrollador, los vínculos a sitios web y tareas opcionales. Tenga en cuenta que las tareas de soporte técnico solo pueden ser vínculos a sitios web, pero también se pueden usar tareas de reproducción para tareas de soporte técnico opcionales.

El Explorador de juegos puede usar una imagen de mapa de bits en miniatura, pero se recomienda que, en su lugar, proporcione un recurso de icono de Windows con iconos grandes (256 256). El recurso de icono debe incluir tamaños de imagen de 256 256 48 48, 32 32 y 16 16 en profundidades de color de 24 bits (color verdadero) y de 8 bits (256). El editor de iconos proporcionado en Visual Studio 2008 y 2010 admite estos formatos de iconos grandes, como lo hace IconWorkshop Lite.

En el SDK de DirectX se proporcionan detalles sobre la integración con Windows Games Explorer. El SDK de DirectX incluye un editor de archivos de definición de juegos (GDF), así como un ejemplo de GDF que se incluye en GDFExampleBinary, un ejemplo. Otro ejemplo, GameUxInstallHelper, proporciona rutinas para integrar la funcionalidad necesaria en los sistemas de instalación existentes. El validador de archivos de definición de juegos (gdftrace.exe) proporciona compatibilidad de depuración para evaluar una GDF. Consulte también "Windows Games Explorer Integration" en la documentación del SDK de DirectX para C++.

Windows 7 presenta compatibilidad con la segunda versión de un esquema para archivos GDF. La nueva versión incluye un método simplificado para crear tareas de juego y compatibilidad con notificaciones de actualización, proveedores de servicios de juegos, estadísticas de juegos y fuentes RSS para proveedores de servicios de juegos. La versión más reciente de GameUxInstallHelper controla todo el registro y la compatibilidad heredada necesaria para usar un archivo GDF de versión 2 con Windows Vista. Use las herramientas y el código de ejemplo del SDK de DirectX desde agosto de 2009 o posterior. Se recomienda usar un archivo GDF de la versión 2 para habilitar la compatibilidad con fuentes RSS, estadísticas de juegos y notificaciones de actualización. Consulte también los ejemplos ProviderGDFExampleBinary y GameStatisticsExample.

En Windows Vista Business Edition, Windows 7 Professional Edition y Enterprise Edition de Windows Vista y Windows 7, el vínculo Juegos de la menú Inicio está oculto. El Explorador de juegos sigue estando disponible en el menú Inicio haciendo clic en Todos los programas y, a continuación, en Juegos.

Para las aplicaciones asociadas que se instalan con tu juego, pero no con ellos mismos, puedes crear menú Inicio grupos de programas, accesos directos e iconos de escritorio en todas las versiones de Windows, incluidos Windows Vista y Windows 7. Estas aplicaciones asociadas deben pasar juegos aplicables para Windows requisitos; para obtener más información, consulta Directrices para productos de middleware de juegos. Se recomienda que los servicios de juegos se registren con games Explorer como proveedor de juegos para Windows 7. 1

1.2 Apoyar la seguridad familiar / Controles parentales

Requisito

Los juegos deben ser totalmente compatibles con Windows Seguridad Familiar al cumplir con las siguientes reglas:

  • Los juegos no deben requerir que el usuario tenga credenciales administrativas para jugar. La instalación, la aplicación de revisiones y la eliminación pueden requerir credenciales administrativas, según los requisitos de la sección 3. (Relacionado con este es el requisito 2.1, Siga las directrices de control de cuentas de usuario).
  • Los juegos clasificados por Windows paneles de clasificación admitidos, como ESRB y PEGI, deben incluir su información de clasificaciones asignadas en su archivo de definición de juego (GDF). Todos los datos de clasificaciones disponibles deben incluirse en cada versión localizada de la GDF, así como en la versión neutra del idioma.
  • Los juegos deben enumerar sus archivos ejecutables en la GDF para proporcionar una buena experiencia de usuario para restricciones generales de aplicaciones, a menos que el juego use una tecnología contra la piratería que crea ejecutables con nombre aleatorio en tiempo de ejecución.
  • Los juegos deben llamar al método VerifyAccess de la interfaz del Explorador de juegos durante el inicio, si está disponible, y salir si devuelve *pfHasAccess como FALSE.

Fundamento

Todos los juegos deben ejecutarse en el contexto de una cuenta de usuario estándar para permitir que las cuentas controladas por Windows controles parentales jueguen al juego. Los padres quieren la capacidad de supervisar y controlar el acceso de sus hijos a los juegos. Además, numerosas industrias, grupos gubernamentales y de promoción desean mejores formas de permitir a los padres supervisar y controlar los juegos a los que se exponen sus hijos. Junto con la arquitectura que ofrece el Explorador de Juegos, Microsoft proporciona a los padres esta capacidad a través de Windows controles parentales.

Incluso para juegos que no participan en un programa de tablero de clasificaciones, requerir privilegios elevados crea una experiencia de juego deficiente para la mayoría de las cuentas de usuario. Este es especialmente el caso si los controles parentales están habilitados, lo que requeriría que el padre escriba la contraseña de administrador cada vez que se inicie el juego.

El sistema de controles parentales Windows permite a los padres seleccionar las clasificaciones que creen que son adecuadas para sus hijos. Los controles parentales admiten muchos de los sistemas de clasificación mundial. Los controles parentales también permiten a los padres restringir el acceso a juegos basados en descriptores de contenido (si el sistema de clasificación aplicable los admite) y permitir o no permitir el acceso a juegos individuales.

La elección predeterminada del sistema de clasificación para Windows Controles parentales se basa en la configuración regional del sistema, pero el usuario puede modificarlo en Las opciones regionales y de idioma en Panel de control. Por lo tanto, todos los idiomas admitidos deben proporcionar todos los datos de clasificaciones disponibles para que el usuario tenga la libertad de seleccionar cualquier panel de clasificaciones que desee.

Información adicional

Los juegos sin una clasificación deben cumplir los requisitos para admitir el juego como usuario estándar y llamar a VerifyAccess. Estos juegos tienen como valor predeterminado la categoría Unrate, muestran el texto "Sin clasificación proporcionada" en el Explorador de juegos, y están sujetos a la configuración Restricciones de juego en Controles parentales para juegos no clasificados. La configuración de restricciones predeterminada es Permitir.

La información de clasificación en la GDF se omitirá si el binario contenedor no está firmado correctamente Authenticode. Consulte el requisito 2.3.

El Editor de archivos de definición de juegos del SDK de DirectX incluye todos los sistemas de clasificación admitidos y replicará correctamente esta información en todas las versiones localizadas de GDF, así como en una versión neutral del lenguaje. La herramienta GDFTrace descodificará y comprobará toda la información de clasificaciones presente. Use la versión de agosto de 2009 o posterior de estas herramientas.

El GDF para un proveedor de juegos normalmente no contiene información de clasificación y está sujeto a la configuración de contenido no clasificado.

Sistema operativo Sistemas de clasificación admitidos
Windows Vista
  • CERO (Japón)
  • ESRB (EE. UU.)
  • OFLC (Australia)
  • PEGI (Europa)
  • PEGI Finlandia (en desuso)
  • PEGI Portugal
  • PEGI/BBFC (Reino Unido)
  • USK (Alemania)
Windows Vista con un Service Pack Los Service Pack para Windows Vista agregan compatibilidad con lo siguiente:
  • GRB (Corea del Sur)
  • Descriptores de contenido de variante "Mild" de ESRB
Windows 7 Windows 7 admite los sistemas de clasificaciones admitidos por Windows Vista y agrega compatibilidad con lo siguiente:
  • CSRR (Taiwán)
Windows 8 Windows 8 admite los sistemas de clasificaciones anteriores y agrega compatibilidad con lo siguiente:
  • COB-AU (Australia)
  • DJCTQ (Brasil)
  • PFB (Sudáfrica)
  • OFLC-NZ (Nueva Zelanda)
Windows 8 retira la compatibilidad con los siguientes sistemas en desuso:
  • PEGI-FI (Finlandia)
  • OFLC (Australia)

Nota

Cualquier título que incluya nuevos descriptores de contenido de ESRB Windows Vista Service Pack 1 (SP1) se mostrará como Unrated on Windows Vista sin service pack.

Los datos de clasificaciones más recientes se omiten en versiones de sistemas operativos sin compatibilidad con ellos. La variante PEGI (Finlandia) ahora está en desuso en favor del sistema de clasificación estándar PEGI (Europa). El sistema OFLC ahora está en desuso en favor de COB-AU para Australia.

Para obtener más información sobre cómo hacer que un juego sea compatible con privilegios de usuario estándar, consulta el artículo Control de cuentas de usuario de DirectX para desarrolladores de juegos.

Consulta el requisito 1.1 para obtener más detalles sobre el archivo de definición de juego (GDF).

1.3 Compatibilidad con juegos guardados enriquecidos

[Este requisito se ha retirado]

1.4 Admite el controlador común de Xbox 360 para Windows [requisito condicional]

Requisito

Los juegos que admiten controladores del controlador para juegos deben admitir el Mando Xbox 360 para Windows mediante la API XInput. Si también se admiten periféricos de DirectInput, también se puede usar DirectInput. Sin embargo, XInput debe ser la API predeterminada si se usa un dispositivo compatible con Xbox 360.

Todas las referencias a los botones y desencadenadores comunes del controlador deben usar los nombres de Xbox 360. Consulta la lista de terminología de Windows Xbox 360 Para obtener más información, consulta la lista de terminología de Xbox 360.

La vibración del controlador debe desactivarse cuando el juego está en estado en pausa o suspendido.

El control de mouse/teclado no se puede deshabilitar completamente en cualquier momento. Como mínimo, debe haber disponible una opción para volver a los menús del juego.

Fundamento

Este requisito ofrece a los jugadores libertad de elección para usar el mando xbox 360 o el teclado y el mouse, dependiendo del método de entrada que sea más natural e intuitivo.

Información adicional

Este requisito no se aplica a los juegos que usan solo el mouse o el teclado.

Se recomienda implementar la navegación de menús para usar los botones de controlador estándar ampliamente aceptados:

  • A: Aceptar
  • B - Cancelar
  • Inicio: Aceptar o pausar
  • Atrás: cancelar, hacer una copia de seguridad de una pantalla o subir un nivel de menú

Para obtener más información, consulta XInput.

En el tema XInput y DirectInput se describen los problemas relacionados con el uso de ambas API al mismo tiempo.

Se recomienda que DirectInput no se use para implementar controles de teclado o mouse. Los controles de teclado y mouse solo deben implementarse mediante mensajes de Windows y API de Win32. Para más información sobre cómo obtener información sobre el movimiento del mouse de alta resolución sin usar DirectInput, vea Aprovechar High-Definition movimiento del mouse.

1.5 Admite varias relaciones de aspecto y resoluciones

Requisito

El juego debe admitir al menos las siguientes relaciones de aspecto y resoluciones de pantalla asociadas:

  • 4:3 normal (800 600 o 1024 768)
  • Pantalla ancha 16:9 (1280 720)
  • Pantalla ancha 16:10 (1152 720 o 1680 1050 o 800 480)

Para la configuración y detección de la resolución de pantalla, el juego debe cumplir las reglas siguientes:

  • El juego usa la resolución de escritorio del dispositivo de pantalla de forma predeterminada si es una resolución compatible. La relación de aspecto del escritorio debe usarse como criterio de búsqueda si el juego elige una resolución predeterminada diferente.
  • El juego debe pedir al usuario que confirme la nueva configuración de visualización cuando se realice un cambio. Si el usuario no acepta en un plazo de 15 segundos, la pantalla debe revertir a la configuración anterior.
  • El juego no debe estirar píxeles ni centrar una ventana de representación de 4:3 para admitir relaciones de aspecto de pantalla ancha. Sin embargo, la conversión de cuadros de letras es aceptable.

Fundamento

Con el escritorio 3D de Windows, no se puede asumir una relación de aspecto o resolución determinada, debido a los siguientes factores:

  • Compatibilidad con pantallas de alto detalle.
  • Aumento de la cuota de mercado de los monitores de pantalla ancha.
  • Implementaciones de HDTV para Windows Media Center.
  • Requisitos de accesibilidad.

Información adicional

Idealmente, el juego tiene como valor predeterminado la relación de aspecto nativo de la pantalla. Sin embargo, obtener esta información de forma confiable puede ser un desafío, por lo que, como solución más general, el juego puede suponer que el escritorio se ejecuta en la relación de aspecto nativo. La resolución de escritorio se puede obtener llamando a EnumDisplaySettings con ENUM_REGISTRY_SETTINGS.

Para obtener más información, consulta las secciones Relación de aspecto y Pantalla ancha del artículo DirectX Introduction to the 10-Foot Experience for Windows Game Developers.

1.6 Inicio de soporte técnico desde Windows Media Center

[Este requisito se ha retirado.]

Compatibilidad con Direct3D 1.7

Requisito

Si el juego usa Direct3D, la versión mínima admitida debe ser Direct3D 9 y Direct3D debe ser el representador predeterminado seleccionado.

Fundamento

La arquitectura de gráficos Windows Vista y Windows 7 núcleos está diseñada en torno a Direct3D. Direct3D 8 y versiones anteriores son compatibles con la reasignación de interfaces heredadas.

Se recomienda encarecidamente el uso de versiones de Direct3D más recientes que Direct3D 9. Consulta los Juegos para Windows Showcase S.1. Requerir Direct3D 10 o Direct3D 11 es totalmente compatible con el requisito 1.7.

1.8 Habilitación del reconocimiento de valores altos de PPP

Requisito

Los juegos y sus instaladores deben ejecutarse correctamente sin problemas visuales cuando el escalado de puntos por pulgada (PPP) está habilitado (probado con 144 PPP para un escalado del 150 % en resolución de visualización de 1600 1200) en Windows Vista y Windows 7.

Esto normalmente requiere que el ejecutable del juego declare que es compatible con PPP. Esto se logra insertando un elemento de manifiesto: <pppAwaretruedpiAware<>> .

Fundamento

Los monitores LCD de alta calidad son habituales como pantallas de ordenador, y se ven mejor cuando se controlan en sus resoluciones nativas (normalmente 1280 1024, 1600 1200, etc.). Los clientes que tienen dificultades para leer texto y ver imágenes en esta resolución suelen establecer sus equipos de escritorio en una resolución más baja y sufren artefactos visuales del escalado LCD. En su lugar, los clientes pueden dejar la resolución en el tamaño nativo y cambiar el PPP de la pantalla de Windows, lo que hace que el elemento y el texto sean más grandes sin sacrificar la calidad de la imagen.

Aunque esta característica está disponible en algún formato desde Windows XP, rara vez lo habilitan los clientes o los OEM. En la actualidad, más de la mitad de todas las pantallas del equipo se establecen en una resolución inferior a la resolución nativa del monitor, en función de los comentarios de los clientes. Windows 7 hace que esta característica sea mucho más visible para los clientes durante la configuración inicial y al cambiar la configuración de pantalla, lo que les anima a usar el escalado de PPP en lugar de cambiar la resolución de escritorio.

Información adicional

La función SetProcessDPIAware se puede usar en su lugar, si se llama al principio del código de inicio del proceso. Se prefiere agregar al manifiesto para asegurarse de que no haya condiciones de carrera con elementos de software (como archivos DLL) que puedan inicializarse antes de llamar al punto de entrada principal. Tenga en cuenta que SetProcessDPIAware solo está presente en Windows Vista y Windows 7.

Agregar el elemento manifest es fácil de hacer con Visual Studio 2005 y 2008; cree un archivo denominado pppaware.manifest que contenga el texto siguiente:

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

A continuación, dentro de Visual Studio, agregue pppware.manifest al proyecto. Asegúrese de que Insertar manifiesto esté establecido en Sí en las propiedades del proyecto. Tenga en cuenta que las versiones anteriores de la Herramienta de manifiesto (Mt.exe) generarán una advertencia falsa con los elementos de manifiesto compatibles con PPP. Para resolverlo, actualice Mt.exe a la versión más reciente del SDK de Windows.

Visual Studio 2010 incluye una configuración en las propiedades del proyecto, denominada Habilitar reconocimiento de PPP, que elimina la necesidad de un archivo como pppaware.manifest. Busque Habilitar reconocimiento de PPP expandiendo Propiedades de configuración y Herramienta de manifiesto y, a continuación, seleccione Salida de entrada&.

En Windows, el modo de visualización tradicional tiene como valor predeterminado 96 PPP, que era común para los monitores de CRT.

Aunque las aplicaciones de pantalla completa cambian la resolución de pantalla, a menudo usan mensajes de ventana y métricas al configurar búferes y rectángulos de visualización. La virtualización de PPP hace que estos modos de visualización de pantalla completa aparezcan recortados y la declaración de reconocimiento de PPP impedirá estos problemas. Para obtener más información, consulta Escribir DPI-Aware aplicaciones Win32.

Seguridad y compatibilidad

Resumen de los requisitos de seguridad y compatibilidad

Ventajas del cliente

Los siguientes requisitos mejoran la seguridad general de los juegos y ayudan a garantizar que trabajan con Windows en diferentes arquitecturas, bajo diferentes configuraciones y en diferentes modos.

2.1 Seguir las directrices de control de cuentas de usuario

Requisito

Cada archivo ejecutable (es decir, cada archivo que tenga una extensión .exe) debe contener un manifiesto incrustado que defina su nivel de ejecución incluyendo la siguiente etiqueta:

            <requestedExecutionLevel>

Por requisito 1.2, el juego principal y el ejecutable autorun deben tener el nivel de ejecución de asInvoker para admitir contextos de usuario estándar.

Los archivos de datos de usuario que tienen asociaciones de archivos registradas con Explorador de archivos deben colocarse en una subcarpeta de la carpeta especificada por CSIDL_PERSONAL (también denominada Documentos o Mis documentos). Todos los demás archivos de datos de usuario deben almacenarse en una subcarpeta de las carpetas especificadas por CSIDL_LOCAL_APPDATA o CSIDL_COMMON_APPDATA. (Estos directorios están ocultos de forma predeterminada para usuarios individuales y para todos los usuarios).

Fundamento

La experiencia de Windows de un usuario es más segura si las aplicaciones solo se ejecutan con los permisos necesarios.

Información adicional

Si solo algunas características de una aplicación requieren privilegios administrativos (por ejemplo, una aplicación que necesita configurar un firewall), el proceso principal de la aplicación debe seguir ejecutándose mediante privilegios de usuario estándar. Las características que requieren privilegios administrativos deben moverse a un proceso independiente, como un instalador o una utilidad de configuración.

Si no se requieren privilegios administrativos, el XML del manifiesto incrustado debe incluir lo siguiente:

            <?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 se requieren privilegios administrativos, el XML del manifiesto incrustado debe incluir lo siguiente:

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

Con Visual Studio 2005, esto se inserta fácilmente agregando un archivo de manifiesto (.manifest) que contiene uno de los bloques anteriores al proyecto y asegurándose de que Insertar manifiesto esté establecido en Sí en las propiedades del proyecto para la herramienta manifiesto. Para Visual Studio 2008 y 2010, las propiedades de UAC se pueden establecer directamente en las propiedades del proyecto para el enlazador en la página Archivo de manifiesto. Tenga en cuenta que las versiones anteriores de la Herramienta de manifiesto (Mt.exe) generan una advertencia falsa con los elementos del manifiesto UAC. Para resolverlo, actualice Mt.exe a la versión más reciente del SDK de Windows.

Consulte el requisito 3.1 para obtener más información sobre los casos especiales de instalación, aplicación de revisiones y eliminación.

Las bibliotecas de vínculos dinámicos (DLL) no requieren dichos manifiestos.

Para obtener más información sobre el control de cuentas de usuario, consulta Control de cuentas de usuario para desarrolladores de juegos.

2.2 Compatibilidad con Windows versiones x64

Requisito

Para mantener la compatibilidad con las ediciones de 64 bits de Windows, los juegos deben cumplir los siguientes requisitos.

  • Los títulos y los instaladores de título no deben contener ningún código de 16 bits ni confiar en ningún componente de 16 bits.
  • Si el juego depende de los controladores en modo kernel para su funcionamiento, las versiones x64 de estos controladores deben estar disponibles. La configuración del juego debe detectar e instalar los controladores y componentes adecuados para las ediciones de 64 bits de Windows.

Fundamento

Muchos Windows Vista y Windows 7 usuarios ejecutarán ediciones de 64 bits del sistema operativo durante la vida útil del producto, por lo que es fundamental que las aplicaciones sean compatibles con este sistema operativo.

Información adicional

Windows en Windows 64 (WOW64) permite que el código de 32 bits se ejecute en ediciones de 64 bits de Windows, por lo que no es necesario que la aplicación sea código nativo de 64 bits en ediciones de 64 bits de Windows. El código de dieciséis bits no se ejecuta en ediciones de 64 bits de Windows.

No es necesario mantener la compatibilidad con Windows XP Professional x64 Edition, pero se recomienda encarecidamente.

Para obtener más información, consulta programación de 64 bits para desarrolladores de juegos.

2.3 Archivos de firma

Requisito

Todos los archivos de código ejecutable (normalmente, los archivos con la extensión .exe o .dll) deben estar firmados con un certificado Authenticode válido públicamente y deben tener una dirección URL de servidor de marca de tiempo válida para la firma de producción.

Si tu juego usa Windows Instalador, los archivos de paquete del instalador (archivos .msi) deben estar firmados.

Fundamento

La firma de un archivo ayuda a los usuarios a decidir si confiar en una aplicación y garantiza a los usuarios que los archivos no se han alterado. También permite que las aplicaciones se ejecuten correctamente en entornos bloqueados.

Información adicional

Para obtener más información, consulta Authenticode Signing for Game Developers.

Si tu juego usa Windows Instalador, te recomendamos habilitar la aplicación de revisiones UAC/LUA, incluyendo una tabla MsiPatchCertificate. Para obtener más información, consulte Aplicación de revisiones de Control de cuentas de usuario (UAC).

No se recomienda firmar archivos (.cab), a menos que sean relativamente pequeños (menos de 100 MB).

2.4 Firmar controladores

Requisito

Cualquier controlador en modo kernel instalado por el juego debe estar firmado con un certificado Authenticode válido públicamente.

Cualquier controlador de dispositivo de hardware en modo kernel instalado por el juego debe tener una firma de Microsoft, que se puede obtener de los laboratorios de calidad de hardware (WHQL) de Windows o del programa Firma de confiabilidad de controladores (DRS).

Fundamento

Los controladores de malware o mal escritos pueden afectar gravemente a la estabilidad y seguridad de un sistema. En las ediciones de 64 bits de Windows Vista y Windows 7, los controladores sin firmar no se cargan. Esta directiva también se puede habilitar para ediciones de 32 bits de Windows Vista y Windows 7.

Información adicional

Se necesitan versiones nativas de 32 y 64 bits de todos los controladores en modo kernel por requisito 2.2.

Puede encontrar más información sobre los programas de firma de controladores de Microsoft en el portal para desarrolladores de hardware de Windows.

2.5 Realizar la comprobación de versiones adecuada

Requisito

Los juegos no deben no ejecutarse en sistemas operativos futuros, como se indica en los cambios en el número de versión de Windows, a menos que el Contrato de licencia de usuario final prohíbe el uso en sistemas operativos futuros. Si se supone que el juego falla, debe hacerlo correctamente mostrando un mensaje adecuado al usuario.

Si se realizan comprobaciones de versión Windows, se deben usar las API de comprobación de versiones (GetVersionEx o VerifyVersionInfo) para comprobar la versión del sistema operativo. Las claves del Registro no deben leerse para determinar la versión.

Las comprobaciones de versión explícitas del tiempo de ejecución de DirectX no deben estar presentes en el juego. Estas comprobaciones de versión no deben estar presentes en la instalación que inicia la instalación del entorno de ejecución de DirectX (DirectSetup).

Fundamento

Cuando Windows los usuarios actualizan sus sistemas operativos, no deben bloquearse de jugar a los juegos actuales simplemente porque el número de versión de Windows ha aumentado. Los comprobadores de versiones mal escritos siguen creando problemas para el software que, de lo contrario, funciona bien en las versiones más recientes de Windows o simplemente con la adición de un Service Pack de Windows.

La lógica de comparación de comprobación de versiones frágil para el entorno de ejecución de DirectX ha creado numerosas instalaciones con errores cuando se ejecuta en diferentes versiones de Windows. El número de versión de DirectX solo se aplica a los componentes principales del sistema operativo. No se aplica a los componentes del SDK de DirectX en paralelo que usan muchos juegos.

Información adicional

Es bastante común ver que los instaladores comprueban una versión mínima del sistema operativo. Sin embargo, esta comprobación debe realizarse con cuidado para asegurarse de que prueba para mayor o igual que, en lugar de igualdad simple, lo que bloquea una versión específica del sistema operativo. El uso de la prueba HighVersionLie del comprobador de aplicaciones es una manera rápida y sencilla de determinar cómo reaccionará el instalador a un cambio significativo en el número de versión del sistema operativo.

El uso adecuado del paquete de redistribución en tiempo de ejecución de DirectX (instalación de DirectX) implica iniciarlo siempre durante la instalación, preferiblemente en modo silencioso. Esto permite que el código proporcionado por Microsoft realice las actualizaciones de versión necesarias. También permite la instalación de cualquier componente opcional del SDK de DirectX en paralelo, como D3DX, XACT, MDX o XInput.

Para conocer los procedimientos recomendados para implementar el entorno de ejecución de DirectX, consulta Instalación de DirectX para desarrolladores de juegos.

Se recomienda que los juegos que admitan Windows XP comprueben un nivel de Service Pack de 2 o superior, ya que Service Pack 2 (SP2) y Service Pack 3 (SP3) proporcionan mejoras de seguridad significativas, un requisito simplificado de redistribución en tiempo de ejecución de DirectX y una implementación extremadamente amplia. La mayoría de las tecnologías modernas de Microsoft que admiten Windows XP requieren SP2 o SP3 (XAudio2, Juegos para Windows - LIVE, etc.).

2.6 Admite sesiones de usuario simultáneas

Requisito

Los juegos que dependen de gráficos 3D no son necesarios para trabajar a través de una conexión a escritorio remoto, pero el usuario debe recibir alertas cuando se produce un error en el juego.

Los juegos deben admitir escenarios estándar de Windows multitarea mediante la adhesión a las reglas siguientes:

  • Los juegos no deben bloquear el uso de sesiones de usuario simultáneas.
  • Un juego debe ejecutarse en una nueva sesión de usuario cuando ya se está ejecutando en otra sesión.
  • El sonido del juego en una sesión de usuario no debe escucharse cuando otro usuario está activo en una sesión diferente.
  • Los juegos deben admitir el cambio rápido de usuario.
  • Los juegos no deben intentar deshabilitar el cambio de tareas estándar. Los juegos no deben deshabilitar el método abreviado de teclado ALT+TAB. Los juegos pueden deshabilitar los métodos abreviados de teclado de accesibilidad, como se describe en Deshabilitar teclas de método abreviado en juegos.

Fundamento

Windows los usuarios deben poder ejecutar sesiones simultáneas sin conflictos o interrupciones. Se trata de un escenario común para un equipo de Windows compartido por una familia, compañeros de habitación u otros.

Información adicional

Para probar si el juego se inicia en una sesión remota, llama a GetSystemMetrics(SM_REMOTESESSION). Un valor distinto de cero indica que la sesión es remota.

Para obtener más información, consulte Cambio rápido de usuario. Tenga en cuenta que el cambio rápido de usuario se produce si las restricciones de tiempo de los controles parentales están habilitadas cuando el tiempo del usuario está actualizado. Consulte el requisito 1.2 para obtener más detalles.

2.7 Admite nombres largos

Requisito

Si un juego admite guardar archivos, debe poder guardar archivos que tengan nombres y rutas de acceso largos. El juego debe controlar correctamente caracteres especiales del sistema de archivos, como \ / : * ? " <>, en los campos de entrada de usuario que se usan para crear nombres de archivo o rutas de acceso.

Los juegos deben funcionar correctamente cuando un usuario tiene un nombre de usuario largo.

Fundamento

Los jugadores están acostumbrados a usar nombres largos en rutas de acceso profundas compatibles con el sistema operativo subyacente.

Información adicional

Los nombres largos se definen como aquellos que contienen los valores máximos definidos en el SDK de Windows.

Instalación

Resumen de los requisitos de seguridad y compatibilidad

Ventajas del cliente

Los clientes pueden estar seguros de que las aplicaciones se instalarán en Windows sin degradar el sistema operativo u otras aplicaciones si las aplicaciones usan métodos oficiales de distribución de componentes del sistema. Una experiencia de instalación simplificada proporciona una experiencia de instalación más accesible y sin problemas para juegos.

3.1 Compatibilidad con la instalación sencilla

Requisito

Los juegos deben proporcionar una ruta de acceso simplificada en la interfaz de usuario de configuración mediante la implementación de lo siguiente:

  • Muestra un máximo de un aviso de CLUF.
  • La ruta de instalación predeterminada debe omitir todas las selecciones de la instalación (como la carpeta de instalación o las selecciones de componentes), asumir las selecciones predeterminadas y, a continuación, ejecutar el juego o iniciador tras la instalación correcta, sin avisos adicionales. Si lo desea, se puede proporcionar una opción de instalación personalizada para las opciones de configuración avanzadas.
  • Instale los componentes de sistema operativo necesarios (como los entornos de ejecución de DirectX y Visual C) mediante los paquetes de redistribución de Microsoft correctos. La instalación debe realizarse de forma silenciosa, sin preguntar y sin estar protegida por comprobaciones de versión del componente.
  • Proporciona eliminación a través de programas y características en Panel de control tanto para la aplicación de juego como para los archivos de trabajo generados. Se recomienda una opción para eliminar los archivos de datos creados por el usuario. El proceso de eliminación debe asegurarse de que se quitan todos los archivos instalados y se borran todas las opciones de configuración (por ejemplo, entradas de lista de excepciones de firewall y claves del Registro). Los componentes redistribuidos del sistema operativo no deben quitarse.
  • Si el juego requiere que se agreguen excepciones al firewall de Windows, el proceso de configuración puede solicitar a los usuarios que este cambio sea necesario. Este mensaje debe aparecer antes de que comience la instalación.

La instalación y eliminación pueden requerir derechos administrativos. La aplicación de revisiones puede requerir la solicitud de credenciales administrativas, en función de la frecuencia de actualización. El juego normal no debe requerir derechos administrativos, según el requisito 2.1 Siga las directrices de control de cuentas de usuario.

Fundamento

La instalación sencilla es una filosofía de desarrollo de juegos centrada en Windows diseñada para simplificar y simplificar el proceso tedioso y confuso a veces de instalar juegos en equipos que ejecutan Windows sistemas operativos. La instalación sencilla se habilita mediante el uso de un conjunto de tecnologías y procedimientos recomendados que reducen la complejidad innecesaria y el riesgo percibido de instalar juegos en Windows equipos.

Los objetivos clave son:

  • Reduzca la cantidad de tiempo para entrar en el juego y empezar a jugar.
  • Reduzca el número de cuadros de diálogo y opciones a muy pocos, o ninguno, con el fin de simplificar la experiencia de instalación del juego.

Algunas instalaciones tradicionales tienen avisos que permiten instalaciones no funcionales, aunque la aplicación parezca estar instalada correctamente. Por ejemplo, un juego puede requerir que un usuario acepte un CLUF. A continuación, se instala el juego y, a continuación, aparece el CLUF de DirectX. Este CLUF permite a los usuarios rechazar y, por tanto, omitir la instalación del entorno de ejecución de DirectX. Este escenario puede dar lugar a un juego que no se puede ejecutar debido a que faltan componentes.

Información adicional

Para obtener más información sobre la instalación de juegos, técnicas de instalación de juegos no tradicionales, soluciones de aplicación de revisiones compatibles con UAC y control de revisiones frecuentes, consulta los siguientes artículos de DirectX:

Nota

La eliminación de archivos de datos generados específicos del usuario solo debe realizarse para el usuario actual y para ubicaciones de usuario compartidas comunes. No hay ninguna manera sólida de examinar el sistema para quitar archivos específicos del usuario para otros usuarios, incluso si la eliminación requiere credenciales administrativas.

3.2 Compatibilidad con el control de cuentas de usuario para la instalación

Requisito

El instalador del juego no debe asumir que se ejecuta en el mismo contexto que el usuario. Las ubicaciones específicas del usuario serán diferentes del instalador y el reproductor incluso para los sistemas de usuario único debido a la elevación de credenciales de administrador. Por lo tanto, cuando un juego se ejecuta por primera vez, debe realizar tareas específicas del usuario, por separado del proceso de instalación.

El cuadro de diálogo de excepción de firewall de Windows no debe aparecer cuando un usuario hospeda o se une a un juego multijugador. Cualquier configuración necesaria debe realizarse en el momento de la instalación. Las instrucciones de configuración deben informar al usuario de que esta operación se producirá como parte de la configuración.

El instalador del juego debe proporcionar un manifiesto incrustado que designe el nivel de ejecución necesario, según el requisito 2.1 Siga las directrices de control de cuentas de usuario.

Si el instalador inicia el juego una vez completada la instalación, debe iniciarse en el contexto del usuario original.

Fundamento

Uno de los cambios más grandes en el sistema operativo Windows en Windows Vista es la adición de Control de cuentas de usuario (UAC), que ejecuta aplicaciones con privilegios reducidos de forma predeterminada. Como resultado, los instaladores deben administrar los niveles de privilegios en consecuencia. Windows 7 también hace un uso extenso de UAC. Aunque Windows 7 mejora la experiencia del usuario de UAC, los instaladores deben cumplir los mismos requisitos que en Windows Vista para funcionar correctamente, sin depender de un comportamiento de virtualización potencialmente confuso.

UAC está activo de forma predeterminada en Windows Vista y Windows 7, y la gran mayoría de los clientes (88 % o más, en función de los comentarios) dejan habilitada esta característica.

Información adicional

Para obtener más información sobre cómo configurar el firewall de Windows, consulta el artículo de DirectX Windows Firewall para desarrolladores de juegos y el ejemplo FirewallInstallHelper.

El lanzamiento estándar del juego al final del proceso de instalación no cumple el último aspecto de este requisito si un usuario estándar inicia la instalación y, si el proceso de instalación requiere privilegios administrativos (es decir, solicita credenciales de administrador). También hereda privilegios administrativos, lo que supone un riesgo de seguridad potencial. En su lugar, un cargador de arranque de configuración debe iniciar el juego después de volver de una invocación correcta del instalador. Para obtener más información, vea el artículo de MSDN Magazine Teach Your Apps to Play Nicely with Windows Vista User Account Control.

3.3 Instalar en carpetas correctas

Requisito

Los juegos instalados para todos los usuarios deben instalarse en la carpeta Archivos de programa de forma predeterminada. Los datos de usuario deben escribirse cuando el juego se ejecuta por primera vez, no durante la instalación.

Fundamento

Los usuarios deben tener la flexibilidad de instalar aplicaciones donde las necesiten. También deben tener una experiencia coherente y segura con la ubicación predeterminada de los archivos.

Información adicional

Los juegos pueden usar las distintas ubicaciones de carpetas conocidas (como las especificadas por CSIDL_LOCAL_APPDATA y CSIDL_COMMON_APPDATA) para almacenar grandes cantidades de datos del juego y archivos ejecutables auxiliares para implementar escenarios avanzados de instalación a petición y aplicación de revisiones.

Dado que la instalación puede requerir elevación a una cuenta de usuario diferente durante el proceso de instalación de todos los usuarios, no hay ninguna ubicación de usuario correcta en la que almacenar los datos en el momento de la instalación. Además, si el cifrado de archivos está habilitado, la cuenta de usuario que las creó solo puede acceder a los archivos cifrados.

3.4 Instalación correcta de recursos de Windows

Requisito

Las aplicaciones no deben intentar instalar archivos ni claves del Registro protegidas por Windows Protección de recursos (WRP). Si la aplicación requiere versiones más recientes de los componentes del sistema, debe actualizar estos componentes mediante microsoft Service Pack o un paquete de instalación aprobado por Microsoft que contenga el componente del sistema. Los componentes del sistema nunca se deben volver a empaquetar.

Fundamento

Windows Protección de recursos (WRP) está diseñado para asegurarse de que los recursos del sistema protegidos solo se actualizan mediante mecanismos de instalación o actualización aprobados por Microsoft. WRP mejora la confiabilidad del sistema asegurándose de que los resultados de una instalación son predecibles.

Información adicional

WRP es el sucesor de Windows Protección de archivos, que protege la mayoría de los componentes del sistema instalados en la carpeta Windows. WRP protege la mayoría de las claves del Registro que almacenan la configuración para la creación de objetos COM. También reserva determinadas carpetas para su uso exclusivo por el sistema operativo. Los intentos de acceder a los recursos protegidos suelen producir un error de denegación de acceso.

Para obtener más información sobre los procedimientos recomendados cuando el tiempo de ejecución de DirectX se implementa con un juego, consulta el artículo instalación de DirectX para desarrolladores de juegos.

3.5 Evitar reinicios durante la instalación

Requisito

El instalador del juego no debe suponer que la instalación de componentes de Windows de los paquetes de redistribución requiere un reinicio, a menos que el reinicio se indique mediante un resultado devuelto o por la documentación de Microsoft.

Si el instalador del juego siempre fuerza un reinicio, Microsoft debe aprobarlo.

Los cuadros de diálogo de archivos en uso que se incluyen en Windows paquetes del instalador deben contener una opción para cerrar automáticamente las aplicaciones e intentar reiniciarlas una vez completada la instalación.

Fundamento

Reiniciar el sistema después de una instalación es una interrupción inconveniente para los usuarios y, por lo general, no es necesario.

Información adicional

Para obtener más información, vea Uso del instalador de Windows con el Administrador de reinicio.

3.6 Usar el control de versiones de archivos correctamente

Requisito

El programa de instalación del juego debe comprobar correctamente para asegurarse de que están instaladas las versiones de archivo más recientes. La instalación de un juego nunca debe volver a los archivos que no se producen o que son compartidos por las aplicaciones que no se producen.

Fundamento

Los componentes compartidos y los componentes del sistema a menudo se actualizan para las correcciones de seguridad y la funcionalidad ampliada. Una instalación que incluya una versión anterior de los componentes actualizados no debería dar lugar a la pérdida de actualizaciones y correcciones que ya se han aplicado.

3.7 Compatibilidad con Autorun [Requisito condicional]

Requisito

En el caso de los juegos distribuidos en CD, DVD u otros medios extraíbles que admitan Autorun, cuando el disco se inserta por primera vez, la aplicación debe ejecutarse automáticamente o pedir al usuario que instale el juego, a menos que el usuario haya deshabilitado la característica Autorun.

Una vez instalada correctamente la aplicación, volver a insertar el disco en la unidad no debe hacer que la instalación se inicie automáticamente. Es aceptable preguntar a los usuarios si quieren actualizar o cambiar sus opciones de instalación.

La aplicación automática no debe solicitar la elevación (es decir, debe tener asInvoker en el manifiesto, por requisito 2.1, aunque puede iniciar el programa de instalación u otra utilidad que requiera derechos administrativos. La elevación solo debe producirse si el juego no está instalado o si el usuario lo selecciona específicamente.

Fundamento

Autorun simplifica la experiencia de usar aplicaciones distribuidas por medios, como juegos que normalmente requieren que el disco esté presente en la unidad para poder jugar al juego.

Información adicional

No es aceptable exigir al usuario que navegue en Explorador de archivos para iniciar la instalación desde el CD o DVD.

En el caso de los juegos distribuidos en varios discos, los discos posteriores idealmente deben usar la característica Autorun o continuar la instalación sin pedir al usuario que presione una tecla o realice otra acción.

Al crear un programa Autorun, asegúrese de que todos los componentes necesarios estén presentes en instalaciones nuevas de Windows. Las aplicaciones típicas dependen de las tecnologías instaladas por el programa de instalación, pero autorun se ejecuta antes de que se produzca dicha configuración. Un ejemplo común es el error de los programas de ejecución automática porque los archivos DLL de Visual C Runtime no se incluyeron como parte de la configuración de Windows. El programa Autorun, por lo tanto, debe usar la implementación de CRT local de la aplicación o debe vincular estáticamente el CRT.

Los programas de ejecución automática escritos para su uso en versiones de Windows antes de Windows Vista no deben usar el entorno de ejecución de .NET porque esta tecnología no se incluye con Windows XP o versiones anteriores de Windows. Windows Server 2003 y Windows Vista son las primeras versiones de Windows para incluir el entorno de ejecución de .NET como parte de su sistema operativo.

Por motivos similares, los programas autorun no pueden requerir la presencia de componentes opcionales del SDK de DirectX, como D3DX9, D3DX10, D3DX11, XAudio2, X3DAudio, XACT, XINPUT y MDX 1.1.

Para obtener un ejemplo de uso de Autorun, consulte Ejemplo de ejecución automática.

Confiabilidad

Resumen de los requisitos de seguridad y compatibilidad

Ventajas del cliente

Estos requisitos hacen que una aplicación sea más confiable al minimizar el número de bloqueos, bloqueos y reinicios. Los requisitos de confiabilidad pueden ayudar a garantizar que el software sea más predecible, fácil de mantener, resistente y recuperable.

4.1 Eliminar reinicios innecesarios

Requisito

Todos los instaladores de aplicaciones deben aprovechar las API del administrador de reinicio para evitar reinicios del sistema (consulte el requisito 3.5).

Los juegos no deben bloquear el apagado.

Todas las aplicaciones deben responder al administrador de reinicio escuchando y respondiendo a los siguientes mensajes de apagado:

WM_QUERYENDSESSION con LPARAM = ENDSESSION_CLOSEAPP (0x1)

Las aplicaciones de GUI deben responder (TRUE) inmediatamente como preparación para un reinicio.

WM_ENDSESSION con LPARAM = ENDSESSION_CLOSEAPP (0x1)

Las aplicaciones deben devolver un valor de 0 en un plazo de 5 segundos y, a continuación, cerrarse.

CTRL+C

Las aplicaciones de consola que reciben este mensaje deben cerrarse inmediatamente.

Fundamento

Los reinicios del sistema son una interrupción importante. Conducen a una mala experiencia de usuario y deben minimizarse. Algunas operaciones, como las actualizaciones críticas del sistema, pueden requerir reinicios. Al escuchar mensajes de apagado, el juego y otras aplicaciones pueden reaccionar rápidamente a las solicitudes del administrador de reinicio. De esta manera, pueden evitar retrasos innecesarios en las solicitudes de reinicio válidas.

Información adicional

Si un instalador de juegos usa la tecnología Windows Installer (MSI) sin ninguna acción personalizada, esta funcionalidad se proporciona automáticamente. Los paquetes de redistribución de Microsoft también admiten el Administrador de reinicio.

Para obtener más información sobre el Administrador de reinicios, vea el artículo de MSDN Acerca del Administrador de reinicio.

4.2 Eliminar errores de comprobador de aplicaciones

Requisito

El juego no debe generar errores que se ejecuten en Microsoft Application Verifier (AppVerifier), versión 4.0 o posterior, en las siguientes pruebas:

  • Conceptos básicos: identificadores, montones, bloqueos, memoria, TLS
  • Varios: DangerousAPIs, DirtyStacks

Fundamento

AppVerifier comprueba muchos problemas conocidos que provocan bloqueos y bloqueos en aplicaciones de Windows, así como vulnerabilidades de seguridad conocidas.

Información adicional

Para obtener más información sobre application Verifier, vea Application Verifier and Using Application Verifier Within Your Software Development Lifecycle (Comprobador de aplicaciones en el ciclo de vida de desarrollo de software ) en MSDN. Puede descargar Application Verifier en Detalles de descarga: Comprobador de aplicaciones en el Centro de descarga de Microsoft.

Este requisito no se aplica a aplicaciones administradas puras sin interoperabilidad nativa.

Estas pruebas se deben ejecutar en una compilación de versión. Las compilaciones de depuración pueden generar errores falsos. Algunas tecnologías anti-piratería y anti-trampa pueden interferir con la ejecución de AppVerifier. Por lo tanto, estas pruebas deben realizarse sin la piratería y las tecnologías anti-trampa habilitadas.

Puede ser necesario establecer la propiedad Full de la prueba Basics:Heaps en FALSE, ya que pageHeap completo aumenta considerablemente la presión de memoria de la aplicación en ejecución. Se seguirán detectando errores, pero es posible que sean más difíciles de rastrear si usa solo pageHeap parcial.

Si usa las pruebas relacionadas con UAC/LUA en Application Verifier para cumplir los requisitos de Control de cuentas de usuario 2.1 y 3.2, debe usar standard User Analyzer para revisar los resultados. También hay muchas otras pruebas útiles proporcionadas por Application Verifier, que se recomienda encarecidamente usar en desarrollo y pruebas para garantizar un alto nivel de compatibilidad con las versiones actuales y futuras de Windows. La prueba HighVersionLie se usa para comprobar el cumplimiento con el requisito 2.5.

Visual Studio Team System incluye un subconjunto de la funcionalidad AppVerifier integrada en el entorno de depuración. Esto puede resultar útil para realizar un seguimiento y resolver problemas con aspectos básicos: montones, identificadores y pruebas de bloqueos.

4.3 Compatibilidad con Informe de errores de Windows e información de versión de archivo

Requisito

Para habilitar la compatibilidad con Informe de errores de Windows, los juegos deben cumplir los siguientes requisitos:

  • Los juegos solo deben controlar las excepciones conocidas y esperadas. Informe de errores de Windows no se debe deshabilitar. Si aparece un error como una infracción de acceso en un juego, debe permitir que Informe de errores de Windows informe del bloqueo.
  • Todos los archivos ejecutables (por ejemplo, archivos .exe o ARCHIVOS DLL) deben contener un nombre de producto preciso, un nombre de empresa y una versión de archivo.
  • La salida normal del juego no debe dar lugar a un error de excepción desconocido.

Fundamento

Las API de Informe de errores de Windows proporcionan comentarios vitales a Microsoft para detectar bloqueos generalizados y bloqueos en las aplicaciones. Esto permite a Microsoft y a sus asociados detectar y resolver rápidamente los problemas del sistema y del controlador que conducen a errores de aplicación rápidamente.

Información adicional

Los juegos pueden incluir controladores de excepciones no controladas personalizados para realizar la compatibilidad personalizada y la funcionalidad de informes, pero deben pasar cualquier error en las funciones ReportFault o WerReportSubmit .

La información de la versión de archivo adecuada se puede comprobar viendo las propiedades del archivo en la interfaz de usuario de escritorio de Windows y comprobando la página de propiedades Versión.

Para obtener más información sobre las API de Informe de errores de Windows y cómo analizar los volcados de memoria generados al usar este servicio, consulte el artículo Análisis de volcado de memoria de DirectX.

Controlador común de Xbox 360 para terminología de Windows

NOMBRE Descripción
Un Botón A.
B Botón B.
ATRÁS El botón Atrás.
(derecha/izquierda) parachoques El botón situado en el borde superior derecho e izquierdo del controlador. Equivalente a un botón de hombro.
panel direccional Panel direccional del controlador.
D-pad Abreviatura aceptada del panel direccional.
DP Abreviatura del panel direccional y etiqueta del controlador.
RB, LB Abreviaturas de parachoques de derecha e izquierda y etiquetas de controlador.
RS, LS Abreviaturas de stick derecho e izquierdo y etiquetas de controlador.
RT, LT Abreviaturas de desencadenador de derecha e izquierda y etiquetas de controlador.
RSB, LSB Abreviaturas de stick derecho e izquierdo y etiquetas de controlador.
INICIO El botón Iniciar.
(derecho/izquierdo) stick El stick del controlador. Anteriormente, stick analógico.
Botón stick (derecho/izquierdo) El botón stick del controlador. Anteriormente, el botón del stick digital.
Desencadenador (derecho/izquierdo) Desencadenador del controlador.
Vibración Comentarios del juego producidos por el motor del controlador. No use roncar.
x Botón X.
S El botón Y.
Mando Xbox 360 para Windows El controlador para juegos de Xbox 360 se vende como una SKU de hardware de PC, incluido un disco de controlador de dispositivo Windows.
Mando inalámbrico Xbox 360 para Windows El controlador para juegos inalámbrico xbox 360 se vende como una SKU de hardware de PC, incluido un disco de controlador de dispositivo Windows.

Directrices para productos de middleware de juegos

Introducción

Para que los juegos se califiquen para los Juegos para Windows programa, deben cumplir una lista de requisitos técnicos. Los componentes de terceros que se incluyen con un título (archivos ejecutables, archivos DLL, controladores, etc.) también deben cumplir estos requisitos para que el juego pueda calificar. En este documento se resaltan los requisitos más comunes que también deben cumplir los componentes de terceros para que el juego supere las pruebas de cumplimiento. Los instaladores y los paquetes completos de motor o producción de juegos deben revisar el documento completo Juegos para Windows requisitos técnicos, ya que muchos de estos requisitos se ven afectados por estas herramientas.

Recomendaciones adicionales

Además de garantizar que el componente admita la creación de títulos que cumplan los requisitos de Juegos para Windows, hay una serie de otras consideraciones que debe tener en cuenta al diseñar e implementar una biblioteca o utilidad de soporte técnico para un juego de Windows.

  • Para admitir a los desarrolladores que trabajan en aplicaciones x64 nativas de 64 bits, proporcione versiones nativas de 32 y 64 bits de las bibliotecas. La versión de 32 bits debe ser compatible con 64 bits por 2.2. Las bibliotecas de aplicaciones de 32 bits no deben suponer que el bit alto de cualquier dirección de 32 bits no se usa para admitir el uso en aplicaciones x86 largeADDRESSAWARE.

  • Si proporciona encabezados de código nativo (C/C++), use la sintaxis del atributo Standard Annotation Language (SAL) para decorar las rutinas de la API pública. Esto permitirá a los usuarios de la biblioteca obtener la máxima ventaja de usar la Code Analysis estática (/analyze), que forma parte de Visual Studio Team System 2005, Visual Studio Team System 2008, Visual Studio 2010 Premium y Visual Studio 2010 Ultimate, así como las herramientas del compilador Windows SDK disponibles públicamente.

  • Si el producto crea subprocesos dentro del proceso del usuario, asegúrese de asignar un nombre a cada subproceso para que las herramientas de depuración puedan anotar correctamente los subprocesos en ejecución.

  • Si escribes rutinas diseñadas para llamarse dentro del bucle principal de un juego, usa las rutinas D3DX D3DPERF_BeginEvent/EndEvent y D3DPERF_SetMarker anotar operaciones de alto nivel para facilitar la identificación de cuellos de botella mediante PIX para Windows.

    Nota

    Para la funcionalidad de diagnóstico de gráficos de Visual Studio 2012, estas rutinas D3DX y PIX se reemplazan por la interfaz ID3DUserDefinedAnnotation.

  • En el caso de las bibliotecas de red, proporcione implementaciones independientes de IP y evite las rutinas IPv4 en desuso solo para admitir las tecnologías IPv6 y Teredo en Windows XP con Service Pack 2, Windows Vista y Windows 7.

  • Los proveedores de servicios de juegos deben registrarse con games Explorer con la versión 2 del esquema de GDF y usar la característica RSS para proporcionar noticias relacionadas con el servicio.

Juegos para presentaciones de Windows

Introducción

Los juegos para Windows presentación van más allá de proporcionar una experiencia de juego sólida en Windows pc. Al implementar estas características, los juegos pueden agregar más entusiasmo a la experiencia del usuario en las plataformas de Windows más recientes.

Los juegos para Windows títulos deben cumplir todos los requisitos técnicos enumerados en este artículo, pero las características de presentación son opcionales. Estos títulos son gratuitos para implementar algunas, ninguna o todas estas presentaciones.

S.1 Exploit Direct3D 11

Requisito

Direct3D 11 es la API de representación de última generación para Windows Vista y Windows 7. Los juegos que aprovechan Direct3D 11 usan contenido optimizado, técnicas avanzadas de representación y nuevas características de hardware para crear una experiencia atractiva en el hardware que admite 10, 10.1 y 11.

Si el juego también implementa Direct3D 9, una comparación en paralelo debe demostrar una mejora perceptible en la calidad del contenido, la fidelidad visual, el rendimiento, la complejidad de la escena y otras áreas de fidelidad de gráficos para Direct3D 11. Esta compatibilidad está sujeta a los Juegos para Windows Requisito técnico 1.7.

La tecnología Direct3D 10level9 se puede usar para admitir el hardware de vídeo de clase Direct3D 3.0/3.0 en Windows Vista y Windows 7, en lugar de usar una implementación de Direct3D 9 en paralelo para una amplia compatibilidad con hardware. Sin embargo, esto no es suficiente para demostrar esta presentación.

En equipos que ejecutan Windows Vista o Windows 7 con Direct3D 11 instalado, el juego debe usar Direct3D 11 de forma predeterminada.

Fundamento

La API de Direct3D 11 se basa en la infraestructura Windows de controlador de pantalla (WDDM) y Direct3D 10.1 para admitir nuevas funcionalidades: teselación de hardware, sombreadores de proceso, representación multiproceso y creación de recursos, nuevos formatos de compresión de texturas y un lenguaje de sombreador más flexible. Direct3D 11 proporciona compatibilidad unificada de hardware para tarjetas de vídeo modernas, incluidas las partes de Direct3D 11 de última generación, todas las tarjetas de vídeo Direct3D 10 y 10.1, y muchas tarjetas de vídeo shader Model 2.0/3.0 Direct3D 9, que es el hardware de vídeo mínimo necesario para el escritorio Aero 3D.

Información adicional

Migrar un motor de representación de Direct3D 9 para usar la nueva interfaz de Direct3D 11 es una tarea bien definida:

  • Elimine todas las operaciones de función fija en favor de sombreadores programables.
  • Actualice todos los sombreadores existentes a la nueva sintaxis de Shader Model 4.x/5.
  • Actualice la administración de recursos para admitir el nuevo modelo de vista.
  • Convierta todos los recursos para usar una nueva lista de formatos disponibles.
  • Actualice el control de estado de representación para usar bloques de estado inmutables y vuelva a trabajar las constantes del sombreador en búferes de constantes.

Esta conversión es esencial para habilitar la presentación de Direct3D 11, aunque el resultado no cumple el requisito de presentación de aprovechar la nueva API.

La nueva API y el modelo de programación HLSL asociado ofrecen muchas oportunidades para mejorar el contenido:

  • Aprovechando las características de hardware de Direct3D 10 existentes, como sombreador de geometría, Stream Out, matrices de texturas y los formatos de textura comprimido BC4/BC5.
  • Aprovechando las características de hardware existentes de Direct3D 10.1, como modos independientes de combinación de destino por representación, lectura de profundidad de MSAA, acceso de sombreador de MSAA por muestra, matrices de mapas de cubos y representación en formatos comprimidos por bloque (BC).
  • Implementación de algoritmos avanzados de GPU mediante el sombreador de proceso con CS4.x en tarjetas de vídeo Direct3D 10/10.1 existentes (habilitadas por controladores de vídeo actualizados) o CS 5.0 en tarjetas de vídeo Direct3D 11 de próxima generación.
  • Representación en varios subprocesos mediante la creación de recursos sin subprocesos y varios contextos de dispositivo para mejorar el rendimiento en sistemas multicore (con controladores de vídeo actualizados). Para obtener más información, consulta Games for Windows Showcase S.3.
  • Usando nuevas características de hardware de vídeo de clase Direct3D 11, como teselación de hardware con sombreadores de casco y dominio, Sombreador modelo 5.0 HLSL características de hardware de sombreador BC6HBC7 formatos de textura comprimidos y Vinculación dinámica del sombreador.

Las técnicas que se pueden implementar con Direct3D 9 (en gran medida a través de un alto costo de CPU) se pueden descargar en la GPU de forma eficaz, lo que libera recursos de CPU para admitir otras demandas de juego.

Las API de Direct3D 11, las herramientas auxiliares y los ejemplos están disponibles en el SDK de DirectX. Consulte también Las API de gráficos en Windows.

S.2 Exploit x64 Native

Requisito

El juego incluye un ejecutable nativo de 64 bits que ofrece una nueva experiencia atractiva habilitada por las ediciones x64 de Windows que se ejecutan en hardware compatible con x64. Una comparación en paralelo con la versión de 32 bits del juego debe mostrar una mejora perceptible en la complejidad del contenido, reducir los tiempos de carga generales y el rendimiento.

En las ediciones de 64 bits de Windows, la instalación siempre debe configurar la versión nativa de 64 bits del juego como valor predeterminado para los accesos directos en el Explorador de juegos y Windows XP Professional x64 Edition. Si se desea una instalación dual, se puede especificar una tarea de reproducción adicional para el Explorador de juegos en Windows Vista y Windows 7 que apunte a la versión de 32 bits, pero el valor predeterminado debe seguir siendo la versión nativa de 64 bits.

Ten en cuenta que el juego debe admitir las ediciones de 64 bits de Windows Vista y Windows 7 para cumplir esta recomendación de presentación. Se recomienda la compatibilidad con Windows XP Professional x64 Edition, pero no es necesario.

Fundamento

La tecnología x64 proporciona funcionalidades de direccionamiento de 64 bits para los mercados de consumidores y servidores que incluye versiones anteriores de 32 bits de velocidad completa para aplicaciones existentes. x64 es una parte clave de la hoja de ruta para AMD (AMD64) e Intel (EMT64), y, a excepción de las CPU ultra-móviles, admite la tecnología para todos los procesadores de generación actual y futura.

Windows XP Professional x64 Edition fue el primer sistema operativo (SO) Windows orientado al consumidor para admitir la tecnología x64, y Windows Vista y Windows 7 amplían considerablemente la disponibilidad de la habilitación del sistema operativo para la informática de consumo de 64 bits. Con 2 GB de RAM como estándar en muchos equipos nuevos, las mejoras adicionales en el escalado de memoria no beneficiarán a aplicaciones individuales de 32 bits que no pueden abordar más de 2 GB de RAM física. En la actualidad, muchos juegos se enfrentan a desafíos que ajustan todo el contenido disponible a las restricciones de 2 GB de espacio de direcciones virtuales, especialmente cuando se combinan con las memorias de vídeo grandes disponibles en GPU de gama alta y el cambio a la tecnología x64 aumenta considerablemente los niveles de detalle compatibles.

La compatibilidad con x64 para juegos de 32 bits es un requisito técnico de juegos para Windows (2.2), pero aprovechar al máximo las nuevas tecnologías requiere una implementación nativa de 64 bits.

Información adicional

La principal ventaja de direccionamiento de 64 bits es la capacidad de acceder directamente a más de 2 GB de memoria física y virtual. El espacio de direcciones de memoria virtual grande permite un uso extenso de E/S asignada por memoria sin preocuparse por los problemas de agotamiento del espacio de direcciones de máquina virtual frecuentes en la programación de 32 bits. Los juegos pueden aprovechar el nuevo espacio para mejorar considerablemente los tiempos de carga o, en algunos casos, para eliminar las pausas para cargar contenido.

Las aplicaciones de 32 bits existentes pueden beneficiarse de las ediciones x64 al tener la capacidad de procesar direcciones con datos completos de 32 bits cuando se compilan con la opción del enlazador Habilitar direcciones grandes (/LARGEADDRESSAWARE). En las versiones de 32 bits de Windows XP, los modos de arranque especiales permitían a estas aplicaciones abordar hasta 3 GB de RAM y las ediciones x64 proporcionan acceso a hasta 4 GB de RAM para aplicaciones compatibles con direcciones grandes (LAA). Aunque el uso de LAA en una aplicación de 32 bits no cumple este requisito de presentación, esta tecnología de puente es una manera extremadamente útil de proporcionar ventajas de escalado adicionales en las versiones x64 de Windows para aquellos que no implementan completamente este requisito de presentación.

Para obtener más información, consulta Programación de 64 bits para desarrolladores de juegos y RAM, VRAM y Más RAM: Juegos de 64 bits está aquí en Gamasutra.

Nota

Un desafío clave para esta presentación es garantizar que las bibliotecas o componentes de terceros en los que se basa el juego estén disponibles para el desarrollo nativo de 64 bits. Muchas API heredadas de Microsoft también se han eliminado del entorno nativo de 64 bits, lo que puede demostrar un desafío para las bases de código del motor que contienen implementaciones anteriores de sistemas clave.

Procesadores de Many-Core de vulnerabilidades de seguridad de S.3

Requisito

El juego implementa características que aprovechan los procesadores de varios núcleos, el escalado a 3, 4 o más núcleos, cuando están disponibles.

Si el juego admite sistemas de un solo procesador o de doble núcleo, una comparación en paralelo con un sistema de cuatro núcleos debe demostrar nuevas características perceptibles, efectos atractivos adicionales, mejora en la calidad del contenido o rendimiento mejorado.

Dado que el escalado de doble núcleo ya es ampliamente compatible con los juegos, así como lo usan automáticamente varias mejoras del controlador Direct3D, el escalado de doble núcleo no es suficiente para demostrar esta presentación.

Fundamento

El crecimiento continuo en el rendimiento de las CPU ha cambiado de mejoras de velocidad de reloj a la adición de núcleos computacionales. Tanto AMD como Intel se basan en diseños escalables y de varios núcleos. Todas las plataformas de juegos de última generación tienen CPU de varios núcleos debido a este cambio fundamental en la evolución de los procesadores. Las aplicaciones de un solo subproceso ya no verán ganancias significativas de las CPU de próxima generación. El multithreading simple también no se puede escalar a medida que el número de núcleos de CPU en uso común crece a tres o más.

Información adicional

Tenga en cuenta que los recuentos de núcleos no necesitan ser una potencia de dos, por lo que los juegos deben escalar linealmente y controlar los recuentos de núcleos de 3, 4, 5, 6, 7, 8, etc.

El escalado aumentando el número de subprocesos de una aplicación solo proporciona un retorno si el costo de la comunicación y la sincronización de subprocesos se mantienen en la comprobación. El escalado basado en características puede resultar una solución más sencilla a corto plazo, lo que permite que el juego funcione normalmente sin los subprocesos adicionales en sistemas de un solo núcleo y habilitarlos cuando la potencia adicional de CPU esté disponible.

Para obtener más información, consulta Codificar para varios núcleos en Xbox 360 y Microsoft Windows y Consideraciones de programación sin bloqueo para Xbox 360 y Microsoft Windows en los artículos de DirectX, así como la utilidad DXUTLockFreePipe y el ejemplo CoreDetection.

Hacer uso de los contextos de dispositivo y creación de recursos sin subprocesos de Direct3D 11 es útil para lograr una escalabilidad de varios núcleos en la representación y la carga de recursos gráficos. Consulta Juegos para Windows Showcase S.1.

Tenga en cuenta que el uso de las instrucciones de CPU rdtsc directamente, en lugar de usar Windows API para calcular el tiempo en sistemas multicore, puede provocar problemas en algunas configuraciones de hardware y sistema operativo; consulta Game Timing and Multicore Processors en los artículos de DirectX.

Juegos de soporte técnico de S.4 para Windows - LIVE

Juegos para Windows: Live ya no es compatible con Microsoft.

Compatibilidad con S.5 Windows Touch

Requisito

Windows juegos compatibles con toques táctiles son jugables con toques o gestos en equipos que ejecutan Windows 7 con una pantalla táctil. También se puede usar la entrada del teclado, pero la interfaz de reproducción principal debe basarse en la función táctil.

Habilitar la función táctil no debe impedir el uso del mouse o del controlador común, sujeto al Requisito técnico 1.4.

No se espera que el instalador del juego admita Windows funcionalidad Touch.

Fundamento

Las pantallas compatibles con varios toques para equipos están disponibles para equipos portátiles y escritorios, y representan una característica de hardware clave que se promueve con el lanzamiento de Windows 7. Windows 7 admite Windows Touch en todas las interfaces de escritorio y controles comunes.

Información adicional

Las aplicaciones de código nativo pueden tener acceso multitáctil a través de los mensajes de WM_TOUCH, en combinación con la función RegisterTouchWindow . Consulte también manipulations and Inertia API (Manipulaciones e inercia).

Windows Presentation Foundation (WPF) 4.0 proporciona una solución administrada para interfaces multitáctil.

Para obtener más información, consulte el SDK de Windows Touch.

S.6 admite color alto

Requisito

Los juegos que admiten color alto usan un formato 10:10:10:2 (DXGI_FORMAT_R10G10B10A2, D3DFMT_A2B10G10R10) o un formato 16:16:16:16:16 (DXGI_FORMAT_R16G16B16A16, D3DFMT_A16B16G16R16) para el modo de visualización de reserva y pantalla completa de representación.

Mediante el uso de un destino de representación de color alto, High-Dynamic contenido de rango (HDR) se puede representar con una gama extendida o ancha al realizar una asignación de tono a un intervalo de 10 o 16 bits.

Fundamento

Los monitores han sido capaces de mostrar más de 256 niveles de color por canal durante muchos años, incluso cuando las pantallas de CRT eran frecuentes. El hardware de exploración en tarjetas de vídeo ha sido el factor de limitación. Las GPU modernas, incluida la mayoría del hardware de clase 9 de Direct3D y todas las clases de Direct3D 10 y mejor hardware, tienen hardware de exploración capaz de al menos 10 bits por canal y la funcionalidad de hardware se establece para crecer a 16 bits por canal de color en el futuro. Los sistemas de interconexión de TV HD (HDMI, DisplayPort) han sido diseñados para manejar más de 8 bits por canal, y VGA analógico ya transportará tales señales.

Información adicional

Tenga en cuenta que, históricamente, color alto o color hi, hace referencia históricamente a la migración de 256 (8 bits) a pantallas de color de 15 o 16 bits. La mayoría de los sistemas de visualización han pasado mucho tiempo a True Color, que es color de 24 bits o 8 bits por canal de color para rojo, verde y azul. Por Color alto aquí nos referimos a una nueva generación de sistemas de pantallas que pueden funcionar con más de 8 bits por canal de color individual. también se conoce como Color profundo.

Introducción

Además de cumplir los requisitos técnicos y adoptar una o varias presentaciones en su título, hay una serie de procedimientos recomendados que deben seguirse para todos los juegos de Windows. Aunque estas recomendaciones están fuera del ámbito de los requisitos técnicos básicos, se recomienda encarecidamente emplearlas para todos los juegos para Windows títulos.

Recomendaciones adicionales

  • Use el compilador y el entorno de ejecución de Visual Studio más recientes. Las versiones más recientes del compilador implementan mejoras significativas para la calidad del código generado y para los problemas de seguridad, y emplean estrategias modernas de optimización del procesador. La actualización del compilador y el uso del entorno de ejecución de C más reciente es una manera sencilla de migrar a procedimientos de codificación modernos.
  • Use la versión de la biblioteca de vínculos dinámicos (DLL) del runtime de C, en lugar de la vinculación estática, y use CRT seguro. (Las excepciones se pueden realizar en casos de preinstalación especiales, como para un programa Autorun o para el propio instalador).
  • Para el audio del juego, usa XAudio2, X3DAudio o XACT, en lugar de DirectSound. Para los motores de audio que realizan todas las mezclas y la conversión de velocidad de origen y solo necesitan una solución de baja latencia para la salida de audio, use DirectSound en Windows XP (solo) y WASAPI en Windows Vista y Windows 7.
  • Evite usar LAS API heredadas y en desuso: DirectDraw, DirectSound, DirectPlay, la capa de rendimiento de DirectMusic, DirectPlay Voice y el modo retenido de Direct3D. Ten en cuenta que DirectPlay Voice y el modo retenido de Direct3D no están disponibles en Windows Vista o Windows 7. La capa de rendimiento de DirectPlay y DirectMusic no están disponibles para las aplicaciones nativas de x64.
  • Optimice mediante conjuntos de instrucciones SIMD SSE/SSE2. Consulte la API de DirectXMath en el SDK de Windows como una solución multiplataforma para las operaciones matemáticas optimizadas para SIMD.
  • Use procedimientos recomendados modernos para la seguridad de Windows (incluidas las opciones del compilador y del enlazador, como /NXCOMPAT, /GS, /SAFESEH, /DYNAMICBASE, /SDL, etc.). Para obtener más información, consulta Procedimientos de seguridad recomendados en el desarrollo de juegos.
  • Use los componentes y bibliotecas más recientes del SDK de Windows. Quite las dependencias de los componentes heredados de DirectSetup implementados fuera de banda, como D3DX9, D3DX10 y D3DX11. Considere la posibilidad de usar DirectXTex o DirectXTK o ambos.
  • Evite usar el compilador HLSL anterior y, en su lugar, use el compilador HLSL moderno. Si la aplicación requiere compatibilidad con el sombreador de píxeles 1.x, use el ensamblado de sombreador en lugar de HLSL o limite el uso del compilador anterior a solo esos escenarios.

Recursos

Término Descripción
Juegos para Windows: Casos de prueba
 Procedimientos recomendados para juegos en Windows XP, Windows Vista y Windows 7
SDK de Windows
 SDK de Windows
Directrices de control de cuentas de usuario
 Windows Vista Application Development Requirements for User Account Control Compatibility
Portal para desarrolladores de WinQual
 Windows Quality Online Services (Winqual)
Portal para desarrolladores de DirectX
 Centro para desarrolladores de Directx
Blog de juegos para Windows y SDK de DirectX
 Juegos para Windows y el SDK de DirectX
Artículos adicionales de DirectX
 Artículos técnicos de DirectX