Атом Configable

Этот атом создан для быстрой подгрузки переменных из внешних конфигурационных ini файлов (или сохранения в него).
ini файлы расположены в двух местах. В директории Config корневой директории проекта и в Директории Save. В целом это работает примерно так-же, как и в UnrealEngine. Сначала смотрится значение в Default конфиге в Config директории, потом, если это разрешено настройкой, то смотрится override в Save.
Управляется так:

• Subsystem.Input - подсистема для работы с устройствами ввода

• Реликт Input.Raw - модуль для работы с клавиатурой и мышью (в том числе с высоким DPI)

• Реликт Input.Xinput - модуль для работы с Xinput (для поддержки контроллеров) [опциональный]

Вывод:

• Subsystem.Renderer - некий универсальный api для работы непосредственно с графикой

• Реликт Renderer.Window - модуль универсального api для работы с окнами

• Реликт Renderer.Window.WinAPI - модуль для работы с окнами Windows

• Реликт Renderer.Window.XWindow - модуль для работы с окнами Xorg

• Реликт Renderer.Window.Wayland - модуль для работы с окнами Wayland (замена Xorg) [и вот еще нужно почитать нужны ли они будут обе, или достаточно только одной, ибо с Wayland еще не работал никогда]

• Реликт Renderer.Null - модуль-затычка, на случай, если нам нужно только окно, но не рендер (ну и как прототип для GL и VK)

• Реликт Renderer.GL - для работы с OpenGL

• Реликт Renderer.VK - для работы с Vulkan

В случае, использования SDL/glfw, нам придется его зашивать намертво в модуль Engine, как прямую зависимость. Кода будет сильно меньше, но при этом мы несколько потеряем в гибкости (плюс SDL забирает на себя еще и работу со звуком, при этом F·Mod туда впиливается через непонятно кем написанный плагин, что не очень хорошо [хотя в принципе непонятно, на кой фиг это надо, т.к. F·Mod всегда был вещью в себе]).

В общем, пока думаю и читаю документации к api. А непосредственно работу начну, наверное, не раньше мая.

Пока, конечно, все сыровато, есть вещи которые я в дальнейшем еще пересмотрю, но в целом работает.

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

• Добавлен typedef TRelictClass на RelictClass

Теперь, вместо public RelictClass<Class, BaseClass, ClassFlags>::Type можно писать public TRelictClass<Class, BaseClass,ClassFlags> при оглашении игровых классов

• Классы подсистемы вынесены на уровень выше в пространство имен Subsystems

• Переработана работа SubsystemManager для удобства доступа к классу подсистемы

Теперь, для обращения к подсистеме нужно обращаться к менеджеру, а не к самому классу подсистемы: auto SS = SubsystemManager::Get<Subsystems::ScriptSubsystem>("ScriptSubsystem");

• Исправлена работа функции FindObject со стороны Lua

После изменения регистранта Lua на UserData функция не была переписана. Упс.

• Часть функций Виртуальной Машины Lua вынесены в глобальное пространство имен и больше не доступны для прямого вызова из вне.

• Отключены стандартные библиотеки Lua за ислючением необходимого минимума.

• Класс Application перенесен из модуля GameFramework в модуль Engine

Это было сделано, т.к. в бинарной сборке нарушался принцип наследования зависимостей.

• Добавлены правила CMake для цели install

Наследование является опциональной (!) возможностью для скриптовой сущности. Наследуемая сущность указывается вторым аргументом, и не обязательно должна быть верхней в дереве наследования (можно пропустить часть классов, если нам не нужны их методы в текущей сущности). Если наследование не нужно, то требуется указать NULL (не 0, не nullptr, а именно NULL).

В юните так-же нужно не забыть зарегистрировать скриптовую сущность с помощью макроса REGISTER_SCRIPTCLASS, чтобы подсистема отправила его в виртуальную машину Lua.

Каждая скриптовая сущность может иметь, или не иметь поля. Каждое поле является методом, который может получать из виртуальной машины аргументы и возвращать в нее результат. Поддерживаются следующие типы аргумента: bool, int64_t, double, std::string, Object* и его производные (при условии наличия у них скриптовой сущности)

Функция вызывается привычным способом. Никакой дополнительной семантики не требуется

Наследования со стороны Lua пока-что не предусмотрено (но будет добавлено в дальнейшем) [под наследованием в данном ключе имеется ввиду наследование от Object классов, чтобы движок знал об этих сущностях. Обычное табличное наследование Lua работает]

Каждая зарегистрированная сущность сохраняется в глобальной таблице Lua и доступна в любое время для создания нового объекта, или поиска созданного ранее (как со стороны скрипта, так и со стороны C++). Для создания нового объекта используется метод NewObject, в качестве аргументов следует указать запись из глобальной таблицы Lua, которая связана с нашим С++ классом, и если необходимо, владельца нового объекта (иначе при первом же тике Сборщик мусора этот объект удалит). Для поиска объекта следует использовать метод FindObject. В качестве первого аргумента следует указать запись из глобальной таблицы Lua, а вторым, имя искомого объекта. В случае, если такой объект действительно существует, то в скрипт вернется его экземпляр. В противном случае, вернется nil

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

• Переделан ScriptClass, для возможности наследования сущностей

• Добавлен пустой класс ScriptClass_NULL для обозначения отсутствия наследования

• Добавлен флаг Singleton (RootObject | NoInstantiate) для RelictClass шаблона

• Добавлена спецфункция SetNull, вызываемая для void методов.

Следующим большим этапом, которым я буду заниматься после небольшого перерыва - это оконная подсистема (SDL2 или SDL3), рендер (OpenGL 4.5), математика на базе библиотеки glm и фреймворк сцен.