PCX — растр ZSoft Paintbrush

PCX — растровий формат з індексованими кольорами з початку 90-х. Total Annihilation використовує його для портретів юнітів (unitpics/*.pcx), панелей інтерфейсу й кількох зображень попереднього перегляду мап. У TA: Kingdoms PCX розміром 1×1 ще й слугує носієм палітр окремих сторін: рушій читає вбудовану палітру з PCX і застосовує її до сусіднього файлу анімації .taf.

unitpics/armcom.pcx → PNG (палітра TA)

kbot pcx describe unitpics/armcom.pcx        # full header + what TA will do with it
kbot pcx info     unitpics/armcom.pcx        # one-line summary
kbot pcx convert  unitpics/armcom.pcx -f png -o armcom.png

import "github.com/coreprime/kbot/formats/pcx"

f, _ := os.Open("unitpics/armcom.pcx")
defer f.Close()
r, _ := pcx.LoadFromReader(f)
fmt.Println(r.Width(), "×", r.Height(), "@", r.BitsPerPixel(), "bpp")
img, _ := r.Decode()                          // returns image.Image

PCX — загальновідомий формат, а не формат Cavedog#

Cavedog не вигадувала PCX — він старший за Windows. Тож, на відміну від HPI, GAF чи TNT, на момент виходу TA структура на диску вже була відкритою специфікацією. Ця сторінка описує лише те, що стосується PCX, знайденого в інсталяції TA; повну специфікацію див. в оригінальному технічному довіднику ZSoft.

Підмножина, що стосується TA:

• 8 бітів на піксель, 1 площина — лише палітрові зображення. 24-бітні, 4-бітні й багатоплощинні варіанти існують, але Cavedog таких не постачає.
• Кодування RLE (Encoding = 1). PCX без стиснення формально допустимі, але трапляються рідко.
• 256-колірна палітра VGA, дописана після піксельних даних, перед якою стоїть один байт-маркер 0x0C. TA завжди використовує цю структуру; 16-колірна палітра в заголовку ігнорується.

Заголовок (128 байтів)#

typedef struct {
    uint8  Manufacturer;     // Always 0x0A (ZSoft signature)
    uint8  Version;          // 0–5 (TA images are typically version 5)
    uint8  Encoding;         // 1 = RLE
    uint8  BitsPerPixel;     // Bits per plane per pixel (8 in TA)
    uint16 XMin, YMin;       // Image bounds (inclusive)
    uint16 XMax, YMax;
    uint16 HorzDPI, VertDPI;
    uint8  Palette16[48];    // Legacy 16-colour palette (unused in TA)
    uint8  Reserved;
    uint8  NumPlanes;        // 1 for 256-colour images
    uint16 BytesPerLine;     // Encoded bytes per scan line per plane
    uint16 PaletteInfo;      // 1 = colour, 2 = grayscale
    uint16 HorzScreen, VertScreen;
    uint8  Filler[54];       // Pad to 128 bytes (Cavedog leaves it zeroed)
} PCXHeader;

Обчислений розмір зображення#

Width  = XMax − XMin + 1
Height = YMax − YMin + 1

Гра обчислює їх у повних цілих числах, тож ширина 65 536 можлива, і відхиляє файл, максимум якого менший за мінімум. Стандартний читач вважає кінцеві байти кожного рядка розгортки (BytesPerLine − Width) доповненням; гра — ні (див. нижче).

Піксельні дані RLE#

Для кожного з Height рядків розгортки повторюйте:

while (decoded < BytesPerLine) {
    uint8 b = read();
    if ((b & 0xC0) == 0xC0) {
        int count = b & 0x3F;        // 1..63 reps
        uint8 value = read();
        emit(value, count);
    } else {
        emit(b, 1);                  // literal
    }
}

Далі стандартний читач відкидає кінцеве доповнення (BytesPerLine − Width байтів). TA 3.1c натомість декодує рівно Width пікселів на рядок, ідучи безперервно від заголовка, тож будь-яке доповнення стає першими пікселями наступного рядка; серія, що виходить за кінець рядка, там і обрізається.

Вбудована палітра (256 записів × 3 байти)#

Після останнього байта RLE файл закінчується 769 байтами:

   1 byte  : marker, always 0x0C
 256 × 3   : R, G, B per entry (8-bit each)

Щоб знайти палітру, не розбираючи RLE, перейдіть до fileSize - 769 і перевірте маркер. Стандартний читач без маркера повертається до 16-колірної палітри із заголовка (попередні перегляди kbot використовують палітру TA). TA 3.1c завжди бере останні 768 байтів як палітру, хоч з маркером, хоч без нього, і відхиляє файл, коротший за 896 байтів (заголовок плюс палітра).

Що TA 3.1c робить із PCX#

Гра читає із заголовка лише поля виробника, версії й меж:

• Вона завантажує лише версію 5 і відхиляє файл, у якого XMax/YMax менший за мінімум або який коротший за 896 байтів.
• Вона ігнорує Encoding, BitsPerPixel, NumPlanes і BytesPerLine: кожен файл декодується з RLE як 8-бітні одноплощинні дані, по Width байтів на рядок. Тому 24-бітний файл показується як сміття, а рядки з доповненням зсуваються.
• Палітра — це останні 768 байтів, хоч би що стояло перед ними.
• Фони малюються непрозорими: індекс палітри 0 — звичайний чорний.
• Піксельні дані, що закінчуються передчасно, її не зупиняють: вона продовжує малювати з останнього прочитаного байта.

Графічні редактори читають такі файли стандартним способом, тож фон із мода може правильно виглядати в редакторі (і в попередньому перегляді kbot), але неправильно — у грі. kbot pcx describe завершується розділом TA 3.1c, де перелічено кожну відмінність (pcx.Reader.Compat у kbot-io); MCP-інструмент pcx_describe повертає її як game_loads / game_issues, а оглядач ресурсів показує значок поруч із попереднім переглядом:

TA 3.1c:
  ⚠ The game will load this file but draw it differently:
    ⚠ BytesPerLine is 4 but the width is 3: the game ignores BytesPerLine and decodes 3 bytes per row, so the rows shift

Розібраний приклад — unitpics/armcom.pcx#

$ kbot pcx describe unitpics/armcom.pcx
Manufacturer:  0x0A
Version:       5
Encoding:      1 (RLE)
BitsPerPixel:  8
Planes:        1
Bounds:        (0,0) - (95,95)   →  96 × 96 px
BytesPerLine:  96
Palette:       embedded (768 bytes after 0x0C marker)
Unique colors: 41

Це все, що потрібно, щоб відрендерити файл вручну: зображення 96×96, використано 41 різний індекс палітри, палітру дописано в кінці. kbot pcx convert -f png експортує його як палітровий PNG, щоб індекси кольорів пережили round-trip назад у PCX.

TA: Kingdoms — прийом із «PCX-палітрою»#

Коли ви конвертуєте .gaf із TA для TA: Kingdoms, рушію потрібна палітра, але в .taf (перейменованому .gaf) її немає. Прийом полягає в тому, щоб покласти поруч із .taf PCX розміром 1×1 з тим самим базовим ім'ям файлу:

ui/mywidget.taf      ← animation data
ui/mywidget.pcx      ← 1×1 paletted PCX carrying the 256-colour palette

Рушій читає вбудовану палітру mywidget.pcx і ігнорує його піксель. Для анімацій юнітів і об'єктів палітра неявно визначається стороною (Aramon, Taros, Veruna, Zhon); для анімацій інтерфейсу ви кладете окремий PCX для кожної послідовності.

Найпоширеніший підводний камінь тут — використання палітри, експортованої з PSP: її значення RGB трохи відрізняються від канонічної палітри TA, і на деяких послідовностях це може призвести до падіння TA:K. kbot pal swatch вивантажить будь-яку палітру в PNG, щоб ви могли порівняти її з еталоном.

Підводні камені#

• Гра використовує останні 768 байтів як палітру незалежно від того, чи стоїть перед ними маркер 0x0C. Стандартні читачі без маркера повертаються до 16-колірної палітри із заголовка.
• У TA завантажується лише версія 5.
• Поле заголовка PaletteInfo ненадійне. Вважайте його лише рекомендаційним; припускайте, що палітра кольорова, якщо тільки не у кожному записі вбудованої палітри R==G==B.
• Файли unitpics/*.pcx у TA мають розмір 96×96 за домовленістю — формат цього не вимагає. Моди інколи постачають більші або неквадратні портрети.

Типові розміри#

Див. також#

• PAL — коли палітра натомість міститься в окремому файлі.
• GAF — файли .taf у TA: Kingdoms поєднуються з PCX-носієм палітри.
• Глосарій — paletted image, embedded palette.