Light Source: Editor. Первый запуск игры.

Написание тестовых примеров под будущую плагин систему в LightSource: Editor.

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

Соскучились?

Немного о том, что было...

Примерно с Ноября 2020 года переезжали в недостроенный дом. Приходилось работать и днем, и вечером. А с Марта 2021 года закончили наконец-то внутреннюю отделку, кроме дверей... А из интернета имеется только очень слабый 4g интернет, который едва ловит.

Надеюсь летом удастся провести оптоволокно.


Продолжим: профайлер

Light Source: Editor. Label. [ссылка]
Light Source: Editor. Input. [ссылка]
Light Source: Editor. Основа. [ссылка]

Начал работу над Editor'om

Прочитать новость можно на моем патрон канале

Скелетная анимация: первый рабочий пример

Прочитать новость можно на моем патрон канале

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

Не хотел никак писать на C++ этот парсинг всего DOM дерева элементов и строговой привязки по id и sid, потому что это бы заняло целую вечность, но сегодня взял себя за... и решил начать. Как оказалось не так страшен черт как его малюют.

После написания хотя бы небольшого парсинга именно нужных элементов я продолжу тестировать и отлаживать скелетную анимацию, которая была написана ранее.

Задали вопрос по почте, решил ответить всем.

Opensource?

Я собираюсь делать полноценный кроссплатформенный игровой движок. Моими (одиночными) усилиями тягаться с такими мастодонтами, как Unity или Unreal Engine нет никакого смысла. Даже если брать функциональность того, что можно делать на таких крупных движках, то мне даже при всем желании никак их не догнать.

Тем не менее основными столпами игрового движка Light Source будет:
- кроссплатформенность
- макс. производительность

Хочется добавить возможность создания игр и под старые игровые платформы, такие как PS2, PSVita, GameCube и т.д., а так же под новые платформы Android, iOS, Nintendo Switch и др., при этом дав только самый минимум функциональности игрового движка.

Почему же он не открытый?

Как и любой проект, который держится лишь на энтузиазме, он постепенно заканчивается и проекты забрасывают, а основная причина такого - доход. Мы живем не в абстрактном мире, а в мире где нужно хотя бы питаться, а значит нужны деньги. Такие проекты как игровые движки высасывают уйму времени и сил. Чтобы создать полноценный игровой движок нужны годы усердного труда и при этом если не иметь никакого дохода, тогда смысл и ценность проекта тают на глазах.

Именно поэтому Light Source хоть и начинался, как opensource и раннее начало можно застать на github, тем не менее он сейчас закрыт! А все исходники и новые наработки хранятся исключительно у меня. Сделано это в первую очередь потому, что в будущем это будет коммерческий проект с системой монетизации продаешь игру на Light Source, будь добр поделится небольшим % от дохода. А чтобы выходить на такие уровни, а так же защитить свои интеллектуальные права на игровой движок опять же нужны деньги. Другими словами он все же будет свободно распространятся для некоммерческого использования, но только когда все интеллектуальные права сможем защитить.

Дорастёт ли проект до такого сказать трудно, ибо как уже сказано раньше это очень затратно и требует много усердного труда. Пока же иду именно в этом направлении...

На данный момент выбрано 2 платформы: Windows и PSP. Работаю над кроссплатформенной оболочкой, где уже есть отличные наработки. В будущем, если ядро кроссплатформы будет написано идеально, то можно будет отлаживать игры прямо на Windows с окном игры и консолью отладки, и просто перенести перекомпилировав сборку под PSP, и она будет работать точно так же.

Если кому интересно, то я снова, как и раньше, буду каждые выходные продолжать работу на Light-Source.

У меня была неделя отпуска где я начал работу с кроссплатформенности. Было решено разделить движок на 2 основных компонента:
- ядро, которое будет выступать в качестве кроссплатформенной обертки между всеми поддерживаемыми в будущем платформами
- framework, рабочую структуру движка, в которой будет определено поведение и взаимодействие компонентов движка (выделение памяти, работа с сущностями и т.д.)

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

Видеопамять PSP в 2 МБ резервируется на 3 буфера:
- буфер отрисовки
- буфер дисплея
- буфер глубины
при этом остается 688 кбайт неиспользуемой видеопамяти. Поэтому на ровне с OpenGL будет создана общая обертка по работе с видеопамятью, где будет резервироваться память под конкретные элементы.

Если в OpenGL можно резервировать видеопамять под любые нужны, от буфера вершин, буфера индексов, текстурного буфера и т.д., то в ядре движка (и под PSP) будет сделано схожим образом, но в framework будет предложен заранее более оптимальная конфигурация работы.

Добавлено спустя 4 часа 41 минуту 30 секунд:

Успешно протестирована кроссплатформенная обертка по работе с видеопамятью.

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

Разница между win32, linux и PSP не так велика, как казалось бы. Достаточно прописать общую обертку под выделение оперативной памяти, выделение видео памяти, дисплея, рендера и звука, но помимо этого необходимо сущ. переработать структуру движка, что решит многие вопросы, которые возникали раньше.

Я начал с самого простого - оперативной памяти.

Идет серьезная работа по усовершенствованию слоев памяти и уже есть отличные успехи в этом направлении.

В ближайшем будущем будет тестироваться динамическое изменение/удаление игровых ресурсов из статичной памяти.

Благодаря более новому компилятору был написан один из важных примеров "идеальной передачи и универсальных ссылок". Основываясь на этом примере будет лучше прорабатываться распределение памяти за счет уменьшения случаев выделения памяти под временные объекты в констукторах классов.

Специально под свои нужны был обновлен компилятор на PSP у Windows с GCC 4.3.5 до GCC 8.2.0.

https://darksectordds.github.io/html/MinimalistPSPSDK/index.html

Написан один из важных примеров поддержки DXT1 сжатия текстур на уровне железа. Как оказалось PSP имеет эту поддержку, правда специфическую из-за чего нужно будет переводить ассеты текстур в бинарные файлы при создании "игры" через World Editor.

Ссылка на новость.

Добавлено спустя 4 часа 41 минуту 13 секунд:

Mipmap test

После создания примера поддержки DXT1 сжатия было грех не проверить текстурные уровни в самом *.dds файле.

World Editor: alpha build ver. 000001

Очень много времени ушло на то, чтобы выбрать GUI библиотеки для создания полноценного, простого графического интерфейса под light-source.

Qt показался слишком громоздким и имел ошибки при попытке использовать FileDialog на Windows 10. Но до этого нужно было его скачать, установить, собрать библиотеки и немного попользоваться, а это время...

wxWidgets - другой популярный кроссплатформенный GUI. С ним так же пришлось помучаться, но пока серьезных недостатков в нем я не вижу. Он довольно простой и весит не так много. Поэтому сейчас World Editor будет собираться именно на нем.

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

Соскучились по мне?

Работа не оставляет мне свободного времени, поэтому прогресс над light-source заметно притормозил.

Планируются следующие этапы разработки:

1. изменяю структуру light-source под кроссплатформенность (текущий этап разработки)
2. буду создавать простенький (стартовый) UI под World Editor, который и будет изменять\компоновать основные форматы, которыми и будет управлять ядро light-source
3. далее будет писаться парсинг с .collada формата именно в World Editor'e. Туда же перенесется чтение .obj и .png формата, т.к. скорее всего большая часть форматов будет изменятся под особый. Это нужно в первую очередь для того, чтобы обеспечить большую производительность. Например: будут промежуточные форматы, которые будут хранить скажем заранее рассчитанные смещения до необходимой структуры данных, чтобы не читать весь файл полностью
4. будет наконец-то определена структура моделей и возможность манипуляции данных через World Editor. Например: у конкретной модели "ученый" добавить к голове коллизию для определения взаимодействия, скажем выстрел в голову

Возможно от чего-то придется отказаться, скажем от intraFont, но это не беда, т.к старый способ карты шрифтов никто не отменял.

Наконец-то дописан первый пример скелетной анимации.

Ссылка на патреон.

Добавлено спустя 3 часа 38 минут 9 секунд:

Написан wireframe пример, который даст возможность визуально отлаживать проблемы с моделью и коллизией.

Были добавлены *.obj и .*png загрузчики.



PS: модель взята из GTA San Andreas

Внимание: ложная тревога!

Причиной такого быстрого падения FPS при таком маленьком количестве объектов на рендер была потому, что перед этим у меня в тестовом варианте стоял расчет вращения объекта и назначение матрице модели этого самого вращения, через sceGumRotateXYZ(&rot).

Перепроверил без "искусственного вращения" и получил след. результаты:

- 60 FPS при 250 объектах
- 30 FPS при 1200 объектах

Добрый день pspinfo. Сделал еще несколько тестов. Видимо все не так "радужно", как хотелось бы...

Из-за того, что это "воссозданный" SDK, а не нормальные "инструменты разработчика", то похоже в самом SDK заложена эта проблема...

Поэтому, чтобы получить приемлемые 27 FPS необходимо уложится в 100 вызовов отрисовки примитивов (sceGumDrawArray).



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



Тем не менее, не смотря на эту проблему, все это можно обойти, хотя она ставит серьезные ограничения...

Был проведен первый стресс тест. Как оказалось, чтобы выдавать 25-28 FPS количество отображаемых объектов в текущий момент должно быть в пределах 100. При 150 объектах FPS падает до 17.

Написано малая часть Entity Component System и тестовый пример по распределению памяти по компонентам системы из заранее выделенного общего блока.

Были продуктивные выходные.

Написал 4 тестовых примера:
- проверка template компилятора
- проверка Variadic templates компилятора
- выделение памяти с psp
- Allocator под Entity Component System

(изображение результата выделения памяти из "Линейного Allocator'а")

Совершенно недавно был заложен "первый камень" в будущий движок оптимизированный спец. под PSP платформу под названием Light-Source. Пока делаются только предварительные наброски, чтобы выделить основную структуру.

Планируется:
- выделение памяти по МАХ. в момент инициализации движка, а в дальнейшем распределение необходимой памяти по компонентам движка (сложно реализуемое)
- добавление скриптового языка под "игровые сценарии" вроде Lua или Pawn
- использование intraFont
- профилирование, чтобы отслеживать равномерную нагрузку между всеми аппаратными частями PSP
- выделение собственных 3D и промежуточных форматов, чтобы МАХ. не вычислять промежуточные значения матричных координат в пространстве и предельного использования VFPU
- дополнительный инструментарий World Editor, чтобы можно было импортировать всевозможные форматы 3D моделей и редактировать "игровой мир на лету"
- поддержка формата .collada, т.к. это открытый XML стандарт и используется практически всеми программами по 3D моделированию

Одновременно вместе с движком будет писаться демо версия игры, которая будет основана на Half-Life.

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