Войти
ПрограммированиеФорумОбщее

Кто хочет сделать Open Source движок для .net? (2 стр)

Страницы: 1 2 3 48 Следующая »
#15
19:50, 7 июня 2019

GLoom
Unity как раз написан на c++, и если из него убрать весь c#, то на внутреннюю кухню движка это никак не повлияет. Просто не будет возможности скриптовать. По крайней мере так было несколько лет назад, не знаю как сейчас, так как не слежу.

bgfx - поддерживает легаси апи, более современный аналог (Vulkan, DX12) это https://github.com/DiligentGraphics/DiligentEngine

#16
21:55, 7 июня 2019

Misanthrope
> дело тут в комьюнити так-то
А, я думал ты про то, что MS забили на поддержку xna

#17
23:21, 7 июня 2019

xruck
> Просто не будет возможности скриптовать.
юнити есть возможность официально писать на с/c++

#18
0:00, 8 июня 2019

xruck
> написан на c++, и если из него убрать весь c#
не выйдет

c тех пор как они написали burst compiler
подробности

#19
0:10, 8 июня 2019

xruck
Надо попробовать Diligent завести под .net. что то схожу не нашлось готовых решений.

А так выглядит как то что я хотел. В bgfx все плохо с многопоточных рендером, я правильно понимаю?

#20
(Правка: 1:52) 1:47, 8 июня 2019

GLoom
> Я сам не смогу писать много кода, но могу помогать советами, отсматривать код и
> заниматься общим планированием.
А для чего движок ? Может лучше игру делать ? Или там придется проценты делить )))

iperov
> не серьёзно тратить кучу времени компилируя несколько строк на UE4.
> C++ движки это уже динозавры.
сам ты динозавр, в анриле никто не мешает пару строчек блупринтом сделать

#21
(Правка: 2:13) 2:07, 8 июня 2019

GLoom
>Итак, наш движок будет состоять из следующих частей:
А как на счёт таких связок?
- ECS - https://github.com/Leopotam/ecs
- Рендер - https://github.com/mellinoe/veldrid
- C физикой согласен.
- По звуку. Выбора нет. Либо FMOD/Bass, либо OpenAL + https://github.com/ioctlLR/NVorbis (для ogg). Других вариантов не вижу.
- По редактору материалов сказать нечего. Тут надо в общем и целом сам World Editor планировать в первую очередь, как мне кажется.
- А скриптование зачем? C# не котируется за скриптовый язык? :) Допустим при таком структуре - Deps.dll (зависимости), Engine.dll (само двигло), GameLauncher.exe (инициализация двигла -> запуск игрули), GameImpl.dll (реализация сообстна игрули, без всяких скриптовых языков, вся логика/механика игры на шарпе), WorldEditor.exe (ну тут панятна) - шарп не зайдет?
- По glTF 2.0 норм (https://github.com/VPenades/SharpGLTF).

Ну и так для кучи:
- По шрифтам - https://github.com/rds1983/StbTrueTypeSharp
- По форматам изображений для текстур - TGA/DDS-DXT1/3/5 - https://github.com/nickbabcock/Pfim, либо https://github.com/KFreon/CSharpImageLibrary (всё тоже самое + поддержка BC 6-7, но проект заброшен)
- А для математики можна https://github.com/opentk/MathSharp - как раз на SIMD'ах и задействует новые возможности .NET Core 3.0. Правда, пока в активном развитии. Ещё бы в идеале чтобы руки у автора BepuPhysics добрались до симдов неткора 3.0, о которых он так грезил :) Но, он зараза, ждет пока финальная версия выйдет.

И, в общем-то, всё перечисленное выше - pure managed (кроме FMOD/Bass/OpenAL) и cross platform с компиляцией под .NET Core :)
Pure managed считаю крайне важен, и зависимостей на с/плюсах должно быть минимум, иначе проще писать на плюсах, чем держать две ИДЕшки открытыми и прыгать из шарпового проекта в плюсовой и обратно.

xruck
>На c# как-то не серьезно
https://mattwarren.org/2019/03/01/Is-CSharp-a-low-level-language/
Думаю всё зависит от прямоты рук)

iperov
>C# powered game engines:
Из перечисленных в твоем списке только Xenko3D и WaveEngine можно назвать almost (ну если учитывать кучку сишных зависимостей что они юзают) 100% pure managed 3D движками. У FLAX - только редактор мира на шарпе написан и публичная апиха (они аналогичную и для плюсовиков предоставляют -- но только тем, кто лицензировал двигло), можно посмотреть (https://github.com/FlaxEngine/FlaxAPI)
У всех остальных перечисленных - C# плюс/минус поскриптовать, с разной степенью глубины интеграции и предоставляемых возможностей (у Unity например сильно больше, чем у CryEngine).
За UrhoSharp не скажу, не смотрел, возможно тоже лишь обёртка над Сишными кишками.
Ну и можно к списку (Xenko3D, WaveEngine) добавить так же MonoGame, вполне живой и здравствует, прост в использовании.


xruck
>Все адекватные движки которые я знаю написаны на C++ (кроме xenko)
Скорее тут вопрос инерции, предубеждений (JIT/GC МЕДЛЕННОЕ ЗЛОО-О-О) и количество академического материала, который почти весь на С/С++.
Безусловно, вопрос скорости тоже имеет значение, но думаю с приходом .NET Core он постепенно невелируется до незначительного (или непринципиального, у кого какие вкусы).
А .NET Core 3.0, где стали доступны SIMDы, помимо непрекращающихся оптимизаций CLR обширным коммьюнити на гитхабе, помойму, в достаточной степени развязали руки всем желающим попробовать сделать своего убийцу... Крузиса? Или что нынче модно?.
Но, все же, прямота рук, и желание, имеют значение, и наверное даже превалируют над технологией. В конце концов, если сильно хочеться, то тебе ничто не мешает даже на стареньком и медленном (в сравнении с неткором конечно) .NET Framework 4.6 написать полноценную и очень успешную в плане продаж стратежку - https://store.steampowered.com/app/644930/They_Are_Billions/ - без всяких Юнитей и прочего блекджека.
У ребят там только их простенькая физика на плюсах разве что, ну и ещё сишный Bass для звука юзают, и... libVLC на кой-то хрен (видимо, для поддержки воспроизведения видео роликов, которых я особо не замечал).
В остальном у них там всё на шарпе, и игра при тысячах движущихся зомби на экране работает прекрасно (хотя иногда да мимолётно сборщик мусора проскочит на одну секунду :-D). Но и справедливости ради скажу, что 3D у них там весьма "условное", но арт у них зачетный.
Единственное разве что непонятно зачем они SlimDX юзали в качестве прослойки к DirectX'у, а не SharpDX, последний пошустрее будет.

GLoom
>Надо попробовать Diligent завести под .net. что то схожу не нашлось готовых решений.
А под него и нет готового враппера под .NET, он совсем недавно ж публичный свет только увидел)

#22
2:35, 8 июня 2019

Kinjal
> предубеждений (JIT/GC МЕДЛЕННОЕ ЗЛОО-О-О)
это так, unity3D давно использует IL2CPP, но с появлением у них компилятора а-ля ispc они все остальные компиляторы перестали считать за нормальные (есть ссылка выше)

#23
7:44, 8 июня 2019

endeavour_pr
> сам ты динозавр, в анриле никто не мешает пару строчек блупринтом сделать

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

#24
10:06, 8 июня 2019

endeavour_pr
> А для чего движок ?
Мне кажется настал момент в истории геймдева, когда движки можно собирать вот так, из деталей. Хочется проверить на практике.

#25
10:08, 8 июня 2019

Kinjal
Посмотрел по быстрому. Да, выглядит интересно, я не против такого набора.

#26
10:13, 8 июня 2019

GLoom
> Мне кажется настал момент в истории геймдева, когда движки можно собирать вот
> так, из деталей.
Всё таки скорее всего нет.
Одна из главных штук компьютера — операционная система.
Все программы которые сделаны на компьютере—-обращаются к операционной системе.
Операционная система является поставщиком услуг для программ.
Чтобы собрать движок просто вот так из деталей—- вы должны знать устройство операционной системы—- а это устройство вам никто не даст —это все таки наука,авторство,патенты, бизнес и деньги, труд других людей(не ваш труд) и этот труд охраняется.
  Просто так собрать из деталей—-скорее всего нет, не всё так просто.

#27
10:19, 8 июня 2019

Kinjal
> шарп не зайдет?
Мне лично - зайдет. Но если потом с этим идти "в народ" то нужно что то упрощенное. По началу можно без скриптов.

Я смотрю veldrid содержит sdl2 вместе с его событиями ввода. Я про абстрагирование ввода совсем забыл в списке.

#28
(Правка: 13:08) 13:05, 8 июня 2019

#!
>это так, unity3D давно использует IL2CPP, но с появлением у них компилятора а-ля ispc они все остальные компиляторы перестали считать за нормальные (есть ссылка выше)
Понятное дело что любой JIT/GC это немного медленнее, чем plain C например :)
Но, считаю, зависит от целеполагания. Вон, авторам They Are Billions это не помешало родить вполне себе прикольную игрулю которая играется более чем smoothly.
Да и, современные возможности шарпа/неткора позволяют писать performance-critical участки кода с как можно меньшим pressure на GC (Span<T> и сотоварищи), невелируя по возможности просадки которые могут быть вызваны сборкой мусора там, где это совсем не желательно.

GLoom
>Мне лично - зайдет. Но если потом с этим идти "в народ" то нужно что то упрощенное.
Что-то "упрощенное" уже есть - Unity. Ошибочно пытаться делать движок и метить на его поле.
И потому, если и делать двигло, то считаю надо соизмерять размер челюстей, и аудиторию которую хочешь охватить, с учетом доступности Unity для любителей скриптов, CryEngine для любителей сурового С++, и UE4 для любителей медетативного процесса долгой компиляции.
Не говоря уж о всяких WaveEngine/Xenko3D/Shiva3D (до кучи) и прочих.
Хотя, если говорить о С++ двиглах не из когорты CryEngine/UE, то самая тру-основа для сообственной технологии это пожалуй Banshee3D, неплохо написан.

>Я смотрю veldrid содержит sdl2 вместе с его событиями ввода
Да, у него там свой ничошный такой враппер над SDL2, который охватывает не весь конечно апи SDL вплоть до 2.0.9, но всё основное для окна/ввода - есть.
Скачай, скомпиль, позырь основную демку (NeoDemo), зацени производительность.

>Я про абстрагирование ввода совсем забыл в списке.
Да там ещё можно всякого добавить в твой список, например сеть (https://github.com/RevenantX/LiteNetLib/ или https://github.com/lidgren/lidgren-network-gen3), или там Steamworks (https://github.com/Facepunch/Facepunch.Steamworks/), или там AvaloniaUI (https://github.com/AvaloniaUI/Avalonia) для редактора (хотя можно и SciterSharp - этакий аналог Хрома для нужд UI юзая веб-технологии, но размером в 5мб и всего одна дллка - http://sciter.com), или SquidUI (https://github.com/Roderik11/Squid) для игрового UI...

P.S.
Но, что считаю более важным, всё-таки, прежде чем делать движок, понять потенциальную целевую аудиоторию которой двигло может зайти (а может и нет) и определить некий feature-set, чтобы не делать лишнюю работу которая затянет процесс на года, и не лезть на заведомо проигрышную территорию (Unity3D) успех на которой требует просто много планомерной и последовательной работы.
То есть, как мне это видиться,
1. Делать двигло общего назначения смысла нет. Ибо есть юнити и уе4, и где то сбоку плетется крайенжин, если говорить о мастадонтах с кучей доков/примеров и командой их разрабатывающих.
2. Как следует из пункта 1, делать очередной движок для шутеров смысла тоже нет, ибо там важен графон. А в таких случаях выбор многих однозначно падёт либо в сторону уе4, либо крайенжин на крайняк.
3. Имеет смысл сконцентрироваться тупо на одном жанре, и делать двигло под него. Моё предложение - RTS/RPG (тоесть 3д, но под изометрическую камеру), ориентиры - варкрафт, старкрафт, дота 2, компания героев, divinity. Почему? Та просто потому что если погуглить, то окажется что под них тупо нет нормального опенсорного движка. Это абсолютно свободная ниша как мне кажется. В стане ртс есть конечно Spring3D - но это ужасное говно мамонта, хотя и с неплохим коммьюнити. Есть ещё https://play0ad.com и wesnoth.org - но это опенсорсные ртс игры, и графические возможности их движков ужасны (у 0a.d в этом плане чуть получше). У rpg так вообще пусто на этом поле, либо допускаю что я просто не слышал.
4. Делать только под .NET Core 3.0 и не ниже, потому как:
а) Он развивается, а framework в статусе maintenance
б) в 3.0 завезли интринсики/simd, и unity-build (можно тупо один ехешник распространять, весь runtime/зависимости и сами бинарники проекта уже в нем).
в) кроссплатформа, в отличии от фреймворка.
г) когда родится движок, будет уже .NET Core 128.3 :) Поэтому на "вчерашний" день ориентироваться даже смысла нет.
5. Ну и, пожалуй, любой движковый новострой ценен только одним - когда для него есть хоть какая-нибудь демочка. Полноценная игра, например :) То есть, делать двиг не ради двига, а пытаться делать под какую-то [хотя бы маленькую] игру - имеет бОльший смысл, чем просто делать двиг ради двига, который никому будет не нужен, ибо не будет наглядной демонстрации "боевого крещения" (помимо feature демок, разумеется).
6. А для организации внутреннего процесса можно юзать Dev Azure - канбан борда, гит, автосборка если надо, вики, все вместе и все удобно :)

Как-то так мне это всё видится. Допускаю, что неправ :)

#29
16:03, 8 июня 2019

Kinjal
Ну мне все нравится. Когда начинаем?

Страницы: 1 2 3 48 Следующая »
ПрограммированиеФорумОбщее