Alex2013 писал(а): 19.03.2026 11:03:51
А не пора ли все-же перебраться на более продвинутый в плане графики движок ?
БД и День истребления написаны даже не под GZDoom, они написаны под Зандронум - уникальный порт дума с клиент-серверной архитектурой, застрявший навеки в 2012-м году по уровню технологий. Потому что это форк ZDoom 1.5.
Если кто-то решит переписать БД и День Истребления полностью с нуля на новый движок - флаг ему в руки. Я думаю, одному человеку понадобится всего пять или шесть лет, упахиваясь каждый день с перерывами на еду и сон.
sts писал(а): 19.03.2026 13:08:01
счетчик ссылок сбрасывает кеш
ЕСЛИ его имплементировать наивно, как стандартные менеджед типы в ФП.
Но я имплементирую его используя ускоренные поля - фича сродни Entity Component System, заточеннная под дружественность кешу. Их изменение *не* прикасается к инстансу, к которому они привязаны - всё идёт через чёрную магию арифметики с указателями.
З.Ы. Это уже давно имплементировано через хитровывернутый диспетчер памяти для инстансов - всеми премудростями заведует класс TChepersyMemoryManagerChunk , а инстанс чанка для любого инстанса получаем очищая младшие 17 бит, поскольку NewInstance чанка выравнивает его на 128 Кб. Т.е. под инстанс чанка выделяется 128Кб и чанк содержит инстансы одинакового размера (64, 128, 192 байт и т.д - в целых линейках кеша). И память под инстансы игровых объектов выделяет внутри этих 128 Кб, за концом собственных полей. А собственные поля в основном состоят из массивов ускоренных полей - причём, при чтении сначала проверяется битовая маска, которая в 32 раза компактнее чем само ускоренное поле, ещё дальше уменьшая загрязнение кеша).
В текущей имплементации в ускоренных полях хранятся флаги, а также индексы, используемые при сериализации и прочем обходе графа - что минимум вдвое ускорило обход графа, поскольку инстансы дёргаются только на чтение и только один раз, а проверка индексов их вообще не трогает.
З.З.Ы. И я буду по возможности избегать локальных переменныъ типа "умная ссылка" - это будут 99% поля игровых объектов, т.е. счётчик ссылок будет дёргать только при изменении самих игровых объектов, конкретно - при изменениях связей между ними.
Если же проводится проверка "текущий враг вообще жив и не готов ли укусить меня за жопу" - это делается посредством вызова метода Peek умной ссылки, который возвращает обычный указатель на инстанс, который записывается в локальную переменную - а объектные указатели не менеджед ни разу.
Да, я ностальгирующий дед, я назвал ключевые методы механизма расслаиваемого мира "Peek" и "Poke"
З.З.З.Ы. А заодно кладбища заворачиваются в простыню и ползут на кладбище:
1. Метод Scrape больше не хоронит на кладбище, он освобождает *немедленно* если счётчик ссылок нулевой - т.е. действует как Free если не использовались умные ссылки.
2. Менеджер памяти шерстит все свои чанки каждый кадр (не каждый тик, а каждый кадр) на предмет Scraped объектов с нулевым счётчиком ссылок и делает им секир-башка. Ооочень дешёвая операция, учитывая, как всё организовано (и это * один* проход).
