Разработка игры на JavaScript-холсте

Question

У меня была действительно озадачивающая медленная проблема с игрой, над которой я работаю, вероятно, потому что я не уверен, как обрабатывать графику (скорее всего, ответственную за замедление) в javascript, не используя стороннюю структуру, такую ​​как Phaser/ImapactJS/EaselJS и т. Д.) *. Ниже приведена нижняя часть того, как я приближаюсь к своей графике. Я был бы очень благодарен за некоторые советы или методы, как это сделать правильно.

• Моя игра плитка основе - с использованием плитки, разработанные на 500x500 пикс , потому что я хочу, чтобы отобразить прилично на устройствах с высоким разрешением.
• Я использую spritesheet для загрузки всех (большинства) моих плит до запуска основного цикла. Это изображение примерно 4000 x 4000 (поддерживая его ниже 4096, потому что размер текстуры для графических процессоров больше, чем этот).
• Затем я использую функцию drawImage для циклического перехода и рисования каждой плитки на части холста с использованием информации (w, h, x, y), хранящейся в массиве плитки. Я делаю это в каждом цикле основного цикла, используя мою функцию drawMap.
• Карта в настоящее время 6x6 плиток размером
• Символьный спрайт также загружается и наносится на холст после того, как карта была нарисована. Символ отображает другой кадр анимации в каждом цикле основного цикла. Есть множество анимаций для символа, каждый из которых содержится в одном и том же спрайте.
  • Спрайт лист символов примерно 4000x3500
• Символ примерно 350x250 PX

• Другие объекты также использовать один и тот же лист спрайтов. В настоящее время существует только один объект.

  Возможно полезные вопросы:

• я использую слишком много spritesheets или слишком мало?

• Должен ли я рисовать что-либо только в том случае, если его координаты находятся в границах экрана?
• Как мне организовать сбор мусора? Нужно ли устанавливать объекты изображений в null, когда они больше не используются?

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

* Обратите внимание, что я планирую перенести игру JS в cocoonJS, которая обеспечивает ускорение графики для элемента canvas на мобильном устройстве.

** Если вас интересует, пожалуйста, посетите мой Patreon page для удовольствия!

Answer 1

Здесь вы задали много вопросов, я рассмотрю те, с которыми столкнулся. Я хотел бы начать с очень ясно говорят,

Используйте профайлер

выяснить, является ли каждая вещь вам рекомендуется делать, никто, делает улучшение. Если мы не будем работать над вашим кодом, мы можем дать вам только советы о том, как его оптимизировать.

Как я могу собирать сборку мусора? Нужно ли устанавливать объекты изображений в null, когда они больше не используются?

Если вы больше не пользуетесь объектом, установка его ссылка на null может означать, что это приведет к сбору мусора. Наличие нулей вокруг не обязательно хорошо, но это не входит в сферу этого вопроса.

Для высокопроизводительных приложений вы хотите избежать слишком большого выделения и, следовательно, слишком большой активности сбора мусора. Посмотрите, что говорит ваш профайлер - хром-профилировщик может рассказать вам, сколько процессорного времени занимает сборщик мусора. На данный момент, возможно, все в порядке.

Затем я использую функцию drawImage для циклического перехода и рисования каждой плитки на часть холста с использованием информации (w, h, x, y), хранящейся в массиве плитки. Я делаю это в каждом цикле основного цикла, используя мою функцию drawMap.

Это довольно медленно - вместо этого подумайте о том, чтобы нарисовать текущий на экранных плитках фоновый холст, а затем только рисовать области, которые ранее были закрыты.

Например, если ваш игрок идет влево, в левой части экрана будет много фрагментов, которые появились в поле зрения; вам нужно будет нарисовать фоновый буфер на экране, смещать для учета движения, а затем нарисовать недостающие фрагменты.

Моя игра плитка основы - с использованием плитки, разработанной на 500x500 пикселей, потому что я хочу, чтобы отобразить прилично на устройствах с высоким разрешением

Если я интерпретирую это право, ваши плитки 500x500px в диаметре, и вы рисуете маленькие число из них на экране. а затем для устройств без такого высокого разрешения рендеринг холста будет масштабировать их. Вы действительно хотите рисовать пиксели 1: 1 на каждом устройстве.

Можете ли вы вместо этого иметь большее количество мелких плит на экране - таким образом, избегая дополнительного рисования по краям? Вероятно, плитки вокруг краев иногда будут рисовать только несколько пикселей одного края, а остальная часть изображения будет обрезана в любом случае, так почему бы не разбить их дальше?

Должен ли я рисовать что-либо только в том случае, если его координаты находятся в границах экрана?

Да, это очень распространенная и хорошая оптимизация. Вы обнаружите, что это имеет большое значение.

Я использую слишком много спрайтов или слишком мало?

Я обнаружил, что, когда у меня есть небольшое количество листов спрайтов, большой удар по производительности - это когда я часто переключаюсь между ними. Если в течение одной фазы вы рисуете все ваши персонажи из character_sheet.png, а затем нарисуйте все растения из plant_sheet.png, все будет в порядке. Переключение между ними может вызвать множество проблем, и вы увидите замедление. Вы узнаете, что это происходит, если ваш профилировщик говорит вам, что drawImage занимает большую часть вашего кадра.