Comments 9
надо где-то хранить количество кадров и fps для каждой анимации
а ширина / высота одного фрейма у всех спрайтов разная?
Если бы была разная, то пришлось бы хранить табличку с данными каждого спрайта, как делается в игровых движках.
В моем случае это не особо нужно было, потому и прямоугольник каждого кадра очень просто определяется по формуле:
где height — высота большого битмапа (sprite sheet), width — его ширина, деленная на кол-во кадров, frame — номер кадра.
В моем случае это не особо нужно было, потому и прямоугольник каждого кадра очень просто определяется по формуле:
Rect frameRect = new Rect(frame * width, 0, (frame + 1) * width, height);где height — высота большого битмапа (sprite sheet), width — его ширина, деленная на кол-во кадров, frame — номер кадра.
Я к тому, что если ширина и высота фрейма везде одинаковая, то зачем хранить кол-во фреймов?
Недавно нужно было портировать приложение с JAVA-ME и не найдя в андроиде класса Sprite, пришлось его реализовать, подсматривая в сорцы JAVA-ME ( jcs.mobile-utopia.com/jcs/73812_Sprite.html ) и там как раз при инициализации спрайта задаётся ширина и высота фрейма, а не их кол-во. При чём спрайт не важно горизонтально, вертикально или в 5 колонок нарисован — результат один.
Недавно нужно было портировать приложение с JAVA-ME и не найдя в андроиде класса Sprite, пришлось его реализовать, подсматривая в сорцы JAVA-ME ( jcs.mobile-utopia.com/jcs/73812_Sprite.html ) и там как раз при инициализации спрайта задаётся ширина и высота фрейма, а не их кол-во. При чём спрайт не важно горизонтально, вертикально или в 5 колонок нарисован — результат один.
Зная количество кадров и геометрию расположения, мы можем как-угодно масштабировать большую картинку — код не изменится. Например, под разные разрешения можно спокойно держать битмапы в папках drawable-hdpi, drawable-xhdpi и пр.
В «правильной» же реализации для каждого фрейма хранится отдельное описание, включая координаты, размер и параметры кропа. Тот же Zwoptex может генерить такие файлы в любом формате, включая и cocos2d.
В «правильной» же реализации для каждого фрейма хранится отдельное описание, включая координаты, размер и параметры кропа. Тот же Zwoptex может генерить такие файлы в любом формате, включая и cocos2d.
m_frameRect — лучше не создавать каждый раз, а использовать старый.
>>Разумным решением было бы разбить анимации на кадры и оформить в xml для AnimationDrawable, но для 15 видов оружия это значило бы мусорку из 5000+ кадров по 10-15 кб каждый.
Что-то я очень сомневаюсь, с большой вероятностью вы бы начали вылетать с out of memory, хотя все зависит от размера одного кадра.
Что-то я очень сомневаюсь, с большой вероятностью вы бы начали вылетать с out of memory, хотя все зависит от размера одного кадра.
Что-то я очень сомневаюсь, с большой вероятностью вы бы начали вылетать с out of memory, хотя все зависит от размера одного кадра.
Собственно, memory footprint для такого решения 1в1 такой же, как и для Sprite Sheet, описанного в статье (+- мелкие расходы на разные Bitmap). Может, прочитаете?
Собственно, memory footprint для такого решения 1в1 такой же, как и для Sprite Sheet, описанного в статье (+- мелкие расходы на разные Bitmap). Может, прочитаете?
Я прочитал, и спасибо за статью, вариант интересный.
Вроде не зря подметил, что все зависит от размера одного кадра. Если взять допустим 20-30 кадров, с размером кадра где-то 200х200, точно сейчас не скажу, то со стандартным animationdrawable упадем с out of memory, т.к. все грузится сразу в память, довольно известная проблема…
Вроде не зря подметил, что все зависит от размера одного кадра. Если взять допустим 20-30 кадров, с размером кадра где-то 200х200, точно сейчас не скажу, то со стандартным animationdrawable упадем с out of memory, т.к. все грузится сразу в память, довольно известная проблема…
32 кадра с размером 256х256 дадут нам 32 штуки Bitmap -> BitmapDrawable, а это будет как раз 8 мб памяти в режиме ARGB_8888 (если кадры с расширением PNG, то наверняка именно так они и загрузятся). Собственно, промежуточный вариант с наследником AnimationDrawable так и делал, только принудительно ставил режим RGB_565, а это уже в 2 раза оптимальнее.
По-сути, sprite sheet не дает нам существенного выигрыша в памяти, только в удобстве работы. Более того, когда я в своей Косынке под Андроид решил не грузить 52 карты из разных файлов, а соединил в большой sprite sheet, получилась загрузка примерно в 2 раза медленее — около секунды вместо старых 0.3-0.5.
По-сути, sprite sheet не дает нам существенного выигрыша в памяти, только в удобстве работы. Более того, когда я в своей Косынке под Андроид решил не грузить 52 карты из разных файлов, а соединил в большой sprite sheet, получилась загрузка примерно в 2 раза медленее — около секунды вместо старых 0.3-0.5.
Sign up to leave a comment.
Видео последовательность в Drawable