Ассеты и линкер
Dec. 20th, 2007 20:23![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
aruslanИногда создается ощущение, что то, как линкер работает - военная тайна.
И поэтому делают странное и смешное.
Например, в процессе чтения одного ассета (или библиотеки ассетов) - лезут в другой, в третий, обратно в первый, обратно во второй.
До тех пор, пока много секунд загрузки не будут потрачены исключительно на DVD seek.
Про циркулярные зависимости я промолчу. И про тонны копирований внутри - тоже.
Ну и про отсутствие минимального контроля целостности.
А вот линкеры - они обычно умнее. Особенно те, что разрешают связи при загрузке.
Конечно, не все.
Есть пара линкеров, которые умиляют всех уже давно, и вот они как раз делают очень похоже.
В потрепанной жёлтой книжке про Ассемблер и Линкер я вычитал в детстве тривиальный принцип: cначала надо собрать всю инфу о связях,
и только потом эти связи разрешить.
В геймдеве ассеты, используемые одновременно, обычно складывают в библиотеки. Ассеты ссылаются на ассеты в других библиотеках, и обычно можно понять в каких именно. И памяти всегда более чем хватает чтобы всю инфу собрать. Всё это - сильно упрощает.
В применении к набору библиотек ассетов самая тупая схема выглядит так.
Сначала полностью загрузить библиотеку. То есть прокачать ассеты кусочками вменяемого размера через загрузку новых кусочков и параллельную распаковку старых.
Выяснить кто еще нужен и кого не хватает. Загрузить полностью другой и т.д.
Потом одним пробегом пропатчить внутренние фиксапы и внешние связи где надо. И одним пробегом всех создать (если вдруг такое вообще нужно кому-то).
Ассеты бывают неоднородными - хидеры и внешние связи, разнообразные сегменты со специфическими потребностями к памяти, фрагменты игрового состояния и т.п. Поэтому ассеты имеет смысл сразу разбить на блоки - для разрешения связей (и освободить), в память (и в какую), временно (и освободить) и т.п.
Те, кто поизвращеннее, могут делать всякое. Интерливить видео с данными, чтобы одновременно еще и видео показывать дабы юзер не скучал. Или скажем процедурно генерить данные по скачиваемым кускам. Или там текстуры по мере распаковки сразу перемещать в видеопамять и не тратить много системной - была бы нужда.
Плюс в реальной жизни библиотеки ассетов не бывают вот уж прям настолько отдельными. Поэтому можно вполне еще в оффлайне построить карту связей, отсортировать её топологически да грузить в том порядке который подходит.
И на DVD/Blu-ray в оптимальном порядке записать.
И табличку заранее составить типа какой ассет где лежит.
Патчи и лок-киты в эту схему обычно вполне вписываются.
И самое характерное - у всех получившихся после загрузки ресурсов из библиотеки ассетов - одно и то же время жизни. И управлять им не нужно. Умные указатели использовать можно, но только в дебаге и только для контроля что всё действительно хорошо.
Замечу - эта схема более чем тривиальная.
Её в самом тупом виде реализовать ничуть не сложнее, чем сложную обычную.
Учитывая управление временем жизни и прочее счастье вроде хэш-таблиц - так еще и проще.
Грустно про это рассказывать, на самом деле. Ведь не стриминг бесконечных миров даже.
Вот и дядя Дима на gamedeff рассказывает хоть и уровнем повыше, но всё про то же.
Зачем делать плохо - вот загадка.
Лучше уж не делать совсем - хотя бы устойчивее работать будет, да и дешевле.
И поэтому делают странное и смешное.
Например, в процессе чтения одного ассета (или библиотеки ассетов) - лезут в другой, в третий, обратно в первый, обратно во второй.
До тех пор, пока много секунд загрузки не будут потрачены исключительно на DVD seek.
Про циркулярные зависимости я промолчу. И про тонны копирований внутри - тоже.
Ну и про отсутствие минимального контроля целостности.
А вот линкеры - они обычно умнее. Особенно те, что разрешают связи при загрузке.
Конечно, не все.
Есть пара линкеров, которые умиляют всех уже давно, и вот они как раз делают очень похоже.
В потрепанной жёлтой книжке про Ассемблер и Линкер я вычитал в детстве тривиальный принцип: cначала надо собрать всю инфу о связях,
и только потом эти связи разрешить.
В геймдеве ассеты, используемые одновременно, обычно складывают в библиотеки. Ассеты ссылаются на ассеты в других библиотеках, и обычно можно понять в каких именно. И памяти всегда более чем хватает чтобы всю инфу собрать. Всё это - сильно упрощает.
В применении к набору библиотек ассетов самая тупая схема выглядит так.
Сначала полностью загрузить библиотеку. То есть прокачать ассеты кусочками вменяемого размера через загрузку новых кусочков и параллельную распаковку старых.
Выяснить кто еще нужен и кого не хватает. Загрузить полностью другой и т.д.
Потом одним пробегом пропатчить внутренние фиксапы и внешние связи где надо. И одним пробегом всех создать (если вдруг такое вообще нужно кому-то).
Ассеты бывают неоднородными - хидеры и внешние связи, разнообразные сегменты со специфическими потребностями к памяти, фрагменты игрового состояния и т.п. Поэтому ассеты имеет смысл сразу разбить на блоки - для разрешения связей (и освободить), в память (и в какую), временно (и освободить) и т.п.
Те, кто поизвращеннее, могут делать всякое. Интерливить видео с данными, чтобы одновременно еще и видео показывать дабы юзер не скучал. Или скажем процедурно генерить данные по скачиваемым кускам. Или там текстуры по мере распаковки сразу перемещать в видеопамять и не тратить много системной - была бы нужда.
Плюс в реальной жизни библиотеки ассетов не бывают вот уж прям настолько отдельными. Поэтому можно вполне еще в оффлайне построить карту связей, отсортировать её топологически да грузить в том порядке который подходит.
И на DVD/Blu-ray в оптимальном порядке записать.
И табличку заранее составить типа какой ассет где лежит.
Патчи и лок-киты в эту схему обычно вполне вписываются.
И самое характерное - у всех получившихся после загрузки ресурсов из библиотеки ассетов - одно и то же время жизни. И управлять им не нужно. Умные указатели использовать можно, но только в дебаге и только для контроля что всё действительно хорошо.
Замечу - эта схема более чем тривиальная.
Её в самом тупом виде реализовать ничуть не сложнее, чем сложную обычную.
Учитывая управление временем жизни и прочее счастье вроде хэш-таблиц - так еще и проще.
Грустно про это рассказывать, на самом деле. Ведь не стриминг бесконечных миров даже.
Вот и дядя Дима на gamedeff рассказывает хоть и уровнем повыше, но всё про то же.
Зачем делать плохо - вот загадка.
Лучше уж не делать совсем - хотя бы устойчивее работать будет, да и дешевле.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: Dec. 21st, 2007 08:29 (UTC)no subject
Date: Dec. 21st, 2007 09:06 (UTC)Если ассертов понаставить, сделать руками кэширующие фиберы и с бубном потанцевать.
Просто вот эта пластическая хирургия - она не нужна совсем.
Проще написать то же самое - но дешевле и яснее.
no subject
Date: Dec. 21st, 2007 09:20 (UTC)Ну это из серии "а давайте [пока] делать игровые объекты в хмльках". Знаем проходили.
no subject
Date: Dec. 21st, 2007 09:32 (UTC)no subject
Date: Dec. 21st, 2007 11:51 (UTC)1) Грузим в игровом цикле. После десяти картинок - FPS никакой.
2) Грузим перед игровым циклом. Скорость загрузки - в три раза больше, чем хочется.
3) hash_map. Тонем в сиках.
4) Выдаем пользователю не текстуру, а пустышку-прокси, которую грузим потом когда удобней. Менеджер мержит и сортирует запросы, что бы читать по порядку. Барахтаемся в сиках.
5) Profile Guided Optimization. Пишем скрипты, который смотрит что когда игра грузит, и под это переставляет файлы.
7) Тестеры часто жалуются на assertion failed на недостающий файл. Пишем regexp, который по коду находит использующиеся текстуры, с 5% LoadTexture которые не подходят под regexp разбираемся отдельно.
7) Много лишних неиспользующихся текстур, проблема решается как в предыдущем пункте.
В результате получается гораздо сложней чем линкер, но 1) можно вовремя остановиться 2) 7 по 0.2 может быть легче чем 1.0 одним куском.
no subject
Date: Dec. 21st, 2007 11:53 (UTC)*Время загрузки - в три раза больше, чем хочется
*Скорость загрузки - в три раза меньше, чем хочется
no subject
Date: Dec. 21st, 2007 22:21 (UTC)