?

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: sim0nsays
2006-05-31 06:49 pm (UTC)
Убил и съел - значит, не выполнил философских ожиданий? Я по-другому не умею разговаривать, мне непонятно без объяснений на пальцах.

Ну надо контролировать цикл жизни shared-кусков. Вовремя их выгружать-загружать и т.д. Как это делать?

Proxy - для буферизации запросов. Пришел новый кусок SG на загрузку, загрузил одним куском уникальные данные. Теперь нужно загружать shared. Составили список тех, которых еще не загружено, поставили вместо них proxy, ждем асинхронной загрузки.

Выгружать надо так, чтобы те, кто эти же данные пользуют, не погибли. Кусков одновременно, конечно, живет много.
Как их менеджить и это контролировать?

Сравнивать со спеками можно прямой "загрузкой" - позиция в мире определяет объем загруженных данных. Я лично вижу только проблему контроля спеков на время загрузки этих частей. Что во-первых из-за фрагментирования винта и так хер проконтролируешь и во-вторых оценки таки есть в препроцессе.

(Reply) (Parent) (Thread)
[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)