Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
Я в раздумьях =)
Нужно выбрать способ технической реализации спрайтовой анимации для своего проекта.
На странице будет от 1 до 20-25 спрайтов одновременно. Они могут перемещаться, менять состояния.
Нужно выбрать способ технической реализации спрайтовой анимации для своего проекта.
На странице будет от 1 до 20-25 спрайтов одновременно. Они могут перемещаться, менять состояния.
Глупый вопрос. JS отпадает, тормозит сильно. Gif даст некачественную анимацию, особенно если есть прозрачность.
Я написал простейшую демку, не заметил вообще никакой нагрузки от покадрового спрайта на JS. Поэтому и задался вопросом… Сегодня собираюсь написать полноценное демо, приближенное к реальной ситуации (много спрайтов, перемещение, смена состояний).
Правда в Actionscript я полный нуб, соответственно сравнить с флэшем будет проблематично.
Правда в Actionscript я полный нуб, соответственно сравнить с флэшем будет проблематично.
20-25 спрайтов, которые меняются 5 раз в секунду через JS. А потом посмотрите на нагрузку процессора :) и что будет если прокрутить страницу, не подтормаживает? :)
Примерно такую демку и напишу, поглядим что выйдет.
Прокручивать страницу там будет не нужно.
А у вас есть опыт разработки подобного на Flash? Поделитесь опытом? )
Прокручивать страницу там будет не нужно.
А у вас есть опыт разработки подобного на Flash? Поделитесь опытом? )
Как ни крути, а flash производительнее, опыта нет, я не flash-разработчик.
Смотрел аналогичные проекты целиком на flash — загрузка одного ядра процессора на 100% — хотя может дело в том, что у меня линух.
Было бы интересно узнать зачем столько анимированных частей на странице
Игровой проект.
Очень много факторов влияет на производительность:
1.частота изменения картинки.
2.размер анимированных частей.
Я как-то смотрел проект майл.ру с игрой, мобы тоже анимированные, их много, сетка 50 на 50 где-то, на флеше не тормозило.
1.частота изменения картинки.
2.размер анимированных частей.
Я как-то смотрел проект майл.ру с игрой, мобы тоже анимированные, их много, сетка 50 на 50 где-то, на флеше не тормозило.
У меня размер моба будет примерно 50х75, сетка гексагональная, на весь верхний фрейм.
Частота — 5-8 кадров в сек.
Частота — 5-8 кадров в сек.
Попробуй размножить www.otanistudio.com/swt/sprite_explosions/ готовую анимацию на 25 объектов :)
Это кстати тот самый вариант что предложил smmurf ниже.
Вариант со спавном бесконечного количества спрайтов
У меня на хроме до спавна ~2000 спрайтов нет тормозов.
Более осмысленный пример
Спрайтов 15-30, все анимированные и перемещающиеся; FPS ~19.44 (50мс задержка между обновлением).
У меня на хроме до спавна ~2000 спрайтов нет тормозов.
Более осмысленный пример
Спрайтов 15-30, все анимированные и перемещающиеся; FPS ~19.44 (50мс задержка между обновлением).
C флешем можно добиться хорошей производительности, даже если объектов будет много. Основной момент — отрисовывать все в битмапы либо в фотошопе, либо руками через класс Bitmap. Основная причина тормозов во флеше — нагрузка на процессор из-за просчета большого количества векторной анимации. С растром всё проще.
Мне нужна именно полноценная анимация, т.е. несколько чередующихся кадров (объект ходит, объект атакует, объект умирает и т.п.). Простое перемещение тут не подойдет.
а почему не рассматривается вариант с DIV фиксированных размеров, в котором длинные бекграунды с высотой кадра по высоте дива?
[0]
0
0
вся анимация сводится к смещению background-position на высоту дива, это быстрее, чем менять src изображений, да и подгружается сразу вся анимация объекта.
[0]
0
0
вся анимация сводится к смещению background-position на высоту дива, это быстрее, чем менять src изображений, да и подгружается сразу вся анимация объекта.
Интересная идея. хотя из-за недостатка опыта слабо себе представляю как показывать только кусок картинки.
Спасибо за идею, буду пробовать и такой вариант.
Практика показывает, что вариант с overflow: hidden и изменением координат слоя в контейнере работает чуть быстрее и плавнее, чем background-position.
Простите, туплю, вы же сами и ответили — использовать как фон элемента нужного размера.
Гляньте выше в ответе на коммент jeje, дал ссылки, реализовал по этой схеме, работает шустро =)
Спасибо за совет.
Спасибо за совет.
Где вариант «зависит от анимации»? Везде есть и свои плюсы и свои минусы.
Всем спасибо за конструктивные комментарии, даже не задумывался о варианте, предложенном smmurf и BaBL, буду делать демку и смотреть на результаты.
Если интересно — покажу потом.
Если интересно — покажу потом.
Если интерфейс будет завязан на Javascript, и связь кадров анимации со скриптами будет прямая, то выбор, на мой взгляд, очевиден. Я как-то реализовывал игровое поле, которое само состояло из ~15 слоев, плюс спрайты с анимацией, которые работали через матрешки, контролируемые Javascript. Причем сами спрайты тоже были многослойные — т.е. поверх анимированного слоя был еще один, тоже анимируемый. Проще говоря, было много анимаций и наложенных друг на друга слоев. Все управлялось Javascript, причем одним глобальным таймером анимации (а не каждой анимации свой таймер). Работало все это дело с нормальной скоростью, везде, кроме ie
Да, я тоже собираюсь использовать один глобальный таймер для анимации.
… кроме ie версии 6 и ниже, поскольку использовался png24-fix, который сильно сажает производительность. В chrome работало практически идеально, в других браузерах — практически неразличимые подтормаживания.
Кстати есть еще вариант с svg/vml графикой, или использованием canvas. Оба эти варианта работают чуть быстрее (с растровой графикой, перемещением и анимацией), чем просто матрешки. Однако эти решения нетривиальны, имеют свои ограничения, а canvas, к тому же, работает не во всех браузерах.
Но специфика проекта была такая, что графика была «под 8-битку» и анимации были дерганные «by design». Так что если нужна красочная, плавная анимация, то лучше посмотреть в сторону плагинов (flash, silverlight и т.д. и т.п.).
Кстати есть еще вариант с svg/vml графикой, или использованием canvas. Оба эти варианта работают чуть быстрее (с растровой графикой, перемещением и анимацией), чем просто матрешки. Однако эти решения нетривиальны, имеют свои ограничения, а canvas, к тому же, работает не во всех браузерах.
Но специфика проекта была такая, что графика была «под 8-битку» и анимации были дерганные «by design». Так что если нужна красочная, плавная анимация, то лучше посмотреть в сторону плагинов (flash, silverlight и т.д. и т.п.).
Если дело идет о создании игр, то может это поможет. JS фреймворк для создания игр. www.effectgames.com/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Каков самый быстрый по производительности способ спрайтовой анимации на странице?