1. Почти довёл X11 фреймворк:работает всё, включая переключение полноэкранный/оконный, но панель задач XFCE остаётся поверх полноэкранного окна. Отложил до тех пор, пока поставлю куда-нибудь убунту свежее, чем то ископаемое пятилетней давности, на котором сейчас тестю.
2. Преодолел затык в портировании на Raspberry Pi II. Окно создаётся, библиотека грузится, падает потом: порт на GLES даже близко не завершён.
Снова откладываю линукс, чтобы сосредоточиться на ключевых игровых механиках. К линуксу вернусь когда можно будет пострелять, побегать.
Добавлено спустя 2 часа 58 минут 15 секунд:Окей, памятка себе чтобы не забыть, как будет работать игровая логика (до которой ещё семь вёрст раком):
1. Полоумные указатели:
Игровые объекты - со счётчиком ссылок. Когда один физический объект обращается к другому, который потенциально мог деспавниться - от мобов до чанков до целых вселенных - он должен сначала пнуть его метод "Ты_там_живой?(держи бестиповый указатель на мою ссылку на тебя). Если тот не живой (для чего у всех игровых объектов предусмотрен специальный флаг "моооозги"), то он сбрасывает эту ссылку в nil, тем самым сокращая свой счётчик ссылок.
Вся красота этого метода в крахоустойчивости: даже если погромист забудет добавить вызов Ты_там_живой() перед обращением, то худшее, что может произойти - ссылаемый на зависнет на какое-то время в состоянии зомби пока ссылающийся не обратится к нему правильно.
Для отладки - несложная проверка на утечки зомбей при очередном обходе графа (например, при сохранении). То есть всё прекрасно ловится.
2. Чанки и любые другие сложные сущности хранятся как объекты с одним/несколькими числовыми массивами внутри. В частности, у чанка эти массивы содержат упакованные хитрым образом мини-октри.
При клонировании такого объекта, все массивы клонируются путём увеличения счётчика ссылок (после копирования ссылки, которое происходит при тупом копировании внутренностей инстанса как бинарного блоба).
Естественно, любая запись в любой такой массив должна предваряться SetLength(a, Length(a)). Подумываю даже сделать собственную имплементацию array of Longint, где любая запись идёт через методы, гарантирующие Copy-on-write, и собственным диспетчером памяти, чтобы счётчики ссылок компактно лежали отдельно от тела массива - можно, например, уменьшить счётчик ссылок до одного байта, и блокировать тела массивов посредством
VirtualProtect чтобы сделать, например, основной слой только для чтения в то время, как идёт просчёт всплывающего слоя - гарантированно ловя любые ошибки в коде, поскольку запись куда не надо вызовет AV.
3. Отпочковывание всплывающего слоя выглядит так:
а. Составляется список чанков, попадающих в расслаиваемую зону. Помечаются флагом "Ыц".
б. Составляется список объектов, находящихся внутри расслаиваемой зоны. Помечаются флагом "Ыц".
в. Осуществляется клонирование по флагу "Ыц", где корневым объектом служит список чанков, подлежащих клонированию. В процессе оного, ссылки на клонируемые объекты изменяются на ссылку на клон, а ссылки на объекты без флага остаются ссылками на базовый слой (примечание: это таки требует специализированного диспетчера памяти с отдельнолежащими полями, мне больше не отвертеться: каждому объекту надо временно придать поле "вот ссылка на мой клон", а пихать её внутрь самого объекта будет слишком жирно).
Одно важное исключение: если у чанка ссылка на соседний чанк, который в зону не входит, то она сбрасывается в NIL.
г. Сброс флага "Ыц" у всех затронутых.
Имеем: копированию подвергается порядка двух тысяч объектов сравнительно небольшого размера (порядка 200 байт), все тяжеловесные таблицы как лежали в массивах, так и лежат (и, со специализированным диспетчером памяти, их даже никто не трогал).
4. Физика расслоенного мира
- поскольку ссылки на объекты за пределами зоны сохраняются, то, например, бот продолжит преследование игрока который за границей видимости, только не идеально точно (его реакция будет слегка лагать, поскольку тот игрок - в отстающем базовом слое) Более того, бот, скорее всего, перестанет видеть того игрока, поскольку все запросы проверить линию взгляда идут через иерархию чанков и будут упираться в NIL. А огонь игрока не попадёт по боту, поскольку не существует во всплывающем слое. Все подобные последствия корректируются путём всплывания нового слоя от базового - т.е. нещадно лагают.
- любое изменение чанка (в массивах же) приводит к тому, что затронутый массив copy-on-writится. Но только он. Иначе всё просто сдохло бы: плавающих слоёв - минимум два, и все, кроме одного, гоняют физику на многократно увеличенной скорости
- критически важно чтобы мобы могли повлиять друг на друга только посредством событий, отправляемых через чанк. Никакого "Я тебя вижу?.. А если найду?.. Тогда я в тебя запулил!". Моб спрашивает у своего чанка: "Я вижу вон того ханурика?", подписываясь на событие "проверка видимости". Через некоторе время (как оптимизация трассировки лучей сложится, может, через несколько кадров) чанк сигналит мобу: "видишь". Тогда моб говорит чанку "Окей, моя стреляй рейлган вот по этому вектору", создавая объект "выстрел из рейлгана". Чанк просчитывает линию, видит, что линия упёрлась в его внешнюю границу, и пинает соседа: "Эй, тут тебе из рейлгана прилетело, вот объект". И так по цепочке, пока не попадёт во что-нибудь. Причём, если упрётся в NIL - просто молча останавливается. Если попало куда надо - объекту выстрела сигналят, в кого попал, а уже тот сигналит своему родному боту "Поздравляю, ты фрагнул имярек, кровькишкирасхреначило" и тот включает анимацию "
"
- также все взаимодействия чанка с NIL соседом замирают: если оттуда лилась вода - она продолжит литься до бесконечности, с той же скоростью. Если дотуда дотечёт вода, она будет течь дальше с той скоростью, с какой втекла в прикасающийся к NIL стенке блок. И т.п.
Лирическое отступление: текущая вода - статический блок, обладающий параметрами скорости и давления. Меняется лениво при изменении давления соседей, обладает заметной петлёй гистерезиса. Что позволяет:
- задёшево создавать эпические потопы а ля Terraria, где значительная часть потопа статична, и потоп вменяемо ведёт себя на границе активной зоны вокруг игрока (общее количество воды не сохраняется, если текло из NIL - то может налиться целое море из ручейка, если текло в NIL - то будет утекать пока не утечёт целое море: у блока, соседствующего с несуществующим, просто не будет пересчитываться скорость течения
- автогенерировать текущие реки, которые с точки зрения физики абсолютно статичны
Cheb » 12.10.2016 16:14:02 
