Войти
ПроектыФорумУтилиты

Inanity Engine

Страницы: 1 2 Следующая »
#0
3:27, 7 фев. 2014

Название: Inanity
Что это: кроссплатформенный игровой 3D-движок на C++
Разработчик: я
Статус: в разработке
Исходный код: https://github.com/quyse/inanity (лицензия MIT)
Платформы: Windows, Linux, macOS, web (порт через Emscripten)
Графическое API: DirectX 11, OpenGL 3.2-4.3, WebGL
Поддержка скриптов: Lua, Javascript (V8), Javascript (NPAPI)
Устройства ввода: мышь, клава, геймпад (через Windows Raw Input на винде, SDL2 на остальных)
Растеризация текста: FreeType + Harfbuzz
Другие API/либы: физика bullet, сеть Boost.Asio, звук OpenAL + Ogg Vorbis

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

Документация (очень мало): https://github.com/quyse/inanity/wiki
Документация по сборке: https://github.com/quyse/inanity/wiki/Building

Игры
Несыть (Insatia) - перешла на использование Inanity как прослойки для платформозависимых апи, т.е. графики, загрузки ассетов, обработки управления от юзера, на Windows, Linux и macOS. Бесплатное демо Несыти на itch.io
Скрин:

+ Показать

Старая демка: F.A.R.S.H.
Делалось давно под конкурс треша и угара, но не успелось.
Исходники: https://github.com/quyse/farsh
Бинарник для Windows: https://github.com/quyse/farsh/releases/tag/v0.1 (разрешение 800x600, чтобы увеличить можно просто развернуть окно, нажав Win+Up)
F.A.R.S.H. портированный в веб с помощью Emscripten: http://quyse.net/farsh/farsh.html (после загрузки сразу нажимайте Fullscreen)
Скрин:

+ Показать

Что есть хорошего

Полная абстракция от графического API


DirectX 11 и OpenGL приведены в возможностях к общему знаменателю (с некоторым набором опционально поддерживаемых или эмулируемых фич), что позволяет писать игру, используя абстрактные классы, и вообще не думая о графическом API. Даже о языке шейдеров.
Шейдеры предполагается писать на C++. Суть в том, что программер пишет код, используя экземпляры специальных классов, обозначающие входные данные шейдера, временные переменные и т.п., причём код пишется достаточно естественно. Скажем, если нужно что-то вычислить в шейдере, то так и пишем на C++:
...
Value<vec3> toLight = normalize(uLightPosition - vPosition["xyz"]);
Value<vec3> resultColor = lerp(color1, color2, dot(normal, toLight));
Этот код в runtime не делает вычисления, а строит синтаксическое дерево, описывающее операции, которые должны быть сделаны над данными. Это дерево затем транслируется в код на HLSL или GLSL, в зависимости от текущего GAPI. Важно, что никаких внешних кодогенераторов не требуется, используется только валидный C++ (даже макросы не используются). Inspired by Boost.Spirit.
Конструирование шейдера таким образом позволяет легко реализовывать убершейдеры, используя по сути обыкновенный синтаксис, и не скатываясь в кодогенератор-говнокод, слепляющий шейдер из строчек (как в Torque3D). В идеале, шейдер становится "продолжением" управляющей программы на C++. Плюс к этому получаем типовую безопасность и дополнительные проверки на этапе компиляции. Кстати, данные в шейдер передаются, используя те же экземпляры классов, которые присутствуют в теле шейдера, т.е. действительно C++ как бы "передаёт данные" напрямую в шейдер.
Такая гибкость, в частности, позволяет собирать под винду бинарники, поддерживающие одновременно DX11 и OpenGL, которые при запуске выбирают, какое GAPI использовать. И конечно можно без проблем поддерживать одновременно винду и линукс. В перспективе возможна реализация забавных штук, таких как кросс-API отладчик графики, или передача графических команд через сеть.
Пример кода, работающего с графикой, из F.A.R.S.H. Demo.

Абстрактная привязка к скриптовым языкам


Позволяет проталкивать C++ API в скрипт почти без лишних действий, опять же обходясь только валидным шаблонным C++ (плюс несколько макросов) без каких-либо кодогенераторов. Кроме того, метаданные не зависят от скриптового языка (API, библиотеки), так что единожды описанные метаданные класса могут использоваться для добавления поддержки сразу нескольких скриптовых языков, а C++ код взаимодействия со скриптом может не заботиться о том, что там за язык.
В метаданных поддерживаются конструкторы, статические и нестатические методы классов. Ведётся учёт ссылок на отданные в скрипт объекты.
Пример кода:
+ Показать

"Сырая" работа из C++ со скриптовыми объектами также поддерживается через абстрактные классы.
Другие библиотеки для встраивания скриптов или содержат внешние компиляторы/кодогенераторы (SWIG), или ориентированы только на один язык, и не избавляют от особенностей его API (LuaPlus). Другое решение, использующее только C++, и поддерживающее более одного языка, мне неизвестно. Моё же решение позволяет добавлять новые языки довольно быстро и просто (минимально рабочая версия интеграции с Google V8 была сделана за два дня).

Что есть своеобразного

Что есть плохого

Последние пара пунктов делают движок не слишком дружелюбным для игростроителей. Я работаю над этим в проекте игрового редактора Inanity Oil.

Несмотря на указанные недостатки, я думаю, что проект может быть полезным программерам уже сейчас. Код движка простой и чистый (на мой замыленный взгляд, конечно, и исключая шаблонные извращения), утечки памяти фактически отсутствуют благодаря автоматическому менеджменту памяти, написано много полезного для взаимодействия со всякими API и либами.


#1
7:33, 7 фев. 2014

Интересно. Если будешь дальше работать, то он однозначно пригодится. Главное что не нужно делать - забивать и забрасывать движок.
Напиши про графические фичи.
Еще интерисует как организована сеть, много надо ли делать работы чтобы устроить сетевую игру?
Выложи скриншоты редактора.
Напиши еще про пост-эффекты.

#2
10:33, 7 фев. 2014

Прикольно. Порадовала работоспособность и производительность web-демки.
Автору респект :)

#3
11:03, 7 фев. 2014

ASD
а чем, если не секрет? вот посмотрел. она не работает нигде кроме хрома. и webgl до сих пор настолько медленный, что это для него круто?

#4
11:09, 7 фев. 2014

N1
> а чем, если не секрет? вот посмотрел. она не работает нигде кроме хрома. и
> webgl до сих пор настолько медленный, что это для него круто?

А у меня FireFox и никаких проблем ^^

#5
11:16, 7 фев. 2014

ASD
ща обновил, завелась. но 50 фпс это, конечно, сильно для кубиков с 1 простой vsm.

#6
11:39, 7 фев. 2014

Emscripten выполняет нативный код (точнее LLVM IR) на собственной JS машине? :) Какая жесть...

#7
13:16, 7 фев. 2014

cin
> Интересно. Если будешь дальше работать, то он однозначно пригодится. Главное
> что не нужно делать - забивать и забрасывать движок.
Спасибо :)

cin
> Напиши про графические фичи.
> Напиши еще про пост-эффекты.
Всё, что есть в движке - по сути, низкоуровневое. Пост-эффектов, материалов, даже анимированных моделек в движке нет, есть только шейдеры, вершинные буферы, текстуры и так далее. Всё что есть сверх этого в демке, реализовано в самой демке. В будущем перенесу это в движок, в каком-то более-менее универсальном виде.

В демке реализованы exponential shadow maps, quaternion-based skinning, normalmaps without precomputed tangents, HDR tone mapping, bloom, light adaptation. Материалы рисуются через убершейдеры, зависящие от количества источников света (с тенями и без), наличия/отсутствия текстур. Убершейдеры генерируются шейдерной системой, компилируются и кладутся в кэш шейдеров (в файле shaders рядом с экзешником). Повторяющиеся объекты рисуются через instancing.

cin
> Еще интерисует как организована сеть, много надо ли делать работы чтобы
> устроить сетевую игру?
Сети особо нет, есть только обёртка над Boost.Asio, чтобы привести его работу к "стилю" движка. Так что да, много :)
> Выложи скриншоты редактора.
К сожалению, пока нечего выкладывать, разве что окошко с парой вкладок и кнопок.

#8
13:34, 7 фев. 2014

N1
> ща обновил, завелась. но 50 фпс это, конечно, сильно для кубиков с 1 простой
> vsm.
На предыдущем файрфоксе не работало, да, из-за слабой поддержки расширений webgl (мне надоело реализовывать обходные пути). По той же причине не работает в IE 11.

Фпс часто непонятный, иногда на явно более мощной машине фпс ниже, чем на слабой. Что удалось понять - во-первых, хром ограничивает фпс, больше 60 кадров нигде получить не удалось. Во-вторых, фпс зависит от поддерживаемых расширений webgl, скажем, если возможен instancing, всё работает чуть быстрее, а если нет, то каждый кубик рисуется отдельным drawcall'ом. Но надо ещё выяснять.

Dr. Tirinox
> Emscripten выполняет нативный код (точнее LLVM IR) на собственной JS машине? :)
> Какая жесть...
Точнее, Emscripten компилирует LLVM IR в javascript.
И там в демке ещё есть интерпретатор Lua, скомпилированный в javascript, выполняющий на этапе инициализации Lua скрипт :)

#9
12:04, 8 фев. 2014

Может стоит использовать CMAKE для создания проектов? Изображение

#10
12:43, 8 фев. 2014

в лисе малевич, в хроме ок.

quyse
> да, из-за слабой поддержки расширений webgl (мне надоело реализовывать обходные
> пути). По той же причине не работает в IE 11.
ну ты сравнил. у IE 11 поддержка вебгл это вообще анекдот, у лисы всё намного лучше.

#11
13:21, 8 фев. 2014

В общем так и не осилил сборку. А если прям в таком виде запихнуть в Visual Studio, то будет каша. Надо переделавать всё под CMAKE.
Нужно делать систему сцены, и тогда уже узлы сцены свяжут модели с физикой всем остальным.

#12
13:30, 8 фев. 2014

cin
> Может стоит использовать CMAKE для создания проектов?
Да наверно стоит, уже думал об этом. Как найду время, попробую. Если честно, пока с CMake умею только готовые проекты собирать.

cin
> В общем так и не осилил сборку.
Печально. На винде вроде особых проблем не было. Может, смогу помочь в личке?

#13
14:09, 8 фев. 2014

Спасибо) Но лучше если освоишь CMAKE и переделаешь.
Сейчас главно тебе сделать так чтобы другим было легче вникнуть в твой движок и помочь тебе его развивать.

#14
16:27, 8 фев. 2014

Код хороший, но очень много мелких файлов. Колоссально затрудняет чтение кода.

Страницы: 1 2 Следующая »
ПроектыФорумУтилиты

Тема в архиве.