кешування movieclip

Коли я зауважив, що мої ігри сильно гальмують з релізной графікою я вирішив її якось оптимізувати. Стандартний cacheAsBitmap не допоміг. Порившись на форумах і Гугла я з'ясував, що краще самому кешувати кліпи в Bitmap. Навіть знайшов вихідні кешування від TouchMyPixel. розробників гри Scary Girl. Але він був занадто не універсальна, змушував художника зро за розміром кадрів. Тому взявши його за основу я написав свій клас, який перетворює будь-який MovieClip в набір Bitmap'ов з урахуванням всіх зсувів. Надалі цей клас можна буде використовувати для створення атласів анімації, які можна буде використовувати при портировании Flash ігор на інші платформи.

Зверніть увагу, що використовуючи статичний метод getClip у нас створюється бібліотека кліпів, звідки потім використовуються фрейми і офсет, щоб не плодити їх копії.

Update. Виправив помилки, додав лейбли.

1. getRect треба замінити на getBounds. Бо метод getBounds видає прямокутник з урахуванням товщини ліній, виступаюшего блюра / глоу. У підсумку в твоєму прикладі у багатьох випадках будуть обрізані краю.
2. Прямокутник, який віддається в цих методах має нецілі взагалі кажучи параметри. Те-є щоб знову таки не отримати обрізки по краях - застосовувати Math.ceil для ширини / висоти і Math.floor для x і y.
3. До речі матрицю пересоздавать кожен луп циклу не варто, не мучте гарбадж колектор, та й взагалі подібний підхід сумарно на всьому коді зекономити перфоманс.

Так, у них так. Але нічого хорошого в цьому не бачу. Живий приклад номер один - у мене є анімація вибуху. Зрозуміло, що спочатку він малесенький, потім розростається. При правильному підході економиться пам'ять дуже сильно. Приклад номер два - метелик, вид зверху, махає крилами. Приклад номер три - м'ячик падає на землю і підскакує рази три. При підході з e_bounds буде купа напівпорожніх бітмапами, бо розмірчик треба буде робити великий, щоб в одному кутку помістився м'ячик у верхній фазі а в іншому кутку - внизу. Теоретично можна в кліпі прибрати переміщення, а реалізовувати його програмно, але в іграх повно таких моментів, які зручно аніматору синхронізувати і малювати одночасно.

У цьому підході дуже економиться пам'ять.

По мимо прискорення та економії пам'яті, головний плюс мого коду в тому, що ми можемо зробити кліп з центром в (0; 0), закеширувати його і обертати. І все буде коректно.

тож писав подібну штуку. код тільки товстіший. я якщо чесно не зрозумів навіщо пхати в різні бітмапами дати (ну і що що треба задавати область відтворення? крім області можливо ще потрібен буде бібокс або який-небудь шейп під фізику кароче особисто мене не напружує кинути в кліп прозорий прямокутник draw_frame). якщо ми суем все в одну бітмапами дату (або кілька, але мається на увазі спрайтщіт саме) то ніби як лежать кадри в пам'яті близько і робота по отрисовке повинна бути спритніше але це навряд чи так для флеша. знову ж якщо ми так робимо (ЯКЩО це реально працює) то доведеться проводити сортування об'єктів до рендеру сортуючи по використовуваному ресурсу - а потім вже малювати. принаймні для тих чи інших частинок це робиться елементарно. повторюся поняття не маю чи правильно це для флеша. ще при такому кешування ми втрачаємо основна перевага мувікліпа - робота з вкладеними мувікліп (типу піти ІМ на такий-то кадр). тобто доводиться складати об'єкти вже в коді.

ще не зрозумів навіщо дублювати цей исходник, якщо можна користуватися класом надбудовою який і буде займатися анімацією і отрисовкой тупо використовуючи лінк на єдиний екземпляр ресурсу з бітмапами датами / фреймами та іншої тонною даних. имхо треба б розділити поняття. дискусія на цю тему вітається.

ще розкажи будь ласка як ти реалізував перехід по лейблу на потрібну анімацію? типу gotoAndPlay (label: String) як у тебе працює? Був би дуже вдячний за інфу. Сам вибрав досить брутальний спосіб - лейбли це тупо uint і перехід здійснюється по uint на номер лейбла а не по імені. Це не наочно, а коли НЕ наочно голова болить.

За пост спасибі. Коли писав свій компілятор особливо відкритих кодів не було, доводилося сильно ламати голову)) Ну і так, згоден, можна зробити автоматичний експортер графіки (резалку спрайтщітов) (куди небудь в png) але треба подумати про збереження даних про анімацію / кадрах.

Про бітмапи. У моєму випадку багато бетмапов потрібно якраз для економії пам'яті, Наприклад при анімації вибуху, коли об'єкт з точки перетворюється в велику кулю диму. При використанні прозорого прямокутника в перших кадрах у нас буде багато непотрібних пікселів.

Про вбудовані кліпи. Ними можна пожертвувати, якщо ціна - значне прискорення відтворення. Або просто не кешувати такі об'єкти, якщо їх не багато (а зазвичай це так і є).

Про дублювання. Воно зроблене якраз для того, щоб не плодити однакові дані. Якщо у нас є 10 однакових об'єктів, то вони будуть використовувати один набір кадрів. Але при цьому вони незалежно анімуються.

Про лейбли. Перехід по іменах лейблів НЕ Делело і взагалі не уявляю, нафіга це потрібно. При роботі з анімацією я все одно використовую номера кадрів. Але зробити це досить просто. Або записати в Object номер кадру по ключу імені кадру, або перебрати масив labels - індекси масивів збігаються.

Про повороти. У бітмапами флеш малює дуже швидко, але. У нашому випадку це потрібно тільки один раз. Потім Bitmap додається в Sprite і крутимо ми вже його, штатними засобами.
Про гру. Так, писав все це під конкретну задачу - прискорити гру. Конкретних цифр не знаю. Але на око гра прискорилася рази в 3. Все і вся, звичайно, кешувати не потрібно. Наприклад я персонаж не кешируєтся, вони складно-складові, але їх не багато. Інтерфейс теж не кешируєтся. Тільки блоки, декорації, об'єкти.

Будь ласка. Атлас робиться в нашому випадку просто. Графіку - в PNG, дані в XML.

Спасибі за відповідь.

Про дублювання я погано висловився - у мене двиг малює все в одну бітмапами дату - екран. Олдскульний такий підхід. Сценграф флеша не використовується при цьому, ніякі там new Bitmap () і т.п. не потрібні. Тому для мене логічно що ресурс як такої не дублюється ніяким способом. У твоєму випадку це потрібно щоб був Bitmap. Так як підходи різні то і методи різні. Мені наприклад зручніше мати абсолютно окремий клас який працює з єдиним екземпляром ресурсу переходячи по кадрам і отрісовивая його на той самий екран. Ну власне в цьому контексті і питав що буде швидше draw нескладного вектора або draw того ж вектора але кеш в бітмапами дату?

Про лейбли все дуже просто - якщо ти використовуєш номера кадрів це не наочно. Ти потім сам Новомосковскешь код і повинен згадувати куди нафіг йде цей gotoAndStop (182)? Можна зробити константу const ANIM_RUN: uint = 182; і отримаємо gotoAndStop (ANIM_RUN) що вже наочніше, але зручніше було б використовувати лейбли щоб не створювати зайвого коду. Спробую використовувати Object для цієї мети, на зразок буде спритніше ніж прокручувати список лейблів порівнюючи рядки.

Про dispose нічого не знаю, треба почитати. Ніби як сміттяр видаляє все, на що немає посилань.
Прямокутники кадрів є в самих кадрах, тому що у нас кожен кадр малюється в окрему бітмапи. Яка за розмірами як раз одно кадру.
На рахунок лейблів - пофіг. Там зовсім дрібниці, до того ж не дублюються.

Сміттяр bitmap data видалить. Але оскільки bitmap data - дуже великий об'єкт, то слід добре помити їх самостійно, якщо вони більше не потрібні. А то поки не запуститься наступний прохід сміттяра (який відбудеться, коли, грубо кажучи, «пам'ять скінчиться»), вони будуть висіти в пам'яті і займати дуже багато місця.

Але якщо bitmap data просто створюється на весь час життя флешки (як кеш, наприклад), то і видаляти їх явно не потрібно.

Ну в нашому випадку приблизно це і відбувається. Можна, звичайно, для параноїків зробити статичну функцію очищення кешу, яка і буде все dispose робити. Подумаю над цим.

ui і з фоном в результаті треба щось зробити. Я розумію тут стиль такий можливо, але ... з інтересом.

Запустив. 50 мб завантаження на старті - все таки перебір для таких ігор. Як і відсутність.

Тобто, зовсім чесні нові ігри? А яким чином ранжируется по місцях, не в курсі, випадком?

злякався дуже сильної конкуренції)

О, ось це чудова новина, ввечері перевірю як працює.

Вартість продакшена (як в грошах, так і в людино-годинах) цілком собі можна вважати.

Кому-небудь ще вдалося перемогти зв'язку AIR + Mac + Steam? Після обробки файлу гри стімовскім.

Не бачу великих змін для адекватних розробників

Вітання! Для того ми тут і зібралися, в тому числі розповідати про граблі :)

Дякую що звернули увагу. Поправив.

Успіхів! Теж робимо гру на air :)

Адоб точно не напише, що не написали вінфон і ще купу всього. Та й Шумву з компанією.

Ой спасибище! Якщо хоч одній людині сайт став у нагоді, значить я не дарма витрачав на нього час!

А коли вони його закривають? Історія прекрасна! Плюсанул, удачі!