Compartilhar via

Requisitos técnicos do Games for Windows: práticas recomendadas para jogos no Windows XP, Windows Vista, Windows 7 e Windows 8

  • Artigo

Este artigo fornece requisitos técnicos e práticas recomendadas para jogos executados no Windows. Criamos esses requisitos técnicos e práticas recomendadas principalmente para cobrir o Windows Vista e o Windows 7, bem como o sistema operacional Windows XP herdado. Essas práticas recomendadas também se aplicam geralmente a jogos Win32 de área de trabalho no Windows 8.

Este artigo contém estas seções:

Diferenças do Windows 8

Veja a seguir um resumo das principais diferenças ao aplicar esses requisitos técnicos e as práticas recomendadas ao Windows 8.

A interface do usuário do Gerenciador de Jogos não está visível

Todos os jogos registrados no Gerenciador de Jogos são exibidos como blocos na nova interface do Windows, mas muitos dos metadados associados ao título não estão mais visíveis. Você ainda usa a ferramenta Criador de Arquivos de Definição de Jogos (GDFMAKER.EXE), que agora está disponível no SDK (Software Development Kit) do Windows, para criar os metadados. Você também usa os mecanismos existentes para implantar os metadados. Continue testando seu registro do Gerenciador de Jogos usando o Windows 7 e verifique se o novo bloco da interface do usuário do Windows aparece quando você o instala no Windows 8 (consulte 1.1 Integração do Gerenciador de Jogos).

Para baixar o SDK do Windows 8, confira Downloads para desenvolver aplicativos da área de trabalho.

O registro com as APIs do Gerenciador de Jogos continua sendo o mecanismo para registrar seu jogo com os controles dos pais do Windows

Recomendamos que você execute a versão do SDK do Windows do GDFMAKER na versão lançada do Windows 8 para garantir que ele possa preencher todos os sistemas de classificação com suporte atualmente.

Observação

Esta versão do GDFMAKER requer o .NET 4.0.

Consulte 1.2 Suporte à segurança da família/controle dos pais.

Agora existem três opções para usar a API XINPUT, dependendo de seus requisitos

O XINPUT 1.4 está integrado ao Windows 8. Os aplicativos da Windows Store e os aplicativos Win32 da área de trabalho podem usar o XINPUT 1.4. Todas as versões do Windows podem usar o XINPUT 9.1.0 para controladores comuns simplificados, mas não há pacote de redistribuição com o XINPUT 9.1.0. Todas as versões do Windows também podem usar o XINPUT 1.3 versão SDK do DirectX existente, que requer o DirectSetup para implantação.

Consulte 1.4 Suporte ao controle comum do Xbox 360 para Windows.

Há suporte somente para um conjunto limitado de aplicativos Win32 da área de trabalho no Windows RT

Os jogos executados no Windows 7 podem e devem ser executados corretamente nas plataformas x86 e x64 do Windows 8.

Consulte 2.2 Suporte a versões do Windows x64.

Certifique-se de que todas as verificações do sistema operacional sejam feitas corretamente

A versão do sistema operacional Windows 8 é 6.2. O Windows 8 passa nos testes mínimos de qualidade atuais que recomendamos para a implantação de jogos.

O pacote de Redistribuição do Usuário Final do DirectX é executado com sucesso no Windows 8, bem como no Windows 7, para implantar D3DX9, D3DX10, D3DX11, XINPUT 1.3, XAUDIO 2.7, XACTEngine e assim por diante

No entanto, existe um problema conhecido com o DirectSetup em sistemas com apenas o .NET 4.0 instalado devido ao tratamento de implantação dos assemblies herdados do DirectX 1.1 gerenciado. Esse problema se aplica ao Windows 8, que vem com o .NET 4.5 por padrão, e aos novos computadores com Windows XP com o runtime do .NET 4.0 instalado. No entanto, esse problema não se aplica a nenhuma versão do .NET anterior ao .NET 4.0. Embora o Windows 8 tenha um comportamento de compatibilidade de aplicativos para resolver esse problema automaticamente (o que requer acesso à rede), recomendamos que os jogos que continuam a implantar o DirectSetup sejam atualizados para a versão atualizada do SDK do DirectX (junho de 2010) dos arquivos REDIST. Como sempre, se você usar o DirectSetup para seu título, reduza seu título ao conjunto mínimo necessário de CABs.

Consulte 3.4 Instalar os recursos do Windows corretamente.

Os jogos que exigem o runtime compatível com o .NET 2.0 (2.0, 3.0, 3.5) continuam a usar mecanismos de implantação existentes

Esses jogos disparam um comportamento de compatibilidade de aplicativos no Windows 8 para habilitar o runtime do .NET 3.5 automaticamente (o que requer acesso à rede). No entanto, recomendamos que os desenvolvedores do .NET mudem para o runtime do .NET 4.0.

Observação

Os assemblies herdados do DirectX 1.1 gerenciado não são compatíveis com o runtime do .NET 4.x.

Consulte 3.4 Instalar os recursos do Windows corretamente.

Não é recomendado o uso de um executor automático ou outra tecnologia de pré-instalação que dependa do .NET

Você pode supor que apenas tempos de execução compatíveis com .NET 2.0 (2.0, 3.0, 3.5) estão presentes no Windows Vista e no Windows 7. Apenas o runtime compatível com .NET 4.0 está presente no Windows 8 por padrão.

Consulte 3.7 Suporte à execução automática.

Há um Application Verifier atualizado para Windows 8

O SDK do Windows 8 inclui esse Application Verifier atualizado.

Consulte 4.2 Eliminar falhas do Application Verifier.

Informações Adicionais

Guia de compatibilidade do Windows 8 e do Windows Server 2012
Onde está o SDK do DirectX?

Games for Windows

Resumo dos requisitos dos jogos

Benefícios ao cliente

Os jogos de computador são uma experiência de entretenimento importante no Windows, mas as questões de facilidade de uso têm gerado frustração nos clientes ao longo dos anos. Tradicionalmente, os jogos são instalados como aplicativos, mas são usados mais como mídia de entretenimento (filmes ou músicas, por exemplo). Inovações, como o Gerenciador de Jogos, expõem os jogos de forma consistente e diferente dos aplicativos padrão. Essas inovações também conferem aos jogos o status de prioridade, ao lado de Música e Imagens. Os requisitos a seguir ajudam a garantir que o Windows Vista e o Windows 7 ofereçam uma experiência de jogo aprimorada, mais acessível e unificada. Ao mesmo tempo, garantem a compatibilidade com o Windows XP.

1.1 Integração do Gerenciador de Jogos

Requisito

O jogo deve estar visível no Gerenciador de Jogos (a pasta Jogos) no Windows Vista e no Windows 7. Quando selecionado, o jogo também deve exibir metadados corretos, que incluem editor, desenvolvedor, data de lançamento, versão, pontuações do Índice de Experiência do Windows, classificação (se aplicável) e hiperlinks associados.

Se o jogo for distribuído digitalmente por meio de um serviço de jogos online, o provedor de serviços também deverá aparecer no Gerenciador de Jogos. Para garantir o tratamento adequado do provedor e permitir o uso de feeds RSS, a versão 2 do esquema para arquivos de definição de jogo (GDFs) deve ser usada. (Para obter mais informações sobre GDFs, consulte Informações adicionais.)

Além disso, os instaladores de jogos devem observar as seguintes regras quando executados no Windows Vista e no Windows 7:

  • A instalação não deve criar um atalho para iniciar o jogo na área de trabalho, no menu Iniciar ou em qualquer outro local.
  • Tarefas e atalhos para remoção não devem ser criados.
  • Os usuários devem ser capazes de remover o jogo usando Programas e Recursos no Painel de Controle no Windows Vista e no Windows 7, ou Adicionar ou Remover Programas no Painel de Controle no Windows XP.

No Windows XP e em versões anteriores do Windows, o instalador do jogo é gratuito para criar grupos de programas, ícones da área de trabalho ou atalhos conforme necessário.

Fundamento

O Gerenciador de Jogos do Windows é semelhante em conceito às pastas Meus Documentos ou Minhas Imagens do Windows XP. A ideia é centralizar conteúdo semelhante em um só lugar e permitir uma organização mais fácil e atividades sensíveis ao contexto. O Gerenciador de Jogos estende o conceito Meus Documentos ou Minhas Imagens, permitindo uma organização e controle mais avançados sobre os jogos. O Gerenciador de Jogos permite que os jogadores visualizem, organizem e interajam com todos os jogos instalados em seus sistemas. Também permite que os editores de jogos comuniquem informações importantes do jogo com mais eficiência. O sistema é orientado por dados, tornando mais fácil para um editor de jogos atualizar as informações do jogo ao longo da vida útil do produto.

Informações adicionais

A integração com o Gerenciador de Jogos requer que você crie um arquivo de definição de jogo (GDF), que é um arquivo de texto XML inserido em um arquivo binário (um arquivo executável ou uma DLL) como um recurso, juntamente com um ícone do Windows. O jogo deve então ser registrado no Gerenciador de Jogos. O GDF também permite a exposição de informações fornecidas, como título do jogo, editor, desenvolvedor, links para sites e tarefas opcionais. Observe que as tarefas de suporte podem ser apenas links para sites, mas as tarefas de reprodução também podem ser usadas para tarefas de suporte opcionais.

O Gerenciador de Jogos pode usar uma imagem de bitmap em miniatura, mas é recomendável que, em vez disso, você forneça um recurso de ícone do Windows com ícones grandes (256 256). O recurso de ícone deve incluir tamanhos de imagem de 256 256 48 48, 32 32 e 16 16 em profundidades de cor de 24 bits (True Color) e 8 bits (256). O editor de ícones fornecido no Visual Studio 2008 e 2010 oferece suporte a esses formatos de ícones grandes, bem como o IconWorkshop Lite.

Detalhes sobre a integração com o Gerenciador de Jogos do Windows são fornecidos no DirectX SDK. O SDK do DirectX inclui um editor GDF (arquivo de definição de jogo), bem como um GDF de exemplo incluído em GDFExampleBinary, um exemplo. Outro exemplo, GameUxInstallHelper, fornece rotinas para integrar a funcionalidade necessária aos sistemas de instalação existentes. O Validador de Arquivo de Definição de Jogo (gdftrace.exe) fornece suporte de depuração para avaliar um GDF. Consulte também "Integração do Gerenciador de Jogos do Windows" na documentação do SDK do DirectX para C++.

O Windows 7 apresenta suporte para a segunda versão de um esquema para arquivos GDF. A nova versão inclui um método simplificado para criar tarefas de jogo e suporte para notificações de atualização, provedores de serviços de jogos, estatísticas de jogos e feeds RSS para provedores de serviços de jogos. A versão mais recente do GameUxInstallHelper lida com todo o registro e suporte herdado necessários para usar um arquivo GDF versão 2 com o Windows Vista. Use as ferramentas e o código de exemplo do SDK do DirectX de agosto de 2009 ou posterior. Recomenda-se usar um arquivo GDF versão 2 para habilitar o suporte a feeds RSS, estatísticas de jogos e notificações de atualização. Além disso, consulte os exemplos ProviderGDFExampleBinary e GameStatisticsExample.

No Windows Vista Business Edition, Windows 7 Professional Edition e Enterprise Edition do Windows Vista e Windows 7, o link Jogos no menu Iniciar está oculto. O Gerenciador de Jogos ainda está disponível no menu Iniciar clicando em Todos os Programas e, em seguida, em Jogos.

Para aplicativos associados que estão instalados com seu jogo, mas que não são jogos em si, você pode criar grupos de programas, atalhos e ícones da área de trabalho do menu Iniciar em todas as versões do Windows, incluindo Windows Vista e Windows 7. Esses aplicativos associados devem atender aos requisitos aplicáveis do Games for Windows. Para obter detalhes, consulte Diretrizes para produtos de middleware de jogos. Os serviços de jogos são incentivados a se registrar no Gerenciador de Jogos como um Provedor de Jogos para Windows 7. 1

1.2 Suporte à segurança da família/controle dos pais

Requisito

Os jogos devem oferecer suporte total ao Windows Proteção para a Família aderindo às seguintes regras:

  • Os jogos não devem exigir que o usuário tenha credenciais administrativas para jogar. A instalação, a aplicação de patches e a remoção podem exigir credenciais administrativas, sujeitas aos requisitos da seção 3. (Relacionado a isso está o requisito 2.1, Seguir as diretrizes de controle de conta de usuário.)
  • Os jogos classificados por conselhos de classificação compatíveis com Windows, como ESRB e PEGI, devem incluir as informações de classificação atribuídas em seu arquivo de definição de jogo (GDF). Todos os dados de classificação disponíveis devem ser incluídos em todas as versões localizadas do GDF, bem como na versão neutra em termos de linguagem.
  • Os jogos devem listar seus executáveis no GDF para fornecer uma boa experiência do usuário para Restrições Gerais de Aplicativos, a menos que o jogo use uma tecnologia antipirataria que crie executáveis nomeados aleatoriamente no runtime.
  • Os jogos devem chamar o método VerifyAccess da interface do Gerenciador de Jogos durante a inicialização, se disponível, e sair se retornar *pfHasAccess como FALSE.

Fundamento

Todos os jogos devem ser executados dentro do contexto de uma conta de usuário padrão para permitir que contas controladas pelo Controle dos Pais do Windows joguem. Os pais querem a capacidade de monitorar e controlar o acesso de seus filhos aos jogos. Além disso, vários grupos da indústria, do governo e de defesa querem melhores formas de permitir que os pais monitorem e controlem os jogos aos quais seus filhos são expostos. Em conjunto com a arquitetura oferecida pelo Gerenciador de Jogos, a Microsoft fornece aos pais essa capacidade por meio dos Controles dos Pais do Windows.

Mesmo para jogos que não participam de um programa de classificação, exigir privilégios elevados cria uma experiência de jogo ruim para a maioria das contas de usuário. Isso acontece principalmente se o Controle dos Pais estiver habilitado, o que exigiria que os pais digitassem a senha do administrador toda vez que o jogo fosse iniciado.

O sistema de Controle dos Pais do Windows permite que os pais selecionem as classificações que acreditam ser adequadas para seus filhos. Os Controles dos Pais são compatíveis com muitos dos sistemas de classificação em todo o mundo. Os Controles dos Pais também permitem que os pais restrinjam o acesso a jogos com base em Descritores de Conteúdo (se o sistema de classificação aplicável os suportar) e permitam ou não o acesso a jogos individuais.

A escolha padrão do sistema de classificação dos Controles dos Pais do Windows é baseada na configuração de localidade do sistema, mas pode ser modificada pelo usuário em Opções Regionais e de Idioma em Painel de Controle. Portanto, todos os idiomas suportados devem fornecer todos os dados de classificação disponíveis para que o usuário possa selecionar qualquer quadro de classificação que quiser.

Informações adicionais

Os jogos sem classificação ainda precisam atender aos requisitos para oferecer suporte ao jogo como usuário padrão e chamar VerifyAccess. Esses jogos são definidos como padrão na categoria Sem classificação, exibem o texto "Nenhuma classificação fornecida" no Gerenciador de Jogos e estão sujeitos à configuração Restrições de jogos em Controle dos Pais para jogos sem classificação. A configuração padrão Restrições é Permitir.

As informações de classificação no GDF serão ignoradas se o binário contido não estiver devidamente assinado pelo Authenticode. Consulte o requisito 2.3.

O Editor de Arquivos de Definição de Jogo no SDK do DirectX inclui todos os sistemas de classificação com suporte e replicará corretamente essas informações para todas as versões localizadas do GDF, bem como para uma versão neutra em termos de idioma. A ferramenta GDFTrace decodificará e verificará todas as informações de classificação presentes. Use a versão de agosto de 2009 ou posterior dessas ferramentas.

Geralmente, o GDF de um provedor de jogos não contém informações de classificação e está sujeito às configurações de conteúdo não classificado.

Sistema operacional Sistemas de classificação compatíveis
Windows Vista
  • CERO (Japão)
  • ESRB (EUA)
  • OFLC (Austrália)
  • PEGI (Europa)
  • PEGI Finlândia (obsoleto)
  • PEGI Portugal
  • PEGI/BBFC (Reino Unido)
  • USK (Alemanha)
Windows Vista com um service pack Os service packs para Windows Vista adicionam suporte para o seguinte:
  • GRB (Coreia do Sul)
  • Descritores de conteúdo variantes "leve" de ESRB
Windows 7 O Windows 7 oferece suporte aos sistemas de classificação com suporte do Windows Vista e adiciona suporte para o seguinte:
  • CSRR (Taiwan)
Windows 8 O Windows 8 oferece suporte aos sistemas de classificação anteriores e adiciona suporte para o seguinte:
  • COB-AU (Austrália)
  • DJCTQ (Brasil)
  • PFB (África do Sul)
  • OFLC-NZ (Nova Zelândia)
O Windows 8 descontinua o suporte para os seguintes sistemas, agora obsoletos:
  • PEGI-FI (Finlândia)
  • OFLC (Austrália)

Observação

Qualquer título que inclua novos descritores de conteúdo ESRB do Service Pack 1 (SP1) do Windows Vista será exibido como Sem classificação no Windows Vista sem um service pack.

Os dados de classificação mais recentes são ignorados em versões de sistemas operacionais sem suporte para eles. A variante PEGI (Finlândia) agora está obsoleta em favor do sistema de classificação padrão PEGI (Europa). O sistema OFLC agora está obsoleto em favor do COB-AU para a Austrália.

Para obter mais informações sobre como tornar um jogo compatível com privilégios de usuário padrão, consulte o artigo Controle de conta de usuário para desenvolvedores de jogos do DirectX.

Consulte o requisito 1.1 para obter mais detalhes sobre o arquivo de definição de jogo (GDF).

1.3 Suporte a jogos salvos avançados

[Este requisito foi retirado]

1.4 Suporte ao controle comum do Xbox 360 para Windows [requisito condicional]

Requisito

Os jogos que oferecem suporte a controladores de gamepad devem oferecer suporte ao controlador Xbox 360 para Windows usando a API XInput. Se os periféricos DirectInput também tiverem suporte, o DirectInput também poderá ser usado. No entanto, o XInput deverá ser a API padrão se um dispositivo compatível com o Xbox 360 for usado.

Todas as referências a gatilhos e botões comuns do controlador devem usar os nomes do Xbox 360. Consulte a lista Terminologia do controle comum do Xbox 360 para Windows para obter detalhes.

A vibração do controle deve ser desligada quando o jogo estiver pausado ou suspenso.

O controle do mouse/teclado não pode ser totalmente desabilitado em nenhum momento. No mínimo, uma opção para retornar aos menus do jogo deve estar disponível.

Fundamento

Esse requisito dá aos jogadores a opção de escolher usar o controle do Xbox 360 ou o teclado e o mouse, dependendo de qual método de entrada é a interface mais natural e intuitiva.

Informações adicionais

Este requisito não se aplica a jogos que usam apenas o mouse e/ou o teclado.

Recomendamos que a navegação do menu seja implementada para usar os botões do controlador padrão amplamente aceitos:

  • A - Aceitar
  • B - Cancelar
  • Iniciar - Aceitar ou pausar
  • Voltar - Cancelar, voltar uma tela ou subir um nível de menu

Para obter mais informações, consulte XInput.

O tópico XInput e DirectInput aborda problemas com o uso das duas APIs ao mesmo tempo.

Recomenda-se que o DirectInput não seja usado para implementar controles de teclado ou mouse. Os controles de teclado e mouse só devem ser implementados usando mensagens do Windows e APIs do Win32. Para obter detalhes sobre como obter informações de movimento do mouse de alta resolução sem usar o DirectInput, consulte Aproveitando o movimento do mouse em alta definição.

1.5 Suporte a várias proporções e resoluções

Requisito

O jogo deve suportar pelo menos as seguintes proporções e resoluções de tela associadas:

  • 4:3 normal (800 600 ou 1024 768)
  • Tela panorâmica 16:9 (1280 720)
  • Tela panorâmica 16:10 (1152 720 ou 1680 1050 ou 800 480)

Para configuração e detecção de resolução de tela, o jogo deve seguir as seguintes regras:

  • O jogo usa a resolução da área de trabalho do dispositivo de exibição por padrão, se for uma resolução compatível. A proporção da área de trabalho deve ser usada como critério de pesquisa se o jogo escolher uma resolução padrão diferente.
  • O jogo deve solicitar que o usuário confirme as novas configurações de exibição quando uma alteração for feita. Se o usuário não aceitar em 15 segundos, a exibição deverá retornar à configuração anterior.
  • O jogo não deve esticar pixels ou centralizar uma janela de renderização 4:3 para oferecer suporte a proporções de tela panorâmica. No entanto, o formato letterboxing é aceitável.

Fundamento

Com a área de trabalho 3D do Windows, não é possível considerar uma proporção ou resolução específica devido aos seguintes fatores:

  • Suporte para exibições com alto nível de detalhes.
  • Aumento da participação de mercado de monitores de tela panorâmica.
  • Implantações de HDTV para o Windows Media Center.
  • Requisitos de acessibilidade.

Informações adicionais

Idealmente, o padrão do jogo é a proporção nativa da exibição. No entanto, obter essas informações de forma confiável pode ser um desafio. Portanto, como uma solução mais geral, o jogo pode considerar que a área de trabalho está sendo executada na proporção nativa. A resolução da área de trabalho pode ser obtida chamando EnumDisplaySettings com ENUM_REGISTRY_SETTINGS.

Para obter mais detalhes, consulte as seções Proporção e Tela panorâmica do artigo Introdução à experiência dos 3 metros para desenvolvedores de jogos do Windows do DirectX.

1.6 Suporte ao lançamento a partir do Windows Media Center

[Este requisito foi retirado.]

1.7 Suporte Direct3D

Requisito

Se o jogo usar Direct3D, a versão mínima com suporte deverá ser Direct3D 9 e Direct3D deverá ser o renderizador padrão selecionado.

Fundamento

A arquitetura gráfica principal do Windows Vista e do Windows 7 foi projetada em torno do Direct3D. O Direct3D 8 e versões anteriores têm suporte pelo remapeamento de interfaces herdadas.

É altamente recomendável o uso de versões do Direct3D mais recentes que o Direct3D 9. Consulte a Demonstração do Games for Windows S.1. Exigir Direct3D 10 ou Direct3D 11 é totalmente compatível com o requisito 1.7.

1.8 Habilitar reconhecimento de DPI alto

Requisito

Os jogos e seus instaladores devem ser executados corretamente, sem problemas visuais, quando o dimensionamento de pontos por polegada (DPI) estiver habilitado (testado com 144 DPI para dimensionamento de 150% na resolução de tela de 1600 1200) no Windows Vista e no Windows 7.

Isso geralmente requer que o executável do jogo declare reconhecimento de DPI. Isso é feito incorporando um elemento de manifesto: <dpiAware>true<dpiAware> .

Fundamento

Monitores LCD de alta qualidade são comuns como telas de computador e apresentam melhor qualidade quando usados em suas resoluções nativas (geralmente 1280 1024, 1600 1200 e assim por diante). Os clientes que têm dificuldade em ler textos e ver imagens nessa resolução geralmente configuram seus computadores para uma resolução mais baixa e sofrem com artefatos visuais causados pelo dimensionamento do LCD. Em vez disso, os clientes podem deixar a resolução no tamanho nativo e alterar o DPI da exibição do Windows, aumentando assim a aparência do item e do texto sem sacrificar a qualidade da imagem.

Embora esse recurso esteja disponível de alguma forma desde o Windows XP, ele raramente é habilitado por clientes ou OEMs. Mais da metade de todos os monitores de computador hoje são configurados para uma resolução mais baixa do que a resolução nativa do monitor, com base no feedback dos clientes. O Windows 7 torna esse recurso muito mais visível para os clientes durante a configuração inicial e ao alterar as configurações de exibição, incentivando-os a usar o dimensionamento de DPI em vez de alterar a resolução da área de trabalho.

Informações adicionais

A função SetProcessDPIAware poderá ser usada, se chamada no início do código de inicialização do processo. É preferível adicionar ao manifesto para garantir que não haja condições de corrida com elementos de software (como DLLs) que possam ser inicializados antes que o ponto de entrada principal seja chamado. Observe que SetProcessDPIAware está presente apenas no Windows Vista e no Windows 7.

Adicionar o elemento manifesto é fácil com o Visual Studio 2005 e 2008. Crie um arquivo chamado dpiaware.manifest que contenha o seguinte texto:

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

Depois, dentro do Visual Studio, adicione dpiware.manifest ao projeto. Verifique se o Manifesto Inserido está definido como Sim nas propriedades do projeto. Observe que versões mais antigas da ferramenta de manifesto (Mt.exe) gerarão um aviso falso com os elementos de manifesto com reconhecimento de DPI Para resolver isso, atualize Mt.exe para a versão mais recente do SDK do Windows.

O Visual Studio 2010 inclui uma configuração nas propriedades do projeto, chamada Habilitar reconhecimento de DPI, que elimina a necessidade de um arquivo como dpiaware.manifest. Localize Habilitar reconhecimento de DPI expandindo Propriedades de configuração e Ferramenta de manifesto e selecionando Entrada e saída.

No Windows, o modo de exibição tradicional é definido como 96 DPI, o que era comum em monitores CRT.

Embora os aplicativos de tela inteira alterem a resolução de exibição, eles geralmente usam mensagens de janela e métricas ao configurar buffers e retângulos de exibição. A virtualização de DPI faz com que esses modos de exibição em tela inteira apareçam cortados, e declarar reconhecimento de DPI evitará esses problemas. Para obter mais informações, consulte Escrevendo aplicativos Win32 com reconhecimento de DPI.

Segurança e compatibilidade

Resumo dos requisitos de segurança e compatibilidade

Benefícios ao cliente

Os requisitos a seguir melhoram a segurança geral dos jogos e ajudam a garantir que funcionem com o Windows em diferentes arquiteturas, em diferentes configurações e em diferentes modos.

2.1 Seguir as diretrizes de controle de conta de usuário

Requisito

Cada arquivo executável (ou seja, cada arquivo que tem uma extensão .exe) deve conter um manifesto inserido que defina seu nível de execução incluindo a seguinte marcação:

            <requestedExecutionLevel>

De acordo com o requisito 1.2, o jogo principal e o executável de execução automática devem ter o nível de execução de asInvoker para oferecer suporte a contextos de usuário padrão.

Os arquivos de dados do usuário que têm associações de arquivo registradas no Explorador de Arquivos devem ser colocados em uma subpasta da pasta especificada por CSIDL_PERSONAL (também chamada Documentos ou Meus documentos). Todos os outros arquivos de dados do usuário devem ser armazenados em uma subpasta das pastas especificadas por CSIDL_LOCAL_APPDATA ou CSIDL_COMMON_APPDATA. (Esses diretórios estão ocultos por padrão para usuários individuais e para todos os usuários.)

Fundamento

A experiência do Windows de um usuário será mais segura se os aplicativos forem executados apenas com as permissões necessárias.

Informações adicionais

Se apenas alguns recursos em um aplicativo exigirem privilégios administrativos (por exemplo, um aplicativo que precisa configurar um firewall), o processo principal do aplicativo ainda deverá ser executado usando privilégios de usuário padrão. Os recursos que exigem privilégios administrativos devem ser movidos para um processo separado, como um instalador ou utilitário de configuração.

Se privilégios administrativos não forem necessários, o XML do manifesto incorporado deverá incluir o seguinte:

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

Se privilégios administrativos forem necessários, o XML do manifesto incorporado deverá incluir o seguinte:

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

Com o Visual Studio 2005, isso é facilmente inserido apenas adicionando um arquivo de manifesto (.manifest) que contém um dos blocos anteriores ao projeto e garantindo que Inserir manifesto esteja definido como Sim nas propriedades do projeto da Ferramenta de Manifesto. Para o Visual Studio 2008 e 2010, as propriedades do UAC podem ser definidas diretamente nas propriedades do projeto para o vinculador na página Arquivo de Manifesto. Observe que versões mais antigas da ferramenta de manifesto (Mt.exe) gerarão um aviso falso com os elementos de manifesto de UAC Para resolver isso, atualize Mt.exe para a versão mais recente do SDK do Windows.

Consulte o requisito 3.1 para obter detalhes sobre os casos especiais de instalação, aplicação de patches e remoção.

As DLLs (bibliotecas de vínculo dinâmico) não exigem esses manifestos.

Para obter mais informações sobre o Controle de Conta de Usuário, consulte Controle de conta de usuário para desenvolvedores de jogos.

2.2 Suporte a versões do Windows x64

Requisito

Para manter a compatibilidade com edições de 64 bits do Windows, os jogos devem atender aos requisitos a seguir.

  • Os títulos e instaladores de títulos não devem conter nenhum código de 16 bits ou depender de nenhum componente de 16 bits.
  • Se o jogo depender de drivers do modo kernel para operação, as versões x64 desses drivers deverão estar disponíveis. A configuração do jogo deve detectar e instalar os drivers e componentes adequados para as edições de 64 bits do Windows.

Fundamento

Muitos usuários do Windows Vista e Windows 7 executarão edições de 64 bits do sistema operacional ao longo da vida útil do produto. Portanto, é essencial que os aplicativos sejam compatíveis com esse sistema operacional.

Informações adicionais

O Windows no Windows 64 (WOW64) permite que o código de 32 bits seja executado em edições de 64 bits do Windows. Portanto, não é necessário que o aplicativo seja um código nativo de 64 bits em edições de 64 bits do Windows. O código de dezesseis bits não é executado em edições de 64 bits do Windows.

Manter a compatibilidade com o Windows XP Professional x64 Edition não é necessário, mas é altamente recomendável.

Para obter detalhes, consulte Programação de 64 bits para desenvolvedores de jogos.

2.3 Assinar arquivos

Requisito

Todos os arquivos de código executável (geralmente, arquivos com a extensão .exe ou .dll) devem ser assinados com um certificado Authenticode publicamente válido e devem ter uma URL de servidor de carimbo de data/hora válida para assinatura de produção.

Se o seu jogo usar o Windows Installer, os arquivos do pacote do instalador (arquivos .msi) deverão ser assinados.

Fundamento

A assinatura de um arquivo ajuda os usuários a decidir se devem confiar em um aplicativo e garante aos usuários que os arquivos não foram adulterados. Também permite que os aplicativos sejam executados corretamente em ambientes bloqueados.

Informações adicionais

Para obter detalhes, consulte Assinatura Authenticode para desenvolvedores de jogos.

Se o seu jogo usar o Windows Installer, recomendamos que você habilite o patch UAC/LUA, incluindo uma tabela MsiPatchCertificate. Para obter mais informações, consulte Aplicação de patch UAC (controle de conta do usuário).

Não recomendamos assinar arquivos de gabinete (.cab), a menos que sejam relativamente pequenos (menos de 100 MB).

2.4 Assinar drivers

Requisito

Qualquer driver de modo kernel instalado pelo jogo deve ser assinado com um certificado Authenticode válido publicamente.

Qualquer driver de dispositivo de hardware no modo kernel instalado pelo jogo deve ter uma assinatura da Microsoft, que pode ser obtida no WHQL (Windows Hardware Quality Labs) ou no programa DRS (Driver Reliability Signature).

Fundamento

Drivers mal escritos ou com malware podem afetar gravemente a estabilidade e a segurança de um sistema. Nas edições de 64 bits do Windows Vista e Windows 7, os drivers não assinados não são carregados. Essa política também pode ser habilitada para edições de 32 bits do Windows Vista e do Windows 7.

Informações adicionais

As versões nativas de 32 bits e 64 bits de todos os drivers do modo kernel são necessárias de acordo com o requisito 2.2.

Obtenha mais informações sobre os programas de assinatura de driver da Microsoft no Centro de Desenvolvimento de Hardware do Windows.

2.5 Executar verificação de versão adequada

Requisito

Os jogos não devem deixar de ser executados em sistemas operacionais futuros, conforme indicado por alterações no número da versão do Windows, a menos que o Contrato de Licença do Usuário Final proíba o uso em sistemas operacionais futuros. Se o jogo tiver de falhar, ele deverá fazê-lo normalmente, exibindo uma mensagem apropriada para o usuário.

Se forem feitas verificações de versão do Windows, as APIs de verificação de versão (GetVersionEx ou VerifyVersionInfo) deverão ser usadas para verificar a versão do sistema operacional. As chaves do registro não devem ser lidas para determinar a versão.

As verificações explícitas de versão do runtime do DirectX não devem estar presentes no jogo. Essas verificações de versão não devem estar presentes na instalação que inicia a configuração de runtime do DirectX (DirectSetup).

Fundamento

Quando os usuários do Windows atualizam seus sistemas operacionais, não devem ser impedidos de usar os jogos atuais simplesmente porque o número da versão do Windows aumentou. Verificadores de versão mal escritos continuam a criar problemas para softwares que, de outra forma, funcionariam bem em versões mais recentes do Windows ou apenas com a adição de um service pack do Windows.

A lógica de comparação de verificação de versão frágil do runtime do DirectX criou diversas instalações com falha quando ele é executado em versões diferentes do Windows. O número de versão do DirectX se aplica somente aos principais componentes do sistema operacional. Ele não se aplica aos componentes do SDK do DirectX lado a lado que são usados por muitos jogos.

Informações adicionais

É muito comum ver os instaladores verificarem uma versão mínima do sistema operacional. No entanto, essa verificação deve ser feita com cuidado para garantir que o teste seja maior ou igual a, em vez de simples igualdade, bloqueando assim uma versão específica do sistema operacional. Usar o teste HighVersionLie do Application Verifier é uma forma rápida e fácil de determinar como seu instalador reagirá a uma mudança significativa no número da versão do sistema operacional.

O uso adequado do pacote de redistribuição do runtime do DirectX (Instalação do DirectX) envolve sempre iniciá-lo durante a instalação, de preferência no modo silencioso. Isso permite que o código fornecido pela Microsoft execute todas as atualizações de versão necessárias. Também permite a instalação de qualquer componente opcional do SDK do DirectX lado a lado, como D3DX, XACT, MDX ou XInput.

Para obter as práticas recomendadas para implantar o runtime do DirectX, consulte Instalação do DirectX para desenvolvedores de jogos.

Recomenda-se que os jogos que oferecem suporte ao Windows XP verifiquem se há um service pack nível 2 ou superior, porque o Service Pack 2 (SP2) e o Service Pack 3 (SP3) oferecem melhorias significativas de segurança, um requisito simplificado de redistribuição do runtime do DirectX e uma implantação extremamente ampla. A maioria das tecnologias modernas da Microsoft que oferecem suporte ao Windows XP requer SP2 ou SP3 (XAudio2, Games for Windows - LIVE e assim por diante).

2.6 Suporte a sessões de usuário simultâneas

Requisito

Os jogos que dependem de gráficos 3D não precisam funcionar em uma conexão de área de trabalho remota, mas o usuário deve ser alertado quando o jogo falhar.

Os jogos devem oferecer suporte a cenários multitarefa padrão do Windows aderindo às seguintes regras:

  • Os jogos não devem bloquear o uso de sessões de usuário simultâneas.
  • Um jogo deve ser executado em uma nova sessão de usuário quando já estiver em execução em outra sessão.
  • O som do jogo em uma sessão de usuário não deve ser ouvido quando outro usuário estiver ativo em outra sessão.
  • Os jogos devem oferecer suporte à troca rápida de usuário.
  • Os jogos não devem tentar desabilitar a troca de tarefas padrão. Os jogos não devem desabilitar o atalho de teclado ALT+TAB. Os jogos podem desabilitar atalhos de teclado de acessibilidade, conforme descrito em Desabilitar teclas de atalho em jogos.

Fundamento

Os usuários do Windows devem ser capazes de executar sessões simultâneas sem conflito ou interrupção. Esse é um cenário comum para um computador Windows compartilhado por uma família, colegas de quarto ou outras pessoas.

Informações adicionais

Para testar se o jogo é iniciado em uma sessão remota, chame GetSystemMetrics(SM_REMOTESESSION). Um valor diferente de zero indica que a sessão é remota.

Para obter mais informações, consulte Troca rápida de usuário. Observe que a Troca rápida de usuário ocorre se as restrições de tempo do Controle dos Pais estiverem habilitadas quando o tempo do usuário terminar. Consulte o requisito 1.2 para obter mais detalhes.

2.7 Suporte a nomes longos

Requisito

Se um jogo oferecer suporte para salvar arquivos, ele deverá ser capaz de salvar arquivos com nomes e caminhos longos. O jogo deve lidar adequadamente com caracteres especiais do sistema de arquivos, como \ / : * ? " <>, em qualquer campo de entrada de usuário usado para criar nomes de arquivo ou caminhos.

Os jogos devem funcionar corretamente quando um usuário tem um nome de usuário longo.

Fundamento

Os jogadores estão acostumados a usar nomes longos em caminhos profundos que são suportados pelo sistema operacional subjacente.

Informações adicionais

Os nomes longos são definidos como aqueles que contêm os valores máximos definidos no SDK do Windows.

Instalação

Resumo dos requisitos de segurança e compatibilidade

Benefícios ao cliente

Os clientes podem ter certeza de que os aplicativos serão instalados no Windows sem degradar o sistema operacional ou outros aplicativos se os aplicativos usarem métodos oficiais de distribuição de componentes do sistema. Uma experiência de instalação simplificada proporciona uma experiência mais acessível e sem problemas para jogos.

3.1 Suporte a fácil instalação

Requisito

Os jogos devem fornecer um caminho simplificado na interface do usuário de configuração implementando o seguinte:

  • Exiba no máximo uma solicitação de EULA.
  • O caminho de instalação padrão deve ignorar todas as seleções para a instalação (como pastas de instalação ou seleções de componentes), assumir as seleções padrão e, então, executar o jogo ou o inicializador após a instalação bem-sucedida, sem solicitações adicionais. Se desejado, uma opção de instalação personalizada poderá ser fornecida para opções de configuração avançadas.
  • Instale todos os componentes necessários do sistema operacional (como os tempos de execução do DirectX e do Visual C) usando os pacotes de redistribuição corretos da Microsoft. A instalação deve ser executada silenciosamente, sem avisar e sem ser protegida por verificações de versão do componente.
  • Forneça remoção por meio de Programas e Recursos no Painel de Controle para o aplicativo do jogo e os arquivos de trabalho gerados. Recomenda-se uma opção para excluir todos os arquivos de dados criados pelo usuário. O processo de remoção deve garantir que todos os arquivos instalados sejam removidos e todas as configurações (por exemplo, entradas da lista de exceções do firewall e chaves de registro) sejam limpas. Os componentes redistribuídos do sistema operacional não devem ser removidos.
  • Se o jogo exigir que exceções sejam adicionadas ao Firewall do Windows, o processo de instalação poderá solicitar que os usuários informem que essa alteração é necessária. Essa solicitação deverá aparecer antes do início da instalação.

A instalação e a remoção podem exigir direitos administrativos. A aplicação de patches pode exigir a solicitação de credenciais administrativas, dependendo da frequência de atualização. O jogo normal não deve exigir direitos administrativos, de acordo com o requisito 2.1 Seguir as diretrizes de controle de conta de usuário.

Fundamento

A instalação fácil é uma filosofia de desenvolvimento de jogos centrada no Windows, projetada para simplificar e agilizar o processo às vezes tedioso e confuso de instalação de jogos em computadores que executam sistemas operacionais Windows. A instalação fácil é habilitada usando um conjunto de tecnologias e práticas recomendadas que reduzem a complexidade desnecessária e o risco percebido de instalar jogos em computadores Windows.

Os principais objetivos são:

  • Reduzir a quantidade de tempo para entrar no jogo e começar a jogar.
  • Reduzir o número de caixas de diálogo e opções para muito poucas ou nenhuma, a fim de simplificar a experiência de instalação do jogo.

Algumas instalações tradicionais têm solicitações que permitem instalações não funcionais, mesmo que o aplicativo pareça ter sido instalado com êxito. Por exemplo, um jogo pode exigir que um usuário aceite um EULA. O jogo é então instalado e o EULA do DirectX é exibido. Esse EULA permite que os usuários recusem e, assim, ignorem a instalação do runtime do DirectX. Esse cenário pode resultar em um jogo que não funciona devido à falta de componentes.

Informações adicionais

Para obter mais informações sobre instalação de jogos, técnicas de instalação de jogos não tradicionais, soluções de aplicação de patch compatíveis com UAC e como lidar com patches frequentes, consulte os seguintes artigos do DirectX:

Observação

A remoção de arquivos de dados gerados especificamente pelo usuário deve ser realizada apenas para o usuário atual e para locais de usuários compartilhados em comum. Não há uma maneira robusta de examinar o sistema para remover arquivos específicos de outros usuários, mesmo que a remoção exija credenciais administrativas.

3.2 Suporte ao controle de conta de usuário para instalação

Requisito

O instalador do jogo não deve supor que está sendo executado no mesmo contexto que o usuário. Os locais específicos do usuário serão diferentes do instalador e do jogador, mesmo para sistemas de usuário único, devido à elevação das credenciais do administrador. Portanto, quando um jogo é executado pela primeira vez, ele deve executar tarefas específicas do usuário de forma separada do processo de instalação.

A caixa de diálogo de exceção do Firewall do Windows não deve aparecer quando um usuário hospedar ou entrar em um jogo de múltiplos jogadores. Todas as configurações necessárias devem ser feitas no momento da instalação. As instruções de configuração devem informar ao usuário que esta operação ocorrerá como parte da configuração.

O instalador do jogo deve fornecer um manifesto incorporado que designará o nível de execução necessário, de acordo com o requisito 2.1 Seguir as diretrizes de controle de conta de usuário.

Se o jogo for iniciado pelo instalador após a conclusão da instalação, ele deverá ser iniciado no contexto do usuário original.

Fundamento

Uma das maiores alterações no sistema operacional Windows no Windows Vista é a adição do UAC (controle de conta de usuário), que executa aplicativos com privilégios reduzidos por padrão. Como resultado, os instaladores precisam administrar os níveis de privilégio adequadamente. O Windows 7 também faz uso extensivo do UAC. Embora o Windows 7 melhore a experiência do usuário do UAC, os instaladores ainda precisam atender aos mesmos requisitos do Windows Vista para funcionar corretamente, sem depender de comportamento de virtualização potencialmente confuso.

O UAC está ativo por padrão no Windows Vista e no Windows 7, e a grande maioria dos clientes (88% ou mais, com base nos comentários) mantém esse recurso habilitado.

Informações adicionais

Para obter mais detalhes sobre como configurar o Firewall do Windows, consulte o artigo Firewall do Windows para desenvolvedores de jogos do DirectX e o exemplo de FirewallInstallHelper.

O lançamento padrão do jogo no final do processo de instalação não atenderá ao último aspecto deste requisito se a instalação for iniciada por um usuário padrão e se o processo de configuração exigir privilégios administrativos (ou seja, solicitar credenciais de administrador). Também herdará privilégios administrativos, o que será um risco potencial de segurança. Em vez disso, um carregador de bootstrap de configuração deverá iniciar o jogo após retornar de uma invocação bem-sucedida do instalador. Para obter mais informações, consulte o artigo Ensine seus aplicativos a funcionarem bem com o Controle de Conta de Usuário do Windows Vista da MSDN Magazine.

3.3 Instalar para corrigir pastas

Requisito

Os jogos instalados para todos os usuários devem ser instalados na pasta Arquivos de Programas por padrão. Os dados do usuário devem ser gravados quando o jogo é executado pela primeira vez, não durante a instalação.

Fundamento

Os usuários devem ter flexibilidade para instalar aplicativos onde forem necessários. Também devem ter uma experiência consistente e segura com o local padrão dos arquivos.

Informações adicionais

Os jogos podem usar vários locais de pasta conhecidos (como aqueles especificados por CSIDL_LOCAL_APPDATA e CSIDL_COMMON_APPDATA) para armazenar quantidades significativas de dados do jogo e arquivos executáveis de suporte para implementar cenários avançados de instalação sob demanda e aplicação de patches.

Como a instalação pode exigir elevação para uma conta de usuário diferente durante o processo de instalação de todos os usuários, não há um local de usuário correto no qual armazenar dados no momento da instalação. Além disso, se a criptografia de arquivos estiver habilitada, os arquivos criptografados só poderão ser acessados pela conta de usuário que os criou.

3.4 Instalar os recursos do Windows corretamente

Requisito

Os aplicativos não devem tentar instalar arquivos ou chaves de registro protegidos pelo WRP (Proteção de Recursos do Windows). Se o aplicativo exigir versões mais recentes dos componentes do sistema, ele deverá atualizar esses componentes usando um Microsoft Service Pack ou um pacote de instalação aprovado pela Microsoft que contenha o componente do sistema. Os componentes do sistema nunca devem ser empacotados novamente.

Fundamento

O WRP (Proteção de Recursos do Windows) foi desenvolvida para garantir que os recursos protegidos do sistema sejam atualizados usando somente mecanismos de instalação ou atualização aprovados pela Microsoft. O WRP melhora a confiabilidade do sistema garantindo que os resultados de uma instalação sejam previsíveis.

Informações adicionais

O WRP é o sucessor da Proteção de Arquivo do Windows, que protege a maioria dos componentes do sistema instalados na pasta do Windows. O WRP protege a maioria das chaves de registro que armazenam configurações para a criação de objetos COM. Além disso, reserva determinadas pastas para uso exclusivo do sistema operacional. As tentativas de acessar recursos protegidos geralmente resultam em um erro de acesso negado.

Para obter detalhes sobre as práticas recomendadas quando o runtime do DirectX é implantado com um jogo, consulte o artigo Instalação do DirectX para desenvolvedores de jogos do DirectX.

3.5 Evitar reinicializações durante a instalação

Requisito

O instalador do jogo não deve supor que a instalação de componentes do Windows a partir de pacotes de redistribuição requer uma reinicialização, a menos que a reinicialização seja indicada por um resultado de retorno ou pela documentação da Microsoft.

Se o instalador do jogo sempre forçar uma reinicialização, isso deverá ser aprovado pela Microsoft.

As caixas de diálogo de arquivos em uso incluídas nos pacotes do Windows Installer devem conter uma opção para fechar aplicativos automaticamente e tentar reiniciá-los após a conclusão da instalação.

Fundamento

Reinicializar o sistema após uma instalação é uma interrupção inconveniente para os usuários e geralmente é desnecessário.

Informações adicionais

Para obter mais informações, consulte Usar o Windows Installer com o gerenciador de reinicialização.

3.6 Usar o controle de versão de arquivo corretamente

Requisito

O programa de instalação do jogo deve verificar corretamente se as versões mais recentes do arquivo estão instaladas. A instalação de um jogo nunca deve regredir nenhum arquivo que você não produz ou que seja compartilhado por aplicativos que você não produz.

Fundamento

Os componentes compartilhados e os componentes do sistema geralmente são atualizados para correções de segurança e funcionalidade expandida. Uma instalação que inclui uma versão mais antiga de componentes atualizados não deve resultar na perda de atualizações e correções que já foram aplicadas.

3.7 Suporte a execução automática [requisito condicional]

Requisito

No caso de jogos distribuídos em CD, DVD ou outra mídia removível com suporte à execução automática, quando o disco for inserido pela primeira vez, o aplicativo deverá ser executado automaticamente ou solicitar que o usuário instale o jogo, a menos que o usuário tenha desabilitado o recurso de execução automática.

Depois que o aplicativo for instalado com sucesso, reinserir o disco na unidade não deverá fazer com que a instalação seja reiniciada automaticamente. É aceitável perguntar aos usuários se eles desejam atualizar ou alterar suas opções de instalação.

O aplicativo de execução automática não deverá solicitar elevação (ou seja, deve ter asInvoker no manifesto, de acordo com o requisito 2.1, embora possa iniciar o programa de instalação ou outro utilitário que exija direitos administrativos. A elevação deverá ocorrer somente se o jogo não estiver instalado ou se o usuário o selecionar especificamente.

Fundamento

A execução automática simplifica a experiência de usar aplicativos distribuídos por mídia, como jogos que geralmente exigem que o disco esteja na unidade para executar o jogo.

Informações adicionais

Não é aceitável exigir que o usuário navegue no Explorador de Arquivos para iniciar a instalação a partir do CD ou DVD.

Para jogos distribuídos em vários discos, os discos subsequentes deverão, idealmente, usar o recurso de execução automática ou continuar a instalação sem solicitar que o usuário pressione uma tecla ou execute outra ação.

Ao criar um programa de execução automática, verifique se todos os componentes necessários estão presentes em novas instalações do Windows. Os aplicativos típicos dependem de tecnologias instaladas pela configuração, mas a execução automática é executada antes que ocorra qualquer configuração desse tipo. Um exemplo comum é a falha de programas de execução automática porque as DLLs do runtime do Visual C não foram incluídas como parte da instalação do Windows. Portanto, o programa de execução automática deverá usar a implantação do CRT local do aplicativo ou vincular estaticamente o CRT.

Os programas de execução automática escritos para uso em versões do Windows anteriores ao Windows Vista não deverão usar o runtime do .NET, pois essa tecnologia não está incluída no Windows XP ou em versões mais antigas do Windows. O Windows Server 2003 e o Windows Vista são as primeiras versões do Windows a incluir o runtime do .NET como parte de seu sistema operacional.

Por razões semelhantes, os programas de execução automática não podem exigir a presença de componentes lado a lado opcionais do SDK do DirectX, como D3DX9, D3DX10, D3DX11, XAudio2, X3DAudio, XACT, XINPUT e MDX 1.1.

Para obter um exemplo de como usar a execução automática, consulte Exemplo de execução automática.

Confiabilidade

Resumo dos requisitos de segurança e compatibilidade

Benefícios ao cliente

Esses requisitos tornam um aplicativo mais confiável, minimizando o número de falhas, travamentos e reinicializações. Os requisitos de confiabilidade podem ajudar a garantir que o software seja mais previsível, sustentável, resiliente e recuperável.

4.1 Eliminar reinicializações desnecessárias

Requisito

Todos os instaladores de aplicativos devem aproveitar as APIs do gerenciador de reinicialização para evitar reinicializações do sistema (consulte o requisito 3.5).

Os jogos não devem bloquear o desligamento.

Todos os aplicativos devem responder ao gerenciador de reinicialização ouvindo e respondendo às seguintes mensagens de desligamento:

WM_QUERYENDSESSION com LPARAM = ENDSESSION_CLOSEAPP (0x1)

Os aplicativos GUI devem responder (TRUE) imediatamente em preparação para uma reinicialização.

WM_ENDSESSION com LPARAM = ENDSESSION_CLOSEAPP (0x1)

Os aplicativos devem retornar um valor 0 em 5 segundos e depois fechar.

CTRL+C

Os aplicativos de console que recebem essa mensagem devem ser fechados imediatamente.

Fundamento

As reinicializações do sistema são uma grande interrupção. Elas levam a uma experiência ruim do usuário e devem ser minimizadas. Algumas operações, como atualizações críticas do sistema, podem exigir reinicializações. Ao ouvir mensagens de desligamento, o jogo e outros aplicativos podem reagir prontamente às solicitações do gerenciador de reinicialização. Dessa forma, podem evitar atrasos desnecessários em solicitações de reinicialização válidas.

Informações adicionais

Se um instalador de jogos usar a tecnologia Windows Installer (MSI) sem nenhuma ação personalizada, essa funcionalidade será fornecida automaticamente. Os pacotes de redistribuição da Microsoft também oferecem suporte ao Gerenciador de reinicialização.

Para obter mais informações sobre o Gerenciador de reinicialização, consulte Sobre o Gerenciador de reinicialização.

4.2 Eliminar falhas do Application Verifier

Requisito

O jogo não deve gerar falhas em execução no Application Verifier (AppVerifier) da Microsoft, versão 4.0 ou posterior, nos seguintes testes:

  • Noções básicas: identificadores, heaps, bloqueios, memória, TLS
  • Diversos: DangerousAPIs, DirtyStacks

Fundamento

O AppVerifier testa muitos problemas conhecidos que causam falhas e travamentos em aplicativos do Windows, bem como vulnerabilidades de segurança conhecidas.

Informações adicionais

Para obter mais informações sobre o Application Verifier, consulte Application Verifier e Uso do Application Verifier em seu ciclo de vida de desenvolvimento de software.

Esse requisito não se aplica a aplicativos gerenciados puros sem interoperabilidade nativa.

Esses testes devem ser executados em uma compilação de versão. A depuração de compilações pode gerar falhas falsas. Algumas tecnologias antipirataria e antifraude podem interferir na execução do AppVerifier. Portanto, esses testes devem ser realizados sem habilitar as tecnologias antipirataria e antifraude.

Pode ser necessário definir a propriedade Full do teste Basics:Heaps como FALSE, pois o PageHeap completo aumenta muito a pressão de memória do aplicativo em execução. As falhas ainda serão detectadas, mas poderá ser mais difíceis rastreá-las se você usar apenas PageHeap parcial.

Se você usar os testes relacionados ao UAC/LUA no Application Verifier para atender aos requisitos 2.1 e 3.2 do Controle de Conta de Usuário, deverá usar o Standard User Analyzer para analisar os resultados. Há também diversos outros testes úteis fornecidos pelo Application Verifier cujo o uso é altamente recomendado no desenvolvimento e teste para garantir um alto nível de compatibilidade com as versões atuais e futuras do Windows. O teste HighVersionLie é usado para verificar a conformidade com o requisito 2.5.

O Visual Studio Team System inclui um subconjunto da funcionalidade AppVerifier que é integrada ao ambiente de depuração. Isso pode ser útil para rastrear e resolver problemas com testes Noções básicas: heaps, identificadores e bloqueios.

4.3 Suporte ao relatório de erros do Windows e informações de versão do arquivo

Requisito

Para habilitar o suporte ao Relatório de erros do Windows, os jogos deverão atender aos seguintes requisitos:

  • Os jogos devem lidar apenas com exceções conhecidas e esperadas. O Relatório de erros do Windows não deve ser desabilitado. Se uma falha como Violação de acesso aparecer em um jogo, ele deverá permitir que o Relatório de erros do Windows informe a falha.
  • Todos os arquivos executáveis (por exemplo, arquivos .exe ou DLLs) devem conter um nome de produto, nome da empresa e versão do arquivo precisos.
  • A saída normal do jogo não deve resultar em uma falha de exceção desconhecida.

Fundamento

As APIs de Relatório de erros do Windows fornecem comentários essenciais para a Microsoft detectar falhas e travamentos generalizados em aplicativos. Isso permite que a Microsoft e seus parceiros detectem e resolvam rapidamente problemas de sistema e driver que levam a falhas de aplicativos rapidamente.

Informações adicionais

Os jogos podem incluir manipuladores de exceção não processados personalizados para executar funcionalidades de suporte e relatórios personalizados, mas devem passar qualquer erro para as funções ReportFault ou WerReportSubmit.

As informações adequadas sobre a versão do arquivo podem ser verificadas exibindo as propriedades do arquivo na interface do usuário da área de trabalho do Windows e verificando a página de propriedades Versão.

Para obter mais informações sobre as APIs de Relatório de erros do Windows e como analisar os despejos de memória gerados ao usar esse serviço, consulte o artigo Análise de despejo de memória do DirectX.

Terminologia do controle comum do Xbox 360 para Windows

Nome Descrição
Um O botão A.
B O botão B.
BACK o botão Voltar.
Botão superior (direita/esquerda) O botão na borda superior direita e esquerda do controle. Equivalente a um botão de ombro.
teclado direcional O teclado direcional do controlador.
D-pad Abreviatura aceita de teclado direcional.
DP Abreviatura do teclado direcional e etiqueta do controlador.
RB, LB Abreviaturas do botão superior direito e esquerdo e etiquetas do controlador.
RS, LS Abreviações dos joystick direito e esquerdo e etiquetas do controlador.
RT, LT Abreviaturas do gatilho direito e esquerdo e etiquetas do controlador.
RSB, LSB Abreviações dos joystick direito e esquerdo e etiquetas do controlador.
START O botão Iniciar.
joystick (direita/esquerda) O joystick do controlador. Anteriormente thumbstick.
Botão joystick (direita/esquerda) O botão joystick do controlador. Anteriormente botão thumbstick.
gatilho (direita/esquerda) O gatilho do controlador.
Vibração Feedback de jogabilidade produzido pelo motor do controlador. Não use tremor.
X O botão X.
Y O botão Y.
Controle do Xbox 360 para Windows O gamepad do Xbox 360 foi vendido como um SKU de hardware de PC, incluindo um disco de driver de dispositivo do Windows.
Controle sem fio do Xbox 360 para Windows O gamepad sem fio do Xbox 360 foi vendido como um SKU de hardware de PC, incluindo um disco de driver de dispositivo do Windows.

Diretrizes para produtos de middleware de jogos

Introdução

Para que os jogos se qualifiquem para o programa Games for Windows, eles devem atender a uma lista de requisitos técnicos. Todos os componentes de terceiros fornecidos com um título (arquivos executáveis, DLLs, drivers e assim por diante) também deverão atender a esses requisitos para que o jogo se qualifique. Este documento destaca os requisitos mais comuns que também devem ser atendidos pelos componentes de terceiros para que o jogo passe nos testes de conformidade. Os instaladores e os pacotes completos de mecanismos de jogos/produção devem analisar o documento completo de requisitos técnicos do Games for Windows, pois muitos desses requisitos são afetados por essas ferramentas.

Recomendações adicionais

Além de garantir que seu componente suporte a criação de títulos que estejam em conformidade com os requisitos do Games for Windows, há uma série de outras considerações que você deve levar em conta ao desenvolver e implantar uma biblioteca ou utilitário de suporte para um jogo do Windows.

  • Para oferecer suporte a desenvolvedores que trabalham em aplicativos x64 nativos de 64 bits, forneça versões nativas de 32 bits e 64 bits de suas bibliotecas. A versão de 32 bits deve ser compatível com 64 bits conforme 2.2. As bibliotecas para aplicativos de 32 bits não devem supor que o bit alto de qualquer endereço de 32 bits não é utilizado para oferecer suporte ao uso em aplicativos LARGEADDRESSAWARE x86.

  • Se você fornecer cabeçalhos de código nativo (C/C++), use a sintaxe de atributo SAL (Standard Annotation Language) para decorar suas rotinas de API públicas. Isso permitirá que os usuários da sua biblioteca obtenham o máximo benefício do uso da Análise de Código Estático (/analyze), que faz parte do Visual Studio Team System 2005, Visual Studio Team System 2008, Visual Studio 2010 Premium e Visual Studio 2010 Ultimate, bem como das ferramentas do compilador Windows SDK disponíveis publicamente.

  • Se o produto criar threads dentro do processo do usuário, certifique-se de nomear cada thread para que as ferramentas de depuração possam anotar corretamente os threads em execução.

  • Se você escrever rotinas que devem ser chamadas dentro do loop principal de um jogo, use as rotinas D3DPERF_BeginEvent/EndEvent e D3DPERF_SetMarker para anotar operações de alto nível para facilitar a identificação de gargalos usando o PIX para Windows.

    Observação

    Para a funcionalidade de diagnóstico gráfico do Visual Studio 2012, essas rotinas D3DX e PIX são substituídas pela interface ID3DUserDefinedAnnotation.

  • Para bibliotecas de rede, forneça implementações neutras em relação a IP e evite rotinas obsoletas somente IPv4 para oferecer suporte às tecnologias IPv6 e Teredo no Windows XP com Service Pack 2, Windows Vista e Windows 7.

  • Os provedores de serviços de jogos devem se registrar no Gerenciador de Jogos usando a versão 2 do esquema GDF e usar o recurso RSS para fornecer notícias relacionadas ao serviço.

Demonstração do Games for Windows

Introdução

As demonstrações do Games for Windows vão além de fornecer uma experiência de jogo sólida em PCs com Windows. Ao implementar esses recursos, os jogos podem adicionar mais emoção à experiência do usuário nas plataformas Windows mais recentes.

Os títulos do Games for Windows devem atender a todos os requisitos técnicos listados neste artigo, mas os recursos de demonstração são opcionais. Esses títulos são livres para implementar algumas, nenhuma ou todas essas demonstrações.

S.1 Explorar Direct3D 11

Requisito

O Direct3D 11 é a API de renderização de última geração para Windows Vista e Windows 7. Os jogos que exploram o Direct3D 11 usam conteúdo otimizado, técnicas avançadas de renderização e novos recursos de hardware para criar uma experiência atraente em hardware compatível com 10, 10.1 e 11.

Se o jogo também implementar o Direct3D 9, uma comparação lado a lado deverá demonstrar uma melhoria perceptível na qualidade do conteúdo, na fidelidade visual, no desempenho, na complexidade da cena e em outras áreas de fidelidade gráfica para o Direct3D 11. Esse suporte está sujeito ao Requisito técnico 1.7 do Games for Windows.

A tecnologia Direct3D 10level9 pode ser usada para oferecer suporte ao hardware de vídeo Shader Model 2.0/3.0 Direct3D 9 no Windows Vista e Windows 7, em vez de usar uma implementação Direct3D 9 lado a lado para amplo suporte de hardware. No entanto, isso não é suficiente para essa demonstração.

Em computadores que executam o Windows Vista ou Windows 7 com o Direct3D 11 instalado, o jogo deve usar o Direct3D 11 por padrão.

Fundamento

A API do Direct3D 11 se baseia no WDDM (Modelo de Driver de Exibição) do Windows e na infraestrutura do Direct3D 10.1 para oferecer suporte a novos recursos: mosaico de hardware, sombreadores de computação, renderização multithread e criação de recursos, novos formatos de compactação de textura e uma linguagem de sombreador mais flexível. O Direct3D 11 fornece suporte de hardware unificado para placas de vídeo modernas, incluindo as partes Direct3D 11 de última geração, todas as placas de vídeo Direct3D 10 e 10.1 e muitas placas de vídeo Direct3D 9 Shader Model 2.0/3.0, que é o hardware de vídeo mínimo necessário para a área de trabalho Aero 3D.

Informações adicionais

Migrar um mecanismo de renderização do Direct3D 9 para usar a nova interface do Direct3D 11 é uma tarefa bem definida:

  • Elimine todas as operações de função fixa em favor de sombreadores programáveis.
  • Atualize todos os sombreadores existentes para a nova sintaxe do Shader Model 4.x/5.
  • Atualize o gerenciamento de recursos para oferecer suporte ao novo modelo de exibição.
  • Converta todos os ativos para usar uma nova lista de formatos disponíveis.
  • Atualize o tratamento do estado de renderização para usar blocos de estado imutáveis e retrabalhe as constantes do sombreador em buffers constantes.

Essa conversão é essencial para habilitar a demonstração do Direct3D 11, embora o resultado não atenda ao requisito de demonstração de explorar a nova API.

A nova API e o modelo de programação HLSL associado oferecem muitas oportunidades para conteúdo aprimorado:

  • Aproveitando os recursos de hardware existentes do Direct3D 10, como Geometry Shader, Stream Out, matrizes de textura e os formatos de textura compactada BC4/BC5.
  • Aproveitando os recursos de hardware existentes do Direct3D 10.1, como modos de mesclagem independentes por destino de renderização, leitura de profundidade MSAA, acesso de sombreador por amostra MSAA, matrizes de mapa de cubo e renderização para formatos BC (compactados em bloco).
  • Implementação de algoritmos avançados de GPU usando o sombreador de computação com CS4.x em placas de vídeo Direct3D 10/10.1 existentes (habilitadas por drivers de vídeo atualizados) ou CS 5.0 em placas de vídeo Direct3D 11 de última geração.
  • Renderização em vários threads usando a criação de recursos de thread livre e vários contextos de dispositivo para melhorar o desempenho em sistemas de vários núcleos (com drivers de vídeo atualizados). Para obter mais informações, consulte Demonstração do Games for Windows S.3.
  • Com novos recursos do hardware de vídeo da classe Direct3D 11, como mosaico de hardware com sombreadores de envoltório e domínio, o sombreador HLSL do Shader Model 5.0 apresenta formatos de textura compactados BC6HBC7 e Vinculação Dinâmica de Sombreador.

As técnicas que podem ser implementadas com o Direct3D 9 (em grande parte por meio do alto custo da CPU) podem ser descarregadas na GPU de forma eficiente, liberando recursos da CPU para oferecer suporte a outras demandas do jogo.

As APIs do Direct3D 11, as ferramentas de suporte e os exemplos estão disponíveis no SDK do DirectX. Consulte também APIs gráficas no Windows.

S.2 Explorar x64 Nativo

Requisito

O jogo inclui um executável nativo de 64 bits que oferece uma nova experiência atraente habilitada pelas edições x64 do Windows executadas em hardware compatível com x64. Uma comparação lado a lado com a versão de 32 bits do jogo deve mostrar uma melhoria perceptível na complexidade do conteúdo, tempos de carregamento gerais reduzidos e desempenho.

Nas edições de 64 bits do Windows, a instalação deve sempre configurar a versão nativa de 64 bits do jogo como padrão para atalhos no Gerenciador de Jogos e no Windows XP Professional x64 Edition. Se desejar uma instalação dupla, uma tarefa de jogo adicional poderá ser especificada para o Gerenciador de Jogos no Windows Vista e Windows 7 que aponte para a versão de 32 bits, mas o padrão deverá permanecer a versão nativa de 64 bits.

Observe que o jogo deve oferecer suporte às edições de 64 bits do Windows Vista e Windows 7 para atender a essa recomendação de demonstração. O suporte para o Windows XP Professional x64 Edition é recomendado, mas não obrigatório.

Fundamento

A tecnologia x64 fornece recursos de endereçamento de 64 bits para os mercados de consumo e servidor, incluindo 32 bits de velocidade total compatíveis com aplicativos existentes. O x64 é uma parte fundamental do roteiro para AMD (AMD64) e Intel (EMT64) e, com exceção das CPUs ultramóveis, oferece suporte à tecnologia para todos os processadores da geração atual e futura.

O Windows XP Professional x64 Edition foi o primeiro sistema operacional do Windows orientado ao consumidor a oferecer suporte à tecnologia x64, e o Windows Vista e o Windows 7 expandiram muito a disponibilidade da habilitação do sistema operacional para computação de consumo de 64 bits. Com 2 GB de RAM como padrão em muitos computadores novos, melhorias adicionais no dimensionamento de memória não beneficiarão aplicativos individuais de 32 bits que não conseguem lidar com mais de 2 GB de RAM física. Atualmente, muitos jogos estão enfrentando desafios para encaixar todo o conteúdo disponível nas restrições de 2 GB de espaço de endereço virtual, especialmente quando combinados com as grandes memórias de vídeo disponíveis em GPUs de última geração, e migrar para a tecnologia x64 aumenta muito os níveis de detalhes suportáveis.

A compatibilidade x64 para jogos de 32 bits é um requisito técnico do Games for Windows (2.2), mas aproveitar ao máximo as novas tecnologias requer uma implementação nativa de 64 bits.

Informações adicionais

O principal benefício do endereçamento de 64 bits é a capacidade de acessar diretamente mais de 2 GB de memória física e virtual. O grande espaço de endereço de memória virtual permite o uso extensivo de E/S mapeada em memória sem se preocupar com os problemas de esgotamento do espaço de endereço da VM predominantes na programação de 32 bits. Os jogos podem aproveitar o novo espaço para melhorar muito os tempos de carregamento ou, em alguns casos, para eliminar pausas para carregamento de conteúdo.

Os aplicativos de 32 bits existentes podem se beneficiar das edições x64 por terem a capacidade de processar endereços com dados completos de 32 bits quando criados com a opção de vinculador Habilitar endereços grandes (/LARGEADDRESSAWARE). Nas versões de 32 bits do Windows XP, os modos de inicialização especiais permitiam que esses aplicativos abordassem até 3 GB de RAM, e as edições x64 fornecem acesso a até 4 GB de RAM para aplicativos LAA (Large Address Reware). Embora o uso do LAA em um aplicativo de 32 bits não atenda a esse requisito de demonstração, essa tecnologia de ponte é uma forma extremamente útil de fornecer benefícios adicionais de dimensionamento em versões x64 do Windows para aqueles que não implementam totalmente esse requisito de demonstração.

Para obter mais informações, consulte Programação de 64 bits para desenvolvedores de jogos e RAM, VRAM e mais RAM: jogos de 64 bits estão aqui no site do desenvolvedor do jogo.

Observação

Um dos principais desafios desta demonstração é garantir que todas as bibliotecas ou componentes de terceiros dos quais seu jogo depende estejam disponíveis para desenvolvimento nativo de 64 bits. Muitas APIs herdadas da Microsoft também foram eliminadas do ambiente nativo de 64 bits, o que pode ser um desafio para bases de código de mecanismo que contêm implementações mais antigas de sistemas importantes.

S.3 Explorar processadores de muitos núcleos

Requisito

O jogo implementa recursos que aproveitam os processadores de vários núcleos, escalando para 3, 4 ou mais núcleos, quando disponíveis.

Se o jogo for compatível com sistemas de processador único ou dual-core, uma comparação lado a lado com um sistema quad-core deverá demonstrar novos recursos perceptíveis, efeitos adicionais atraentes, melhoria na qualidade do conteúdo e/ou desempenho aprimorado.

Como o dimensionamento dual-core já é amplamente compatível com jogos, bem como usado automaticamente por vários aprimoramentos de driver Direct3D, o dimensionamento dual-core não é suficiente para fazer esta demonstração.

Fundamento

O crescimento contínuo do desempenho das CPUs mudou de melhorias na taxa de clock para a adição de núcleos computacionais. Os roteiros da AMD e da Intel são baseados em designs escaláveis e de vários núcleos. Todas as plataformas de jogos de última geração têm CPUs de vários núcleos devido a essa mudança fundamental na evolução dos processadores. Os aplicativos de thread único não terão mais ganhos significativos com as CPUs de última geração. O multithreading simples também não será dimensionado à medida que o número de núcleos de CPU em uso comum aumentar para três ou mais.

Informações adicionais

Observe que as contagens de núcleos não precisam ser uma potência de dois. Portanto, os jogos devem ser dimensionados linearmente e lidar com contagens de núcleos de 3, 4, 5, 6, 7, 8 e assim por diante.

O dimensionamento por meio do aumento do número de threads em um aplicativo só fornecerá retorno se o custo de comunicação e sincronização de threads forem mantidos sob controle. O dimensionamento baseado em recursos pode ser uma solução mais fácil a curto prazo, permitindo que o jogo funcione normalmente sem threads adicionais em sistemas de núcleo único e habilitando-os quando a potência adicional da CPU estiver disponível.

Para obter mais informações, consulte Codificação para vários núcleos no Xbox 360 e no Microsoft Windows e Considerações de programação sem bloqueio para Xbox 360 e Microsoft Windows nos artigos do DirectX, bem como o utilitário DXUTLockFreePipe e o exemplo CoreDetection.

Fazer uso da criação de recursos de thread livre e dos contextos de dispositivos do Direct3D 11 é útil para obter escalabilidade de vários núcleos na renderização e no carregamento de recursos gráficos. Consulte Demonstração do Games for Windows S.1.

Observe que usar a instrução de CPU rdtsc diretamente, em vez de usar APIs do Windows para calcular o tempo em sistemas multicore, pode levar a problemas em algumas configurações de hardware e sistema operacional. Consulte Tempo do jogo e processadores com vários núcleos nos artigos do DirectX.

S.4 Suporte para Games for Windows - LIVE

O Games for Windows - LIVE não tem mais suporte da Microsoft.

S.5 Suporte Windows Touch

Requisito

Os jogos compatíveis com toque do Windows podem ser reproduzidos usando toque e/ou gestos em computadores que executam o Windows 7 com uma tela sensível ao toque. A entrada do teclado também pode ser usada, mas a interface de reprodução principal deve ser baseada em toque.

Habilitar o toque não deve impedir o uso do mouse ou do controlador comum, sujeito ao Requisito Técnico 1.4.

Não se espera que o instalador do jogo ofereça suporte à funcionalidade Windows Touch.

Fundamento

Telas multitoque para computadores estão disponíveis para laptops e desktops e representam um recurso de hardware essencial promovido com o lançamento do Windows 7. O Windows 7 oferece suporte ao Windows Touch em toda a área de trabalho e interfaces de controles comuns.

Informações adicionais

Os aplicativos de código nativo podem acessar o multitoque por meio das mensagens WM_TOUCH, em combinação com a função RegisterTouchWindow. Consulte também a API de manipulações e inércia.

O WPF (Windows Presentation Foundation) 4.0 oferece uma solução gerenciada para interfaces multitoque.

Para obter mais informações, consulte o SDK do Windows Touch.

S.6 Suporte a High Color

Requisito

Jogos que suportam High Color usam um formato 10:10:10:2 (DXGI_FORMAT_R10G10B10A2, D3DFMT_A2B10G10R10) ou 16:16:16:16 (DXGI_FORMAT_R16G16B16A16, D3DFMT_A16B16G16R16) para o buffer de renderização e o modo de exibição em tela cheia.

Usando um destino de renderização High Color, o conteúdo HDR (High-Dynamic Range) pode ser renderizado com uma gama estendida ou ampla ao executar o mapeamento de tons para um intervalo de 10 ou 16 bits.

Fundamento

Os monitores foram capazes de exibir mais de 256 níveis de cor por canal durante muitos anos, mesmo quando os monitores CRT eram predominantes. O hardware de varredura em placas de vídeo tem sido o fator limitante. As GPUs modernas, incluindo a maioria do hardware Direct3D classe 9 e todo o hardware Direct3D classe 10 e superiores, têm hardware de digitalização capaz de pelo menos 10 bits por canal, e a capacidade do hardware deverá crescer para 16 bits por canal de cor no futuro. Os sistemas de interconexão de TV HD (HDMI, DisplayPort) também foram projetados para lidar com mais de 8 bits por canal, e o VGA analógico já transporta esses sinais.

Informações adicionais

Observe que High Color (ou Hi Color), historicamente se refere à mudança de telas coloridas de 256 (8 bits) para telas coloridas de 15 ou 16 bits. A maioria dos sistemas de exibição já migrou para o True Color há muito tempo, que é uma cor de 24 bits, ou 8 bits por canal de cor para vermelho, verde e azul. Por High Color queremos dizer uma nova geração de sistemas de exibição que podem operar com mais de 8 bits por canal de cor individual. Também é conhecido como Deep Color.

Introdução

Além de atender aos Requisitos Técnicos e adotar uma ou mais Demonstrações em seu título, há várias práticas recomendadas que devem ser seguidas para todos os jogos do Windows. Embora essas recomendações estejam fora do escopo dos principais requisitos técnicos, recomendamos que você as use para todos os títulos do Games for Windows.

Recomendações adicionais

  • Use o compilador e o runtime mais recentes do Visual Studio. As versões mais recentes do compilador implementam melhorias significativas na qualidade do código gerado e em questões de segurança, além de usar estratégias modernas de otimização do processador. Atualizar o compilador e usar o C Runtime mais recente é uma maneira fácil de migrar para práticas de codificação modernas.
  • Use a versão DLL (biblioteca de vínculo dinâmico) do C Runtime, em vez de vinculação estática, e use o Secure CRT. (Podem ser feitas exceções em casos especiais de pré-instalação, como para um programa de execução automática ou para o próprio instalador).
  • Para áudio de jogos, use XAudio2, X3DAudio e/ou XACT, em vez de DirectSound. Para mecanismos de áudio que fazem toda a mixagem e conversão de taxa de origem e precisam apenas de uma solução de baixa latência para saída de áudio, use o DirectSound no Windows XP (somente) e o WASAPI no Windows Vista e Windows 7.
  • Evite usar APIs herdadas e preteridas: DirectDraw, DirectSound, DirectPlay, camada de desempenho do DirectMusic, DirectPlay Voice e Modo Retido do Direct3D. Observe que o DirectPlay Voice e o Direct3D Retained Mode não estão disponíveis no Windows Vista ou no Windows 7. O DirectPlay e a camada de desempenho do DirectMusic não estão disponíveis para aplicativos nativos x64.
  • Otimize usando conjuntos de instruções SSE/SSE2 SIMD. Consulte a API DirectXMath no SDK do Windows como uma solução multiplataforma para operações matemáticas otimizadas para SIMD.
  • Use as práticas recomendadas modernas para segurança do Windows (incluindo opções de compilador e vinculador como /NXCOMPAT, /GS, /SAFESEH, /DYNAMICBASE, /SDL e assim por diante). Para obter mais informações, consulte Práticas recomendadas de segurança no desenvolvimento de jogos.
  • Use os componentes e as bibliotecas mais recentes do SDK do Windows. Remova as dependências nos componentes fora de banda implantados do DirectSetup herdados, como D3DX9, D3DX10 e D3DX11. Considere usar DirectXTex ou DirectXTK ou ambos.
  • Evite usar o compilador HLSL mais antigo e, em vez disso, use o compilador HLSL moderno. Se o suporte ao Pixel Shader 1.x for necessário para seu aplicativo, use o assembly de sombreador em vez do HLSL ou limite o uso do compilador mais antigo apenas para esses cenários.

Recursos

Termo Descrição
Games for Windows: Casos de teste
Práticas recomendadas para jogos no Windows XP, Windows Vista e Windows 7
SDK do Windows
SDKs do Windows
Diretrizes de controle de conta de usuário
Requisitos de desenvolvimento de aplicativos do Windows Vista para compatibilidade com o Controle de Conta de Usuário
Portal do Desenvolvedor DirectX
Centro de desenvolvedores do DirectX
Blog do SDK de Games for Windows e DirectX
 SDK do Games for Windows e do DirectX
Artigos adicionais do DirectX
 Artigos técnicos do DirectX