?

Log in

No account? Create an account
Помощники - Valse oubliée — LiveJournal [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 ]

Помощники [May. 30th, 2006|03:06 pm]
aruslan
[Tags|, , , , ]

Ненавижу
автоматически рождающиеся объекты типа блокирующего loading-on-demand. И синглтоны типа Майерса.
автоматически уничтожающиеся объекты под smart_ptr. И подсчёт ссылок.
автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений.
автоматически создающиеся нетривиальные объекты со статическим storage duration. И вообще бурную деятельность до main().

мгновенность, нераспределенность, модель exception, lower-order programming.

Но научить правильно не всегда получается.
LinkReply

Comments:
[User Picture]From: aruslan
2006-05-31 08:36 pm (UTC)
Ок, Саймон, буду краток и конкретен.
Но уж тогда прости - не сферической вакуумности для, но краткости ради.

Одно описываю, второе - ты додумаешь.


Есть мир побитый на чанки типа грид, чанки стримятся.
Одна камера без мгновенных скачков.
Константные требования по количеству чанков в локации.
Каждый чанк требует некоторого количества "ресурсов", которые стримятся.
Ресурсы - потенциально shared, квадратные и все одинакового размера.

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

Для каждого чанка есть табличка фиксированного и одинакового для всех чанков размера (пока неизвестного), в которую в определенные (пока неизвестные) позиции будут записаны "номера" ресурсов требуемых этим чанком.

Тупым линейным по гриду алго заполняем эти таблички.
Инвариант - для каждой локации гарантируется, что размера таблички хватит, чтобы уместить все необходимые активным чанкам ресурсы, при этом никакие разные ресурсы в смежных по локации чанках не лежат в одной и той же позиции таблицы.
Ресурсы внутри табличек смежных по локации чанков лежат по одним и тем же местам (это необязательно но типа желательно).
(Это примерно то же самое распределение, которое даст твой ref counting - оно неоптимально, но всегда существует и не требует затрат на поиск.)
(Очевидно, я знаю алго, которое находит субоптимальное решение для неквадратных ресурсов в менее сферическо-вакуумном варианте.)

Резюмирую:
Теперь мы знаем размер таблиц - это то, куда будем класть ресурсы.
Во всех чанках есть табличка, в которой написано что где должно лежать (плюс "UNUSED" для позиций по которым похуй что лежит).
В смежных по локации чанках всегда можно разместить необходимые ресурсы.


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

Теперь загрузка нового чанка.
Матчим табличку чанка against нашей рабочей.
Если чанк требует ресурс а у нас там не он - мы обязаны загрузить туда требуемый ресурс. По инварианту это означает, что если у нас в этой позиции таблицы был какой-то ресурс - он нахуй никому не нужен и мы можем его выкинуть.

Выгрузка чанка - ничего не делаем.


Вкратце если интересно - чем это отличается от ref count:

1. Нет проёбов типа "выгрузить - бля! - загрузить обратно", которые неминуемы при ref counting - особенно если порядок загрузки чанков определяется фазой луны и есть дырки типа "ресурс нужен - теперь не нужен - а вот теперь снова нужен".
Очевидным образом, если уж выгрузили - то только для загрузки необходимого ресурса.

2. Нет проёбов типа "ох нихуя себе! и куда теперь грузить?!", неминуемых при ref counting - ты так и не рассказал, дорогой, как же ИМЕННО ты собираешься мне гарантировать, что при любых путях на "гриде" у тебя хватит памяти.
Более строго - реальный IP здесь - это алго распределения, если хочется хотя бы субоптимального решения.

3. Нет проёбов типа "ох нихуя себе! рисуем что успели загрузить!", неминуемых при ref counting - ты так и не рассказал, как же ИМЕННО ты собираешься мне гарантировать, что все ресурсы успеют загрузится при переезде от локации к локации при произвольных путях.


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

Весь механизм - в реальности - классический, но ощутимо более сложный, чем я здесь описал (кстати, я мог что-то проебать при упрощении, не обессудь).
Но алгоритмы и идеи - все из 70-80 годов - оверлеи IBM, раскраска регистров и т.п.


Теперь второе.
Никогда не задумывался, почему ни в оверлеях, ни в страничной виртуальной памяти не используются счётчики ссылок?
Думай.
(Reply) (Parent) (Thread)
[User Picture]From: sim0nsays
2006-06-01 07:36 am (UTC)
Руслан, кусочков одновременно - несколько. Мне кажется, ты постоянно упускаешь этот момент. В этом понимании то что в гриде есть ресурс, не нужный новому загружаемому куску не значит, что его надо выгружать. Потому что он другому нужен. И ты дополнишь к своей табличке тот самый рефкаунт при матченьи и выгрузке, да-да-да.

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

Гарантировать очень просто. Требования к памяти для точки-куска не зависят от того, каким путем мы к нему дошли. И поэтому его можно успешно проверять при экспорте. Сложно только формализуются требования к скорости стриминга как такового, но и здесь можно вполне строить оценки преходов, и как бы shared-ресурсы таки меньше уникальных.

Рефкаунт для таких shared-ресурсов - просто, тупо и весело. Оно дискретно, оно не имеет циклов, оно решает время жизни shared-объектов для независимых кусков в иерархии сверху-вниз.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-06-01 07:47 am (UTC)
Семёнчег, кусочков несколько, конечно.
И если есть ресурс, не нужный загружаемому куску - не надо его трогать.
Прочти внимательно, что я написал, тривиальная же схема :(

Только загружаешь, никогда не выгружаешь.

"Требования к памяти для точки-куска не зависят от того, каким путем мы к нему дошли."
Это надо понимать в том же русле, как и гарантии отсутствия фрагментации при malloc?
(Reply) (Parent) (Thread)
[User Picture]From: sim0nsays
2006-06-01 08:22 am (UTC)
Ага, я перечитал и вроде понял. Ух, круто как. Это новая для меня мысль. Я так не умею пока.

А если тот алгоритм "я не могу создать грид нужного размера" - что делать артистам? А если ресурсы достаточно разнородны по размерам (пусть даже по степеням двойки)? Что если соотношение shared-unique ресурсов сильно изменяется?
И мистический алго таки расскажи?
Ультимейт-вопрос - вы так делаете?

Я согласен, что так больше контроля. Ценой равномерности кусков и сложности алго.

Понимать - примерно в том же русле, да. Виртуальная память, текстуры, вся херня ;)
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-06-01 10:23 am (UTC)
Издеваешься?
А зря (ц)

Вопрос "вы так делаете", видимо, следует считать ударом ниже пояса.
Нет, в игровых автоматах Уникума используются совсем другие техники.

Что конкретно тебя так удивило?
Неравномерность кусков?
Ты про оверлеи и виртуальную память таки подумал?

Или ленишься? ;)
(Reply) (Parent) (Thread)
[User Picture]From: sim0nsays
2006-06-01 02:58 pm (UTC)
Хорошо, у вас стриминг вообще есть? :)
Подойдет любой другой пример "вместо refcount".

Ну, мне идея понравилась, на самом деле. Беседа получилась вполне позитивной и полезной.

Да, ответь плз на вопросы из предыдущего коммента. Про размеры, необходимый размер грида и т.д.?

Про виртуальную память я подумаю, но очевидной связи с предметом разговора не вижу. Нет там той предсказуемости, которую требует сколько-то управляемый refcount.
(Reply) (Parent) (Thread)
From: (Anonymous)
2006-06-01 06:26 pm (UTC)

мой пароль на работе

Зря Руслан и Семен сносят разговор чисто в техническую область, где по определению нет никаких сложностей. Шарообразность не в том, что ресурсы имеют разный тип, природу, разный размер; да и свойство квадратности у них зачастую отсутствует.

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

Вот посмотрим на пятых героев с точки зрения жителя страны эльфов. Очевидно, что есть ассеты, отвечающие разным фракциям. Хуманы, демоны, эльфы двух типов, подземелье. С каждой фракцией связаны свои типы террейна ( текстуры и декоративные объекты ), свои двеллинги, свой город. Есть константный кусок информации - это комбатные creatures, которые могут возникать произвольным образом. Есть города внутри, есть интерфейсы. Нужна рандомная карта - выбирай 3 фракции и ставь позволенные объекты. Все естественным образом разбивается на куски по 20 мегабайт. Плюс-минус.

Усилиями (мап)дизайна можно свести процент использования объектов внутри ассета к 50-90 процентам. Геометрия тяжелая? Жми, делай тонкий FVF. Текстуры тяжелые - пусть художники внутри одного ассета бьются, дрочат. Получится у тебя не 500 мегабайт выделения памяти в пике, а 100.

Оно конечно я силен после драки кулаками махать, но пятых героев можно сделать вполне себе такими консольными. Со спеками и лимитами. Прям щас могу расписать.

А вот спускаемся на грешную землю. Ах, батюшки мои, надо патч собирать, в нем домик поправили. И не один, а 10 штук, в каждом ассете по домику. Разъебаи. А еще в процессе работы художники заебываются ждать, пока этот ассет на 20 мегов скомпилируется. И он такой жесткий, бинарный, под систему контроля версий не ложится. На сервере терабайты кончились. Начинаются любимые Русланом процессы, и эта самая ебаная консольная загрузка не приносит никакого бизнес-вэлью. На топе PC игра идет, и хуй с ней.


(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-06-04 08:57 pm (UTC)
В последних двух предложениях - соль costs/benefit analysis.
Только он сложнее, чем тупое "давайте ничего не делать - оно так дешевле".
Потому что будут проёбаны и USP и added value и место на рынке.

Умение балансировать - единственно важное.
Собственно - это и есть то общее, о чём спрашивал Семён про музыкальную форму и про управление.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-06-04 08:53 pm (UTC)
refcount как раз непредсказуем.
Вот как тебе, скажем, вариант "размазанное копирование объекта в течение нескольких кадров"? Или "удаление ставших ненужными объектов на протяжении нескольких кадров"?
Простые же задачи, нет?
(Reply) (Parent) (Thread)