s8000_1
09.06.2012, 17:40
Всем привет.
Есть боёвка, в ней присутствуют юниты. Юнитов примерно 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.
Есть боёвка, в ней присутствуют юниты. Юнитов примерно 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.