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

1. Разработка под консоли Хорошие и плохие решения Akella. Арсенихин Роман

2. Попадая на консоли... • Мало памяти • ... Но другим её хватает • Нету быстрого HDD, есть медленный DVD • Особенности местного графического процессора весьма непривичны КРИ 2005. 3 апреля.

3. Платформы. Графические движки КРИ 2005. 3 апреля.

4. Выбор платформ • Чёткое понимание возможности реализации желаемых features При выборе нескольких платформ: • Архитектурная совместимость – не придётся ли писать две реализации одного и того же движка? КРИ 2005. 3 апреля.

5. Выбор платформПонимание возможностей Разрабатываем революционный FPS? Ок Требования дизайнеров: • Чтобы у монстров было по 2, 3 или 4 руки. • Чтобы у них из глаз вылетали лучи смерти. • Чтобы был оригинальный режим зрения сквозь стены. • Чтобы можно было перемещаться по всему миру без задержек и загрузок. КРИ 2005. 3 апреля.

6. Выбор платформПонимание возможностей Рассуждения программистов: • 2, 3 или 4 руки у монстров? С этим проблем нет, наш универсальный движок поддерживает любое количество рук. • Лучи смерти из глаз будут легко реализованы с помощью системы частиц. • Зрение сквозь стены. На PC мы сделаем это легко, на XBox – если не будет страдать производительность. На PS2 этого эффекта мы не сможем достичь из-за особенностей графического процессора. Не предложить ли дизайнерам отказаться от этой фичи? • Перемещение по большому миру – понадобиться много времени и сил, но, пожалуй, мы сможем достичь нужного результата на всех платформах. КРИ 2005. 3 апреля.

7. Выбор платформАрхитектурная совместимость Параллельные рассчёты игровых процессов? Интеллектуальное распределением времени, выделяемого на ту или иную операцию? Как только у всех пользователей будут процессоры с поддержкой Hyper Threading, и все консоли будут поддерживать архитектуру ala Cell, стоит задуматься о разработке сложных многопоточных движков. КРИ 2005. 3 апреля.

8. Выбор графического движка • Движок собственного изготовления • Некое middle-ware решение. КРИ 2005. 3 апреля.

9. + Полный доступ ко всем исходникам + Большая гибкость при добавлении желаемых возможностей + Перспективность использования при качественной базовой реализации Необходимость глубокого понимания архитектуры и возможностей выбранных платформ Необходимость наличия высококвалифицированных разработчиков, способных разработать качественное решение Выбор графического движкаIn-house solution КРИ 2005. 3 апреля.

10. + Набор готовых решений для ряда платформ + Наличие квалифицированной технической поддержки + Наличие развитого инструментария «Чёрный ящик» отсутствие доступа к исходникам (или наличие, но за отдельные деньги) Технологическая привязка к чужому решению Возможное отсутствие необходимых features Выбор графического движкаMiddleware КРИ 2005. 3 апреля.

11. Эффективное распределение памяти КРИ 2005. 3 апреля.

12. Эффективное распределение памяти Стандартная схема • Единый пул • Стратегия распределение «first-fit» Ведёт к фрагментации памяти Затрудняет поиск утечек КРИ 2005. 3 апреля.

13. Эффективное распределение памяти Причины фрагментации: • Распределение объектов с разным временем жизни в едином пространстве • Распределение объектов существенно отличающихся размеров в едином пространстве Свободно Блок 1 Свободно Блок 1 2 Свободно Блок 1 2 Блок 3 Свободно 2 Свободно КРИ 2005. 3 апреля.

14. Эффективное распределение памяти Пути улучшения эффективности распределения памяти • Группирование объектов по размерам • Группирование объектов по времени жизни • Группирование объектов по предназначению • Дефрагментация памяти КРИ 2005. 3 апреля.

15. Эффективное распределение памяти Ключ – введение признака использования выделяемого блока (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 КРИ 2005. 3 апреля.

16. Эффективное распределение памяти Оптимизированная схема №1 • Маленькие объекты распределяются из пула А. • Крупные объекты распределяются из пула Б. Оптимизированная схема №2 • Постоянные объекты распределяются из пула А. • Временные объекты распределяются из пула Б. КРИ 2005. 3 апреля.

17. Эффективное распределение памяти Типы пулов: • Chunk Allocator – все блоки одного размера, не требуется вспомогательной информации, максимальная скорость распределения. - используемые части блоков - неиспользуемые части блоков - свободные блоки КРИ 2005. 3 апреля.

18. Эффективное распределение памяти Типы пулов: • Block Allocator – блоки переменного размера, классический метод «boundary tags» - к каждому блоку прикреплён тег с дополнительной информацией, стратегия «best-fit» tag data tag data tag tag data tag - эффективная (используемая) часть блока - информационная часть блока (тэг) - свободные пространство КРИ 2005. 3 апреля.

19. Эффективное распределение памяти Практическая схема: • Набор пулов для статических строковых идентификаторов (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 апреля.

20. Эффективное распределение памяти Строки. • Статические строки != динамические строки. Для хранения используются различные области памяти. • Счётчики ссылок – копирование строки = присваивание указателя + увеличение счётчика ссылок. КРИ 2005. 3 апреля.

21. Эффективное распределение памяти Контейнеры. • STL. Собственные аллокаторы. • Вектор с заданной скоростью роста 0 0 1 2 3 4 величина роста 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 8 КРИ 2005. 3 апреля.

22. Эффективное распределение памяти Дефрагментация. • Собирает используемые блоки в одно место • Освобождает неиспользуемые пулы Возможна при: • Отсутствии указателей на блок в момент вызова КРИ 2005. 3 апреля.

23. Эффективное распределение памяти КРИ 2005. 3 апреля.

24. Эффективное распределение памяти КРИ 2005. 3 апреля.

25. Эффективное распределение памяти Результаты применения технологии: • Значительное уменьшение фрагментации до почти полного её отсутствия • Получение полного контроля над временем жизни блоков памяти • Лёгкий поиск утечек памяти КРИ 2005. 3 апреля.

26. Большие миры КРИ 2005. 3 апреля.

27. Большие миры Требования: • Непрерывное (без загрузок) перемещение на большие расстояния • Наполненность мира объектами в т.ч. Интерактивными Решение – динамическая подгрузка игрового контента. КРИ 2005. 3 апреля.

28. Большие миры Что загружать? Это решает система видимости. Когда загружать? Система видимости + дизайнер КРИ 2005. 3 апреля.

29. Большие мирыQuad- and oct-trees КРИ 2005. 3 апреля.

30. Большие миры«Кишка» Набор частей большой локации, для каждой из которых указаны правила связи с другими частями. Кусок 2 Кусок 1 КРИ 2005. 3 апреля.

31. Большие миры«Кишка» Характеристики: • Протяжённость • Связи • «Критические» области Характеристики определяются техническими ограничениями – успеет ли загрузиться следующий кусок, пока мы перемещаемся по текущему? КРИ 2005. 3 апреля.

32. Большие миры«Кишка» 2 1 3 КРИ 2005. 3 апреля.

33. Большие мирыЧтение с диска 33 Чаще, но меньше 33 3 Больше, но реже Всегда возникает компромисс между частотой и объёмом подкачки с диска КРИ 2005. 3 апреля.

34. Большие мирыЧтение с диска Повышение скорости чтения • Чтение без поиска • Перенос наиболее критичных к скорости данных на внешние дорожки диска Быстрее Медленнее КРИ 2005. 3 апреля.

35. Большие мирыЧтение с диска Способы использования динамической загрузки • Загрузка необходимых данных по запросу • Загрузка данных по запросу + предзагрузка данных которые могут понадобиться • Загрузка данных для данного куска локации как единого целого КРИ 2005. 3 апреля.

36. Большие мирыЧтение с диска Загрузка необходимых данных по запросу Загрузка объекта Объект создан! Нужна геометрия Нужна текстура Запрос ресурса House012.mesh Запрос ресурса Brick.tga Игровой код Драйвер диска Поиск + чтение Поиск + чтение КРИ 2005. 3 апреля.

37. Большие мирыЧтение с диска Предзагрузка данных Загрузка объекта Загрузка объекта Нужна геометрия Нужна геометрия Запрос House.mesh Запрос Wall.mesh Игровой код Возврат Wall.mesh из кеша Менеджер ресурсов Загрузка House.mesh Загрузка Brick.tga Загрузка Wall.mesh единая операция Поиск + чтение Драйвер диска КРИ 2005. 3 апреля.

38. Большие мирыЧтение с диска Загрузка данных как единого целого Загрузка объекта Загрузка объекта Нужна геометрия Нужна геометрия Запрос House.mesh Запрос Wall.mesh Возврат house.mesh из кеша Возврат Wall.mesh из кеша Загрузка потока Поиск + чтение КРИ 2005. 3 апреля.

39. Большие мирыСоздание объектов Есть: • Загруженная геометрия + текстура • Сериализованные данные для инициализации Задача: • Создать и инициализировать все 10k+ объектов находящихся в данном куске локации КРИ 2005. 3 апреля.

40. Большие мирыСоздание объектов Способ 1. Немедленное создание объектов как только всё загружено. Возможные неприятности: Задержка! Ход выполнения Инициализация объектов Ход выполнения Уведомление о готовности данных При «тяжёлых» объектах или при их большом количестве неминуемы задержки, что выливается в остановке игры на секунды КРИ 2005. 3 апреля.

41. Большие мирыСоздание объектов Способ 2. Создание объектов, распределённое на несколько кадров кадр кадр кадр Расчёт кадра Расчёт кадра Расчёт кадра Создание нескольких объектов Создание нескольких объектов Создание нескольких объектов - Усложнение структуры движка КРИ 2005. 3 апреля.

42. Большие мирыПрактическое применение Rage Rider: • Технология «кишка» • Предзагрузка данных • Средняя длина куска ~ 0.5 Km • ~1500 игровых объектов в каждом куске • ~2.5 Mb данных на каждый кусок уровня • Расстояние видимости ~ 1.2 Km КРИ 2005. 3 апреля.

43. Ресурсы и мультиплатформенность КРИ 2005. 3 апреля.

44. Хранение ресурсов в платформонезависимом виде + Единый набор ресурсов + Единообразный доступ к ресурсам Низкая производительность – необходимо в процессе исполнения «инстанцировать» ресурсы Ограничение характеристиками самой слабой из платформ Хранение ресурсов в платформозависимом виде + Максимальная производительность + Наиболее полное использование возможностей платформы Множество разных наборов ресурсов для каждой из платформ – большой риск рассинхронизированности Различный код доступа к ресурсам для различных платформ Ресурсы и мультиплатформенность КРИ 2005. 3 апреля.

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

46. Ресурсы и мультиплатформенность Общий формат хранения: • Геометрия для коллизий • Сериализованные описания объектов • Данные для системы AI (пути, триггеры и т.п.) Платформозависимый формат: • Графические модели • Текстуры (различноеразрешение для разных платформ) • Звуковые данные КРИ 2005. 3 апреля.

47. Ресурсы и мультиплатформенность Возможный способ хранения Сборщик ресурсов автоматически проверяет обновления в исходных каталогах и вносит изменения в архивы для выбранных платформ. КРИ 2005. 3 апреля.

48. The last but not the leastМелкие оптимизации КРИ 2005. 3 апреля.

49. Мелкие оптимизацииExceptions? Errors! Исключения используются только для критических ошибок и только в debug-варианте – избавляемся от таблиц исключений или от кодаразворачивания стека. #if defined(CORE_USE_EXCEPTIONS) #defineCORE_THROW(a) throw(a) #defineCORE_CATCH(a) catch(a) #defineCORE_CATCH_ALL catch(…) #else #defineCORE_THROW(a) sayGoodByeAndDie(…) #defineCORE_CATCH(a) if (0) #defineCORE_CATCH_ALL if (0) #endif КРИ 2005. 3 апреля.

50. Мелкие оптимизацииDouble Trouble При математических вычислениях следует явно использовать функции одинарной точности – компиляторы не знают что вы делаете критичное к скорости выполнения приложение. КРИ 2005. 3 апреля.