Практика портирования 3D шутера на PlayStation® 3 Пальвелев Артём, Saber Interactive

Содержание 1. Введение 2. Ресурсы (движок, инструментарий, люди) 3. Портирование движка 4. Память 5. Профайлинг и оптимизация 6. Сертификация 1. Введение

Введение Целевая аудитория доклада: программисты и их руководители. Тема доклада: специфика портирования на консоли вообще и на PS3 в частности.

TimeShift Доклад основан на опыте параллельной разработки 3D-шутера TimeShift под платформу PS3. Кросс-платформенная игра для Xbox 360, PS3 и PC. Игра была полностью переделана менее, чем за год. Версия PS3 была завершена и выпущена почти одновременно с остальными после всего 10 месяцев разработки.

Содержание 1. Введение 2. Ресурсы (движок, инструментарий, люди) 3. Портирование движка 4. Память 5. Профайлинг и оптимизация 6. Итоги 2. Ресурсы (движок, инструментарий, люди)

Движок и middleware FMOD Havok Bink GameSpy Собственный движок Saber3D. Кроме того, используются следующее middleware:

Human resources Портирование проекта с Xbox360 заняло менее 10 месяцев. 2 полностью занятых программиста + авторы отдельных подсистем + ещё несколько программистов и художников для финального профайлинга и фиксов перед сертификацией.

Инструментарий Компилятор GCC, ProDG интеграция в Visual Studio от SN Systems. Компилятор SNC тогда был в beta-версии. Внешний отладчик, копирующий фичи VS. Два профайлера для кода. Компилятор Cg от Sony. Специализированные профайлеры и отладчики для графики от Sony.

Содержание 1. Введение 2. Ресурсы (движок, инструментарий, люди) 3. Портировании движка 4. Память 5. Профайлинг и оптимизация 6. Итоги 3. Портирование движка

Компилятор: проблемы compile-time Компилятор GCC существенно отличается от MSVC (как правило, в сторону строгой поддержки стандарта C++). Портирование готовой игры потребовало примерно 2 недели, чтобы только скомпилировать проект. –~700К строк C++ кода; –1 человек.

Компилятор: проблемы runtime Byte ordering –общее для PowerPC. Выравнивание данных –влияет на совместимость с middleware; –становится требованием при оптимизации. Pointer aliasing –-fno-strict-aliasing, хотя он может испортить производительность. На несовместимости компиляторов проблемы не заканчиваются.

Platform-specific код в движке Syscall wrapper (IO, synchronization) PS3 system calls PS3-specific rendering FMODGameSpy platform-independent код Asynchronous loading Sound Multiplayer logic Save/load Platform-independent rendering impl. platform-specific код

Многопоточность в движке 2 аппаратных нити на PPU + 6 SPU. Мы уже имели кросс-платформенную систему шедулинга job-ов для произвольного числа процессоров. Она использовала 2 нити PPU. Эта система имела две «тяжёлые нити»: Render() и Update(), и несколько «лёгких» (анимация). FMOD работает на 2х SPU. Havok тоже поддерживает SPU, но у нас не было времени на внедрение.

Графика Cg, почти совместим с HLSL. Мы имели один исходный код шейдеров на все три платформы; для каждой платформы был свой #define. Низкоуровневое API, напрямую помещающее токены в комманд-буфер. Весь менеджмент памяти и ресурсов выполняется вручную.

Файловая система и паки Пак – это зиппованный файл, который мы читаем/разжимаем асинхронно. 1 пак на уровень + несколько initial. Требования асинхронности и минимизации трафика довольно важны: –синхронное чтение очень медленное; –seek-и очень дорогие.

Что не попало в паки Файлы видео и звуков, которые стримились. Поэтому: для звуков авторами FMOD-а была написана довольно хорошая асинхронная подгрузка; мы дописали кеширование звуков на PS3 HDD.

Встроенный HDD На ранних стадиях разработки мы использовали встроенный HDD для кеширования данных. Позднее, мы использовали HDD для кеширования стримящихся данных. На PS3 можно использовать 1 Гб системного кеша и 7 Гб инсталлируемых данных. PSN installable demos обязаны работать на HDD.

Содержание 1. Введение 2. Ресурсы (движок, инструментарий, люди) 3. Портирование движка 4. Память 5. Профайлинг и оптимизация 6. Итоги 4. Память

Память У нас было 209 Мб системной памяти и 224 Мб видеопамяти. За вычетом exe и статических библиотек, получаем ~170 Мб системной памяти. Мы уже имели статистику памяти с бюджетом для каждой подсистемы. Портирование с Xbox360 не потребовало сильных изменений этих бюджетов, кроме...

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

Память: mallocs Мы используем dlmalloc. Мы можем делать до 0.5 миллиона malloc() за загрузку уровня, это стоит ~0.5 сек. Фрагментация всё же остаётся проблемой – мы должны иметь пул свободной памяти. Per-frame аллокации не проблема, хотя нужно соблюдать осторожность.

Память: статистика В non-retail билдах мы жертвуем 16 Мб памяти под детальную статистику памяти. Для каждого аллоцированного блока хранится __FILE__, __LINE__. Классы контейнеров получают параметры в конструкторе. В консоли по нажатию кнопки можно сохранить дамп карты памяти.

Память: результаты Автоматическое получается разделение по подсистемам. Легко отслеживать потребление памяти каждой подсистемой. Есть тул, который позволяет сравнить два дампа статистики и определяет memory leaks.

Видеопамять Аллокация видеопамяти: top += block_size Дефрагментация на выгрузке уровня. Часть данных персистентна (текстуры оружия, UI), остальное загружается/удаляется вместе с уровнем. Звуковые банки кладутся в видеопамять на старте игры Управление видеопамятью простое и эффективное:

Содержание 1. Введение 2. Ресурсы (движок, инструментарий, люди) 3. Портирование движка 4. Память 5. Профайлинг и оптимизация 6. Итоги 5. Профайлинг и оптимизация

Профайлинг У нас были профайлеры от Sony и SN Systems. А также собственные тулзы для сбора статистики (per-frame и loading time). Эти тулзы были кросс- платформенными и использовались везде. Большинство оптимизаций также были кросс-платформенными.

Профайлинг: тулзы Консоль, работающая через TCP/IP. Позволяет выбирать интересующие счётчики. Текстовая и графическая визуализация.

Профайлинг: тулзы-2

Содержание 1. Введение 2. Ресурсы (движок, инструментарий, люди) 3. Портирование движка 4. Память 5. Профайлинг и оптимизация 6. Сертификация 6. Итоги

Sony developer support Техподдержка довольно быстро отвечает. На багрепорты оперативно выдаётся либо поправленный билд, либо workaround. Фиче-риквесты реализуются!

Сертификация, TRC Основные проблемы: - время загрузки не более 30 секунд; - обработка disk eject (в новых SDK упрощено); - обработка PS button во время загрузки. TRC – Technical Requirements Checklist. Мы прошли сертификацию SCEA с первого раза и SCEE со второго.

Итоги и будущее движка Работа по TimeShift была успешно завершена за 10 месяцев. Сейчас наш движок дорабатывается. Делаются platform-specific оптимизации, в том числе: –стримминг с использованием SPU; –куллинг треугольников на SPU; –и это только начало!

Напоследок: практика отладки Меньше дебагера, больше printf()! Хороший логгинг неоценим. Во многих ситуациях не доступны символы. printf() –единственный способ отлаживаться на SPU (хотя отладчики совершенствуются). Иногда printf() меняет тайминги кода :) В целом, отладка не сложнее, чем на PC.

Узнать больше о TimeShift и Saber Interactive вы можете на Ярмарке Проектов.

Were hiring Если вы считаете себя экстремально талантливым, напишите нам об этом:

Вопросы ?