Как не копировать поверхность уровня каждый кадр в червячной игре?

Я работаю над игрой, которая имеет разрушаемую местность (как в игре Worms или Scorched Earth) и использует точное определение столкновений с помощью масок.

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

Есть ли способ избежать копирования всей поверхности уровня в каждом кадре и по-прежнему иметь возможность использовать инструменты идеального столкновения пикселей, найденные в pygame?

Я попытался сначала скопировать поверхность уровня, а затем скопировать каждый спрайт на экране (с их координатами блитов, настроенными камерой, за исключением персонажа игрока, координаты которого статичны), но в этом случае система обнаружения столкновений разваливается, и я могу '' Кажется, я не могу это исправить.

ОБНОВИТЬ

Мне удалось заставить его работать следующим образом: при рисовании спрайтов я конвертирую их координаты игрового мира (которые в основном являются координатами относительно начала растрового изображения уровня) в экранные координаты (координаты относительно камеры, которая в данный момент является видимая область уровня).

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

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


person Kiril    schedule 03.05.2012    source источник


Ответы (1)


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

  1. Сохраните копию фона за кадром, как вы это делаете сейчас.

  2. Выделите рабочее растровое изображение того же размера, что и экран.

  3. Для каждого спрайта вычислите ограничивающий прямоугольник (ограничивающий прямоугольник) для его новой и старой позиций.

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

  5. Сгруппируйте все ограничивающие рамки в наборы, которые перекрывают друг друга. Все они могут оказаться в одном наборе (когда спрайты расположены близко друг к другу), или каждая ограничивающая рамка может быть в наборе отдельно (когда спрайты далеко друг от друга).

  6. Скопируйте фон в области рабочего растрового изображения, соответствующие каждому набору ограничивающей рамки.

  7. Скопируйте спрайты для каждого набора в рабочее растровое изображение в их новых позициях (конечно, в правильном z-порядке!).

  8. Наконец, скопируйте готовое закадровое растровое изображение на поверхность отображения, установите ограничивающую рамку, установив ограничивающую рамку.

Такой подход сводит к минимуму объем копирования, которое вам нужно сделать, как фона, так и спрайта. Если спрайты малы по сравнению с областью отображения, экономия должна быть значительной. В худшем случае все спрайты расположены по диагонали, едва перекрывая друг друга. В этом случае вы можете захотеть переключиться на более обобщенную ограничивающую фигуру, чем прямоугольник. Взгляните на QuickDraw Regions в качестве примера: Википедия Обсуждение / a> Источник.

Теперь вы можете подумать, что работа по группировке ограничивающих прямоугольников в наборы - это операция O (n ^ 2), и вы были бы правы. Но он растет только с квадратом количества спрайтов. 16 спрайтов подразумевают 256 сравнений. Это, вероятно, меньше работы, чем один спрайт.

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

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

person Randall Cook    schedule 10.05.2012