Comments 88
И все равно на моем компе 14 FPS выдает всего. Правда у меня Win Vista…
тоже 14 фпс — хром, семерка.
В фф — 50-55 fps,
хром и ie9 — 18-20
хром и ie9 — 18-20
13 FPS — Хром, 7ка.
У меня 4 FPS, и что? Вы думаете, что на разном железе должны быть одинаковые показатели?
А вообще — JS и HTML 5 не готов для игр — подобная вещь может выдавать сотни fps используя нативный код на намного более слабых машинах.
А вообще — JS и HTML 5 не готов для игр — подобная вещь может выдавать сотни fps используя нативный код на намного более слабых машинах.
Ноутбук Lenovo Core i3 \ 8gb DDR3 \ видео Intel HM55 те же 14 FPS
Chrome 18.0.1025.142 @ Ubuntu 11.10
Неоптимизированный код — 21fps
Оптимизированный код — 25fps
Неоптимизированный код — 21fps
Оптимизированный код — 25fps
Микрософт задолбал своей рекламой, извиняюсь.
Этот комментарий относиться исключительно к навязчивой шапке Visual Studio, измененному лейауту страницы, и к посту не имеет отношения.
Когда портят привычные вещи это вызывает справедливое раздражение. Об этом должны знать создатели данной рекламы, поэтому минусующие — идите лесом.
Когда портят привычные вещи это вызывает справедливое раздражение. Об этом должны знать создатели данной рекламы, поэтому минусующие — идите лесом.
Это их блог, это благодаря им вы прочли эту статью. Так что… идите лесом?
Гм, я выразил сове мнение.
Мне молчать о том, что своей рекламой они похерели шрифты, я не сразу нашел ссылку «Лента» чтобы уйти со страницы.
То есть по вашему, если, к примеру, двери в магазин сделали по-дебильному, то мне нельзя об этом высказаться хозяину магазина, указав на недостатки?
Мне молчать о том, что своей рекламой они похерели шрифты, я не сразу нашел ссылку «Лента» чтобы уйти со страницы.
То есть по вашему, если, к примеру, двери в магазин сделали по-дебильному, то мне нельзя об этом высказаться хозяину магазина, указав на недостатки?
Хинт: «у вас не особенно удобно страница сделана, если честно — и я говорю это без маньяческого желания кого-то оскорбить или покричать о джинсе, которой и впомине нет».
37-39fps FF, Gentoo
Chrome 18 — стабильные 14 fps
FF 10 — постоянно скачет в диапазоне примерно 27-32 fps
Причем одинаково и первый, и второй пример. Может ссылки попутаны?
WinXP, E6500, GeForce 520
FF 10 — постоянно скачет в диапазоне примерно 27-32 fps
Причем одинаково и первый, и второй пример. Может ссылки попутаны?
WinXP, E6500, GeForce 520
Оптимизированный — 38 фпс, неоптимизированный — 40 фпс. Странно всё это. Браузер ФХ 11.
20 fps (оптимизированный), Chrome 18 — MacOS
> молодым автором демо-сцен
> автором демо-сцен
> демо-сцен
сделайте меня развидеть это
> автором демо-сцен
> демо-сцен
сделайте меня развидеть это
к сожалению множество людей путает демосцену как явление и демо как ее конечный продукт
Специально для минусатора-анонимуса
www.youtube.com/watch?feature=player_detailpage&v=iRkZcTg1JWU#t=196s
www.youtube.com/watch?feature=player_detailpage&v=iRkZcTg1JWU#t=196s
неоптимизированный 3, оптимизированный 38 — заметная разница.
А самый большой скачок, судя по графику, даёт кеширование значений DOM свойств.
А самый большой скачок, судя по графику, даёт кеширование значений DOM свойств.
24 fps на HP ProBook 4530s. Довольно таки неплохой результат.
У меня оба варианта 25-30 fps). Chrome 18, mac os.
Спасибо за статью, очень наглядно.
p.s. Картинка в начале статьи заставила улыбнуться.
p.s. Картинка в начале статьи заставила улыбнуться.
0 фпс — не оптимизированный
2 фпс — оптимизированный
iOS safari iPad2
2 фпс — оптимизированный
iOS safari iPad2
Вот это меня и печалит. Почему такие тормоза? Где же «будущее» если HTML5 на iPad так себя показывает?
Да и на маке в Safari рывки и fps 12
Позор…
Да и на маке в Safari рывки и fps 12
Позор…
i7-860, 18fps, Chrome.
То есть то что на 7Mhz Amiga выдавало 60fps, тормозит на мощном 4х-ядерном разогнанном до 4Ghz процессоре при использовании JavaScript.
Не увидел мощь HTML5.
То есть то что на 7Mhz Amiga выдавало 60fps, тормозит на мощном 4х-ядерном разогнанном до 4Ghz процессоре при использовании JavaScript.
Не увидел мощь HTML5.
На 7мгц данный эффект мог работать в 60fps лишь в сильно уменьшенном разрешении.
Если это вас как-то утешит :-)
Если это вас как-то утешит :-)
Пример. 8bit, 3.5MHz, 64x32 но нужно учитывать что это multicolor т.е. помимо самого эффекта еще значительное время тратится на его правильный вывод. Впрочем вы и без меня все это знаете :)
Годный пример, но 50fps там нет
DR на хабре detected =)
DR на хабре detected =)
Показалось что предыдущий эффект плавнее работал.
Тут же метаболлы ещё вылетают потом.
Понятно, что простой мультиколорный туннель во фрейм должен работать.
Спектрум-читерская машина с чанковым экраном и читерским бордюром.
www.youtube.com/watch?feature=player_detailpage&v=rIncbxgg6Jk#t=192s
(корявость английского в скроллере вызывает у меня чувство невыносимого стыда, но писали уж как могли)
Хотя на классической амиге тоже можно с коппером поиграть.
Тут же метаболлы ещё вылетают потом.
Понятно, что простой мультиколорный туннель во фрейм должен работать.
Спектрум-читерская машина с чанковым экраном и читерским бордюром.
www.youtube.com/watch?feature=player_detailpage&v=rIncbxgg6Jk#t=192s
(корявость английского в скроллере вызывает у меня чувство невыносимого стыда, но писали уж как могли)
Хотя на классической амиге тоже можно с коппером поиграть.
UFO just landed and posted this here
Смотря что за Amiga, 320x200 (а не 240) было у самого первого поколения Amiga, еще в середине 80-х. Если брать семейство с AGA чипсетом (Amiga 1200, Amiga 4000) то там и по разрешению и по цветам все очень достойно, особенно для того времени когда они были выпущены. Сравнивая демки для Amiga и PC начала/середины 90-х годов (пока PC не ушел слишком далеко по скорости процессора) можно явно увидеть графическое превосходство Amiga.
Да и Motorola 68040/68060 по вычислительной мощности тоже будут достаточны для обсчета подобного эффекта в нормальном разрешении.
Да и Motorola 68040/68060 по вычислительной мощности тоже будут достаточны для обсчета подобного эффекта в нормальном разрешении.
В Opera 11.62 показывает 10 fps в оптимизированном варианте. И ещё не корректно отображается, будто фрактал мальденброта пляшет позади(но это больше вопросы к создателям Opera). И по заголовку поста я ожидал увидеть игру.
Спасибо за статью но «для разработки современных игр» я б заменил «для разработки игр технологически выполненых на уровне эпохи первых пентиумов»
UFO just landed and posted this here
UFO just landed and posted this here
У меня лично этот туннель ничего общего с играми не вызывает, соответственно и доверия к автору статьи.
Оптимизации полезные, но упущено парочка важных:
— не рисуйте на канвасе без необходимости.
— при множестве отрисовок использовать невидимый канвас как буфер.
Оптимизации полезные, но упущено парочка важных:
— не рисуйте на канвасе без необходимости.
— при множестве отрисовок использовать невидимый канвас как буфер.
Никаких аргументов.
— не рисуйте на канвасе без необходимости.
Почему?
— при множестве отрисовок использовать невидимый канвас как буфер.
Зачем?
— не рисуйте на канвасе без необходимости.
Почему?
— при множестве отрисовок использовать невидимый канвас как буфер.
Зачем?
1. Чтобы лишний раз не вызывать перерисовку?
2. Чтобы не вызывать перерисовку при каждой отрисовке очередного элемента каждый раз, а «нарисовать» всё в память и вывести готовую картинку
2. Чтобы не вызывать перерисовку при каждой отрисовке очередного элемента каждый раз, а «нарисовать» всё в память и вывести готовую картинку
Операции работы с экраном довольно дорогостоящие по времени. Тот же флеш автоматически определяет области перерисовки и поступает мудро, ведь зачем перерисовывать то, что не изменилось?
Отрисовка в буфер так же сокращает работу с экраном, так как передает уже сформированное изображение для вывода на экран. Это в случае, если надо обновлять весь экран.
Хотя уверен, что вы лучше знаете, ведь я все эти штуки и по вашим статьям учил;)
Отрисовка в буфер так же сокращает работу с экраном, так как передает уже сформированное изображение для вывода на экран. Это в случае, если надо обновлять весь экран.
Хотя уверен, что вы лучше знаете, ведь я все эти штуки и по вашим статьям учил;)
1. С этим согласен — я подумал, что вы имеете ввиду «не используйте канвас впринципе»
2. Там есть хитрости. Решение из топика лучше отрисовывать сразу на результатирующий канвас, т.к. кешировать там по сути нечего.
Просто стоит заметить, что двойная буферизация с десктопа здесь, в html5 canvas не рациональна. Первое время я и сам заблуждался в её целесообразности. Браузер сам буферизирует вывод, а потом выводит в ближайший animation frame.
Скрытый канвас имеет смысл использовать для того, чтобы отрисовать тяжёлые вычисления, например вектор перевести в растр, или попиксельный эффект — чтобы отрисовывать обычное растровое изображение
Пример — у нас есть картинка, которую мы должны загнать в чёрно-белый и прогнать по экрану слева-направо. Лучше её в невидимый канвас очернобелить, а потом эту чернобелую картинку отрисовывать через drawImage, чем каждый кадр делать putImageData.
Аналогично, если есть, например, машинка, которая собирается из кучи векторных объектов — её лучше растеризировать и выводить из кеша растр, чем каждый раз рисовать вектора.
2. Там есть хитрости. Решение из топика лучше отрисовывать сразу на результатирующий канвас, т.к. кешировать там по сути нечего.
Просто стоит заметить, что двойная буферизация с десктопа здесь, в html5 canvas не рациональна. Первое время я и сам заблуждался в её целесообразности. Браузер сам буферизирует вывод, а потом выводит в ближайший animation frame.
Скрытый канвас имеет смысл использовать для того, чтобы отрисовать тяжёлые вычисления, например вектор перевести в растр, или попиксельный эффект — чтобы отрисовывать обычное растровое изображение
Пример — у нас есть картинка, которую мы должны загнать в чёрно-белый и прогнать по экрану слева-направо. Лучше её в невидимый канвас очернобелить, а потом эту чернобелую картинку отрисовывать через drawImage, чем каждый кадр делать putImageData.
Аналогично, если есть, например, машинка, которая собирается из кучи векторных объектов — её лучше растеризировать и выводить из кеша растр, чем каждый раз рисовать вектора.
То есть использование скрытых канвасов рационально только для отдельных элементов (кеширование обработанных изображений или вектора)?
У меня был опыт что добавление бэкбуфера позволило чуть ли не в два раза увеличить количество fps, что для меня стало железным аргументом. Может не все браузеры буферизируют вывод? Или может операция по выводу в буфер браузера оказывается все равно дороже, чем в скрытый буфер?
У меня был опыт что добавление бэкбуфера позволило чуть ли не в два раза увеличить количество fps, что для меня стало железным аргументом. Может не все браузеры буферизируют вывод? Или может операция по выводу в буфер браузера оказывается все равно дороже, чем в скрытый буфер?
А как вы потом буфер выводили на экран? drawImage source-буфера в буфер на странице или через replaceChild?
drawImage
clearRect, а потом drawImage особенно большого холста — это очень ресурсоёмкая операция, особенно без аппаратного ускорения. Особенно учитывая тот факт, что часто надо перерисовывать только небольшой квадратик размером, скажем, 50*50
clearRect не использовал, так как перерисовывал весь экран, но согласен что для мелких перерисовок буфер — лишнее.
Если у нас летит шарик на прозрачном фоне, то отрисовывая бекбуфер в новый буфер мы будем иметь все предыдущие кадры.
А если у нас поле изометрическое, с анимированными объектами, которые взрываются, двигаются и еще пользователь перетягивает игровое поле?
Если есть прозрачные участки — будет баг)
UFO just landed and posted this here
в каких слоях, вы о чем?)
UFO just landed and posted this here
Прошу прощения, но просто самого понятия слоев в канвасе нету, мало ли что вы могли иметь в виду, люди ведь разные бывают.
Задачи разные бывают, я вот столкнулся с такой, когда надо было перерисовывать все поле. Вы же предлагаете, как я понимаю, кешировать отображаемую анимацию в скрытых канвах?
P.S. Я пробовал как то использовать несколько канвасов доя отрисовки различных слоев — тормоза дичайшие были. Это в случае, если вы это имели в виду)
Задачи разные бывают, я вот столкнулся с такой, когда надо было перерисовывать все поле. Вы же предлагаете, как я понимаю, кешировать отображаемую анимацию в скрытых канвах?
P.S. Я пробовал как то использовать несколько канвасов доя отрисовки различных слоев — тормоза дичайшие были. Это в случае, если вы это имели в виду)
Вообще, отличная демонстрация того, почему HTML5 вытеснит Flash для игр… лет через 5.
Thinkpad t520, интеловское видео.
Linux Debian Sid + Experimental.
Gnome-shell, Chromium 17.0.963.83.
На панели ноутбука — 34 fps.
На внешнем мониторе — 25fps.
Загрузка процессора — 45-50%.
Linux Debian Sid + Experimental.
Gnome-shell, Chromium 17.0.963.83.
На панели ноутбука — 34 fps.
На внешнем мониторе — 25fps.
Загрузка процессора — 45-50%.
Все соревнуются кого с какой скоростью засасывает в зеленый анус. Страшно.
Я не силён в геймдеве и задам вопрос.
Вот в случае статического ФПС при использовании setInterval, мы можем отрисовывать движущиеся предметы, передвигая их с заданой скоростью, например 4 пикселя за такт. В случае RequestAnimationFrame нам получается необходимо умножать скорость движения на время до предыдущего кадра. Если объектом много не скажется это на производительности в худшую сторону?
Вот в случае статического ФПС при использовании setInterval, мы можем отрисовывать движущиеся предметы, передвигая их с заданой скоростью, например 4 пикселя за такт. В случае RequestAnimationFrame нам получается необходимо умножать скорость движения на время до предыдущего кадра. Если объектом много не скажется это на производительности в худшую сторону?
Примерно так. Но лучше все равно использовать RequestAnimationFrame, при этом логику и физику оставить на таймере (если это критично).
Кроме того, RequestAnimationFrame позволит избавиться от «захлебывания» на клиентской машине, когда она не успевает отработать один кадр и начинает отрабатывать другой — получаются жуткие тормоза, которых в принципе можно было избежать, поставив рендер либо на таймаут, либо на RequestAnimationFrame.
Кроме того, RequestAnimationFrame позволит избавиться от «захлебывания» на клиентской машине, когда она не успевает отработать один кадр и начинает отрабатывать другой — получаются жуткие тормоза, которых в принципе можно было избежать, поставив рендер либо на таймаут, либо на RequestAnimationFrame.
Вот в случае статического ФПС при использовании setInterval, мы можем отрисовывать движущиеся предметы, передвигая их с заданой скоростью, например 4 пикселя за такт.
Ошибаетесь. Никто не гарантирует стабильности изменения setInterval, потому всё-равно на перемножать на дельту. И нет, на производительности это практически не сказывается (в рамках погрешности)
Рассказали бы все же еще, хотя бы вкратце, как работает эффект. А то смотрю на все эти
40.0 * Math.abs(Math.cos(angle)) и ничего не понимаю :(
В данном примере рендеринг производится в области 300x200, а GPU масштабирует до размеров вашего окна.
Все хорошо пока соотношения сторон не меняются
Все хорошо пока соотношения сторон не меняются
Пример конечно интересный, но прямая работа с пикселями — это то чего избегать надо.
Про канвас в данном топике имхо — не сказано ни слова.
Про канвас в данном топике имхо — не сказано ни слова.
Спасибо, помогло. Увеличил FPS своей демки до 60-и.
А мне вот что интересно на Windows 8 CP:
9-11fps — Опера (11.62), причем отображается по краям красным цветом, и ежесекундные затыки.
13fps — Хром (18.0.1025.151m) — стабильно, но замедленно
Зато IE10 (10.0.8250.0) выдает 40-41 не меньше.
Хитрые оптимизации однако)
9-11fps — Опера (11.62), причем отображается по краям красным цветом, и ежесекундные затыки.
13fps — Хром (18.0.1025.151m) — стабильно, но замедленно
Зато IE10 (10.0.8250.0) выдает 40-41 не меньше.
Хитрые оптимизации однако)
Sign up to leave a comment.
Как раскрыть мощь HTML5 Canvas для игр