Именно по этой причине все люди занятые в препродакшене: концепт художники, сценаристы работают в основном на контрактной основе, и никто не заставляет держать их у себя на зарплате.
Не слишком честно снова собирать деньги, учитывая, что Wasteland они еще не закончили. Я бы хотел ошибаться, но мне кажется они просто учуяли легкие деньги и собирают просто потому, что могут.
парсится swf, по ней генерируется спрайтшит, xml описания анимаций и код.
За счет генерации кода есть возможность обращаться к частям анимации, изменять в рантайме ее свойства. Кроме того это упрощает работу с графикой.
Можно делать так (весь код MyClip и его детей генерируется):
var clip = new MyClip();
clip.child1.partOfChild.Rotation = 40;
clip.someOtherChild.GotoAndPlay(12);
clip.FinishEvent += OnAnimationFinish;
Работать нужно так, чтоб нравилось.
Переписывать уже готовый проект скучно.
Перейти с .net на php…
Все зависит от вашего отношения к работе — если это просто зарабатывание денег, однозначно да. Если работа для вас что то большее (а для меня это дело всей жизни) то однозначно нет.
fmod — не промежуточная библиотека, не обертка над существующими апи. Это кроссплатформенная библиотека для софтварного проигрывания, микширования и риалтайм обработки звука. Для больших проектов стоит $15к (это не аргумент, конечно, но подразумевает серьезность )
На виндовс ее использование дало мне меньшие задержки (по сравнению с XNA), и идеальное микширование нескольких звуковых дорожек. До iOS я пока еще не добрался и поэтому мне интересно было сравнение fmod с нативным апи.
Я далеко не профи в обработке звука — просто сейчас пишу музыкальную игру, но советовал бы посмотреть в сторону fmod если еще не щупали (не сочтите за рекламу).
Но если ее свернуть, а потом вернуться в нее — то половина текстур заменяется черными квадратами.
Это встречается сплошь и рядом в играх под андроид (из последних вспомню Rayman Origins). Связано с тем, что андроид не гарантирует, что OpenGL ресурсы сохранятся в памяти при работающей в фоне активити. Фиксится довольно просто — при возвращении из фона текстуры перезагружаются. Игры пишу на своем движке, реализовывал это сам — там пару строк кода всего.
Что это? Баг Unity?
Однозначно. Это известная «фича» андроида и странно, что в юнити это не исправили.
а вы проверьте. у меня на живом проекте после запихивания всего в 2 вызова фпс поднялся с 45 до 60. До этого отдельно рендерил кривые и на каждую кривую был отдельный вызов (всего до 20).
Не могу сказать, что это заслуга только уменьшения количества вызовов, так как переписывание сильно затронуло разные части рендера.
Посмотрите в сторону XNA или Sony PSM SDK. Как они работают с 2д. Объединение всего что возможно и минимизация вызовов к видеокарте — это лучшая практика.
Количество вершин у вас ведь все равно одинаковое, что разбивать вызовы что не разбивать. Наполнить 30 массивов по 40 вершин или 1 в 1200 — какая разница?
При том количестве вершин что в 2д (врядли вы вылезете за 2000) и при том как 2д обрабатывается (вы же в 2д объекты двигаете, а не камеру) вообще нет смысла выделять «статику» — быстрее будет банально сформировать 1 буфер и 1 раз его весь обновить.
Всегда стараюсь всю сцену впихнуть в 1-2 вызова. С системами частиц, любыми трансформациями, рисованием примитивов, кривых итд. Но, конечно, работаю не с Юнити.
C# обеспечивает чудесную кроссплатформенность. При чем на некоторых платформах он является безальтернативным вариантом (PS Vita, XBox). В основном это актуально для игр.
Но да, сам использую и другим советую именно mono. Так как
отсутствие пользовательских value-типов (структур)
парсится swf, по ней генерируется спрайтшит, xml описания анимаций и код.
За счет генерации кода есть возможность обращаться к частям анимации, изменять в рантайме ее свойства. Кроме того это упрощает работу с графикой.
Можно делать так (весь код MyClip и его детей генерируется):
var clip = new MyClip();
clip.child1.partOfChild.Rotation = 40;
clip.someOtherChild.GotoAndPlay(12);
clip.FinishEvent += OnAnimationFinish;
Код на C#, так как пишу на моно.
Переписывать уже готовый проект скучно.
Перейти с .net на php…
Все зависит от вашего отношения к работе — если это просто зарабатывание денег, однозначно да. Если работа для вас что то большее (а для меня это дело всей жизни) то однозначно нет.
На виндовс ее использование дало мне меньшие задержки (по сравнению с XNA), и идеальное микширование нескольких звуковых дорожек. До iOS я пока еще не добрался и поэтому мне интересно было сравнение fmod с нативным апи.
Я далеко не профи в обработке звука — просто сейчас пишу музыкальную игру, но советовал бы посмотреть в сторону fmod если еще не щупали (не сочтите за рекламу).
У вас просто слишком простые задачи.
Это встречается сплошь и рядом в играх под андроид (из последних вспомню Rayman Origins). Связано с тем, что андроид не гарантирует, что OpenGL ресурсы сохранятся в памяти при работающей в фоне активити. Фиксится довольно просто — при возвращении из фона текстуры перезагружаются. Игры пишу на своем движке, реализовывал это сам — там пару строк кода всего.
Однозначно. Это известная «фича» андроида и странно, что в юнити это не исправили.
Часы по цене китайского смартфона… если пойдет, то через 2 недели в поднебесной будут продавать такие же по 5$
Не могу сказать, что это заслуга только уменьшения количества вызовов, так как переписывание сильно затронуло разные части рендера.
Количество вершин у вас ведь все равно одинаковое, что разбивать вызовы что не разбивать. Наполнить 30 массивов по 40 вершин или 1 в 1200 — какая разница?
При том количестве вершин что в 2д (врядли вы вылезете за 2000) и при том как 2д обрабатывается (вы же в 2д объекты двигаете, а не камеру) вообще нет смысла выделять «статику» — быстрее будет банально сформировать 1 буфер и 1 раз его весь обновить.
Всегда стараюсь всю сцену впихнуть в 1-2 вызова. С системами частиц, любыми трансформациями, рисованием примитивов, кривых итд. Но, конечно, работаю не с Юнити.
Но да, сам использую и другим советую именно mono. Так как удар по производительности (особенно для игр)
дьяволаMeeGo.