![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
aruslanНенавижу
автоматически рождающиеся объекты типа блокирующего loading-on-demand. И синглтоны типа Майерса.
автоматически уничтожающиеся объекты под smart_ptr. И подсчёт ссылок.
автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений.
автоматически создающиеся нетривиальные объекты со статическим storage duration. И вообще бурную деятельность до main().
мгновенность, нераспределенность, модель exception, lower-order programming.
Но научить правильно не всегда получается.
автоматически рождающиеся объекты типа блокирующего loading-on-demand. И синглтоны типа Майерса.
автоматически уничтожающиеся объекты под smart_ptr. И подсчёт ссылок.
автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений.
автоматически создающиеся нетривиальные объекты со статическим storage duration. И вообще бурную деятельность до main().
мгновенность, нераспределенность, модель exception, lower-order programming.
Но научить правильно не всегда получается.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: May. 31st, 2006 20:36 (UTC)Но уж тогда прости - не сферической вакуумности для, но краткости ради.
Одно описываю, второе - ты додумаешь.
Есть мир побитый на чанки типа грид, чанки стримятся.
Одна камера без мгновенных скачков.
Константные требования по количеству чанков в локации.
Каждый чанк требует некоторого количества "ресурсов", которые стримятся.
Ресурсы - потенциально shared, квадратные и все одинакового размера.
Строим таблицу всех ресурсов требуемых любым из чанков.
Вычисляем для каждого чанка список требуемых ему лично ресурсов.
Для каждого чанка есть табличка фиксированного и одинакового для всех чанков размера (пока неизвестного), в которую в определенные (пока неизвестные) позиции будут записаны "номера" ресурсов требуемых этим чанком.
Тупым линейным по гриду алго заполняем эти таблички.
Инвариант - для каждой локации гарантируется, что размера таблички хватит, чтобы уместить все необходимые активным чанкам ресурсы, при этом никакие разные ресурсы в смежных по локации чанках не лежат в одной и той же позиции таблицы.
Ресурсы внутри табличек смежных по локации чанков лежат по одним и тем же местам (это необязательно но типа желательно).
(Это примерно то же самое распределение, которое даст твой ref counting - оно неоптимально, но всегда существует и не требует затрат на поиск.)
(Очевидно, я знаю алго, которое находит субоптимальное решение для неквадратных ресурсов в менее сферическо-вакуумном варианте.)
Резюмирую:
Теперь мы знаем размер таблиц - это то, куда будем класть ресурсы.
Во всех чанках есть табличка, в которой написано что где должно лежать (плюс "UNUSED" для позиций по которым похуй что лежит).
В смежных по локации чанках всегда можно разместить необходимые ресурсы.
В рантайме у нас есть одна табличка, в которую мы пишем, что куда у нас сейчас загружено из ресурсов. Формат таблички - такой же, как и в чанках.
Теперь загрузка нового чанка.
Матчим табличку чанка against нашей рабочей.
Если чанк требует ресурс а у нас там не он - мы обязаны загрузить туда требуемый ресурс. По инварианту это означает, что если у нас в этой позиции таблицы был какой-то ресурс - он нахуй никому не нужен и мы можем его выкинуть.
Выгрузка чанка - ничего не делаем.
Вкратце если интересно - чем это отличается от ref count:
1. Нет проёбов типа "выгрузить - бля! - загрузить обратно", которые неминуемы при ref counting - особенно если порядок загрузки чанков определяется фазой луны и есть дырки типа "ресурс нужен - теперь не нужен - а вот теперь снова нужен".
Очевидным образом, если уж выгрузили - то только для загрузки необходимого ресурса.
2. Нет проёбов типа "ох нихуя себе! и куда теперь грузить?!", неминуемых при ref counting - ты так и не рассказал, дорогой, как же ИМЕННО ты собираешься мне гарантировать, что при любых путях на "гриде" у тебя хватит памяти.
Более строго - реальный IP здесь - это алго распределения, если хочется хотя бы субоптимального решения.
3. Нет проёбов типа "ох нихуя себе! рисуем что успели загрузить!", неминуемых при ref counting - ты так и не рассказал, как же ИМЕННО ты собираешься мне гарантировать, что все ресурсы успеют загрузится при переезде от локации к локации при произвольных путях.
Недостаток тоже очевиден - схема чуть более сложная в реальной жизни.
Но если достаточно неоптимальное решение - ничего сверхестественного в ней нет. Понятно, что таблицы реально выглядят иначе, да и номеров в ней нет, ну и т.п.
Весь механизм - в реальности - классический, но ощутимо более сложный, чем я здесь описал (кстати, я мог что-то проебать при упрощении, не обессудь).
Но алгоритмы и идеи - все из 70-80 годов - оверлеи IBM, раскраска регистров и т.п.
Теперь второе.
Никогда не задумывался, почему ни в оверлеях, ни в страничной виртуальной памяти не используются счётчики ссылок?
Думай.
no subject
Date: Jun. 1st, 2006 07:36 (UTC)Выгрузить-загрузить обратно будет с дискретностью перехода по нескольким кускам. Это большой период времени типично. И значит - пусть лучше он выгрузится, а потом загрузится.
Гарантировать очень просто. Требования к памяти для точки-куска не зависят от того, каким путем мы к нему дошли. И поэтому его можно успешно проверять при экспорте. Сложно только формализуются требования к скорости стриминга как такового, но и здесь можно вполне строить оценки преходов, и как бы shared-ресурсы таки меньше уникальных.
Рефкаунт для таких shared-ресурсов - просто, тупо и весело. Оно дискретно, оно не имеет циклов, оно решает время жизни shared-объектов для независимых кусков в иерархии сверху-вниз.
no subject
Date: Jun. 1st, 2006 07:47 (UTC)И если есть ресурс, не нужный загружаемому куску - не надо его трогать.
Прочти внимательно, что я написал, тривиальная же схема :(
Только загружаешь, никогда не выгружаешь.
"Требования к памяти для точки-куска не зависят от того, каким путем мы к нему дошли."
Это надо понимать в том же русле, как и гарантии отсутствия фрагментации при malloc?
no subject
Date: Jun. 1st, 2006 08:22 (UTC)А если тот алгоритм "я не могу создать грид нужного размера" - что делать артистам? А если ресурсы достаточно разнородны по размерам (пусть даже по степеням двойки)? Что если соотношение shared-unique ресурсов сильно изменяется?
И мистический алго таки расскажи?
Ультимейт-вопрос - вы так делаете?
Я согласен, что так больше контроля. Ценой равномерности кусков и сложности алго.
Понимать - примерно в том же русле, да. Виртуальная память, текстуры, вся херня ;)
no subject
Date: Jun. 1st, 2006 10:23 (UTC)А зря (ц)
Вопрос "вы так делаете", видимо, следует считать ударом ниже пояса.
Нет, в игровых автоматах Уникума используются совсем другие техники.
Что конкретно тебя так удивило?
Неравномерность кусков?
Ты про оверлеи и виртуальную память таки подумал?
Или ленишься? ;)
no subject
Date: Jun. 1st, 2006 14:58 (UTC)Подойдет любой другой пример "вместо refcount".
Ну, мне идея понравилась, на самом деле. Беседа получилась вполне позитивной и полезной.
Да, ответь плз на вопросы из предыдущего коммента. Про размеры, необходимый размер грида и т.д.?
Про виртуальную память я подумаю, но очевидной связи с предметом разговора не вижу. Нет там той предсказуемости, которую требует сколько-то управляемый refcount.
мой пароль на работе
Date: Jun. 1st, 2006 18:26 (UTC)Пока мы говорим за графы, в нодах которых кто-то сидит, за функции оценки и оптимальные алгоритмы - мы находимся в стране эльфов.
Вот посмотрим на пятых героев с точки зрения жителя страны эльфов. Очевидно, что есть ассеты, отвечающие разным фракциям. Хуманы, демоны, эльфы двух типов, подземелье. С каждой фракцией связаны свои типы террейна ( текстуры и декоративные объекты ), свои двеллинги, свой город. Есть константный кусок информации - это комбатные creatures, которые могут возникать произвольным образом. Есть города внутри, есть интерфейсы. Нужна рандомная карта - выбирай 3 фракции и ставь позволенные объекты. Все естественным образом разбивается на куски по 20 мегабайт. Плюс-минус.
Усилиями (мап)дизайна можно свести процент использования объектов внутри ассета к 50-90 процентам. Геометрия тяжелая? Жми, делай тонкий FVF. Текстуры тяжелые - пусть художники внутри одного ассета бьются, дрочат. Получится у тебя не 500 мегабайт выделения памяти в пике, а 100.
Оно конечно я силен после драки кулаками махать, но пятых героев можно сделать вполне себе такими консольными. Со спеками и лимитами. Прям щас могу расписать.
А вот спускаемся на грешную землю. Ах, батюшки мои, надо патч собирать, в нем домик поправили. И не один, а 10 штук, в каждом ассете по домику. Разъебаи. А еще в процессе работы художники заебываются ждать, пока этот ассет на 20 мегов скомпилируется. И он такой жесткий, бинарный, под систему контроля версий не ложится. На сервере терабайты кончились. Начинаются любимые Русланом процессы, и эта самая ебаная консольная загрузка не приносит никакого бизнес-вэлью. На топе PC игра идет, и хуй с ней.
no subject
Date: Jun. 4th, 2006 20:57 (UTC)Только он сложнее, чем тупое "давайте ничего не делать - оно так дешевле".
Потому что будут проёбаны и USP и added value и место на рынке.
Умение балансировать - единственно важное.
Собственно - это и есть то общее, о чём спрашивал Семён про музыкальную форму и про управление.
no subject
Date: Jun. 4th, 2006 20:53 (UTC)Вот как тебе, скажем, вариант "размазанное копирование объекта в течение нескольких кадров"? Или "удаление ставших ненужными объектов на протяжении нескольких кадров"?
Простые же задачи, нет?