2009-08-14 1 views
2

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

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

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

Редактировать: Я думаю, для уточнения. Если у меня есть, например, объект, в котором есть 2 анимации из 5 кадров, это простой лист спрайта для создания и организации, его простая сетка 2x5 (или 5x2 в зависимости от того, как вы ее выкладываете). Но проблема в том, что теперь эти 2 анимации нужно поворачивать в 32 направлениях. Это означает, что в конце будет 320 отдельных спрайтов. Я собираюсь сказать это (и исправить меня, если я ошибаюсь), так как меня беспокоит производительность и частота кадров, вращая спрайты «на лету», каждый отдельный кадр не является вариантом. Итак, как организовать эти 320 спрайтов, которые составляют эти 2 анимации? Было бы лучше, чтобы

  • думать о нем, как 32 2x5 спрайтов листы
  • разделить спрайты листа на отдельные кадры, а затем массив 32 различных направлений в кадр (так 10 массивов 32 направленных спрайтов)
  • Другое ....?
  • Не имеет значения?

Благодаря

ответ

1

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

2

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

Для примера кода, ознакомьтесь с спрайтом Chimp в этом pygame tutorial. Он вращает спрайты, когда шимпанзе «головокружение».

+0

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

4

32 направления для спрайта преобразуются в 32 оборота на 11,25 градуса.

Вы можете уменьшить количество предварительно просчитанных изображений до 8, вы вычисляете только первые 90 градусов (11.25, 22.5, 33.75, 45.0, 56.25, 67.5, 78.75, 90.0) и динамически выполняете флип-операции. Флипсы намного быстрее, потому что они существенно изменяют порядок копирования изображения из буфера.

Например, при отображении изображения, которое повернуто на 101,25 градуса, загрузите предварительно просчитанное изображение 67,5 градуса и поверните его вертикально.

Я просто понял, что это работает только, если ваш графический симметрична ;-)

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

+0

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

Смежные вопросы