![]() |
|
||||||||||
|
|||||||
|
|
« Предыдущая тема | Следующая тема » |
| Опции темы | Опции просмотра |
|
![]() |
|
|||||
|
Регистрация: Jun 2007
Сообщений: 374
|
Всем привет.
Есть боёвка, в ней присутствуют юниты. Юнитов примерно 10 на бой. Каждый юнит может хитро атаковать, у юнита 3 атаки. Как конкретно - см. fla во вложении, символ в библиотеке, например, unit5_Las_vegas_attack3_shot. Проблема в том, что на слабых ноутах даже одна такого рода комплексная анимация, проигрываемая единовременно, снижает fps с 31 до 20. Потому встала задача оптимизировать графику и её воспроизведение. Пошел по пути растеризации векторной графики. cacheAsBitmap Не работает, просто потому, что в анимациях в 90% экземплярах мувиков используются трансформации масштаба и поворот отрисовка кадров мувиклипов через draw Проблема 1. Чтобы сфотографировать все кадры, необходимо проиграть мувиклип полностью и в обработчике enter_frame делать draw. Через gotoAndStop() я не смог добиться того, чтобы мувиклип стал таким, каким он реально в находится этом кадре вместе со своими детьми. Приходится делать stage.invalidate() и ждать события Event.RENDER, которое приходит всё равно через кадр. Поэтому время отрисовки всех атак всех юнитов равно сумме времени воспроизведения каждой атаки. Можно делать параллельно, это сокращает время раза в три, но не более того. Среднее время атаки 6 секунд, и в 3 параллельных потока оно будет рендерить графику ~= 1 минуту, а это очень долго для игры, т. к. бои частые. Вопрос 1. Есть ли какое-либо решение, которое мувиклип со всеми детьми отрисовывает быстрее, чем время проигрывания этого мувиклипа? Проблема 2. Если отрисовать всю атаку как есть, т. е. без каких-либо оптимизаций, на весь кадр атаки, то получившаяся BitmapData занимает около 100 мб памяти. 30 анимаций никак не уместишь в максимально допустимую память 500 мб. При таком подходе сохраняется очень много полупрозрачностей, поэтому я немного помянял способ сохранения - не таймлайн главного мувиклипа, а "фотки" детей в своих границах. Объем получилось сократить до 50 мб, но это всё равно много. Если перейти еще на более глубокий уровень и фотографировать не детей, а детей детей, то я не уверен, что это позволит сильно сократить объем, а уж тем более увеличить какую-либо производительность. Пробовал хранить данные не в BitmapData, а в ByteArray, предварительно сконверченным через PNEncoder2 (самый быстрый, судя по тестам). Объем становится приемлемым (~15мб), раскодировка всех картинок (порядка 1500) loader'ом очень быстрая, работает замечательно. Но конвертор в PNG каждую атаку конвертирует очень долго, и время пререндера увеличивается еще раза в три. А три минуты ожидания пререндера тоже неприемлемы для игроков. По этой же причине не можем хранить все пререндеры в asset'ах. Очень много весит. Вопрос 2. Есть ли способы как-то уменьшить объем сложных анимаций в памяти и решить проблему2? Использование GPU и фреймворка starling Проблема 3. Можно сделать свой конвертор мувиклипов, который превращает классы детей этого мувиклипа в текстуры, сохраняет информацию о трансформации детей и плеер, который создает starling.display.MovieClip'ы из этих текстур и располагает в правильных трансформациях. Проблема оперативной памяти будет не такой острой, т. к. сохраняются нетрансформированные текстуры, которые переиспользуются и трансформируются. Проблема долгого времени конвертации остаётся. Но я не тестировал этот вариант как очень сложный, и не уверен, что starling-мувики из текстур поворачиваются/трансформируются с хорошим качеством + будут быстрее. В принципе можно то же самое и без starling'а сделать, но флэш очень портит качество картинок при трансформациях, и производительность от этого не увеличивается. Вопрос 3. Наверняка я не первый, кто столкнулся с подобной проблемой. Может быть где-то есть какой-нибудь класс для starling'а, которые конвертят мувиклипы как есть и проигрывают их? Вопрос 4. Есть ли ещё способы увеличить производительность такой графики? Мне тут сообщили, что в игре "Легенда" вообще каждый слой игрового мира - отдельная флэшка на html. Но не факт, что это было сделано из-за производительности, скорее из-за того, что какие-то куски игры написаны на as2. |
![]() |
Часовой пояс GMT +4, время: 11:10. |
|
|
« Предыдущая тема | Следующая тема » |
|
|