Почему разработчики игр помещают много изображений в одно большое изображение?

Question

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

Я также видел несколько больших библиотек JavaScript с графическим интерфейсом, таких как ext.js, использующих эту технику. В ext.js есть большое изображение, содержащее много маленьких.

Одна вещь, которую я заметил, такова: независимо от того, насколько маленьким является мое PNG-изображение, Finder на Mac всегда говорит мне, что он потребляет не менее 4 КБ. Что чертовски много, если у вас всего 10 пикселей.

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

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

Или это лень, потому что думать об очень многих именах файлов утомительно?

Есть ли название этой технике? И как эти маленькие изображения отделяются от большого во время выполнения?

Answer 1

Это называется spriting - и для этого есть разные причины.

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

Эффект такого же типа может быть видимым в других сценариях - например, может быть более эффективно хранить и загружать один большой файл изображения, чем несколько маленьких, в зависимости от файловой системы. Это полностью помимо от любой эффективности, полученной с точки зрения необработанного "общего размера файла", и связано с накладными расходами на файл (запись в каталоге, размер блока и т. Д.). Это немного похоже на издержки «на запрос» в веб-сценарии, но из-за немного других факторов.

Answer 2

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

OpenGL и Direct-X получают снижение производительности, когда вы рисуете с одного изображения (текстуры) и переключаетесь на другое, поэтому мы упаковываем несколько изображений в одно большое изображение, а затем мы можем нарисовать несколько (или сотни) изображений и никогда переключать текстуры. Это не имеет ничего общего с размером файла 4K (или не имеет значения через 15 лет).

Кроме того, до самого недавнего времени текстуры должны были иметь степень 2 (64, 128, 256), и если в вашей игре было много изображений нечетного размера, это много потерянной памяти. Упаковка их в одну текстуру может сэкономить много места.

Answer 3

Использование 4 КБ является побочным эффектом хранения файлов на диске. Наименьший возможный адресуемый бит памяти в файловой системе - это блок, который обычно имеет фиксированный размер 512, 1024, 2048 и т. Д. Байтов. В вашем Mac это 4k блоков. Это означает, что даже для 1-байтового файла потребуется физическое пространство не менее 4 КБ, так как файловая система не может адресовать какой-либо блок хранения МЕНЬШЕ, чем 4 КБ.

Причины этих «больших» блоков различны, но большая из них заключается в том, что чем более «гранулированной» становится ваша адресация (чем меньше блоки), тем больше места вы тратите на индексы, чтобы увидеть, какие блоки назначены каким файлам. , Если бы у вас были блоки размером 1 байт, то для каждого байта данных, которые вы храните в файле, вам также нужно было бы хранить информацию об использовании в метаданных файловой системы стоимостью более 1 байта, и вы бы потеряли по крайней мере ПОЛОВИНА вашего хранилища только на индексах.

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

Answer 4

Еще одна причина прошлых дней была паллетами.

Если бы вы сделали одно изображение, вы могли бы оформить его одним поддоном. Цвет = 14 = светло-серый с оттенком зеленого.

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

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

С помощью этого метода все еще выполняется множество простых анимаций, таких как огонь, дым, водопровод.

Answer 5

Причины немного отличаются в разных средах.

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

При извлечении данных с хороших старых механических жестких дисков для хорошей производительности чтения требуются непрерывные данные. Если вы сохраняете данные в большом количестве файлов, вы получаете дополнительное время поиска для каждого файла. Существует также размер блока для рассмотрения. Файлы сделаны из блоков, в вашем случае 4 КБ. При чтении файла из одного байта вам все равно нужно прочитать целый блок. Если у вас много маленьких изображений, вы можете собрать их целую кучу в один блок диска и получить их все одновременно, как если бы в блоке было только одно маленькое изображение.