Олег Мекекечко natexriver

Привет! Спасибо за отзыв) Жаль, на UWP пока не удается обновить)

Привет! Недавно сделали перевод Unity приложения на Hindi, у нас таблица хранится в Google Sheets. Просто добавили ее в проект, и индус подтвердил, что все супер. Вероятно, Google Sheets все эти конверсии делает при письме, а Unity уже поддерживает все символы из коробки.

Каждый охотник желает знать, где сидит фазан. Аналитика — важный инструмент разработки. Ей и нужны такие разрешения.

Так и есть. Будешь эффективно работать, рано уходить и гонять чаи, посчитают бездельником. А прикинешься дурачком, авось и не тронут.

Все это очень относительно. Я разве написал, что бездельничал? А вы уже свои выводы сделали. Впрочем, малоинтересные.

Это очень большая компания. Ничего с ней не случилось. Я думаю, что негативные последствия таких менеджеров (на компанию в целом) в статье сильно преувеличены. Не такие уж дураки те, кто их нанимает.

Сталкивался с таким в самом начале карьеры. Компания была довольна крупная, но называть я ее не буду. Дружно жили не тужили своим отделом. Делали свое дело, был адекватный начальник, пятничные вечерушки с пиццей, тимбилдинги, гибкий график, печеньки, попугайчик в офисе и все такое. В какой-то момент в компанию приезжает топ-менеджер, да непростой, заграничный. Начинает всех ругать, все плохо работают, неэффективно, бездельники. Начальника нашего (к слову, из рабочей среды) от реальной власти отстранили. Все, теперь у нас новый менеджер — молодая девочка, которая вообще не в теме. Но знает, как сделать круто. Появляются мудреные метрики. Появляется матрица ресурсов, т.е. тебя начинают разрывать на части между кучей проектов, чтобы ты не «простаивал». Тебя так и называют — ресурс. Тебя можно зарезервировать, использовать, заменить или освободить. Премии и тимбилдинги уже не даются и не проводятся за просто так, а только по результатам метрик. Гибкий график больше не гибкий, ибо ты не должен спать, когда другие работают, и наоборот. Старожилы и самые шарящие спецы постепенно уходят в другие компании. Зато приходит много новых людей. У менеджера появляется заместитель, который курирует проекты. Турникеты начинают измерять время, проведенное в туалете. Появляются регулярные митинги, на которых ты должен доказать, что ты не бездельник. Премии начинают резать за любые проступки. Затем каждый день заставляют писать отчет о проделанной работе. Не сказать, что все это происходит мгновенно. В моем случае прошло около года, ну а потом я сменил работодателя.

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

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

Есть и другая точка зрения. Если приложение или игра того стоит — то буду жаловаться. А если нет, то оптимизация не поможет.

Кроме того, аналитику и Performance Reporting никто не отменял.

Ох, внешние параметры для игры — это отдельная тема. Но Unity работают над этим, может что-то и выйдет в ближайшее время.

Я человек простой. Если пользователи жалуются на тормоза — я буду искать причину. В остальное время я нацелен на конечный результат. В процессе работы меня мало интересуют нюансы реализации локализации и специфика работы uGUI. Главное, чтобы заработало побыстрее. Все эти паттерны, рефакторинги и оптимизация — кому они нужны, если проект не зашел? Да, есть и такие, кто считает, что в паттернах и всяких крутых вещах, вроде gettext, и есть суть разработки. Их право.

Видел и статьи, и гитхабы. Но хочется же ничего не делать, чтобы оп — и готово. Пришлось делать самому.

immaculate про хорошую вещь говорит, тут вопрос целесообразности и применимости.

Excel и Google Sheet экранируют такие ячейки в кавычки.

Да, только кавычки остаются. Но код открытый, простой и будет только рад допиливанию)

Кстати, переносы строк экранируются двойными кавычками при скачивании CSV. Так что проблем не будет. Главное, чтобы парсер корректно это прочитал. Мой парсер такое обрабатывает, но оставляет кавычки. Исправлю как нибудь)

У меня не было проблем с ними. Ведь служебные символы так и переезжают в локализацию, где их рендерит компонент Text.

Ну есть же всякие ContentSizeFitter и HorizontalLayoutGroup. Хотя я обычно просто устанавливаю динамичный размер текста, чтобы он вписывался в размер элемента.

Стоит также учесть специфику разработки. Если вы начинающий инди-разработчик, который пришел к Unity именно из-за низкого порога входа и C#, то вряд ли вам нужно все то, о чем вы рассказываете. Мне, например, определенно хватает и CSV.

Увы, мне об этом не известно. Вот официальный гайд на эту тему: unity3d.com/ru/learn/tutorials/topics/scripting/localization-manager

Ну, первое, почему стоит выбрать Unity — это низкий порог входа (C# в сравнении с C++) и скорость разработки. В большинстве случаев аспекты производительности не имеют определяющего значения. Да, С++ быстрее. А ассемблер еще быстрее.

Вообще и Unity жрет, и поверхностное знание программирования тоже часто становится причиной тормозов. Нагрузку «размазывать» действительно приходится. Для этого в Unity есть Coroutines. Хотя многие считают, что Coroutines это потоки. Есть в Unity и настоящие потоки, для работы с которыми нужны дополнительные навыки, которые есть далеко не у всех разработчиков игр вроде меня)

Привет! Моя статья не предполагает холивары на эту тему. Если мы говорим, что Unity работает медленно, то разбираемся, почему. Нашли 2 проблемы: в моей библиотеке и в реализации LINQ в Unity. Говорить, что игры на Unity тормозят или что в Unity плохая графика, по моему, довольно безосновательно.

Проверил, результат тот же. Я полагаю, что компиляция консольного приложения и Unity приложения происходят одинаково.

Нет, но проверю, спасибо!

Спасибо за готовность помочь! Источников проблем оказалось 2:

1. строковый ключ в алгоритме сжатия LZW, заменил
next = code + " " + colorIndexes[i];
на
next = 257 * (code + 1) + colorIndexes[i];

2. использование LINQ для больших коллекций. Похоже действительно, у сборщика мусора появляется много работы после реализации LINQ в Unity. Убрал LINQ где это было уместно.

Проблем с потоками в Unity нет, все работает как и в консольном приложении.

Действительно, IndexOf работает быстрее LINQ в 7 раз в моем случае. Что ж, придется выпиливать LINQ из библиотеки GIF)

Похоже дело действительно в особенностях Garbage Collector в Unity, ведь LINQ генерирует много мусора. А я очень люблю LINQ. Придется посидеть над этим с профайлером.

Выходит, такие задачи средствами Unity выполнить не получится? Только системные вызовы?

Написал в UPD статье простой сценарий. Что думаете по этому поводу?

Спасибо, уже сделал ключ long, стало немного быстрее. Но проблема лагов в Unity не исчезла. Написал в UPD статье простой сценарий, который это подтверждает. Что думаете по этому поводу?

Решил отделить мухи от котлет. Многопоточность и моя реализация — это второй вопрос. Взял базовую алгоритмическую операцию — сжатие массива целых чисел алгоритмом LZW.
Реализация: github.com/hippogamesunity/SimpleGif/blob/master/SimpleGif/GifCore/LzwEncoder.cs

В консольном приложении на тестовом массиве эта операция выполняется за 18 ms. В Unity она же выполняется за 380 ms.

Скриншот профайлера по этой операции: yadi.sk/i/dMwQV18X3YgDhy

Выходит, что базовая операция вроде проверки ключа в словаре выполняется в Unity в 20 раз медленнее.

Похожая проблема: answers.unity.com/questions/325710/dll-call-10x-slower-in-unity.html

В Unity я так же вижу все 16 потоков. Только выполняются они гораздо медленнее.

Я извиняюсь, но опыта программирования потоков у меня нет) Поэтому благодарен за любые замечания. Если придраться, то как стоит написать?
Почему потоки висят в блокировках, если в lock расположены только присвоения, там нет никаких вычислений?
Кроме того, это не дает ответа на вопрос, почему этот же код в Unity работает в 20 раз медленнее)