Compartir a través de

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

  • Artículo

En este artículo se proporcionan los requisitos técnicos y los procedimientos recomendados para los 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 juegos de Win32 de escritorio en Windows 8.

Estos artículos contienen estas secciones:

Diferencias para Windows 8

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

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

Todos los juegos que registra 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. Puede seguir 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. Siga probando el registro del Explorador de juegos con Windows 7 y compruebe que el nuevo icono de la interfaz de usuario de Windows aparece al instalarlo en Windows 8 (consulte 1.1 Integración del Explorador de juegos).

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

El registro con las API del Explorador de juegos sigue siendo el mecanismo para registrar el juego con controles parentales de Windows

Se recomienda ejecutar la versión de Windows SDK 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.

Consulte 1.2 Compatibilidad con protección 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 winW2 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 del SDK de DirectX existente XINPUT 1.3, que requiere que DirectSetup se implemente.

Consulte 1.4 Compatibilidad con el mando 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 plataformas Windows 8 x86 y x64.

Consulte 2.2 Compatibilidad con versiones de Windows 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 barra mínima actuales que se recomiendan para la implementación de juegos.

El paquete de redistribución del usuario final de DirectX se ejecuta correctamente en Windows 8, como 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 administrados heredados de DirectX 1.1. Este problema se aplica a Windows 8, que viene con .NET 4.5 de forma predeterminada, y a los 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 al conjunto mínimo necesario de CAB.

Consulte 3.4 Instalación correcta de los recursos de Windows.

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

Estos juegos desencadenan un comportamiento de compatibilidad de aplicaciones en Windows 8 para habilitar automáticamente el entorno de ejecución de .NET 3.5 (que requiere acceso a la red). Pero se recomienda que los desarrolladores de .NET se muevan 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 correcta de los recursos de Windows.

No se recomienda el uso de un sistema de ejecución automática u otra tecnología de preinstalación basada 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 con ejecución 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 Eliminación de errores de comprobador de aplicaciones.

Información adicional

Guía paso a paso de la compatibilidad con Windows 8 y Windows Server 2012
¿Dónde está el SDK de DirectX?

Juegos para Windows

Resumen de los requisitos de los juegos

Ventajas para los clientes

Los juegos de ordenador son una experiencia de entretenimiento clave en Windows, pero las preocupaciones sobre la facilidad de uso han causado frustración entre los clientes a lo largo de los años. Tradicionalmente, los juegos se instalan como aplicaciones, pero se utilizan más como medios de entretenimiento (películas o canciones, por ejemplo). Las innovaciones, como Games Explorer, exponen los juegos de una forma coherente y diferente a las aplicaciones estándar. Estas innovaciones también otorgan a los juegos el estatus de ciudadanos de primera clase 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 publicador, desarrollador, fecha de lanzamiento, versión, puntuaciones del índice de experiencia de Windows, clasificación (si procede) e hipervínculos asociados.

Si el juego se distribuye digitalmente a través de un servicio de juegos 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 juegos (GDF). (Para obtener más información sobre los GDF, consulte Información adicional).

Además, los instaladores de juegos deben observar 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 mediante 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.

Análisis razonado

El Explorador de juegos de Windows es similar en concepto a las carpetas de 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 de Mis documentos o Mis imágenes al permitir una organización más rica 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 el Explorador de juegos requiere que cree un archivo de definición de juego (GDF), que es un archivo de texto XML incrustado dentro de 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. El 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 (True Color) y de 8 bits (256). El editor de iconos proporcionado en Visual Studio 2008 y 2010 admite estos formatos de iconos grandes, al igual que IconWorkshop Lite.

Los detalles sobre la integración con el Explorador de juegos de Windows se proporcionan en el SDK de DirectX. 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 un GDF. Consulte también "Integración del Explorador de juegos de Windows" 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 la 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 en el 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, haciendo clic en Juegos.

Para las aplicaciones asociadas que se instalan con el juego, pero no los propios juegos, puede crear grupos de programas del menú Inicio, accesos directos e iconos de escritorio en todas las versiones de Windows, incluidos Windows Vista y Windows 7. Estas aplicaciones asociadas deben cumplir los requisitos aplicables de Juegos para Windows; para obtener más información, consulte Directrices para productos de middleware de juegos. Se recomienda que los servicios de juegos se registren con el Explorador de juegos como proveedor de juegos para Windows 7. 1

1.2 Compatibilidad con protección familiar/controles parentales

Requisito

Los juegos deben ser totalmente compatibles con la protección familiar de Windows respetando las siguientes normas:

  • 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 requisito 2.1, siga las directrices de control de cuentas de usuario).
  • Los juegos calificados por organismos de calificación compatibles con Windows, como ESRB y PEGI, deben incluir la información de clasificación asignada en su archivo de definición del juego (GDF). Todos los datos de calificación disponibles deben incluirse en cada versión localizada del GDF, así como en la versión de idioma neutro.
  • Los juegos deben enumerar sus ejecutables en el GDF para ofrecer una buena experiencia de usuario en las restricciones generales de aplicación, a menos que el juego utilice una tecnología antipiratería que cree ejecutables con nombres aleatorios 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.

Análisis razonado

Todos los juegos deben ejecutarse en el contexto de una cuenta de usuario estándar para permitir que las cuentas controladas por controles parentales de Windows jueguen al juego. Los padres quieren poder vigilar y controlar el acceso de sus hijos a los juegos. Además, numerosos grupos de la industria, el gobierno y la defensa de los derechos de los menores desean mejores formas de permitir a los padres supervisar y controlar los juegos a los que están expuestos sus hijos. Junto con la arquitectura que ofrece el Explorador de Juegos, Microsoft proporciona a los padres esta capacidad a través de controles parentales de Windows.

Incluso para los juegos que no participan en un programa de calificación, exigir privilegios elevados crea una mala experiencia de juego para la mayoría de las cuentas de usuario. Esto es especialmente cierto si está activado el control parental, que requiere que los padres introduzcan la contraseña de administrador cada vez que se inicia el juego.

El sistema de control parental de Windows permite a los padres seleccionar las calificaciones que consideran apropiadas para sus hijos. El control parental es compatible con muchos de los sistemas de calificación de todo el mundo. El control parental también permite a los padres restringir el acceso a los juegos en función de los descriptores de contenido (si el sistema de calificación aplicable los admite) y permitir o denegar el acceso a juegos concretos.

La elección predeterminada del sistema de calificación para el control parental de Windows se basa en la configuración regional del sistema, pero el usuario puede modificarlo en Opciones regionales y de idioma en Panel de control. Por lo tanto, cada idioma compatible debe proporcionar todos los datos de calificación disponibles para que el usuario pueda seleccionar la calificación que desee.

Información adicional

Los juegos sin calificació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 Sin calificar, muestran el texto "Sin calificación proporcionada" en el Explorador de juegos y están sujetos a la configuración de Restricciones de juego en Controles parentales para juegos sin calificar. La configuración de restricciones predeterminada es Permitir.

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

El Editor de archivos de definición de juegos del SDK de DirectX incluye todos los sistemas de calificació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 calificación 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 calificación y está sujeto a la configuración de contenido no calificado.

Sistema operativo Sistemas de calificación compatibles
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 Service Packs para Windows Vista agrega compatibilidad para lo siguiente:
  • GRB (Corea del Sur)
  • Descriptores de contenido de variantes de ESRB "Mild"
Windows 7 Windows 7 admite los sistemas de calificación compatibles con Windows Vista y agrega compatibilidad con lo siguiente:
  • CSRR (Taiwán)
Windows 8 Windows 8 admite los sistemas de calificación 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 ahora en desuso:
  • PEGI-FI (Finlandia)
  • OFLC (Australia)

Nota:

Los títulos que incluyan nuevos descriptores de contenido de Windows Vista Service Pack 1 (SP1) de ESRB se mostrarán como Sin calificar en Windows Vista sin Service Pack.

Los datos de calificación más recientes se omiten en versiones de sistemas operativos sin compatibilidad. La variante PEGI (Finlandia) ahora está en desuso en favor del sistema de calificación estándar PEGI (Europa). El sistema OFLC ahora está en desuso a 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, consulte el artículo de DirectX Control de cuentas de usuario para desarrolladores de juegos.

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

1.3 Compatibilidad con juegos guardados enriquecidos

[Este requisito se ha retirado]

1.4 Compatibilidad con el mando común de Xbox 360 para Windows [Requisito condicional]

Requisito

Los juegos compatibles con mandos tipo gamepad deben ser compatibles con el Mando Xbox 360 para Windows mediante la API XInput. Si también se admiten periféricos 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 mando deben usar los nombres de Xbox 360. Consulte la lista de Terminología del mando común de Xbox 360 para Windows para obtener más información.

La vibración del mando debe desactivarse cuando el juego está 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.

Análisis razonado

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 por menús para usar los botones del mando estándar ampliamente aceptados:

  • A - Aceptar
  • B - Cancelar
  • Inicio - Aceptar o pausar
  • Atrás - Cancelar, retroceder una pantalla o subir un nivel de menú

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

En el tema XInput y DirectInput se describen los problemas 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 obtener más información sobre cómo obtener información sobre el movimiento del mouse de alta resolución sin usar DirectInput, consulte Aprovechamiento del movimiento del mouse de alta definición.

1.5 Compatibilidad con 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)
  • 16:9 pantalla panorámica (1280 720)
  • 16:10 pantalla panorámica (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 siguientes reglas:

  • El juego debe usar 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 pantalla cuando se realice un cambio. Si el usuario no acepta en un plazo de 15 segundos, la pantalla debe revertirse a la configuración anterior.
  • El juego no debe estirar los píxeles ni centrar una ventana de representación de 4:3 para admitir relaciones de aspecto de pantalla ancha. Sin embargo, el formato de pantalla ancha es aceptable.

Análisis razonado

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

  • Compatibilidad con pantallas de alto nivel de detalle.
  • Aumento de la cuota de mercado de los monitores panorámicos.
  • Implementaciones de HDTV para Windows Media Center.
  • Requisitos de accesibilidad.

Información adicional

Lo ideal es que el juego tenga como valor predeterminado la relación de aspecto nativa de la pantalla. Sin embargo, obtener esta información de forma fiable puede ser un reto, por lo que como solución más general el juego puede asumir que el escritorio se está ejecutando en la relación de aspecto nativa. La resolución de escritorio se puede obtener llamando a EnumDisplaySettings con ENUM_REGISTRY_SETTINGS.

Para obtener más información, consulte las secciones Relación de aspecto y Pantalla panorámica del artículo de DirectX Introducción a la experiencia de 10 pies para desarrolladores de juegos de Windows.

1.6 Compatibilidad con el inicio desde Windows Media Center

[Este requisito se ha retirado.]

1.7 Compatibilidad con Direct3D

Requisito

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

Análisis razonado

La arquitectura de gráficos principales de Windows Vista y Windows 7 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. Consulte Presentación de Juegos para Windows S.1. Requerir Direct3D 10 o Direct3D 11 es totalmente compatible con el requisito 1.7.

1.8 Habilitación de alta compatibilidad con 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 la resolución de pantalla de 1600 1200) en Windows Vista y Windows 7.

Normalmente, esto requiere que el ejecutable del juego declare que es compatible con PPP. Esto se logra mediante la inserción de un elemento de manifiesto: <dpiAware>true<dpiAware> .

Análisis razonado

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 de alguna forma desde Windows XP, rara vez lo habilitan los clientes o los OEM. En la actualidad, más de la mitad de todas las pantallas de 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 de manifiesto es fácil de hacer con Visual Studio 2005 y 2008; cree un archivo denominado dpiaware.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, en Visual Studio, agregue dpiware.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 dpiaware.manifest. Busque Habilitar reconocimiento de PPP expandiendo Propiedades de configuración y Herramienta de manifiesto y, a continuación, seleccionando Entrada y salida&.

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 pantalla. La virtualización de PPP hace que estos modos de visualización de pantalla completa aparezcan recortados y el reconocimiento de PPP evitará estos problemas. Para obtener más información, consulte Escritura de aplicaciones Win32 con reconocimiento de PPP.

Seguridad y compatibilidad

Resumen de los requisitos de seguridad y compatibilidad

Ventajas para los clientes

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

2.1 Seguimiento de 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>

Según el requisito 1.2, el juego principal y el ejecutable de ejecución automática 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 el 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).

Análisis razonado

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 contenga 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 de manifiesto de 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 estos manifiestos.

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

2.2 Compatibilidad con versiones de Windows 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 basarse en ningún componente de 16 bits.
  • Si el juego depende de los controladores en modo kernel para la operación, 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.

Análisis razonado

Muchos usuarios de Windows Vista y Windows 7 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, consulte Programación de 64 bits para desarrolladores de juegos.

2.3 Firma de archivos

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 su juego usa Windows Installer, los archivos de paquete del instalador (.msi archivos) deben estar firmados.

Análisis razonado

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

Información adicional

Para obtener más información, consulte Firma con Authenticode para desarrolladores de juegos.

Si su juego usa Windows Installer, 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 del 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 Firma de 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 Windows Hardware Quality Labs (WHQL) o del programa Firma de confiabilidad de controladores (DRS).

Análisis razonado

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 según el requisito 2.2.

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

2.5 Comprobación de versiones adecuada

Requisito

Los juegos no deben dejar de funcionar en futuros sistemas operativos, como indican los cambios en el número de versión de Windows, a menos que el Contrato de licencia de usuario final prohíba su uso en futuros sistemas operativos. Si el juego debe fallar, debe hacerlo con elegancia mostrando un mensaje apropiado al usuario.

Si se realizan comprobaciones de versiones de 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 para el 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).

Análisis razonado

Cuando los usuarios de Windows actualicen sus sistemas operativos, no se les debería impedir jugar a los juegos actuales simplemente porque el número de versión de Windows haya aumentado. Los comprobadores de versiones mal escritos siguen creando problemas a programas que, por lo demás, funcionan bien en versiones más recientes de Windows o simplemente con la adición de un Service Pack de Windows.

La frágil lógica de comparación de comprobación de versiones para el tiempo de ejecución de DirectX ha creado numerosas instalaciones fallidas 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 habitual ver que los instaladores comprueben si hay una versión mínima del sistema operativo. Sin embargo, esta comprobación debe realizarse con cuidado para garantizar que se comprueba si es mayor o igual que, en lugar de una simple igualdad, con lo que se bloquea a 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, consulte Instalación de DirectX para desarrolladores de juegos.

Se recomienda que los juegos compatibles con 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 Compatibilidad con sesiones simultáneas de usuario

Requisito

Los juegos que se basan en gráficos 3D no están obligados a funcionar a través de una conexión de escritorio remoto, pero el usuario debe recibir un aviso cuando el juego falle.

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

  • Los juegos no deben bloquear el uso de sesiones simultáneas de usuario.
  • 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 Deshabilitación de las teclas de método abreviado en juegos.

Análisis razonado

Los usuarios de Windows deben poder ejecutar sesiones simultáneas sin conflictos ni interrupciones. Este es un escenario común para un equipo 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, llame 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 se acaba el tiempo del usuario. Consulte el requisito 1.2 para obtener más información.

2.7 Compatibilidad con 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 cualquier campo de entrada de usuario que se use para crear nombres de archivo o rutas de acceso.

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

Análisis razonado

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 para los clientes

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 simplificada en la interfaz de usuario de configuración implementando lo siguiente:

  • Muestra un máximo de un mensaje 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 el iniciador tras la instalación correcta, sin avisos adicionales. Si lo desea, se puede proporcionar una opción de instalación personalizada para 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 protegerla mediante comprobaciones de versión del componente.
  • Proporcione eliminación a través de Programas y características en Panel de control tanto para la aplicación del 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 quiten todos los archivos instalados y que se borren todas las configuraciones (por ejemplo, entradas de lista de excepciones de firewall y claves del Registro). No se deben quitar los componentes redistribuidos del sistema operativo.
  • Si el juego requiere que se agreguen excepciones al Firewall de Windows, el proceso de configuración puede pedir a los usuarios que informen de que este cambio es 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 Seguimiento de las directrices de control de cuentas de usuario.

Análisis razonado

La instalación sencilla es una filosofía de desarrollo de juegos centrada en Windows diseñada para simplificar y simplificar el proceso a veces tedioso y confuso de instalar juegos en equipos que ejecutan sistemas operativos Windows. 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 equipos Windows.

Los objetivos clave son:

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

Algunas instalaciones tradicionales tienen indicaciones 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 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, consulte 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 las 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 suponer que se ejecuta en el mismo contexto que el usuario. Las ubicaciones específicas del usuario serán diferentes del instalador y el jugador 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, independientemente del proceso de instalación.

El cuadro de diálogo 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 insertado que designe el nivel de ejecución necesario, según el requisito 2.1, Seguimiento de 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.

Análisis razonado

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 amplio 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, consulte 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, que es un riesgo de seguridad potencial. En su lugar, un cargador de arranque de instalación debe iniciar el juego después de volver de una invocación correcta del instalador. Para obtener más información, consulte el artículo de MSDN Magazine Teach Your Apps to Play Nicely with Windows Vista User Account Control.

3.3 Instalación en las 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 ejecute por primera vez, no durante la instalación.

Análisis razonado

Los usuarios deben tener la flexibilidad de instalar aplicaciones en las que 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 los creó solo puede acceder a los archivos cifrados.

3.4 Instalación correcta de los recursos de Windows

Requisito

Las aplicaciones no deben intentar instalar archivos ni claves del Registro protegidas por Windows Resource Protection (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.

Análisis razonado

Windows Resource Protection (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 sean predecibles.

Información adicional

WRP es el sucesor de Windows File Protection, 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 ciertas 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 entorno de ejecución de DirectX se implementa con un juego, consulta el artículo de DirectX 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 a partir de 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 los paquetes de Windows Installer deben contener una opción para cerrar automáticamente las aplicaciones e intentar reiniciarlas una vez completada la instalación.

Análisis razonado

Reiniciar el sistema después de una instalación es una molestia para los usuarios y suele ser innecesario.

Información adicional

Para obtener más información, consulte Uso de Windows Installer con el Administrador de reinicio.

3.6 Uso correcto del control de versiones de archivos

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 genere o que se compartan mediante aplicaciones que no genere.

Análisis razonado

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 provocar la pérdida de actualizaciones y correcciones que ya se han aplicado.

3.7 Compatibilidad con ejecución automática [requisito condicional]

Requisito

En el caso de los juegos distribuidos en CD, DVD u otros medios extraíbles compatibles con la ejecución automática, 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 de ejecución automática.

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

La aplicación de ejecución automática no debe solicitar elevación (es decir, debe tener asInvoker en el manifiesto, según el 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.

Análisis razonado

La ejecución automática 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 vaya a 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 deberían usar idealmente la característica de ejecución automática o continuar la instalación sin pedir al usuario que pulse una tecla o realice otra acción.

Al crear un programa de ejecución automática, asegúrese de que todos los componentes necesarios estén presentes en las instalaciones nuevas de Windows. Las aplicaciones típicas dependen de las tecnologías instaladas por la instalación, pero la ejecución automática 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. Por lo tanto, el programa de ejecución automática 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 anteriores a 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 de ejecución automática 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 la ejecución automática, consulte Ejemplo de ejecución automática.

Fiabilidad

Resumen de los requisitos de seguridad y compatibilidad

Ventajas para los clientes

Estos requisitos hacen que una aplicación sea más confiable al minimizar el número de 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 Eliminación de 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 with LPARAM = ENDSESSION_CLOSEAPP (0x1)

Las aplicaciones GUI deben responder (TRUE) inmediatamente en 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.

Análisis razonado

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

Información adicional

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

Para obtener más información sobre el Administrador de reinicio, consulte Acerca del Administrador de reinicio.

4.2 Eliminación de 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

Análisis razonado

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

Información adicional

Para obtener más información sobre Application Verifier, consulte Application Verifier y Uso de Application Verifier en el ciclo de vida de desarrollo de software.

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 antipiratería y antitrampa pueden interferir con la ejecución de AppVerifier. Por lo tanto, estas pruebas deben realizarse sin las tecnologías antipiratería y antitrampas activadas.

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. Los errores se seguirán detectando, pero pueden ser más difíciles de rastrear si usa solo PageHeap parcial.

Si usa las pruebas relacionadas con UAC/LUA en el comprobador de aplicaciones para cumplir los requisitos de Control de cuentas de usuario 2.1 y 3.2, debe usar el Analizador de usuarios estándar para revisar los resultados. También hay muchas otras pruebas útiles proporcionadas por el comprobador de aplicaciones 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 del 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 rastrear 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 el informe de errores de Windows, los juegos deben cumplir los siguientes requisitos:

  • Los juegos deben controlar solo las excepciones conocidas y esperadas. El informe de errores de Windows no debe deshabilitarse. Si un error como una infracción de acceso aparece en un juego, debe permitir que el informe de errores de Windows notifique el bloqueo.
  • Todos los archivos ejecutables (por ejemplo, archivos .exe o 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.

Análisis razonado

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 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 funcionalidad personalizada de soporte técnico e informes, pero deben pasar cualquier error a las funciones ReportFault o WerReportSubmit.

Para comprobar la información de la versión de archivo adecuada, vea las propiedades del archivo en la interfaz de usuario de escritorio de Windows y compruebe 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 que se generan al usar este servicio, consulte el artículo de DirectX Análisis de volcado de memoria.

Mando común de Xbox 360 para la terminología de Windows

Nombre Descripción
Un El botón A.
B El botón B.
ATRÁS El botón Atrás.
Botón superior (derecha/izquierda) El botón situado en la parte superior derecha y el borde izquierdo del mando. Equivalente a un botón superior.
mando de dirección Mando de dirección del mando.
Cruceta Abreviatura aceptada del mando de dirección.
DP Abreviatura del mando de dirección y etiqueta del mando.
RB, LB Abreviaturas del botón superior derecho e izquierdo y etiquetas del mando.
RS, LS Abreviaturas del stick derecho e izquierdo y etiquetas del mando.
RT, LT Abreviaturas del desencadenador superior derecho e izquierdo y etiquetas del mando.
RSB, LSB Abreviaturas del stick derecho e izquierdo y etiquetas del mando.
START El botón Iniciar.
Stick (derecho/izquierdo) El stick del mando. Anteriormente, la palanca de control.
Botón de stick (derecho(izquierdo) El botón del stick del mando. Anteriormente, el botón de la palanca de control.
Desencadenador (derecho/izquierdo) Desencadenador del mando.
Vibración Comentarios del juego producidos por el motor del mando. No usa estruendo.
X El botón X.
Y El botón Y.
Mando Xbox 360 para Windows El controlador para juegos 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 para juegos

Introducción

Para que los juegos puedan acogerse al programa Juegos para Windows, deben cumplir una lista de requisitos técnicos. Los componentes de terceros que se envían con un título (archivos ejecutables, archivos DLL, controladores, etc.) también deben cumplir estos requisitos para que el juego pueda acogerse. 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 de juego/producción deben revisar el documento completo de requisitos técnicos de Juegos para Windows, 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 compatibles con 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 ayudar a los desarrolladores que trabajan con aplicaciones nativas x64 de 64 bits, proporcione versiones nativas de 32 y 64 bits de sus bibliotecas. La versión de 32 bits debe ser compatible con 64 bits por 2.2. Las bibliotecas para aplicaciones de 32 bits no deben asumir que el bit alto de cualquier dirección de 32 bits está sin usar para admitir su uso dentro de aplicaciones x86 LARGEADDRESSAWARE.

  • Si proporciona encabezados de código nativo (C/C++), use la sintaxis de atributo Standard Annotation Language (SAL) para decorar las rutinas de API públicas. Esto permitirá a los usuarios de la biblioteca obtener la máxima ventaja de usar el análisis de código estático (/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 de 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 las 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 redes, 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 el Explorador de juegos 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 van más allá de ofrecer una experiencia de juego sólida en equipos Windows. Al implementar estas características, los juegos pueden agregar más entusiasmo a la experiencia del usuario en las plataformas Windows más recientes.

Los títulos de Juegos para Windows deben cumplir todos los requisitos técnicos enumerados en este artículo, pero las características de presentación son opcionales. Estos títulos pueden 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 al requisito técnico de Juegos para Windows 1.7.

La tecnología Direct3D 10level9 se puede usar para admitir el modelo de sombreador 2.0/3.0 hardware de vídeo de clase 9 de Direct3D 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.

Análisis razonado

La API de Direct3D 11 se basa en la infraestructura del modelo de controladores de pantalla de Windows (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 textura y un lenguaje de sombreador más flexible. Direct3D 11 proporciona compatibilidad unificada con 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:

  • Elimina todas las operaciones de función fija en favor de los sombreadores programables.
  • Actualiza todos los sombreadores existentes a la nueva sintaxis de Shader Model 4.x/5.
  • Actualiza la administración de recursos para admitir el nuevo modelo de vista.
  • Convierte todos los recursos para usar una nueva lista de formatos disponibles.
  • Actualiza el control de estado de representación para usar bloques de estado inmutables y vuelve a procesar 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 de contenido mejorado:

  • Aprovechamiento de las características de hardware existentes de Direct3D 10, como sombreador de geometría, salida de secuencia, matrices de texturas y formatos de textura comprimidos BC4/BC5.
  • Aprovechamiento de las características de hardware existentes de Direct3D 10.1, como modos independientes de combinación por destino de representación, lectura de profundidad de MSAA, acceso al sombreador de MSAA por muestra, matrices de mapas de cubo y representación en formatos comprimidos por bloque (BC).
  • Implementación de algoritmos avanzados de GPU con sombreador de proceso con CS4.x en tarjetas de vídeo de 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, consulte Presentación de Juegos para Windows S.3.
  • Uso de nuevas características de hardware de vídeo de clase Direct3D 11, como la teselación de hardware con sombreadores de casco y dominio, sombreador modelo 5.0 HLSL características de hardware de sombreador de HLSL BC6HBC7 formatos de textura comprimidos y vinculación del sombreador dinámico.

Las técnicas que se pueden implementar con Direct3D 9 (en gran medida a través de un alto coste de CPU) se pueden descargar a 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 debería 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 la 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 permanecer en 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.

Análisis razonado

La tecnología x64 proporciona funcionalidades de direccionamiento de 64 bits para los mercados de consumidores y servidores que incluyen 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 actuales y futuros.

Windows XP Professional x64 Edition fue el primer sistema operativo 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 consumidor 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 pasar a la tecnología x64 aumenta considerablemente los niveles de detalle compatibles.

La compatibilidad 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 amplio de E/S asignadas a memoria sin preocuparse por los problemas de agotamiento del espacio de direcciones de la máquina virtual que se produce 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, eliminar 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 hasta 4 GB de RAM para aplicaciones con reconocimiento de 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 forma extremadamente útil de proporcionar ventajas de escalado adicionales en versiones x64 de Windows para aquellos que no implementan completamente este requisito de presentación.

Para obtener más información, consulte Programación de 64 bits para desarrolladores de juegos y RAM, VRAM y más RAM: los juegos de 64 bits ya están aquí en el sitio web para desarrolladores de juegos.

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.

S.3 Aprovechamiento de procesadores de varios núcleos

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 un rendimiento mejorado.

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

Análisis razonado

El crecimiento continuo en el rendimiento de las CPU ha cambiado de las mejoras de velocidad de reloj a la adición de núcleos computacionales. Las hojas de ruta de AMD e Intel se basan en diseños escalables y de varios núcleos. Todas las plataformas de juegos de última generación tienen CPU multicore 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 tampoco se escalará a medida que el número de núcleos de CPU en uso común aumente 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 una devolución si el coste de la comunicación y la sincronización de subprocesos se mantienen en la comprobación. El escalado basado en características puede demostrar 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, consulte Codificación 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 resulta útil para lograr una escalabilidad de varios núcleos en la representación y carga de recursos gráficos. Consulte Presentación de Juegos para Windows S.1.

Tenga en cuenta que el uso del rdtsc de instrucciones de CPU directamente, en lugar de usar las API de Windows para calcular el tiempo en sistemas multicore, puede provocar problemas en algunas configuraciones de hardware y sistema operativo; consulte Control del tiempo de juego y procesadores de varios núcleos en los artículos de DirectX.

S.4 Compatibilidad con Juegos para Windows - LIVE

Juegos para Windows - LIVE ya no proporciona soporte para Windows XP.

S.5 Compatibilidad con Windows Touch

Requisito

Los juegos compatibles con Windows Touch se pueden jugar con gestos o movimientos táctiles 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.

La habilitación de la función táctil no debe impedir el uso del mouse o el mando común, sujeto al requisito técnico 1.4.

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

Análisis razonado

Las pantallas compatibles con varios toques para los 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 a la función multitáctil a través de los mensajes de WM_TOUCH, en combinación con la función RegisterTouchWindow. Véase también la API de 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 Compatibilidad con color alto

Requisito

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

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

Análisis razonado

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 de tarjetas de vídeo ha sido el factor de limitación. Las GPU modernas, incluida la mayoría del hardware de la clase 9 de Direct3D y todo el hardware direct3D 10 y mejor hardware, tienen hardware de exploración capaz de al menos 10 bits por canal y la funcionalidad de hardware está establecida para crecer a 16 bits por canal de color en el futuro. Los sistemas de interconexión de TV HD (HDMI, DisplayPort) se han diseñado para manejar más de 8 bits por canal, y VGA analógico ya llevará estas señales.

Información adicional

Tenga en cuenta que el color alto o el color Hi, históricamente hace referencia 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 hace tiempo que pasaron a True Color, que es el color de 24 bits, es decir, 8 bits por canal de color para rojo, verde y azul. Por color alto entendemos aquí una nueva generación de sistemas de visualización 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 el título, hay una serie de procedimientos recomendados que se deben seguir 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 títulos de Juegos para Windows.

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 fácil de migrar a prácticas de codificación modernas.
  • Use la versión de la biblioteca de vínculos dinámicos (DLL) de C Runtime, 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 autor o para el propio instalador).
  • Para el audio del juego, use 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 API heredadas y en desuso: DirectDraw, DirectSound, DirectPlay, capa de rendimiento de DirectMusic, DirectPlay Voice y Modo retenido de Direct3D. Tenga 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 aplicaciones nativas 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, consulte Prácticas recomendadas de seguridad 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
Windows SDKs
Directrices de control de cuentas de usuario
Requisitos de desarrollo de aplicaciones de Windows Vista para la compatibilidad con el control de cuentas de usuario
Portal para desarrolladores de DirectX
Centro para desarrolladores de Directx
Blog de Juegos para Windows y el SDK de DirectX
 Juegos para Windows y el SDK de DirectX
Artículos adicionales de DirectX
 Artículos técnicos de DirectX