⚙️Log #18

Прошлый пост был больше эмоциональным, а в этом — конкретика по новому архитектурному плану. Покопался в идеях, переосмыслил подходы и пришёл к более трезвым и реализуемым решениям.

🟢 Нативное ядро: C# и .NET 8.0 LTS. Это основная сила движка для десктопа. .NET 8 предоставляет отличную производительность и современные возможности. Логика будет разбита на модули в виде отдельных DLL-библиотек. Сам движок соберётся в одну динамическую библиотеку.

🟢 В нативной части рендеринг будет на OpenGL. Это проверенная технология с хорошим балансом сложности и возможностей. В далёкой перспективе — переход на Vulkan для более тонкого контроля и производительности. Для веб-версии, естественно, будет задействован WebGL|GPU.

🟢 Фокус сейчас на Windows. Как только нативное ядро станет стабильным, займусь вебом через WebAssembly (WASM) и того же WebGL.

🟢 От идеи с собственным скриптовым языком ManuScript я отказался. Не вижу смысла тратить силы на создание и поддержку того, что уже прекрасно реализовано другими. Это дикая дистилляция велосипеда.
- Основной язык логики — C#.
- Для гибкости будем подключать скриптовые языки, вроде Lua или JavaScript. Идеально для контента, модов или быстрого прототипирования.
- DSL остаются для конкретных задач, например, для описания UI, сделаю что-то похожее на XML для структуры и подобие CSS для стилей.
- Будет еще визуальный язык, что-то похожее на блюпринты в UE. (это не в приоритете и скорее всего будет являться инструментом для систем, где важна четкая визуальная связь)

Итого план стал более зрелым и сфокусированным. Вместо распыления на два ядра и свой язык — концентрация на сильном нативном ядре на C# с продуманной модульной архитектурой.

⚙️Log #19

В данный момент занимаюсь модулем рендеринга. Пробую описать какой-то пайплайн...

🟢 Пока что пришел к такой системе: Render Pipeline -> Render Phase -> Render Phase Layer -> IRenderable

Для теста завел объект спрайта и попытался его отрендерить в этойм пайплайне.

🟢 Моя первичная задача:
Реализовать модуль рендеринга до какого-то рабочего состояния.
- Чтобы можно было например отрендерить N спрайтов с уникальными трансформами
- Чтобы все это было за N батчей (система батчинга)
- Чтобы N спрайтов использовали N текстур
- Чтобы были динамические спрайты, которые могут менять свои параметры в процессе. (для анимаций)

🟡 После этого рендеринг можно будет оставить на какое-то время и заняться системой UI. Начну писать каркас на основе XML + CSS.

⚙️Log #20

Я давно знал о существовании RenderDoc - наблюдал за его использованием на стримах других разработчиков, но тогда он казался мне чем-то сложным и непонятным. До недавнего времени я откладывал глубокое погружение, но сейчас решился - и был приятно удивлен!

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

Я разрабатываю движок и систему рендеринга на .NET 8. При обычном запуске или дебаге все работало идеально, но при попытке захватить процесс через RenderDoc приложение молча падало на старте. Ни ошибок, ни логов - просто краш.

Перелопатил пол-интернета в поисках решения. Находил похожие проблемы, но их фиксы не подходили под мой случай. Начал даже думать, что .NET принципиально несовместим с RenderDoc.

Тут началось детективное расследование.

В отчаянии я решил проверить другие .NET движки - Stride и Prowl. К моему удивлению, их рантайм прекрасно работал с RenderDoc! Это окончательно сбило меня с толку - почему у них работает, а у меня нет?

Погрузившись в документацию OpenTK (обертка над OpenGL), я нашел ключ - нужно было включить дебаг-режим для OpenGL. И вот тут проявилась настоящая причина проблемы!

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

Самое интересное: в обычном режиме эта ошибка молча игнорировалась, но RenderDoc сразу ее детектил и жестко падал - без каких-либо подсказок о причине.

🟡 Теперь планирую глубже изучить RenderDoc - буду читать документацию и экспериментировать с различными фичами инструмента.

⚙️Log #21

Изучаю потихоньку OpenGL, вникаю в системы рендеринга.

Вот основной список документаций, которые штудирую:
1. OpenTK Learn
2. OpenGL Core
3. OpenGL GLSLang Spec

🟢 Ещё глубже разобрался, как работают атрибуты и юниформы. Всё оказалось гораздо проще, чем я себе представлял. Если условно, то атрибут используется для каждой вершины в вершинном шейдере, а юниформа — глобально для всех шейдеров. Очень удобно их применять на разных этапах рендеринга. Например, атрибут может спокойно принимать целый буфер разных данных в одном массиве. Потом мы просто для атрибута конкретной вершины определяем смещение в байтах и настраиваем офсет. Таким образом, массив становится своеобразной инструкцией для всех вершин. Атрибут можно использовать, например, для настройки градиента для спрайта, указания позиций вершин, нормалей для освещения или тех же UV-координат для наложения текстур.

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

🟢 Помимо этого, ещё почитал документацию о VBO — это вершинный буфер, который, собственно, принимает в себя данные для загрузки на GPU. Потом углубился в VAO — это некоторая настройка для атрибутов, через которую можно задавать правила чтения этого буфера. Важный момент: я понял, что привязка VAO происходит к текущему привязанному VBO. Это важно учитывать. Если VBO не был привязан или привязался другой, то VAO будет привязан к последнему или выбросит ошибку, потому что нет буфера, с которым он работает.

🟢 Потом познакомился с оптимизацией для работы с вершинами. Условно, мы можем для отрисовки спрайта использовать 6 вершин, что не очень эффективно, потому что в двух местах будет дубликат вершин из-за наложения двух треугольников. Либо же мы можем использовать только 4 вершины, что будет правильнее, и переиспользовать для создания треугольника уже известную вершину. Для этого нам поможет EBO — это буфер элементов, в который мы передаём индексы вершин, загруженные в VBO и определённые при помощи VAO. Здесь, кстати, тоже есть важный момент: EBO нужно привязывать к привязанной VAO, потому что он работает с ней, так как ему нужно понимать индексы вершин.

🟢 Ну и по мелочи: ещё поигрался с настройками OpenGL, например, с включением смешивания.

🟡 Дальше планирую по-прежнему работать над рендерингом. Нужно разобраться более подробно с фундаментом.

⚙️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. Пока что всё работает отлично: процесс удобен и не требует дополнительных манипуляций с файлами проекта.