В XNA, когда уместно рендерить ваш игровой контент, используя несколько спрайтов? До сих пор я никогда не использовал более одного, и никогда не замечал никаких недостатков в этом подходе.
В каких ситуациях было бы необходимо использовать несколько спрайт-пакетов?
Очень мало случаев, когда необходимо использовать несколько SpriteBatches. Одним из примеров, которые я вижу многократно, является ситуация, в которой вы хотите применить различные постобработки/визуализации к различным наборам спрайтов, для чего требуется отдельный SpriteBatch для каждого набора.
Обычно считается хорошей практикой использовать только одну партию, если это вообще возможно, поскольку рисование как можно большего количества в одной партии намного более результативно, чем распространение работы по нескольким партиям. Кроме того, поскольку вы можете управлять только порядком сортировки в пределах одного SpriteBatch, это может затруднить (или невозможно) контролировать глубину между спрайтами из разных партий.
Вкратце: существуют мыслимые ситуации, в которых вы, возможно, захотите это сделать, но это не все, что обычно и в целом вы должны придерживаться одного SpriteBatch, если не знаете, что не можете выполнить то, что хотите, не используя больше чем один.
Здесь - хороший пример того, когда использовать более 1 SpriteBatch (блог Shawn - как обычно - окончательный источник).
SpriteBatch фактически не делает никакого чертежа, пока вы не вызовете метод End. Это означает, что вы можете начинать несколько совпадающих партий с разными настройками, рисовать спрайты в любом порядке, используя любую комбинацию экземпляров партии, и управлять тем, какой порядок обрабатывается всем содержимым каждой партии, путем упорядочения ваших вызовов End.
Обратите внимание, что этот пример посвящен оптимизации производительности для сцены с альфа-смешиванием и спрайтами, отсортированными по глубине. Когда (или, вернее, если) вы столкнетесь с проблемами производительности, может быть что-то выиграть, используя несколько SpriteBatches. До тех пор, вы, вероятно, лучше не считаете его простым.
В случае с DrawableGameComponents также может быть проще иметь SpriteBatch для DrawableGameComponent вместо того, чтобы пытаться передать это.