немного не по теме статьи, но папку Resources лучше не использовать вообще. Мало того, что оно плохо контролируема, и туда вероятно попадает много лишнего, так и при большом количестве файлов замедляется запуск приложения, из-за индексации всего содержимого. После появления Addressables стало намного проще организовывать локально подгружаемые ресурсы, и к тому же в любой момент можно все перенести на CDN без переработки кода. В конце концов, можно и бандлами ограничиться, если захочется чуть производительности сэкономить и отказаться от Addressables
Вообще, в контексте "Размера билда Юнити", хотелось увидеть что-то более неожиданное, как например уменьшение размера даже пустого билда, путем пересмотра содержимого PackageManager, или еще каких-нибудь грязных трюков :)
что-то мне думается, что вы не правы насчет того, что если анимации лежат по разным fbx, то это увеличит размер билда. Не fbx ведь в билд попадает, а импортированные Юнити и конвертированные бинарные данные из него - отдельно меши и анимации, в зависимости от того что вы используете в сценах/префабах. Из FBX с анимацией в билд попадут только анимационные клипы, на которые будет ссылаться ваш Animator/Animation.
Если я буду вращать ручку яркости своего светильника с постоянной скоростью, я ожидаю такое же изменение и яркости (в моих глазах, а не на графике прибора)
Тогда может подскажете алгоритм гамма коррекции на пассивных элементах?
Я понимаю, что воспроизвести линейную яркость (да, именно речь про человеческий глаз, а не показания приборов) проще и может даже дешевле на тиньке какой сделать, но вот просто любопытно, насколько это реально. А поскольку мои знания в электронике ограничиваются повторением готовых схем, давно ищу людей понимающих, которые возможно задавались таким же вопросом))
давно ищу схему без использования всяких ардуин с реализацией линейного изменения яркости, ну или хотя бы близко к нему... Но пока линейно меняется либо скважность, либо ток, но не яркость ;(
конечно с МК проще и в современных реалиях может даже правильнее (по соотношению цена-трудозатраты), но несомненно варианты решения без МК заслуживают отдельного уважения. Думаю это сродни MP3 vs vinyl - оба имеют право на жизнь
Подумал, что Сити-17 с Цитаделью могли быть вдохновлены городом Сопота.
Могу ошибаться, но вроде цитадель была вдохновлена "Темной Башней" Стивена Кинга, как и сама игра (тут уже не могу ошибаться) - "Мглой" того же автора.
А как долго у вас собираются билды и как долго ранятся автотесты? Потому что процесс прям как у нас, но у нас проблема с тем что долго ПРы заезжают. Билд может собираться час, тесты могут каких полчаса бежать, потом еще мануальное тестирование в ветке ПРа (заафекченного функционала) пройдет - а там уже глядишь и девелоп пару раз обновился, а замерджиться можно только если разница между веткой и девелопом (по количеству коммитов в девелоп) должна быть минимальной. И погнали по новой - билд, автотесты (которые еще и флаки порой бывают). Еще и вручную нельзя завозить ПРы - все делает бот, который для скорости собирает несколько ПРов в батч, и если один из них в чем-то зафейлится - весь батч будет пересобиратья и ждать. В итоге среднее время заезда ПРа - неделя после его создания. И несмотря на всю хитрую схему все равно случается что девелоп ломается - тесты ведь не на весь код запускаются, а только на изменения, иначе отрабатывали бы несколько часов, да и автомерджилка может пошалить на мердже юнитевских ямл файлов, когда автоматически разруливает конфликты.
Причем, на прошлом проекте тестирование у нас проводилось только вручную и только в девелопе, и стабильность последнего была не сильно хуже ( у нас автотестов и в помине не было - только на сервере). Так что придя на проект, сразу возник вопрос - а стоит ли игра свеч, если итоговая стабильность не 100%?
ну, смотрю у вас схема похожая, так что может такова наша се ля ви - страдать )
Больная тема для нас, и хоть у нас Юнити, а не Анрил - думаю все равно окажется в рамках этой статьи.
Какие у вас условия для заезда ПРа в девелоп (или мастер, смотря какая ветка у вас считается стабильной)? Помимо апрувов от лидов и прочих заинтересованных? Гоняете ли вы для каждого ПРа тесты, в том числе мануальные, собираете ли билд чтобы выявить ошибки компиляции и в целом не сломалась ли сборка.
А после вливания ПРа в стабильную ветку - делаете ли повторные тесты, чтобы убедиться что после мерджа не сломалось ничего нового? :)
управление надо инвертировать. Если вы делаете движение камеры через клик+драг, то должно быть все наоборот, будто вы тянете за экран. Если бы вы спрятали курсор и кликать не нужно было - тогда да, все верно
У меня как-то была OUYA, и главный недостаток что у я нее нашел... нет, не железо или софт... то что она легкая, и веса приставки не хватает, чтобы уверенно сопротивляться пружинистости не самого тонкого HDMI кабеля XD
Как сделать билд минимального размера в Unity?
немного не по теме статьи, но папку Resources лучше не использовать вообще. Мало того, что оно плохо контролируема, и туда вероятно попадает много лишнего, так и при большом количестве файлов замедляется запуск приложения, из-за индексации всего содержимого. После появления Addressables стало намного проще организовывать локально подгружаемые ресурсы, и к тому же в любой момент можно все перенести на CDN без переработки кода. В конце концов, можно и бандлами ограничиться, если захочется чуть производительности сэкономить и отказаться от Addressables
Как сделать билд минимального размера в Unity?
Вообще, в контексте "Размера билда Юнити", хотелось увидеть что-то более неожиданное, как например уменьшение размера даже пустого билда, путем пересмотра содержимого PackageManager, или еще каких-нибудь грязных трюков :)
Как сделать билд минимального размера в Unity?
что-то мне думается, что вы не правы насчет того, что если анимации лежат по разным fbx, то это увеличит размер билда. Не fbx ведь в билд попадает, а импортированные Юнити и конвертированные бинарные данные из него - отдельно меши и анимации, в зависимости от того что вы используете в сценах/префабах. Из FBX с анимацией в билд попадут только анимационные клипы, на которые будет ссылаться ваш Animator/Animation.
Повышающий драйвер светодиода с плавной регулировкой яркости
вот, если не сочтут за рекламу, инженер Яндекс станции как раз рассказывает как добивался плавного изменения яркости светодиода:
Видео с YouTube
Повышающий драйвер светодиода с плавной регулировкой яркости
Это наверно самый очевидный и верный подход :)
Повышающий драйвер светодиода с плавной регулировкой яркости
Если я буду вращать ручку яркости своего светильника с постоянной скоростью, я ожидаю такое же изменение и яркости (в моих глазах, а не на графике прибора)
Повышающий драйвер светодиода с плавной регулировкой яркости
Я под яркостью понимаю то что под яркостью понимает среднестатистический пользователь)
Повышающий драйвер светодиода с плавной регулировкой яркости
Тогда может подскажете алгоритм гамма коррекции на пассивных элементах?
Я понимаю, что воспроизвести линейную яркость (да, именно речь про человеческий глаз, а не показания приборов) проще и может даже дешевле на тиньке какой сделать, но вот просто любопытно, насколько это реально. А поскольку мои знания в электронике ограничиваются повторением готовых схем, давно ищу людей понимающих, которые возможно задавались таким же вопросом))
Повышающий драйвер светодиода с плавной регулировкой яркости
давно ищу схему без использования всяких ардуин с реализацией линейного изменения яркости, ну или хотя бы близко к нему... Но пока линейно меняется либо скважность, либо ток, но не яркость ;(
Велосипедный фонарь с динамическими поворотами. Зачем покупать на AliExpress, если можно сделать самому?
конечно с МК проще и в современных реалиях может даже правильнее (по соотношению цена-трудозатраты), но несомненно варианты решения без МК заслуживают отдельного уважения. Думаю это сродни MP3 vs vinyl - оба имеют право на жизнь
Red Faction 2 (2002)
Могу ошибаться, но вроде цитадель была вдохновлена "Темной Башней" Стивена Кинга, как и сама игра (тут уже не могу ошибаться) - "Мглой" того же автора.
Игрушечный ЯП — Cockroach
У нас на "Немигах" стояла "Черепашка". Там похожий синтаксис был - "пока справа стена - вверх"
Какие технологии, процессы и решения мы используем при разработке на Unreal Engine 4 — опыт Allods Team
Спасибо за такой развернутый ответ!
А как долго у вас собираются билды и как долго ранятся автотесты? Потому что процесс прям как у нас, но у нас проблема с тем что долго ПРы заезжают. Билд может собираться час, тесты могут каких полчаса бежать, потом еще мануальное тестирование в ветке ПРа (заафекченного функционала) пройдет - а там уже глядишь и девелоп пару раз обновился, а замерджиться можно только если разница между веткой и девелопом (по количеству коммитов в девелоп) должна быть минимальной. И погнали по новой - билд, автотесты (которые еще и флаки порой бывают). Еще и вручную нельзя завозить ПРы - все делает бот, который для скорости собирает несколько ПРов в батч, и если один из них в чем-то зафейлится - весь батч будет пересобиратья и ждать. В итоге среднее время заезда ПРа - неделя после его создания. И несмотря на всю хитрую схему все равно случается что девелоп ломается - тесты ведь не на весь код запускаются, а только на изменения, иначе отрабатывали бы несколько часов, да и автомерджилка может пошалить на мердже юнитевских ямл файлов, когда автоматически разруливает конфликты.
Причем, на прошлом проекте тестирование у нас проводилось только вручную и только в девелопе, и стабильность последнего была не сильно хуже ( у нас автотестов и в помине не было - только на сервере). Так что придя на проект, сразу возник вопрос - а стоит ли игра свеч, если итоговая стабильность не 100%?
ну, смотрю у вас схема похожая, так что может такова наша се ля ви - страдать )
Какие технологии, процессы и решения мы используем при разработке на Unreal Engine 4 — опыт Allods Team
Больная тема для нас, и хоть у нас Юнити, а не Анрил - думаю все равно окажется в рамках этой статьи.
Какие у вас условия для заезда ПРа в девелоп (или мастер, смотря какая ветка у вас считается стабильной)? Помимо апрувов от лидов и прочих заинтересованных? Гоняете ли вы для каждого ПРа тесты, в том числе мануальные, собираете ли билд чтобы выявить ошибки компиляции и в целом не сломалась ли сборка.
А после вливания ПРа в стабильную ветку - делаете ли повторные тесты, чтобы убедиться что после мерджа не сломалось ничего нового? :)
Таксофон — это единственный выход из «Матрицы»
Хотел выйти из матрицы, а позвонил Кузе!
Браузерная игра про пиратов
управление надо инвертировать. Если вы делаете движение камеры через клик+драг, то должно быть все наоборот, будто вы тянете за экран. Если бы вы спрятали курсор и кликать не нужно было - тогда да, все верно
Что внутри карманного компьютера Maibenben? Разборка микрокомпьютера PCJ4, который помещается на ладони
Так проблема не техническая, а психологическая, что ли... Если шевеление провода валит устройство на бок, создается ощущение его несерьезности :)
Что внутри карманного компьютера Maibenben? Разборка микрокомпьютера PCJ4, который помещается на ладони
У меня как-то была OUYA, и главный недостаток что у я нее нашел... нет, не железо или софт... то что она легкая, и веса приставки не хватает, чтобы уверенно сопротивляться пружинистости не самого тонкого HDMI кабеля XD
Как предсказать настроение женщины или зачем нам статистика. Часть 1
до конца все дочитают, как раз чтобы увидеть основные выводы, пропустив промежуточные :)
Принципы домашнего танкостроения
капец аж мурашки по спине от этих схем...