Pull to refresh

Comments 43

2D это здорово, но лучше бы сделали поддержку Linux.
Во-первых, — чем лучше?
Во-вторых, — поддержка Линукса уже сто лет как есть, о чем вы?
Это тем более странно, что редактор есть под винду и макось, т.е. по логике, он уже должен быть кроссплатформенным.
Определенные наработки по запуску редактора Юнити у нас есть. Другое дело — сделать линукс-порт коммерческого качества.
Поддерживать продукт такого высокого качества сразу на трех платформах, одна из которых (линух) еще и нехило фрагментирована — очень дорого. Мне кажется, разрабам и двух платформ хватает с их прибамбасами и причудами.
Да и сам рынок ПК с линуксом мал по сравнению даже с рынком OSX…
Да Вы что? Я вот только что зашёл на Kongregate, открыл первую попавшуюся игру на Unity3D, согласился скачать плагин, и получил:
The Unity Web Player is not currently compatible with the operating system that you appear to be using.
ЧЯДНТ?

P.S. В репозитории Gentoo никакого unity тоже нет.
На этой страничке они обнадёживают разработчиков игр, что, возможно, если звёзды станут в ряд, то их игры будут достаточно мультиплатформенными чтобы работать в убунту. Это радует, но я не разработчик игр, я пользователь, и я всё ещё не вижу каким образом мне запускать игры, разработанные на Unity3D, под линухом, хотя бы и убунту.
Вот только веб-плеера под линух так и нету, насколько я помню.
Лучше бы сделали нормальную работу с ресурсами.
Давайте поговорим об этом :)
Давайте. На мобильных устройствах размер получается огромный, в основном за счёт текстур (большой размер приложения — первый кандидат на удаление). Текстуры занимают 95% приложения, практически не сжимаются (2048*2048 — 16 мб), сжатия дают артефакты. В общем, использовать родные форматы текстур очень накладно. Если использовать JPEG (в Resources) — надо переименовывать в bytes, причём он зараза всё равно видит что это текстура, и воспринимает её как текстуру. Нужны танцы с бубном. То же самое с другими форматами.
В общем, хотелось бы более открытый доступ, куда складываешь текстуры и другие ресурсы, и грузишь спокойно (как сейчас это StreamingAssets, кроме Андройда). В идеале чтобы движок видел зип-архивы, и из них доставал файлы, причём обращаешься как к обычный файлам, и он их видит. Мы предыдущий проект делали на неоаксисе, там так сделано, очень удобно. Легко что-то менять, патчи делать, и т. п.
И по отладке идейка: Было бы здорово сделать в профайлере движка консоль, куда приходили бы все сообщения из Debug.Log(), чтобы можно было легко их читать при отладке. Ну и текстбоксик там, чтобы можно было отсылать команды на девайс.
Для зип-архивов имеются ассет-бандлы. Если мне не изменяет память — компрессия lzma.
Ассет-бандлы при этом могут вполне себе валяться в StreamingAssets И никому не мешать.
Текстуры в jpeg-формате видеокарта «кушать» не умеет. Мы говорим о мобильных устройствах, соответственно, железяки нужно кормить текстурами таких форматов как, например, DXT, ATC, ETC. Не вижу вину Юнити в этом. Зато вижу заслугу — в ETC2, который является обязательным в стандарте OGLES3 появится нормальный альфа-канал и ряд других плюшек. Да, мы состоим в Хронос группе и сильно влияем на будущее.

Jpeg из ресурсов будет на лету распаковываться в RGBA16 или RGBA32 — это ж сколько мегабайт в памяти гонять то?! Так делать нельзя.

Существующие AssetBundles — это и есть ZIP-архивы из которых можно доставать файлы. Вот только jpeg в ассет бандле останется jpeg-ом, который распаковывается на лету в очень тяжелый для мобильного утсройства набор байтов. Текстуры для мобилок надо сжимать в редакторе.

В профайлер Юнити можно добавить любую функцию из вашего кода:
Profiler.BeginSample („MyCode”);
Profiler.EndSample ();

Плюс пару трюков с профайлером я в своем блоге выложил: drinkandcode.com/unity-profiler-tricks/
Я понимаю, чем к примеру DXT отличается от JPG. Просто есть моменты, когда лучше использовать JPG (или PNG). Бывает иногда нужно пожертвовать высокой скоростью загрузки в пользу размера приложения.

ZIP можно просто переименовать в AssetBundle? Или это аналог зипов? Не совсем понял. Ну и для использования AssetBundle надо менять код загрузки ресурса, я же говорил о том, чтобы двиг сам это обрабатывал.

Про профайлер — я говорил немного о другом. BeginSample/EndSample — это для замера скорости выполнения кода, если я правильно понимаю, я же говорил о логгировании.

Ещё бывает код неправильно работает, хотя это уже очевидно вина Xamarin. Могу прислать к примеру маленький классик, который работает не так как надо, если есть желание поразбираться.
Вопрос не по теме коммента, но по теме топика — скейлинг все так же будет разбивать батчинг для 2д или будет использоваться внутренняя генерация единого меша, как сделано в NGUI? Все эти анимационные рюшечки будут не сильно интересны для мобилок, если количество DrawCalls будет зашкаливать.
Дроколлы не всегда являются боттлнеком, батчинг в runtime кушает процессор — иногда дешевле чаще функцию отрисовки вызывать, чем заставлять процессор меши комбинировать.

По батчингу в 2Д — Юха с Томасом оперативно отвечают на нашем форуме, предлагаю почитать: forum.unity3d.com/threads/197921-In-House-2D-Support-with-Unity-4-3/page2
Дроколлы не всегда являются боттлнеком

Вопросов больше не имею :)
Хотите сказать, что это не так? Да, дроуколлы — важный параметр для мобильных девайсов, но не единственный. На ПК вообще про дроуколлы можно в ряде случаев не думать…
Я получил ответ на свой вопрос в стиле «нет, оно работать не будет, но ведь есть случаи, когда это не важно» :) IMHO, юнити не является конкурентоспособной платформой на десктопе на текущий момент, но на мобильном рынке ей нет равных. Для меня — это основное направление. Ну что же, все понятно, будем продолжать пользоваться NGUI.
Мм, а какие есть конкуренты у Юнити на ПК, учитывая цену в $1500 (т.е. не берем в расчет всяческие CryEngine и Unreal Engine)? Что-то только бесплатный Irrlicht вспоминается.
Ну как раз таки берем их в расчет + роялти у них (можно девелопить сколько-угодно, а платить только с релиза). Соотношение качество картинки / трудозатраты на них просто на порядок лучше. Это если не брать отвратительную работу с ресурсами у юнити в рантайме. Фоновый стриминг — где оно? Без адекватного менеджера ресурсов из коробки, способного обрабатывать здоровые объемы на юнити так и будут пилить маленькие казуалки. Да даже на мобилках ProjectAnarchy будет составлять здоровую конкуренцию юнити, как только допилят его до вменяемого состояния (хотя бы редактор).
Кхм. Стриминг? Чем вам бандлы не угодили?
Не путайте подгрузку внешних ресурсов-архивов (для дальнейшего доступа к их контенту) и фоновое инстанцирование и убивание отработанных дальних объектов для экономии памяти непосредственно в процессе игры. В юнити это все приходится пилить руками, делая отложенное и размазанное по времени инстанцирование, разбивая его на простые объекты, чтобы синхронная операция не сильно убивала перфоманс. Во всех перечисленных выше движках об этом не надо думать в принципе — это обеспечивается автоматом и в фоне.
Вот пример по поводу ресурсов — сильно течет память если создаешь ландшафты динамически, а потом удаляешь. Не помогает ничего ни Destroy, ни UnloadUnusedAssets
Все зависит от того как создаются динамические ассеты. И как вы мониторите утечки памяти. Предлагаю отправить нам багрепорт.

Однако, не забывайте, что у Юнити есть managed и unmanaged память, т.е. если объект родной для движка — в мэнэджэд памяти будет торко вроппер над ним. Если вы создали gameobject, то все наоборот. В итоге вы должны или пользоваться Unity API, чтобы управлять своими объектами, или убеждаться, что не оставили ликов в памяти C++ или C#.
Сейчас, в Unity 4.3, который выйдет осенью, процесс разработки 2D игр будет стандартизирован, появится новый набор инструментов для работы с 2D графикой, а так же популярный физический движок Box2D.

Ну просто отличные новости.
Хм, я прочитал «Unity 2D: реклама и надувательство».
коллега!

прочитал «Unity 2D: реклама и издевательство» :)))
Интересно, родной 2D будет лучше чем популярные пакеты типа 2D Toolkit? Или все прийдется писать руками?
Будет механизм удобной работы с атласами, батчинг в единый меш, оверрайды камеры и автоматическая подгрузка разных атласов для ретины/не ретины?
Исходя из этой темы они предлагают пользоваться внешними атлас-генераторами, либо встроенным, который будет доступен только в про-версии. А про батчинг вроде как есть ответ тут.
Приколько конечно. Но посмотрел видео и ещё другие материалы и складывается не очень хорошее впечатление о среде в целом. Разработчика силой огорождают от разных компонентов.
Очень сильно привлекает количество поддерживаемых платформ, и всё же с Corona SDK переходить не буду.
А в чем отличие-то? Разницы никакой, только плоскость проецирования меняется, что никак на игру не влияет
Я имею в виду физику для вида сверху, чтобы можно было задавать коэффициенты трения у «земной» поверхности.
Это делается несколькими строками кода, нет смысла разделять 2Д на кучу проекций только по этому параметру
Sign up to leave a comment.