Но зато есть и вторая сторона медали: Теперь редактор ну прям очень сочно работает!

Вместо 1000 акторов-кубиков, в каждом из которых по 6 сторон-компонентов, у меня чисто один актор и куча компонентов внутри

А также раньше в SEv2 (Standard Editor v2) ветвь данных и визуализации была разделена, и знали бы сколько я настрадался, пока пытался синхронизировать эти 2 ветки......

Но благо в SEv3 (Standard Editor v3) исправился, и теперь ветвь данных лишь ссылается на визуализацию, а визуализация, в свою очередь, не имеет той самостоятельности, что было в прошлой версии архитектуры редактора карт

Так и живем :)

nah UHT-парсер такой старый что даже не понимает современные фичи C++ 🥀

Интересный факт

В редакторе карт для каждого элемента дается свой собственный уникальный ID (GUID - Globally Unique Identifier - Глобальный Уникальный Идентификатор) используемый для наименования элементов, дальнейшей работы с проводами, логикой и тд.

И если вы будете спавнить по одному элементу, то счетчик ID просто будет увеличиваться на один

И чтобы сломать редактор карт, достаточно заспавнить 2^64 элементов - тогда произойдет переполнение счетчика и начнется отсчет от нуля

Так что у вас есть уникальная возможность заспавнить 18 446 744 073 709 551 616 элементов, а затем написать в баг репорт что редактор карт сломался :)

Ого, Ютуб нашел мне 2 похожих видео, спасибо, посмотрю обязательно

Если так подумать - то мы безумцы, пройдя всю шахматную доску менее чем за 50 лет

Есть такая легенда, что изобретатель, когда создал шахматы, попросил у правителя в награду всего лишь одно зерно, но с условием - на первую клетку доски положить 1 зернышко, на вторую - 2, на третью - 4, и так далее, удваивая количество на каждой следующей клетке

То есть на каждой клетке будет 2^(номер клетки) зерен. И на 64-й клетке число зерен стало бы таким огромным (~18 квинтиллионов), что их не хватило бы со всей планеты Земля

Теперь вспомним процессоры, их битность означает сколько адресов (байт) они могу оцифровать, то есть, 2^(битность процессора) байт

А затем представим мысленно игру: У вас есть пешка, вы начинаете с первой клетке, и идете по далее по одной. Что получится? Представьте только...

1-я клетка (1 бит) - 2 байта - 1945-1956 - первые компьютеры, лаборатории, транзисторы с размером кулака, 30-тонные машинные комнаты

4-я клетка (4 бит) - 16 байт - 1971 - Intel выпускает свой первый процессор Intel 4004 для японских калькуляторов с техпроцессом в 10.000 нм. Начинают зарождаться UNIX и язык C

8-я клетка (8 бит) - 256 байт - 1972-1985 - Intel 8008, зарождение 8-битного детства: 8-битная музыка, 8-битная графика. Приставки: Atari 2600, NES, Dendy. Появление Марио, Пакмана

16-я клетка (16 бит) - 65.536 байт (64 Кб) - 1985-1993 - Intel 8086 (Архитектура х86 которого сохранилась до сих пор!), зарождение MS-DOS и Windows 1.0, Кармак создает алгоритм Raycasting и такие легенды, как Wolfenstein 3D и DOOM. Игры становятся плавнее, красочнее, амбициознее, появляются персональные компьютеры от Apple. Именно на 16-й клетке Алексей Пажитнов напишет свой Тетрис. А Билл Гейтс скажет что "16 бит - хватит всем, это предел" как же он ошибался...

32-я клетка (32 бита) - ~4.2 млрд байт (4 ГБ) - 1990-2005 - Intel выпускает свой Intel 80386, а затем и "пеньки" Pentium, и чего только не было... Windows 95/98, Quake, Unreal Engine, Half-Life. Начало эпохи Sony PlayStation (1-2). Настоящие 16.7 млн цветов (True Color). Борьба AMD и Intel в гонке частот за 1 ГГц в 2000. Краем глаза зарождение первых вокалоидов в 2004, а также Flash-игры, браузеры, Skype, настоящее 3D

И... Один шаг

64-я клетка (64 бит) - ~18 квинтиллионов байт (~16 эксабайт) - 2003-наше время - Процессоры 32-бита уперлись в невозможности адресации больше 4 ГБ, и тогда AMD взяли все в свои руки и просто увеличили архитектуру 32 бита вдвое, создав свою архитектуру AMD64. И что же она породила? Да оглянитесь вокруг - любые компьютеры, телефоны, планшеты - все это результат 64-бит. Высочайшее качество 4К, 120 кадров в секунду и даже Искуственный Интеллект. Компьютеры научились думать, петь, размышлять, говорить, слушать, отвечать, генерировать изображения, аудио, видео...

И... Куда дальше? А все, мы прошли всю доску... В шахматной доске ровно 64 клетки, и мы стоим на последней

И теперь оглянитесь назад:
- Между первыми 30-тонными лабораторными компьютерами на 2 байта в 1945 и 64-битниками на ~16 эксабайт в 2003 прошло 58 лет (менее чем жизнь человека)
- А между создателем Алгебры Логики (без чего бы у нас не было компьютеров) Джоджом Булем (да-да, bool) в 1854 и первым компьютером в 1945 прошло 91 год, то есть...

Его алгебра логики пылилась на полках математики более чем 100 лет, а затем в один момент мы за половину того времени сделали больше, чем за последние несколько тысяч лет

Так что теперь когда слышите задачу про "зерна на шахматной доске" - задумайтесь... Может, держа свой телефон в руках, 64-я клетка не такая уж и далекая?

Умные мысли преследовали его

Но он оказался "Just UE5 & C++ Coder without personal life :D"

Clang + AST Analysis = Reflection + Code Generation

Читаю Джейсона Грегори, решил по книжке попробовать реализовать аллокаторы

Аллокатор - своеобразный диспетчер памяти. Вместо того чтобы каждый раз просить память у Windows (что ужасно смертельно долго, поверьте), движок берет 1 большой кусок памяти при запуске и отдает ее аллокатору

А тот уже просто нарезает память на кусочки и помечает у себя в таблице: "этот кусочек занят, этот свободен" и раздает их моментально (и да, аллокатор буквально переводится как распределитель)

== TPoolAllocator ==
Принимает размер ячейки/пула (BlockSize в байтах) и хранит в себе арену (64 таких ячеек) (размер которых равен BlockSize * 64 байт)

А также служебную маску (FreeBlocksMask), в которой каждый бит - является состояние "свободная ли ячейка?" (можно сказать карта города - какие ячейки заняты, а какие свободны и можно ли их занять)

== TBinnedAllocator ==
А этот аллокатор уже является "менеджером" пуловых аллокаторов. Название произошло от английского (англицизм, ага) Bin - корзина.

Его главная задача - получить запрос на аллокацию, например, 12 байт. Сгладить 12 байт до ближайшего большего (например, к 16 байт), а затем вызвать 16-байтовый аллокатор (попросить аллокацию и тд.)

Можно сказать это если бы мы сидели у нескольких мусорных ведер разного размера, нам давали какой-нибудь предмет, а мы по его размеру сортировали и кидали в маленькое, среднее или большое мусорное ведро

Конечно об этом аллокаторе Джейсон Грегори не писал подробно, но я узнал о нем периодами изучая исходный код Unreal Engine - у него есть прекрасные исторические примеры таких аллокаторов, как FMallocBinned (UE3, старый), FMallocBinned2 (UE4.12+, многопоточность) и FMallocBinned3 (UE5, 64-бит)

И да, это все работает просто замечательно

Могу смело запрашивать блоки даже "не красивого" размера, TBinnedAllocator округляет их, находит нужный мне аллоктор и дергает его

Одним словом - не зря нахваливают Джейсона Грегори и его книгу "Игровой Движок" (все таки движок - это лишь 90% Архитектуры и 10% Реализации)

Root Engine - Удобство, Смерть и Рендер
Ох, как же я не хотел поднимать эту тему... но время пришло

На чем писать графику в Root Engine?

- OpenGL - Быстрый, удобный, но стар как этот мир (1992)
- Vulkan - Долго, муторно, но производительно
- DirectX - Интеграция с экосистемой Windows, но внутри симметрично отражает Vulkan

Я бы мог сейчас начать поливать типа "OpenGL - херня. Vulkan - топ", но не стану. Это не столь важно. Лучше гляньте историю шире и глубже:

- Minecraft - пожалуй единственная игра ради которой OpenGL имел хоть какой-то смысл. Но! Относительно недавно Mojang объявили, что начнут переписывать рендер-движок Java-версии на Vulkan! (а еще я напомню: Mojang принадлежит Microsoft, а у Microsoft есть DirectX)
- OpenGL 4.6 - последняя версия, выпущенная в 2017, после которой до сих пор нет даже планов развитии данного API
- Самый явный признак смерти API: Драйвера Mesa Zink позволяет запускать OpenGL поверх Vulkan
- А также Google (Android) планируют драйвер ANGLE сделать по умолчанию. Что это значит? Что в будущем Android-устройства будут поддерживать только Vulkan, а OpenGL ES будет работать лишь как слой абстракции поверх Vulkan
- Также Apple начали вставлять свои палки в колеса, формально пометив OpenGL устаревшим (и вырезав его), но по факту - Unity и Unreal Engine уже вырезают OpenGL RHI для билда под macOS и iOS, оставляя только Vulkan и Metal
- И банально: любые новые технологии, такие как Ray Tracing или Mesh Shaders - исключительно Vulkan и DirectX 12

То есть чувствуете это? Все когда-нибудь зарождается и умирает - принцип RAII работает всегда и везде. И OpenGL - не исключение, а мы с вами - свидетели эпохи, когда впервые 34-летний API начал... умирать

Хорошо, мы похоронили OpenGL, и у нас остаются 5 игроков: Vulkan, DirectX, Metal, bfgx и WebGPU

Metal
- Очень быстр, код призван быть "приятнее Vulkan", но очевидно теряем большую долю рынка - движок и игры будут только на технике Apple (которой, к слову, у меня нет :D)

WebGPU
- Совсем новый, взяв лучшие идеи из Vulkan, DirectX и Metal, переосмысливая их (как Rust в экосистеме C/C++)
- Проверка на лету, нельзя обрушить драйвер "случайно"
- Но вместе с эти накладные расходы на проверки и валидацию

bfgx
- Швейцарский нож от всего и для всего
- Быстрое проектирование, за вечер рендер, за неделю Анрюша на коленках
- Но это черный ящик, по сути - повторяя судьбу OpenGL - быстро строишь, но если нужен контроль - ничего не сделаешь
- Хорошо для начала, но в будущем - нож самому себе

И вот тут остаются 2 близняшки: DirectX и Vulkan - Внутри они очень сильно повторяют друг-друга, можно сказать зеркально (и да, они оба убийственно сложные)

DirectX
- Лучшая поддержка, много инструментов для отладки
- Быстрее внедряются новые технологии
- ОЧЕНЬ хорошая интеграция с Windows
- Но вместе с этим - золотая клетка, ведь выйти из экосистемы Microsoft практически невозможно
- Движок останется навсегда только для Windows и Xbox пользователей
- А про Android, Steam Deck, Linux и PlayStation можно забыть

Vulkan
- Настоящий, открытый и доступный API для всего что умеет рисовать пиксели на экране
- Windows, Linux, Android, Xbox, Steam Deck, PlayStation, macOS, iOS - весь рынок будет доступен
- Vulkan, в какой-то степени, язык C в мире GPU - абсолютный контроль, который оплачивается высоким понимаем как работает GPU, а не простым оперированием абстракциями
- Но и вместе с этим - можно выжимать максимальную производительность

И в выборе между Vulkan и DirectX ответ пришел откуда не ждали: Помните я упомянул что: Mojang - дочерняя компания Microsoft, а Microsoft имеет DirectX?

Думаете почему Mojang не заставили переписать Minecraft на DirectX? Рынок... Microsoft сами прекрасно знают про свою золотую клетку. И понимают, что их DirectX - красив, но теряет большую долю рынка (оставляя только Windows и Xbox)

Поэтому Vulkan - остается единственным, сложным, но универсальным API ко всему, что можно классифицировать как "видеокарта"