Relict Engine
44 поста
44 поста
12 постов
RatTools теперь используется как пакетный рекурсивный импортер ресурсов.
Добавлена заготовка для системы материалов.
Потихоньку идет работа над конвейером и импортером материалов. Идет тяжелее, чем надеялся, но идет (больше читаю спецификации, чем пишу + работа + РКН и моя личная борьба с ними).
Итак, что получается на данный момент.
За основу взял заготовку, о которой писал тут: Relict Engine: Шейдеры. Часть 2. Материалы. Синтаксис
Вписал в RatTools парсер трех словных команд по принципу: команда аргумент значение. Для примера: use domain Simple - use команда, domain аргумент, а Simple значение.
Сделал, пока откровенным говнокодом, обработку этого дела. Команда use (в указанном выше посте using) domain подгружает Vertex.glsl и Fragment.glsl из директории SHADERS/domain/%Значение%, считывает их. Подгружает дополнительные файлы glsl с помощью самодельной команды препроцессора #include и подставляет в нужные места значения команды set с выборкой по аргументу. Выглядит это на данный момент так:
inline vec3 Material_Offset()
{
#set return vOffset:vec3(0)
}
Допустим, есть у нас вот такая функция. Парсер видит самодельную команду препроцессор #set с двумя аргументами и селектором ':'. Обращается к хранилищу команды set и ищет там аргумент vOffset. Если находит, то подставляет его значение на место этой строки, если нет, то значение после селектора. В итоге функция превращается в
inline vec3 Material_Offset()
{
return vec3(0);
}
ну или, если vOffset присутствует в материале, то подставится его значение. Заместо return может быть имя переменной, тогда вместо return будет оператор присвоения, например
void Material_Offset(out vec3 MaterialOffset)
{
#set MaterialOffset vOffset:vec3(0)
}
вернет нам
void Material_Offset(out vec3 MaterialOffset)
{
MaterialOffset = vec3(0);
}
ну и тд, но до создания переменной заданного типа пока не доросли (и я не уверен, нужно ли это).
Прежде чем идти дальше (перегнать все это в SPIR-V формат и добавить недостающий функционал, типа ввода/вывода юниформов) хочу немного причесать код, да избавится от ряда костылей, которые появились пока я пробовал разные подходы к форматированию.
P.S. Вот после этой новости мои прошлые посты с тезисом, что РКН под прикрытием блокировок занимается прямой диверсионной деятельностью в отношении критической ИТ-инфраструктуры и сотрудников ИТ-сферы России уже не кажутся прям таким бредом? Сколько тут было комментаторов "вы всё врёте"?
Хоспаде, как вы заебали уже с этим. Там не роботы работают, а люди. Косячат, да. Ну а хули. Не косячит лишь тот, кто нехуя не делает. Далее. Вот вы панику разводите. А по факту те, кто с этими ресурсами работает, и у кого они внезапно заблокировались, уже давно списались с техподдержкой, которая занимается обслуживанием ТСПУ, и уже все пофикшено (если сей факт вообще имел место быть, и это не связано с косяками провайдеров, или утренним сбоем на IX, который имел место быть).
Я вам даже больше скажу. Любой человек может пожаловаться своему оператору на заблокированный ресурс, и оператор будет обязан связаться с той-же поддержкой ТСПУ. И в 90% случаев (ну кроме понятных youtube, tg, discord итд, т.е. те о которых они публично говорили) все разбанивается (правда тут есть минус - разбанивается на конкретном ТСПУ, через который трафик обратившегося ходит).
И добавлю: Большинство проблем сейчас связаны лишь с тем, что особо одаренные товарищи, заместо того, чтобы обратится по адресу со своей проблемой пытаются хитрожопить особо выебанными способами, что лишь увеличивает вероятность т.н. "блокировок за компанию" и в последствии увеличивает же время реакции на косяки. Так что по большему счету (но подчеркну отдельно, что не всегда), вы сами себе же злобные буратины.
И второе: если вы нашли метод обхода, то блять, не трубите об этом в пабликах. Не будьте дегенератами. Помните, что паблики мониторят СМИ. А Сми уже Минцифры, которые оперативно спускают в РКН приказ банить эту новую хуйню (и далее см. пункт 1).
Все, можете минусить.
Добавлены Log Facility в первом приближении
Атом Configable частично переделал на Property
Мелкие исправления
Просто маленький пост на финишной прямой миграции ядра на новую кодобазу. Ранее я уже игрался с классом свойством, но хотел отложить работу с ними до лучших времен, когда вернусь к доделкам скриптовой подсистемы. Однако посидев, подумав и покурив уже готовый код пришел к мнению, что частично класс-свойство можно ввести уже сейчас и использовать как обертку для сериализованных конфиг переменных. Попробовал. Понравилось.
Для сравнения было/стало
вот так было ранее. Подключался атом, в конструкторе которого задавалась секция конфига, и потом через функцию-макрос оно подгружалась.
Как видно, конфиг и секция теперь задаются в инит. структуре, однако непосредственно процесс загрузки переменной теперь спрятан под капот в объект Property. В коде Property ведет себя как обычная типовая переменная указанного типа. В данном случае int32_t. Значение 42, указанное в конструкторе является значением по умолчанию. Т.е. если в конфиге переменная не указана, то TestProperty инициализируется со значением 42, если указано, то оно инициализируется уже со значением из конфига. Текстовое представление Property может быть каким-угодно, т.к. рефлексии в c++ нету (ну вернее уже есть в стандарте C++26, но лучше его пока не трогать).
Смысл его пока только в загрузке данных из конфига (и сохранение в user конфиг), но в дальнейшем потихоньку расширю этот функционал.
Добавлен логгер из "Proof of Concept" версии движка
Исправлена ошибка связывания сущности RenderObject с UnitObject
Исправлена ошибка линковки мета классов в модулях
Почти закончил миграцию ядра на новую кодобазу. По сути осталось ровно две вещи сделать: чтение переменных конфигов в класс, и чуть модернизировать логгер, чтобы можно было им управлять через инит. структуру мета класса и добавить ему т.н. заводы "Facility" (сейчас он подключен как самостоятельная сущность).
Сам лог довольно подробный в DEBUG режиме; ротирует файлы лога по дате/времени ротации и пишет данные не только в непосредственно файл, но и в консоль. Выглядит это так:
Log started at 2026-02-03 13:39:02.968 GMT+3
[Debug] 2026-02-03 13:39:02.991 GMT+3 - Core: Class Relict::AssetManager Registred
[Debug] 2026-02-03 13:39:02.992 GMT+3 - Core: Class Relict::IFileSystem Registred
[Debug] 2026-02-03 13:39:02.992 GMT+3 - Core: Class Relict::FSManager Registred
[Debug] 2026-02-03 13:39:02.992 GMT+3 - Core: Class Relict::IAsset Registred
[Debug] 2026-02-03 13:39:02.993 GMT+3 - Core: Class Relict::ThreadManager Registred
[Debug] 2026-02-03 13:39:02.993 GMT+3 - Core: Class Relict::IRenderWindow Registred
[Debug] 2026-02-03 13:39:02.993 GMT+3 - Core: Class Relict::SubsystemManager Registred
[Debug] 2026-02-03 13:39:02.994 GMT+3 - Core: Class Relict::ISubsystem Registred
[Debug] 2026-02-03 13:39:02.994 GMT+3 - Core: Class Relict::StaticMesh Registred
[Debug] 2026-02-03 13:39:02.994 GMT+3 - Core: Class Relict::TestAsset Registred
[Debug] 2026-02-03 13:39:02.995 GMT+3 - Core: Class Relict::RenderWindow Registred
[Debug] 2026-02-03 13:39:02.995 GMT+3 - Core: Class Relict::GameEntity Registred
[Debug] 2026-02-03 13:39:02.995 GMT+3 - Core: Class Relict::GameWorld Registred
[Debug] 2026-02-03 13:39:02.996 GMT+3 - Core: Class Relict::Units::SceneUnit Registred
[Debug] 2026-02-03 13:39:02.996 GMT+3 - Core: Class Relict::IScene Registred
[Debug] 2026-02-03 13:39:02.996 GMT+3 - Core: Class Relict::FS::RelictFS Registred
[Debug] 2026-02-03 13:39:02.997 GMT+3 - Core: Class Relict::FS::SystemFS Registred
[Debug] 2026-02-03 13:39:02.997 GMT+3 - Core: Class Relict::Render::IRenderObject Registred
[Debug] 2026-02-03 13:39:02.997 GMT+3 - Core: Class Relict::Units::RenderUnit Registred
[Debug] 2026-02-03 13:39:02.998 GMT+3 - Core: Class Relict::Render::IRender Registred
[Debug] 2026-02-03 13:39:02.998 GMT+3 - Core: Class Relict::Renderer Registred
[Debug] 2026-02-03 13:39:02.998 GMT+3 - Core: Class Relict::Units::StaticMeshUnit Registred
[Debug] 2026-02-03 13:39:02.999 GMT+3 - Core: Class Relict::Render::StaticMesh_RenderObject Registred
[Debug] 2026-02-03 13:39:02.999 GMT+3 - Core: Class Relict::Render::VertexArrayObject Registred
[Debug] 2026-02-03 13:39:02.999 GMT+3 - Core: Class Relict::Render::OpenGL Registred
[Debug] 2026-02-03 13:39:03.000 GMT+3 - Core: Created Object Renderer_S class Relict::Renderer owned by none
[Debug] 2026-02-03 13:39:03.001 GMT+3 - Core: Created Object OpenGL_S class Relict::Render::OpenGL owned by none
[Debug] 2026-02-03 13:39:03.001 GMT+3 - Core: Class Relict::Render::StaticMesh_GLRenderObject Registred
[Debug] 2026-02-03 13:39:03.002 GMT+3 - Core: Class Relict::Game::Actor Registred
[Debug] 2026-02-03 13:39:03.002 GMT+3 - Core: Class TestNv Registred
[Debug] 2026-02-03 13:39:03.002 GMT+3 - Core: Class TestInhNv Registred
[Debug] 2026-02-03 13:39:03.003 GMT+3 - Core: Class TestActor Registred
[Debug] 2026-02-03 13:39:03.267 GMT+3 - Core: Created Object FSManager_S class Relict::FSManager owned by none
[Debug] 2026-02-03 13:39:03.267 GMT+3 - Core: Created Object SystemFS_S class Relict::FS::SystemFS owned by none
[Debug] 2026-02-03 13:39:03.268 GMT+3 - Core: Created Object AssetManager_S class Relict::AssetManager owned by none
[Debug] 2026-02-03 13:39:03.268 GMT+3 - Core: Created Object StaticMesh_1 class Relict::StaticMesh owned by AssetManager_S
[Debug] 2026-02-03 13:39:03.269 GMT+3 - Core: Object /Cube previously known as StaticMesh_1
[Debug] 2026-02-03 13:39:03.269 GMT+3 - Core: Created Object StaticMesh_2 class Relict::StaticMesh owned by AssetManager_S
[Debug] 2026-02-03 13:39:03.270 GMT+3 - Core: Object /Mesh previously known as StaticMesh_2
[Debug] 2026-02-03 13:39:03.270 GMT+3 - Core: Created Object StaticMesh_3 class Relict::StaticMesh owned by AssetManager_S
[Debug] 2026-02-03 13:39:03.271 GMT+3 - Core: Object /Torus previously known as StaticMesh_3
[Debug] 2026-02-03 13:39:03.271 GMT+3 - Core: Created Object ThreadManager_S class Relict::ThreadManager owned by none
[Debug] 2026-02-03 13:39:03.272 GMT+3 - Core: Created Object SubsystemManager_S class Relict::SubsystemManager owned by none
[Debug] 2026-02-03 13:39:03.272 GMT+3 - Core: Created Object RenderWindow_1 class Relict::RenderWindow owned by none
[Info] 2026-02-03 13:39:03.778 GMT+3 - Empty Application run
[Debug] 2026-02-03 13:39:03.779 GMT+3 - Core: Created Object TestNv_1 class TestNv owned by none
[Debug] 2026-02-03 13:39:03.779 GMT+3 - Core: Created Object GameWorld_1 class Relict::GameWorld owned by none
[Debug] 2026-02-03 13:39:03.780 GMT+3 - Core: Created Object TestActor_1 class TestActor owned by GameWorld_1
[Debug] 2026-02-03 13:39:03.780 GMT+3 - Core: Created Object SceneUnit_1 class Relict::Units::SceneUnit owned by TestActor_1
[Debug] 2026-02-03 13:39:03.780 GMT+3 - Core: Created Object StaticMeshUnit_1 class Relict::Units::StaticMeshUnit owned by SceneUnit_1
[Debug] 2026-02-03 13:39:03.781 GMT+3 - Core: Created Object StaticMeshUnit_2 class Relict::Units::StaticMeshUnit owned by StaticMeshUnit_1
[Debug] 2026-02-03 13:39:09.308 GMT+3 - Core: Created Object StaticMesh_GLRenderObject_1 class Relict::Render::StaticMesh_GLRenderObject owned by StaticMeshUnit_2
[Debug] 2026-02-03 13:39:09.309 GMT+3 - Core: Created Object VertexArrayObject_1 class Relict::Render::VertexArrayObject owned by /Cube
[Debug] 2026-02-03 13:39:12.098 GMT+3 - Core: Created Object StaticMesh_GLRenderObject_2 class Relict::Render::StaticMesh_GLRenderObject owned by StaticMeshUnit_1
[Debug] 2026-02-03 13:39:16.659 GMT+3 - Core: Object RenderWindow_1 Marked for destruction
[Debug] 2026-02-03 13:39:16.689 GMT+3 - Core: Deleting Object RenderWindow_1
[Info] 2026-02-03 13:39:16.689 GMT+3 - Empty Application end
[Debug] 2026-02-03 13:39:16.690 GMT+3 - Core: Deleting Object StaticMeshUnit_2
[Debug] 2026-02-03 13:39:16.690 GMT+3 - Core: Deleting Object StaticMeshUnit_1
[Debug] 2026-02-03 13:39:16.691 GMT+3 - Core: Deleting Object SceneUnit_1
[Debug] 2026-02-03 13:39:16.691 GMT+3 - Core: Deleting Object GameWorld_1
[Debug] 2026-02-03 13:39:16.692 GMT+3 - Core: Deleting Object TestActor_1
[Debug] 2026-02-03 13:39:16.692 GMT+3 - Core: Deleting Object StaticMesh_GLRenderObject_1
[Debug] 2026-02-03 13:39:16.692 GMT+3 - Core: Deleting Object StaticMesh_GLRenderObject_2
[Debug] 2026-02-03 13:39:16.693 GMT+3 - Core: Deleting Object TestNv_1
[Debug] 2026-02-03 13:39:16.693 GMT+3 - Core: Deleting Object VertexArrayObject_1
[Debug] 2026-02-03 13:39:16.693 GMT+3 - Core: Deleting Object ThreadManager_S
[Debug] 2026-02-03 13:39:16.693 GMT+3 - Core: Deleting Object SystemFS_S
[Debug] 2026-02-03 13:39:16.694 GMT+3 - Core: Deleting Object /Mesh
[Debug] 2026-02-03 13:39:16.697 GMT+3 - Core: Deleting Object /Cube
[Debug] 2026-02-03 13:39:16.697 GMT+3 - Core: Deleting Object /Torus
[Debug] 2026-02-03 13:39:16.698 GMT+3 - Core: Deleting Object FSManager_S
[Debug] 2026-02-03 13:39:16.698 GMT+3 - Core: Deleting Object OpenGL_S
[Debug] 2026-02-03 13:39:16.698 GMT+3 - Core: Deleting Object SubsystemManager_S
[Debug] 2026-02-03 13:39:16.699 GMT+3 - Core: Deleting Object Renderer_S
[Debug] 2026-02-03 13:39:16.699 GMT+3 - Core: Deleting Object AssetManager_S
Log closed at 2026-02-03 13:39:16.699 GMT+3
И дебажить код стало сильно легче )
PS: Если присмотреться, то видно, что есть еще один не исправленный баг (TestNV_1 не самоудаляется, хотя должен, т.к. не указан владелец) - [UPD: исправлено. Забыл проверку на овнера сделать в регистраторе Сборщика мусора, когда переделывал на событийную модель
[Debug] 2026-02-03 14:48:42.331 GMT+3 - Core: Created Object TestNv_1 class TestNv owned by NaN
[Debug] 2026-02-03 14:48:42.331 GMT+3 - Core: Object TestNv_1 Marked for destruction
...
[Debug] 2026-02-03 14:48:42.335 GMT+3 - Core: Deleting Object TestNv_1
]
Снова исправил дублирование создания копий мета классов для одной и той-же сущности, путем вынесения функции из шаблона класса в глобальное пространство имен(проблема линковки при inline переменных), что автоматом исправило проблему, которая вылезла несколько ранее с привязкой объекта рендер пайпа к юниту сцены (не находил нужный метакласс, так-как создавал новый при регистрации делегата создания из-за того, что был разный контекст вызова функции). Долго дебажил это дело, поэтому и лог сегодня такой маленький.
Краткий список изменений:
Ядро переключено на новую кодобазу с метаклассами
Удалены сущности DefaultObject
Изменен принцип регистрации сущностей со статичных вызовов на делегаты
Заменен старый глобальный тикер на новый через метакласс
Добавлен функционал Subticks с заданным интервалом
Функция тикера вызывается каждые N миллисекунд, где N заданное произвольное число
Куча мелких исправлений (и еще столько же предстоит исправить)
Комментарий:
В общем, как я не старался, но все равно поломал почти все при переключении. Сейчас движок практически полностью работает на новой кодобазе ядра (и под работает я имею ввиду компилируется под платформы и запускается). Есть шероховатости, дебажу потихоньку. Например, после переключения на метаклассы, выстрелило то, чего я боялся в старой кодобазе - а именно нарушилась очередь создания объектов, в результате чего объект мог запросить метаинформацию раньше, чем она была создана в ядре (что любопытно, поймать это удалось только в gcc).
Но это поправил, хоть и не совсем, как мне кажется, красиво и видимо все-таки нужно будет в следующем обновлении ядра (начало след. года, видимо) подумать про глобальную сущность, которая будет хранить все ранние делегаты, чтобы вызывать их не из глобальной части кода, а после того, как все шаблоны раскрылись и инициализировались во всех модулях. И дергать из функции инициализации уже.
Миграция все еще в процессе и займет довольно продолжительное кол-во времени. Благо в начале Февраля начинается отпуск. Там, думаю, дела пойдут веселее и в Марте переключусь уже непосредственно на графоний, чтобы не отставать от намеченного плана.
Добавлены структуры инциализаторы шаблонного класса RelictClass
На данный момент просто как сущность. Функционал для них пока не готов.
Добавлен класс Relict::Class как хранилище инициализационных структур
Перенесена часть функционала, касающаяся регистрации/удаления объектов из ObjectStorage в Relict::Class
Упрощена работа Сборщика мусора путем перевода его на событийную модель
Добавлены заготовки на контейнеры сетевых/скриптовых полей Property
Добавлены в качестве залипухи на будущее. В логике работы движка они ни коем образом не участвуют.
Пока новый код работает параллельно со старым. Полностью переключу движок на новый код чуть позднее, когда появится уверенность, что весь ранее заложенный функционал работает корректно в новой реализации.
Касательно структур, решил сделать чуть иначе, чем в концепт-коде, приведенном в пред. посте: Relict Engine: Начало сезона 2026
Вместо некрасивого нагромождения различных скобок в шаблоне (который еще и очень не нравится IDE, несмотря на то, что стандарт допускает такое использование) вынес их отдельно. Теперь это выглядит вот так:
Потихоньку выхожу из майонезной комы и начинаю продолжать разработку.
Как и говорил в итогах, начало этого года будет посвящено работе над ошибками и некоторому рефакторингу кода ядра. Отказу от Атомной системы расширений и прочим мелочам.
Как показала практика использования, система атомов не состоятельна. Нет, ее можно использовать на уровне проектов для внедрения дополнительного функционала, но не на уровне ядра. Поэтому она идет под нож. Заместо нее появятся конфигурационные структуры для шаблонов классов. Выглядеть они будут примерно так:
концепт код: https://godbolt.org/z/q1zPeMeE3
Так-же, подобные структуры позволят нам реализовать ряд интересных вещей. Например, после реализации мета классов, они позволят нам связать создание одного объекта с другим объектом (Например класс RenderObject с SceneUnit) для более прозрачной работы конвейера.
Вторым крупным улучшением (которое уже внедрено и работает), стало замена тикера Сборщика мусора на событийную модель. Это сильно повысило производительность, т.к. я избавился от цикла перебора всех созданных движком объектов. И, смотря на перспективу, возможно, сборщик мусора будет объеден с глобальным хранилищем объектов, ибо уже сейчас бессмысленно ее держать отдельно. Но это уже потом; узелок на память завязал.
Третьим улучшением, которое частично будет реализовано сейчас, а частично очень потом - это внедрение мета классов аналогов UClass в Unreal Engine, для хранения константных проинициализированных структур инициализаторов и мета методов для работы с Lua. Что позволит нам сильно упростить работу с скрипт подсистемой. Которая, возможно, перейдет из состояния подсистемы в ядро (но это не точно, поэтому и откладываю на потом). А так-же избавит от необходимости таскать в дефолтном конструкторе Initializer. И в дополнение, они позволят нам избавится от такого рудимента, как DefaultObject (он используется для проверки Флагов в хранилище объектов).
Традиционно подвожу итоги года и даю себе месяц на отдохнуть; примерно распланировать 2026 год. Правда в этот раз итоги получаются не за год, а за год с хвостиком, но не суть.
Разработана архитектура и модель памяти движка.
Создана фабрика всех движковых объектов, Сборщик мусора, отвечающий за автоматическое удаление и освобождение памяти от ненужных сущностей. И центральное хранилище объектов. Продуманы системы подгрузки подсистем, встроенных модулей и взаимодействие с проектами высокого уровня (читай играми).
Создана скрипт подсистема на основе языка Lua и внедрена в виде подключаемой подсистемы.
Подробнее: Relict Engine: Скриптовая подсистема + DevLog 20250405
Разработана утилита для импорта внешних форматов в формат движка
Разработан формат хранения статичной геометрической сетки (статичный меш)
Подробнее: Relict Engine: Формат Статичного меша
Разработана система работы с асинхронными задачами
Разработана структура сцен
Подробнее: Relict Engine: Мир и DevLog 20250928
Разработана система вывода графики и работа с ней
Подробнее: Relict Engine: DevLog 20251120
Иными словами за этот год я смог сделать некий полнофункциональный скелет. И теперь, на этот скелет следует наращивать мяско.
Начало 2026 года я планирую посвятить работе над ошибками. Например, очень хочется организовать очередь создания объектов, дабы была возможность управлять порядком их создания (сейчас некоторые объекты, например RenderObject, создают свои дефолтные экземпляры вне main рутины, а ДО нее, что не есть очень хорошо, и может привести к проблемам в какой-то момент).
Так-же будет нужно сделать шейдерный pbr и доделать для них внятную систему материалов; добавить ассет текстур; добавить различные юниты для работы со светом, системами частиц, итд. Поэтому, остальной 2026 год будет посвящен работе "в ширь". Успею ли сделать что-то еще зависит от множества неподконтрольных мне факторов, поэтому загадывать по максимуму не буду.
Еще хочу напомнить, что у движка есть дорожная карта, ознакомится с которой можно вот тут: https://yougile.com/board/8o3quozyj1in , и где видно сколько было сделано. И сколько еще предстоит сделать.
И на этом год 2025 считаю закрытым.
И в заключении, от себя и от лица команды Delta-Proxima Team хотим заранее поздравить пользователей Пикабу, и отдельно Лигу разработчиков Видеоигр с новым, 2026м годом. Желаем, чтобы ваши проекты покоряли вершины чартов, а каждый новый релиз становился событием в мире игровой индустрии.
Пусть код пишется легко, баги находятся быстро, а вдохновение никогда не покидает вас!
А на кухне никогда не заканчиваются кофе и печеньки ;)
С уважением и наилучшими пожеланиями,
Delta-Proxima Team