ModdingWiki - User contributions [en-gb]

Dynablaster

2022-08-01T05:36:11Z

Aybe: Add Dynablaster sprite sheets

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}
{{NoModdingInfo}}

== File formats ==

The IMG files in the GFX directory are sprite sheets in [[LBM Format]] with most having a corrupt header.

The following C# program will create corrected copies of them as .LBM files:

<source>

using System.Buffers.Binary;
using System.Text;

var paths = Directory.GetFiles(Environment.CurrentDirectory, "*.img");

foreach (var path in paths)
{
using var src = File.OpenRead(path);
using var tgt = File.Create(Path.ChangeExtension(path, ".lbm"));

src.CopyTo(tgt);

tgt.Position = default;

using var writer = new BinaryWriter(tgt, Encoding.Default, true);

var length = (int)src.Length - 8;

if (BitConverter.IsLittleEndian)
{
length = BinaryPrimitives.ReverseEndianness(length);
}

writer.Write(Encoding.ASCII.GetBytes("FORM"));
writer.Write(length);
writer.Write(Encoding.ASCII.GetBytes("ILBM"));
writer.Write(Encoding.ASCII.GetBytes("BMHD"));
}
</source>

File:Dynablaster.png

2022-08-01T05:35:28Z

Aybe:

Quarantine

2021-11-26T22:47:01Z

Aybe: Levels (preliminary)

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
| Demo = No
}}

'''Quarantine''' is a vehicular first person shooter set in a dystopian city. It was developed by [[:Category:Imagexcel|Imagexcel]] and published by [[:Category:GameTek|GameTek]] in 1994.

The game's executable is a 32-bit [[Linear Executable (LX/LE) Format|Linear Executable]] loaded by the DOS4GW 16-bit extender. It was built with the Watcom C/C++ tool suite.

{{BeginGameFileList}}
{{GameFile
| Name = *.FLI
| Format = [[FLIC Format]]
| KnownFormat = Yes
| Desc = Animations
}}
{{GameFile
| Name = *.IMG
| Format = [[Graphics Interchange Format|GIF]] with modified signature ("<tt>IMAGEX</tt>" instead of standard "<tt>GIF87a</tt>")
| KnownFormat = Yes
| Desc = Fullscreen/backdrop graphics
}}
{{GameFile
| Name = *.SPR
| Format = Simple package of [[Raw VGA Image]]s
| KnownFormat = Yes
| Desc = Sprites
}}
{{EndGameFileList}}

[[Category:GameTek]]
[[Category:Imagexcel]]
[[Category:3D]]
[[Category:First-Person Shooter]]

=== FARE[?].ENC ===

Transcode the file, XOR-ing every byte read with 0x55, the file now looks like a structured text file:

# the person talking, matched with regex <code>^\s*/\s*(\P{C}+)$</code>
# the person quotes, matched with regex <code>^\s*("\P{C}+",?)\s*$</code>
# goto step 1, repeat until EOF

Example:

<source>
/ PROFESSIONAL
"SO, UH. DO YOU THINK YOU COULD GIVE ME A RIDE LITTLE BUDDY? I'M IN A BIT OF A RUSH.",
</source>

== Levels (preliminary) ==

Each level is constituted of three files, e.g. CITY.BLK, CITY.BSP, CITY.MAP.

=== *.MAP ===

# read an [[UINT16LE]], this is the map width
# read an [[UINT16LE]], this is the map height
# follows <code>width * height</code> tiles as [[UINT16LE]]

== Credits ==

[[User:aybe|aybe]] for the ENC format.

Quarantine

2021-11-26T22:15:11Z

Aybe: Reversed ENC format :)

File format data types

2021-09-26T14:49:54Z

Aybe: Add BitConverter.IsLittleEndian

This is a list of all the data types used in the file format descriptions on the wiki. They are loosely based on common C/C++ data types, and should be used throughout the wiki for consistency.

== Type list ==

==== Numeric values ====

{|class="wikitable"
!Data type!!Description
|-
|UINT8||Unsigned 8-bit integer
|-
|UINT16LE||Unsigned 16-bit integer in little-endian format
|-
|UINT16BE||Unsigned 16-bit integer in big-endian format
|-
|UINT32LE||Unsigned 32-bit integer in little-endian format
|-
|UINT32BE||Unsigned 32-bit integer in big-endian format
|}

Signed equivalents are the same without the leading U, i.e. <tt>INT8</tt>, <tt>INT16LE</tt>, etc. Unless otherwise stated, the format is in [[wikipedia:Two's complement|two's complement]] (where a UINT8 value of 255 is -1 as an INT8, for example.)

==== Floating point values ====

{|class="wikitable"
!Data type!!Description
|-
|Single||32-bit float (IEEE-754)
|-
|[[Turbo Pascal Real|Real]]||48-bit float (Pascal specific)
|-
|Double||64-bit float (IEEE-754)
|}

All floating point values are signed. They usually contain a sign bit, exponent, and mantissa.

==== Character strings ====

Characters and strings are all [[wp:Code page 437|CP437]] unless otherwise stated. On modern platforms, this means the bytes will need to be converted to the local character set (such as UTF-8) in order for the glyphs to match what was originally intended.

{|class="wikitable"
!Data type!!Description
|-
|char[x]||String ''x'' bytes/characters long, may or may not be null terminated (each use should indicate which)
|-
|char||Single 8-bit character
|-
|ASCIIZ||A C-style string (variable-length, terminated with a single NULL/0x00 value)
|}

==== Misc data types ====
{|class="wikitable"
!Data type!!Description
|-
|BYTE||Same as UINT8 but conceptually for generic data rather than numeric values (e.g. UINT8 would be used for a number, while a BYTE would be used for a bitfield)
|-
|BYTE[x]||Block of data ''x'' bytes long
|}

== Big endian vs little endian ==

For numeric values larger than a single byte, the endianness specifies how the values are split over multiple bytes. For example a hex value of 0x1234AABB when written to a file will take up two bytes, as follows:

{|class="wikitable"
!Endian!!Bytes in file
|-
|Big||<code>12 34 AA BB</code>
|-
|Little||<code>BB AA 34 12</code>
|}

For those languages that allow direct memory access such as C/C++, converting an integer value to a byte array will reveal the value stored in-memory in the same order as the table above.

Normally when reading or writing a variable to a file a programmer will simply pass the memory address of the variable, resulting in the file mirroring the byte order in memory. This is no problem when reading the variable back in on the same system, as the byte order will match. However when reading data from a different system (for example using an Intel PC to read files from a PowerPC Mac) the byte order will be opposite to what the system expects and the programmer must convert the values manually.

=== Conversion examples ===

If a value is being read on the same system (little to little or big to big) then no action is required. If the systems are different, then the values must be swapped. The following sections list examples for different programming languages.

==== C/C++ ====

<syntaxhighlight lang="c">
// 16-bit
int in = 0x1234;
int out = ((in & 0xFF) << 8) | (in >> 8);
// out should now be 0x3412

// 32-bit
int in = 0x1234AABB;
int out =
((in & 0xFF) << 24) |
((in & 0xFF00) << 8) |
((in & 0xFF0000) >> 8) |
(in >> 24);
// out should now be 0xBBAA3412
</syntaxhighlight>

==== C# .NET ====

<syntaxhighlight lang="csharp">
Int16 ByteSwap16(Int16 inValue)
{
return (Int16)(
((inValue & 0xFF) << 8) |
((inValue >> 8) & 0xFF)
);
}

Int32 ByteSwap32(Int32 inValue)
{
return (Int32)(
((inValue & 0xFF) << 24) |
((inValue & 0xFF00) << 8) |
((inValue & 0xFF0000) >> 8) |
((inValue >> 24) & 0xFF)
);
}
</syntaxhighlight>

==== Visual Basic .NET ====

<syntaxhighlight lang="vbnet">
Function ByteSwap16(ByVal InValue as Int16) as Int16
Return ((InValue And &HFF) << 8) Or ((InValue >> 8) And &HFF)
End Function

Function ByteSwap32(ByVal InValue as Int32) as Int32
Return ((InValue And &HFF) << 24) Or _
((InValue And &HFF00) << 8) Or _
((InValue And &HFF0000) >> 8) Or _
((InValue >> 24) And &HFF)
End Function
</syntaxhighlight>

Note: endianness of the platform in .NET can be known using the value of ''System.BitConverter.IsLittleEndian''.

[[Category:File Formats]]

Category:Fighting

2021-08-09T06:34:02Z

Aybe: Editing Category:Fighting

This category contains all fighting games in the wiki.

[[Category:Game Genres]]

Category:Fighting

2021-08-09T05:23:49Z

Aybe: Creating Category:Fighting

This category contains all fighting games in the wiki.

Super Street Fighter II TURBO

2021-08-09T05:22:33Z

Aybe: Category:Fighting

{{NeedMoreInfo}}
{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

Super Street Fighter II Turbo is a fighting game released for the arcades by Capcom in Japan on February 23, 1994, in North America on February 23 and March 26, 1994 (beta) and in Europe in March 1994 (beta). It is the fifth installment in the Street Fighter II sub-series of Street Fighter games, following Super Street Fighter II: The New Challengers. (from [https://en.wikipedia.org/wiki/Super_Street_Fighter_II_Turbo Wikipedia])

{{BeginGameFileList}}
{{GameFile
| Name = *.spr
| Format = [[Super Street Fighter II TURBO Sprite Format]]
| KnownFormat = Partial
| Desc = Sprite graphics
}}
{{EndGameFileList}}

[[Category:Fighting]]

File:Super Street Fighter II TURBO.png

2021-08-09T05:15:23Z

Aybe: Aybe uploaded a new version of File:Mod-Super Street Fighter II TURBO.png

Super Street Fighter II TURBO Sprite Format

2021-08-09T05:05:06Z

Aybe: Editing Super Street Fighter II TURBO Sprite Format (section)

{{Image Infobox
| Hardware1 = VGA
| Depth = 8-bit (VGA)
| MinSize = Unknown
| MaxSize = Unknown
| Palette = External
| NumPlanes = 1
| HasTransparency = Yes
| HasHitmap = Yes
| Games = {{Game|Super Street Fighter II TURBO}}
}}

This format is used by [[Super Street Fighter II TURBO]] to store sprite graphics.

== General ==

Most of the files are RNC-compressed and therefore should be decompressed beforehand.

Some files may store multiple frames each one after the other, this, without any indication.

The associated external [[VGA Palette]] may have the same file name, or not if it's a generic one.

Sprites used during ''Continue'' presumably are XOR-ed as some regions have diverging indices.

== Algorithm ==

{{TODO|Figure out why it does work for all files but LEVELS\DHALSIM\ANIMS.SPR.}}

The format is a simple form of [[RLE Compression]].

<source lang="csharp">
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.IO;
using System.Text;

namespace SSF2T
{
public class Sprite
{
public Sprite(Stream stream)
{
if (stream == null)
throw new ArgumentNullException(nameof(stream));

using var reader = new BinaryReader(stream, Encoding.Default, true);

Width = reader.ReadUInt16();
Height = reader.ReadUInt16();

var pixels = new byte[Width * Height];

var index = 0;

for (var i = 0; i < Height; i++)
{
while (true)
{
var b = reader.ReadByte();

if (b == 0)
{
break;
}

if (b < 128)
{
index += b;
continue;
}

for (var j = 0; j (pixels);
}

public ushort Width { get; }

public ushort Height { get; }

public IReadOnlyList<byte> Pixels { get; }

}
}</source>

== Credits ==

Reverse-engineered by aybe on 9th of August 2021.

File:Super Street Fighter II TURBO Sprite Format.png

2021-08-09T05:01:38Z

Aybe:

Super Street Fighter II TURBO Sprite Format

2021-08-09T05:01:21Z

Aybe: Creating Super Street Fighter II TURBO Sprite Format

{{Image Infobox
| Hardware1 = VGA
| Depth = 8-bit (VGA)
| MinSize = Unknown
| MaxSize = Unknown
| Palette = External
| NumPlanes = 1
| HasTransparency = Yes
| HasHitmap = Yes
| Games = {{Game|Super Street Fighter II TURBO}}
}}

This format is used by [[Super Street Fighter II TURBO]] to store sprite graphics.

== General ==

Most of the files are RNC-compressed and therefore should be decompressed beforehand.

Some files may store multiple frames each one after the other, this, without any indication.

The associated external [[VGA Palette]] may have the same file name, or not if it's a generic one.

== Algorithm ==

{{TODO|Figure out why it does work for all files but LEVELS\DHALSIM\ANIMS.SPR.}}

The format is a simple form of [[RLE Compression]].

<source lang="csharp">
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.IO;
using System.Text;

namespace SSF2T
{
public class Sprite
{
public Sprite(Stream stream)
{
if (stream == null)
throw new ArgumentNullException(nameof(stream));

using var reader = new BinaryReader(stream, Encoding.Default, true);

Width = reader.ReadUInt16();
Height = reader.ReadUInt16();

var pixels = new byte[Width * Height];

var index = 0;

for (var i = 0; i < Height; i++)
{
while (true)
{
var b = reader.ReadByte();

if (b == 0)
{
break;
}

if (b < 128)
{
index += b;
continue;
}

for (var j = 0; j (pixels);
}

public ushort Width { get; }

public ushort Height { get; }

public IReadOnlyList<byte> Pixels { get; }

}
}</source>

== Credits ==

Reverse-engineered by aybe on 9th of August 2021.

Super Street Fighter II TURBO

2021-08-09T04:43:08Z

Aybe: Editing Super Street Fighter II TURBO - SPR Format

File:Super Street Fighter II TURBO.png

2021-08-09T04:39:59Z

Aybe:

2019-11-19T09:37:21Z

Aybe: {{NeedMoreInfo}}

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}
{{NeedMoreInfo}}

== Versions ==

=== Windows (published by Xplosiv) ===

Runs an emulator (Z80.DLL), SecuROM protected.

=== DOS (version this page is about) ===

Seems to be a direct port of the PSX version, which does not emulate a Z80.

== SPR files ==

Some but not all files are compressed using [[Rob Northern Compression]]. When decompressed, they will be either of [[PCX Format]] or [[LBM Format]], for the latter appearing to be taken from the PSX version with chunks such as '''PSX''', '''CL00''' (CLUT, 16-bit colors), '''TP00''' (texture page, raw image), '''BX00''' (unknown).

Bubble Bobble featuring Rainbow Islands

2019-11-19T09:34:16Z

Aybe: /* SPR files */

{{Game Infobox
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}
{{NoModdingInfo}}

== Versions ==

=== Windows (published by Xplosiv) ===

Runs an emulator (Z80.DLL), SecuROM protected.

=== DOS (version this page is about) ===

Seems to be a direct port of the PSX version, which does not emulate a Z80.

== SPR files ==

Some but not all files are compressed using [[Rob Northern Compression]]. When decompressed, they will be either of [[PCX Format]] or [[LBM Format]], for the latter appearing to be taken from the PSX version with chunks such as '''PSX''', '''CL00''' (CLUT, 16-bit colors), '''TP00''' (texture page, raw image), '''BX00''' (unknown).

File:LBM Format.png

2019-11-19T09:30:45Z

Aybe:

File:PCX Format.png

2019-11-19T09:30:19Z

Aybe:

LBM Format

2019-11-19T09:24:16Z

Aybe: Added Bubble Bobble featuring Rainbow Islands

PCX Format

2019-11-19T09:23:37Z

Aybe: Added Bubble Bobble featuring Rainbow Islands

{{Image Infobox
| Hardware1 = CGA
| Hardware2 = EGA
| Hardware3 = VGA
| Depth = Multiple
| MinSize = 0×0
| MaxSize = 65536×65536 
| Palette = Internal (optional)
| NumPlanes = 1-255
| HasTransparency = No
| HasHitmap = No

| Games =
{{Game|Bubble Bobble featuring Rainbow Islands}}
{{Game|Crystal Caves}}
{{Game|Halloween Harry}}
{{Game|Hocus Pocus}}
{{Game|Hugo's House of Horrors}}
{{Game|Hugo II, Whodunit?}}
{{Game|Hugo III, Jungle of Doom!}}
{{Game|Math Rescue}}
{{Game|Wacky Wheels}}
{{Game|Word Rescue}}
}}
The [[PCX Format]] is an image format used by many games, usually to store full screen (320x200) 16-colour EGA, and later 256-colour VGA (mode 13h), graphics. It was, for a time, also a general picture format like .bmp or .png, and was the primary format used by PC Paintbrush. It declined in popularity after support for 24-bit true colour images was added too late, by which time many people had switched to competing formats like .png and JPEG (the latter offering far better compression for photos.) It also lacks support for transparency, which resulted in it losing some ground to the GIF format which otherwise provided a similar feature set.

== Header ==

The PCX file is composed of two parts, the header and the image data, which is usually compressed. The header is as follows:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT8]] || Manufacturer || Always 0x0A
|-
| [[UINT8]] || Version || PC Paintbrush version. Acts as file format version. 0 = v2.5 2 = v2.8 with palette 3 = v2.8 without palette 4 = Paintbrush for Windows 5 = v3.0 or higher
|-
| [[UINT8]] || Encoding || Should be 0x01 0 = uncompressed image (not officially allowed, but some software supports it) 1 = PCX run length encoding
|-
| [[UINT8]] || BitsPerPlane || Number of bits per pixel in each entry of the colour planes (1, 2, 4, 8, 24)
|-
| [[UINT16LE]] || WindowXmin ||rowspan=4| Window (image dimensions): ImageWidth = <tt>Xmax - Xmin + 1</tt> ImageHeight = <tt>Ymax - Ymin + 1</tt> Normally <tt>Xmin</tt> and <tt>Ymin</tt> should be set to zero. Note that these field values are valid rows and columns, which is why you have to add one to get the actual dimension (so a 200 pixel high image would have Ymin=0 and Ymax=199, or Ymin=100 and Ymax=299, etc.)
|-
| [[UINT16LE]] || WindowYmin
|-
| [[UINT16LE]] || WindowXmax
|-
| [[UINT16LE]] || WindowYmax
|-
| [[UINT16LE]] || VertDPI ||rowspan=2| This is supposed to specify the image's vertical and horizontal resolution in DPI (dots per inch), but it is rarely reliable. It often contains the image dimensions, or nothing at all.
|-
| [[UINT16LE]] || HorzDPI
|-
| [[UINT8]] || Palette[48] || Palette for 16 colors or less, in three-byte RGB entries. Padded with 0x00 to 48 bytes in total length. See below for more details on palette handling.
|-
| [[UINT8]] || Reserved || Should be set to 0, but can sometimes contain junk.
|-
| [[UINT8]] || ColorPlanes || Number of colour planes. Multiply by <tt>BitsPerPlane</tt> to get the actual colour depth.
|-
| [[UINT16LE]] || BytesPerPlaneLine || Number of bytes to read for a single plane's scanline, i.e. at least <tt>ImageWidth</tt> ÷ 8 bits per byte × <tt>BitsPerPlane</tt>. Must be an even number. Do '''not''' calculate from Xmax-Xmin. Normally a multiple of the machine's native word length (2 or 4)
|-
| [[UINT16LE]] || PaletteInfo || How to interpret palette: 1 = Color/BW 2 = Grayscale (ignored in PC Paintbrush IV and later)
|-
| [[UINT16LE]] || HorScrSize ||rowspan=2| Only supported by PC Paintbrush IV or higher; deals with scrolling. Best to just ignore it.
|-
| [[UINT16LE]] || VerScrSize
|-
| [[BYTE]][54] || Padding || Filler to bring header up to 128 bytes total. Can contain junk.
|}

== Image Data ==

Image data comes after the header (starting at offset 0x80 in a PCX file), and will be RLE compressed if the header indicated so. The way the data is stored depends on how many colour planes are specified. Each row has its color planes stored sequentially, similar to [[raw EGA data]].

For one plane of eight bits (256-colour), each byte will represent one pixel. For one plane of four bits (16-colour), each byte will represent two pixels. The bits within the byte are in big-endian order, so the most significant bit belongs to the left-most pixel. In other words, in two bits per pixel mode, a byte of value 0xE4 (binary 11 10 01 00) will have left-to-right pixel values of 3, 2, 1, 0.

EGA 16-colour images are often stored with four colour planes instead of one, with each plane being one-bit-per-pixel (think of four black and white images, one each for red, green, blue and intensity.) The planes are stored sequentially for each line (see [[Raw EGA data#Row-planar EGA data|Row-planar EGA data]] for the exact details), thus a 320x200 EGA image will store at least 40 bytes for each scanline's colour plane (320 pixels ÷ 8 bits per byte × 1 bit per pixel), with each scanline being at least 160 bytes long (320 pixels ÷ 8 bits per byte × 1 bit per pixel × 4 planes). Note that the scanline length can be larger than expected (40 bytes in this example), especially for images whose width is not a multiple of four. This is because each scanline in a plane is padded to a multiple of two or four bytes, depending on the architecture of the machine used to create the file. The actual size is stored in the <tt>BytesPerPlaneLine</tt> field in the header, which should always be used instead of calculating the value from the other image attributes.

True colour PCX files are not common, and could be either three planes (R, G and B) of eight bits each (24-bit RGB) or one plane of 24-bits. Technically, the same is applicable for alpha-capable 32-bit images (with four planes in planar mode), though no official format specs ever included such a thing.

The split into planes is generally governed by what is most convenient for the game at the time, which in turn depends on which video mode is being used to display the image. Since EGA video memory is split into planes, 16-colour PCX files are frequently split into matching planes so that no processing is required when loading an image directly into video memory.

=== RLE Compression ===

The PCX format uses a form of [[RLE Compression]] that is rather unique. It compresses on the byte level and uses a flag system, where the flag is the two highest bits of a byte. If this flag is set (i.e. the two upper bits are set, or in other words the value is >= 192) then the lower six bits are the number of times to repeat the following byte.

Thus, for a byte pair <tt>C7 28</tt>, the 0xC7 can be decomposed into the flag value 192 (128 + 64) plus 7, meaning the full byte pair means '7 bytes of 0x28'. So to get the amount, you subtract 192 from the flag, or, using faster logic operations, you can do <code>byte & 0x3F</code> to retain only the lowest six bits.

This means that the six-bit length values have a maximum of 63. It also means that any value larger than 191 ''must'' be stored as a length/value pair, which can actually ''increase'' the size of the file in some cases. For instance, if you have a single byte of color 192, then it must be represented by two bytes - one of 193 (C1, a repeat of one time) followed by one of 192 (C0, color byte 192).

It is also worth noting that the byte value C0 does not have a clearly defined effect. Depending on the implementation in the decoding program, this could do any of the following:

* treat <tt>C0</tt> as a literal byte.
* ignore <tt>C0</tt> and continue with the following byte.
* 'repeat the following byte zero times', effectively ignoring any byte following <tt>C0</tt>. This could conceivably be used to embed non-image data in the PCX file which would be ignored by any program displaying the image.
* 'repeat the following byte 65536 times', which is basically a bugged implementation using a "<tt>while (--count != 0)</tt>" style loop with a 16 bit variable/CPU register.

At any rate, the best way to handle a <tt>C0</tt> when encoding (compressing) is to write the sequence <tt>C1 C0</tt>. When decoding (decompressing), a value of <tt>C0</tt> almost always indicates an error in the file.

Note that each scanline is compressed independently - an RLE sequence may span multiple planes, but it will never span more than one row of pixels. Thus when decompressing an image, the RLE algorithm will produce at most <tt>BytesPerPlaneLine</tt> bytes at a time. Even where the RLE coding could have continued over to the next scanline, it will stop and start again fresh for each line.<ref>[http://www.drdobbs.com/pcx-graphics/184402396#01ED_0105 PCX Graphics | Dr Dobb's]</ref> For example, if the input image is 8×4 pixels EGA 16-colour, and the first two lines of pixels are black (color 0) and the last two are white (color 15), they must be compressed as <tt>C4 00 | C4 00 | C4 FF | C4 FF</tt> and not as <tt>C8 00 | C8 FF</tt>.

=== Palettes ===

Most of the game's supported formats are indexed, and thus require a colour palette. There are, however, three distinct ways of handling those palettes; CGA, EGA and VGA. For images with 16 colours or less, the palette is stored in the header. For images with more colours (i.e. 256-colour images) the header palette is ignored, and the 768-byte is stored after the image data. Some sources seem to indicate that there are formats where even the smaller palettes are added behind the image, so it is best to always check for it there. To determine if this is the case, check if the decompressed image data is followed by a <tt>0C</tt> byte, and if there is enough data left in the file behind that for the palette data.

As a general rule, the palettes are lists of 3-byte blocks. These blocks normally contain 8-bit RGB data, but even if they are used differently (as is the case for CGA palettes), they will still retain the 3-byte block structure.

It is difficult to correctly determine the palette for 1-bit and 2-bit images, since they can be stored either as CGA or as VGA, and there is no real way to identify which method to use. Some sources suggest checking for 640x200 dimensions on 1-bit images, or 320x200 on 2-bit, since those are standard CGA sizes for respectively its monochrome and 4-colour mode, but 320x200 is a very common size for non-CGA images as well, and there has most likely never been anything preventing people on CGA hardware from saving PCX images in different sizes than a full screen. It is also suggested, for two bit per pixel images, that those with a single 2-bit plane would use a CGA palette, while those with two 1-bit planes would use VGA<ref>[http://www.fysnet.net/pcxfile.htm PCX graphics files explained] - section "Interpretation of the PCX data"</ref>. All of this makes fully automatic identification for these image types very difficult.

==== CGA palette ====

CGA palette handling is a bit peculiar. As with other colour palettes, the data is seen as blocks of three bytes. However, in CGA mode, these blocks do not contain normal RGB colour data.

The first triplet contains the background colour to be put on palette index #0. Only the highest four bits of the first byte are used, meaning the actual colour value can be found by taking that byte and shifting it four bits to the right. The result is a value from 0..15, which matches [[EGA Palette|one of the standard CGA/EGA text-mode colours]].

For monochrome CGA images, the other entry is filled in with black (EGA palette entry #0), and the palette is complete.

For actual 4-colour palettes, three status bits are normally fed into the CGA hardware to determine the rest of the palette:

{|class="wikitable"
! Name !! Description
|-
| ColorBurst || Technically indicates the presence of colour on the palette, but disabling the bit actually causes a switch to Mode 5, which, on colour monitors, gives access to the extra unofficial '''palette 2'''.
|-
| Palette || Choice between '''palette 0''' and ''' palette 1'''. If <tt>ColorBurst</tt> is disabled, this bit is ignored.
|-
| Intensity || Choice between '''dark''' (0) or '''bright''' (1) version of the palette.
|}

The default palettes are comprised of the following indices on the [[EGA Palette|standard EGA palette]]. The Intensity modifier simply increases all indices by 8 to get the bright equivalents of these colours.

{|class="wikitable"
! Palette # !! Dark colours !! Bright colours !! Description
|-
| 0 || [2,4,6] || [10,12,14]|| Mode 4, palette 0
|-
| 1 || [3,5,7] || [11,13,15]|| Mode 4, palette 1
|-
| 2 || [3,4,7] || [11,12,15]|| The unofficial Mode 5 palette, accessed by disabling <tt>ColorBurst</tt>.
|}

However, the way these three bits are determined changed in PC Paintbrush version IV, and this change is not reflected in a change in the <tt>Version</tt> value in the header. The only decent way to distinguish the files from before and after version IV is to check the <tt>PaletteInfo</tt> byte in the header, which is 0 on files using the old method, and filled in (with 1 or 2) on files using the new method.

===== Older method =====

In the original way the status bits were saved, the second palette entry's first byte (byte 3) contains the three status bits.<ref name="fileformat">[https://www.fileformat.info/format/pcx/egff.htm PCX specs on fileformat.info]</ref> They can be extracted by taking the highest three bits of that byte.

* Bit 8 (<tt>10000000</tt>) is <tt>ColorBurst</tt>.
* Bit 7 (<tt>01000000</tt>) is the <tt>Palette</tt>.
* Bit 6 (<tt>00100000</tt>) is the <tt>Intensity</tt>.

===== Newer method =====

For the newer files, with the <tt>PaletteInfo</tt> byte filled in, the following<ref>[https://github.com/samuel/go-pcx/blob/d9c017170db4e016377181263f7e4cbb6bf1d8cc/pcx/decoder.go#L299 PCX image encoder and decoder for Go] - ''PC Paintbush 4.0 encodes the CGA palettes differently than 3.0.''</ref><ref>[https://github.com/wjaguar/mtPaint/blob/3884b6d6ebc18511df7bf1485a19fe774dd61dcf/src/png.c#L5416 Mark Tyler's Painting Program] - ''CGA palette is evil: what the PCX spec describes is the way it was handled by PC Paintbrush 3.0, while 4.0 was using an entirely different, undocumented encoding for palette selection.''</ref> should be done to determine the palette:

* Take the green and blue values of the second palette entry. These are the bytes at index 4 and 5 in the palette data.
* If the green value is strictly-greater than the blue value, take Palette 0, otherwise take Palette 1.
* If the largest of these two values is greater than 200, the Intensity bit is enabled.

The new method seemed to have been intended to convert a fully-saved colour palette back to CGA status bits. Sadly, it seems people figured out exactly what it checked, and started writing PCX files which contained only exactly enough data to derive those bits instead of saving an actual full palette.

As a side effect of this, there is no real check for the color burst, meaning it is always considered to be enabled, and there is no support for palette 2. If an actual palette is saved in the file, such support ''could'' be added. A viable check for detecting palette 2 (meaning, a disabled colour burst bit) would be that the original logic matches palette 1, and the third entry's red value is greater than its blue value.

==== EGA palette ====

EGA images are those with eight or sixteen colours. Typically, they have <tt>BitsPerPlane</tt> set to 1 and <tt>ColorPlanes</tt> set to 3 or 4, though variations like two 2-bit planes or one 4-bit plane are possible as well. For these images, there are two ways of handling the colours:

* If the version in the header is 0 or 3, then the [[EGA Palette|standard EGA palette]] is used, since version 0 does not support a modified palette, and version 3 specifically indicates that no palette information is present in the file.<ref name="fileformat" />
* In any other version, the palette is read from the header. The data is structured the same way as [[VGA Palette#The_.22Modern.22_format|8-bit VGA palettes]], except that it's less long.

Most EGA images will be 4 bits per pixel, meaning the palette will be 16 colours long, but 3 bit per pixel planar format is supported as well. In that case, only 8 entries are read, or if it uses the default EGA palette, only the darker first eight colours will be available. 2 bit per pixel images could use EGA palette handling as well, but these are hard to distinguish from the CGA ones.

Note that technically, EGA images are limited to 2 bit colour components, meaning every component would need to be rounded to the nearest multiple of <tt>0x55</tt>, though, practically, there is little reason to not let the images retain the more accurate colours as they are specified in the palette.

==== VGA palette ====

For 8-bit images, the 256-colour palette can be found behind the image data. It is a [[VGA Palette#The_.22Modern.22_format|standard VGA palette in 8-bit RGB format]]. A single signature byte of <tt>0C</tt> is included before the palette data begins.

Some PCX readers simplify the start offset of the 256-colour palette to <code>EndOfFile - 768</code>, though technically, the correct way to find it is to take the offset you end up at after decompressing the image, checking for the <tt>0C</tt> byte after that, and then reading the 768-byte palette.

== Source Code ==

=== ASM ===

<source lang="asm">
EXTERN kbdin, dosxit ; LIB291 functions

SEGMENT ScratchSeg
ScratchPad resb 65535

SEGMENT stkseg STACK
resb 64*8
stacktop:
resb 0

SEGMENT code

PCX1 db 'my_pcx1.pcx', 0 ; Filenames
PCX2 db 'my_pcx2.pcx', 0 ; (Must end with 0 byte)

..start:
mov ax, cs ; Set up data and stack segments
mov ds, ax
mov ax, stkseg
mov ss, ax
mov sp, stacktop

MAIN:
; Sets up mode 13h and clears screen
mov ax, 0013h
int 10h

mov dx, pcx1 ; Filename to display
call ShowPCX ; Display PCX file to screen

; Wait for keypress
call kbdin

; Go back to text mode
mov ax, 0003h
int 10h

; Return to DOS
call dosxit

;-----------------------------------------------------------------------------
; ShowPCX procedure by Brandon Long,
; modified by Eric Meidel and Nathan Jachimiec,
; converted to NASM, cleaned up, and better commented by Peter Johnson
; Inputs: DX has the offset of PCX filename to show.
; Output: PCX file displayed (all registers unchanged)
; Notes: Assumes PCX file is 320x200x256.
; Uses ScratchSeg for temporary storage.
; The PCX file must be in the same directory as this executable.
;-----------------------------------------------------------------------------
ShowPCX
push ax ; Save registers
push bx
push cx
push si
push di
push es

mov ax, 3D00h
int 21h ; Open file
jc .error ; Exit if open failed

mov bx, ax ; File handle
mov cx, 65535 ; Number of bytes to read
mov ax, ScratchSeg ; DS:DX -> buffer for data
mov ds, ax
mov dx, ScratchPad
mov si, dx
mov ah, 3Fh
int 21h ; Read from file

mov ax, 0A000h ; Start writing to upper-left corner
mov es, ax ; of graphics display
xor di, di

add si, 128 ; Skip header information

xor ch, ch ; Clear high part of CX for string copies

.nextbyte:
mov cl, [si] ; Get next byte
cmp cl, 0C0h ; Is it a length byte?
jb .normal ; No, just copy it
and cl, 3Fh ; Strip upper two bits from length byte
inc si ; Advance to next byte - color byte
lodsb ; Get color byte into AL from [SI]
rep stosb ; Store to [ES:DI] and inc DI, CX times
jmp short .tst

.normal:
movsb ; Copy color value from [SI] to [ES:DI]

.tst:
cmp di, 320*200 ; End of file? (written 320x200 bytes)
jb .nextbyte

mov cl, [si]
cmp cl, 0Ch ; Palette available?
jne .close

; Set palette using port I/O
mov dx, 3C8h
mov al, 0
out dx, al
inc dx ; Port 3C9h
mov cx, 256*3 ; Copy 256 entries, 3 bytes (RGB) apiece
inc si ; Skip past padding byte

.palette:
lodsb
shr al, 1 ; PCX stores color values as 0-255
shr al, 1 ; but VGA DAC is only 0-63
out dx, al
dec cx
jnz .palette

.close:
mov ah, 3Eh
int 21h ; Close file

.error:
pop es ; Restore registers
pop di
pop si
pop cx
pop bx
pop ax
ret
</source>

== Tools ==

PCX files can be read, and occasionally converted by several programs, notably, the Microsoft Photo Editor included in Windows XP can do so.

{{BeginFileFormatTools|Type=image}}
{{FileFormatTool
| Name = [http://www.xnview.com XnView]
| Platform = Windows/MacOSX/Linux
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = N/A
| editMetadata = N/A
| notes = Freeware for private non-commercial or educational use.
}}
{{FileFormatTool
| Name = [http://www.imagemagick.com ImageMagick]
| Platform = Cross-platform
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = N/A
| editMetadata = N/A
| notes = Is unable to correctly write 16-colour PCX files.
}}
{{FileFormatTool
| Name = [http://www.gimp.org GNU Image Manipulation Program]
| Platform = Cross-platform
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = N/A
| editMetadata = N/A
| notes = Does not handle CGA or default-palette EGA images correctly.
}}
{{FileFormatTool
| Name = [[Engie File Converter]]
| Platform = Windows
| canView = Yes
| canExport = No
| canImport = Yes
| editHidden = N/A
| editMetadata = N/A
| notes = Relies on common image dimensions for CGA detection.
}}
{{EndFileFormatTools}}

== Useful links ==

* [http://bespin.org/~qz/pc-gpe/pcx.txt Official PCX documentation]
* [http://web.archive.org/web/20030111010058/http://www.nist.fss.ru/hr/doc/spec/pcx.htm Official PCX documentation in HTML (archived version)]
* [http://www.fileformat.info/format/pcx/egff.htm PCX at the File Format Encyclopaedia] - very detailed
* [http://fileformats.archiveteam.org/wiki/PCX PCX on the 'Just Solve the File Format Problem' wiki] - includes useful sample files.

== References ==
<references/>