?

Log in

No account? Create an account
Ассеты и линкер - Valse oubliée [entries|archive|friends|userinfo]
aruslan

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]
[ delicious | aruslan's delicious ]

Links
[Links:| Tags Profile Friends FG1 PP gamedev XNA FF Entries Comments Memories ]

Ассеты и линкер [Dec. 20th, 2007|08:23 pm]
aruslan
[Tags|, , , , ]
[Current Mood |angryangry]

Иногда создается ощущение, что то, как линкер работает - военная тайна.
И поэтому делают странное и смешное.

Например, в процессе чтения одного ассета (или библиотеки ассетов) - лезут в другой, в третий, обратно в первый, обратно во второй.
До тех пор, пока много секунд загрузки не будут потрачены исключительно на DVD seek.
Про циркулярные зависимости я промолчу. И про тонны копирований внутри - тоже.
Ну и про отсутствие минимального контроля целостности.

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

В потрепанной жёлтой книжке про Ассемблер и Линкер я вычитал в детстве тривиальный принцип: cначала надо собрать всю инфу о связях,
и только потом эти связи разрешить.

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

В применении к набору библиотек ассетов самая тупая схема выглядит так.
Сначала полностью загрузить библиотеку. То есть прокачать ассеты кусочками вменяемого размера через загрузку новых кусочков и параллельную распаковку старых.
Выяснить кто еще нужен и кого не хватает. Загрузить полностью другой и т.д.
Потом одним пробегом пропатчить внутренние фиксапы и внешние связи где надо. И одним пробегом всех создать (если вдруг такое вообще нужно кому-то).

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

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

Плюс в реальной жизни библиотеки ассетов не бывают вот уж прям настолько отдельными. Поэтому можно вполне еще в оффлайне построить карту связей, отсортировать её топологически да грузить в том порядке который подходит.
И на DVD/Blu-ray в оптимальном порядке записать.
И табличку заранее составить типа какой ассет где лежит.
Патчи и лок-киты в эту схему обычно вполне вписываются.

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

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

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

Зачем делать плохо - вот загадка.
Лучше уж не делать совсем - хотя бы устойчивее работать будет, да и дешевле.
LinkReply

Comments:
[User Picture]From: _winnie
2007-12-21 01:57 am (UTC)
>Её в самом тупом виде реализовать ничуть не сложнее, чем сложную обычную
Я не согласный. hash_map<string, T> - гораздо проще чем тонны кода в оффлайне.

ДУМАТЬ о том что бы всё сролось после СЛОЖНО!
(Reply) (Thread)
[User Picture]From: _winnie
2007-12-21 03:26 am (UTC)
Вот есть у нас D3DXCreateTextureFromFile, std::map, shared_ptr. "Текстурный менеджер" пишется меньше чем за час. Твои же мега-системы билда ассетов сначала продумываются днями, затем днями на white-board и на бумажках, затем пишется неделю в несколько пар рук, затем ещё несколько месяцев находим редкие баги и забытые ассерты. Как можно сложное называть простым - я не понимаю. Разумеется, у KISS решения куча недостатков, но его нельзя нельзя назвать "таким же простым".
(Reply) (Parent) (Thread)
[User Picture]From: _winnie
2007-12-21 03:42 am (UTC)
А потом к тебе приходят, и спрашивают, а как загрузить двумерный массив

char *characters[3] = { "cat", "dot", "mouse" };
for (int i = 0; i < ARRAY_SIZE(characters); ++i)
   for (int j = 0; j < ANIMATION_MAX; ++j)
     ... = LoadTexture("animations/%s_%02d", characters[i], j);


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

(Reply) (Parent) (Thread)
[User Picture]From: virtul
2007-12-21 08:29 am (UTC)
Думаеццо, что на консолях по другому не взлетит. Да и крупном писишном стоит имхо заморочиться на нечто подобное.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2007-12-21 09:06 am (UTC)
Взлететь-то взлетит, к сожалению.
Если ассертов понаставить, сделать руками кэширующие фиберы и с бубном потанцевать.

Просто вот эта пластическая хирургия - она не нужна совсем.
Проще написать то же самое - но дешевле и яснее.
(Reply) (Parent) (Thread)
[User Picture]From: virtul
2007-12-21 09:20 am (UTC)
>Если ассертов понаставить, сделать руками кэширующие фиберы и с бубном >потанцевать.

Ну это из серии "а давайте [пока] делать игровые объекты в хмльках". Знаем проходили.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2007-12-21 09:32 am (UTC)
Вот через это и.
(Reply) (Parent) (Thread)
[User Picture]From: _winnie
2007-12-21 11:51 am (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 одним куском.

(Reply) (Parent) (Thread)
[User Picture]From: _winnie
2007-12-21 11:53 am (UTC)
> Скорость загрузки - в три раза больше, чем хочется
*Время загрузки - в три раза больше, чем хочется
*Скорость загрузки - в три раза меньше, чем хочется
(Reply) (Parent) (Thread)
[User Picture]From: _winnie
2007-12-21 10:21 pm (UTC)
Читаю The way that the system developed is perfectly logical. It makes sense., и оно мне напомнило этот пост :)
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2007-12-21 09:02 am (UTC)
Если что - ты говоришь странное.
Я строго за тупую загрузку ассетов говорю.
Без всяких этих энтелегентских шалостей.

LoadTexture будет работать вполне себе замечательно.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2007-12-21 09:04 am (UTC)
Опять ты говоришь странное.
Я не предлагаю мегаунификации или там спецификации.
Я наоборот - предлагаю простые тупые решения.

Или уж тогда не делать вид что решение есть и тупо юзать map+ptr, да.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2007-12-21 08:59 am (UTC)
Дык я ж не против hashmap! Это как раз из серии "лучше уж не делать совсем" - быстро дешево и работает!

Я против когда делают много всякого - и оно работает плохо.
(Reply) (Parent) (Thread)
[User Picture]From: fenikso
2007-12-21 09:02 am (UTC)
Если я правильно помню, некоторые линуксовые LiveCD как раз оптимайзят в том плане, чтобы при загрузе минимум DVD seeks был. Вроде как хорошее ускорение загрузки получается :)
(Reply) (Thread)
[User Picture]From: aruslan
2007-12-21 09:11 am (UTC)
Оптимайзить игру в плане DVD layout - простое и радостное занятие.
Но не в случае, если кто-то бегает по диску туда-сюда в поисках утерянного счастья. Не всегда под кэш есть много памяти, обычно есть только на один-два уровня промахов. Ну и фрагменты файла разместить непоследовательно может просто не получиться.
(Reply) (Parent) (Thread)
[User Picture]From: loyso_b
2007-12-24 09:31 am (UTC)
> Зачем делать плохо - вот загадка.

Какая уж тут загадка. Традиционно систему зачинает группа amateurs у которой весь анализ происходит в спинном мозге (на уровне "лучше уж не делать совсем"). А потом про нее забывают. Ибо даже у студентов все фичи - по экспоненте ;)
(Reply) (Thread)
From: al_zatv
2010-02-04 02:38 pm (UTC)
привет! вопрос немного не по теме, но по программированию
http://al-zatv.livejournal.com/137474.html
если есть чего посоветовать, буду признателен.
(Reply) (Thread)