Про options.plist — TeamId не нужен, он берется из архива, а вот
<key>compileBitcode</key>
<false/>
сильно ускоряет подпись для dev-билдов.
Еще бы неплохо указать, что для сборки все-равно потребуется macos с xcode и установленными cli tools, а так же sshpass (через homebrew) если на sftp используются не ключи, а доступ по паролю.
Если используются нейтивные сдк, которые напрямую лезут к java и прочим штукам — скачиваемый jdk через unityhub не подойдет, т.к не прописаны в $PATH. Решение — прописывать их в $PATH перед запуском, либо поставить отдельно openjdk через homebrew. Второй способ удобнее, т.к юнити можно обновлять без проблем, а системный jdk останется и сам будет прописан в переменные окружения.
Вот класс из UIExtensions использовать нельзя, как и пример из статьи. Быстрее, чем сделано в нейтиве и через вызов одного метода в managed-коде нельзя, тем более с ручным перекидыванием меша в жирный и медленный uGui. Вот это https://github.com/mob-sakai/ParticleEffectForUGUI — обертка поверх нейтивного бейка партиклов в меш и самый быстрый вариант из всех, несмотря на такое себе качество кода в плане скорости.
Для начала можно пройтись по ссылкам, там есть тесты производительности. Ну и можно зайти с другой стороны — когда unity-ecs позволит передавать без адского бойлерплейта, занимающего треть кода, инстансы классов дальше для работы (после джобов и т.п) — вот тогда можно будет рассматривать ихнее поделие как рабочий вариант. Сейчас это — исключительно one-task-performance-only решение для ускорения одной задачи, из-за которой потом приходится страдать и выковыривать данные обратно из NativeArray и т.п. Все коммунити-проекты (тот же Entitas) являются multipurpose-решениями и позволяют строить всю архитектуру приложения на них.
Все реализации кроме нативной не дадут того прироста производительности, и по факту являются надстройкой над монобехом.
Очень смелое и абсолютно голословное утверждение. Мое поделие как и Entitas не имеет никаких зависимостей от юнити и может использоваться в .net core безо всяких монобехов, например, в серверной реализации или вообще сторонних проектах (например, мод кастомных ранений для gta5). И да, джобы делаются через штатный мультитред без проблем.
Есть много реализаций, в том числе и моя. Есть Entitas, Svelto, EgoEcs и т.п. Смысл в том, что в случае ecs размазывание обработки последовательно с пре/пост-процессингом получается просто и непринужденно, без использования ООП.
You may have heard about Microarchitectural Data Sampling (MDS) vulnerability — also referred to as ZombieLoad — a significant security vulnerability that affects cloud providers, including DigitalOcean. Left unmitigated, this vulnerability could allow sophisticated attackers to gain access to sensitive data, secrets, and credentials that could allow for privilege escalation and unauthorized access to user data.
Since learning of the vulnerability, our engineering team has been rapidly rolling out mitigations across our fleet. We also recommend taking steps to ensure your Droplet is up to date and secure. This is especially important if you are running multi-tenant applications or untrusted code inside your Droplet.
We’ll continue to keep you updated via our blog, but if there are any steps that you need to take — we’ll reach out directly via email with instructions.
Это «Subdivision surface» — модификатор, у которого есть параметры. А есть операция — «Subdivide», доступная по «W, Subdivide». Есть отдельная операция «W, Subdivide Smooth», она да, похожа на «Subdivision surface» и позволяющая сглаживать границы.
И где все это? :)
Про options.plist — TeamId не нужен, он берется из архива, а вот
сильно ускоряет подпись для dev-билдов.
Еще бы неплохо указать, что для сборки все-равно потребуется macos с xcode и установленными cli tools, а так же sshpass (через homebrew) если на sftp используются не ключи, а доступ по паролю.
Если используются нейтивные сдк, которые напрямую лезут к java и прочим штукам — скачиваемый jdk через unityhub не подойдет, т.к не прописаны в $PATH. Решение — прописывать их в $PATH перед запуском, либо поставить отдельно openjdk через homebrew. Второй способ удобнее, т.к юнити можно обновлять без проблем, а системный jdk останется и сам будет прописан в переменные окружения.
Чувствуешь как уходит потенциальный приз? :) Поздравляю с проходом в финал.
3072×1920, 226ppi
Вот класс из UIExtensions использовать нельзя, как и пример из статьи. Быстрее, чем сделано в нейтиве и через вызов одного метода в managed-коде нельзя, тем более с ручным перекидыванием меша в жирный и медленный uGui. Вот это https://github.com/mob-sakai/ParticleEffectForUGUI — обертка поверх нейтивного бейка партиклов в меш и самый быстрый вариант из всех, несмотря на такое себе качество кода в плане скорости.
А можно перестать наркоманить и использовать ParticleSystemRenderer.BakeMesh + внешнюю камеру для гуя.
https://yhatt.github.io/marp/
https://gitpitch.com/
https://remarkjs.com/
Миллион их, почему именно AsciiDoctor?
Там перекрытие в несколько лет между 1 и 2 картинкой (1981-1984).
Для начала можно пройтись по ссылкам, там есть тесты производительности. Ну и можно зайти с другой стороны — когда unity-ecs позволит передавать без адского бойлерплейта, занимающего треть кода, инстансы классов дальше для работы (после джобов и т.п) — вот тогда можно будет рассматривать ихнее поделие как рабочий вариант. Сейчас это — исключительно one-task-performance-only решение для ускорения одной задачи, из-за которой потом приходится страдать и выковыривать данные обратно из NativeArray и т.п. Все коммунити-проекты (тот же Entitas) являются multipurpose-решениями и позволяют строить всю архитектуру приложения на них.
Очень смелое и абсолютно голословное утверждение. Мое поделие как и Entitas не имеет никаких зависимостей от юнити и может использоваться в .net core безо всяких монобехов, например, в серверной реализации или вообще сторонних проектах (например, мод кастомных ранений для gta5). И да, джобы делаются через штатный мультитред без проблем.
Есть много реализаций, в том числе и моя. Есть Entitas, Svelto, EgoEcs и т.п. Смысл в том, что в случае ecs размазывание обработки последовательно с пре/пост-процессингом получается просто и непринужденно, без использования ООП.
А можно посмотреть в сторону ECS (не обязательно штатной реализации) и понять, что там это все реализуется даже проще.
FinalCutX 23k руб, LogicProX 15k руб — официальные цены в апсторе, далеко не четверть от цены.
15 мая пришло вот такое от DO:
Тогда рекомендую об этом поспорить с Джобсом, это не мои слова. Я пользовался как winmobile6, так и samsung note3 со стилусом.