TehnoMagEG

TehnoMagEG

Soon™
Пикабушник
Дата рождения: 3 июля
7901 рейтинг 28 подписчиков 7 подписок 67 постов 3 в горячем
Награды:
10 лет на Пикабу
7

Relict Engine: DevLog 20260411

Серия Relict Engine

Краткий список изменений

  • 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 формат и добавить недостающий функционал, типа ввода/вывода юниформов) хочу немного причесать код, да избавится от ряда костылей, которые появились пока я пробовал разные подходы к форматированию.

Показать полностью

Ответ на пост «Пользователи предположили, что РКН заблокировал доступ к обновлениям Linux в РФ»4

P.S. Вот после этой новости мои прошлые посты с тезисом, что РКН под прикрытием блокировок занимается прямой диверсионной деятельностью в отношении критической ИТ-инфраструктуры и сотрудников ИТ-сферы России уже не кажутся прям таким бредом? Сколько тут было комментаторов "вы всё врёте"?


Хоспаде, как вы заебали уже с этим. Там не роботы работают, а люди. Косячат, да. Ну а хули. Не косячит лишь тот, кто нехуя не делает. Далее. Вот вы панику разводите. А по факту те, кто с этими ресурсами работает, и у кого они внезапно заблокировались, уже давно списались с техподдержкой, которая занимается обслуживанием ТСПУ, и уже все пофикшено (если сей факт вообще имел место быть, и это не связано с косяками провайдеров, или утренним сбоем на IX, который имел место быть).

Я вам даже больше скажу. Любой человек может пожаловаться своему оператору на заблокированный ресурс, и оператор будет обязан связаться с той-же поддержкой ТСПУ. И в 90% случаев (ну кроме понятных youtube, tg, discord итд, т.е. те о которых они публично говорили) все разбанивается (правда тут есть минус - разбанивается на конкретном ТСПУ, через который трафик обратившегося ходит).

И добавлю: Большинство проблем сейчас связаны лишь с тем, что особо одаренные товарищи, заместо того, чтобы обратится по адресу со своей проблемой пытаются хитрожопить особо выебанными способами, что лишь увеличивает вероятность т.н. "блокировок за компанию" и в последствии увеличивает же время реакции на косяки. Так что по большему счету (но подчеркну отдельно, что не всегда), вы сами себе же злобные буратины.

И второе: если вы нашли метод обхода, то блять, не трубите об этом в пабликах. Не будьте дегенератами. Помните, что паблики мониторят СМИ. А Сми уже Минцифры, которые оперативно спускают в РКН приказ банить эту новую хуйню (и далее см. пункт 1).

Все, можете минусить.

Показать полностью
10

Relict Engine: DevLog 20260206

Серия Relict Engine

Краткий список изменений

  • Добавлены Log Facility в первом приближении

  • Атом Configable частично переделал на Property

  • Мелкие исправления

Комментарий

Просто маленький пост на финишной прямой миграции ядра на новую кодобазу. Ранее я уже игрался с классом свойством, но хотел отложить работу с ними до лучших времен, когда вернусь к доделкам скриптовой подсистемы. Однако посидев, подумав и покурив уже готовый код пришел к мнению, что частично класс-свойство можно ввести уже сейчас и использовать как обертку для сериализованных конфиг переменных. Попробовал. Понравилось.

Для сравнения было/стало

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

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

а вот так-вот стало.

а вот так-вот стало.

Как видно, конфиг и секция теперь задаются в инит. структуре, однако непосредственно процесс загрузки переменной теперь спрятан под капот в объект Property. В коде Property ведет себя как обычная типовая переменная указанного типа. В данном случае int32_t. Значение 42, указанное в конструкторе является значением по умолчанию. Т.е. если в конфиге переменная не указана, то TestProperty инициализируется со значением 42, если указано, то оно инициализируется уже со значением из конфига. Текстовое представление Property может быть каким-угодно, т.к. рефлексии в c++ нету (ну вернее уже есть в стандарте C++26, но лучше его пока не трогать).

Смысл его пока только в загрузке данных из конфига (и сохранение в user конфиг), но в дальнейшем потихоньку расширю этот функционал.

Показать полностью 3
7

Relict Engine: DevLog 20260203

Серия Relict Engine

Краткий список изменений

  • Добавлен логгер из "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 переменных), что автоматом исправило проблему, которая вылезла несколько ранее с привязкой объекта рендер пайпа к юниту сцены (не находил нужный метакласс, так-как создавал новый при регистрации делегата создания из-за того, что был разный контекст вызова функции). Долго дебажил это дело, поэтому и лог сегодня такой маленький.

Показать полностью
7

Relict Engine: DevLog 20260119

Серия Relict Engine

Краткий список изменений:

  • Ядро переключено на новую кодобазу с метаклассами

  • Удалены сущности DefaultObject

  • Изменен принцип регистрации сущностей со статичных вызовов на делегаты

  • Заменен старый глобальный тикер на новый через метакласс

  • Добавлен функционал Subticks с заданным интервалом

    Функция тикера вызывается каждые N миллисекунд, где N заданное произвольное число

  • Куча мелких исправлений (и еще столько же предстоит исправить)

Комментарий:

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

Но это поправил, хоть и не совсем, как мне кажется, красиво и видимо все-таки нужно будет в следующем обновлении ядра (начало след. года, видимо) подумать про глобальную сущность, которая будет хранить все ранние делегаты, чтобы вызывать их не из глобальной части кода, а после того, как все шаблоны раскрылись и инициализировались во всех модулях. И дергать из функции инициализации уже.

UPD: inline Class _Class должен быть inline Class& _Class (заметил после публикации поста)

UPD: inline Class _Class должен быть inline Class& _Class (заметил после публикации поста)

После фикса все встало на свои места

После фикса все встало на свои места

Миграция все еще в процессе и займет довольно продолжительное кол-во времени. Благо в начале Февраля начинается отпуск. Там, думаю, дела пойдут веселее и в Марте переключусь уже непосредственно на графоний, чтобы не отставать от намеченного плана.

Показать полностью 3
8

Relict Engine: DevLog 20260108

Серия Relict Engine

Краткий список изменений

  • Добавлены структуры инциализаторы шаблонного класса RelictClass

    На данный момент просто как сущность. Функционал для них пока не готов.

  • Добавлен класс Relict::Class как хранилище инициализационных структур

  • Перенесена часть функционала, касающаяся регистрации/удаления объектов из ObjectStorage в Relict::Class

  • Упрощена работа Сборщика мусора путем перевода его на событийную модель

  • Добавлены заготовки на контейнеры сетевых/скриптовых полей Property

    Добавлены в качестве залипухи на будущее. В логике работы движка они ни коем образом не участвуют.

Комментарий

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

Касательно структур, решил сделать чуть иначе, чем в концепт-коде, приведенном в пред. посте: Relict Engine: Начало сезона 2026
Вместо некрасивого нагромождения различных скобок в шаблоне (который еще и очень не нравится IDE, несмотря на то, что стандарт допускает такое использование) вынес их отдельно. Теперь это выглядит вот так:

Не обращайте внимание на префикс Nv. Это нужно для совместимости со старым кодом. Во время переключения вернется старый добрый TRelictClass

Не обращайте внимание на префикс Nv. Это нужно для совместимости со старым кодом. Во время переключения вернется старый добрый TRelictClass

Показать полностью 1
13

Relict Engine: Начало сезона 2026

Серия Relict Engine

Потихоньку выхожу из майонезной комы и начинаю продолжать разработку.
Как и говорил в итогах, начало этого года будет посвящено работе над ошибками и некоторому рефакторингу кода ядра. Отказу от Атомной системы расширений и прочим мелочам.

Отказ от Атомов.

Как показала практика использования, система атомов не состоятельна. Нет, ее можно использовать на уровне проектов для внедрения дополнительного функционала, но не на уровне ядра. Поэтому она идет под нож. Заместо нее появятся конфигурационные структуры для шаблонов классов. Выглядеть они будут примерно так:

концепт код: <a href="https://pikabu.ru/story/relict_engine_nachalo_sezona_2026_13570983?u=https%3A%2F%2Fgodbolt.org%2Fz%2FEjnMYr153&t=https%3A%2F%2Fgodbolt.org%2Fz%2Fq1zPeMeE3&h=4c6de45e1a4af5a22e8239524a02c7adae7804da" title="https://godbolt.org/z/EjnMYr153" target="_blank" rel="nofollow noopener">https://godbolt.org/z/q1zPeMeE3</a>

концепт код: https://godbolt.org/z/q1zPeMeE3

Так-же, подобные структуры позволят нам реализовать ряд интересных вещей. Например, после реализации мета классов, они позволят нам связать создание одного объекта с другим объектом (Например класс RenderObject с SceneUnit) для более прозрачной работы конвейера.


Остальные улучшения

Вторым крупным улучшением (которое уже внедрено и работает), стало замена тикера Сборщика мусора на событийную модель. Это сильно повысило производительность, т.к. я избавился от цикла перебора всех созданных движком объектов. И, смотря на перспективу, возможно, сборщик мусора будет объеден с глобальным хранилищем объектов, ибо уже сейчас бессмысленно ее держать отдельно. Но это уже потом; узелок на память завязал.

Третьим улучшением, которое частично будет реализовано сейчас, а частично очень потом - это внедрение мета классов аналогов UClass в Unreal Engine, для хранения константных проинициализированных структур инициализаторов и мета методов для работы с Lua. Что позволит нам сильно упростить работу с скрипт подсистемой. Которая, возможно, перейдет из состояния подсистемы в ядро (но это не точно, поэтому и откладываю на потом). А так-же избавит от необходимости таскать в дефолтном конструкторе Initializer. И в дополнение, они позволят нам избавится от такого рудимента, как DefaultObject (он используется для проверки Флагов в хранилище объектов).

Показать полностью 1
14

Relict Engine: Итоги 2025

Серия Relict Engine

Традиционно подвожу итоги года и даю себе месяц на отдохнуть; примерно распланировать 2026 год. Правда в этот раз итоги получаются не за год, а за год с хвостиком, но не суть.

Что было сделано за этот год:

  • Разработана архитектура и модель памяти движка.
    Создана фабрика всех движковых объектов, Сборщик мусора, отвечающий за автоматическое удаление и освобождение памяти от ненужных сущностей. И центральное хранилище объектов. Продуманы системы подгрузки подсистем, встроенных модулей и взаимодействие с проектами высокого уровня (читай играми).

  • Создана скрипт подсистема на основе языка Lua и внедрена в виде подключаемой подсистемы.

    Подробнее: Relict Engine: Скриптовая подсистема + DevLog 20250405

  • Разработана утилита для импорта внешних форматов в формат движка

    Подробнее: Relict Engine: RatTools. Меши. Статичные Меши

  • Разработан формат хранения статичной геометрической сетки (статичный меш)

    Подробнее: Relict Engine: Формат Статичного меша

  • Разработана система работы с асинхронными задачами

    Подробнее: Relict Engine: ThreadManager и DevLog 20250822

  • Разработана структура сцен
    Подробнее: Relict Engine: Мир и DevLog 20250928

  • Разработана система вывода графики и работа с ней

    Подробнее: Relict Engine: DevLog 20251120

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


Что планируется на 2026

Начало 2026 года я планирую посвятить работе над ошибками. Например, очень хочется организовать очередь создания объектов, дабы была возможность управлять порядком их создания (сейчас некоторые объекты, например RenderObject, создают свои дефолтные экземпляры вне main рутины, а ДО нее, что не есть очень хорошо, и может привести к проблемам в какой-то момент).

Так-же будет нужно сделать шейдерный pbr и доделать для них внятную систему материалов; добавить ассет текстур; добавить различные юниты для работы со светом, системами частиц, итд. Поэтому, остальной 2026 год будет посвящен работе "в ширь". Успею ли сделать что-то еще зависит от множества неподконтрольных мне факторов, поэтому загадывать по максимуму не буду.

Еще хочу напомнить, что у движка есть дорожная карта, ознакомится с которой можно вот тут: https://yougile.com/board/8o3quozyj1in , и где видно сколько было сделано. И сколько еще предстоит сделать.


И на этом год 2025 считаю закрытым.

И в заключении, от себя и от лица команды Delta-Proxima Team хотим заранее поздравить пользователей Пикабу, и отдельно Лигу разработчиков Видеоигр с новым, 2026м годом. Желаем, чтобы ваши проекты покоряли вершины чартов, а каждый новый релиз становился событием в мире игровой индустрии.
Пусть код пишется легко, баги находятся быстро, а вдохновение никогда не покидает вас!
А на кухне никогда не заканчиваются кофе и печеньки ;)

С уважением и наилучшими пожеланиями,
Delta-Proxima Team

Показать полностью
Отличная работа, все прочитано!

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества