Comments 34
Зачем вы перерисовываете незатронутые объекты?
Зачем вы целиком перерисовываете такие большие здания со спрайтами сложной формы, если задета только небольшая их часть?
Вы же понимаете, что у вас общая площадь спрайтов для отрисовки получается сравнимая с общей площадью сцены если не больше? Где же тут оптимизация?!
Если у вас много объектов сложной формы, то разбейте пространство на ещё более мелкие квадраты, но фон и объекты храните в бОльших кратных спрайтах, находите список необходимых для обновления тайлов по формулам, перерисовываете не все тайлы, а только тех их участки, которые нужно, как и объекты на других слоях. Постройте эффективные списки или деревья объектов и тайлов с учётом слоёв.
Про кэширование я уже просто молчу — при такой структуре сцены это всё должно отрисовываться в теневые буферы и кэшироваться! Отрисовайте статичные предметы в теневой буфер и берите тайлы оттуда! Вот это будет оптимизация на технологиях 30-летней давности.
Это всё в совершенстве работало в Warcraft 1 в 1994 году, а до того — десять лет на приставках!
И вы ещё рассказываете про оптимизацию? Или это «лекция для колхозников»? Но и тогда нельзя давать таких советов и таких примеров кода!
Прошу заметить, что за этот "движок" автор хочет ~5 тыс. для коммерческого использования. Боюсь представить какой же там остальной код.
Таблица недвусмысленно намекает, что это за базовую версию, но для коммерческого использования
Вы уж меня извините, но движок — про низкокачественные игры-однодневки, которыми и без того заполонён интернет. Aka Flash reborn 2021.
Почему-то при использовании UE4 оправдываться не придётся, а тут сразу такие проблемы. Не думаю, что хоть одна из игр подобного уровня достигнет gross revenue >$1M, так что беспокоиться про роялти смысла нет
Игровой фон должен быть разбит на части и не являться целым изображением. Судите сами: если фон — целое изображение, то его все равно придется где-то перерисовать. И раз оно цельное, то перерисовать придется полностью, а значит, ни о какой перерисовке отдельной части CANVAS речи быть не может.
Неужели секретная техника отрисовки только части изображения утеряна в веках?
Камера в игре должна стоять. Потому что если камера движется, то и вся сцена движется, а значит, всю ее и надо перерисовать
В некоторых случаях имеет смысл использовать внеэкранный холст чуть большего размера. Или даже основной холст чуть большего размера, обрезанный через overflow: hidden.
В некоторых случаях имеет смысл использовать внеэкранный холст чуть большего размера. Или даже основной холст чуть большего размера, обрезанный через overflow: hidden.
30 лет назад использование подобного подхода в играх было абсолютной нормой. Зачем перерисовывать весь фон при его движении, когда можно просто менять смещение экранного буфера и подрисовывать края при необходимости?
Написано специально для habr.com. Копирование или иное использование материала без письменного разрешения автора запрещено.Упс. Я уже скопировал в кеш браузера и использовал для просмотра с прочтением.
Надо было предупреждение в начало статьи ставить до перехода под кат.
И описать способ получения письменного разрешения автора.
P.S. Шутки шутками, но у Хабра есть зеркала, а также какое-то Соглашение с пунктами 4.8, 4.10 и другими.
в конце текста не хватает приписки типа «тестировалось на не разогнанном Ryzen 9 5900X».
Ну у меня всегда объект перерисовывается целиком — способа перерисовать кусок растра с которым мы контактировали я пока не нашел. Если вы знаете как это сделать на CANVAS — буду рад услышать и применить.
Вы же
CanvasRenderingContext2D.drawImage()
используете для рисования растра на канву, верно? Он умеет это всё из коробки.1. Запоминаем прямоугольную часть фона, на которой собираемся нарисовать спрайт;
2. Рисуем спрайт;
3. Пауза;
4. Восстанавливаем часть фона из памяти;
5. Запоминаем часть фона на новой позиции спрайта;
6. Рисуем спрайт на новой позиции…
и так далее.
При этом я тогда знать не знал, что такое слои. Тупо брал часть изображения прямо с экрана и помещал в память. Что мешает поступать аналогичным образом?
Боюсь спросить как этот движок будет А* реализовывать при таких нагрузках.
С их помощью можно кэшировать всю большую сцену, и перерисовывать только кусок куда надо.
Ну вообще для тайлового кеша — для каждого тайла нарисовать все что внутри него, там не нужно считать зависимости, надо просто знать в каком тайле какие персонажи.
Именно так кешируют части веб-страницы в браузерах.
А применимо к таким играм, само собой разделение фона и персов, персов всех каждый кадр заново рисовать. Это привет 2012 году, тогда такое везде использовали
Чем это
file : "img/" + xy + ".gif", // путь к файлу
отличается от этого
file : "img/merged_" + xy + ".gif", // путь к файлу
А почему отказались от готовой библиотеки, например PIXI.js? На мой взгляд неплохим решением был бы WebGL с текстурным атласом и анимацией в вершинном шейдере. Нет особого смысла в Javascript каждый кадр возиться с каждым объектом на экране, пусть этим занимается видеокарта — сегодня даже смартфоны могут железно рисовать сотни тысяч треугольников в секунду.
Хорошая статья! Автору спасибо)
Стоит ли в играх перерисовывать только ту часть CANVAS, которая изменилась? Или проще стереть все и нарисовать заново?