Разработка под консоли

Разработка под консолиХорошие и плохие решения

Akella. Арсенихин Роман

Попадая на консоли...

• Мало памяти

• ... Но другим её хватает

• Нету быстрого HDD, есть медленный DVD

• Особенности местного графического процессора весьма непривичны

КРИ 2005. 3 апреля.

Платформы. Графические движки


Выбор платформ

• Чёткое понимание возможности реализации желаемых features

При выборе нескольких платформ:

• Архитектурная совместимость – не придётся ли писать две реализации одного и того же движка?


Выбор платформПонимание возможностейРазрабатываем революционный FPS? Ок

Требования дизайнеров:• Чтобы у монстров было по 2, 3 или 4 руки.• Чтобы у них из глаз вылетали лучи смерти.• Чтобы был оригинальный режим зрения

сквозь стены.• Чтобы можно было перемещаться по всему

миру без задержек и загрузок.


Выбор платформПонимание возможностейРассуждения программистов:• 2, 3 или 4 руки у монстров? С этим проблем нет, наш

универсальный движок поддерживает любое количество рук.

• Лучи смерти из глаз будут легко реализованы с помощью системы частиц.

• Зрение сквозь стены. На PC мы сделаем это легко, на XBox – если не будет страдать производительность. На PS2 этого эффекта мы не сможем достичь из-за особенностей графического процессора. Не предложить ли дизайнерам отказаться от этой фичи?

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


Выбор платформАрхитектурная совместимостьПараллельные рассчёты игровых процессов?

Интеллектуальное распределением времени, выделяемого на ту или иную операцию?

Как только у всех пользователей будут процессоры с поддержкой Hyper Threading, и все консоли будут поддерживать архитектуру ala Cell, стоит задуматься о разработке сложных многопоточных движков.


Выбор графического движка

• Движок собственного изготовления

• Некое middle-ware решение.


Выбор графического движкаIn-house solution+ Полный доступ ко всем

исходникам

+ Большая гибкость при добавлении желаемых возможностей

+ Перспективность использования при качественной базовой реализации

- Необходимость глубокого понимания архитектуры и возможностей выбранных платформ

- Необходимость наличия высококвалифицированных разработчиков, способных разработать качественное решение


Выбор графического движкаMiddleware+ Набор готовых решений

для ряда платформ

+ Наличие квалифицированной технической поддержки

+ Наличие развитого инструментария

- «Чёрный ящик» отсутствие доступа к исходникам (или наличие, но за отдельные деньги)

- Технологическая привязка к чужому решению

- Возможное отсутствие необходимых features


Эффективное распределение памяти



Стандартная схема

• Единый пул

• Стратегия распределение «first-fit»

Ведёт к фрагментации памяти

Затрудняет поиск утечек



Причины фрагментации:• Распределение объектов с разным временем

жизни в едином пространстве• Распределение объектов существенно

отличающихся размеров в едином пространстве

Свободно

СвободноБлок 1

Блок 1 2

Блок 1 2 Блок 3

Свободно 2

Свободно

Свободно



Пути улучшения эффективности распределения памяти

• Группирование объектов по размерам

• Группирование объектов по времени жизни

• Группирование объектов по предназначению

• Дефрагментация памятиКРИ 2005. 3 апреля.


Ключ – введение признака использования выделяемого блока (memory hint)

• Время жизни (global, per-location, per-frame и т.п.)

• Предназначение (string buffer, texture buffer и т.п.)

Block #18

Size = 1024

Hint = Global + String

Block #385

Size = 36

Hint = Temp + Object



Оптимизированная схема №1• Маленькие объекты распределяются из пула

А.• Крупные объекты распределяются из пула Б.

Оптимизированная схема №2• Постоянные объекты распределяются из

пула А.• Временные объекты распределяются из пула

Б.КРИ 2005. 3 апреля.


Типы пулов:• Chunk Allocator – все блоки одного размера,

не требуется вспомогательной информации, максимальная скорость распределения.

- используемые части блоков

- неиспользуемые части блоков

- свободные блоки



Типы пулов:• Block Allocator – блоки переменного размера,

классический метод «boundary tags» - к каждому блоку прикреплён тег с дополнительной информацией, стратегия «best-fit»

tag data tag data tag tag data tag

- эффективная (используемая) часть блока

- информационная часть блока (тэг)

- свободные пространство



Практическая схема:• Набор пулов для статических строковых

идентификаторов (chunk, 128 Kb)• Набор пулов для строк (chunk + block, 128 Kb)• Набор пулов для мелких объектов (<128 байт, chunk

512 Kb)• Набор пулов для средних объектов (<4 Kb, block

64Kb)• Набор пулов для объектов графического движка

(chunk 128Kb + block 1Mb)• Набор пулов для объектов времени жизни игровой

локации (chunk 256Kb + block 64Kb)КРИ 2005. 3 апреля.


Строки.

• Статические строки != динамические строки. Для хранения используются различные области памяти.

• Счётчики ссылок – копирование строки = присваивание указателя + увеличение счётчика ссылок.



Контейнеры.

• STL. Собственные аллокаторы.

• Вектор с заданной скоростью роста

0

0 1 2 3 4

0 1 2 3 4 5 6 7

0 1 2 3 4 5 6 7 8

величина роста


Эффективное распределение памятиДефрагментация.

• Собирает используемые блоки в одно место

• Освобождает неиспользуемые пулы

Возможна при:

• Отсутствии указателей на блок в момент вызова







Результаты применения технологии:

• Значительное уменьшение фрагментации до почти полного её отсутствия

• Получение полного контроля над временем жизни блоков памяти

• Лёгкий поиск утечек памяти


Большие миры



Требования:

• Непрерывное (без загрузок) перемещение на большие расстояния

• Наполненность мира объектами в т.ч. Интерактивными

Решение – динамическая подгрузка игрового контента.



Что загружать?

Это решает система видимости.

Когда загружать?

Система видимости + дизайнер


Большие мирыQuad- and oct-trees


Большие миры«Кишка»Набор частей большой локации, для

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

Кусок 1Кусок 2


Большие миры«Кишка»Характеристики:• Протяжённость• Связи• «Критические» области

Характеристики определяются техническими ограничениями – успеет ли загрузиться следующий кусок, пока мы перемещаемся по текущему?


Большие миры«Кишка»

1

2

3


Большие мирыЧтение с диска

Больше, но реже

Чаще, но меньше

Всегда возникает компромисс между частотой и объёмом подкачки с диска


Большие мирыЧтение с дискаПовышение скорости

чтения

• Чтение без поиска

• Перенос наиболее критичных к скорости данных на внешние дорожки диска


Большие мирыЧтение с дискаСпособы использования динамической

загрузки• Загрузка необходимых данных по

запросу• Загрузка данных по запросу +

предзагрузка данных которые могут понадобиться

• Загрузка данных для данного куска локации как единого целого


Большие мирыЧтение с дискаЗагрузка необходимых данных по запросу

Загрузкаобъекта

Нужнагеометрия

Запрос ресурсаHouse012.mesh

Поиск + чтение

Нужнатекстура

Запрос ресурсаBrick.tga


Объектсоздан!

Игровой код

Драйвер диска


Большие мирыЧтение с дискаПредзагрузка данных


Нужна геометрия

ЗапросHouse.mesh

Загрузка House.mesh

Загрузка Brick.tga

Загрузка Wall.mesh

единая операция



ЗапросWall.mesh

ВозвратWall.meshиз кеша


Игровой код

Драйвер диска

Менеджер

ресурсов


Большие мирыЧтение с дискаЗагрузка данных как единого целого



ЗапросHouse.mesh

Загрузкапотока


Возвратhouse.mesh

из кеша



ЗапросWall.mesh

ВозвратWall.meshиз кеша


Большие мирыСоздание объектовЕсть:• Загруженная геометрия + текстура• Сериализованные данные для

инициализации

Задача:• Создать и инициализировать все 10k+

объектов находящихся в данном куске локации


Большие мирыСоздание объектовСпособ 1.Немедленное создание объектов как только всё

загружено.

Возможные неприятности:

Ход выполнения Инициализация объектов Ход выполнения

Уведомление о готовности данных

Задержка!

При «тяжёлых» объектах или при их большом количестве неминуемы задержки, что выливается в остановке игры на секунды


Большие мирыСоздание объектовСпособ 2.Создание объектов, распределённое на несколько

кадров

Расчёт кадра

Созданиенесколькихобъектов





кадр кадр кадр

- Усложнение структуры движка


Большие мирыПрактическое применениеRage Rider:

• Технология «кишка»

• Предзагрузка данных

• Средняя длина куска ~ 0.5 Km

• ~1500 игровых объектов в каждом куске

• ~2.5 Mb данных на каждый кусок уровня

• Расстояние видимости ~ 1.2 Km


Ресурсы и мультиплатформенность


Ресурсы и мультиплатформенностьХранение ресурсов в

платформонезависимом виде

+ Единый набор ресурсов+ Единообразный доступ к

ресурсам

- Низкая производительность – необходимо в процессе исполнения «инстанцировать» ресурсы

- Ограничение характеристиками самой слабой из платформ

Хранение ресурсов в платформозависимом виде

+ Максимальная производительность

+ Наиболее полное использование возможностей платформы

- Множество разных наборов ресурсов для каждой из платформ – большой риск рассинхронизированности

- Различный код доступа к ресурсам для различных платформ


Ресурсы и мультиплатформенностьРешение – синтез платформозависимых и

платформонезависимых наборов.

Данные, к которым требуется единообразный доступ на всех платформах – в общем виде.

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


Ресурсы и мультиплатформенностьОбщий формат хранения:• Геометрия для коллизий• Сериализованные описания объектов• Данные для системы AI (пути, триггеры и т.п.)

Платформозависимый формат:• Графические модели• Текстуры (различное разрешение для разных

платформ)• Звуковые данные


Ресурсы и мультиплатформенностьВозможный способ хранения

Resources

PI(platform independent)

PS2

XBox

Common data

Textures

Models

Textures

Models

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


The last but not the leastМелкие оптимизации


Мелкие оптимизацииExceptions? Errors!Исключения используются только для критических

ошибок и только в debug-варианте – избавляемся от таблиц исключений или от кода разворачивания стека.

#if defined(CORE_USE_EXCEPTIONS)

#define CORE_THROW(a) throw(a)

#define CORE_CATCH(a) catch(a)

#define CORE_CATCH_ALL catch(…)

#else

#define CORE_THROW(a) sayGoodByeAndDie(…)

#define CORE_CATCH(a) if (0)

#define CORE_CATCH_ALL if (0)

#endif


Мелкие оптимизацииDouble TroubleПри математических

вычислениях следует явно использовать функции одинарной точности – компиляторы не знают что вы делаете критичное к скорости выполнения приложение.

sin sinf

fmod fmodf

abs absf


Мелкие оптимизацииСкорость vs размерРезультат оптимизации Optimize for speed

не всегда быстрее, чем Optimize for size.


Мелкие оптимизацииОптимизации – зло?Некоторые компиляторы генерируют

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

• Передача/возврат пустого вектора по значению

• Неправильные значения stl-итераторов


Итоги

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


Спасибо!

Вопросы?

[email protected]

www.akella.com


mailto:[email protected]

Documents

Разработка под консоли