Поделиться через


Игры для Windows Технические требования: рекомендации по играм в Windows XP, Windows Vista, Windows 7 и Windows 8

В этой статье приведены технические требования и рекомендации по играм, работающим в Windows. Мы написали эти технические требования и рекомендации в первую очередь для покрытия Windows Vista и Windows 7, а также устаревшей операционной системы Windows XP. Эти рекомендации также обычно применяются к классическим играм Win32 в Windows 8.

В этой статье содержатся следующие разделы:

Различия для Windows 8

Ниже приведена сводка ключевых различий при применении этих технических требований и рекомендаций к Windows 8.

Пользовательский интерфейс обозревателя игр не отображается

Все игры, которые вы регистрируете в обозревателе игр, отображаются как плитки в новом пользовательском интерфейсе Windows, но большая часть метаданных, связанных с заголовком, больше не отображается. Вы по-прежнему используете средство создания файлов определения игр (GDFMAKER.EXE), которое теперь доступно в пакете sdk для разработки программного обеспечения Windows, чтобы создать метаданные. Вы также используете существующие механизмы для развертывания метаданных. Продолжайте тестирование вашей регистрации в Games Explorer с использованием Windows 7 и убедитесь, что новый элемент интерфейса Windows отображается при установке на Windows 8 (см. раздел 1.1 Интеграция Games Explorer).

Чтобы скачать пакет SDK для Windows 8, см. раздел "Загрузки для разработки настольных приложений".

Регистрация через API обозревателя игр по-прежнему является механизмом регистрации вашей игры в системе родительского контроля Windows

Рекомендуется запустить версию пакета SDK для Windows GDFMAKER в выпущенной версии Windows 8, чтобы убедиться, что она может заполнять все поддерживаемые системы оценки.

Примечание.

Для этой версии GDFMAKER требуется .NET 4.0.

см. раздел 1.2 Поддержка функций обеспечения безопасности семьи / родительского контроля.

Теперь существует три варианта использования API XINPUT в зависимости от ваших требований.

XINPUT 1.4 встроен в Windows 8. Приложения Магазина Windows и классические приложения Win32 могут использовать XINPUT 1.4. Все версии Windows могут использовать XINPUT 9.1.0 для упрощенных общих контроллеров, но нет пакета распространения с XINPUT 9.1.0. Все версии Windows также могут использовать существующую версию пакета SDK DirectX XINPUT 1.3, которая требует развертывания DirectSetup.

См. раздел 1.4. Поддержка общего контроллера Xbox 360 для Windows.

В Windows RT поддерживаются только ограниченный набор классических приложений Win32

Игры, которые работают в Windows 7, могут работать правильно на платформах Windows 8 x86 и x64.

См. статью 2.2 Поддержка версий Windows x64.

Убедитесь, что все проверки ОС выполнены правильно

Версия ОС Windows 8 — 6.2. Windows 8 проходит текущие минимальные тесты уровня, которые мы рекомендуем для запуска игр.

Пакет распространения конечных пользователей DirectX успешно работает в Windows 8, так же, как и в Windows 7, позволяя развертывать D3DX9, D3DX10, D3DX11, XINPUT 1.3, XAUDIO 2.7, XACTEngine и т. д.

Известная проблема существует с DirectSetup на системах, где установлен только .NET 4.0 из-за процедуры обработки развертывания устаревших сборок Managed DirectX 1.1. Эта проблема относится как к Windows 8, которая поставляется с .NET 4.5 по умолчанию, так и к новым компьютерам Windows XP с установленной средой выполнения .NET 4.0. Но эта проблема не применяется к любой версии .NET до .NET 4.0. Хотя в Windows 8 есть функция совместимости приложений, которая автоматически решает эту проблему (для работы требуется сетевой доступ), мы рекомендуем играм, которые продолжают использовать DirectSetup, обновиться до обновленной версии файлов REDIST из комплекте SDK DirectX (июнь 2010 г.). Если вы используете DirectSetup для заголовка, как всегда, обрезайте заголовок до минимально необходимого набора CAB-файлов.

См. 3.4 Правильная установка ресурсов Windows.

Игры, требующие совместимой среды выполнения .NET 2.0 (2.0, 3.0, 3.5) продолжают использовать существующие механизмы развертывания.

Эти игры активируют поведение совместимости приложений в Windows 8, чтобы включить среду выполнения .NET 3.5 автоматически (для этого требуется сетевой доступ). Но мы рекомендуем разработчикам .NET перейти в среду выполнения .NET 4.0.

Примечание.

Устаревшие сборки Managed DirectX 1.1 несовместимы с средой выполнения .NET 4.x.

См. 3.4. Правильная установка ресурсов Windows.

Использование автоматического запуска или другой предварительной установки технологии, которая использует .NET, не рекомендуется

Предположим, что в Windows Vista и Windows 7 присутствуют только совместимые среды выполнения .NET 2.0 (2.0, 3.0, 3.5). По умолчанию в Windows 8 присутствует только совместимая среда выполнения .NET 4.0.

См. раздел 3.7 Поддержка автоматического запуска.

Существует обновленный средство проверки приложений для Windows 8

Пакет SDK для Windows 8 включает этот обновленный средство проверки приложений.

См. раздел 4.2. Устранение сбоев проверяющего приложения.

Дополнительная информация

Руководство по совместимости Windows 8 и Windows Server 2012
Где находится пакет SDK для DirectX?

Игры для Windows

Сводка требований к играм

Преимущества клиентов

Компьютерные игры являются ключевым опытом развлечений в Windows, но проблемы с удобством использования вызвали разочарование клиентов на протяжении многих лет. Традиционно игры устанавливаются как приложения, но они используются больше как развлекательные средства массовой информации (фильмы или песни, например). Инновации, такие как Games Explorer, предоставляют игры единообразно, отличаясь от стандартных приложений. Эти инновации также дают играм статус гражданина первого класса в Windows, вместе с музыкой и фотографиями. Следующие требования помогают обеспечить улучшенный, более доступный и унифицированный игровой интерфейс Windows Vista и Windows 7. В то же время они обеспечивают совместимость с Windows XP.

1.1 Интеграция Games Explorer

Требование

Игра должна быть видна в обозревателе игр ( папка "Игры ") в Windows Vista и Windows 7. При выборе игра также должна отображать правильные метаданные, включая издателя, разработчика, дату выпуска, версию, оценки windows Experience Index, рейтинг (если применимо), а также связанные гиперссылки.

Если игра распространяется через онлайн-службу игр, поставщик услуг также должен появиться в Game Explorer. Чтобы обеспечить правильную обработку поставщика и возможность использования RSS-каналов, следует использовать вторую версию схемы для файлов определения игр (GDFs). (Дополнительные сведения о GDFS см. в разделе "Дополнительные сведения".)

Кроме того, установщики игр должны соблюдать следующие правила при запуске в Windows Vista и Windows 7:

  • Установка не должна создавать ярлык для запуска игры на рабочем столе, в меню или в любом другом расположении.
  • Задачи и сочетания клавиш для удаления не должны быть созданы.
  • Пользователи должны иметь возможность удалить игру с помощью программ и компонентов в панель управления в Windows Vista и Windows 7 или добавить или удалить программы в панель управления в Windows XP.

В Windows XP и в предыдущих версиях Windows установщик игр может создавать группы программ, значки рабочего стола или ярлыки по мере необходимости.

Логическое обоснование

Обозреватель игр Windows аналогичен концепцией папок Windows XP "Мои документы " или "Мои рисунки". Идея заключается в том, чтобы централизовать аналогичное содержимое в одном месте и упростить организацию и контекстно-зависимые действия. Обозреватель игр расширяет концепцию "Мои документы" или "Мои фотографии", позволяя более богатую организацию и контроль над играми. Game Explorer позволяет игрокам просматривать, упорядочивать и взаимодействовать со всеми играми, установленными в своих системах. Она также позволяет издателям игр более эффективно обмениваться важной информацией о игре. Система управляется данными, что упрощает обновление сведений о игре в течение всей жизни продукта.

Дополнительная информация

Для интеграции с Game Explorer требуется создать файл определения игры (GDF), который является XML-текстовым файлом, внедренным в двоичный файл (исполняемый файл или dll) в качестве ресурса, а также значком Windows. Затем игра должна быть зарегистрирована в Game Explorer. GDF также позволяет отображать предоставленные сведения, такие как название игры, издатель, разработчик, ссылки на веб-сайты и необязательные задачи. Обратите внимание, что задачи поддержки могут быть только ссылками на веб-сайты, но игровые задачи также могут быть использованы для дополнительных задач поддержки.

Обозреватель игр может использовать эскизное изображение, но рекомендуется предоставить ресурс значка Windows с большими значками (256×256). Ресурс значка должен содержать размеры изображений 256 256 48 48, 32 32 и 16 16 в 24-разрядном (истинном цвете) и 8-разрядной (256) глубине цвета. Редактор значков, предоставляемый в Visual Studio 2008 и 2010, поддерживает эти форматы больших значков, как и IconWorkshop Lite.

Сведения об интеграции с Обозревателем игр Windows приведены в пакете SDK DirectX. Пакет DirectX SDK включает редактор файла определения игры (GDF), а также пример GDF, который включен в GDFExampleBinary, как образец. Другой пример GameUxInstallHelper предоставляет подпрограммы для интеграции необходимых функций в существующие системы установки. Утилита проверки файлов определения игры (gdftrace.exe) предоставляет средства отладки для оценки GDF. См. также статью "Интеграция Обозревателя игр Windows" в документации по пакету SDK DirectX для C++.

Windows 7 предоставляет поддержку второй версии схемы для файлов GDF. Новая версия включает упрощенный метод для создания задач воспроизведения и поддержки уведомлений об обновлениях, поставщиков услуг игр, статистики игр и RSS-каналов для поставщиков услуг игр. Последняя версия GameUxInstallHelper обеспечивает всю регистрацию и поддержку устаревших систем, необходимую для использования GDF файла версии 2 с Windows Vista. Используйте средства и пример кода из пакета SDK DirectX с августа 2009 г. или более поздней версии. Использование GDF-файла версии 2 рекомендуется для обеспечения поддержки RSS-каналов, статистики игр и уведомлений об обновлении. Кроме того, см. примеры ProviderGDFExampleBinary и GameStatisticsExample.

В Windows Vista Business Edition, Windows 7 Professional Edition и в Enterprise Edition для Windows Vista и Windows 7 ссылка на "Игры" на меню "Пуск" скрыта. Обозреватель игр по-прежнему доступен на меню , щелкнув "Все программы", а затем щелкнув "Игры".

Для сопутствующих приложений, которые устанавливаются вместе с вашей игрой, но не являются самими играми, вы можете создавать группы программ в меню Пуск, ярлыки и значки на рабочем столе во всех версиях Windows, включая Windows Vista и Windows 7. Такие связанные приложения должны соответствовать применимым требованиям Games for Windows; подробности см. в Руководствах по продуктам промежуточного программного обеспечения для игр. Игровые службы рекомендуется зарегистрировать в Game Explorer в качестве поставщика игр для Windows 7. 1

1.2 Поддержка семейной безопасности / родительских средств контроля

Требование

Игры должны полностью поддерживать Безопасность семьи Windows, следуя следующим правилам:

  • Игры не должны требовать, чтобы у пользователя были административные учетные данные для игры. Установка, исправление и удаление могут потребовать административных учетных данных в соответствии с требованиями в разделе 3. (Это требование 2.1. Следуйте рекомендациям по управлению учетными записями пользователей.)
  • Игры, оцененные рейтинговыми комиссиями, поддерживаемыми Windows, такими как ESRB и PEGI, должны включать информацию о присвоенных рейтингах в файл описания игры (GDF). Все доступные данные оценок должны быть включены в каждую локализованную версию GDF, а также в версию, нейтральную на языке.
  • Игры должны перечислять свои исполняемые файлы в GDF, чтобы обеспечить хороший пользовательский интерфейс для общих ограничений приложений, если игра не использует технологию защиты от пиратства, которая создает случайным образом именованные исполняемые файлы во время выполнения.
  • Игры должны вызывать метод VerifyAccess интерфейса Обозревателя игр при запуске, если он доступен, и завершать работу, если он возвратит *pfHasAccess значение FALSE.

Логическое обоснование

Все игры должны выполняться в контексте учетной записи стандартного пользователя, чтобы разрешить учетные записи, контролируемые родительскими элементами управления Windows, играть в игру. Родители хотят иметь возможность отслеживать и контролировать доступ своих детей к играм. Кроме того, многочисленные отраслевые, государственные и пропагандистские группы хотят лучше, чтобы родители могли отслеживать и контролировать игры, к которым подвергаются их дети. В сочетании с архитектурой, предлагаемой Games Explorer, корпорация Майкрософт предоставляет родителям эту возможность с помощью Родительского контроля Windows.

Даже для игр, которые не участвуют в рейтинговых системах, необходимость в повышенных привилегиях создает плохой игровой опыт для большинства пользователей. Это особенно касается включения родительских элементов управления, для которых родитель должен ввести пароль администратора при каждом запуске игры.

Система управления родительскими элементами Windows позволяет родителям выбирать рейтинги, которые они считают подходящими для своих детей. Родительские средства контроля поддерживают многие из мировых систем рейтингов. Родительский контроль также позволяет родителям ограничить доступ к играм на основе дескрипторов содержимого (если соответствующая система рейтингов поддерживает их) и разрешить или запретить доступ к отдельным играм.

Выбор системы оценки по умолчанию для родительского контроля Windows основан на настройках языкового стандарта системы, но может быть изменен пользователем в региональных и языковых параметрах в Панели управления. Таким образом, каждый поддерживаемый язык должен предоставлять все доступные данные о рейтингах, чтобы пользователь был свободен выбрать любой совет рейтингов, который они хотят.

Дополнительная информация

Игры без рейтинга по-прежнему должны соответствовать требованиям для поддержки игры в качестве стандартного пользователя и вызова VerifyAccess. Такие игры по стандарту относятся к категории "Не оцененные", отображают текст "Нет оценки" в Games Explorer и подпадают под параметры "Ограничения игры" в "Родительском контроле" для игр без оценки. Параметр ограничений по умолчанию — Allow.

Сведения о рейтинге в GDF будут игнорироваться, если содержащий двоичный файл не является должным образом подписанным Authenticode. См. требование 2.3.

Редактор файла определения игры в пакете SDK DirectX включает все поддерживаемые системы рейтингов и правильно реплицирует эти сведения ко всем локализованным версиям GDF, а также языковой нейтральной версии. Средство GDFTrace декодирует и проверяет все сведения о рейтингах. Используйте версию август 2009 г. или более позднюю версию этих средств.

GDF для поставщика игр обычно не содержит сведений о рейтинге и зависит от настроек для контента без рейтинга.

Операционная система Поддерживаемые системы оценки
Windows Vista
  • CERO (Япония)
  • ESRB (США)
  • OFLC (Австралия)
  • PEGI (Европа)
  • PEGI Финляндия (не рекомендуется)
  • PEGI Португалия
  • PEGI/BBFC (Соединенное Королевство)
  • USK (Германия)
Windows Vista с пакетом обновления Пакеты обновления для Windows Vista добавляют поддержку следующих компонентов:
  • GRB (Южная Корея)
  • Варианты дескрипторов содержимого ESRB "Mild"
Windows 7 Windows 7 поддерживает системы рейтингов, поддерживаемые Windows Vista, и добавляет поддержку следующих компонентов:
  • CSRR (Тайвань)
Windows 8 Windows 8 поддерживает предыдущие системы оценки и добавляет поддержку следующих компонентов:
  • COB-AU (Австралия)
  • DJCTQ (Бразилия)
  • PFB (Южная Африка)
  • OFLC-NZ (Новая Зеландия)
Windows 8 не поддерживает следующие устаревшие системы:
  • PEGI-FI (Финляндия)
  • OFLC (Австралия)

Примечание.

Любая игра, включающая новые дескрипторы содержимого ESRB для Windows Vista с пакетом обновления 1 (SP1), будет отображаться как без рейтинга в Windows Vista без пакета обновления.

Более новые данные о рейтингах игнорируются в версиях операционных систем, не имеющих поддержки для них. В настоящее время вариант PEGI (Финляндия) устарел в пользу стандартной системы рейтингов PEGI (Европа). Система OFLC в настоящее время устарела в пользу COB-AU для Австралии.

Дополнительные сведения о том, как сделать игру совместимой со стандартными привилегиями пользователей, см. в статье DirectX "Управление учетными записями пользователей для разработчиков игр".

Дополнительные сведения о файле определения игры (GDF) см. в описании требования 1.1.

1.3 Поддержка богатых сохраненных игр

[Это требование прекращено]

1.4 Поддерживает общий контроллер Xbox 360 для Windows [условное требование]

Требование

Игры, поддерживающие контроллеры геймпадов, должны поддерживать контроллер Xbox 360 для Windows с помощью API XInput . Если также поддерживаются периферийные устройства DirectInput, можно также использовать DirectInput. Однако XInput должен быть API по умолчанию, если используется устройство, совместимое с Xbox 360.

Все ссылки на общие триггеры контроллера и кнопки должны использовать имена Xbox 360. Дополнительные сведения см. в списке распространенных контроллеров Xbox 360 для терминологии Windows.

Вибрация контроллера должна быть отключена, когда игра находится в паузе или приостановке.

Управление мышью и клавиатурой не может быть полностью отключено в любое время. Как минимум, должен быть доступен вариант возврата в игровые меню.

Логическое обоснование

Это требование дает игрокам свободу выбора, чтобы использовать контроллер Xbox 360 или клавиатуру и мышь, в зависимости от того, какой метод ввода более естественный и интуитивно понятный интерфейс.

Дополнительная информация

Это требование не применяется к играм, которые используют только мышь и /или клавиатуру.

Мы рекомендуем реализовать навигацию по меню, чтобы использовать широко принятые стандартные кнопки контроллера:

  • A — Принять
  • B - Отмена
  • Пуск — принятие или приостановка
  • Назад — отменить, вернуться на один экран или вверх по уровню меню

Дополнительные сведения см. в разделе XInput.

В разделе XInput и DirectInput рассматриваются проблемы с использованием обоих API одновременно.

Рекомендуется не использовать DirectInput для реализации элементов управления клавиатурой или мышью. Элементы управления клавиатурой и мышью должны быть реализованы только с помощью сообщений Windows и API Win32. Дополнительные сведения о получении сведений о движении мыши с высоким разрешением без использования DirectInput см. в разделе "Преимущества перемещения мыши с высоким определением".

Поддерживать несколько форматов пропорций и разрешений

Требование

Игра должна поддерживать по крайней мере следующие пропорции и связанные разрешения экрана:

  • 4:3 нормально (800 600 или 1024 768)
  • 16:9 широкий экран (1280 720)
  • 16:10 широкий экран (1152 720 или 1680 1050 или 800 480)

Для настройки разрешения экрана и обнаружения игра должна соответствовать следующим правилам:

  • Игра использует разрешение на рабочем столе устройства дисплея по умолчанию, если это поддерживаемое разрешение. Пропорции рабочего стола должны использоваться в качестве критерия поиска, если игра выбирает другое разрешение по умолчанию.
  • Игра должна предложить пользователю подтвердить новые параметры отображения при изменении. Если пользователь не принимает в течение 15 секунд, дисплей должен вернуться к предыдущему параметру.
  • Игра не должна растягивать пиксели или располагать по центру окно 4:3, чтобы поддерживать широкоэкранные пропорции. Тем не менее, форматирование в стиле "letterboxing" является приемлемым.

Логическое обоснование

При использовании рабочего стола Windows 3D нельзя предположить определенное соотношение аспектов или разрешение из-за следующих факторов:

  • Поддержка отображения высокой детализации.
  • Увеличение доли рынка широкоэкранных мониторов.
  • Внедрение HDTV для Windows Media Center.
  • Требования по доступности.

Дополнительная информация

В идеале игра по умолчанию использует родное соотношение сторон дисплея. Однако надежное получение этой информации может быть проблемой, поэтому в качестве более общего решения игра может предположить, что рабочий стол работает в собственном соотношении сторон. Разрешение рабочего стола можно получить путем вызова EnumDisplaySettings с ENUM_REGISTRY_SETTINGS.

Дополнительные сведения см. в разделах "Соотношение сторон" и "Широкоэкранный формат" статьи Введение в 10-футовый интерфейс Windows для разработчиков игр DirectX.

Запуск поддержки 1.6 из Windows Media Center

[Это требование было прекращено.]

Поддержка Direct3D 1.7

Требование

Если в игре используется Direct3D, минимальная версия должна быть Direct3D 9, а Direct3D должна быть выбранной отрисовщиком по умолчанию.

Логическое обоснование

Архитектура графики Windows Vista и Windows 7 предназначена для Direct3D. Direct3D 8 и более ранние версии поддерживаются через преобразование устаревших интерфейсов.

Использование версий Direct3D более поздних версий, чем Direct3D 9, настоятельно рекомендуется. См. игры для Windows Showcase S.1. Требование Direct3D 10 или Direct3D 11 полностью соответствует требованиям 1.7.

1.8 Включение поддержки высокой четкости (DPI)

Требование

Игры и их установщики должны работать правильно без визуальных проблем при включении масштабирования точек на дюйм (DPI) (протестировано с 144 DPI для 150 % масштабирования при разрешении отображения 1600 1200) в Windows Vista и Windows 7.

Обычно для этого требуется, чтобы исполняемый файл игры указывал поддержку DPI. Для достижения этого необходимо встроить элемент манифеста: <dpiAware>true<dpiAware>.

Логическое обоснование

Высококачественные мониторы LCD являются распространенными в качестве отображения компьютера, и они лучше всего выглядят при их собственных разрешениях (как правило, 1280 1024, 1600 1200 и т. д.). Клиенты, которые испытывают трудности с чтением текста и с просмотром изображений в этом разрешении, часто устанавливают рабочие столы компьютеров на более низкое разрешение и испытывают визуальные артефакты от масштабирования на ЖК-дисплеях. Вместо этого клиенты могут оставить разрешение в собственном размере и изменить DPI дисплея Windows, что делает элемент и текст более большим, не жертвуя качеством изображения.

Хотя эта функция доступна в некоторой форме с Windows XP, она редко включается клиентами или изготовителами оборудования. Более половины всех дисплеев компьютеров сегодня настроены на более низкое разрешение, чем их естественное разрешение, согласно отзывам клиентов. Windows 7 делает эту функцию гораздо более видимой для клиентов во время начальной настройки и при изменении параметров отображения, поощряя их использовать масштабирование DPI, а не изменять разрешение рабочего стола.

Дополнительная информация

Вместо этого можно использовать функцию SetProcessDPIAware, если она вызывается в начале кода запуска процесса. Добавление в манифест предпочтительнее, чтобы гарантировать отсутствие условий гонки с программными элементами (например, библиотеки DLL), которые могут инициализироваться до вызова основной точки входа. Обратите внимание, что SetProcessDPIAware присутствует только в Windows Vista и Windows 7.

Добавление элемента манифеста легко сделать с Помощью Visual Studio 2005 и 2008; создайте файл с именем dpiaware.manifest, содержащий следующий текст:

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

Затем в Visual Studio добавьте dpiware.manifest в проект. Убедитесь, что параметр Встраивание манифеста установлен на Да в свойствах проекта. Обратите внимание, что старые версии средства манифеста (Mt.exe) создадут ложное предупреждение с элементами манифеста, поддерживающими DPI. Чтобы устранить эту проблему, обновите Mt.exe до последней версии из пакета SDK для Windows.

Visual Studio 2010 включает параметр в свойствах проекта с именем Enable DPI Awareness, который устраняет необходимость в файле, например dpiaware.manifest. Найдите функцию "Включить осведомленность о DPI", расширив свойства конфигурации и инструмент манифеста, а затем выбрав входные и выходные данные.

В Windows традиционный режим отображения по умолчанию используется в 96 DPI, что было распространено для мониторов CRT.

Хотя полноэкранные приложения изменяют разрешение дисплея, они часто используют сообщения окна и метрики при настройке буферов и отображения прямоугольников. Виртуализация DPI приводит к тому, что эти полноэкранные режимы отображения становятся обрезанными, и установка параметра "осведомленность о DPI" поможет предотвратить эти проблемы. Дополнительные сведения см. в статье "Написание приложений Win32 с поддержкой DPI".

Безопасность и совместимость

Сводка требований к безопасности и совместимости

Преимущества клиентов

Следующие требования повышают общую безопасность игр и помогают обеспечить работу с Windows на разных архитектурах, в разных конфигурациях и в разных режимах.

2.1 Следуйте рекомендациям по управлению учетными записями пользователей

Требование

Каждый исполняемый файл (т. е. каждый файл с расширением .exe) должен содержать внедренный манифест, определяющий уровень выполнения, включая следующий тег:

            <requestedExecutionLevel>

В соответствии с требованием 1.2, основная игра и исполняемый файл Autorun должны иметь уровень выполнения «asInvoker» для работы в стандартных пользовательских контекстах.

Файлы данных пользователя, имеющие ассоциации файлов с Проводником, должны быть помещены в вложенную папку в папке, указанной в CSIDL_PERSONAL (также называемой «Документы» или «Мои документы»). Все остальные файлы данных пользователя должны храниться в подпапке папок, которые указаны CSIDL_LOCAL_APPDATA или CSIDL_COMMON_APPDATA. (Эти каталоги скрыты по умолчанию для отдельных пользователей и для всех пользователей.)

Логическое обоснование

Взаимодействие с Windows пользователя более безопасно, если приложения выполняются только с необходимыми разрешениями.

Дополнительная информация

Если в приложении требуются только некоторые функции с правами администратора (например, приложение, необходимое для настройки брандмауэра), основной процесс приложения по-прежнему должен выполняться с помощью стандартных привилегий пользователя. Компоненты, требующие прав администратора, необходимо переместить в отдельный процесс, например установщик или служебную программу конфигурации.

Если права администратора не требуются, внедренный XML-код манифеста должен содержать следующее:

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

Если требуются права администратора, внедренный XML манифеста должен содержать следующее:

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

С помощью Visual Studio 2005 это легко интегрируется, просто добавив файл манифеста (.manifest), содержащий один из предыдущих блоков в проект. Также удостоверьтесь, что встраивание манифеста установлено в значение "Да" в свойствах проекта для средства манифеста. Для Visual Studio 2008 и 2010 можно установить свойства UAC непосредственно в свойствах проекта для компоновщика на странице манифестного файла. Обратите внимание, что старые версии инструмента работы с манифестами (Mt.exe) создают ложное предупреждение с элементами манифеста UAC. Чтобы устранить эту проблему, обновите Mt.exe до последней версии из пакета SDK для Windows.

Дополнительные сведения об установке, исправлении и удалении см. в требованиях 3.1.

Библиотеки динамических ссылок (DLL) не требуют таких манифестов.

Дополнительные сведения об управлении учетными записями пользователей см. в разделе "Управление учетными записями пользователей" для разработчиков игр.

2.2 Поддержка версий Windows x64

Требование

Для обеспечения совместимости с 64-разрядными выпусками Windows игры должны соответствовать следующим требованиям.

  • Заголовки и установщики заголовков не должны содержать 16-разрядный код или полагаться на любой 16-разрядный компонент.
  • Если игра зависит от драйверов в режиме ядра для операций, должны быть доступны версии x64 этих драйверов. Программа установки игры должна обнаруживать и устанавливать соответствующие драйверы и компоненты для 64-разрядных выпусков Windows.

Логическое обоснование

Многие пользователи Windows Vista и Windows 7 будут запускать 64-разрядные выпуски операционной системы в течение всего времени существования продукта, поэтому важно, чтобы приложения были совместимы с этой операционной системой.

Дополнительная информация

Windows в Windows 64 (WOW64) позволяет 32-разрядному коду работать в 64-разрядных выпусках Windows, поэтому не обязательно, чтобы приложение было собственным 64-разрядным кодом в 64-разрядных выпусках Windows. Шестнадцатиразрядный код не выполняется в 64-разрядных версиях Windows.

Поддержка совместимости с Windows XP Professional x64 Edition не требуется, но настоятельно рекомендуется.

Для получения подробной информации см. 64-разрядное программирование для разработчиков игр.

2.3 Файлы подписи

Требование

Все исполняемые файлы кода (как правило, файлы с расширением .exe или .dll) должны быть подписаны действительным общедоступным сертификатом Authenticode и должны иметь допустимый URL-адрес сервера метки времени для подписания в рабочей среде.

Если в игре используется установщик Windows, необходимо подписать файлы пакета установщика (.msi файлы).

Логическое обоснование

Подписывание файла помогает пользователям решить, следует ли доверять приложению, и гарантирует пользователям, что файлы не были изменены. Он также позволяет приложениям правильно работать в заблокированных средах.

Дополнительная информация

Дополнительные сведения см. в разделе "Подписывание Authenticode для разработчиков игр".

Если ваша игра использует установщик Windows, мы рекомендуем включить поддержку UAC/LUA, добавив таблицу MsiPatchCertificate. Для получения дополнительной информации см. Патчинг управления учетными записями пользователей (UAC).

Мы не рекомендуем подписывать файлы (.cab), если они не являются относительно небольшими (менее 100 МБ).

2.4 Драйверы подписей

Требование

Любой драйвер в режиме ядра, установленный игрой, должен быть подписан с общедоступным действительным сертификатом Authenticode.

Любой драйвер аппаратного устройства в режиме ядра, установленный игрой, должен иметь подпись Майкрософт, которая может быть получена из программы "Лаборатории качества оборудования Windows" (WHQL) или из программы сигнатуры надежности драйвера (DRS).

Логическое обоснование

Плохо написанные или вредоносные драйверы могут сильно повлиять на стабильность и безопасность системы. В 64-разрядных выпусках Windows Vista и Windows 7 не загружаются неподписанные драйверы. Эта политика также может быть включена для 32-разрядных выпусков Windows Vista и Windows 7.

Дополнительная информация

Требуются 32-разрядные и 64-разрядные версии всех драйверов в режиме ядра для каждого требования 2.2.

Дополнительные сведения о программах подписывания драйверов Майкрософт см. в Центр разработки оборудования Windows.

2.5. Проверка правильной версии

Требование

Игры не должны переставать выполняться в будущих операционных системах, как указано изменениями в номере версии Windows, если лицензионное соглашение конечного пользователя запрещает использование в будущих операционных системах. Если игра должна завершиться ошибкой, она должна сделать это корректно, показывая соответствующее сообщение пользователю.

Если проверка версий Windows выполняется, для проверки версии необходимо использовать API проверки версий (GetVersionEx или VerifyVersionInfo). Ключи реестра не должны использоваться для определения версии.

Явные проверки версий для среды выполнения DirectX не должны присутствовать в игре. Эти проверки версий не должны присутствовать в установке, которая запускает программу установки среды выполнения DirectX (DirectSetup).

Логическое обоснование

Когда пользователи Windows обновляют свои операционные системы, им не должно быть запрещено играть в текущие игры только потому что версия Windows изменилась. Плохо написанные средства проверки версий продолжают создавать проблемы для программного обеспечения, которое, в противном случае, работает хорошо над более новыми версиями Windows или просто с добавлением пакета обновления Windows.

Хрупкая логика проверки версии для среды выполнения DirectX привела к многочисленным неудачным установкам при запуске на различных версиях Windows. Номер версии DirectX применяется только к основным компонентам операционной системы. Он не применяется к компонентам пакета SDK DirectX, работающим в режиме side-by-side, которые используются многими играми.

Дополнительная информация

Обычно установщики проверяют минимальную версию ОС. Однако эта проверка должна быть выполнена с осторожностью, чтобы убедиться, что она проверяет наличие большего или равного, а не простого равенства, тем самым блокируя определенную версию операционной системы. С помощью теста HighVersionLie средства проверки приложений можно быстро и легко определить, как установщик будет реагировать на значительное изменение номера версии ОС.

Правильное использование пакета распространения среды выполнения DirectX (программа установки DirectX) включает всегда запускать его во время установки, предпочтительно в автоматическом режиме. Это позволяет коду, предоставленному Microsoft, выполнять любые необходимые обновления версий. Он также позволяет устанавливать любые необязательные компоненты пакета SDK DirectX, такие как D3DX, XACT, MDX или XInput.

Рекомендации по развертыванию среды выполнения DirectX см. в разделе "Установка DirectX для разработчиков игр".

Рекомендуется, чтобы игры, поддерживающие windows XP, проверяли уровень пакета обновления 2 или выше, так как пакет обновления 2 (SP2) и пакет обновления 3 (SP3) обеспечивают значительные улучшения безопасности, упрощенное требование к распространению среды выполнения DirectX и чрезвычайно широкое развертывание. Большинство современных технологий Майкрософт, поддерживающих Windows XP, требуют sp2 или SP3 (XAudio2, Игры для Windows — LIVE и т. д.).

2.6 Поддерживает одновременные сеансы пользователей

Требование

Игры, использующие трехмерную графику, не обязаны работать через подключение к удаленному рабочему столу, но пользователь должен быть оповещен, когда игра не работает.

Игры должны поддерживать стандартные сценарии многозадачности Windows, следуя следующим правилам:

  • Игры не должны блокировать использование одновременных сеансов пользователей.
  • Игра должна выполняться в новом сеансе пользователя, когда она уже запущена в другом сеансе.
  • Звук игры в одном сеансе пользователя не должен быть услышан, когда другой пользователь активен в другом сеансе.
  • Игры должны поддерживать быстрое переключение пользователей.
  • Игры не должны пытаться отключить стандартное переключение задач. Игры не должны отключать сочетание клавиш ALT+TAB. Игры могут отключать сочетания клавиш специальных возможностей, как описано в разделе "Отключение сочетаний клавиш в играх".

Логическое обоснование

Пользователи Windows должны выполнять одновременные сеансы без конфликтов или нарушений. Это распространенный сценарий для компьютера Windows, совместно используемого семьей, товарищами по комнате или другими пользователями.

Дополнительная информация

Чтобы проверить, запущена ли игра в удаленном сеансе, вызовите GetSystemMetrics(SM_REMOTESESSION). Значение, отличное от нуля, указывает, что сеанс удалённый.

Дополнительные сведения см. в разделе "Быстрое переключение пользователей". Обратите внимание, что быстрое переключение пользователей происходит, если ограничения времени родительского контроля включены, когда время пользователя истекает. Дополнительные сведения см. в описании требования 1.2.

2.7 поддерживает длинные имена

Требование

Если игра поддерживает сохранение файлов, она должна иметь возможность сохранять файлы с длинными именами и путями. Игра должна правильно обрабатывать специальные символы файловой системы, такие как \ / : * ? " <>в любых полях ввода пользователя, которые используются для создания имен файлов или путей.

Игры должны работать правильно, если у пользователя есть длинное имя пользователя.

Логическое обоснование

Игроки привыкли использовать длинные имена на глубоких путях, поддерживаемых базовой операционной системой.

Дополнительная информация

Длинные имена определяются как те, которые содержат максимальные значения, определенные в пакете SDK для Windows.

Установка

Сводка требований к безопасности и совместимости

Преимущества клиентов

Клиенты могут быть уверены, что приложения будут устанавливаться в Windows, не ухудшая операционную систему или другие приложения, если приложения используют официальные методы распространения компонентов системы. Упрощенная установка обеспечивает более доступный и беспроблемный процесс первого запуска игр.

3.1 Поддержка простой установки

Требование

Игры должны предоставлять упрощенный путь в пользовательском интерфейсе установки, реализуя следующее:

  • Отображать не более одного запроса на принятие лицензионного соглашения.
  • Путь установки по умолчанию должен пропустить все варианты выбора для установки (например, папки установки или выбор компонентов), использовать выбор по умолчанию, а затем запустить игру или средство запуска после успешной установки без дополнительных запросов. При необходимости можно указать настраиваемый параметр установки для дополнительных параметров конфигурации.
  • Установите все необходимые компоненты операционной системы (например, среды выполнения DirectX и Visual C) с помощью правильных пакетов распространения Майкрософт. Установка должна выполняться автоматически без запроса и без проверки версий компонентов.
  • Предоставление удаления через программы и компоненты в панель управления для игрового приложения и созданных рабочих файлов. Рекомендуется удалить все файлы данных, созданные пользователем. Процесс удаления должен обеспечить удаление всех установленных файлов и очистку всех параметров (например, записей списка исключений брандмауэра и разделов реестра). Компоненты операционной системы, подлежащие распространению, не должны удаляться.
  • Если игра требует добавления исключений в брандмауэр Windows, процесс установки может предложить пользователям сообщить о необходимости этого изменения. Этот запрос должен появиться перед началом установки.

Установка и удаление могут требовать права администратора. Исправление может потребовать запроса на получение учетных данных администратора в зависимости от частоты обновления. Обычная игра в игре не должна требовать прав администратора, в соответствии с требованием 2.1 следуйте рекомендациям по управлению учетными записями пользователей.

Логическое обоснование

Простая установка — это философия разработки игр, ориентированной на Windows, которая предназначена для упрощения и упрощения иногда мученного и запутанного процесса установки игр на компьютерах под управлением операционных систем Windows. Простая установка включается с помощью набора технологий и рекомендаций, которые снижают ненужную сложность и предполагаемый риск установки игр на компьютерах Windows.

Ключевыми целями являются следующие задачи.

  • Сократите время на вход в игру и начало игры.
  • Уменьшите количество диалоговых окон и вариантов до очень мало или нет, чтобы упростить установку игры.

Некоторые традиционные установки имеют запросы, разрешающие нефункциональную установку, даже если приложение, как представляется, успешно установлено. Например, игра может требовать от пользователя принять EULA. Сначала будет установлена игра, а затем появится лицензионное соглашение DirectX. Этот лицензионный договор позволяет пользователям отказаться и, таким образом, пропустить установку среды выполнения DirectX. Этот сценарий может привести к тому, что игра не выполняется из-за отсутствующих компонентов.

Дополнительная информация

Дополнительные сведения об установке игр, не традиционных способах установки игр, решениях исправления, совместимых с UAC, и об обработке частых исправлений см. в следующих статьях DirectX:

Примечание.

Удаление созданных пользователем файлов данных должно выполняться только для текущего пользователя и для общих расположений пользователей. Нет надежного способа сканирования системы, чтобы удалить файлы, относящиеся к пользователю, для других пользователей, даже если удаление требует административных учетных данных.

3.2 Поддержка управления учетными записями пользователей для установки

Требование

Установщик игры не должен предполагать, что он работает в том же контексте, что и пользователь. Расположения, относящиеся к пользователю, будут отличаться от установщика и проигрывателя даже для однопользовательских систем из-за повышения прав администратора. Поэтому при первом запуске игры она должна выполнять определенные пользователем задачи отдельно от процесса установки.

Диалоговое окно исключения брандмауэра Windows не должно отображаться, когда пользователь размещает или присоединяется к многопользовательской игре. Любая требуемая конфигурация должна выполняться во время установки. Инструкции по настройке должны сообщить пользователю, что эта операция будет выполняться в процессе установки.

Установщик игры должен предоставить внедренный манифест, указывающий необходимый уровень выполнения, в соответствии с требованием 2.1 Следуйте рекомендациям по управлению учетными записями пользователей.

Если игра запускается установщиком после завершения установки, она должна быть запущена в контексте исходного пользователя.

Логическое обоснование

Одним из крупнейших изменений в операционной системе Windows в Windows Vista является добавление контроля учетных записей пользователей (UAC), которое запускает приложения с ограниченными привилегиями по умолчанию. В результате установщики должны соответствующим образом управлять уровнями привилегий. Windows 7 также широко использует UAC. Хотя Windows 7 улучшает пользовательский интерфейс UAC, установщики по-прежнему должны соответствовать тем же требованиям, что и в Windows Vista для правильной работы, не полагаясь на потенциально запутанное поведение виртуализации.

UAC активна по умолчанию в Windows Vista и Windows 7, и подавляющее большинство клиентов (88% или более, согласно отзывам) оставляют эту функцию включенной.

Дополнительная информация

Дополнительные сведения о настройке брандмауэра Windows см. в статье Брандмауэр Windows для разработчиков игр и пример брандмауэра FirewallInstallHelper.

Стандартный запуск игры в конце процесса установки не соответствует последнему аспекту этого требования, если установка запускается стандартным пользователем, и если процесс установки требует прав администратора (то есть запрашивает учетные данные администратора). Он также наследует права администратора, что является потенциальным риском безопасности. Вместо этого программа начальной загрузки должна запустить игру после успешного вызова установщика. Для получения дополнительной информации смотрите статью журнала MSDN Magazine Teach Your Apps to Play Nicely with Windows Vista User Account Control.

3.3. Установка в правильные папки

Требование

Игры, установленные для всех пользователей, должны быть установлены в папку Program Files по умолчанию. Пользовательские данные должны быть записаны при первом запуске игры, а не во время установки.

Логическое обоснование

Пользователи должны иметь гибкость для установки приложений, где им нужны. Они также должны иметь согласованный и безопасный интерфейс с расположением файлов по умолчанию.

Дополнительная информация

Игры могут использовать различные известные расположения папок (например, указанные CSIDL_LOCAL_APPDATA и CSIDL_COMMON_APPDATA) для хранения значительных объемов игровых данных и вспомогательных исполняемых файлов для реализации расширенных сценариев установки по запросу и исправлений.

Поскольку при установке может потребоваться переключение на другую учетную запись пользователя во время процесса установки для всех пользователей, нет подходящего места для хранения данных во время установки. Кроме того, если шифрование файлов включено, зашифрованные файлы можно получить только с помощью учетной записи пользователя, созданной им.

3.4 Правильно установите ресурсы Windows

Требование

Приложения не должны пытаться установить файлы или разделы реестра, защищенные Защитой ресурсов Windows (WRP). Если приложению требуются более новые версии системных компонентов, необходимо обновить эти компоненты с помощью пакета обновления Майкрософт или утвержденного корпорацией Майкрософт пакета установки, содержащего системный компонент. Системные компоненты никогда не должны быть перепаковыты.

Логическое обоснование

Защита ресурсов Windows (WRP) предназначена для обеспечения обновления защищенных системных ресурсов только с помощью утвержденных корпорацией Майкрософт механизмов установки или обновления. WRP повышает надежность системы, гарантируя, что результаты установки прогнозируются.

Дополнительная информация

WRP является преемником защиты файлов Windows, который защищает большинство системных компонентов, установленных в папке Windows. WRP защищает большинство разделов реестра, которые хранят параметры для создания COM-объектов. Он также резервирует определенные папки для использования исключительно операционной системой. Попытки доступа к защищенным ресурсам обычно приводят к ошибке отказа доступа.

Для получения сведений о лучших практиках развертывания среды выполнения DirectX с игрой см. статью DirectX Installation for Game Developers.

3.5 Избегайте перезагрузки во время установки

Требование

Установщик игр не должен предполагать, что установка компонентов Windows из пакетов распространения требует перезагрузки, если перезагрузка не указана результатом возврата или документацией Майкрософт.

Если установщик игры всегда заставляет перезагрузку, это должно быть одобрено корпорацией Майкрософт.

Диалоговые окна использования файлов, включенные в пакеты установщика Windows, должны содержать параметр автоматического закрытия приложений и попытки перезапустить их после завершения установки.

Логическое обоснование

Перезагрузка системы после установки является неудобным нарушением для пользователей и обычно не требуется.

Дополнительная информация

Дополнительные сведения см. в разделе "Использование установщика Windows с диспетчером перезапуска".

3.6 Правильно использовать управление версиями файлов

Требование

Программа установки игр должна правильно проверить, что установлены последние версии файлов. Установка игры никогда не должна заменять любые файлы, которые вы не производите, или которые совместно используются с приложениями, которые вы не производите.

Логическое обоснование

Общие компоненты и системные компоненты часто обновляются для исправлений безопасности и расширенных функциональных возможностей. Установка, содержащая более раннюю версию обновленных компонентов, не должна привести к потере обновлений и исправлений, которые уже применены.

3.7 Поддержка автоматического запуска [условное требование]

Требование

Для игр, распределенных на компакт-диске, DVD-диске или других съемных носителях, поддерживающих автозапуск, когда диск вставляется в первый раз, приложение должно автоматически запускать или запрашивать у пользователя установку игры, если пользователь не отключил функцию автоматического запуска.

После успешной установки приложения повторное вставление диска в привод не должно привести к автоматическому запуску установки. Можно попросить пользователей обновить или изменить варианты установки.

Приложение автозапуска не должно запрашивать повышение прав (т. е. оно должно иметь asInvoker в манифесте согласно требованию 2.1), хотя оно может запустить программу установки или другую служебную программу, требующую прав администратора. Запрос на повышение привилегий должен происходить только в том случае, если игра не установлена или если пользователь специально выбирает это.

Логическое обоснование

Автоматическое выполнение упрощает использование распределенных мультимедиа приложений, таких как игры, которые обычно требуют, чтобы диск присутствовал на диске, чтобы играть в игру.

Дополнительная информация

Не допускается требовать, чтобы пользователь использовал Проводник для запуска установки с CD-диска или DVD-диска.

Для игр, распределенных на нескольких дисках, последующие диски должны в идеале использовать функцию автоматического запуска или продолжить установку без запроса пользователя нажать клавишу или выполнить другое действие.

При создании программы автоматического запуска убедитесь, что все необходимые компоненты присутствуют в свежих установках Windows. Типичные приложения зависят от технологий, установленных программой установки, но Автозапуск осуществляется до какой-либо такой настройки. Одним из распространенных примеров является сбой программ автоматического запуска, так как библиотеки DLL среды выполнения Visual C не были включены в программу установки Windows. Поэтому программа автоматического запуска должна использовать локальное развертывание CRT приложения или статически связать CRT.

Программы автоматического запуска, написанные для использования в версиях Windows до Windows Vista, не должны использовать среду выполнения .NET, так как эта технология не входит в состав Windows XP или более ранних версий Windows. Windows Server 2003 и Windows Vista — это первые версии Windows, которые включают среду выполнения .NET в состав своей операционной системы.

По аналогичным причинам программы автоматического запуска не могут требовать наличия дополнительных компонентов пакета SDK DirectX, таких как D3DX9, D3DX10, D3DX11, XAudio2, X3DAudio, XACT, XINPUT и MDX 1.1.

Пример использования автозапуска см. в разделе "Пример автозапуска".

Надежность

Сводка требований к безопасности и совместимости

Преимущества клиентов

Эти требования делают приложение более надежным путем минимизации количества сбоев, зависания и перезагрузки. Требования к надежности могут помочь гарантировать, что программное обеспечение является более предсказуемым, обслуживаемым, устойчивым и восстанавливаемым.

4.1 Устранение ненужных перезагрузк

Требование

Все установщики приложений должны воспользоваться API диспетчера перезапуска, чтобы избежать перезагрузки системы (см. требование 3.5).

Игры не должны блокировать завершение работы.

Все приложения должны отвечать менеджеру перезапуска, слушая и реагируя на следующие сообщения о завершении работы:

WM_QUERYENDSESSION с LPARAM = ENDSESSION_CLOSEAPP (0x1)

Приложения графического интерфейса должны немедленно реагировать (TRUE) при подготовке к перезапуску.

WM_ENDSESSION: LPARAM = ENDSESSION_CLOSEAPP (0x1)

Приложения должны возвращать значение 0 в течение 5 секунд, а затем закрыть.

CTRL+C

Консольные приложения, получающие это сообщение, должны немедленно закрыться.

Логическое обоснование

Перезагрузки системы являются серьезным нарушением. Они приводят к плохому интерфейсу пользователя и должны быть сведены к минимуму. Для некоторых операций, таких как критически важные обновления системы, могут потребоваться перезагрузки. Прослушивая сообщения о завершении работы, игра и другие приложения могут оперативно реагировать на запросы от диспетчера перезапуска. Таким образом, они могут избежать ненужных задержек в допустимых запросах перезагрузки.

Дополнительная информация

Если установщик игр использует технологию установщика Windows (MSI) без пользовательских действий, эта функция предоставляется автоматически. Пакеты распространения Майкрософт также поддерживают диспетчер перезапуска.

Дополнительные сведения о диспетчере перезапуска см. в разделе "О диспетчере перезапуска".

4.2 Устранение сбоев проверяющего приложения

Требование

Игра не должна приводить к ошибкам при запуске в среде Microsoft Application Verifier (AppVerifier) версии 4.0 или более поздней версии в следующих тестах:

  • Основы: дескрипторы, кучи, блокировки, память, TLS
  • Прочие: DangerousAPIs, DirtyStacks

Логическое обоснование

AppVerifier проводит тесты на наличие многих известных проблем, вызывающих сбои и зависания в приложениях Windows, а также проверяет на уязвимости безопасности.

Дополнительная информация

Дополнительные сведения о средстве проверки приложений см. в разделе "Проверка приложений" и "Использование средства проверки приложений" в рамках жизненного цикла разработки программного обеспечения.

Это требование не применяется к чистым управляемым приложениям без собственного взаимодействия.

Эти тесты должны выполняться в релизной версии. Отладка сборок может привести к ложным сбоям. Некоторые антипиратские и анти-обманные технологии могут препятствовать выполнению AppVerifier. Таким образом, эти тесты должны выполняться без поддержки антипиратских и анти-обманных технологий.

Возможно, потребуется задать для свойства Full теста Basics:Heaps значение FALSE, так как полный PageHeap значительно увеличивает давление памяти запущенного приложения. Ошибки по-прежнему будут обнаружены, но их может быть сложнее отслеживать, если вы используете только часть PageHeap.

Если вы используете тесты, связанные с UAC/LUA, в Средство проверки приложений для соответствия требованиям контроля учетных записей пользователей 2.1 и 3.2, следует использовать анализатор стандартного пользователя для просмотра результатов. Существуют также многочисленные полезные тесты, предоставляемые средством проверки приложений, которые настоятельно рекомендуется использовать в разработке и тестировании, чтобы обеспечить высокий уровень совместимости с текущими и будущими версиями Windows. Тест HighVersionLie используется для проверки соответствия требованиям 2.5.

Visual Studio Team System включает подмножество функциональных возможностей AppVerifier, интегрированных в среду отладки. Это может оказаться полезным для отслеживания и устранения проблем с основными тестами: кучи, дескрипторы и блокировки.

4.3 Поддержка системы отчетов об ошибках Windows и информации о версии файла

Требование

Чтобы обеспечить поддержку отчетов об ошибках Windows, игры должны соответствовать следующим требованиям:

  • Игры должны обрабатывать только исключения, известные и ожидаемые. Отчеты об ошибках Windows не должны быть отключены. Если в игре возникает ошибка, например, нарушение доступа, необходимо предоставить системе отчетов об ошибках Windows возможность зарегистрировать сбой.
  • Все исполняемые файлы (например, .exe файлы или библиотеки DLL) должны содержать точное имя продукта, имя компании и версию файла.
  • Обычный выход из игры не должен привести к ошибке из-за неизвестного исключения.

Логическое обоснование

API отчета об ошибках Windows обеспечивают важную обратную связь Microsoft для обнаружения частых сбоев и зависаний в приложениях. Это позволяет корпорации Майкрософт и ее партнерам быстро обнаруживать и устранять проблемы системы и драйвера, которые приводят к сбоям приложений.

Дополнительная информация

Игры могут включать пользовательские обработчики необработанных исключений для выполнения пользовательских функций поддержки и функциональности отчетов, но они должны передавать любые ошибки в функции ReportFault или WerReportSubmit.

Правильные сведения о версии файла можно проверить, просмотрев свойства файла в классическом пользовательском интерфейсе Windows и проверив страницу свойств version.

Для получения дополнительной информации об API Windows Error Reporting и об анализе аварийных дампов, создаваемых при использовании этой службы, см. статью DirectX Анализ аварийных дампов.

Общий контроллер Xbox 360 для терминологии Windows

Имя Описание
а Кнопка A.
Б Кнопка B.
НАЗАД Кнопка "Назад".
Бампер (справа или влево) Кнопка в правом верхнем и левом крае контроллера. Эквивалентно плечевой кнопке.
направление площадки Панель направления контроллера.
D-pad Принятая аббревиатура для крестовины.
DP Сокращенная панель направления и метка контроллера.
RB, LB Сокращения для правого и левого плечевых кнопок и обозначения на контроллере.
RS, LS Сокращения для правого и левого стика и обозначения контроллера.
RT, LT Аббревиатуры и метки контроллера для правого и левого триггеров.
RSB, LSB Сокращения правого и левого джойстика и обозначения на контроллере.
НАЧАЛО Кнопка "Пуск".
(справа/слева) палка Палка контроллера. Ранее джойстик.
кнопка правого/левого джойстика Кнопка стика контроллера. Ранее кнопка джойстика.
Триггер (справа или слева) Триггер контроллера.
Вибрация Обратная связь в игровом процессе, создаваемая мотором контроллера. Не используйте вибрацию.
X Кнопка X.
Y Кнопка Y.
Контроллер Xbox 360 для Windows Геймпад Xbox 360 продается как артикул оборудования для ПК, включая диск с драйверами устройств Windows.
Беспроводной контроллер Xbox 360 для Windows Беспроводной геймпад Xbox 360 продаётся как комплект для ПК, включая диск с драйвером для Windows.

Рекомендации по промежуточному программному обеспечению для игровых продуктов

Введение

Для того чтобы игры соответствовали программе Games for Windows, они должны удовлетворять списку технических требований. Любые сторонние компоненты, поставляемые с заголовком (исполняемые файлы, библиотеки DLL, драйверы и т. д.), также должны соответствовать этим требованиям, чтобы игра соответствовала требованиям. В этом документе описаны наиболее распространенные требования, которые также должны соответствовать сторонним компонентам для игры, чтобы пройти тесты соответствия. Установщики и полные игровые движки/производственные пакеты должны просмотреть полный документ о технических требованиях для игр на Windows, так как многие из этих требований влияют на эти инструменты.

Дополнительные рекомендации

Помимо обеспечения того, чтобы ваш компонент поддерживал создание названий, соответствующих требованиям для игр для Windows, следует учитывать ряд других аспектов, которые следует учитывать при разработке и развертывании библиотеки или служебной программы поддержки для игры Windows.

  • Для поддержки разработчиков, работающих с 64-разрядными приложениями x64, предоставьте 32-разрядные и 64-разрядные версии собственных библиотек. 32-разрядная версия должна быть совместима с 64-разрядной в соответствии с пунктом 2.2. Библиотеки для 32-разрядных приложений не должны предполагать, что старший бит любого 32-разрядного адреса не используется, чтобы обеспечить использование в приложениях x86 LARGEADDRESSAWARE.

  • Если вы предоставляете заголовки исходного кода (C/C++), используйте синтаксис атрибута Standard Annotation Language (SAL), чтобы аннотировать процедуры вашего общедоступного API. Это позволит пользователям библиотеки получить максимальное преимущество использования статического анализа кода (/анализа), который является частью Visual Studio Team System 2005, Visual Studio Team System 2008, Visual Studio 2010 Premium и Visual Studio 2010 Ultimate, а также общедоступных средств компилятора Windows SDK.

  • Если ваш продукт создает потоки в процессе пользователя, обязательно присвойте каждому потоку имя, чтобы средства отладки могли правильно подтвердить выполнение потоков.

  • Если вы пишете подпрограммы, которые должны вызываться в основном цикле игры, используйте подпрограммы D3DX D3DPERF_BeginEvent/EndEvent и D3DPERF_SetMarker для упрощения идентификации узких мест с помощью PIX для Windows.

    Примечание.

    Для графических диагностик в Visual Studio 2012 подпрограммы D3DX и PIX заменены на интерфейс ID3DUserDefinedAnnotation.

  • Для сетевых библиотек предоставьте IP-нейтральные реализации и избегайте использования устаревших только для IPv4 процедур, чтобы поддерживать технологии IPv6 и Teredo в Windows XP с пакетом обновлений 2, Windows Vista и Windows 7.

  • Поставщики игровых услуг должны зарегистрировать себя в Game Explorer с помощью схемы GDF версии 2 и использовать функцию RSS для предоставления новостей, связанных с обслуживанием.

Витрины игр для Windows

Введение

Демонстрации Games for Windows выходят за рамки предоставления полноценного игрового опыта на компьютерах с Windows. Реализуя эти функции, игры могут добавить больше удовольствия к пользовательскому интерфейсу на последних платформах Windows.

Игры для Windows должны соответствовать всем техническим требованиям, перечисленным в этой статье, но демонстрационные функции являются необязательными. Эти проекты могут реализовывать некоторые, ни одну или все из этих демонстраций.

S.1 Эксплойт Direct3D 11

Требование

Direct3D 11 — это API отрисовки следующего поколения для Windows Vista и Windows 7. Игры, использующие Direct3D 11, используют оптимизированное содержимое, расширенные методы отрисовки и новые аппаратные функции, чтобы создать привлекательный интерфейс на оборудовании, поддерживающем 10, 10.1 и 11.

Если игра также реализует Direct3D 9, параллельное сравнение должно продемонстрировать заметное улучшение качества контента, наглядности, производительности, сложности сцены и других областей графической точности для Direct3D 11. Данная поддержка подчиняется требованиям Games for Windows Technical Requirement 1.7.

Технологию Direct3D 10Level9 можно использовать для поддержки шейдерной модели 2.0/3.0 класса Direct3D 9 видеоустройств в Windows Vista и Windows 7, что позволяет избежать необходимости в параллельном использовании Direct3D 9 для широкой поддержки различного оборудования. Однако это недостаточно, чтобы продемонстрировать эту демонстрацию.

На компьютерах под управлением Windows Vista или Windows 7 с установленным Direct3D 11 игра должна по умолчанию использовать Direct3D 11.

Логическое обоснование

API Direct3D 11 основывается на инфраструктуре WDDM и Direct3D 10.1 для поддержки новых возможностей: аппаратной тесселяции, вычислительных шейдеров, многопоточной отрисовки и создания ресурсов, новых форматов сжатия текстур и более гибкого языка шейдеров. Direct3D 11 обеспечивает унифицированную поддержку оборудования для современных видеоадаптеров, включая последнее поколение компонентов Direct3D 11, все видеокарты Direct3D 10 и 10.1, а также многие видеокарты с моделью шейдеров 2.0/3.0 Direct3D 9, что является минимальной видеоконфигурацией, необходимой для рабочего стола Aero 3D.

Дополнительная информация

Перенос обработчика отрисовки Direct3D 9 для использования нового интерфейса Direct3D 11 является четко определенной задачей:

  • Исключите все операции с фиксированными функциями в пользу программируемых шейдеров.
  • Обновите все существующие шейдеры до нового синтаксиса модели шейдера 4.x/5.
  • Обновите управление ресурсами для поддержки новой модели представления.
  • Преобразуйте все ресурсы для использования нового списка доступных форматов.
  • Обновите обработку состояния отрисовки, чтобы использовать неизменяемые блоки состояния, и преобразуйте константы шейдера в буферы констант.

Это преобразование важно для показа Direct3D 11, хотя результат не соответствует требованиям демонстрации использования нового API.

Новый API и связанная модель программирования HLSL предлагает множество возможностей для расширенного содержимого:

  • Использование существующих аппаратных функций Direct3D 10, таких как шейдер геометрии, Stream Out, массивы текстур и форматы сжатия текстур BC4/BC5.
  • Использование существующих аппаратных функций Direct3D 10.1, таких как независимые режимы смешения для каждого целевого рендера, обратное чтение глубины MSAA, доступ к шейдерам MSAA по выборкам, массивы кубических карт и отрисовка в форматы блочно-компрессированных данных (BC).
  • Реализация расширенных алгоритмов GPU с помощью шейдера вычислений с CS4.x на существующих видеокартах Direct3D 10/10.1 (включено обновленными драйверами видео) или CS 5.0 на видеокартах direct3D 11 следующего поколения.
  • Отрисовка на нескольких потоках с помощью создания свободного потока ресурсов и нескольких контекстов устройств для повышения производительности в многоядерных системах (с обновленными драйверами видео). Дополнительные сведения см. в разделе "Игры для Windows Showcase S.3".
  • Использование новых функций видеоустройства класса Direct3D 11, таких как аппаратная тесселяция с шейдерами оболочки и домена, Shader Model 5.0 HLSL, аппаратные возможности BC6H и BC7 для сжатых текстурных форматов и динамическая компоновка шейдеров.

Методы, которые можно реализовать с помощью Direct3D 9, что в значительной степени связано с высокой нагрузкой на ЦП, можно эффективно перенести на GPU, что освобождает ресурсы ЦП для поддержки других требований игры.

API Direct3D 11, вспомогательные средства и примеры доступны в пакете SDK DirectX. Также см. API графики в Windows.

S.2 Эксплойт x64 Native

Требование

Игра включает в себя 64-разрядный исполняемый файл, который обеспечивает захватывающий новый опыт, возможный благодаря выпускам x64 Windows, работающим на оборудовании, поддерживающем x64. Параллельное сравнение с 32-разрядной версией игры должно показать заметное улучшение сложности содержимого, снижение общей нагрузки и производительность.

В 64-разрядных выпусках Windows установка должна всегда настраивать 64-разрядную версию игры в качестве сочетаний клавиш по умолчанию в Game Explorer и Windows XP Professional x64 Edition. Если требуется двойная установка, можно указать дополнительную задачу воспроизведения для обозревателя игр в Windows Vista и Windows 7, которая указывает на 32-разрядную версию, но по умолчанию должна оставаться 64-разрядная версия.

Обратите внимание, что игра должна поддерживать 64-разрядные выпуски Windows Vista и Windows 7, чтобы удовлетворить эту рекомендацию. Поддержка Windows XP Professional x64 Edition рекомендуется, но не требуется.

Логическое обоснование

Технология x64 предоставляет 64-разрядные возможности адресации для рынков потребителей и серверов, включая полную 32-разрядную обратную совместимость для существующих приложений. x64 является ключевой частью стратегии для AMD (AMD64) и Intel (EMT64), и, за исключением ультра-мобильных процессоров, поддерживает технологию для всех текущих и будущих процессоров поколения.

Windows XP Professional x64 Edition была первой ориентированной на потребителя операционной системой Windows для поддержки технологии x64, а Windows Vista и Windows 7 значительно расширяют доступность для 64-разрядных вычислений на потребительских ОС. При использовании 2 ГБ ОЗУ в качестве стандартного на многих новых компьютерах дальнейшее улучшение масштабирования памяти не будет способствовать 32-разрядным отдельным приложениям, которые не могут обращаться к более чем 2 ГБ физической ОЗУ. Многие игры сегодня сталкиваются с проблемами размещения всего доступного контента в ограничениях 2 ГБ виртуального адресного пространства, особенно в сочетании с большими объемами видеопамяти, доступными на высокопроизводительных GPU, и переход на технологию x64 значительно увеличивает поддерживаемые уровни детализации.

Совместимость x64 для 32-разрядных игр — это техническое требование для Windows (2.2), но для использования новых технологий требуется 64-разрядная собственная реализация.

Дополнительная информация

Основным преимуществом 64-разрядной адресации является возможность прямого доступа к более чем 2 ГБ физической и виртуальной памяти. Большое адресное пространство виртуальной памяти позволяет широко использовать сопоставленные с памятью операции ввода-вывода без проблем с исчерпанием пространства виртуальных машин, распространенных в 32-разрядном программировании. Игры могут воспользоваться новым пространством, чтобы значительно улучшить время загрузки или, в некоторых случаях, чтобы исключить паузы для загрузки содержимого.

Существующие 32-разрядные приложения могут воспользоваться x64-редакциями, получая возможность обрабатывать адреса с использованием полного 32-разрядного пространства адресации при сборке с параметром компоновщика Enable Large Addresses (/LARGEADDRESSAWARE). В 32-разрядных версиях Windows XP специальные режимы загрузки позволяют таким приложениям обращаться к 3 ГБ ОЗУ, а выпуски x64 предоставляют доступ к 4 ГБ ОЗУ для приложений, поддерживающих большие адреса (LAA). Хотя использование LAA в 32-разрядном приложении не соответствует этому демонстрационному требованию, эта технология моста является чрезвычайно полезным способом предоставления дополнительных преимуществ масштабирования на версиях Windows x64 для тех, кто не полностью реализует это демонстрационное требование.

Дополнительные сведения см. в 64-разрядном программировании для разработчиков игр и ОЗУ, видеопамять и больше ОЗУ: 64-разрядные игры появились на веб-сайте Game Developer.

Примечание.

Ключевой задачей для этой демонстрации является обеспечение того, чтобы любые сторонние библиотеки или компоненты, на которые ваша игра опирались, доступны для 64-разрядной разработки. Многие устаревшие API Майкрософт также были исключены из 64-разрядной собственной среды, которая может оказаться проблемой для баз кода ядра, содержащих старые реализации ключевых систем.

S.3 Используйте процессоры с множеством ядер

Требование

Игра реализует функции, которые используют многоядерные процессоры, масштабирование до 3, 4 или более ядер, если они доступны.

Если игра поддерживает однопроцессорные или двухядерные системы, параллельное сравнение с четырехядерными системами должно продемонстрировать убедительные новые функции, дополнительные убедительные эффекты, улучшение качества содержимого и /или повышение производительности.

Так как масштабирование с двумя ядрами уже широко поддерживается играми, а также автоматически используется различными усовершенствованиями драйверов Direct3D, масштабирование с двумя ядрами недостаточно для демонстрации этой демонстрации.

Логическое обоснование

Продолжающееся увеличение производительности процессоров переключилось с улучшения тактовой частоты на увеличение числа вычислительных ядер. Стратегии AMD и Intel основаны на масштабируемых многоядерных конструкциях. Все игровые платформы следующего поколения имеют многоядерные ЦП из-за этого фундаментального изменения в эволюции процессоров. Однопоточные приложения больше не будут видеть значительные выгоды от процессоров следующего поколения. Простое многопоточность тоже не сможет масштабироваться, когда число используемых ядер ЦП возрастает до трех или более.

Дополнительная информация

Обратите внимание, что количество ядер не должно быть мощностью двух, поэтому игры должны масштабироваться линейно и обрабатывать количество ядер 3, 4, 5, 6, 7, 8 и т. д.

Масштабирование путем увеличения числа потоков в приложении обеспечивает возврат только в том случае, если затраты на обмен данными и синхронизацию потоков контролируются. Масштабирование на основе функций может оказаться более простым решением в краткосрочной перспективе, позволяя игре работать нормально без дополнительных потоков в одноядерных системах и включить их, когда дополнительная мощность ЦП доступна.

Дополнительные сведения см. в статье "Написание кода для нескольких ядер" в Xbox 360 и Microsoft Windows и рекомендации по программированию без блокировки для Xbox 360 и Microsoft Windows в статьях DirectX, а также служебную программу DXUTLockFreePipe и пример CoreDetection.

Использование свободного потока ресурсов Direct3D 11 и контекстов устройств полезно для достижения масштабируемости на многих ядрах при отрисовке и загрузке графических ресурсов. См. статью "Игры для Windows Демонстрация S.1".

Обратите внимание, что использование инструкции ЦП rdtsc напрямую вместо использования API Windows для вычисления времени на многоядерных системах может привести к проблемам в некоторых конфигурациях оборудования и ОС; См . раздел "Время игры" и "Многоядерные процессоры " в статьях DirectX.

Игры поддержки S.4 для Windows — LIVE

Игры для Windows — LIVE больше не поддерживаются корпорацией Майкрософт.

S.5 поддерживает Windows Touch

Требование

Игры с поддержкой сенсорного ввода Windows можно играть с помощью сенсорных и /или жестов на компьютерах под управлением Windows 7 с сенсорным дисплеем. Кроме того, можно использовать ввод клавиатуры, но основной интерфейс воспроизведения должен быть сенсорным.

Включение касания не должно препятствовать использованию мыши или общего контроллера в соответствии с техническим требованием 1.4.

Установщик игры, как ожидается, не поддерживает функции Windows Touch.

Логическое обоснование

Экраны с поддержкой нескольких сенсорных устройств для компьютеров доступны для ноутбуков и настольных компьютеров, и они представляют ключевую функцию оборудования, которая продвигается в выпуске Windows 7. Windows 7 поддерживает Windows Touch на рабочем столе и общих интерфейсах элементов управления.

Дополнительная информация

Приложения на нативном коде могут получать доступ к мультиточечным сообщениям WM_TOUCH в сочетании с функцией RegisterTouchWindow. См. также API манипуляций и инерции.

Windows Presentation Foundation (WPF) 4.0 предоставляет управляемое решение для много сенсорных интерфейсов.

Дополнительные сведения см. в пакете SDK для Windows Touch.

S.6 поддерживает высокий цвет

Требование

Игры, поддерживающие высокий цвет, используют формат 10:10:10:2 (DXGI_FORMAT_R10G10B10A2, D3DFMT_A2B10G10R10) или 16:16:16:16 (DXGI_FORMAT_R16G16B16A16, D3DFMT_A16B16G16R16) для режима отображения обратного буфера и полноэкранного отображения.

Используя целевой объект отрисовки с высоким цветом, содержимое с высоким динамическим диапазоном (HDR) можно отобразить с расширенным или широким диапазоном при выполнении сопоставления тонов с 10-разрядным или 16-разрядным диапазоном.

Логическое обоснование

Мониторы уже много лет были способны отображать более 256 уровней цвета на канал, даже когда преобладали CRT-дисплеи. Сканирование оборудования на видеокартах было фактором ограничения. Современные графические процессоры, включая большинство оборудования класса Direct3D 9 и все оборудование класса Direct3D 10 и выше, имеют аппаратное обеспечение, поддерживающее сканирование как минимум с 10 битами на канал. В будущем аппаратные возможности будут увеличиваться до 16 бит на цветовой канал. Системы взаимодействия HD TV (HDMI, DisplayPort) предназначены для обработки более чем 8 бит на канал, а аналоговая VGA будет передавать такие сигналы.

Дополнительная информация

Обратите внимание, что высокий цвет или Hi Color исторически относится к переходу от 256 (8-разрядного) цвета до 15- или 16-разрядного цветового отображения. Большинство систем отображения уже давно перешли на True Color, который является 24-разрядным цветом или 8-разрядным каналом цвета для красного, зеленого и синего. Под высококачественным цветом здесь мы понимаем новое поколение систем отображения, которые могут работать с более чем 8-битными каналами для каждого отдельного цвета. Он также известен как Deep Color.

Введение

Помимо соответствия техническим требованиям и принятия одного или нескольких демонстрационных элементов в игре, существует ряд рекомендаций, которыми следует руководствоваться для всех игр Windows. Хотя эти рекомендации выходят за рамки основных технических требований, настоятельно рекомендуется использовать их для всех игр, соответствующих программе Games for Windows.

Дополнительные рекомендации

  • Используйте последний компилятор и среду выполнения Visual Studio. Более новые версии компилятора реализуют значительные улучшения качества кода, созданного и для проблем с безопасностью, и используют современные стратегии оптимизации процессора. Обновление компилятора и использование последней среды выполнения C — это простой способ миграции в современные методики написания кода.
  • Используйте версию библиотеки динамической компоновки (DLL) среды выполнения C, а не статических ссылок и используйте Secure CRT. (Исключения можно сделать в специальных случаях предварительной установки, например для программы автоматического запуска или для самого установщика).
  • Для воспроизведения звука используйте XAudio2, X3DAudio и /или XACT, а не DirectSound. Для звуковых подсистем, которые выполняют все перемешивание и преобразование скорости источника и требуют только решения с низкой задержкой для вывода звука, используйте DirectSound в Windows XP (только) и WASAPI в Windows Vista и Windows 7.
  • Избегайте использования устаревших и замененных API: DirectDraw, DirectSound, DirectPlay, слой производительности DirectMusic, DirectPlay Voice и Direct3D в сохраненном режиме. Обратите внимание, что DirectPlay Voice и Direct3D Retained Mode совсем недоступны в Windows Vista или Windows 7. Уровень производительности DirectPlay и слой DirectMusic недоступен для приложений с родной поддержкой x64.
  • Оптимизируйте использование наборов инструкций SSE/SSE2 SIMD. См. API DirectXMath в пакете SDK для Windows в качестве кроссплатформенного решения для математических операций, оптимизированных для SIMD.
  • Используйте современные лучшие практики по безопасности Windows (включая параметры компилятора и компоновщика, такие как /NXCOMPAT, /GS, /SAFESEH, /DYNAMICBASE, /SDL и т. д.). Дополнительные сведения см. в разделе "Рекомендации по обеспечению безопасности" в разработке игр.
  • Используйте последние компоненты и библиотеки пакета SDK для Windows. Удалите зависимости от устаревших компонентов DirectSetup, развернутых вне диапазона, таких как D3DX9, D3DX10 и D3DX11. Рекомендуется использовать DirectXTex или DirectXTK или оба варианта.
  • Избегайте использования более старого компилятора HLSL и вместо этого используйте современный компилятор HLSL. Если поддержка шейдера пикселей 1.x требуется для приложения, используйте сборку шейдера, а не HLSL, или ограничьте использование старого компилятора только для этих сценариев.

Ресурсы

Срок Описание
Игры для Windows: тестовые случаи
Рекомендации по играм в Windows XP, Windows Vista и Windows 7
Windows SDK
Пакеты SDK для Windows
Рекомендации по управлению учетными записями пользователей
Требования к разработке приложений Windows Vista для обеспечения совместимости управления учетными записями пользователей
Портал разработчика DirectX
Центр разработчиков Directx
Блог об играх для Windows и пакетах SDK DirectX
Игры для Windows и пакета SDK DirectX
Дополнительные статьи DirectX
Технические статьи DirectX