Пользовался дома всеми клиентскими версиями Windows от 3.11 до 10, кроме 8 (из-за меню на весь экран). Ничего плохого про Висту не могу сказать. На машинах с 1 Гб памяти и кучей программ — да, грустно; но и на XP на них получше, не так чтобы очень весело. Дома у меня в то время был двухядерник с 2 или 4 Гб, и нормально всё работало, не хуже, чем до этого на XP.
Виста в своё время понравилась несколькими вещами:
1. Поиск в стартовом меню. Как только распробовал, убрал за ненадобностью все ярлыки программ с рабочего стола и превратил его именно в рабочий стол — место для хранения текущих рабочих файлов/документов.
2. Superfetch. Запуск постоянно используемых программ действительно стал происходить быстрее.
3. По сравнению с XP появилась некоторая лёгкая ватность управления, но оно стало более предсказуемым. На XP какие-то действия выполнялись мгновенно, а какие-то могли стопорить оболочку на несколько секунд или даже десятков секунд. В Висте некоторые ранее мгновенные действия могли выполняться с небольшой задержкой в десятые доли секунды, но зато она заметно реже тупила, а некоторые длительные I/O-операции стало можно легко отменять.
4. У меня тогда стоял какой-то Radeon (9600 или X800), и в игре SimCity 4 в Windows XP жутко тормозил скроллинг карты, если было включено отображение деревьев и использовался аппаратный рендеринг. Никакими тонкими настройками и перебором драйверов я эту проблему победить не мог. В Висте же всё решилось само собой, игра залетала как надо.
Или замедлить. Часто быстрее написать с нуля, чем исправлять смысл, терминологию, а потом ещё и выворачивать наизнанку каждое предложение, чтобы звучало по-человечески, а не как явный дословный перевод.
Я так понимаю, в среднесрочной перспективе будут существовать три платформы: .Net Framework для Windows, .Net Core для трёх основных платформ и Mono для всего.
Фишка .Net Framework ― богатство функционала.
Фишка Mono ― встраиваемость и работа на всём, что движется.
Фишка .Net Core ― автономность, платформа идёт вместе с приложением.
В краткосрочной перспективе Mono переходит со своего компилятора на Roslyn, и все три ветви унифицируют свои библиотеки под флагом .Net Standard.
Примерно так я себе это представляю, но могу ошибаться.
У меня изначальная задумка была не столько для отделения «core-кода» от «не-core-кода», а скорее для того, чтобы вынести код, который я использую в каждом проекте Unity, куда-нибудь в одно место. Чтобы не хранить в десяти Unity-проектах десять копий одних и тех же, но чуть-чуть отличающихся исходников; потому что со временем перестаёшь понимать, где лежит более свежая версия, где более старая, и чем они отличаются.
Пробовал заводить для такого кода отдельный проект и билдить его dll в папку Assets текущего проекта Unity, но это неудобно. Оказалось проще кидать в Unity-проект линк на общую папку. В неё же можно положить какие-нибудь общие часто используемые ассеты, типа текстур в сеточку, в шахматную клеточку, в сеточку с пронумерованными ячейками для отладки uv-координат у геометрии.
Тут конечно появляется вероятность сломать что-нибудь в старом проекте, внеся изменения в общий код. Но пока в Unity не появится родная поддержка чего-нибудь типа NuGet, я думаю, это будет наименьшим злом.
Вот только редактор имеет обыкновение пересоздавать файлы .sln и .csproj, поэтому добавить в решение отдельную сборку довольно сложно (хотя, вроде если сильно исхитриться, то можно), а значит скорее всего придется делать их вообще разными solution'ами, что слегка неудобно — одновременно редактировать и ядро и юнити логику не получится,
Я недавно придумал использовать для этого символические ссылки.
Создаёшь отдельный солюшен (CoreSolution) и проект (CoreProject) в Студии. Внутри CoreProject делаешь папочку Core и весь код хранишь в ней. А в проекте Unity в папку Assets кидаешь символическую ссылку на папку Core. В результате, писать и редактировать код можно и в CoreSolution, и в солюшене Unity, и даже одновременно.
Косяков такого подхода пока не заметил. Единственная неприятность ― если забыться и создать новый cs-файл в Unity внутри папки Core , то в CoreProject его потом надо будет добавлять вручную через Add -> Existing Item... Этот момент несколько раздражает.
Для удобной работы со ссылками есть расширение к Проводнику ― Shell Link Extension.
возможны проблемы с подключением какого-нибудь Vector2 от юнити в этот внешний проект (не проверял, т.ч. может быть тут проблем нет).
В этом плане всё нормально. UnityEngine.dll можно подключать к сторонним проектам и пользоваться всем его управляемым кодом. Правда, его там не особо много, в основном вектора и Mathf. Если нарвёшься на метод, который реализован в нативном коде, в худшем случае получишь исключение сразу в момент его вызова.
Искал, выбирал себе какой-нибудь 3D движок, среди прочих наткнулся на Unity 3.0. Потыкался пару часов и понял ― оно. Следующие два вечера потратил на чтение официального руководства, благо, в отличие от предыдущих движков, оно было и подробное. Прочитал его один раз от начала до конца: что легко шло, прочитал полностью: какие-то очень специфические вещи, типа шейдеров, просмотрел по-диагонали. Стало понятно, что вообще в Unity есть, зачем надо, как оно между собой сообщается и в какую сторону смотреть, когда понадобиться сделать ту или иную вещь.
Имхо, кроме родного руководства больше ничего не надо. Можно ещё посмотреть обучающие ролики на интересующую тему: https://unity3d.com/learn/tutorials Ко всяким левым «урокам» на Ютубе отношусь скептически.
Если выбирать для себя правило, как писать код так, чтобы минимизировать случаи, когда где-то что-то может случайно аллоцироваться, то правило «просто не использовать foreach» малоприменимо практически.
Stack, Queue, HashSet, Dictionary, LinkedList, ICollection, IDictionary, IEnumerable на for не переводятся, у них нет индексаторов. Можно перевести на while с использованием итератора, но получим тот же foreach. LinkedList разве что можно перевести на while без итератора, но у него и так нет проблем с foreach.
На цикл for можно перевести массивы (но у них нет проблем с foreach и никогда не было), List (но у него нет проблем с foreach) и IList ― вот он, единственный случай, где от for есть польза.
Т.е. выходит, что правило «не использовать foreach» существует ради одного единственного случая с IList, а в остальных случаях либо бессмысленно, либо малоприменимо.
Если аллокации почему-то важны, взамен предлагаю другое правило, ничуть не сложнее: «без особой на то причины не использовать коллекции-интерфейсы, а коллекциями-классами, напротив, пользоваться свободно».
Не удивляемся. Интерфейсы ― отличный архитектурный инструмент, но и щедрый источник боксинга, причём не только внутри foreach. Ничего специфичного для Unity.
Всегда верьте статьями с «полезными» советами. Не тратьте время на проверку, делайте в точности так, как советуют. Авторы статей ― умные люди, они знают всё о вашем проекте: целевую платформу, жанр, все потенциально узкие места. Они даже точно знаю версию Unity, которую вы используете.
Начиная с версии 5.5 в Unity используется компилятор C# из Mono 4.6. В нём нет бага с аллокациами в foreach из-за боксинга итераторов. Да и до версии 5.5, если этот баг действительно на что-то принципиально влиял, его, имхо, было проще обходить использованием для финальных билдов другого компилятора, чем переписыванием исходного код на for. Сейчас же тем, кто переписывал foreach на for, можно начинать переписывать обратно. :)
В контексте выполнения FixedUpdate свойство Time.deltaTime возвращает значение равное Time.fixedDeltaTime, так что разницы нет. Использовать везде Time.deltaTime рекомендуется просто для однообразия.
Любопытно. Классический способ (с выходом на орбиту, а потом по гомановской траектории) требует примерно 4300-4500 м/с, чтобы попасть в SOI Муны. А сколько нужно при такой траектории?
Unity требует покупки Pro лицензий, если годовой доход организации превышает $200k. Не знаю, как они проверяют и проверяют ли вообще, но смысл в том, что им не важно, чем занимается контора.
Контора может
делать продукты на Unity и продавать;
раздавать их даром, зарабатывая на рекламе или поддержке;
использовать Unity для каких-то внутренних целей (обучение сотрудников, хз);
жить пожертвования пользователей или получать деньги из гос. бюджета.
Вообще не важно, откуда берутся деньги, но если откуда-то всё-таки берутся, изволь купить лицензии.
Валяется 150k урана-235, не знаю, куда деть.
Виста в своё время понравилась несколькими вещами:
1. Поиск в стартовом меню. Как только распробовал, убрал за ненадобностью все ярлыки программ с рабочего стола и превратил его именно в рабочий стол — место для хранения текущих рабочих файлов/документов.
2. Superfetch. Запуск постоянно используемых программ действительно стал происходить быстрее.
3. По сравнению с XP появилась некоторая лёгкая ватность управления, но оно стало более предсказуемым. На XP какие-то действия выполнялись мгновенно, а какие-то могли стопорить оболочку на несколько секунд или даже десятков секунд. В Висте некоторые ранее мгновенные действия могли выполняться с небольшой задержкой в десятые доли секунды, но зато она заметно реже тупила, а некоторые длительные I/O-операции стало можно легко отменять.
4. У меня тогда стоял какой-то Radeon (9600 или X800), и в игре SimCity 4 в Windows XP жутко тормозил скроллинг карты, если было включено отображение деревьев и использовался аппаратный рендеринг. Никакими тонкими настройками и перебором драйверов я эту проблему победить не мог. В Висте же всё решилось само собой, игра залетала как надо.
Я так понимаю, в среднесрочной перспективе будут существовать три платформы: .Net Framework для Windows, .Net Core для трёх основных платформ и Mono для всего.
Фишка .Net Framework ― богатство функционала.
Фишка Mono ― встраиваемость и работа на всём, что движется.
Фишка .Net Core ― автономность, платформа идёт вместе с приложением.
В краткосрочной перспективе Mono переходит со своего компилятора на Roslyn, и все три ветви унифицируют свои библиотеки под флагом .Net Standard.
Примерно так я себе это представляю, но могу ошибаться.
Решарпер не так давно начал понимать туплы. Теперь можно жить ещё веселее и потихоньку начинать применять C# 7. Правда всерьёз только на Windows.
3) На дворе Unity 5.5 и другой компилятор C#. Он в foreach на списках не аллоцирует.
К тому же, раз ядро в статье пишется в отдельном проекте вне Unity, то и компилируется оно, скорее всего, тоже вне Unity.
У меня изначальная задумка была не столько для отделения «core-кода» от «не-core-кода», а скорее для того, чтобы вынести код, который я использую в каждом проекте Unity, куда-нибудь в одно место. Чтобы не хранить в десяти Unity-проектах десять копий одних и тех же, но чуть-чуть отличающихся исходников; потому что со временем перестаёшь понимать, где лежит более свежая версия, где более старая, и чем они отличаются.
Пробовал заводить для такого кода отдельный проект и билдить его dll в папку Assets текущего проекта Unity, но это неудобно. Оказалось проще кидать в Unity-проект линк на общую папку. В неё же можно положить какие-нибудь общие часто используемые ассеты, типа текстур в сеточку, в шахматную клеточку, в сеточку с пронумерованными ячейками для отладки uv-координат у геометрии.
Тут конечно появляется вероятность сломать что-нибудь в старом проекте, внеся изменения в общий код. Но пока в Unity не появится родная поддержка чего-нибудь типа NuGet, я думаю, это будет наименьшим злом.
Я недавно придумал использовать для этого символические ссылки.
Создаёшь отдельный солюшен (CoreSolution) и проект (CoreProject) в Студии. Внутри CoreProject делаешь папочку Core и весь код хранишь в ней. А в проекте Unity в папку Assets кидаешь символическую ссылку на папку Core. В результате, писать и редактировать код можно и в CoreSolution, и в солюшене Unity, и даже одновременно.
Косяков такого подхода пока не заметил. Единственная неприятность ― если забыться и создать новый cs-файл в Unity внутри папки Core , то в CoreProject его потом надо будет добавлять вручную через Add -> Existing Item... Этот момент несколько раздражает.
Для удобной работы со ссылками есть расширение к Проводнику ― Shell Link Extension.
В этом плане всё нормально. UnityEngine.dll можно подключать к сторонним проектам и пользоваться всем его управляемым кодом. Правда, его там не особо много, в основном вектора и Mathf. Если нарвёшься на метод, который реализован в нативном коде, в худшем случае получишь исключение сразу в момент его вызова.
«Трёхмерный блестящий тетрис» за выходные написать можно. Готовую к выпуску в мир игру вряд ли, а рабочий прототип вполне.
Мне в своё время хватило родного руководства: https://docs.unity3d.com/Manual/index.html
Искал, выбирал себе какой-нибудь 3D движок, среди прочих наткнулся на Unity 3.0. Потыкался пару часов и понял ― оно. Следующие два вечера потратил на чтение официального руководства, благо, в отличие от предыдущих движков, оно было и подробное. Прочитал его один раз от начала до конца: что легко шло, прочитал полностью: какие-то очень специфические вещи, типа шейдеров, просмотрел по-диагонали. Стало понятно, что вообще в Unity есть, зачем надо, как оно между собой сообщается и в какую сторону смотреть, когда понадобиться сделать ту или иную вещь.
Имхо, кроме родного руководства больше ничего не надо. Можно ещё посмотреть обучающие ролики на интересующую тему: https://unity3d.com/learn/tutorials Ко всяким левым «урокам» на Ютубе отношусь скептически.
Если выбирать для себя правило, как писать код так, чтобы минимизировать случаи, когда где-то что-то может случайно аллоцироваться, то правило «просто не использовать foreach» малоприменимо практически.
Stack, Queue, HashSet, Dictionary, LinkedList, ICollection, IDictionary, IEnumerable на for не переводятся, у них нет индексаторов. Можно перевести на while с использованием итератора, но получим тот же foreach. LinkedList разве что можно перевести на while без итератора, но у него и так нет проблем с foreach.
На цикл for можно перевести массивы (но у них нет проблем с foreach и никогда не было), List (но у него нет проблем с foreach) и IList ― вот он, единственный случай, где от for есть польза.
Т.е. выходит, что правило «не использовать foreach» существует ради одного единственного случая с IList, а в остальных случаях либо бессмысленно, либо малоприменимо.
Если аллокации почему-то важны, взамен предлагаю другое правило, ничуть не сложнее: «без особой на то причины не использовать коллекции-интерфейсы, а коллекциями-классами, напротив, пользоваться свободно».
Не удивляемся. Интерфейсы ― отличный архитектурный инструмент, но и щедрый источник боксинга, причём не только внутри foreach. Ничего специфичного для Unity.
IList, ICollection, IEnumerable, IDictionary аллоцируют энумератор; List, HashSet, Queue, Stack, Dictionary ― нет.
Мой вредный совет:
Всегда верьте статьями с «полезными» советами. Не тратьте время на проверку, делайте в точности так, как советуют. Авторы статей ― умные люди, они знают всё о вашем проекте: целевую платформу, жанр, все потенциально узкие места. Они даже точно знаю версию Unity, которую вы используете.
Начиная с версии 5.5 в Unity используется компилятор C# из Mono 4.6. В нём нет бага с аллокациами в foreach из-за боксинга итераторов. Да и до версии 5.5, если этот баг действительно на что-то принципиально влиял, его, имхо, было проще обходить использованием для финальных билдов другого компилятора, чем переписыванием исходного код на for. Сейчас же тем, кто переписывал foreach на for, можно начинать переписывать обратно. :)
В контексте выполнения FixedUpdate свойство Time.deltaTime возвращает значение равное Time.fixedDeltaTime, так что разницы нет. Использовать везде Time.deltaTime рекомендуется просто для однообразия.
Как вы мягко перевели. :)
Unity требует покупки Pro лицензий, если годовой доход организации превышает $200k. Не знаю, как они проверяют и проверяют ли вообще, но смысл в том, что им не важно, чем занимается контора.
Контора может
Вообще не важно, откуда берутся деньги, но если откуда-то всё-таки берутся, изволь купить лицензии.
Тоже не угадал. Там ведь латинским по синему написано: Windows NT 3.1.
Всех веб-разработчиков нужно обязать раз в день заходить на сайт библиотеки Максима Мошкова.