Помощники

[aruslan]

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

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

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

Comments

[sim0nsays.livejournal.com]

Руслан, кусочков одновременно - несколько. Мне кажется, ты постоянно упускаешь этот момент. В этом понимании то что в гриде есть ресурс, не нужный новому загружаемому куску не значит, что его надо выгружать. Потому что он другому нужен. И ты дополнишь к своей табличке тот самый рефкаунт при матченьи и выгрузке, да-да-да.

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

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

Рефкаунт для таких shared-ресурсов - просто, тупо и весело. Оно дискретно, оно не имеет циклов, оно решает время жизни shared-объектов для независимых кусков в иерархии сверху-вниз.

[aruslan.livejournal.com]

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

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

"Требования к памяти для точки-куска не зависят от того, каким путем мы к нему дошли."
Это надо понимать в том же русле, как и гарантии отсутствия фрагментации при malloc?

[sim0nsays.livejournal.com]

Ага, я перечитал и вроде понял. Ух, круто как. Это новая для меня мысль. Я так не умею пока.

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

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

Понимать - примерно в том же русле, да. Виртуальная память, текстуры, вся херня ;)

[aruslan.livejournal.com]

Издеваешься?
А зря (ц)

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

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

Или ленишься? ;)

[sim0nsays.livejournal.com]

Хорошо, у вас стриминг вообще есть? :)
Подойдет любой другой пример "вместо refcount".

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

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

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

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

[(Anonymous)]

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

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

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

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

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

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

[aruslan.livejournal.com]

В последних двух предложениях - соль costs/benefit analysis.
Только он сложнее, чем тупое "давайте ничего не делать - оно так дешевле".
Потому что будут проёбаны и USP и added value и место на рынке.

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

[aruslan.livejournal.com]

refcount как раз непредсказуем.
Вот как тебе, скажем, вариант "размазанное копирование объекта в течение нескольких кадров"? Или "удаление ставших ненужными объектов на протяжении нескольких кадров"?
Простые же задачи, нет?