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

Итак, вот что у нас впереди:

• зачем нужны внешние утилиты (теория)
  
• высококачественные спреи (это просто!)
  
• пару слов о сжатии (теория)
  
• прозрачность (теория)
  
• мипмапы (теория)
  
• спреи с анимацией (это тоже просто!)
  
• спреи с «переливачкой» (а вот тут сложнее… и пока лишь поверхностные указания)

Обычно новички используют встроенную в саму игру возможность использовать свою картинку в качестве спрея. Однако игра делает это дело скверно. Не верите?

Взгляните на пример, увеличив его кликом:

Исходное изображение одно и то же; но слева - то, во что превращает его сама игра, а справа - наш качественный спрей.
Если вы не видите особой разницы в качестве, то может быть, вам и не нужен этот гайд? )

Для начала, попытаемся понять, что делает TF2 с нашими картинками. Создадим тестовую картинку без прозрачности размером 512х512 пикселей, и "скормим" её игре. После этого поищем свежий файл spray.vtf в каталоге Steam'а. Нашли? Окей... Его размер около 40 кб; откроем его в утилите VTFEdit.

Смотрим, что написано во вкладке «info». А написано там такое – тип сжатия DXT1, размер 256х256 пикселей. То есть, игра мало того, что уменьшила размер картинки, так еще и отчасти испортила её специфическим текстурным сжатием. Теперь подсунем игре картинку в формате tga, с прозрачными областями. Повторяем процедуру, и видим, что используется сжатие DXT5, размер картинки 256х256, размер файла 87 кб.

Как мы можем улучшить картинку? Да просто увеличим ее разрешение! Теоретически, мы можем использовать любое разрешение, вплоть до 4096х4096, но на практике мы ограничены размером файла. Слишком большие файлы игра попросту не отобразит. (И это к лучшему. Я с ужасом представляю себе загрузку гигантских много-мегабайтных спреев, если бы они были разрешены, и какую нагрузку бы это создавало серверу…) Что до практики - путем проб и ошибок легко можно выяснить, что разрешенный размер спрея < 500 кб. Вот и попытаемся использовать этот размер «на всю катушку»!

• В старые времена действительно действовало ограничение 256х256 и не больше 120 (?) Кб, но это было еще тогда, когда ТФ2 продавался за деньги и помещался на одном DVD. Новый лимит был введен осенью 2010 года. Мораль такова: не читайте древние гайды: плохому научитесь.

Для начала, надо побороться с принудительным изменением размера картинки. Нам таки потребуется уже упомянутый VTFEdit (его можно скачать здесь[nemesis.thewavelength.net]). В его меню – импорт – указываем нашу картинку с разрешением 512х512 – и выскакивает панель, управляющая преобразованием (это как раз то, что скрыто от нас в игре).

Давайте, для начала, поступим «неправильно» - укажем формат без сжатия, первый в списке (General – Normal Format и Alpha Format – тут как правило стоит указывать всегда одинаковый формат в обеих полях) – выберем RGBA8888 (что означает 4 байта на точку). Запишем спрей. Размер файла спрея – 1,4 Мб, почти в три раза больше допустимого. У-уупс! Такой спрей игра не покажет.

А вот теперь - сделаем всё так, как надо:

Закроем VTFEdit, и запустим его заново. Опять пытаемся импортировать нашу картинку. Но на этот раз выберем сжатие DXT5. Еще стоит обратить внимание на вот что: снять галочки с Resize и Generate Normal Maps, а еще лучше включить галочку Generate Mipmaps, и там выбрать Mipmap filter: Box (upd: нет, только не Box: у него в vtfedit кривая реализация, уж лучше Blackman или "Кайзер") и Sharpen filter: none.

Типичные настройки импорта в VTFEdit:


Кроме того, после импорта, в левой панели стоит взвести два флажка: "anisotropic filtering" и "no level of details". Фактически, это означает "игнорировать настройки детализации игры и показывать спрей всегда с максимальным качеством.

Записываем спрей. Размер файла – 340 кб. Ура! Наш высококачественный спрей готов. Конечно, сжатие DXT5 немного испортило картинку, но выглядит она в своих 512х512 все равно лучше, чем, например, та же картинка в 256х256 без сжатия.

Примеры спреев без- и со сжатием. Кликните для увеличения:
Слева: RGBA8888 (т.е., без сжатия), 256х256, размер файла 341 Кб.
Справа: DXT5 (сжатие с потерями), 512х512, размер файла - те же самые 341 Кб.

• RGBA8888 – формат без сжатия, каждая точка изображения представлена каналами цвета «RGB» и ещё каналом прозрачности «A» (альфа-канал). Т.е., «8888» - означает по 8 бит на канал. На выходе - 4 байта на точку.
  
• RGB888 – как предыдущий, но без прозрачности. Три байта на точку.
  
• BGR565 – цветовые каналы малой точности, без прозрачности. Два байта на точку. (В чистом виде не отображается в TF2)
  
• DXT5 – точки картинки группируются в блоки 4х4, и цвет точек блоков описывается вместе довольно странным алгоритмом. На выходе ~ 1 байт на точку.
  
• DXT1 – почти то же самое, что и DXT5, но без канала прозрачности. На выходе получается ~ ½ байтa на точку.
  
• Формат DXT1 с однобитной альфой, увы, не поддерживается игрой (upd: оказалось, поддерживается, но толку с этого мало, см. подробности в "неудачных экспериментах", ниже), и очень жаль, что так. (кажется, source engine специально игнорирует все форматы с однобитной прозрачностью) (upd: нет! виноваты кривые руки разрабочиков VTFEdit и vtex).

Остальные форматы рассматривать нет смысла.

А реально используются лишь RGBA8888, DXT5, DXT3 и DXT1.

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

Цифры для сравнения: картинка 512х512 без сжатия – 1 Мб (не годится по размеру для спрея), в DXT5 – 256 Кб, в DXT1 – 128 Кб.

Как же выбрать формат? Коротко говоря, если у нас есть большая картинка (512х512) с прозрачностью – выбираем DXT5, если прозрачности нет – DXT1; ну, а вот если оригинал картинки, из которой мы делаем спрей, размер имеет 256х256 и меньше - RGBA8888.

Сжатие RGB в DXT1..5 работает примерно так: картинка разбивается на квадратики 4х4. Для каждого квадратика выбираются два "крайних" цвета, оба сохраняются в формате RGB565. Из каждой из 16 точек квадрата сохраняются лишь 2 бита - они указывают, насколько далеко текущий цвет отстоит от "крайних" цветов. Т.е., фактически, внутри квадратика может быть только 4 цвета, и то, два их них будут чем-то средним между "крайними". На практике, это приводит к заметным искажениям лишь тогда, когда в одной точке сходятся 3 и более различных "ярких" цвета. В разделе "разное", ниже, есть некоторые дополнительные подробности о dxt-сжатии.

"Прозрачность" (и полупрозрачность) хранится в отдельном слое "A" (alpha-канал). И, соответственно, занимает место... до 1/4 в режиме без сжатия и до 1/2 второй в режиме со сжатием DXT3 и DXT5.

Необязательное: При создании спрея с прозрачностью хорошей идеей будет оставить вокруг изображения рамку в 1, а лучше 2 прозрачных или почти прозрачных пикселя. В противном случае, учитывая, что интерполяция текстур видеокартой непрерывна, мы увидим на противоположной стороне спрея следы от краевой текстуры - полоску, слабую, но всё-таки различимую.

Ещё необязательное: Также неплохой мыслью будет "чистка" невидимого изображения под альфой, а еще лучше - заполнение его пикселями цветов с границы прозрачности-непрозрачности. Такую операцию делает автоматически PhotoShop последних версий; выглядит она как характерные ореолы вокруг цветных объектов с прозрачностью; они видны, если скрыть альфа-канал в VTFEdit (в меню - "маска" вкл/выкл). Эта операция нужна для генерации мипмап лучшего качества, а так же, чтобы из под маски альфа-канала не "вылазили" соседние цвета, что иногда случается на картинках с резкой границей "альфы".

Разница между DXT3 и DXT5 состоит только в способе хранения "альфы". И хотя объем прозрачность занимает одинаковый в обоих случаях, способы ее представления различаются. В случае DXT3 мы имеем дело просто с 4-битной альфой на точку; никакого сжатия не применяется. В DXT5 используется механизм интерполяции, подобный сжатию RGB текстур DXT1 - для каждого элемента изображения 4x4 пикселя выбираются два предельных значения прозрачности, и для каждой точки внутри квадрата указывается относительное расстояние до этих крайних значений. В целом, техника DXT5 даёт более плавные тени, но могут случаться "рваные" края изображения спрея, в некоторых случаях, - и вот тогда на помощь придет DXT3.

Если взвести галочку "Generate Mipmaps", файл спрея резко начнёт занимать примерно на треть больше места.

Почему? Да потому, что эта галочка позволяет сохранить в теле файла спрея его уменьшенные со сглаживанием копии. Они показываются игре, когда игрок отдаляется от текстуры. Чем дальше точка зрения, тем меньший кадр достается из обоймы и предъявляется усталому взору игрока. Это нужно для того, чтобы картинка в отдалении неприятно не мерцала муаром – который видеокарта просто не может устранить; видеоакселераторы умеют растягивать текстуры, но не умеют уменьшать их. Поэтому уменьшение производится заранее, еще на этапе подготовки любой текстуры в игре.

Выглядит это внутри нашего спрея примерно так:

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

Что до подготовки мипмап в VTFEdit'е, на мой взгляд, лучший фильтр для мипмапов – "Box" c резкостью "none" или "sharpen soft". Дело в том, что алгоритм "Box" создан как раз для уменьшения картинки в кратное число раз, а именно так мипмапы и генерируются: каждая текстурка в них – уменьшенная вдвое копия предыдущей. UPD: Практика показала, что по-настоящему высококачественных алгоритмов изменения размера в составе VTFEdit-а увы, нет. Теперь я обычно пользуюсь для создания мипмап алгоритмом Blackman'а, c резкостью None. В таком случае резкости бывает маловато. Компенсировать этот эффект не выходит. Даже самый слабый алгоритм наведения резкости (sharpen soft) даёт слишком много резкости. Выходом могла бы служить выгрузка текстуры в DDS-формате (как при создании спреев-переливачек), и ручное составление мипмап, но увы, это слишком кропотливая работа, одна из тех, про которую говорят, что "игра не стоит свеч".

Нужны ли нам мипмапы? Иногда да, иногда нет. Если мы просто делаем качественный спрей 512х512 – мипмапы нужны, он будет лучше смотреться в игре. Но мы можем сделать ловкий «ход конём», отключить мипмапы (и не использовать прозрачность) - а это позволит засунуть в спрей изображение уже размером не 512х512, а 1024х512! В целом, сей ход даст вот что: чуть-чуть улучшится качество картинки вблизи, но ухудшится ее вид издалека. Нужно ли это нам? Решайте сами.

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

Подробности о назначении мимпап: http://ru.wikipedia.org/wiki/Mipmap

Ничего сложного. Просто отметьте несколько файлов при импорте в VTFEdit – и получите свою анимацию.

Наш главный «враг» - размер файла. Мы можем уменьшить его, применив сжатие (экономия 3/4 размера) и отключив mipmaps (экономия ~⅓ размера файла). Можно избавится и от прозрачности, чтобы получить вполтора раза больше места, если это уместно на конкретной картинке, разумеется. Или уменьшить размер кадра с 512х512 до 256х256 или даже еще ниже.

Вот некоторые цифры, полученные опытным путем, они помогут в создании анимации:

Темп анимации – 5 кадров в секунду. Кажется, это число изменить нельзя. (?)

• Анимация 512х512, сжатие DXT1, без альфы, без мипмап – влазит 3 кадра.
  
• Анимация 256х256, сжатие DXT1, без альфы, без мипмап – влазит 15 кадров (3 секунды «видео»).

Вы должно быть видели такие спреи – подходишь к ним ближе, и картинка изменяется.

Как это работает? В мипмапе, во всех её «кадрах», картинка должна быть одна и та же – только разного размера. Но если мы заменим один из кадров – получим именно то, что хотели.

Здесь нам потребуются некоторые специальные утилиты.

• PhotoShop – мы будем использовать плагин к нему.
  
• Nvidia Photoshop Plugin – позволяет Фотошопу записать картинку в формате dds – наш спрей в формате текстуры с мипмапами.
  
• Microsoft DirectX SDK – из него используется только утилита DirectX Texture Tool, удобное средство для замены mipmap-ов.
  
• VPKTool – конверсия из dds-формата в формат vtf.

Охо-хо! На этом месте мне вдруг стало лениво писать; лучше посмотрите картинки в английском гайде – вот тут - http://tf2.gamebanana.com/tuts/9038 (заметка «Distance Fading Sprays»). Там же есть ссылки на все необходимые утилиты.

* * *

Я позже напишу инструкцию подробную инструкцию, а пока пусть будет черновичок:

Готовим 2 картинки. (Можно больше, но надо учесть, что мипмапы где-то начиная с 4й практически невозможно разглядеть, настолько они мелкие, поэтому смысла мало).
Ресайзим/обрезаем картинки под 512х512.
Загружаем одну из картинок в Фотошоп; тут же выгружаем картинку в формате DDS (с включенными мип-мапами, ессно).
Загружаем это безобразие в DirectX Texture Tool. В нем можно листать мип-мапы клавишами Page Up / Page Down. Останавливаемся на той картинке, которую мы хотим заменить (как правило, на самой большой).
Заменяем через меню текущую картинку. (Menu - File - Open Onto This Surface...).
Записываем DDS.
Открываем DDS в VPKTool, и записываем его в формате VTF.
Опционально, открываем наш VTF в VTFEdit и доставляем нужные флаги (для улучшения качества, такие как No LoD, Anisotropic, Clamp S, Clamp T), записываем.

Всё - «переливачка» готова!

* * *

Где-то мне попадался еще другой способ формирования мип-мап; и тот, второй способ мне нравился больше; состав инструментов был почти таким же, но, кажется без directx sdk, а замена картинки производилась прямо в Фотошопе. Но что-то не могу это воспроизвести. Упоминаю я здесь потому, что взялся описывать качественные техпроцессы, так вот, этот способ был менее удобным, но качество на выходе давал лучше, потому что качество сжатия dxt у nvidia-вского плагина выше, чем у тулзы из микрософтовского сдк.

Даже не знаю, стоит ли писать столь очевидные вещи... но тем не менее: используйте качественный оригинал! Как правило, оригиналы популярных картинок и плакатов легко разыскать "поиском картинок" от Google. Пример. Слева - низкокачественная копия со следами JPEG-сжатия (очень портит плакаты, кстати), справа - высококачественный исходник.

VPKTool не устанавливает флаг “no level of details”, поэтому, если этот флаг нужен, спрей нужно открыть в VTFEdit, и установить его в нём. Картинка при этом не изменяется и не портится. Этот флаг нужен, чтобы показывать спрей с максимальным качеством, даже если игрок снизил разрешение текстур в настройках игры.
Кстати, а вы знаете, что делают игры, когда вы снижаете детализацию текстур в настройках видео-игр? Они просто отбрасывают самые большие из набора мипмапов! Большие мипмапы не загружаются в память; загружаются лишь маленькие мипмапы - это экономит память компьютера и видеокарты.

Картинка для спрея может иметь любой размер, важно лишь, чтобы итоговый размер файла не превышал 500 Кб, а каждая из сторон была кратна степени двойки, т.е., 64, 128, 256, 512, 1024 и т.д. Однако, в игре спрайт спрея все равно будет растянут до формы квадрата; а прямоугольник можно отобразить только используя альфа-канал, прозрачность. Но мы можем использовать уже упомянутый размер 1024х512 (или 512х1024) чтобы увеличить разрешение хотя бы по одной из сторон, и качество картинки в целом - тоже. Есть и некоторые "глюки" - иногда игра всё-таки показывает не-равносторонний спрей как прямоугольник, а не квадрат, но это происходит лишь на старых видеокартах в низкой детализации, да и то редко upd: как оказалось, это происходит при настройке в опциях видео... "multicore rendering" : OFF, т.е., шанс показать "неправильный" спрей выше, чем представлялось вначале, и, возможно, стоит действительно ограничиться 512х512. Пример отображения сильно-не-равностороннего (4096х128) спрея с разными настройками:

Форматы с малой битностью на канал, нечто в роде RGBA4444 и RGB565 (rgb565 вообще не отображается, как оказалось) немного неправильно интерпретируются игрой - цвет не получает полную яркость, а альфа - полную прозрачность. В результате картинка может выглядеть бледновато, и сквозь ее даже непрозрачные элементы видно немного стену под ней.

DXT - формат сжатия с потерями. Т.е., картинка портится при сжатии. Так вот, разные утилиты конвертируют картинку в этот формат с ощутимо разным качеством. Самые лучшие результаты дал... VTFEdit! Кажется, он использует современный движок nVidia c алгоритмом Сквиша (Squish) - фотошоп с нвидие-вским плагином дает результаты точь-в-точь как у него. На втором месте - микрософтовская конвертилка "DirectX Texture Tool" из ихнего SDK. Третье место делят всякие утилиты самодельщиков и хваленная (но устаревшая) nVidia-вская утилита "nvcompress" (2007 г.), показавшая на тестах отвратительные результаты. Неплохо сжимает и гуглевская утилита crunch (2012 г.). А по слухам, самое качественное сжатие собираются выдать японцы, смешивая использование нескольких алгоритмов сразу, и выбирая для каждой из групп точек лучший... Но на попробовать они это чудо не дают, т.к. собираются использовать его в своей новой PlayStation.
Почему я уделяю этому сжатию столько внимания? Да потому, что хочу получить идеальный результат, самый лучший, какой только возможно. ;) Однако, кажется, до идеала ещё далеко.
Примеры сжатия сложного для DXT компрессии изображения, кликните для увеличения:

Подробности о сжатии вы можете узнать здесь: http://www.gamedev.ru/code/articles/DDS_DXT1_DXT3_DXT5

Флажок PointSample в VTFEdit означает "отключить сглаживание текстур". Т.е., когда мы ткнемся носом в спрей с таким флагом, мы увидим не привычную "размазню", а "квадратики", как в старых играх вроде Doom. Иногда этот флажок бывает полезен для спреев низкого разрешения, например, с анимацией.
Пример - кликните для увеличения:

Здесь использован один и тот же крошечный спрей размером 32х32 пикселя. Строго говоря, у этих спреев даже файлы одинаковы - почти! - они отличаются лишь одним битом, который как раз означает взведенный флажок "Point Sample": слева он выключен, справа - включен.

Коротко: взводите эти флажки, если хотите получить спрей максимального качества.

Атрибуты Clamp S, Clamp T меняют режим «стыковки» текстур. При не-взведенных флажках работает режим «заполнение» («повторение)». При взведенных флажках (я пока не знаю, какой за что отвечает, поэтому ставлю оба), всё пространство за пределами текстуры будет заполнено (виртуально) ее последними пикселами с краёв. Это сильнее всего нужно на сервере (в картостороение), где можно указать масштабирование/поворот большой текстуры с прозрачностью по краям. Но даже для спреев эти атрибуты стоит взводить - именно они отвечают за то, чтобы с противоположного края текстуры не «протекали» цвета. (Извините, не могу это лучше сформулировать... рекомендую просто погуглить картинки про энтот самый «Кламп», например из гайда по OpenGL, и глядя на них, вы все поймете).

Вообще, vtf-формат, как я его понимаю, это контейнер в котором лежит одна или несколько dds-текстур и кое-какие дополнительные флаги. А vmt - какое-то дополнительное описание, и, поскольку мы в конечном итоге втаскиваем vtf-спрей не заменой файла, а открываем его в игре, vmt не нужен.

Плагин к Винде "VTF Shell Extensions" позволяет видеть превьюшки спреев в каталогах файлов, что бывает весьма полезно.

Скачать его можно тут: https://developer.valvesoftware.com/wiki/VTF_Shell_Extensions

Быстрый способ сделать спрей из комикса или карикатуры:
http://steamproxy.com/sharedfiles/filedetails/?id=317550128
Гайд для полных новичков:
http://steamproxy.com/sharedfiles/filedetails/?id=614711071

См.сразу следующий раздел: «DXT1A 1024x1020»

Формат позволяет сэкономить немного видеопамяти; в некоторых случаях за счет этого можно впихнуть в спрей картинку большего разрешения (512х512 -> 1024x512). В анимации, аналогичен простому DXT1, но позволяет использовать прозрачность, что облагораживает картинку; например, можно сделать, чтобы кадр видео выглядел как прямоугольник, а не квадрат.

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


Сам пока не делал, но вот добрые люди пишут, как: http://source.gamebanana.com/tuts/11009 («DXT With One Bit Alpha Animated Spray»).
Довольно удручающе выглядит требование использовать hex-редактор для создания анимации. ;)

На самом деле «стоны» можно свести к одному простому утверждению: когда разработка утилиты заброшена, а утилитой всё ещё пользуются, ну почему бы не открыть исходники? Это решило бы массу проблем.
Итак. Кривой VTFEdit не показывает взведенным флаг "one bit alpha", а должен бы, однако - альфу-то на картинке он видит, и управлять ею позволяет (Ctrl-M). Эх, вот если б VTFEdit понимал, что можно вскрыть DDS-текстуру (импорт - как отдельных картинок для анимации), но обжимать её в DXT заново уже не нужно, и мипмапы тоже заново генерировать ни к чему - можно было бы легко и анимацию устроить в формате DXT1A, и мипмамы генерировать высочайшего качества.

Утилиту "crunch[code.google.com]" мне пришлось использовать, потому что привычный многим разработчикам "nVidia Texture Tools for Photoshop" выдавал дикие баги на прозрачности в формате dxt1a, причем, если включить режим "запись dxt без оптимизации" - баги пропадали, но качество картинки падало ниже плинтуса. Еще - интересный побочный эффект использования crunch'а - кажется, его фильтры делают мимпамы лучше, чем VTFEdit. Кстати, по ссылке выше на GameBanana, тамошние бойцы признают наличие бага в плагинах и рассказывают, как его обойти.

DXT1A следует использовать только, если анимация не влазит; либо для увеличения разрешения вдоль одной из сторон картинки, в статике, если скажем, мелкий текст не читается. Если же всё и так работает... При простой замене сжатия DXT3 -> DXT1A мы видим, что размер нашего файла с изображением уменьшился с 349 Кб до 176 Кб; но реально это ничего не даст, т.к., как клиент, так и сервер TF2 сжимают эти изображения при передаче; почти пустой альфа канал в любом случае не даст выигрыша даже в скорости загрузки (выигрыш сжатого файла dxt1a по сравнению с dxt3/dxt5 всего лишь 8..10%).
Пример. Оценим читаемость текста в стандартной картинке 512х512 (слева) против 1024х512 в формате DXT1A (справа), кликните для увеличения:
Предупреждение: см.выше про multicore rendering, спреи 1024х512 (любые неравносторонние) могут быть неправильно показаны на некоторых компьютерах, что также добавляет бессмысленности их созданию без крайней на то необходимости.

Устроен этот формат текстур точно так же, как DXT1, но есть один нюанс: если в DXT3/5 сохранены как бы две отдельных плоскости изображения - отдельно альфа-канал и отдельно RGB, то в DXT1 существует только плоскость RGB, и ничего более. Окей, спросите вы, а как же они умудрились запихать в RGB информацию о прозрачности, в таком случае? Это тем более загадочно, учитывая, что мы точно знаем, как хранится информация в плоскости цвета - картинка разбивается на квадратики 4х4 пикселя, и под каждый такой квадратик выделяется строго 8 байт: по два байта на начальный и конечный цвета, и по 2 бита "распределения" на каждую из 16 точек (еще 4 байта). Ни одного лишнего битика там нет! Нет. На первый взгляд. ;) Следите за руками, пример: предположим, начальный цвет у нас белый, а конечный черный. И первая же точка, которую нам надо закодировать, черного цвета. Так вот, мы это можем сделать двумя способами: объявить начальный цвет белым, конечный черным, а заполнитель (цвет пикселя, из палитры 4 цветов (начальный, конечный, и два промежуточные, средние между ними)) указать 11(биты). Или наоборот, начальный цвет будет черным, а конечный белый, а заполнитель тогда будет 00(двоичное). Итоговая картинка от этого не поменяется. Но зато, у нас возникает один дополнительный бит для квадрата 4х4 - порядок цветов. И действительно, разработчики из S3 остроумно решили, что если объявлен формат текстуры DXT1A, то, грубо говоря, если начальный цвет > конечного (цвета - всего лишь цифры, к конце-то концов), то в этом квадратике прозрачности нет, а в противном случае - есть. (На самом деле там хитрее условие, чем просто больше-меньше). Если обнаружена прозрачность, то в квадратике уже не могут использоваться 4 цвета, используется только три, а "конечный цвет" объявляется прозрачным, и не отрисовывается. Увы, благодаря такому необычному решению, на границе прозрачности могут появляться дополнительные артефакты, т.к., цветовое пространство в этих местах реально уже, чем у DXT3 или DXT5.

Внезапно™ оказалось, что требование к кратности стороны текстуры быть степенью двойки (привычные 64, 128, 256, 512, etc) - это требование компрессора (стороннего!), а не распаковщика - т.е., игра прекрасно может скушать текстуры любого размера, кратные 4х4 пикселям (ячейка DXT).

А это в свою очередь значит, что можно сделать почти квадратный холст 1024x1020, который аккуратно влезет в ограничение 512 Кб при компрессии DXT1/DXT1A (без прозрачности или однобитовая прозрачность), без мипмап; - ибо такой спрей будет весить 510 Кб.

Как это сделать? С помощью он-лайн утилиты, описанной здесь https://redd.it/5e9p01 и доступной по адресу {LINK REMOVED}https://mishcat.tk/sprays/ (дубль: mishcat . tk / sprays /)

Единственный хинт с моей стороны: если готовите спрей с прозрачностью, лучше самому, вручную в CQ сделать конвертацию "полупрозрачность - однобитовая прозрачность", контролируя визуально качество границ (в CQ - правая кнопка на холсте, Convert..., Aplha to Simple Transparency).

Неудачей закончился опыт с YCoCg-компрессией. Идея такова - используется DXT5, но для непрозрачных картинок. Канал прозрачности замещается, грубо говоря, дополнительным каналом цвета. Результат - практически полное отсутствие артефактов сжатия. Такие DDS текстуры умеет записывать специальный плагин к Gimp'у. Однако, преобразовать в VTF этот DDS не получилось. TF2 не смог воспроизвести текстуру. Может быть, есть какой-то способ подсунуть такие файлы игре, а может, движок TF2 совсем не поддерживает текстуры такого типа.

Также неудачно завершился эксперимент по созданию 1024х512 текстуры с мипмапами. Идея была записывать dds-текстуру с мипмамами, но не с полным набором, а скажем лишь с двумя-тремя. Это позволило бы втиснутся в ограничение на размер файла, несколько улучшив качество спрея вдалеке, и также - создать качественный спрей-"переливачку". И отчасти идея даже сработала... спрей загрузился в игру, но... Но, во-первых, VPKTool криво его сконвертировал, с каким-то мусором сверху. Во-вторых, в игре показывались мои мип-мапы (да, с "мусором"), но кроме них, почему-то вылазили и дополнительные, содержащие уже полную мешанину пикселей. Может быть, Valve не понимает формат с ограниченным к-вом мипмап?

Теоретически возможно создать анимированную "переливачку". Но... как? Ни одна из утилит, которыми я располагаю, не позволяет упаковать анимацию из нескольких кадров dds напрямую в vtf... (upd: Хм... теоретически хак парней с gamebanada для создания dxt1a анимации может быть применим и к мипмапапам... надобно испытать!)

Если для ваших игр стало мало клиента ТФ2, - и вы решили сделать свой сервер, знайте - возможности "серверных" текстур значительно шире, чем то, что можно подсунуть серверу в качестве спрея.

Во-первых, у нас совершенно нет ограничений на размер файла. Хотите 2048х2048 текстурку, да еще и анимированную? Да пожалуйста! Но, естественно, "злоупотреблять" не стоит: у клиента могут начаться проблемы: либо ему надоест ждать слишком долгой загрузки серверного контента, либо у него будет тормозить клиент игры, что еще хуже.

Во-вторых, vmt-файл теперь создаем мы, а не сервер, а поэтому мы можем там упомянуть что угодно: мастшабирование текстуры, мультитекстурирование (многослойные текстуры), автономное движение (скроллинг), автономное вращение; задание частоты кадров анимации, безумные и бесполезные distance field texture, баловство с z-буффером, баловство с освещением и т.д. и т.п. Мы можем почти ВСЁ! Пожалуй, лучше будет сосредоточиться на обзоре (будет ниже) всех возможностей, которые относительно легко реализовать.

В-третьих, мы наконец-то можем свободно использовать не-равносторонние текстуры, например, 512x128 - не опасаясь, что текстура будет растянута до формы квадрата.

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

И, минусы: 1) Почему-то не работает DXT1A (экономичная однобитная альфа) - несмотря на то, что в спреях она отлично зарекомендовала в последнее время. 2) Нам придется серьезно озаботится созданием vmt-файлов; как я вижу, новичкам они непонятны.

Ниже будет рассмотрено НЕ создание карт и их редактирование, а украшение уже ГОТОВЫХ карт своими «перделками и свистелками».

Что вообще мы можем сделать на своем сервере, не перекомпилируя карты?

- повесить декали на стенки (всякие плакатики, граффити, фурнитуру) - плагин map-decals;
- показать юзеру картинку на весь экран - плагины funcommandsX, screen-overlays;
- прицепить к юзеру всякие спрайты - это я пока не изучал;
- заменить текстуры моделей - это тоже пока не изучено мной;

(...продолжение наверное следует...)