Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Unity (проблемы, решения, перспективы) (87 стр)

Unity (проблемы, решения, перспективы) (87 стр)

Страницы: 186 87 88 89113 Следующая »
MorphiaПостоялецwww18 янв. 20180:53#1290
Mira
делая ассинхронную загрузку файла ты хотел чтобы он грузился как мул по-частям ,но безпрерывно
и при этом нечто выполнялось в программе : типа поворот камеры

Mira
я уж и не знаю в обычной загрузке создается потоковый файл как файл-поток и по идее раз это поток и
он выделен как поток то он и работает как поток , то есть зачем ассинхронная загрузка тогда

Mira
ну уж если тебе так хочется отдельно управлять потоками или контролировать их
то наверняка желательно использовать джава-скрипт и на нем создавать steam shell (потоковую оболочку)
и значит по-мимо си-шарпа придется как-то синхронизироваться с джава-скриптом где-то в коде

Правка: 18 янв. 2018 0:56

CriDosПостоялецwww19 янв. 20184:58#1291
alexzzzz
Привет!:)
Я в своём проекте взял за основу Вашу старую версию хака C# 6-7.
Спасибо! Отличное решение, хотя и были проблемы.
Давно решил проблему со всеми версиями Unity (2017-2018), простым патчем метода CreateCompiler в рантайме с помощью 0Harmony.
Оказалось очень эффективным и стабильным решением:)
Вот так: https://0bin.net/paste/9SUqRVHQ5wS0zPKA#iUCCimIDZgD8Q72vq6dUZETRm… s7qmpU1gxIuYB
Жаль, что вы перешли к более радикальному способу интеграции Roslyn в среду юнити.
Там у Вас и плюшки уже есть в виде Net Standard 2.0...

> Кстати, никто ещё не тестировал IL2CPP под Windows на скорость? Есть хоть какие-то отличия?
Тестировал.
Работа с линейным массивом ushort примерно на 10-15% стала быстрее:)
А так, ОЗУ в половину меньше стал потреблять проект в рабочем состоянии, отзывчивость поднялась на тяжёлых тестах.
В общем, я в восторге.
Более плотно возьмусь за него, когда выйдет релиз 2018.1.

Правка: 19 янв. 2018 5:31

alexzzzzПостоялецwww19 янв. 201813:54#1292
CriDos
> Давно решил проблему со всеми версиями Unity (2017-2018), простым патчем метода
> CreateCompiler в рантайме с помощью 0Harmony.
> Оказалось очень эффективным и стабильным решением:)
> Вот так: https://0bin.net/paste/9SUqRVHQ5wS0zPKA#iUCCimIDZgD8Q72vq6dUZETRm…
> s7qmpU1gxIuYB
> Жаль, что вы перешли к более радикальному способу интеграции Roslyn в среду юнити.

Патчить файл UnityEditor.dll мне не хотелось, а то что можно патчить в рантайме, я даже не подозревал. Спасибо, попробую! Это конечно хуже, чем как раньше совсем без патчинга, но лучше, чем менять файлы внутри папки Unity и восстанавливать их после каждого обновления.

> Там у Вас и плюшки уже есть в виде Net Standard 2.0...
Честно говоря, Net Standard с виду вроде бы работает, но посильнее потестировать с пристрастием пока руки не дошли. VSTU ещё файлы .csproj для Net Standard генерирует через раз или, скорее, один раз из десяти, в зависимости от фазы Луны.

PS

Я правильно понял, что ты тоже изучал UnityEditor.dll в новых 2017 и 2018, тоже нашёл код, который создаёт/запускает компилятор, но тоже не нашёл, каким образом этот код теперь вызывается? Просто я думал, может, я слепой?

Правка: 19 янв. 2018 14:03

alexzzzzПостоялецwww19 янв. 201814:17#1293
CriDos
> Работа с линейным массивом ushort примерно на 10-15% стала быстрее:)
Это по сравнению с неоптимизированным C#, без указателей?

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

CriDosПостоялецwww19 янв. 201815:00#1294
alexzzzz
> Я правильно понял, что ты тоже изучал UnityEditor.dll в новых 2017 и 2018, тоже нашёл код, который создаёт/запускает компилятор, но тоже не нашёл, каким образом этот код теперь вызывается? Просто я думал, может, я слепой?
Да, правильно понял.
Я пытался одно время починить Вашу версию, когда у меня появилась Unity 2018.1b1... но не очень получилось.
Но моя версия с патчем практически сразу заработала после того, как внёс небольшое изменение связанное с getAdditionalReferences (добавил проверку версии Unity).
Вот моя последняя версия с небольшими изменения: https://yadi.sk/d/lDaHyAJ63RbaeF
Основные отличия:
В корне проекта папка CSharpCompilerWrapper (по названию можно понять что там), в ассетах в любом месте папка CSharpNextSupport с патчером и вашей подменой для проектных файлов (Unity.PureCSharpTests) + 0Harmony либа.
В общем, убрал версии из имён папок и привязку относительному расположению в ассетах, а то там уже и JetBrains с Rider плагином встроили проверку папок CSharp60Support и CSharp70Support в корне проекта, что вызвало у меня некоторые проблемы вначале и удивление в конце)
Строка 347: https://github.com/JetBrains/resharper-unity/blob/master/resharpe… tprocessor.cs

Правка: 19 янв. 2018 15:34

CriDosПостоялецwww19 янв. 201815:08#1295
alexzzzz
> Это по сравнению с неоптимизированным C#, без указателей?
Да, это без unsafe кода.
unsafe даже не пробовал, там и так много проблем с компиляцией относительно тяжёлых либ (protobuf, Mono.CSharp)...
alexzzzzПостоялецwww19 янв. 201816:07#1296
Эх, CSharp70Support. Я когда проверял работу C# 7 в Unity, он ещё не вышел официально, был в стадии превью, что-то там ещё менялось периодически. Поэтому решил положить компилятор 7.0 отдельно от стабильного компилятора 6.0 и назвал папку CSharp70Support. Не предполагал, что имя окажется принципиально, а C# начнёт штамповать минорные версии раз в полгода. Когда понял, что получилось как-то нехорошо, плагин к Райдеру уже успел завязаться на название папки. Они спрашивали как-то давно, как точно определить, какая версия C# используется в проекте, и я тогда ответил, не особо подумав, что это можно понять по наличию соответствующей папки. Надо с ними поговорить на эту тему, как лучше переделать.

Вообще, не разделяю это стремление что Райдера, что VSTU поставить ограничение на версию языка в .csproj файлах, типа чтобы пользователь не мог случайно использовать новые фичи языка, которые не скомпилируются в Unity. Я так полагаю, если человек по своей воле воткнул в проект поддержку более свежей версии языка, то он уж как-нибудь разбирается, что скомпилируется, а что нет. Сделали бы просто в своих настройках галочку ограничить версию языка типичной для Unity (по умолчанию), или не ограничивать вообще.

alexzzzzПостоялецwww20 янв. 201823:54#1297
Переделал интеграцию компилятора C# 7.2. Теперь используется Harmony и подменять файл компилятора не нужно. Проверил работу в Unity 2017.2.1p1, 2017.3.0p1, 2018.1.0b3 во всех комбинациях рантаймов и бекендов. В 2017.1 из-за устаревающего API есть две небольшие проблемы, при желании устранимые.

https://bitbucket.org/alexzzzz/unity-c-5.0-and-6.0-integration

CriDosПостоялецwww21 янв. 201811:33#1298
alexzzzz
> Переделал интеграцию компилятора C# 7.2. Теперь используется Harmony и
> подменять файл компилятора не нужно.
Оперативненько:)
Теперь будет гораздо удобней интегрировать решение.
MiraПостоялецwww22 янв. 201820:26#1299
обновил недавно на 2017.3
куда из класса делось DrawLine, LogException и прочие?
ппп | Unity (проблемы, решения, перспективы)
seamanПостоялецwww22 янв. 201821:37#1300
Вроде бы никуда.
+ Показать

2017.3.0f3
Он теперь в сборке UnityEngine.CoreModule.dll

Правка: 22 янв. 2018 21:38

MiraПостоялецwww22 янв. 201821:38#1301
не одного обновления без приколов -_-
как теперь починить Debug ? может реимпортировать что-то надо? (весь проект слишком долго)

такое ощущение что теперь он юзает неправильный Debug , не из этой dll

Правка: 22 янв. 2018 21:51

alexzzzzПостоялецwww22 янв. 201822:40#1302
Mira
> такое ощущение что теперь он юзает неправильный Debug , не из этой dll

Кто такой он? Ты вроде пока не сказал, что конкретно сломалось и что такое collada_exporter.dll.

PS
Чинить, скорее всего, так:

using Debug = UnityEngine.Debug;
но это я наобум.

Правка: 22 янв. 2018 22:42

MiraПостоялецwww22 янв. 201822:45#1303
alexzzzz
после обновления с первой версии Unity 2017 на 2017.3.0f3
сломался проект. стало писать что в различных файлах отсуствуют методы класса Debug (DrawXXX методы, и LogException)
alexzzzz
> collada_exporter.dll
не знаю что это и откуда взялось -_-
alexzzzzПостоялецwww22 янв. 201822:52#1304
Ищи эту гадину в проекте:
+ Показать

В ней класс под названием Debug объявлен вне своего пространства имён.

Страницы: 186 87 88 89113 Следующая »

/ Форум / Программирование игр / Общее

2001—2018 © GameDev.ru — Разработка игр