⚙️Log #22

Начал писать парсер под wavefront формат (.obj) и мне райдер предложил поставить расширение.

Неожиданное и приятно был удивлен, что меш можно осматривать прям в IDE, еще и подсвечивает данные + можно поиграться с разными настройками.

⚙️Log #23

Давно не ощущал такой свободы в разработке...

За последние два года устал заниматься Unity-like мобильной дрочильней. Единственной отдушиной был веб-стек, который пришлось осваивать из-за очередного бума HTML5-игр. Но и там всё переросло в рутину, потому что задачи в той или иной степени повторяются.

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

Вот оно, запах инди! Многое здесь создается только потому, что «Хочу!»

⚙️Log #24

Сезон страданий открылся...

Вчера потратил больше 6 часов на поиск решения проблемы. Изначально я написал логику втупую для работы с буферами, потом решил сделать для них обёртки, чтобы было удобно с этим работать и не писать кучу одинакового низкоуровневого кода.

Всё шло прекрасно до одного нюанса. Приложение начало крашиться, когда я делал два раза подряд привязку одного и того же буфера или вершинного массива. Раньше можно было привязывать сколько угодно раз, а теперь — нет. В рендере начиналась дичь в момент привязки указателей на данные атрибутов. Я хотел сделать лаяут, который автоматически сдвигал бы offset и определял stride для вершинных атрибутов.

По идее всё должно было работать чётко, но приложение падало с access violation. Решения на форумах я не нашёл, а официальная документация утверждала, что привязку можно делать сколько угодно раз. Так в чём же была проблема?

Оказалось, что я создавал буферы в автоматическом свойстве через лямбду:

public int Id => GL.GenBuffer();

Из-за того, что GL.GenBuffer() — unsafe-метод, при каждом обращении к свойству генерировался новый буфер, а старый терялся, создавая утечку памяти. Решение было простым — вынести создание в конструктор:

public int Id { get; private set; }

public ArrayBuffer()
{
    Id = GL.GenBuffer();
}

Теперь буфер создаётся только один раз и больше не вызывает падений при повторных привязках.

P.S. Дипсик и GPT-чат вообще не справляются с низкоуровневой разработкой. Да, они знают многое, и полезно с ними сверяться по каким-то нюансам, но они очень жестко теряются и постоянно выдают невалидную информацию. Она иногда даже не сходится с официальной документацией. А такие нюансы, как порядок привязки буферов — вообще жопа для них. Да, они в курсе, что должен быть какой-то порядок, но какой именно — им пофиг. В каждом ответе всегда рандомный порядок и бессмысленные биндинги и т.д.

⚙️Log #25

🟢 Начал разработку системы проектов для движка. Её основой станет лаунчер, в котором будет отображаться список всех проектов пользователя, их настройки и другие параметры.

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

🟢 Решил реализовать эту систему на раннем этапе, чтобы заложить основу для её дальнейшего развития.

На текущий момент наметил принцип работы:
- Для каждого проекта автоматически генерируется решение (.sln) под .NET 8.0, а также его первый проект (.csproj).
- Параметры сборки для всех проектов определяются на уровне решения. В нём прописаны ссылки на собранные DLL-библиотеки движка.
- Пока что путь к этим DLL читается из переменных окружения компьютера. В будущем этот механизм может быть изменён — возможно, путь будет генерироваться динамически при запуске редактора. Решение через переменные окружения было выбрано как наиболее стандартное на первом этапе.

🟢 Движок можно будет установить прямо из лаунчера. Он загрузится в виде архива, распакуется в указанную пользователем папку и начнется процесс установки, после чего путь к нему будет автоматически добавлен в переменные окружения системы. Это позволит использовать движок как в процессе сборки проектов, так и напрямую из терминала.

🟢 Каждый проект будет содержать главный файл .project с информацией о нём: название, описание и т.д.

Также в этом файле указывается тип проекта:
- Игра — конечный продукт, разрабатываемый на движке. Собирается в исполняемый .exe-файл вместе с контентом. Может иметь зависимости в виде библиотек и пакетов.
- Библиотека — проект, состоящий в основном из кода, без контента. Представляет собой обычные .dll-файлы, которые могут использоваться в играх или других пакетах. Библиотеки могут быть одиночными или представлять собой группу взаимозависимых проектов.
- Пакет — reusable-компонент, который можно легко переиспользовать в разных проектах. Это аналог Packages в Unity, но адаптированный под нужды данного движка. Пакет может содержать как код, так и контент. Он может зависеть от других проектов, но только от библиотек или других пакетов.

🟡 В качестве теста я начал делать в этой системе игру Flappy Bird. Пока что всё работает отлично: процесс удобен и не требует дополнительных манипуляций с файлами проекта.