ModdingWiki - User contributions [en-gb]

Westwood SHP Format (TD)

2023-04-05T22:04:29Z

Matt: /* Tools */ OpenRA

{{Tileset Infobox
| Hardware1 = VGA
| MaxTiles = 65535, though internal addressing limits the file size to 16 MiB.
| Palette = '''Shared'''. Technically possible to have it '''Internal''' but this is unused.
| Names = N
| TileMinSize = 1x1
| TileMaxSize = 65535×65535
| NumPlanes = 1
| PlaneArrangement = Linear
| HasTransparency = P
| Metadata = None
| Subtilesets = N
| Compressed = Y
| Hidden = Y
| Games =
{{Game|Command & Conquer}}
{{Game|Command & Conquer: Sole Survivor}}
{{Game|Command & Conquer: Red Alert}}
}}

The sprite format used in [[Command & Conquer]] (also known as "Tiberian Dawn"), [[Command & Conquer: Red Alert|Red Alert]] and [[Command & Conquer: Sole Survivor|Sole Survivor]] is a collection of compressed 8-bit frames that all have the same dimensions. It can use two different compression algorithms, namely [[Westwood LCW|LCW]] and [[Westwood XOR Delta|XOR Delta]], and normally uses the most optimal one for each frame, though the use of XOR Delta is optional. The format technically supports an internal colour palette and an X and Y offset for the frames, but these options are ignored by the games that use it.

== File format ==

===Header===

{|class="wikitable"
!Offset||Data type!!Name!!Description
|-
|0x00||[[UINT16LE]]||Frames||Number of frames in the file.
|-
|0x02||[[UINT16LE]]||XPos||X-offset. Should be ignored.
|-
|0x04||[[UINT16LE]]||YPos||Y-offset. Should be ignored.
|-
|0x06||[[UINT16LE]]||Width||Width of the frames.
|-
|0x08||[[UINT16LE]]||Height||Height of the frames.
|-
|0x0A||[[UINT16LE]]||DeltaSize||Largest buffer size needed to decompress the frames.
|-
|0x0C||[[BYTE]][2]||Flags||Extra options. Bit 1 of this technically enables an embedded colour palette, but it is unused in the games.
|}

The <tt>XPos</tt> and <tt>YPos</tt> are often set in the headers of original game files as a side effect of Westwood's conversion process, but they are not applied by the games, and should be ignored. An embedded colour palette will most likely also be ignored by the games, since SHP files are typically small sprites drawn on a scene that already has a palette set.

===Frames info table===

After the header comes an array of size <code>Frames + 2</code>, with 8-byte entries that each have the following structure:

{|class="wikitable"
!Offset||Data type!!Name!!Description
|-
|0x00||UINT24LE||DataOffset||A three-byte integer value giving the offset to the frame's compressed data. Since both the LCW and XOR Delta compressions end their data with specific end markers, no end offset is needed.
|-
|0x03||[[BYTE]]||DataFormat||The compression format in which the data at <tt>DataOffset</tt> is stored. See below.
|-
|0x04||UINT24LE||ReferenceOffset||Contains the referenced <tt>DataOffset</tt> or frame number in case XOR chaining is used. See below.
|-
|0x07||[[BYTE]]||ReferenceFormat||Reference format in case XOR chaining is used. See below.
|}

Technically, these are two [[UINT32LE]] values with bit flags enabled in their highest byte. This might also be the simplest way to read them; by reading a UINT32LE, bit-masking the value with 0xFFFFFF to get the offset, and down-shifting the value by 24 bits to get the format.

It is unknown if the <tt>ReferenceFormat</tt> is used in any way; the way to handle the data seems to be completely defined by the <tt>DataFormat</tt>. It can of course be used as consistency check to confirm that the format is valid, and when writing a SHP file, it's better to conform to the known standards to ensure the game handles the file correctly.

If the palette flag is enabled, this table is followed by a 768-byte array containing a [[VGA Palette#The .22Classic.22 format|256-colour 6-bit RGB VGA palette]]. After that follows the actual data referenced at the <tt>DataOffset</tt> addresses in the table. Unlike in [[Westwood WSA Format|WSA format]], the palette is taken into account in the offsets, so no adjustments are needed on them.

There are three possible ways in which a frame can be stored, depending on the <tt>DataFormat</tt>. This is how the table entries look for each of these ways:

====LCW Frame====

The most straightforward frame type is an [[Westwood LCW|LCW-compressed]] frame.

* <tt>DataOffset</tt>: points to the LCW data to uncompress to get the frame graphics.
* <tt>DataFormat</tt>: set to 0x80, indicating '''LCW'''.
* <tt>ReferenceOffset</tt>: irrelevant, and left empty.
* <tt>ReferenceFormat</tt>: irrelevant, and left empty.

====XOR Base Frame====

In case the differences with a previously-saved LCW frame are minimal, [[Westwood XOR Delta|XOR Delta compression]] is used to save instructions for transforming the previous frame's data into the new frame.

* <tt>DataOffset</tt>: points to the XOR data to apply.
* <tt>DataFormat</tt>: set to 0x40, indicating '''XOR Base'''.
* <tt>ReferenceOffset</tt>: Contains the <tt>DataOffset</tt> of the referenced '''LCW frame'''.
* <tt>ReferenceFormat</tt>: set to 0x80 ('''LCW'''). It is unknown if (and unlikely that) any of the other formats are supported as reference.

====XOR Chain Frame====

The third case, chained XOR, is a bit peculiar: it is an XOR with the immediately preceding XOR frame. It can only chain from either an XOR Base frame, or another XOR Chain frame.

* <tt>DataOffset</tt>: points to the XOR data to apply.
* <tt>DataFormat</tt>: set to 0x20, indicating '''XOR Chain'''.
* <tt>ReferenceOffset</tt>: refers to the ''frame number'' of the '''XOR Base''' frame at the ''start'' of the chain.
* <tt>ReferenceFormat</tt>: set to 0x48, indicating '''XOR Chain Reference'''.

====Two final entries====

As mentioned, the table has two more entries than the amount of frames. The first of these two extra entries normally serves as end point; its <tt>DataOffset</tt> contains the file length, and all its other values are set to 0. The final entry is normally completely zeroed out.

However, some games contain SHP files where the ''last'' entry contains the file size. In that case, the entry before that contains the information for a 'loop frame'. Loop frames are normally not used in SHP format; they were conceived for the [[Westwood WSA Format|WSA format]], which, being purely based on XOR Delta compression, needed an extra XOR data entry as a smooth way to transform the final frame into the first one without needing to clear the graphics buffer. If such a loop frame exists in the SHP file, it should be ignored, and the file size should simply be taken from the last entry. It will most likely contain a duplicate of the first frame.

===Implementation notes===

The basic implementation is simple: compress the first frame as LCW, and for every following frame, attempt LCW, XOR Delta with a previous LCW frame, and (if the previous one is an XOR Delta) XOR chaining, and store the one which results in the lowest compressed size.

The existing files seem to work with a system of LCW "key frames"; XOR Base frames never refer to LCW frames before the previously-saved LCW frame. Note that after an XOR chain, it is perfectly possible to have another XOR Base frame referring to this last key frame, and multiple XOR chains can occur after a single key frame.

There also seems to be a rule applied to limit the length of XOR chains. Since the games do not sequentially preload SHP files, but instead interpret the data at the moment it is drawn to the screen, long chains can slow down the drawing process, since it needs to read, interpret and alter all chained frames in sequence. For example, the SAM Site SHP file in C&C1, when saved without chain limiting, would result in chains longer than 50 frames.

To limit this, the used strategy appears to be to only allow chaining if the cumulative size of all chained frames after the original XOR frame does not exceed the size of that original XOR frame.

This is just the saving strategy used in the original files, though; technically, the XOR Base frames can refer to any previous LCW frame in the file, and there is no length limit to XOR chains. The strategy seems to be a compromise between compression time, saved size and decompression time.

== Tools ==

{{BeginFileFormatTools|Type=image}}
{{FileFormatTool
| Name = [[Engie File Converter]]
| Platform = Windows
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = N/A
| notes = Uses the original algorithms and storage principles used by Westwood Studios, with further optimisations to avoid saving data of duplicate frames.
}}
{{FileFormatTool
| Name = [http://xhp.xwis.net/ XCC Mixer]
| Platform = Windows
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = N/A
| notes = The de facto standard modding tool in the C&C community, but like most older tools, its LCW compression is not very good, and it does not use XOR Delta when saving this type.
}}
{{FileFormatTool
| Name = Mix Manager
| Platform = DOS
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = N/A
| notes = The most commonly used modding suite back in the DOS days.
}}
{{FileFormatTool
| Name = RAMIX
| Platform = DOS
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = N/A
| notes = The spiritual successor of Mix Manager, created when people started digging into [[Command & Conquer Red Alert]].
}}
{{FileFormatTool
| Name = [https://web.archive.org/web/20130501143307/http://www.ultraq.net.nz/redhorizon/downloads/ Red Horizon Utilities]
| Platform = Java (command line)
| canView = No
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = N/A
| notes = Original site is defunct. Backups of the tools can be found [http://nyerguds.arsaneus-design.com/tools/redhorizon/ here].
}}
{{FileFormatTool
| Name = [https://github.com/OpenRA/OpenRA/wiki/Utility OpenRA Utility]
| Platform = Windows, Linux, Mac
| canView = No
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = N/A
| notes = Command line tool that can export/import from .png
}}
{{EndFileFormatTools}}

[[Category:Westwood Studios File Formats]]

MIX Format (Westwood)

2023-04-05T22:02:49Z

Matt: /* Tools */ OpenRA

{{Archive Infobox
| MaxFiles = 65,536
| FAT = Beginning
| Names = No
| Metadata = None
| Subdirectories = N
| Compressed = N
| Encrypted = Y
| Hidden = Y
| Games =
{{Game|Command & Conquer}}
{{Game|Command & Conquer: Red Alert}}
{{Game|Command & Conquer: Tiberian Sun}}
{{Game|Command & Conquer: Red Alert 2}}
{{Game|Blade Runner}}
}}

Westwood's '''MIX Format''' is a simple group file used in their games from 1995-2001. It only stores file name hashes so some file names will result in the same hash and as a result will not be able to be stored together if they differ in content. Position and size of files are stored so size does not need to be inferred. It does not support compression.
There are 2 versions of the header, basic and advanced. The basic one only stores the file count and the total data size (not including the header or file index). The advanced one supports additional optional features such as encryption of the header and index and a sha1 checksum tailer to verify the data integrity. An additional flag field is used to indicate which features are present.
The hash algorithm used for the file name is a rolling hash in Command & Conquer and Red Alert and was replaced with crc32 in Tiberian Sun and later. There is nothing to indicate which hash scheme is used. Other games may use other hash methods.

Apart from the original Command & Conquer, all the games can read both types of header provided the hash format is correct for that game.

== File format ==

=== Signature ===

MIX files have no signature. Usually they will have the extension .mix

=== File Header ===

The header consists of an optional flags section 4 bytes in size. The first 2 bytes are 0 in this case to distinguish between a mix without feature flags where this stores the file count as UNIT16LE. The flags are stored in the 3rd byte as a bit field with bit 0 indicating a checksum is present and bit 1 indicating that the header is encrypted.

If the flags indicate encryption, an 80 byte block follows the flag section. This block is encrypted with an RSA private key with the public key used to decrypt being embedded in the games code. This block decrypts to a 56 byte Blowfish key that is used to decrypt the rest of the header.

The standard header follows with a file count and a size which is the size of the data only. C&C games use this when caching a mix file. XCC uses this to validate the format and can be abused by making it larger to prevent XCC reading it correctly at the cost of the games reading additional garbage when caching them. This is used in so called "protection" schemes some mods use to prevent others using their assets.

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT32LE]]||Flags||An optional field that specifies additional optional features that the archive uses.
|-
|[[BYTE]][80]||Key||An optional 80 byte block containing an RSA encrypted Blowfish key to use to decode the rest of the header.
|-
|[[UINT16LE]]||FileCount||The number of files in the archive. Can be used to calculate the size of the file entry index.
|-
|[[UINT32LE]]||DataSize||Size of the data section.
|}

=== File Entry ===

The indexes file entries contain a hash of the filename, the offset of the file within the data section (header size needs to be added for absolute position in the archive) and the size of the file in bytes.

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[INT32LE]]||Id||Hash of the filename. Hash algorithm varies between games.
|-
|[[UINT32LE]]||Offset||File's starting offset within the data section.
|-
|[[UINT32LE]]||Size||File's size.
|}

In order to quickly locate files from their file name hashes, the index is sorted according to the hashes taken as signed integers.

=== Encryption ===

Header encryption can be detected by checking Flags & 0x00020000 does not equal zero. If it doesn't, then the next 80 bytes are two RSA encrypted blocks that need to be decrypted with the Westwood public key. For the purposes of the RSA algorithm, the blocks should be treated as 2 40 byte "big" integers in little endian byte order. 0x10001 should be used as the public exponent for the decryption.

The result is a 56 byte block padded with zeros to use with the Blowfish algorithm in ECB mode. Blocks are 8 bytes long and you need to decode the first block to get the standard header. From that you can calculate the length of the index and thus how many additional blocks you need to decode to get the rest of the index. If the header and index together are not perfectly divisible by 8, then it is padded with zeros since blowfish operates on 8 byte blocks.

Creating an encrypted header is the reverse of this process, a Blowfish key is generated somehow and used to encrypt the header and index and is itself padded with zeros and encrypted using the Westwood private key.

The public key is encoded in the game binaries while the private key was leaked in the form of keys.ini included in one of the Tiberian Sun MIX files. Presumably this was a mistake as it cannot be used from that location. The full contents of the file are as follows.

<source lang="ini">
[PublicKey]
1=AihRvNoIbTn85FZRYNZRcT+i6KpU+maCsEqr3Q5q+LDB5tH7Tz2qQ38V

[PrivateKey]
1=AigKVje8mROcR8QixnxUEF5b29Curkq01DNDWCdOG99XBqH79OaCiTCB
</source>

The keys are Base64 encoded and DER encoded big endian "big" integers and represent the modulus and the private exponent respectively in the RSA encryption scheme.

=== Checksum ===

Data checksum presence can be detected by checking Flags & 0x00010000 does not equal zero. If it doesn't, then the last 20 bytes of the file are a SHA1 hash of the data contents of the file, not including the header.

== Tools ==

{{BeginFileFormatTools|Type=group}}
{{FileFormatTool
| Name = [http://xhp.xwis.net/ XCC Mixer]
| Platform = Windows
| canExtract = Yes
| canDecompress = N/A
| canCreate = Yes
| canModify = Yes
| canCompress = N/A
| editHidden = No
| editMetadata = N/A
}}
{{FileFormatTool
| Name = Mix Manager
| Platform = DOS
| canExtract = Yes
| canDecompress = N/A
| canCreate = Yes
| canModify = Yes
| canCompress = N/A
| editHidden = No
| editMetadata = N/A
}}
{{FileFormatTool
| Name = RAMIX
| Platform = DOS
| canExtract = Yes
| canDecompress = N/A
| canCreate = Yes
| canModify = Yes
| canCompress = N/A
| editHidden = No
| editMetadata = N/A
}}
{{FileFormatTool
| Name = [https://github.com/OpenRA/OpenRA/wiki/Utility OpenRA Utility]
| Platform = Windows, Linux, Mac
| canExtract = Yes
| canDecompress = N/A
| canCreate = No
| canModify = No
| canCompress = N/A
| editHidden = No
| editMetadata = N/A
}}
{{EndFileFormatTools}}

[[Category:Westwood Studios File Formats]]

Westwood SHP Format (TS)

2023-04-05T22:02:00Z

Matt: /* Tools */ OpenRA

{{Tileset Infobox
| Hardware1 = VGA
| MaxTiles = 65535
| Palette = Shared
| Names = N
| TileMinSize = 1x1
| TileMaxSize = 65535×65535
| NumPlanes = 1
| PlaneArrangement = Linear
| HasTransparency = P
| Metadata = None
| Subtilesets = N
| Compressed = Y
| Hidden = Y
| Games =
{{Game|Command & Conquer: Tiberian Sun}}
{{Game|Command & Conquer: Red Alert 2}}
}}

The sprite format used in [[Command & Conquer: Tiberian Sun]] and [[Command & Conquer: Red Alert 2|Red Alert 2]] is a collection of 8-bit frames that all have the same dimensions. The format uses the [[Westwood RLE-Zero]] algorithm to compact transparent areas, and uses X and Y offsets to align smaller frame data in the full frame size, but, unlike its predecessors, uses no real data compression like [[Westwood LCW|LCW]].

An additional 'compression', though applied on game design level rather than on graphics level, is that all separate structure animations in these games are typically stored in separate files. This has the advantages that it both saves space by not including the entire structure graphics in the animation graphics (a problem previously solved by using [[Westwood XOR Delta|XOR Delta]]), and that it gives more freedom for playing multiple looping animations with different amounts of frames on the same structure.

Note that Tiberian Sun and Red Alert 2 are not DOS games. This format is included on this wiki for the sake of completeness in the scope of documenting all indexed graphics formats in the Westwood Studios games, and as logical successor to the [[Westwood SHP Format (Dune II)|Dune II SHP]], [[Westwood SHP Format (Lands of Lore)|Lands of Lore SHP]] and [[Westwood SHP Format (TD)|C&C 1 SHP]] formats.

== File format ==

=== Header ===

The file starts with a very simple 8-byte header:

{|class="wikitable"
!Offset||Data type!!Name!!Description
|-
|0x00||[[UINT16LE]]||Empty||Always zero. This allows a very simple first check to identify this file type.
|-
|0x02||[[UINT16LE]]||FullWidth||Width of the frames.
|-
|0x04||[[UINT16LE]]||FullHeight||Height of the frames.
|-
|0x06||[[UINT16LE]]||NrOfFrames||Number of frames in the file.
|}

=== Frames info table ===

After the header comes an array with <code>NrOfFrames</code> entries, where each entry has the following structure:

{|class="wikitable"
!Offset||Data type!!Name!!Description
|-
|0x00||[[UINT16LE]]||FrameX||X-offset to align the frame in the full <code>FullWidth*FullHeight</code> image.
|-
|0x02||[[UINT16LE]]||FrameY||Y-offset to align the frame in the full <code>FullWidth*FullHeight</code> image.
|-
|0x04||[[UINT16LE]]||FrameWidth||Width of the frame image data.
|-
|0x06||[[UINT16LE]]||FrameHeight||Height of the frame image data.
|-
|0x08||[[UINT32LE]]||Flags||A series of bit flags that determine how the game interprets the data. The two flags are <tt>HasTransparency</tt> (bit 1) and <tt>UsesRle</tt> (bit 2). Since the RLE compression only collapses transparency, bit 2 should never be enabled if bit 1 isn't.
|-
|0x0C||[[BYTE]][4]||FrameColor||The first three bytes of this contain R/G/B colour bytes that can be used on the game's minimap. Unlike the game's colour palettes, this uses 8 bits per colour component.
|-
|0x10||[[UINT32LE]]||Reserved||Always 0.
|-
|0x14||[[UINT32LE]]||DataOffset||Offset of the frame's data. If there is no data, this should be 0. In the original files, the data, and thus these offsets, are always aligned to multiples of 8 bytes, though this is technically not necessary. Since the zero-compression algorithm has line lengths in its format, and uncompressed data is exactly <code>FrameWidth * FrameHeight</code> bytes, no end offset is needed.
|}

The <tt>flags</tt> aren't really decompression options but options to tell the game's blitters how to paint the graphics on the screen. Because of this, it is important to enable the <tt>HasTransparency</tt> bit if the graphics data contains zero-value bytes, otherwise they may get painted as actual zero-value colours, instead of getting handled as transparency.

==== Image data decompression ====

The main way the image data is reduced in size is by saving only a cropped frame, which needs to be realigned in the full frame size using the X and Y offsets. To get the cropped frame, though, the data first needs to be interpreted correctly.

As mentioned, there are two flags that can be set on graphics, and the second should never be enabled if the first one isn't, giving three different types of stored data:

* On fully opaque data, both the <tt>HasTransparency</tt> and <tt>UsesRle</tt> flags are disabled.
* On data containing transparency which is not RLE-compressed, the <tt>HasTransparency</tt> flag is enabled, but the <tt>UsesRle</tt> flags isn't. Typically, this is only used in case the RLE algorithm gives larger output than the original data, however, the game's mouse cursor graphics are saved without RLE, and will not work correctly if RLE is enabled on them.
* On data containing transparency which is RLE-compressed, both the <tt>HasTransparency</tt> and <tt>UsesRle</tt> flags are enabled.

The used compression is the Tiberian Sun variant of the [[Westwood RLE-Zero]] algorithm, a [[RLE Compression#Flag|flag-based RLE]] triggering on value 00, which is treated per line, and which has a [[UINT16LE]] at the start of each line indicating that line's input data length.

==== Frame colour ====

The <tt>FrameColor</tt> is the average colour of all non-transparent pixels in the frame's image data, when seen in its intended palette, or rather, in the graphics fed into the original encoder used by Westwood. Since reapplying an average-colour algorithm to existing game sprites gives slightly different values than the original ones, it is likely that the original images had 8-bit colour components, and that the process of mapping them to the intended game palette was done by the encoding tool itself.

The main purpose of this colour is to serve as display colour on the game's 'radar' minimap. Most units and structures in the game don't need this, since anything owned by either an AI or human player is displayed on the minimap with the colour of its owner, but it is important to have this for map resources and SHP-based terrain pieces such as bridges.

The original encoder used by Westwood seems to have contained some system to compensate for remappable house colours, however, or had a way to override the house colours to the intended in-game colours, because the frames of the tiberium resource in the game, which is remappable, have green colours set, despite the game using red colours on the remapping range on its colour palette. Likewise, some of the tiberium-based mutated wildlife in the game, which is also typically remapped to green in the game, contains green frame colours that can only be achieved by using green-remapped graphics as source.

It must be noted that, on the tiberium graphics, the game uses a somewhat odd system to change these colours when the tiberium in the game is remapped to a different colour than green. For that reason, it is advised that when editing the tiberium graphics, the original graphics' frame colours are copied exactly, otherwise blue tiberium in the game has a tendency to look strangely purple on the minimap. The ''TS/RA2 SHP Radar Colour Editor'' (see [[#Tools|Tools]]) can apply this operation.

=== Shadow filter area ===

On the preceding games, unit and structure shadows are typically indicated on the graphics using colour index 4 (though in C&C1 this is technically defined by the game's [[Westwood Fading Table|fading table]] files), typically coloured bright green <span style="background-color: #000000; color: #54FC54">#54FC54</span> on the palettes. Tiberian Sun and Red Alert 2 work differently; the shadows are split off into additional frames behind the normal graphics, and are painted in colour index 1.

Such shadow frames are not a specific part of the format; there are plenty of graphics in the games (like UI graphics) that are not units or structures in the play field that need to cast a shadow, so these frames are not always an expected thing, but if they are present they should be somewhat detectable by the fact there is an even number of frames, and the pixels in the second half of the frames only use palette indices 0 and 1.

Since shadows should never overlap the main graphics, the correct way to combine the frames is to draw the shadows ''under'' the main graphics. Most conversion tools convert the shadow data to the classic index 4, for the sake of compatibility, because index 4 is never really used in graphics, and because this index is still set to the clearly visible green colour on most default unit and structure palettes in Tiberian Sun and Red Alert 2.

== Tools ==

{{BeginFileFormatTools|Type=image}}
{{FileFormatTool
| Name = [[Engie File Converter]]
| Platform = Windows
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = Has save options to tweak <tt>FrameColor</tt>.
| notes = Generates the <tt>FrameColor</tt> data from the input frames, and has an option to override the red remap colours in that operation with tiberium-green.
}}
{{FileFormatTool
| Name = [http://xhp.xwis.net/ XCC Mixer]
| Platform = Windows
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = No
| notes = The main conversion tool used by the modding community.
}}
{{FileFormatTool
| Name = [https://www.ppmsite.com/?go=shpbuilderinfo OS SHP Builder]
| Platform = Windows
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = No
| notes = An actual graphical sprite editor
}}
{{FileFormatTool
| Name = [https://ppmforums.com/viewtopic.php?t=18679 TS/RA2 SHP Radar Colour Editor]
| Platform = Windows
| canView = No
| canExport = No
| canImport = No
| editHidden = No
| editMetadata = Yes
| notes = Specific tool for editing the <tt>FrameColor</tt> data, since most SHP tools have no support for setting it. Can only view the colours set for the SHP frames, not the graphics themselves.
}}
{{FileFormatTool
| Name = [https://github.com/OpenRA/OpenRA/wiki/Utility OpenRA Utility]
| Platform = Windows, Linux, Mac
| canView = No
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = No
| notes = Command line tool that can export/import from .png
}}
{{EndFileFormatTools}}

[[Category:Westwood Studios File Formats]]