Re[17]: Unity
От: vdimas Россия  
Дата: 02.08.21 10:04
Оценка: 2 (1)
Здравствуйте, Serginio1, Вы писали:

V>>Поэтому сборщик мусора консервативный, он любой мусор в памяти трактует как потенциальную ссылку на объект!!!

S> Ага в нативе свой менеджер памяти, а У СБОРЩИКА МУСОРА СВОЯ память.

Сам придумал?
Я тебе давал уже ссылку, там этот GC:
https://en.wikipedia.org/wiki/Boehm_garbage_collector

Хипы памяти там обычные, нейтивные, поэтому, никаких перемещений/уплотнений памяти нет.


S>>>JIT без среды не бывает!!

V>>Бывает, если бинарный образ в формате LLVM!!
S> Еще раз LLVM это не джит!!

LLVM имеет джит в своей поставке.


S>Он без среды. Jit только со средой идет!!!


А земля тоже плоская? ))
(че-та ржу уже)


V>>Ровно то, что пишет вики.

V>>А вот и пример:
V>>https://gist.github.com/38/39e7b514d916ed6fa6a2bba629fdf6ff
S>Угу https://ru.wikipedia.org/wiki/JIT-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F
S>

S>JIT-компиляция (англ. Just-in-Time, компиляция «на лету»), динамическая компиляция (англ. dynamic translation) — технология увеличения производительности программных систем, использующих байт-код, путём компиляции байт-кода в машинный код или в другой формат непосредственно во время работы программы.


Верно.
1. Бинарники LLVM можно исполнять в режиме транслятора на эмуляторе его процессора;
2. Либо использовать JIT;
3. Либо использовать высокооптимизированный AOT-компилятор.


S>Нахрена JIT если как ты говоришь все в С++.


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


S>JIT нужен для динамической компиляции средой исполнения, то бишь MONO рантайм


Технология JIT cуществовала до MONO и будет существовать после.
Нет там никакой среды исполнения MONO.


V>>Вряд ли, бо в коде скриптов особо оптимизировать обычно нечего.

V>>Повторюсь, вероятнее всего техника генерации С++-исходников выбрана с целью не возиться с самописным компилятором C#.
S> У моно есть компилятор C# https://ru.wikipedia.org/wiki/Mono

Да хоть у .Net Core.
Сосредоточься, "с целью не возиться с самописным компилятором C#" означает "с целью взять какой-нибудь готовый".


S>IL2CPP нужен для яблока. Там своя безопасность. То же самое и в Xamarin. Для андроида JIT идет, для IPhone компилируют в натив


JIT не означает дотнет.
И да, для андроида доступна и AOT.


V>>Потому что многие типы не могут нормально работать без среды с её метаинформацией, тот же Comparer<T>.Default.

V>>А тут никакой метаинформации, llvm — это просто инструкции ассемблера, но не к специальной VM, поддерживающей типы/объекты на уровне своей модели, а ко вполне традиционному по архитектуре риск-процессору. JIT просто переводит код из инструкций этого риск-процессора в код нейтивного процессора.

S>Если не нужно докомпилировать, то и среда не нужна.


Среда нужна не столько для докомпиляции, сколько для метаинформации, чтобы размечать фреймы стека и память объектов для целей работы GC.
Ничего этого в Unity нет.


S>Поэтому на .Net Native много ограничений на рефлексию и динамическую компиляцию.


В Unity нет никакого .Net Native, никакого Mono, никакой среды исполнения, ни-че-го!
Есть инвалидный GC, который работает архи-хреново, потому что он консервативный.
https://habr.com/ru/post/213225/


V>>А ты уже почитал про отличие точного GC от консервативного?

V>>Почитай, устыдись.
S> В .Net Native использеутся один и тот же тот же сборщик https://docs.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation#just-in-time-compilation
S>.NET Native использует тот же сборщик мусора, что и стандартная среда CLR. В сборщике мусора .NET Native фоновая сборка мусора включена по умолчанию.

Т.е., так и не почитал?
Ну вот я ссылку выше дал.

И при чём тут .Net Native, если Unity его не использует и никогда не будет использовать?


S> А ты не путаешь shared_ptr и поиск по достижимым объектам?

S>Как по твоему должен работать
S>System.GC.Collect();

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

Итак, опишите своими словами особенности консервативного сборщика мусора?


S>https://docs.unity3d.com/ru/530/Manual/UnderstandingAutomaticMemoryManagement.html

S>>>Ты видишь С++ и у тебя сразу отсутсвие .Net. При этом ты упорно игнорируешь сборку мусора!!

Потому что я регулярно вижу в С++ сборку мусора безо-всякого дотнета.
Получается, ты не знал, что у С++ бывают GC?
Поэтому выносишь мне моск? ))


S>>>Еще раз JIT компиляция происходит в среде

V>>В какой?
S>ссылки не читаешь?
S>https://www.mono-project.com/docs/advanced/runtime/

У Unity JIT-компиляция не происходит в этой среде.
И никакой другой дотнетной или джавовской.

V>>Не только, там для этого сборщика мусора обитает метаинформация об объектах, т.е. разметка их в памяти.

V>>Просто потёрли имена методов, флаги и т.д.
V>>Без этой метаинформации не работало бы динамическое приведение типов.
S>Информация о типе во многих языках хранится в VMT по отрицательному смещению.

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


S>Виртуальные методы не нужны?


Пфф...
Конкретно тебе нужен исправно работающий моск.
Очень.

V>>В режиме .Net Native доступно большинство фунционала GetType(), просто символьных данных там нет.

V>>Поэтому, Comparer<T>.Default там не работает, поэтому тебе придётся пройтись по своему коду, подставляя в конструктор коллекций comparer явно.

S> При специализации сзаранее создаются типы. Либо ты их можешь указать

S>https://docs.microsoft.com/ru-ru/windows/uwp/dotnet-native/apis-that-rely-on-reflection

Но в твоей программе рефлексия для этих типов не нужна.
И да, в коллекциях хранятся в том или ином виде практически 100% целевых объектов верхнего уровня на всех слоях (верхнего для данного слоя архитектуры), это, получается, у тебя 100% объектов должны будут rely-on-reflection, рилли? ))


V>>Не просто разные.

V>>.Net Native компиллирует код для исполнения в CLR.
S> Нет!! Почитай же ты ссылки!!

Твои ссылки ничего не доказывают, читай свои ссылки внимательней!!
NET Native — это просто разновидность CLR.


V>>Я читаю хорошо, но настоётельно рекомендую тебе, таки, сделать посоветованные приседания, дабы закончить, наконец, засорять эфир мусором.

S>Почему я должен верить тебе

Не надо мне верить!!
Надо взять любой малюсенький пример-сэмпл для Unity, запустить и его немножечко поисследовать.


S>а не документации Unity которые явно говорят

S>Использует ли наша игра компиляцию AOT или JIT, обычно зависит от целевого оборудования.

В документации всё верно.
Просто ты двоечник какой-то, не понимающий простейшего абзаца текста.


V>>.Net Core им нужен был для наличия дотнета в облачных вычислениях.

V>>То бишь, в линухах.
S> Это уже потом.

Это изначально.

On November 12, 2014, Microsoft announced .NET Core, in an effort to include cross-platform support for .NET, including Linux and macOS

Разумеется, первый же выпуск был кроссплатформенным.


S>.Net Native появился еще в 2013 году, а потом они взяли наработки из .Net Native и создали .Net Core/


Ложь и глупость.

В сети хватает информации о построении .Net Core.
Он был сделан из обычного .Net Framework путём последовательной кросс-платформенной доработки либ фреймворка.


S>Используемые библиотеки одни и теже, а для отладки используется Core CLR


Это ты про что сейчас?
Всё еще про Unity Или о чём-то своём?
Если про Unity — то в твоих словах ложь.


V>>Только это в 17 размедленнее простого вызова ф-ии по адресу.

S>И в чем конкретно задержка в 17 раз? Чем ассемблерный код отличается от нативного?

Вопрос сформулирован дико, но фиг с ним.
Вот сравнение кода вызова по управляемому адресу ф-ии и по неуправляемому:
            managedPtr(bar, ref tmp);
00007FFDF38B7D5A  mov         rcx,qword ptr [rbp+10h]  
00007FFDF38B7D5E  mov         qword ptr [rbp-10h],rcx  
00007FFDF38B7D62  mov         rcx,2A1DFA42C80h  
00007FFDF38B7D6C  mov         rcx,qword ptr [rcx]  
00007FFDF38B7D6F  lea         rdx,[rbp-8]  
00007FFDF38B7D73  mov         rax,qword ptr [rbp-10h]  
00007FFDF38B7D77  call        rax  
            unmanagedPtr(bar, ref tmp);
00007FFDF38B7D79  mov         rcx,qword ptr [rbp+18h]  
00007FFDF38B7D7D  mov         qword ptr [rbp-18h],rcx  
00007FFDF38B7D81  mov         rcx,2A1DFA42C80h  
00007FFDF38B7D8B  mov         rcx,qword ptr [rcx]  
00007FFDF38B7D8E  lea         rdx,[rbp-8]  
00007FFDF38B7D92  mov         r10,qword ptr [rbp-18h]  
00007FFDF38B7D96  mov         r11,2A1E80E38A0h  
00007FFDF38B7DA0  call        GenericPInvokeCalliHelper (07FFE53439FD0h)


Смотрим, что происходит при пользовании неуправляемыми указателями на ф-ии:
https://github.com/dotnet/runtime/blob/57bfe474518ab5b7cfe6bf7424a79ce3af9d6657/src/coreclr/vm/amd64/PInvokeStubs.asm#L29


S>Опять использование Jit


Обычно никакого JIT.
В любом случае, это не тот JIT.


S>и GC.Collect ну нихрена не дотнет!


Это не тот GC.
В плюсовом коде тоже есть какой-нить GC.Collect(), и даже несколько их вариантов.
Поэтому — да, не дотнет ни разу.

А почему ты вообще к этому дотнету прицепился как клещами? ))
Шаблончик порвался?


S>>>А используют они компилятор свой и JIT ят тоже своим, хотя .Net Core то открыт. Они могут вложиться и в CoreRT.

V>>С тем же успехом можно предполагать, что они могут вложиться в MS Office или даже в разведение форели.
S> Ну вот другие то вкладываются ибо он открыт, а MS Office нет

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


S> Ну либо используйте .NetStandard, Visual Studio по полной программе. Либо топчитесь на месте


И что?
Используя последний компилятор C# можно генерить код для любого из предыдущих TargetFramework.
В данный момент вся соль в самом языке, который динамично развивается и обрастает возможностями, как раз востребованными в высокоэффективной нише.
Отредактировано 02.08.2021 16:29 vdimas . Предыдущая версия . Еще …
Отредактировано 02.08.2021 13:25 vdimas . Предыдущая версия .
Отредактировано 02.08.2021 12:55 vdimas . Предыдущая версия .
Re[17]: Unity
От: vdimas Россия  
Дата: 02.08.21 10:08
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

S>В настоящее время у нас есть планы по исследованию интеграции сборщика мусора CoreCLR с открытым исходным кодом.


Ты уже приводил этот отрывок.
Там написано, что у них есть планы однажды попытаться построить план.
До релиза не доживём.

Остальное процитированное — описание работы плюсового сборщика мусора.
Re[18]: Unity
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.08.21 10:46
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:


V>>>Поэтому сборщик мусора консервативный, он любой мусор в памяти трактует как потенциальную ссылку на объект!!!

S>> Ага в нативе свой менеджер памяти, а У СБОРЩИКА МУСОРА СВОЯ память.

V>Сам придумал?

V>Я тебе давал уже ссылку, там этот GC:
V>https://en.wikipedia.org/wiki/Boehm_garbage_collector
Там пишут https://blog.unity.com/ru/technology/il2cpp-internals-garbage-collector-integration

Мы рассмотрели некоторые внутренние методы API, чтобы увидеть, как среда выполнения IL2CPP взаимодействует со сборщиком мусора, давая ему знать, какие объекты являются корнями, которые он должен сохранить. Обратите внимание, что мы вообще не говорили о том, какой сборщик мусора использует IL2CPP. В настоящее время он использует GC Бема-Демерса-Вайзера, но мы упорно трудились, чтобы изолировать сборщик мусора за чистым интерфейсом. В настоящее время у нас есть планы по исследованию интеграции сборщика мусора CoreCLR с открытым исходным кодом. У нас пока нет точной даты поставки для этой интеграции, но следите за обновлениями в нашей общедоступной дорожной карте.


И пишут что используют и GSHandle и il2cpp_gc_alloc_fixed. Почитай. Я тебе отдельно скинул http://rsdn.org/forum/flame.comp/8064451.1
Автор: Serginio1
Дата: 02.08 12:24

V>Хипы памяти там обычные, нейтивные, поэтому, никаких перемещений/уплотнений памяти нет.

Угу при этом использую GCHandle и fix. Уплотнения нет, но есть подсчет ссылок по графу достижимых объектов согласно статье.
S>>Он без среды. Jit только со средой идет!!!

V>А земля тоже плоская? ))

V>(че-та ржу уже)
Во во. Я тоже

V>>>Ровно то, что пишет вики.

V>>>А вот и пример:
V>>>https://gist.github.com/38/39e7b514d916ed6fa6a2bba629fdf6ff
S>>Угу https://ru.wikipedia.org/wiki/JIT-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F
S>>

S>>JIT-компиляция (англ. Just-in-Time, компиляция «на лету»), динамическая компиляция (англ. dynamic translation) — технология увеличения производительности программных систем, использующих байт-код, путём компиляции байт-кода в машинный код или в другой формат непосредственно во время работы программы.


V>Верно.

V>1. Бинарники LLVM можно исполнять в режиме транслятора на эмуляторе его процессора;
V>2. Либо использовать JIT;
V>3. Либо использовать высокооптимизированный AOT-компилятор.

AOT ну никак к JIT не относится! Но FOT может быть со средой или без, а вот ОШЕ без среды никак!
S>>Нахрена JIT если как ты говоришь все в С++.

V>Потому что для некоторых платформ компилятор генерирует не родной код, а код для процессора LLVM.

V>И тогда для исполнения на родном коде требуется переводить бинарный код из одной системы команд в другую.
И среда нужна?

S>>JIT нужен для динамической компиляции средой исполнения, то бишь MONO рантайм


V>Технология JIT cуществовала до MONO и будет существовать после.

V>Нет там никакой среды исполнения MONO.
Unity используют MONO

V>>>Вряд ли, бо в коде скриптов особо оптимизировать обычно нечего.

V>>>Повторюсь, вероятнее всего техника генерации С++-исходников выбрана с целью не возиться с самописным компилятором C#.
S>> У моно есть компилятор C# https://ru.wikipedia.org/wiki/Mono

V>Да хоть у .Net Core.

V>Сосредоточься, "с целью не возиться с самописным компилятором C#" означает "с целью взять какой-нибудь готовый".

Еще раз Unity используют MONO. Казалось бы зачем?
S>>IL2CPP нужен для яблока. Там своя безопасность. То же самое и в Xamarin. Для андроида JIT идет, для IPhone компилируют в натив

V>JIT не означает дотнет.

V>И да, для андроида доступна и AOT.
JIT означает что использется библиотеки .Net. А вот во что они компилируются это уже другая история.
По твоему .Net Native не дотнет?

V>>>Потому что многие типы не могут нормально работать без среды с её метаинформацией, тот же Comparer<T>.Default.

V>>>А тут никакой метаинформации, llvm — это просто инструкции ассемблера, но не к специальной VM, поддерживающей типы/объекты на уровне своей модели, а ко вполне традиционному по архитектуре риск-процессору. JIT просто переводит код из инструкций этого риск-процессора в код нейтивного процессора.

S>>Если не нужно докомпилировать, то и среда не нужна.


V>Среда нужна не столько для докомпиляции, сколько для метаинформации, чтобы размечать фреймы стека и память объектов для целей работы GC.

V>Ничего этого в Unity нет.
Ну конечно же JIT без среды это AOT, а они пишут что использут JIT. Я им верю.

S>>Поэтому на .Net Native много ограничений на рефлексию и динамическую компиляцию.


V>В Unity нет никакого .Net Native, никакого Mono, никакой среды исполнения, ни-че-го!

V>Есть инвалидный GC, который работает архи-хреново, потому что он консервативный.
V>https://habr.com/ru/post/213225/
В статье несколько другая информация

V>>>А ты уже почитал про отличие точного GC от консервативного?

V>>>Почитай, устыдись.
S>> В .Net Native использеутся один и тот же тот же сборщик https://docs.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation#just-in-time-compilation
S>>.NET Native использует тот же сборщик мусора, что и стандартная среда CLR. В сборщике мусора .NET Native фоновая сборка мусора включена по умолчанию.

V>Т.е., так и не почитал?

V>Ну вот я ссылку выше дал.

V>И при чём тут .Net Native, если Unity его не использует и никогда не будет использовать?



S>> А ты не путаешь shared_ptr и поиск по достижимым объектам?

S>>Как по твоему должен работать
S>>System.GC.Collect();

V>Это я тебя должен спрашивать на этой итерации, потому что я уже 4 раза говорил, что тебе надо прочитать.

V>Пора задавать контрольные вопросы.

V>Итак, опишите своими словами особенности консервативного сборщика мусора?

Ну ты ссылки читать будешь https://blog.unity.com/ru/technology/il2cpp-internals-garbage-collector-integration
Там написано, что используется граф достижимых объектов!

S>>https://docs.unity3d.com/ru/530/Manual/UnderstandingAutomaticMemoryManagement.html

S>>>>Ты видишь С++ и у тебя сразу отсутсвие .Net. При этом ты упорно игнорируешь сборку мусора!!

V>Потому что я регулярно вижу в С++ сборку мусора безо-всякого дотнета.

V>Получается, ты не знал, что у С++ бывают GC?
V>Поэтому выносишь мне моск? ))

Ты про shared_ptr? shared_ptr основан на подсчете ссылок, а GC основан на подсчете достижимых объектов.
Какой аналог в C++ GC.Collect ?


V>Твои ссылки ничего не доказывают, читай свои ссылки внимательней!!

V>NET Native — это просто разновидность CLR.
Охренеть. Молодец главное аргументировано то как.



V>В документации всё верно.

V>Просто ты двоечник какой-то, не понимающий простейшего абзаца текста.
Ну ты то пишешь, что никаой среды нет!

V>>>.Net Core им нужен был для наличия дотнета в облачных вычислениях.

V>>>То бишь, в линухах.
S>> Это уже потом.

V>Это изначально.

V>

V>On November 12, 2014, Microsoft announced .NET Core, in an effort to include cross-platform support for .NET, including Linux and macOS

V>Разумеется, первый же выпуск был кроссплатформенным.


S>>.Net Native появился еще в 2013 году, а потом они взяли наработки из .Net Native и создали .Net Core/


V>Ложь и глупость.

https://ru.wikipedia.org/wiki/.NET_Core
.NET Core 1.0 27 июня 2016 года[5]
и солнце б утром не вставало, когда бы не было меня
Re[18]: Unity
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.08.21 10:54
Оценка:
Здравствуйте, vdimas, Вы писали:


V>>>Только это в 17 размедленнее простого вызова ф-ии по адресу.

S>>И в чем конкретно задержка в 17 раз? Чем ассемблерный код отличается от нативного?

V>Вопрос сформулиорван дико, но фиг с ним.

V>Вот сравнение кода вызова по управляемому адресу ф-ии и по неуправляемому:
V>
V>            managedPtr(bar, ref tmp);
V>00007FFDF38B7D5A  mov         rcx,qword ptr [rbp+10h]  
V>00007FFDF38B7D5E  mov         qword ptr [rbp-10h],rcx  
V>00007FFDF38B7D62  mov         rcx,2A1DFA42C80h  
V>00007FFDF38B7D6C  mov         rcx,qword ptr [rcx]  
V>00007FFDF38B7D6F  lea         rdx,[rbp-8]  
V>00007FFDF38B7D73  mov         rax,qword ptr [rbp-10h]  
V>00007FFDF38B7D77  call        rax  
V>            unmanagedPtr(bar, ref tmp);
V>00007FFDF38B7D79  mov         rcx,qword ptr [rbp+18h]  
V>00007FFDF38B7D7D  mov         qword ptr [rbp-18h],rcx  
V>00007FFDF38B7D81  mov         rcx,2A1DFA42C80h  
V>00007FFDF38B7D8B  mov         rcx,qword ptr [rcx]  
V>00007FFDF38B7D8E  lea         rdx,[rbp-8]  
V>00007FFDF38B7D92  mov         r10,qword ptr [rbp-18h]  
V>00007FFDF38B7D96  mov         r11,2A1E80E38A0h  
V>00007FFDF38B7DA0  call        GenericPInvokeCalliHelper (07FFE53439FD0h)  
V>


Спасибо!
V>Смотрим, что происходит при пользовании неуправляемуми указателями на ф-ии:
V>https://github.com/dotnet/runtime/blob/57bfe474518ab5b7cfe6bf7424a79ce3af9d6657/src/coreclr/vm/amd64/PInvokeStubs.asm#L29


S>>Опять использование Jit


V>Обычно никакого JIT.

V>В любом случае, это не тот JIT.


S>>и GC.Collect ну нихрена не дотнет!


V>Это не тот GC.

V>В плюсовом коде тоже есть какой-нить GC.Collect(), и даже несколько их вариантов.
V>Поэтому — да, не дотнет ни разу.
Ну да. Интересно какой, если ты про подсчет сылок говоришь, а не про поиск достижимых объектов.
Про копирование читал, но это уже ближе к манагед GC
V>А почему ты вообще к этому дотнету прицепился как клещами? ))
V>Шаблончик порвался?

S>> Ну либо используйте .NetStandard, Visual Studio по полной программе. Либо топчитесь на месте


V>И что?

V>Используя последний компилятор C# можно генерить код для любого из предыдущих TargetFramework.
V>В данный момент вся соль в самом языке, который динамично развивается и обрастает возможностями, как раз востребованными в высокоэффективной нише.
Из предыдущих да, а наоборот нет. Те же Span только в .Net Core https://docs.microsoft.com/ru-ru/dotnet/api/system.span-1?view=netcore-3.1
.NET Standard 2.1
и солнце б утром не вставало, когда бы не было меня
Re[18]: Unity
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.08.21 12:20
Оценка:
Здравствуйте, vdimas, Вы писали:
V>В Unity нет никакого .Net Native, никакого Mono, никакой среды исполнения, ни-че-го!
https://forum.unity.com/threads/mono-versions-bundled-with-unity.602251/

Нет прямого сопоставления между версиями Unity и Mono версиями, так как мы извлекаем исходный код Mono и изменяем его. Однако Unity поддерживает определенные версии профилей .NET. В Unity 2018.3 вы можете выбрать .NET 4.7.1 или .NET Standard 2.0. К сожалению, Span<T> не доступен ни в том, ни в другом.<T>

В будущей версии Unity мы планируем поддерживать .NET Standard 2.1, где Span<T> доступен. Вы можете следить за разработкой .NET Standard здесь: https://github.com/dotnet/standard

и солнце б утром не вставало, когда бы не было меня
Re[12]: Unity
От: alexzzzz  
Дата: 02.08.21 12:56
Оценка: 2 (1) +2
Здравствуйте, vdimas, Вы писали:

A>>И управляемый код библиотек Unity работает в "родном" дотнете.

V>И что?
V>А в Unity не работает, потому что там не дотнет, там от IL-кода не остаётся даже следа.

Чё?

На iOS нет IL, потому что политика платформы, и на WebGL нет IL, потому что так проще. На других платформах IL2CPP — альтернатива. Хочешь — пользуйся, если польза превышает вред. Не хочешь — не пользуйся, будет привычная цепочка: C# -> IL -> Mono JIT. Можно скачать игрушку, которая не использует IL2CPP, покопаться в ней обычным dnSpy, посмотреть как устроена и/или пропатчить как душе угодно. В процессе разработки в самом редакторе Unity весь управляемый код, пользовательский и Unity, работает на Mono JIT, никакого IL2CPP.

A>>Unity не полностью нативный. Там есть ядрёная нативная часть, а более высокоуровневые фишки часто на C# или переползают на C#.

V>Это хорошо, что ты уже торгуешься.
V>Но сам движок нейтивный.
V>Даже которые части на C#.

Чё?

A>>Если из Unity API вырезать управляемую часть, оставить только ту, что ведёт сразу в нативный код, этим будет невозможно пользоваться.

V>Ты имеешь ввиду однострочные "объектные" обёртки на системой хендлов и свободных функций?

Нет.

A>>И что такое скрипты?

V>Да вы издеваетесь? ))
V>http://www.rsdn.org/forum/flame.comp/8063083

На C# они написали только АПИ-биндинг к структурам и функциям движка.


Не только. До вот хоть https://github.com/Unity-Technologies/Graphics

A>>Когда в WinForms нет какого-то специфического нужного тебе контрола, пишешь его сам или берёшь чужой. Нет в Unity какого-то функционала ― пишешь его сам или берёшь чужое.

V>Ага, всё что не касается графических объектов собсно Unity.

Объектов какого уровня? У Unity многоуровневое API, и десяток способов разной сложности реализовать одно и тоже. Уж по графике точно. Если вообще ничего не нравится, можешь самостоятельно генерировать необходимые данные и заливать в самописный шейдер.

Нетехнический флуд я пропущу.
Отредактировано 02.08.2021 13:16 alexzzzz . Предыдущая версия .
Re[13]: Unity
От: vdimas Россия  
Дата: 03.08.21 11:43
Оценка:
Здравствуйте, alexzzzz, Вы писали:

A>В процессе разработки в самом редакторе Unity весь управляемый код


Это всем известно, что редактор на дотнете.
Вопрос был об этапе запуска игры.

A>>>И что такое скрипты?

V>>Да вы издеваетесь? ))

По ссылке был ответ на твой вопрос.


V>>http://www.rsdn.org/forum/flame.comp/8063083

A>

На C# они написали только АПИ-биндинг к структурам и функциям движка.

A>Не только.

В движке только.


A>До вот хоть https://github.com/Unity-Technologies/Graphics


Это не движок, это опенсорсная коллекция велосипедов, которые клиенты писали самостоятельно в своих проектах.
Судя по многочисленным комментам в проекте — проект во многом был вдохновлён и наполнен кодом от клиентов.
Т.е., по-идее, клиенты могли бы и независимо от Unity инициировать опен-сорсную разработку этой библиотеки.

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


A>>>Когда в WinForms нет какого-то специфического нужного тебе контрола, пишешь его сам или берёшь чужой. Нет в Unity какого-то функционала ― пишешь его сам или берёшь чужое.

V>>Ага, всё что не касается графических объектов собсно Unity.
A>Объектов какого уровня?

Объектов уровня низлежащего графического АПИ.
Если Unity не предоставило в АПИ шарпа доступ к какой-либо функциональности (а она не предоставила), то ты уже ничего не сделаешь.
В UE такой проблемы нет.


A>У Unity многоуровневое API, и десяток способов разной сложности реализовать одно и тоже.


Это можно сказать о любой программистской задаче, к делу не относится.
Отредактировано 03.08.2021 12:45 vdimas . Предыдущая версия .
Re[14]: Unity
От: alexzzzz  
Дата: 04.08.21 13:20
Оценка:
Здравствуйте, vdimas, Вы писали:

A>>В процессе разработки в самом редакторе Unity весь управляемый код

V>Это всем известно, что редактор на дотнете.
V>Вопрос был об этапе запуска игры.

Релизный билд может играться на Mono JIT, может на AOT — IL2CPP. Ты сам выбираешь, хочешь иметь JIT или AOTа достаточно. Когда-то выбора вообще не было, на всех платформах был только Mono JIT, кроме iOS — там в принудительном порядке Mono AOT.

V>>>http://www.rsdn.org/forum/flame.comp/8063083

A>>

На C# они написали только АПИ-биндинг к структурам и функциям движка.

A>>Не только.
V>В движке только.

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

A>>До вот хоть https://github.com/Unity-Technologies/Graphics

V>Это не движок, это опенсорсная коллекция велосипедов, которые клиенты писали самостоятельно в своих проектах.

Нет. Это инициатива сверху по переносу части захардкоженного в нативе легаси графического пайплайна на сторону пользователя для большей гибкости.

V>Судя по многочисленным комментам в проекте — проект во многом был вдохновлён и наполнен кодом от клиентов.

V>Т.е., по-идее, клиенты могли бы и независимо от Unity инициировать опен-сорсную разработку этой библиотеки.

Не могли бы.

Можешь посмотреть репозиторий uGUI — он попроще: https://github.com/Unity-Technologies/uGUI
Выкинешь из Unity этот код, не будет игрового UI, будешь велосипедить сам.

V>Объектов уровня низлежащего графического АПИ.

V>Если Unity не предоставило в АПИ шарпа доступ к какой-либо функциональности (а она не предоставила), то ты уже ничего не сделаешь.
V>В UE такой проблемы нет.

Какой конкретно функциональности тебе не хватает? Прямого доступа к API DirectX/OpenGL/Vulcan/Metal/что там ещё есть...?
Re[15]: Unity
От: vdimas Россия  
Дата: 04.08.21 15:35
Оценка:
Здравствуйте, alexzzzz, Вы писали:

A>Сейчас будешь смеяться, потому что теперь я спрошу, что такое движок?


Ну мы же сравнивали с UE?
Вот примерно это же.


A>>>До вот хоть https://github.com/Unity-Technologies/Graphics

V>>Это не движок, это опенсорсная коллекция велосипедов, которые клиенты писали самостоятельно в своих проектах.
A>Нет. Это инициатива сверху по переносу части захардкоженного в нативе легаси графического пайплайна на сторону пользователя для большей гибкости.

1. Но в движке эти же пайплайны остались
2. CommandBuffer был доступен и ранее, т.е. клиенты могли и сами эти пайплайны писать и ранее
3. Комменты в исходниках прямо об этом говорят, что этот эффект от того-то, а этот от того-то.


V>>Судя по многочисленным комментам в проекте — проект во многом был вдохновлён и наполнен кодом от клиентов.

V>>Т.е., по-идее, клиенты могли бы и независимо от Unity инициировать опен-сорсную разработку этой библиотеки.
A>Не могли бы.

Безинициативные? ))


A>Можешь посмотреть репозиторий uGUI — он попроще: https://github.com/Unity-Technologies/uGUI

A>Выкинешь из Unity этот код, не будет игрового UI, будешь велосипедить сам.

В приличных проектах всё-равно GUI свой.


V>>Объектов уровня низлежащего графического АПИ.

V>>Если Unity не предоставило в АПИ шарпа доступ к какой-либо функциональности (а она не предоставила), то ты уже ничего не сделаешь.
V>>В UE такой проблемы нет.
A>Какой конкретно функциональности тебе не хватает? Прямого доступа к API DirectX/OpenGL/Vulcan/Metal/что там ещё есть...?

Может не хватить любой функциональности, которая есть в этих низлежащих API.
Re[16]: Unity
От: alexzzzz  
Дата: 05.08.21 14:18
Оценка:
Здравствуйте, vdimas, Вы писали:

A>>Сейчас будешь смеяться, потому что теперь я спрошу, что такое движок?

V>Ну мы же сравнивали с UE?
V>Вот примерно это же.

Если определение движка — это примерно UE, то раз Unity не примерно UE, то Unity не движок. Как называть, мне пофиг, я Unity просто пользуюсь, но половина разговора тогда не имеет смысла.

A>>>>До вот хоть https://github.com/Unity-Technologies/Graphics

V>>>Это не движок, это опенсорсная коллекция велосипедов, которые клиенты писали самостоятельно в своих проектах.
A>>Нет. Это инициатива сверху по переносу части захардкоженного в нативе легаси графического пайплайна на сторону пользователя для большей гибкости.
V>1. Но в движке эти же пайплайны остались

Там много чего ещё осталось с древних времён. Для Unity практически норма иметь одновременно две-три похожие подсистемы, типа одна легаси для совместимости, другая актуальная боевая и, может, ещё одна перспективная экспериментальная в активной разработке.

V>2. CommandBuffer был доступен и ранее, т.е. клиенты могли и сами эти пайплайны писать и ранее


Старая документация:

While the current rendering pipeline is somewhat extensible (users can write their own shaders, manually control camera rendering, change settings, extend the rendering pipeline with command buffers), it is not extensible enough.


https://docs.unity3d.com/560/Documentation/Manual/ScriptableRenderPipeline.html

V>3. Комменты в исходниках прямо об этом говорят, что этот эффект от того-то, а этот от того-то.


Сверху наросло. Фича разрабатывается с 2017, если не раньше.

V>>>Судя по многочисленным комментам в проекте — проект во многом был вдохновлён и наполнен кодом от клиентов.

V>>>Т.е., по-идее, клиенты могли бы и независимо от Unity инициировать опен-сорсную разработку этой библиотеки.
A>>Не могли бы.
V>Безинициативные? ))

Без исходников Unity не могли бы, а кто с исходниками — тем не надо.

A>>Можешь посмотреть репозиторий uGUI — он попроще: https://github.com/Unity-Technologies/uGUI

A>>Выкинешь из Unity этот код, не будет игрового UI, будешь велосипедить сам.
V>В приличных проектах всё-равно GUI свой.

В UE плохой игровой GUI, или "приличные" проекты не делают на UE?

V>>>Объектов уровня низлежащего графического АПИ.

V>>>Если Unity не предоставило в АПИ шарпа доступ к какой-либо функциональности (а она не предоставила), то ты уже ничего не сделаешь.
V>>>В UE такой проблемы нет.
A>>Какой конкретно функциональности тебе не хватает? Прямого доступа к API DirectX/OpenGL/Vulcan/Metal/что там ещё есть...?
V>Может не хватить любой функциональности, которая есть в этих низлежащих API.

Т.е. без конкретики.
Re[17]: Unity
От: vdimas Россия  
Дата: 05.08.21 16:34
Оценка:
Здравствуйте, alexzzzz, Вы писали:

A>Если определение движка — это примерно UE


Примерно как движок в UE.


A>то раз Unity не примерно UE, то Unity не движок. Как называть, мне пофиг, я Unity просто пользуюсь, но половина разговора тогда не имеет смысла.


По-моему, ты придиираешься.
Разумеется, в поставку Unity входит не только движок, еще ресурсы, примеры, несколько прикладных либ, как ты давал ссылки и даже собственный 3D-редактор.

Простой вопрос — является ли редактор Unity самым удобным для дизайна 3D-объектов?
Как ни крути, но сегодня рулит параметрический дизайн и это в т.ч. подходит для разработки игровых объектов:
https://www.sculpteo.com/blog/2018/03/07/top-8-of-the-best-parametric-modeling-software/

Посмотри как-нить на https://www.rhino3d.com/6/new/grasshopper/

Например, "построить" виртуальный дом или даже виртуальный город можно в десятки раз быстрее с помощью специального ПО, предназначенного для строительного дизайна.
Потому что ты затрахаешься делать это в редакторе Unity, там не сравнимая трудоёмкость.

Аналогично прикладные библиотеки в поставке — это всё не обязательно, т.е. не факт, что будет задействовано.
А вот без движка — никуда.

Неужели в этом контексте всё еще не понятно, что есть "движок", каковы его ф-ии?


A>Там много чего ещё осталось с древних времён. Для Unity практически норма иметь одновременно две-три похожие подсистемы, типа одна легаси для совместимости, другая актуальная боевая и, может, ещё одна перспективная экспериментальная в активной разработке.


В компиляции в нейтив это безразлично, ес-но.
Но если, действительно, что-то предназначено для исполнения из под Mono, то код с плавающей точкой на C# сегодня выполняется до безобразия хреново.
А там столько вычислений сугубо для эффектов на стороне C#...

В этом сценарии уж лучше пользовать встроенное, параметризируя это всё шейдерами и графическими ресурсами.


V>>2. CommandBuffer был доступен и ранее, т.е. клиенты могли и сами эти пайплайны писать и ранее


A>Старая документация:

A>

While the current rendering pipeline is somewhat extensible (users can write their own shaders, manually control camera rendering, change settings, extend the rendering pipeline with command buffers), it is not extensible enough.

A>https://docs.unity3d.com/560/Documentation/Manual/ScriptableRenderPipeline.html

Ну, я не настолько глубоко копал rendering pipeline, чтобы дать свою оценку.
А в чем было меньше гибкости для лично тебя, например?
Не было в наличии каких-то команд в CommandBuffer, которые появились сейчас?

Сдаётся мне, что здесь рассуждения о размене кода шейдеров vs кода C#.
Потому что многие те вычисления можно делать на стороне шейдера, подавая ему лишь аргументы-коэфициенты.
А сейчас они сделали сами шейдеры проще, за счёт большего предвычисления извне.

А точно так было лучше?
ИМХО, язык шейдеров в разы удобней C#, когда речь о векторных вычислениях, "формулы" получаются выразительными, да и работают с несравнимой скоростью.

Взять нормаль к поверхности, или банально ограничить RGB — на стороне C# это тяжелые вычисления, а на стороне шейдера, считай, бесплатные.


A>Без исходников Unity не могли бы, а кто с исходниками — тем не надо.


А что там требует исходников Unity?
Чем нынешний CommandBuffer хуже старого?


A>>>Можешь посмотреть репозиторий uGUI — он попроще: https://github.com/Unity-Technologies/uGUI

A>>>Выкинешь из Unity этот код, не будет игрового UI, будешь велосипедить сам.
V>>В приличных проектах всё-равно GUI свой.
A>В UE плохой игровой GUI, или "приличные" проекты не делают на UE?

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

Но так-то лейблы, кнопки, слайдеры, drag&drop, подвижные сплиттеры окошек и т.д. и т.п. — всё было написано с 0-ля.
Всё заточено на конкретную задачу, всё легковеснее — легковесней некуда.

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


A>>>Какой конкретно функциональности тебе не хватает? Прямого доступа к API DirectX/OpenGL/Vulcan/Metal/что там ещё есть...?

V>>Может не хватить любой функциональности, которая есть в этих низлежащих API.
A>Т.е. без конкретики.

А что тебе даст конкретика?
Ну вот я потрачу минут 20-40 на сравнение возможностей низжлежащей платформы и Unity, дам тебе некоторый список и что изменится? ))

Ты ведь и сам знаешь, что Unity не покрывает возможности последних графических библиотек.
Он работает на DirectX-11 и OpenGL 3.x, оба 12-летней давности.

Никакого DX-12 или Vulkan, или Metal на MacOS.
Мне точно надо делать сравнительный обзор этих технологий в сравнении с упомянутыми устаревшими?

UE поддерживает эти технологии еще с прошлой версии.
Re[18]: Unity
От: alexzzzz  
Дата: 07.08.21 19:03
Оценка: 3 (2)
Здравствуйте, vdimas, Вы писали:

V>Разумеется, в поставку Unity входит не только движок, еще ресурсы, примеры, несколько прикладных либ, как ты давал ссылки и даже собственный 3D-редактор.

V>Простой вопрос — является ли редактор Unity самым удобным для дизайна 3D-объектов?
...
V>Например, "построить" виртуальный дом или даже виртуальный город можно в десятки раз быстрее с помощью специального ПО, предназначенного для строительного дизайна.
V>Потому что ты затрахаешься делать это в редакторе Unity, там не сравнимая трудоёмкость.

Логично. Специализированное ПО на то и специализированное. Программирование, моделирование, скульптинг, текстурирование... делаются в предназначенном для этого ПО, а не в редакторе игрового движка. Редактор нужен, чтобы собрать это всё в единое целое.

V>Аналогично прикладные библиотеки в поставке — это всё не обязательно, т.е. не факт, что будет задействовано.

V>А вот без движка — никуда.
V>Неужели в этом контексте всё еще не понятно, что есть "движок", каковы его ф-ии?

Функции игрового движка:
— обеспечить простую удобную работу с графикой, звуком, физикой, анимацией...;
— абстрагировать разработчика от конечных платформ и конкретных устройств;
— обеспечить интеграцию со сторонним ПО и поддержку популярных форматов для импорта/экспорта ресурсов.

Чтобы разработчик игры занимался разработкой собственно игры, а не переизобретением велосипедов (в том числе разработкой с нуля подсистемы игрового GUI).

V>Но если, действительно, что-то предназначено для исполнения из под Mono, то код с плавающей точкой на C# сегодня выполняется до безобразия хреново.

V>А там столько вычислений сугубо для эффектов на стороне C#...
V>В этом сценарии уж лучше пользовать встроенное, параметризируя это всё шейдерами и графическими ресурсами.

Немного там вычислений, они же не попиксельные. Пикселями естественно всегда шейдеры занимаются.

V>Ну, я не настолько глубоко копал rendering pipeline, чтобы дать свою оценку.

V>А в чем было меньше гибкости для лично тебя, например?
V>Не было в наличии каких-то команд в CommandBuffer, которые появились сейчас?

Render Pipeline определяет логику: что, куда, какими шейдерами и в какой последовательности рендерится и как потом компонуется, чтобы получился финальный кадр.
Что-то типа такого (к Unity не имеет отношения) — https://habr.com/ru/company/ua-hosting/blog/271931/

У встроенного пайплайна есть разные настройки, есть точки расширения, куда можно приткнуть свой CommandBuffer или callback, но в общем логика что куда как рендерить более-менее фиксированная.

Scriptable Render Pipeline даёт возможность логику поменять как душе угодно. Переписать с нуля, модифицировать два идущих к комплекте пайплайна (Universal и High Definition) или просто использовать их вместо встроенного — они более гибкие изначально.

Очень отдалённая аналогия ― fixed-function programming model vs shader-based programming model.

Меня лично графика не особо занимает, достаточно и встроенного пайплайна. Доступ к низлежащим DirectX/... тоже не нужен.

V>Свой GUI, что тут сложного?

V>Могу кинуть в тебя проектом на плюсах поверх OpenGL, где свой GUI был разработан на коленке за пару вечеров.
V>Там отсутствует из популярного полноценный текстовый редактор, это да...
V>Просто не дошли руки взять любой готовый опенсорсный и портировать.
V>Но так-то лейблы, кнопки, слайдеры, drag&drop, подвижные сплиттеры окошек и т.д. и т.п. — всё было написано с 0-ля.
V>Всё заточено на конкретную задачу, всё легковеснее — легковесней некуда.

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

V>Ты ведь и сам знаешь, что Unity не покрывает возможности последних графических библиотек.

V>Он работает на DirectX-11 и OpenGL 3.x, оба 12-летней давности.
V>Никакого DX-12 или Vulkan, или Metal на MacOS.
V>Мне точно надо делать сравнительный обзор этих технологий в сравнении с упомянутыми устаревшими?
V>UE поддерживает эти технологии еще с прошлой версии.

Страничка из документации к Unity 2017.4:
https://docs.unity3d.com/2017.4/Documentation/Manual/GraphicsAPIs.html
Re[2]: Unity
От: romakoma Интернет  
Дата: 09.09.21 13:34
Оценка: :)
Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, mrTwister, Вы писали:


N>>>Ой, вот это умеет и реально используется — большая разница.

T>>По статистике на 2019 год, 52% мобильных игр из top-1000 сделаны на Unity, то есть C#.

N>Я слышал, что у самой Unity большие проблемы, а также, что игры, написанные с ней жрут ресурсы, как не в себе, а также долго работать не могут из-за багов (куча тем про поиск мемори ликов в Unity приложениях).

N>В свете того, что Амазон выпускает open-3d-engine, будущее Unity выглядит туманным.
N>Да, годится для задачи "быстро накидать несложную игру". Но из-за внутренних проблем её может постигнуть участь flash'а.
Мне кажется что большинству плевать на потребление ресурсов и время работы ведь железо (и пользователи) всё стерпит. Почему–то мало кого волнует жиреющий WWW и торомозящий JavaScript.
Re[5]: Unity
От: romakoma Интернет  
Дата: 09.09.21 13:41
Оценка:
Здравствуйте, mrTwister, Вы писали:

T>P.S.: ты не замечаешь, что реальность объективно отличается от твоей модели мира и ты вместо того, чтобы лучше понять реальность начинаешь хвататься за соломинки, чтобы как-то оживить модель мира. В реальности на Unity выходят одни из лучших игр мира (League of Legends например), под все платформы: Play Station, XBox, Ningendo, Android, IOS, Linix, Windows, macOS, но тем хуже для реальности, ведь в твоей модели мира такого не может быть потому что не может быть никогда, ведь C# не кроссплатформенный и ни для чего серьёзного подходить не может


„Лига легенд“ — мусор. Unity так популярен во многом из–за большого количества пролов знающих этот самый Unity. А так, то лучше бы его не было потому что оно жрёт много ресурсов.
Re[6]: Unity
От: alexzzzz  
Дата: 13.09.21 13:54
Оценка:
Здравствуйте, romakoma, Вы писали:

R>„Лига легенд“ — мусор. Unity так популярен во многом из–за большого количества пролов знающих этот самый Unity. А так, то лучше бы его не было потому что оно жрёт много ресурсов.


Твоя игра на Unity будет жрать столько ресурсов, сколько ты ей сам позволишь — на сколько хватит твоих знаний, времени и желания.
Re[2]: Unity
От: Тёмчик Австралия жж
Дата: 15.09.21 03:52
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N> долго работать не могут из-за багов (куча тем про поиск мемори ликов в Unity приложениях).


О да. Устранять утечки с GC языком- особый вид мазохизма, т.к. причины утечек неочевидны, любое невинное измененение кода может создать комбинацию, при которой потечёт. И потом только делать какие-то неочевидные модификации, перезапускать, проверять Heap snapshot, не помогло, тыкать что-то ещё, пересобирать, перезапускать, и так по кругу.
LIVE camera in Dee Why: http://www.coastalwatch.com/surf-cams-surf-reports/nsw/dee-why
Re[3]: Unity
От: alexzzzz  
Дата: 15.09.21 13:44
Оценка:
Здравствуйте, Тёмчик, Вы писали:

N>> долго работать не могут из-за багов (куча тем про поиск мемори ликов в Unity приложениях).


Тё>О да. Устранять утечки с GC языком- особый вид мазохизма, т.к. причины утечек неочевидны, любое невинное измененение кода может создать комбинацию, при которой потечёт. И потом только делать какие-то неочевидные модификации, перезапускать, проверять Heap snapshot, не помогло, тыкать что-то ещё, пересобирать, перезапускать, и так по кругу.


Жизнь — боль. Причины потенциальных утечек с GC очевидны — захватил неуправляемый ресурс и не освободил или подписался на что-то и потом не отписался. GC облегчает жизнь тем, что позволяет свалить на него грязную работу в других случаях.
Re[6]: Unity
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 15.09.21 14:30
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Да пусть выходят, я что против? Я приводил ссылку на блог одного из разработчиков Unity, который говорит о плачевной поддержке новых версий C#, что они задерживаются, что они сами поддерживают устаревший Mono. Я сам вижу проблемы с Mono, вижу как с него сползает контора. Эти факты ничем не противоречат тому, что говоришь ты. В своё время была гора написанных на flash мобильных играх. Он был самым популярным для разработки игр? Да, был. Он был установлен во всех браузерах? Да, был. Где он сейчас? Нет его. Если жить в твоём мире, то flash жив, так как на нём в каком-то году было написано много крутых игр.


Но при этом собираются
https://visualstudiomagazine.com/articles/2021/04/22/unity-plans.aspx

Добавить поддержку .NET Standard 2.1: это откроет запрашиваемые пользователем API, такие как Span и диапазоны. «Мы планируем сначала добавить поддержку .NET Standard 2.1 в существующую экосистему Unity на основе .NET Framework. Хотя .NET Framework не поддерживает .NET Standard 2.1, библиотеки классов Mono поддерживают его, поэтому мы должны иметь возможность предоставить хороший мост к экосистеме на основе .NET Core ".
Полная поддержка C # 8: это идет с вышеупомянутой поддержкой .NET Standard вместе с последним кодом Mono, который поддерживает методы интерфейса по умолчанию.
Полная поддержка C # 9: «Мы хотели бы иметь поддержку ковариантных возвращаемых типов в Mono и IL2CPP для Unity 2021.2. Это также обеспечит полную поддержку C # 9 для пользователей Unity».
Поддержка .NET 6: Петерсон описал это как «все еще немного нечеткое», и компания надеялась предоставить предварительную версию примерно в то время, когда знаковая, объединяющая, веха .NET 6 выйдет в ноябре в виде выпуска с долгосрочной поддержкой (LTS), это означает, что «Unity, скорее всего, полностью пропустит .NET 5». Он описал самые большие препятствия для этого как:
Это критическое изменение для всех пользователей Unity. Любые сборки, скомпилированные с использованием mscorlib.dll из экосистемы .NET Framework, не будут работать, и их необходимо перекомпилировать.
Экосистема .NET Core не поддерживает перезагрузку домена, что является фундаментальным требованием редактора Unity. Мы проделали работу по использованию контекста загрузки сборки, но это будет серьезное изменение, и потребуется время для правильной реализации как со стороны Unity, так и в пользовательских проектах.


Я думаю, что вам действительно нужно заняться интеграцией Visual Studio. Проекты Unity по-прежнему выглядят хитроумно и не являются настоящими файлами .csproj, и им не хватает таких функций, как ссылки на проекты, что действительно важно для некоторых проектов, таких как клиент-серверные игры, где требуется несколько проектов с общими проектами между ними. Я над чем-то работаю. Я был шокирован, узнав несколько месяцев назад, что ссылки на проекты не поддерживаются, и что мне пришлось добавить аргументы команды после сборки, чтобы скопировать сгенерированные файлы DLL в папку сценариев единства, чтобы использовать их, это просто немного хитро и удаляет такие функции, как отладка и возможность перейти к коду из общего проекта, поскольку в библиотеках DLL нет кода, метаданных.


Сейчас .Net 6 открытый код. Могут выбросить Mono и использовать .Net 6, а компилятор из Il у них есть, либо использовать моновкский который в Xamarrin
И максимально интегрировать со студией

Ну и можно последить за текущими движениями
https://forum.unity.com/threads/unity-future-net-development-status.1092205/page-7
и солнце б утром не вставало, когда бы не было меня
Отредактировано 15.09.2021 14:50 Serginio1 . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.