ModdingWiki - User contributions [en-gb]

The Incredible Machine Image Format

2022-08-12T21:33:11Z

Knt47: /* Tools */ TIM level viewer now hosted on Codeberg

{{Tileset Infobox
| Hardware1 = EGA
| Hardware2 = VGA
| MaxTiles = 65535
| Palette = Shared
| Names = N
| TileMinSize = 1x1
| TileMaxSize = 65535×65535
| NumPlanes = 1
| PlaneArrangement = Linear
| HasTransparency = Y
| Metadata = None
| Subtilesets = N
| Compressed = Y
| Hidden = Y
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|Heart of China}}
}}

'''The Incredible Machine''' (TIM) '''bitmap images''' are stored in the <tt>RESOURCE.00?</tt> [[TIM Resource Format|resource files]] as sub-files. They have the extension <tt>.BMP</tt>.

(For full-screen images (<tt>*.SCR</tt>), see [[RES Format (Stellar 7)#SCR: Fullscreen image|Stellar 7 RES Format]].)

== Chunk format ==

The files are built up out of chunks, in the typical Dynamix chunk format: a 3-character ID, followed by a ':', followed by the chunk size in [[UINT32LE]] format. The highest bit of the chunk size value is not actually part of the chunk size: it is set to 1 if the chunk is a container-type chunk that contains more chunks inside itself. This chunk format is documented on the [[RES Format (Stellar 7)#BMP: images|Stellar 7 RES Format]] page.

The BMP file is contained inside one <tt>BMP</tt> chunk. This is a container chunk. None of chunks types embedded inside it are container chunks.

The first chunk inside the <tt>BMP</tt> data is the <tt>INF</tt> chunk. Its data starts with a [[UINT16LE]] indicating the number of sub-images inside the file, followed by two UINT16LE arrays containing respectively the widths and heights of all images.

Based on the chunk type that contains the image data, there are two types of images:

== SCN/OFF format ==

The majority of the image files in ''The Incredible Machine'', including the graphics for puzzle parts, contain an <tt>SCN</tt> and an <tt>OFF</tt> chunk. The image data is stored in the <tt>SCN</tt> chunk, while the <tt>OFF</tt> chunk contains an index for each sub-image's data inside the <tt>SCN</tt> chunk. The <tt>SCN</tt> chunk has its own compression format, described in the next section.

=== The SCN chunk ===

The <tt>SCN</tt> chunk contains the pixel data for each sub-image. Basically, it has an extended [[RLE Compression#Code|code-based run-length encoding]] format with 2-bit commands. This gives four commands; the classic "repeat" and "copy" ones, and two extra commands to skip ahead. These "skips" should always treat the skipped space as transparent. If the output buffer is not cleared in advance, and the decompression is not meant to directly paint the new graphics onto an existing image in the buffer, these commands might need to specifically write 0-values to fill the skipped pixels.

The data for each sub-image starts with an <code>addValue</code> byte that has a special meaning: its value is added to all non-transparent pixel values. It normally corresponds to the lowest pixel value found in the resulting image. The value of this byte is set to 0xFF in some "empty" images that contain only a few transparent pixels.
In 8-bit games, like [[Heart of China]], the result may be an 8-bit image, meaning <code>addValue</code>, and the resulting pixel values, can be larger than 0x0F. The compression itself is based on storage of 4-bit pixels, though, so even on 8-bit images, the final data can only contain values from <code>addValue</code> up to <code>addValue + 0x0F</code>, plus the background colour. This special handling of transparency makes sure that the full range of the 4 bits can be used for colours, without the need to sacrifice one for transparency. This does make it difficult to convert to classic image formats without upgrading the image to at least 8-bit.

The actual RLE codes start after this byte. The <code>command</code> is made from the upper two bits, with the lower six bits serving as the <code>value</code>.

Note that this <code>value</code> always denotes a number of ''pixels'', not bytes, which may be tricky to program for 4-bit images. An alternative approach could be to decompress the image to an 8-bit buffer, and post-process the result to compact it to 4-bit (unless the <code>addValue</code> makes the values too large for that, and it is intended to be 8-bit).

The four different commands are:

==== Command 0: Line skip ====

The <code>command</code> made from high bits <tt>00</tt> is meant to skip to the next line in the image. This command ''must'' be used to terminate a line in the image; the format does not seem to support automatic wraparound for progressing to a new line. This also means none of the other commands will ever write data that goes beyond the end of a line.

The line skip command will move the output pointer down one line on the image (ending up on the same X-coordinate on the next line), and then move back by the amount of pixels specified in <code>value</code>. With wraparound included, this means the operation simply jumps (or background-fills) to the position <code>width - value</code> pixels ahead of your current output write position.

There are some special cases in this, though. Since this should be able to move from the end of one line to the start of the next one, it needs to be able to address the entire width of the image, which, on large images, can't be done in one 6-bit value. Because of this, the data may contain two consecutive bytes with a 'line skip' command, and the values of both of these need to be taken together, with the second command providing the more significant seventh to twelfth bits to be added to the first read value, as <code>value = value1 | (value2 << 6)</code>.

However, if an image has several empty lines in it, it can be unclear whether or not such commands should be taken together. Because of this, if the second command has a <code>value</code> of 0, the rule is to always treat it as separate command. To avoid all ambiguity in these cases, and because a <code>value</code> 00 code ''can'' be extended by one with a higher <code>value</code>, if the non-empty pixels on that later line start at an X-coordinate earlier than the first empty pixel on that earlier line, the first line skip command will '''always''' align the X-coordinate with the point at which the data restarts after the gap, so that all commands following it can be non-ambiguous byte 00 full line skips. Note that if the pixel appears at an identical or higher X-coordinate, all line skips can be done with 00 bytes, and any remaining distance can simply be filled up with 'short skip' commands (see below), which can perfectly be placed after the 00 bytes.

==== Command 1: Short skip ====

The <code>command</code> you get when the high bits are <tt>01</tt> will skip (or background-fill) the amount of pixels specified in <code>value</code>. Numbers greater than 0x3F will simply be encoded in multiple 'short skip' commands. A 'short skip' command with a <code>value</code> of 0, resulting in a Code byte 0x40, is used to indicate the end of the decompression of the current sub-image.

==== Command 2: Repeat ====

A <code>command</code> made up of bits <tt>10</tt> will create a sequence of pixels of the same color. The repeat count is specified by <code>value</code>. A single byte follows the Code byte, containing the pixel value. Since this is a 4-bit format, the most significant 4 bits of this byte are always zero. Note that the <code>addValue</code> from the start of the data needs to be added to this to get the real pixel value to repeat.

==== Command 3: Copy ====

The <code>command</code> from high bits <tt>11</tt> is the Copy command. This simply copies a sequence of pixel values to the output. The amount of pixels is specified in <code>value</code>.

Since the amount is in pixels, the number of bytes after the Code byte does not match the <code>value</code>. It can be calculated as <code>(value + 1) >> 1</code>. Each byte contains two pixels, with the color of the leftmost pixel stored in the most significant nibble. If the number of pixels is odd, the most significant 4 bits of the last byte contains the color of the last pixel, and the less significant nibble is zero. Note that since the <code>addValue</code> from the start of the data needs to be added to every pixel in this range, and the starting position to write pixels to may be an odd number at the start of the command, this operation requires treating all data as nibbles to process them correctly.

==== Terminator ====

Nearly all sub-images are "terminated" by the byte sequence 0x00 0x40; a full line skip, followed by an empty short skip command. However, there are a few exceptions, where it ends on 0x40 alone. Do note that while a 0x40 can always be considered a terminator command, since it has no real meaning on its own, a 0x00 is a perfectly valid full-line skip, and should never be treated as a signal to end the decompression.

=== The OFF chunk ===

The <tt>OFF</tt> chunk contains the offsets for each sub-image in the <tt>SCN</tt> chunk, as [[UINT32LE]] values. The first one should always be zero.

The end of the current sub-image's compressed data in the <tt>SCN</tt> chunk can be determined from the start of the next offset in the list, or the length of the <tt>SCN</tt> chunk, if it's the final image. In practice, though, the data itself will always indicate the end with the 0x40 terminator value.

=== Format quirks ===

Since the 'line skip' command is the only valid way to progress to a new line, and this can only address up to 12 bits, images in this format are technically restricted to a width of up to 4095 pixels.

== BIN format ==

The remaining files in ''The Incredible Machine'' use a <tt>BIN</tt> chunk (e.g. <tt>MOUSE.BMP</tt>, <tt>PARTBIN.BMP</tt>).

The <tt>BIN</tt> chunk has a small header of one byte to indicate the compression algorithm, followed by a [[UINT32LE]] giving the uncompressed size. It supports the same compression algorithms as [[Dynamix Font Format v4-v5#Compression|Dynamix fonts]]. The header is immediately followed by the compressed 4bpp pixel data.

This format is the 4 bit per pixel version of [[RES Format (Stellar 7)#BMP: Image|the BIN/VGA-containing BMP format]] found in several 8-bit Dynamix games.

== Tools ==

{{BeginFileFormatTools|Type=image}}
{{FileFormatTool
| Name = [https://codeberg.org/knt47/timgres The Incredible Machine level/image resource viewer] ([https://www.vogons.org/viewtopic.php?p=1089143#p1089143 VOGONS])
| Platform = Windows, Linux
| canView = Yes
| canExport = Yes
| canImport = No
| editHidden = No
| editMetadata = N/A
| notes =
}}
{{FileFormatTool
| Name = [https://www.vogons.org/viewtopic.php?f=5&t=76910 The Incredible Machine image resource reader] Note: outdated version
| Platform = Windows, Linux
| canView = Yes
| canExport = Yes
| canImport = No
| editHidden = No
| editMetadata = N/A
| notes =
}}
{{FileFormatTool
| Name = [[Engie File Converter]]
| Platform = Windows
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = N/A
| notes = Supports <tt>SCN/OFF</tt> files with a high <code>addValue</code> byte, treating them as 8-bit.
}}
{{EndFileFormatTools}}

== Credits ==
The SCN compression was reverse engineered by [[User:Knt47|Knt47]], with further detail research conducted by [[User:Nyerguds|Nyerguds]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

[[Category:Sierra/Dynamix File Formats]]

The Incredible Machine 2-3 ANM File Format

2022-08-12T21:29:59Z

Knt47: /* Tools */ TIM level viewer now hosted on Codeberg

The '''animation''' (<tt>.ANM</tt>) sub-files are found in the [[TIM Resource Format|archive file]] of [[The Incredible Machine 2]] (TIM 2) and [[Thie Incredible Machine 3|3]] (TIM 3). They contain the information required for drawing puzzle part sprites, which are often comprised of multiple sub-images of [[The Incredible Machine Image Format|image files]] and for animations of the puzzle parts. They are also used for animated parts of the game's user interface (for example the animated icons of the main menu). It can also contain commands for playing sound effects.

Most <tt>.ANM</tt> files (all in TIM 2) contain two chunks, starting with "<tt>ANM:</tt>" and "<tt>TAG:</tt>", respectively. Both use the typical "Dynamix chunk" format, starting with the 4-byte chunk type ("<tt>ANM:</tt>"/"<tt>TAG:</tt>", followed by the chunk size in 32-bit, little endian format. Unlike other Dynamix file formats, the most significant bit in the 32-bit size of the first chunk is not set. A small number of files in TIM 3 contain a third chunk, "<tt>LAB:</tt>", with an unclear meaning.

== The "ANM:" chunk ==

Not counting the chunk type and size, an "<tt>ANM:</tt> chunk has five parts, a 16 or 22 byte header, and four sections containing the actual sprite/animation frame/animation data, labeled here as A-D.

=== Header ===

The "<tt>ANM:</tt>" chunk (not counting the "<tt>ANM:</tt>" chunk type identifier and the chunk size) starts with a header, with a size of 16 or 22 bytes, depending on the magic number. It has the following Format:

[[UINT16LE]] magic_number_1;
UINT16LE magic_number_2;
UINT16LE size_section_a;
UINT16LE size_section_b;
UINT16LE size_section_c;
UINT16LE size_section_d;
UINT16LE anm_width;
UINT16LE anm_height;
/* 3 members, found only in files with a magic number of 0x54 0x42 0xEA 0x03: */
UINT16LE unknown_16;
UINT16LE unknown_18;
UINT16LE unknown_20;

* '''magic_number_1''', '''magic_number_2''': The header starts with a 4-byte magic number. The first two bytes are always 0x54 0x42. The second two bytes are a 16-bit little endian file version number. In TIM 2, the possible values 1000 (0x3E8) or 1001 (0x3E9). There is no obvious difference in the format of the files using these two numbers, however, 0x3E9 is much more common and 0x3E8 is mostly used for relatively small and simple files. In TIM 3, a small number of files use a newer version of the <tt>.ANM</tt> file format, with a magic_number_2 value of 1002 (0x3EA). Such files have a slightly different format compared to files with the other two numbers. The "newer" format is used in the user interface and the game menu, but never for puzzle part graphics.
* '''size_section_a''': The number of entries in the A section of the "<tt>ANM:</tt>" chunk, one entry is 2 byte (i.e. the section is an array of 16-bit integers). Several files do not have an A section (size_section_a == 0)
* '''size_section_b''': The number of entries in the B section. One entry is 12 bytes in the files in files with <code>magic_number_2 = 0x3EA</code>, 10 bytes in all other files.
* '''size_section_c''': The number of entries in the C section, one entry is 4 bytes.
* '''size_section_d''': The size of the D section in bytes.
* '''anm_width''', '''anm_height''': Width and height of the animation. In <tt>.ANM</tt> files for puzzle parts, the two structure members usually have the same value as width_1 and height_1 for the part in puzzle/level files.

Structure members found only in files with the longer header (<code>magic_number_2 = 0x3EA</code>):

* '''unknown_16''': 0x14 in all files, perhaps the size of header minus magic_number_1. Files with the longer header do not contain additional section in "<tt>ANM:</tt>" chunk, so it cannot be a size of such a section.
* '''unknown_18''': 0 in all files
* '''unknown_20''': 0x17 in one file, 0 in all others. Clearly not the size of an additional section in "<tt>ANM:</tt>" chunk. {{TODO|Additional research needed}}

=== Section A ===

Section A is empty in a large number of <tt>.ANM</tt> files. If present, it is an array of 16-bit little endian integers. It contains all numbers from 0 to the number of items in B section minus 1, in increasing order, with some numbers repeated. For example <code>0 1 1 1 2</code> means that the animation frame with index 1 in section B must be shown for the duration of 3 timer ticks instead of 1.

=== Section B ===

Section B is a list of structures containing 16 bit integer members, 6 if magic_number_2 is <tt>0x3EA</tt>, 5 in the other versions of the file format. It contains essential information about each animation frame. One structure has the following members:

[[INT16LE]] relative_pos_x;
INT16LE relative_pos_y;
UINT16LE width;
UINT16LE height;
UINT16LE section_d_offset;
/* Note that the last member is only present in files with */
/* magic number 0x54 0x42 0xEA 0x03 */
UINT16LE unknown_10;

* '''relative_pos_x''', '''relative_pos_y''': The coordinates where the animation frame must be drawn, relative to other frames. For the first item in the B section, the value of both tare typically 0, however there are a few exceptions. The relative position may be negative.
* '''width''', '''height''': The width and the height of the graphics in the specific animation frame.
* '''section_d_offset''': An offset in section D, points to the first command required for drawing the animation frame.
* '''unknown_10''': The meaning is unclear. Often, but not always a number divisible by 3. {{TODO|Additional research needed}}

=== Section C ===

A section C item has the following format:

UINT16LE first_frame_id;
UINT16LE state_id;

* '''first_frame_id''': The meaning of ''first_frame_id'' is slightly different between files containing or not containing an A section. If the A section is not present, this is the index in section B for the first animation frame for a particular animation. If there is an A section, ''first_frame_id'' is an index in the A section, and the 16-bit array item at this index is the required section B index. The section B indices determined this way essentially divide the B section into sub-sectons. One sub-section corresponds to the "animation" of a puzzle part or an user interface element in one specific state. If an "animation" has only one section B item, then the puzzle part or button/icon is not animated in this state.
* '''state_id''': An internal identifier used by the game for a state of the puzzle part or an user interface element. In a specific "state", the puzzle part (or user interface element) may or may not be animated, the animation frames belonging to such a state must be determined using the first_frame_id member.

=== Section D ===

The D section contains the instructions on how to draw each animation frame (or to play a sound). The section_d_offset field in the corresponding section B entry determines where the sequence of commands start for each animation frame. There are 6 different types of commands, numbered 0-5. Each command starts with its number in a 16-bit, little endian format. For commands 2-5, this is followed by a list of 16-bit integer parameters, the number of the parameters depends on command number.

==== Command 0: End of animation frame ====

Command 0 indicates the end of an animation frame in the file. It terminates the list of commands associated with a section B item. Command 0 has no parameters and is always 2 bytes long (the 16-bit command number).

==== Command 1: End of "ANM:" chunk ====

The last two bytes of section D (and the "<tt>ANM:</tt>" chunk) are always <code>01 00</code> (1 in 16-bit little endian format). These two bytes can be interpreted as a 2-byte command that terminates section D and the entire "<tt>ANM:</tt>" chunk. Command 1 is not found anywhere else in section D.

==== Command 2: Draw BMP sub-image ====

Command 2 is an instruction for the game engine to draw a sub-image from a <tt>.BMP</tt> image stored in the archive file of the game. It should be noted that a part sprite is often "cut into" multiple <tt>.BMP</tt> sub images, and in a few cases, they are stored in more than one file. Command 2 has five 16-bit integer parameters (size is 12 bytes, including the command number).

UINT16LE command_num; /* 2 */
UINT16LE bmp_file_num;
UINT16LE bmp_sub_image_num;
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE flip;

* '''bmp_file_num''': Index of the <tt>.BMP</tt> file in the TAG: chunk. The index of the first image is 1.
* '''bmp_sub_image_num''': The "sub-image" number of the <tt>.BMP</tt> file to draw. [[The Incredible Machine Image Format|<tt>.BMP</tt> images in TIM 2]] can have multiple sub images.
* '''draw_pos_x''', '''draw_pos_y''': The position of the image (top left corner), relative to the x and y coordinates in the corresponding section B item.
* '''flip''': The image can be drawn horizontally and/or vertically flipped relative to its original orientation. 1 = vertical flip, 2 = horizontal flip, 3 = both, 0 = no such transform is applied.

==== Command 3: Draw rectangle ====

Command 3 draws a rectangle with a border and fill color provided as arguments. It is mainly used in user interface elements and in the graphics shown in the part help screen, rarely in puzzle part graphics. It has the following format:

UINT16LE command_num; /* 3 */
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE rect_width;
UINT16LE rect_height;
UINT16LE border_color;
UINT16LE fill;

* '''draw_pos_x''', '''draw_pos_y''': Coordinates of the top left corner of the rectangle.
* '''rect_width''', '''rect_height''': The width and height of the rectangle.
* '''border_color''': The border color for the rectangle. In TIM 2, one color from the 16-color palette.
* '''fill''': The value of the ''fill'' parameter is either 0 - no fill, border only - or a value between 0x8000 and 0x800f where the least significant nibble contains the fill color.

==== Command 4: Draw line ====

Command 4 draws a line between two end points with a specific color. Like the rectangle command, it is mainly used for game interface graphics, not the puzzle parts. The format of the command is:

UINT16LE command_num; /* 4 */
INT16LE x1;
INT16LE y1;
INT16LE x2;
INT16LE y2;
UINT16LE line_color;

* '''x1''', '''y1''': The coordinates of one end point.
* '''x2''', '''y2''': The coordinates of the other end point.
* '''line_color''': The color of the line, one color from the 16-color palette in TIM 2.

==== Command 5: Play sound ====

If the command list for an animation frame includes command 5, a sound effect will be played when the particular frame is shown. It has one 16-bit parameter, the ID of the sound. TIM 2 contains sounds in two different formats. Sounds with a number >= 3000 are stored in the archive file of the game (<tt>SX_3???.RAW</tt>). <tt>.RAW</tt> files are uncompressed 8-bit PCM audio files without any header. The rest of the files (with numbers < 300) are found in <tt>TIM2.SX</tt>.
TIM 3 has <tt>.WAV</tt> files instead in the archive file an there is no <tt>TIM2.SX</tt>. ({{TODO|TIM 3 sounds with numbers below 3000}}).

== The "TAG:" chunk ==

The "<tt>TAG:</tt>" chunk contains the names of the <tt>.BMP</tt> sub-files (in the archive file of the game) required for displaying the animation. Not counting the "<tt>TAG:</tt>" chunk type identifier and the 32-bit chunk size, the first two bytes of the data contains the number of image file names in 16-bit little endian format. The remaining part of the data is the list of image file name entries. A single entry is a 16-bit image ID followed by a null-terminated string containing the name of the image. In TIM 2, the ID of the first image is always 1, however, there are exceptions to this rule in TIM 3 (but never in part graphics). There is no gap in the numbering of the images, this makes the image ID field somewhat redundant.

== The "LAB:" chunk ==

The "<tt>LAB:</tt>" chunk is present in a small number of <tt>.ANM</tt> files in TIM 3. <tt>.ANM</tt> files for puzzle parts never contain such a chunk. The structure of the "<tt>LAB:</tt>" chunk is similar to "<tt>TAG:</tt>", it consists of the number of entries stored as 16-bit integer, followed by item ID-null terminated string pairs. The strings are apparently not user interface texts visible to the player.

== Tools ==


[https://codeberg.org/knt47/timgres The Incredible Machine level/image resource viewer] ([https://www.vogons.org/viewtopic.php?p=1089143#p1089143 VOGONS]) supports viewing animations in TIM 2-3 <tt>.ANM</tt> files.

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)


[[Category:All file formats]]
[[Category:The Incredible Machine 2]]
[[Category:The Incredible Machine 3]]

The Incredible Machine Level Format

2022-08-12T21:28:00Z

Knt47: /* Tools */ TIM level viewer now hosted on Codeberg

{{Map Infobox
| Type =
| Layers =
| Tile size = Not tile based, the game uses a 16x16 grid for walls and a few other puzzle parts
| Viewport =
'''576×368''' (Levels in [[The Incredible Machine]] (TIM) and [[The Even More Incredible Machine]] (TEMIM))
'''640×400''' (.GKC files in TIM and TEMIM)
'''560×377''' (Levels in [[The Incredible Machine 2]] and 3)
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|The Incredible Machine 3}}
}}

This page discusses the '''level format''' of [[The Incredible Machine]], from the first DOS version (abbreviated as TIM 1) to [[The Incredible Machine 3|TIM 3]] (which is a 32-bit Windows game). Even if the format of some sections of the file vary significantly between the versions, the way how the parts are stored is highly similar. Level files have the extension <tt>.LEV</tt>.

The machines/puzzles saved from the "freeform machine" mode or the built-in level editor are also discussed here. The format of files saved from built-in editor may be identical to or slightly different from the levels, depending on the game version. Such files are saved by the game with extension <tt>.TIM</tt>.

The animated '''"title screen"''' (<tt>TITLE.GKC</tt>) and '''"credits screen"''' (<tt>CREDITS.GKC</tt>) files (inside the archive file) in TIM 1 and [[The Even More Incredible Machine]] (TEMIM) use a variant of the level file format, even if these are not playable levels.

== Magic number ==

TIM-TIM 3 level and GKC files always start with a 4-byte magic number. The following table summarizes the magic numbers found in various versions of the game.

{| class="wikitable"
! Magic number (hex) !! Usage in game versions
|-
| <code>ED AC 00 01</code>
|
* Puzzles in TIM demo version.
|-
| <code>ED AC 02 01</code>
|
* Puzzles in TIM.
* Saved freeform machines in TIM.
* GKC files in TIM.
* <tt>CREDITS.GKC</tt> in TEMIM.
|-
| <code>EE AC 05 01</code>
|
* New puzzles in TEMIM not found in TIM.
* Saved freeform machines in TEMIM.
* <tt>TITLE.GKC</tt> in TEMIM.
|-
| <code>EF AC 11 01</code>
<code>EF AC 12 01</code>
|
* A small number of puzzles in TIM 2 and 3.
|-
| <code>EF AC 13 01</code>
|
* The large majority of puzzles in TIM 2 and 3.
* Puzzles saved from the built-in editor of TIM 2.
|-
| <code>EF AC 14 01</code>
|
* A small number of puzzles in TIM 3.
* Puzzles saved from the built-in editor of TIM 3.
|}

== Structure of puzzle and GKC files ==

The level/puzzle/saved machine files consist of multiple sections. An overview of the file structure is provided below, separately for TIM / TEMIM and TIM 2 / TIM 3.

=== TIM and TEMIM ===

* Magic number, see above
* Puzzle title, null-terminated string. missing in .GKC files and "freeform machines" saved by the player.
* Goal description, null-terminated string. Absent from .GKC files and "saved freeform machines" with magic number of <code>ED AC 02 01</code>. Present in TEMIM "saved freeform machines" (magic number <code>EE AC 05 01</code>). An empty string in .GKC files with magic number <code>EE AC 05 01</code>.
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move ("fixed", e.g. walls) and are not found initially to the parts bin.
* List of part entry structures for parts that can move (e.g. balls), not in the parts bin.
* An additional 16-bit, little endian integer value in puzzles with magic number of <code>EE AC 05 01</code>. The meaning of this value is unclear. 0 in puzzles from the game archive file. In saved freeform machines, 1 if there are parts placed into the parts bin, 0 otherwise.
* List of part entry structures for parts initially placed into the parts bin.

=== TIM 2 and 3 ===

* Magic number, see above
* Two additional "header" bytes in files with magic number <code>EF AC 13 01</code> or <code>EF AC 14 01</code>. First byte is always 0, second is the background color from the 16-color palette.
* Puzzle title, null-terminated string
* Goal description, null-terminated string
* Hints, see below
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move
* List of part entry structures for parts that can move
* Solution information, see below

== Hints ==

Hints are supported only in TIM 2 and 3 puzzles. The first two bytes of the hint data contain the number of the hints in 16-bit little endian format. This is followed by 8 hint entries, some of them may be unused. A size of an unused entry is 7 bytes. One entry consists of three 16-bit integers and a null-terminated string containing the hint text. The three integer members are (all have a 16-bit little endian format):

* '''position_x''': The X position of the hand icon for the hint.
* '''position_y''': The Y position.
* '''hint_icon_flip''': The hand icon of a hint can be flipped and can have four different orientations. Possible values are 0-3.

In TIM 2, there are 3 (?) puzzles with magic number <code>EF AC 11 01</code>. Neither of these files contain hints. However, the size of the empty hints section is 42 bytes in them instead of the expected 58.

== Puzzle information data structure ==

=== In TIM and TEMIM ===

In TIM and TEMIM, there are two different puzzle header information data structures, one is used by the puzzles, and the another is found in saved "freeform" machines and the GKC files.

The information structure format in TIM / TEMIM puzzles:

[[UINT16LE]] bonus_1;
UINT16LE bonus_2;
[[INT16LE]] pressure;
INT16LE gravity;
INT16LE unknown_8;
INT16LE unknown_10;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

The information structure format in saved "freeform" machines and GKC files:

INT16LE pressure;
INT16LE gravity;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

* '''bonus_1''': The value of "Bonus 1" immediately after the puzzle is loaded (its value is constantly decreasing while the player is solving the puzzle).
* '''bonus_2''': The value of "Bonus 2" for the puzzle.
* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''unknown_8''', ''unknown_10'': The value of these two members is always -8. Perhaps the top left corner of the screen in the coordinate system used for puzzle parts, which is also (-8, -8).
* '''music''': ID of music track played. Valid values are 1001-1016 for TIM and 1001-1021 for TEMIM.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move (e.g. walls), not in the "parts bin".
* '''num_parts_moving''': Number of parts in the puzzles that move (e.g. balls), not in the "parts bin".
* '''num_parts_in_partsbin''': The number of parts that are placed into the parts bin. (The player needs to position them in order to solve the puzzle.)

=== In TIM 2 and 3 ===

The information structure format in TIM 2 and 3:

INT16LE pressure;
INT16LE gravity;
UINT16LE unknown_4;
UINT16LE unknown_6;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE unknown_14;

* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''music''': ID of music track played. Valid values are 1000-1023.
* '''unknown_4''', '''unknown_6''': Meaning is unknown, always 0.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move, regardless of whether they are placed initially into the parts bin or not.
* '''num_parts_moving''': Number of parts in the puzzles that can move.
* '''unknown_14''': Value is always 0. Likely this member corresponds to num_parts_in_partsbin in TIM / TEMIM puzzle header. Unlike TIM / TEMIM, parts placed into the parts bin are not a separate section in TIM 2 / 3, therefore, its value is always zero.

== Puzzle part data ==

With the exception of TIM demo version (see below), the size of a part entry for the majority of puzzle parts is 48 bytes. However, there are exceptions, which are discussed in separate sub-sections. The format of the "default" part entry:

UINT16LE part_type_num;
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
[[BYTE]] belt_connect_pos_x;
BYTE belt_connect_pos_y;
UINT16LE belt_line_distance;
UINT16LE unknown_32;
BYTE rope_1_connect_pos_x;
BYTE rope_1_connect_pos_y;
UINT16LE unknown_36;
BYTE rope_2_connect_pos_x;
BYTE rope_2_connect_pos_y;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''part_type_num''': A number associated with the type of the part (e.g. 0 - bowling ball). Required for identifying parts with an entry size different from the default. See [[The Incredible Machine Level Format/Part Numbers]]
* '''flags_1''': A combination of flag bits.
** '''TIM''' / '''TEMIM''' uses the following flag bits:
*** <code>0x20</code>: Unknown meaning, used for a few "moving" parts (bucket, candle)
*** <code>0x40</code>: Set if the part is a wall.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x800</code>: Part is placed initially into the parts bin (see num_parts_in_partsbin in part information data structure)
*** <code>0x1000</code>: "Moving" part, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x2000</code>: Part cannot move, in fixed position, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x4000</code>: Part cannot move, in fixed position (see ''num_parts_fixed'')
*** <code>0x8000</code>: Set when 0x800 is not set ({{TODO|further testing needed}})
** In '''TIM 2 / 3''', the bits have a known meaning:
*** <code>0x40</code>: Meaning unclear, used for "moving" parts only, but not always set, even for a single type of part.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x1000</code>: "Moving" part, affected by gravity.
*** <code>0x2000</code>, 0x4000: Used in combination for parts that do not move and are not affected by gravity.
* '''flags_2''': Another word containing flag bits. The meaning of most flags is the same in all game versions.
** <code>0x1</code>: A belt can be connected to the part.
** <code>0x2</code>: A belt is connected to the part.
** <code>0x4</code>: A rope can be connected to the part.
** <code>0x8</code>: A second rope can be connected to the part (teeter-totter)
** <code>0x10</code>: The part sprite is drawn horizontally flipped.
** <code>0x20</code>: The part sprite is drawn vertically flipped. Note on flip flags: Flipping a part in the game does not necessarily mean that one of the flip flags will be changed. For several parts, especially in TIM 2 / 3, flipping will affect the value of the ''appearance'' member.
** <code>0x40</code>: Probably unused
** <code>0x80</code>: Part can be stretched in at least one direction: inclines, conveyor belt, walls.
** <code>0x100</code>: Parts that can be stretched both horizontally and vertically, the walls.
* '''flags_3''': Some flags are only present in TIM 2 / 3. This member of the part data structure is missing in the demo version of TIM.
** <code>0x1</code>: The part can be plugged into an electric outlet.
** <code>0x2</code>: The part is an electric outlet.
** <code>0x4</code>: The part can burn (e.g. candle) or has a fuse that can be lit (e.g. dynamite, cannon). Usually in combination with flag 0x8.
** <code>0x8</code>: Meaning of this flag is unclear. Used for several part types, but changing it has no apparent consequence (?)
** Flags present only in '''TIM 2 / 3''':
*** <code>0x40</code>: Part is "locked", i.e not placed into the part bin.
*** <code>0x80</code>: Sizable scenery part (?)
*** <code>0x100</code>: {{TODO|unknown meaning}}
*** <code>0x400</code>: A "program" icon is shown for the part (?)
*** <code>0x1000</code>: Scenery part
*** <code>0x2000</code>: Wall part (?)
*** <code>0x8000</code>: A "Puzzle solution" icon is shown for the part (?)
* '''appearance''': An identifier for the sprite that is shown for a part before the machine is started. (Once the machine is started, the state of the part can change and so can the sprite shown.) The meaning is different between TIM and TIM 2. In TIM, the sprite of some parts consists of only one image, in this case, this is often the number of the sub-image in the [[The Incredible Machine Image Format|image resource file]]. ({{TODO|For other parts, this is probably an internal identifier for the sprite (?)}}). In TIM 2 and 3, the meaning of the appearance is an index in the A section of the [[The Incredible Machine 2-3 ANM File Format|.ANM file]] for the part, or if this is absent, an index in the B section. "Programming" a part in TIM 2 and 3 often results in the change of this field.
* '''unknown_10''': Probably unused, usually 0.
* '''width_1''', '''height_1''': The width and height of the selectable area of the part ({{TODO|more reverse engineering work needed}})
* '''width_2''', '''height_2''': At least in TIM 2, witdh_2 is used for calculating the position of part sprite when the part is flipped because of the horizontal flip bit is set in flags_2.
* '''pos_x''', '''pos_y''': The position of the part, usually the top left corner of the bounding rectangle.
* '''behavior''': In TIM 2 and 3, a programmed behavior of the part. (However, for many parts, "programming" modifies the ''appearance'' member.) For example the number of shots of the phazer gun or character shown by the message computer. Meaning is different for rope parts, see below. Unused in TIM and TEMIM (except for ropes).
* '''unknown_26''': Probably unused, usually 0. Note that belt parts have a value of 1 in this position.
* '''belt_connect_pos_x''', '''belt_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Always positive or 0, because ''pos_x'' and ''pos_y'' are the coordinates of the top left corner where the sprite starts. Note that the formulas required for calculating the exact position of the belt are slightly different between TIM and TIM 2. Parts for which connection of a belt is allowed have a distinct circular area in their sprite, corresponding to the location where the belt is connected. In TIM / TEMIM, ''belt_connect_pos_x'' and ''belt_connect_pos_y'' is approximately the top left corner of its bounding rectangle, while in TIM 2 /3 it is close to the center of the circle.
* '''unknown_36''': Probably unused, usually 0.
* '''belt_line_distance''': The belts in the game appear as two, usually not perfectly parallel black (TIM / TEMIM) or gray (TIM 2 / 3) lines. This parameter determines the distance between the two segments, More precisely, it is either approximately the diameter of the circular area mentioned at ''belt_connect_pos_x'' and ''belt_connect_pos_y'' (TIM / TEMIM) or its radius (TIM 2 / 3).
* '''unknown_32''': Probably unused, usually 0.
* '''rope_1_connect_pos_x''', '''rope_1_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Similarly to belt_connect_pos_x/y, always positive or 0.
* '''rope_2_connect_pos_x''', '''rope_2_connect_pos_y''': The same as ''rope_1_connect_pos_x'', ''rope_1_connect_pos_y'', bit for another connected rope part.
* '''connected_1''', '''connected_2''': The index of one or two parts in the puzzle that are connected to this part with a rope. If the rope runs through pulleys, this is the part index of the first pulley. If no rope is connected or this is not possible for the part, the value of both structure members are -1. (Of course, if one rope is connected, the value of one structure member (usually connected_rope_1) is the index of the rope part and the other is -1) )In TIM 2 and 3, the "remote bomb" part actually corresponds to two entries in the puzzle file. The connected_rope_2 field contains the index of the another "element" of the bomb, in both entries.
* '''outlet_plugged_1''', '''outlet_plugged_2''': These structure members are only meaningful for electric outlet parts. Electric outlets always have 2 "sockets" for parts requiring electricity. It contains the index/indices of the part/parts plugged into the electric outlet, or -1 if the "socket" is free. If the part does not support this, both values are -1.

=== Belts ===

Belt parts (part 8) (except in the demo version of TIM, see below) use a 52-byte entry, with the following format:

UINT16LE part_type_num; /* 8 for belts */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
INT16LE belt_connected_part_1;
INT16LE belt_connected_part_2;
UINT16LE unknown_36;
UINT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0</code>, <code>flags_3 = 0</code>
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0</code>, <code>flags_3 = 0x40</code> (or <code>0</code> if in parts bin)
* '''appearance''': Always 0, belts have no true sprite (represented by two lines).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for belts, always 0.
* '''pos_x''', '''pos_y''' In TIM / TEMIM, either 0 or -1. In TIM 2, -1 or -100 (0xff9c). Meaning of these numbers is unclear, and the usage of the two different values do not correlate with the flags.
* '''behavior''': Not used, always 0.
* '''unknown_26''': Always 1, perhaps indicates that the part is a belt.
* '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''belt_connected_part_1''', '''belt_connected_part_2''': Index of the two parts in the puzzle connected by this belt. In TIM and TEMIM, both are -1 if the belt is placed into the parts bin.
* '''unknown_36''', '''unknown_38''', '''unknown_40''', '''unknown_42''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Ropes ===

Rope parts (part 10) (except in the demo version of TIM, see below) use a 54-byte entry. TIM 2 and 3 also have a "steel cable" part (part 76) which also behaves as a rope and the size of the part entry is also identical. The rope part entry has the following format:

UINT16LE part_type_num; /* 10 for rope, 76 for steel cable */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE rope_segment_length;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
UINT16LE unknown_36;
INT16LE rope_connected_part_1;
INT16LE rope_connected_part_2;
BYTE part_1_connect_field_usage;
BYTE part_2_connect_field_usage;
UINT16LE unknown_44;
UINT16LE unknown_46;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''': Same flags used as in the belt part structure.
* '''appearance''': Always 0, ropes have no true sprite (represented by one or more line segments).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for ropes, always 0.
* '''pos_x''', '''pos_y''': Similarly to belts, possible values are 0 and -1 in TIM / TEMIM; and -1 and -100 in TIM 2 / 3.
* '''rope_segment_length''': The length of the rope (Euclidean distance between the two ends) if the rope does not run through pulleys. Otherwise, the length of the rope segment between the part at one end (rope_connected_part_1 (?)) and the first pulley ({{TODO|additional testing needed}}).
* '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for pulleys.
* '''unknown_36''': Not used, always 0.
* '''rope_connected_part_1''', '''rope_connected_part_2''': Index of the two parts in the puzzle connected by this rope (never the pulleys). In TIM and TEMIM, both are -1 if the rope is placed into the parts bin.
* '''part_1_connect_field_usage''', '''part_2_connect_field_usage''': Whether ''connected_1'' or ''connected_2'' is used in the two connected parts for this rope. 0 if connected_1, 1 if connected_2. ({{TODO|additional testing needed}})
* '''unknown_44''', '''unknown_46''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Pulleys ===

The format of the 56-byte puzzle part entry for the pulley (part 7):

UINT16LE part_type_num; /* 7 for pulley */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
BYTE pulley_rope_1_connect_pos_x;
BYTE pulley_rope_1_connect_pos_y;
INT16LE unknown_36;
INT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
BYTE pulley_rope_2_connect_pos_x;
BYTE pulley_rope_2_connect_pos_y;
INT16LE pulley_connected_1;
INT16LE pulley_connected_2;
INT16LE unknown_50;
INT16LE unknown_52;
INT16LE rope_index;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0x4</code>, <code>flags_3 = 0x8</code> (<code>0x0</code> {{TODO|in some cases}})
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0x4</code>, <code>flags_3 = 0x48</code> (or <code>0x8</code> if in parts bin)
* '''appearance''': Pulleys can have four different sprites depending on the orientation. Possible values are 0-3.
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': The size of the pulley sprite. In TIM 2 / 3, also depends on the orientation.
* '''pos_x''', '''pos_y''': The position of the pulley, top left coordinates of the bounding rectangle.
* '''behavior''', '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for ropes.
* '''pulley_rope_1_connect_pos_x''', '''pulley_rope_1_connect_pos_y''': The coordinates of the point where one rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''. Depends on the orientation of the pulley, like ''appearance''.
* '''unknown_36''', '''unknown_38''': Not used, always -1.
* '''unknown_40'', ''unknown_42''': Not used, always 0.
* '''pulley_rope_2_connect_pos_x''', '''pulley_rope_2_connect_pos_y''': The coordinates of the point where the other rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''.
* '''pulley_connected_1''', '''pulley_connected_2''': Either the index of part at one of the two ends of the rope, or the index of next or previous pulley the rope is running through.
* '''unknown_50''', '''unknown_52''': Not used, always -1.
* '''rope_index''': In TIM 2 / 3, the index of the rope part. Not used (-1) in TIM and TEMIM.

=== Programmable ball (TIM 2 / 3) ===

The programmable ball part is present in TIM 2 and 3, and its part type number is 87. The size of the entry is 60 bytes in total. The first 48 bytes is the same as the default part data structure, which is followed by another, 12-byte structure specific to this part. The format of the programmable ball data is:

UINT16LE density;
UINT16LE elasticity;
UINT16LE friction;
INT16LE gravity_buoyancy;
UINT16LE mass;
UINT16LE appearance_2;

* '''density''': The density of the ball, affects the buoyant force acting on the ball.
* '''elasticity''': The elasticity of the ball.
* '''friction''': The friction.
* '''gravity_buoyancy''': A calculated parameter, using the density and the mass of the ball, as well as the gravity and the pressure set for the puzzle. If its value is negative, the ball will rise due to the buoyant force rather than fall.
* '''mass''': The mass of the ball.
* '''appearance_2''': Has the same value as the ''appearance'' field. The ball can have 7 different colors/patterns.

The game has a dialog for setting the four physical properties (mass, elasticity, density, friction, in this order). However, the number stored in the data structure is not the same as the numbers shown on the program dialog. For example, if following settings are used for the ball: <code>mass = 8</code>, <code>elasticity = 3</code>, <code>density = 7</code>, <code>friction = 3</code>; and the default values are used for gravity/pressure, the puzzle file will contain the following values: <code>density = 3000</code>, <code>elasticity = 128</code>, <code>friction = 16</code>, <code>gravity_buoyancy = 269</code>, <code>mass = 201</code>. (Note: There is an inconsistency in the game here, the programmable ball part uses <code>density = 2832</code> and <code>mass = 200</code> by default, which does not correspond exactly to any value that can be set in the dialog.)

=== TIM demo version ===

In the demo version of the (original) TIM (available at several DOS shareware game websites), the ''flags_3'', ''outlet_plugged_1'' and ''outlet_plugged_2'' fields are missing.
Instead, the 42-byte part data (46 for belts, 48 for ropes, 50 for pulleys) is followed by an another, variable length data structure of unknown significance consisting of 16-bit little endian integers. It is always at least 2 bytes long, and the first two bytes contain the number of additional 16-bit words after this size word. The reverse engineering of this structure is complicated by the fact that it is only present in a demo version containing only 8 puzzles.

== Puzzle solution information ==

Puzzle solution information is only present in TIM 2 and TIM 3 puzzles. Its size is always 132 bytes and can contain 8 different conditions that must be satisfied so that the game will recognize the puzzle as solved. The first two bytes contains the number of such conditions actually set, in a 16-bit little endian format. This is followed by 8 entries, 16 bytes each, containing the required information for solution checking by the game. The format of each entry is:

INT16LE part_index;
UINT16LE part_state_1;
UINT16LE part_state_2;
UINT16LE part_count;
INT16LE position_rect_x;
INT16LE position_rect_y;
INT16LE position_rect_width;
INT16LE position_rect_height;

* '''part_index''': The index of the part in the puzzle file involved in the solution. -1 (0xFF 0xFF) for unused entries.
* '''part_state_1''': An ID for a "physical state" of a part (for example a balloon was popped or a candle was lit). In many puzzles, one specific part must be in a specified "physical state" in order to complete the level. This is the same ID for a "part state" as the ''first_frame_id'' member found in the C section of the part's ANM file.
* '''part_state_2''': Another ID for a "physical state", the exact meaning is unclear.
* '''part_count''': The value of the "Part count" option set in the "program solution" dialog of the game.
* '''position_rect_x''', '''position_rect_y''': The top left corner of the "position rectangle". If such a solution specified puzzle part must be located within this rectangle in order to solve the puzzle.
* '''position_rect_width''', '''position_rect_height''': Width and height of the "position rectangle", see above.

For the last four members ("position rectangle"), there are "fixed" combinations of values with special meaning:

* <code>-1, -1, -1, -1</code>: "Off screen", the part must leave the area visible on the game screen.
* <code>-500, -2000, 1640, 2000</code>: "Off top", the part must leave the visible area at the top.
* <code>-500, 400, 1640, 3000</code>: "Off bottom"
* <code>0, 0, 0, 0</code>: No such solution programmed, either this is "part state" solution or an unused entry (<code>part_index = -1</code>).

The last 2 bytes of the section contain the value of the "Delay" option set in the "program solution" dialog of the game, in 16-bit little endian format.

'''Note on puzzle solution information in TIM and TEMIM''': TIM / TEMIM puzzles do not contain such data. This can also be demonstrated by extracting e.g. <tt>L1.LEV</tt> from the archive file and rename the file to change the number. After starting the game, the level with the same number as the renamed file will be replaced with level 1. When playing the modified level, the game will not be able to check whether the puzzle is solved. Depending on its number, the level can become unwinnable or winnable by just clicking on the start machine button. Sometimes the game freezes.

== Tools ==
{{BeginFileFormatTools|Type=map}}
{{FileFormatTool
| Name = [https://codeberg.org/knt47/timgres The Incredible Machine level/image resource viewer] ([https://www.vogons.org/viewtopic.php?p=1089143#p1089143 VOGONS])
| Platform = Windows, Linux
| canView = Yes

| canCreate = No
| canModify = No
| editHidden = N/A
| editMetadata = N/A
| notes =
}}
{{EndFileFormatTools}}

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

The Incredible Machine Level Format

2022-07-23T09:10:10Z

Knt47: /* Puzzle part data */

{{Map Infobox
| Type =
| Layers =
| Tile size = Not tile based, the game uses a 16x16 grid for walls and a few other puzzle parts
| Viewport =
'''576×368''' (Levels in [[The Incredible Machine]] (TIM) and [[The Even More Incredible Machine]] (TEMIM))
'''640×400''' (.GKC files in TIM and TEMIM)
'''560×377''' (Levels in [[The Incredible Machine 2]] and 3)
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|The Incredible Machine 3}}
}}

This page discusses the '''level format''' of [[The Incredible Machine]], from the first DOS version (abbreviated as TIM 1) to [[The Incredible Machine 3|TIM 3]] (which is a 32-bit Windows game). Even if the format of some sections of the file vary significantly between the versions, the way how the parts are stored is highly similar. Level files have the extension <tt>.LEV</tt>.

The machines/puzzles saved from the "freeform machine" mode or the built-in level editor are also discussed here. The format of files saved from built-in editor may be identical to or slightly different from the levels, depending on the game version. Such files are saved by the game with extension <tt>.TIM</tt>.

The animated '''"title screen"''' (<tt>TITLE.GKC</tt>) and '''"credits screen"''' (<tt>CREDITS.GKC</tt>) files (inside the archive file) in TIM 1 and [[The Even More Incredible Machine]] (TEMIM) use a variant of the level file format, even if these are not playable levels.

== Magic number ==

TIM-TIM 3 level and GKC files always start with a 4-byte magic number. The following table summarizes the magic numbers found in various versions of the game.

{| class="wikitable"
! Magic number (hex) !! Usage in game versions
|-
| <code>ED AC 00 01</code>
|
* Puzzles in TIM demo version.
|-
| <code>ED AC 02 01</code>
|
* Puzzles in TIM.
* Saved freeform machines in TIM.
* GKC files in TIM.
* <tt>CREDITS.GKC</tt> in TEMIM.
|-
| <code>EE AC 05 01</code>
|
* New puzzles in TEMIM not found in TIM.
* Saved freeform machines in TEMIM.
* <tt>TITLE.GKC</tt> in TEMIM.
|-
| <code>EF AC 11 01</code>
<code>EF AC 12 01</code>
|
* A small number of puzzles in TIM 2 and 3.
|-
| <code>EF AC 13 01</code>
|
* The large majority of puzzles in TIM 2 and 3.
* Puzzles saved from the built-in editor of TIM 2.
|-
| <code>EF AC 14 01</code>
|
* A small number of puzzles in TIM 3.
* Puzzles saved from the built-in editor of TIM 3.
|}

== Structure of puzzle and GKC files ==

The level/puzzle/saved machine files consist of multiple sections. An overview of the file structure is provided below, separately for TIM / TEMIM and TIM 2 / TIM 3.

=== TIM and TEMIM ===

* Magic number, see above
* Puzzle title, null-terminated string. missing in .GKC files and "freeform machines" saved by the player.
* Goal description, null-terminated string. Absent from .GKC files and "saved freeform machines" with magic number of <code>ED AC 02 01</code>. Present in TEMIM "saved freeform machines" (magic number <code>EE AC 05 01</code>). An empty string in .GKC files with magic number <code>EE AC 05 01</code>.
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move ("fixed", e.g. walls) and are not found initially to the parts bin.
* List of part entry structures for parts that can move (e.g. balls), not in the parts bin.
* An additional 16-bit, little endian integer value in puzzles with magic number of <code>EE AC 05 01</code>. The meaning of this value is unclear. 0 in puzzles from the game archive file. In saved freeform machines, 1 if there are parts placed into the parts bin, 0 otherwise.
* List of part entry structures for parts initially placed into the parts bin.

=== TIM 2 and 3 ===

* Magic number, see above
* Two additional "header" bytes in files with magic number <code>EF AC 13 01</code> or <code>EF AC 14 01</code>. First byte is always 0, second is the background color from the 16-color palette.
* Puzzle title, null-terminated string
* Goal description, null-terminated string
* Hints, see below
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move
* List of part entry structures for parts that can move
* Solution information, see below

== Hints ==

Hints are supported only in TIM 2 and 3 puzzles. The first two bytes of the hint data contain the number of the hints in 16-bit little endian format. This is followed by 8 hint entries, some of them may be unused. A size of an unused entry is 7 bytes. One entry consists of three 16-bit integers and a null-terminated string containing the hint text. The three integer members are (all have a 16-bit little endian format):

* '''position_x''': The X position of the hand icon for the hint.
* '''position_y''': The Y position.
* '''hint_icon_flip''': The hand icon of a hint can be flipped and can have four different orientations. Possible values are 0-3.

In TIM 2, there are 3 (?) puzzles with magic number <code>EF AC 11 01</code>. Neither of these files contain hints. However, the size of the empty hints section is 42 bytes in them instead of the expected 58.

== Puzzle information data structure ==

=== In TIM and TEMIM ===

In TIM and TEMIM, there are two different puzzle header information data structures, one is used by the puzzles, and the another is found in saved "freeform" machines and the GKC files.

The information structure format in TIM / TEMIM puzzles:

[[UINT16LE]] bonus_1;
UINT16LE bonus_2;
[[INT16LE]] pressure;
INT16LE gravity;
INT16LE unknown_8;
INT16LE unknown_10;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

The information structure format in saved "freeform" machines and GKC files:

INT16LE pressure;
INT16LE gravity;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

* '''bonus_1''': The value of "Bonus 1" immediately after the puzzle is loaded (its value is constantly decreasing while the player is solving the puzzle).
* '''bonus_2''': The value of "Bonus 2" for the puzzle.
* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''unknown_8''', ''unknown_10'': The value of these two members is always -8. Perhaps the top left corner of the screen in the coordinate system used for puzzle parts, which is also (-8, -8).
* '''music''': ID of music track played. Valid values are 1001-1016 for TIM and 1001-1021 for TEMIM.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move (e.g. walls), not in the "parts bin".
* '''num_parts_moving''': Number of parts in the puzzles that move (e.g. balls), not in the "parts bin".
* '''num_parts_in_partsbin''': The number of parts that are placed into the parts bin. (The player needs to position them in order to solve the puzzle.)

=== In TIM 2 and 3 ===

The information structure format in TIM 2 and 3:

INT16LE pressure;
INT16LE gravity;
UINT16LE unknown_4;
UINT16LE unknown_6;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE unknown_14;

* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''music''': ID of music track played. Valid values are 1000-1023.
* '''unknown_4''', '''unknown_6''': Meaning is unknown, always 0.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move, regardless of whether they are placed initially into the parts bin or not.
* '''num_parts_moving''': Number of parts in the puzzles that can move.
* '''unknown_14''': Value is always 0. Likely this member corresponds to num_parts_in_partsbin in TIM / TEMIM puzzle header. Unlike TIM / TEMIM, parts placed into the parts bin are not a separate section in TIM 2 / 3, therefore, its value is always zero.

== Puzzle part data ==

With the exception of TIM demo version (see below), the size of a part entry for the majority of puzzle parts is 48 bytes. However, there are exceptions, which are discussed in separate sub-sections. The format of the "default" part entry:

UINT16LE part_type_num;
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
[[BYTE]] belt_connect_pos_x;
BYTE belt_connect_pos_y;
UINT16LE belt_line_distance;
UINT16LE unknown_32;
BYTE rope_1_connect_pos_x;
BYTE rope_1_connect_pos_y;
UINT16LE unknown_36;
BYTE rope_2_connect_pos_x;
BYTE rope_2_connect_pos_y;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''part_type_num''': A number associated with the type of the part (e.g. 0 - bowling ball). Required for identifying parts with an entry size different from the default. See [[The Incredible Machine Level Format/Part Numbers]]
* '''flags_1''': A combination of flag bits.
** '''TIM''' / '''TEMIM''' uses the following flag bits:
*** <code>0x20</code>: Unknown meaning, used for a few "moving" parts (bucket, candle)
*** <code>0x40</code>: Set if the part is a wall.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x800</code>: Part is placed initially into the parts bin (see num_parts_in_partsbin in part information data structure)
*** <code>0x1000</code>: "Moving" part, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x2000</code>: Part cannot move, in fixed position, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x4000</code>: Part cannot move, in fixed position (see ''num_parts_fixed'')
*** <code>0x8000</code>: Set when 0x800 is not set ({{TODO|further testing needed}})
** In '''TIM 2 / 3''', the bits have a known meaning:
*** <code>0x40</code>: Meaning unclear, used for "moving" parts only, but not always set, even for a single type of part.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x1000</code>: "Moving" part, affected by gravity.
*** <code>0x2000</code>, 0x4000: Used in combination for parts that do not move and are not affected by gravity.
* '''flags_2''': Another word containing flag bits. The meaning of most flags is the same in all game versions.
** <code>0x1</code>: A belt can be connected to the part.
** <code>0x2</code>: A belt is connected to the part.
** <code>0x4</code>: A rope can be connected to the part.
** <code>0x8</code>: A second rope can be connected to the part (teeter-totter)
** <code>0x10</code>: The part sprite is drawn horizontally flipped.
** <code>0x20</code>: The part sprite is drawn vertically flipped. Note on flip flags: Flipping a part in the game does not necessarily mean that one of the flip flags will be changed. For several parts, especially in TIM 2 / 3, flipping will affect the value of the ''appearance'' member.
** <code>0x40</code>: Probably unused
** <code>0x80</code>: Part can be stretched in at least one direction: inclines, conveyor belt, walls.
** <code>0x100</code>: Parts that can be stretched both horizontally and vertically, the walls.
* '''flags_3''': Some flags are only present in TIM 2 / 3. This member of the part data structure is missing in the demo version of TIM.
** <code>0x1</code>: The part can be plugged into an electric outlet.
** <code>0x2</code>: The part is an electric outlet.
** <code>0x4</code>: The part can burn (e.g. candle) or has a fuse that can be lit (e.g. dynamite, cannon). Usually in combination with flag 0x8.
** <code>0x8</code>: Meaning of this flag is unclear. Used for several part types, but changing it has no apparent consequence (?)
** Flags present only in '''TIM 2 / 3''':
*** <code>0x40</code>: Part is "locked", i.e not placed into the part bin.
*** <code>0x80</code>: Sizable scenery part (?)
*** <code>0x100</code>: {{TODO|unknown meaning}}
*** <code>0x400</code>: A "program" icon is shown for the part (?)
*** <code>0x1000</code>: Scenery part
*** <code>0x2000</code>: Wall part (?)
*** <code>0x8000</code>: A "Puzzle solution" icon is shown for the part (?)
* '''appearance''': An identifier for the sprite that is shown for a part before the machine is started. (Once the machine is started, the state of the part can change and so can the sprite shown.) The meaning is different between TIM and TIM 2. In TIM, the sprite of some parts consists of only one image, in this case, this is often the number of the sub-image in the [[The Incredible Machine Image Format|image resource file]]. ({{TODO|For other parts, this is probably an internal identifier for the sprite (?)}}). In TIM 2 and 3, the meaning of the appearance is an index in the A section of the [[The Incredible Machine 2-3 ANM File Format|.ANM file]] for the part, or if this is absent, an index in the B section. "Programming" a part in TIM 2 and 3 often results in the change of this field.
* '''unknown_10''': Probably unused, usually 0.
* '''width_1''', '''height_1''': The width and height of the selectable area of the part ({{TODO|more reverse engineering work needed}})
* '''width_2''', '''height_2''': At least in TIM 2, witdh_2 is used for calculating the position of part sprite when the part is flipped because of the horizontal flip bit is set in flags_2.
* '''pos_x''', '''pos_y''': The position of the part, usually the top left corner of the bounding rectangle.
* '''behavior''': In TIM 2 and 3, a programmed behavior of the part. (However, for many parts, "programming" modifies the ''appearance'' member.) For example the number of shots of the phazer gun or character shown by the message computer. Meaning is different for rope parts, see below. Unused in TIM and TEMIM (except for ropes).
* '''unknown_26''': Probably unused, usually 0. Note that belt parts have a value of 1 in this position.
* '''belt_connect_pos_x''', '''belt_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Always positive or 0, because ''pos_x'' and ''pos_y'' are the coordinates of the top left corner where the sprite starts. Note that the formulas required for calculating the exact position of the belt are slightly different between TIM and TIM 2. Parts for which connection of a belt is allowed have a distinct circular area in their sprite, corresponding to the location where the belt is connected. In TIM / TEMIM, ''belt_connect_pos_x'' and ''belt_connect_pos_y'' is approximately the top left corner of its bounding rectangle, while in TIM 2 /3 it is close to the center of the circle.
* '''unknown_36''': Probably unused, usually 0.
* '''belt_line_distance''': The belts in the game appear as two, usually not perfectly parallel black (TIM / TEMIM) or gray (TIM 2 / 3) lines. This parameter determines the distance between the two segments, More precisely, it is either approximately the diameter of the circular area mentioned at ''belt_connect_pos_x'' and ''belt_connect_pos_y'' (TIM / TEMIM) or its radius (TIM 2 / 3).
* '''unknown_32''': Probably unused, usually 0.
* '''rope_1_connect_pos_x''', '''rope_1_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Similarly to belt_connect_pos_x/y, always positive or 0.
* '''rope_2_connect_pos_x''', '''rope_2_connect_pos_y''': The same as ''rope_1_connect_pos_x'', ''rope_1_connect_pos_y'', bit for another connected rope part.
* '''connected_1''', '''connected_2''': The index of one or two parts in the puzzle that are connected to this part with a rope. If the rope runs through pulleys, this is the part index of the first pulley. If no rope is connected or this is not possible for the part, the value of both structure members are -1. (Of course, if one rope is connected, the value of one structure member (usually connected_rope_1) is the index of the rope part and the other is -1) )In TIM 2 and 3, the "remote bomb" part actually corresponds to two entries in the puzzle file. The connected_rope_2 field contains the index of the another "element" of the bomb, in both entries.
* '''outlet_plugged_1''', '''outlet_plugged_2''': These structure members are only meaningful for electric outlet parts. Electric outlets always have 2 "sockets" for parts requiring electricity. It contains the index/indices of the part/parts plugged into the electric outlet, or -1 if the "socket" is free. If the part does not support this, both values are -1.

=== Belts ===

Belt parts (part 8) (except in the demo version of TIM, see below) use a 52-byte entry, with the following format:

UINT16LE part_type_num; /* 8 for belts */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
INT16LE belt_connected_part_1;
INT16LE belt_connected_part_2;
UINT16LE unknown_36;
UINT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0</code>, <code>flags_3 = 0</code>
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0</code>, <code>flags_3 = 0x40</code> (or <code>0</code> if in parts bin)
* '''appearance''': Always 0, belts have no true sprite (represented by two lines).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for belts, always 0.
* '''pos_x''', '''pos_y''' In TIM / TEMIM, either 0 or -1. In TIM 2, -1 or -100 (0xff9c). Meaning of these numbers is unclear, and the usage of the two different values do not correlate with the flags.
* '''behavior''': Not used, always 0.
* '''unknown_26''': Always 1, perhaps indicates that the part is a belt.
* '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''belt_connected_part_1''', '''belt_connected_part_2''': Index of the two parts in the puzzle connected by this belt. In TIM and TEMIM, both are -1 if the belt is placed into the parts bin.
* '''unknown_36''', '''unknown_38''', '''unknown_40''', '''unknown_42''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Ropes ===

Rope parts (part 10) (except in the demo version of TIM, see below) use a 54-byte entry. TIM 2 and 3 also have a "steel cable" part (part 76) which also behaves as a rope and the size of the part entry is also identical. The rope part entry has the following format:

UINT16LE part_type_num; /* 10 for rope, 76 for steel cable */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE rope_segment_length;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
UINT16LE unknown_36;
INT16LE rope_connected_part_1;
INT16LE rope_connected_part_2;
BYTE part_1_connect_field_usage;
BYTE part_2_connect_field_usage;
UINT16LE unknown_44;
UINT16LE unknown_46;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''': Same flags used as in the belt part structure.
* '''appearance''': Always 0, ropes have no true sprite (represented by one or more line segments).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for ropes, always 0.
* '''pos_x''', '''pos_y''': Similarly to belts, possible values are 0 and -1 in TIM / TEMIM; and -1 and -100 in TIM 2 / 3.
* '''rope_segment_length''': The length of the rope (Euclidean distance between the two ends) if the rope does not run through pulleys. Otherwise, the length of the rope segment between the part at one end (rope_connected_part_1 (?)) and the first pulley ({{TODO|additional testing needed}}).
* '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for pulleys.
* '''unknown_36''': Not used, always 0.
* '''rope_connected_part_1''', '''rope_connected_part_2''': Index of the two parts in the puzzle connected by this rope (never the pulleys). In TIM and TEMIM, both are -1 if the rope is placed into the parts bin.
* '''part_1_connect_field_usage''', '''part_2_connect_field_usage''': Whether ''connected_1'' or ''connected_2'' is used in the two connected parts for this rope. 0 if connected_1, 1 if connected_2. ({{TODO|additional testing needed}})
* '''unknown_44''', '''unknown_46''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Pulleys ===

The format of the 56-byte puzzle part entry for the pulley (part 7):

UINT16LE part_type_num; /* 7 for pulley */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
BYTE pulley_rope_1_connect_pos_x;
BYTE pulley_rope_1_connect_pos_y;
INT16LE unknown_36;
INT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
BYTE pulley_rope_2_connect_pos_x;
BYTE pulley_rope_2_connect_pos_y;
INT16LE pulley_connected_1;
INT16LE pulley_connected_2;
INT16LE unknown_50;
INT16LE unknown_52;
INT16LE rope_index;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0x4</code>, <code>flags_3 = 0x8</code> (<code>0x0</code> {{TODO|in some cases}})
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0x4</code>, <code>flags_3 = 0x48</code> (or <code>0x8</code> if in parts bin)
* '''appearance''': Pulleys can have four different sprites depending on the orientation. Possible values are 0-3.
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': The size of the pulley sprite. In TIM 2 / 3, also depends on the orientation.
* '''pos_x''', '''pos_y''': The position of the pulley, top left coordinates of the bounding rectangle.
* '''behavior''', '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for ropes.
* '''pulley_rope_1_connect_pos_x''', '''pulley_rope_1_connect_pos_y''': The coordinates of the point where one rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''. Depends on the orientation of the pulley, like ''appearance''.
* '''unknown_36''', '''unknown_38''': Not used, always -1.
* '''unknown_40'', ''unknown_42''': Not used, always 0.
* '''pulley_rope_2_connect_pos_x''', '''pulley_rope_2_connect_pos_y''': The coordinates of the point where the other rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''.
* '''pulley_connected_1''', '''pulley_connected_2''': Either the index of part at one of the two ends of the rope, or the index of next or previous pulley the rope is running through.
* '''unknown_50''', '''unknown_52''': Not used, always -1.
* '''rope_index''': In TIM 2 / 3, the index of the rope part. Not used (-1) in TIM and TEMIM.

=== Programmable ball (TIM 2 / 3) ===

The programmable ball part is present in TIM 2 and 3, and its part type number is 87. The size of the entry is 60 bytes in total. The first 48 bytes is the same as the default part data structure, which is followed by another, 12-byte structure specific to this part. The format of the programmable ball data is:

UINT16LE density;
UINT16LE elasticity;
UINT16LE friction;
INT16LE gravity_buoyancy;
UINT16LE mass;
UINT16LE appearance_2;

* '''density''': The density of the ball, affects the buoyant force acting on the ball.
* '''elasticity''': The elasticity of the ball.
* '''friction''': The friction.
* '''gravity_buoyancy''': A calculated parameter, using the density and the mass of the ball, as well as the gravity and the pressure set for the puzzle. If its value is negative, the ball will rise due to the buoyant force rather than fall.
* '''mass''': The mass of the ball.
* '''appearance_2''': Has the same value as the ''appearance'' field. The ball can have 7 different colors/patterns.

The game has a dialog for setting the four physical properties (mass, elasticity, density, friction, in this order). However, the number stored in the data structure is not the same as the numbers shown on the program dialog. For example, if following settings are used for the ball: <code>mass = 8</code>, <code>elasticity = 3</code>, <code>density = 7</code>, <code>friction = 3</code>; and the default values are used for gravity/pressure, the puzzle file will contain the following values: <code>density = 3000</code>, <code>elasticity = 128</code>, <code>friction = 16</code>, <code>gravity_buoyancy = 269</code>, <code>mass = 201</code>. (Note: There is an inconsistency in the game here, the programmable ball part uses <code>density = 2832</code> and <code>mass = 200</code> by default, which does not correspond exactly to any value that can be set in the dialog.)

=== TIM demo version ===

In the demo version of the (original) TIM (available at several DOS shareware game websites), the ''flags_3'', ''outlet_plugged_1'' and ''outlet_plugged_2'' fields are missing.
Instead, the 42-byte part data (46 for belts, 48 for ropes, 50 for pulleys) is followed by an another, variable length data structure of unknown significance consisting of 16-bit little endian integers. It is always at least 2 bytes long, and the first two bytes contain the number of additional 16-bit words after this size word. The reverse engineering of this structure is complicated by the fact that it is only present in a demo version containing only 8 puzzles.

== Puzzle solution information ==

Puzzle solution information is only present in TIM 2 and TIM 3 puzzles. Its size is always 132 bytes and can contain 8 different conditions that must be satisfied so that the game will recognize the puzzle as solved. The first two bytes contains the number of such conditions actually set, in a 16-bit little endian format. This is followed by 8 entries, 16 bytes each, containing the required information for solution checking by the game. The format of each entry is:

INT16LE part_index;
UINT16LE part_state_1;
UINT16LE part_state_2;
UINT16LE part_count;
INT16LE position_rect_x;
INT16LE position_rect_y;
INT16LE position_rect_width;
INT16LE position_rect_height;

* '''part_index''': The index of the part in the puzzle file involved in the solution. -1 (0xFF 0xFF) for unused entries.
* '''part_state_1''': An ID for a "physical state" of a part (for example a balloon was popped or a candle was lit). In many puzzles, one specific part must be in a specified "physical state" in order to complete the level. This is the same ID for a "part state" as the ''first_frame_id'' member found in the C section of the part's ANM file.
* '''part_state_2''': Another ID for a "physical state", the exact meaning is unclear.
* '''part_count''': The value of the "Part count" option set in the "program solution" dialog of the game.
* '''position_rect_x''', '''position_rect_y''': The top left corner of the "position rectangle". If such a solution specified puzzle part must be located within this rectangle in order to solve the puzzle.
* '''position_rect_width''', '''position_rect_height''': Width and height of the "position rectangle", see above.

For the last four members ("position rectangle"), there are "fixed" combinations of values with special meaning:

* <code>-1, -1, -1, -1</code>: "Off screen", the part must leave the area visible on the game screen.
* <code>-500, -2000, 1640, 2000</code>: "Off top", the part must leave the visible area at the top.
* <code>-500, 400, 1640, 3000</code>: "Off bottom"
* <code>0, 0, 0, 0</code>: No such solution programmed, either this is "part state" solution or an unused entry (<code>part_index = -1</code>).

The last 2 bytes of the section contain the value of the "Delay" option set in the "program solution" dialog of the game, in 16-bit little endian format.

'''Note on puzzle solution information in TIM and TEMIM''': TIM / TEMIM puzzles do not contain such data. This can also be demonstrated by extracting e.g. <tt>L1.LEV</tt> from the archive file and rename the file to change the number. After starting the game, the level with the same number as the renamed file will be replaced with level 1. When playing the modified level, the game will not be able to check whether the puzzle is solved. Depending on its number, the level can become unwinnable or winnable by just clicking on the start machine button. Sometimes the game freezes.

== Tools ==
{{BeginFileFormatTools|Type=map}}
{{FileFormatTool
| Name = [https://www.vogons.org/viewtopic.php?p=1089143#p1089143 The Incredible Machine level/image resource viewer]
| Platform = Windows, Linux
| canView = Yes

| canCreate = No
| canModify = No
| editHidden = N/A
| editMetadata = N/A
| notes =
}}
{{EndFileFormatTools}}

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

The Incredible Machine Level Format

2022-07-23T07:37:36Z

Knt47: /* Puzzle part data */ image format link

{{Map Infobox
| Type =
| Layers =
| Tile size = Not tile based, the game uses a 16x16 grid for walls and a few other puzzle parts
| Viewport =
'''576×368''' (Levels in [[The Incredible Machine]] (TIM) and [[The Even More Incredible Machine]] (TEMIM))
'''640×400''' (.GKC files in TIM and TEMIM)
'''560×377''' (Levels in [[The Incredible Machine 2]] and 3)
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|The Incredible Machine 3}}
}}

This page discusses the '''level format''' of [[The Incredible Machine]], from the first DOS version (abbreviated as TIM 1) to [[The Incredible Machine 3|TIM 3]] (which is a 32-bit Windows game). Even if the format of some sections of the file vary significantly between the versions, the way how the parts are stored is highly similar. Level files have the extension <tt>.LEV</tt>.

The machines/puzzles saved from the "freeform machine" mode or the built-in level editor are also discussed here. The format of files saved from built-in editor may be identical to or slightly different from the levels, depending on the game version. Such files are saved by the game with extension <tt>.TIM</tt>.

The animated '''"title screen"''' (<tt>TITLE.GKC</tt>) and '''"credits screen"''' (<tt>CREDITS.GKC</tt>) files (inside the archive file) in TIM 1 and [[The Even More Incredible Machine]] (TEMIM) use a variant of the level file format, even if these are not playable levels.

== Magic number ==

TIM-TIM 3 level and GKC files always start with a 4-byte magic number. The following table summarizes the magic numbers found in various versions of the game.

{| class="wikitable"
! Magic number (hex) !! Usage in game versions
|-
| <code>ED AC 00 01</code>
|
* Puzzles in TIM demo version.
|-
| <code>ED AC 02 01</code>
|
* Puzzles in TIM.
* Saved freeform machines in TIM.
* GKC files in TIM.
* <tt>CREDITS.GKC</tt> in TEMIM.
|-
| <code>EE AC 05 01</code>
|
* New puzzles in TEMIM not found in TIM.
* Saved freeform machines in TEMIM.
* <tt>TITLE.GKC</tt> in TEMIM.
|-
| <code>EF AC 11 01</code>
<code>EF AC 12 01</code>
|
* A small number of puzzles in TIM 2 and 3.
|-
| <code>EF AC 13 01</code>
|
* The large majority of puzzles in TIM 2 and 3.
* Puzzles saved from the built-in editor of TIM 2.
|-
| <code>EF AC 14 01</code>
|
* A small number of puzzles in TIM 3.
* Puzzles saved from the built-in editor of TIM 3.
|}

== Structure of puzzle and GKC files ==

The level/puzzle/saved machine files consist of multiple sections. An overview of the file structure is provided below, separately for TIM / TEMIM and TIM 2 / TIM 3.

=== TIM and TEMIM ===

* Magic number, see above
* Puzzle title, null-terminated string. missing in .GKC files and "freeform machines" saved by the player.
* Goal description, null-terminated string. Absent from .GKC files and "saved freeform machines" with magic number of <code>ED AC 02 01</code>. Present in TEMIM "saved freeform machines" (magic number <code>EE AC 05 01</code>). An empty string in .GKC files with magic number <code>EE AC 05 01</code>.
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move ("fixed", e.g. walls) and are not found initially to the parts bin.
* List of part entry structures for parts that can move (e.g. balls), not in the parts bin.
* An additional 16-bit, little endian integer value in puzzles with magic number of <code>EE AC 05 01</code>. The meaning of this value is unclear. 0 in puzzles from the game archive file. In saved freeform machines, 1 if there are parts placed into the parts bin, 0 otherwise.
* List of part entry structures for parts initially placed into the parts bin.

=== TIM 2 and 3 ===

* Magic number, see above
* Two additional "header" bytes in files with magic number <code>EF AC 13 01</code> or <code>EF AC 14 01</code>. First byte is always 0, second is the background color from the 16-color palette.
* Puzzle title, null-terminated string
* Goal description, null-terminated string
* Hints, see below
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move
* List of part entry structures for parts that can move
* Solution information, see below

== Hints ==

Hints are supported only in TIM 2 and 3 puzzles. The first two bytes of the hint data contain the number of the hints in 16-bit little endian format. This is followed by 8 hint entries, some of them may be unused. A size of an unused entry is 7 bytes. One entry consists of three 16-bit integers and a null-terminated string containing the hint text. The three integer members are (all have a 16-bit little endian format):

* '''position_x''': The X position of the hand icon for the hint.
* '''position_y''': The Y position.
* '''hint_icon_flip''': The hand icon of a hint can be flipped and can have four different orientations. Possible values are 0-3.

In TIM 2, there are 3 (?) puzzles with magic number <code>EF AC 11 01</code>. Neither of these files contain hints. However, the size of the empty hints section is 42 bytes in them instead of the expected 58.

== Puzzle information data structure ==

=== In TIM and TEMIM ===

In TIM and TEMIM, there are two different puzzle header information data structures, one is used by the puzzles, and the another is found in saved "freeform" machines and the GKC files.

The information structure format in TIM / TEMIM puzzles:

[[UINT16LE]] bonus_1;
UINT16LE bonus_2;
[[INT16LE]] pressure;
INT16LE gravity;
INT16LE unknown_8;
INT16LE unknown_10;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

The information structure format in saved "freeform" machines and GKC files:

INT16LE pressure;
INT16LE gravity;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

* '''bonus_1''': The value of "Bonus 1" immediately after the puzzle is loaded (its value is constantly decreasing while the player is solving the puzzle).
* '''bonus_2''': The value of "Bonus 2" for the puzzle.
* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''unknown_8''', ''unknown_10'': The value of these two members is always -8. Perhaps the top left corner of the screen in the coordinate system used for puzzle parts, which is also (-8, -8).
* '''music''': ID of music track played. Valid values are 1001-1016 for TIM and 1001-1021 for TEMIM.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move (e.g. walls), not in the "parts bin".
* '''num_parts_moving''': Number of parts in the puzzles that move (e.g. balls), not in the "parts bin".
* '''num_parts_in_partsbin''': The number of parts that are placed into the parts bin. (The player needs to position them in order to solve the puzzle.)

=== In TIM 2 and 3 ===

The information structure format in TIM 2 and 3:

INT16LE pressure;
INT16LE gravity;
UINT16LE unknown_4;
UINT16LE unknown_6;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE unknown_14;

* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''music''': ID of music track played. Valid values are 1000-1023.
* '''unknown_4''', '''unknown_6''': Meaning is unknown, always 0.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move, regardless of whether they are placed initially into the parts bin or not.
* '''num_parts_moving''': Number of parts in the puzzles that can move.
* '''unknown_14''': Value is always 0. Likely this member corresponds to num_parts_in_partsbin in TIM / TEMIM puzzle header. Unlike TIM / TEMIM, parts placed into the parts bin are not a separate section in TIM 2 / 3, therefore, its value is always zero.

== Puzzle part data ==

As already discussed in the With the exception of TIM demo version (see below), the size of a part entry for the majority of puzzle parts is 48 bytes. However, there are exceptions, which are discussed in separate sub-sections. The format of the "default" part entry:

UINT16LE part_type_num;
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
[[BYTE]] belt_connect_pos_x;
BYTE belt_connect_pos_y;
UINT16LE belt_line_distance;
UINT16LE unknown_32;
BYTE rope_1_connect_pos_x;
BYTE rope_1_connect_pos_y;
UINT16LE unknown_36;
BYTE rope_2_connect_pos_x;
BYTE rope_2_connect_pos_y;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''part_type_num''': A number associated with the type of the part (e.g. 0 - bowling ball). Required for identifying parts with an entry size different from the default. See [[The Incredible Machine Level Format/Part Numbers]]
* '''flags_1''': A combination of flag bits.
** '''TIM''' / '''TEMIM''' uses the following flag bits:
*** <code>0x20</code>: Unknown meaning, used for a few "moving" parts (bucket, candle)
*** <code>0x40</code>: Set if the part is a wall.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x800</code>: Part is placed initially into the parts bin (see num_parts_in_partsbin in part information data structure)
*** <code>0x1000</code>: "Moving" part, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x2000</code>: Part cannot move, in fixed position, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x4000</code>: Part cannot move, in fixed position (see ''num_parts_fixed'')
*** <code>0x8000</code>: Set when 0x800 is not set ({{TODO|further testing needed}})
** In '''TIM 2 / 3''', the bits have a known meaning:
*** <code>0x40</code>: Meaning unclear, used for "moving" parts only, but not always set, even for a single type of part.***
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x1000</code>: "Moving" part, affected by gravity.
*** <code>0x2000</code>, 0x4000: Used in combination for parts that do not move and are not affected by gravity.
* '''flags_2''': Another word containing flag bits. The meaning of most flags is the same in all game versions.
** <code>0x1</code>: A belt can be connected to the part.
** <code>0x2</code>: A belt is connected to the part.
** <code>0x4</code>: A rope can be connected to the part.
** <code>0x8</code>: A second rope can be connected to the part (teeter-totter)
** <code>0x10</code>: The part sprite is drawn horizontally flipped.
** <code>0x20</code>: The part sprite is drawn vertically flipped. Note on flip flags: Flipping a part in the game does not necessarily mean that one of the flip flags will be changed. For several parts, especially in TIM 2 / 3, flipping will affect the value of the ''appearance'' member.
** <code>0x40</code>: Probably unused
** <code>0x80</code>: Part can be stretched in at least one direction: inclines, conveyor belt, walls.
** <code>0x100</code>: Parts that can be stretched both horizontally and vertically, the walls.
* '''flags_3''': Some flags are only present in TIM 2 / 3. This member of the part data structure is missing in the demo version of TIM.
** <code>0x1</code>: The part can be plugged into an electric outlet.
** <code>0x2</code>: The part is an electric outlet.
** <code>0x4</code>: The part can burn (e.g. candle) or has a fuse that can be lit (e.g. dynamite, cannon). Usually in combination with flag 0x8.
** <code>0x8</code>: Meaning of this flag is unclear. Used for several part types, but changing it has no apparent consequence (?)
** Flags present only in '''TIM 2 / 3''':
*** <code>0x40</code>: Part is "locked", i.e not placed into the part bin.
*** <code>0x80</code>: Sizable scenery part (?)
*** <code>0x100</code>: {{TODO|unknown meaning}}
*** <code>0x400</code>: A "program" icon is shown for the part (?)
*** <code>0x1000</code>: Scenery part
*** <code>0x2000</code>: Wall part (?)
*** <code>0x8000</code>: A "Puzzle solution" icon is shown for the part (?)
* '''appearance''': An identifier for the sprite that is shown for a part before the machine is started. (Once the machine is started, the state of the part can change and so can the sprite shown.) The meaning is different between TIM and TIM 2. In TIM, the sprite of some parts consists of only one image, in this case, this is often the number of the sub-image in the [[The Incredible Machine Image Format|image resource file]]. ({{TODO|For other parts, this is probably an internal identifier for the sprite (?)}}). In TIM 2 and 3, the meaning of the appearance is an index in the A section of the [[The Incredible Machine 2-3 ANM File Format|.ANM file]] for the part, or if this is absent, an index in the B section. "Programming" a part in TIM 2 and 3 often results in the change of this field.
* '''unknown_10''': Probably unused, usually 0.
* '''width_1''', '''height_1''': The width and height of the selectable area of the part ({{TODO|more reverse engineering work needed}})
* '''width_2''', '''height_2''': At least in TIM 2, witdh_2 is used for calculating the position of part sprite when the part is flipped because of the horizontal flip bit is set in flags_2.
* '''pos_x''', '''pos_y''': The position of the part, usually the top left corner of the bounding rectangle.
* '''behavior''': In TIM 2 and 3, a programmed behavior of the part. (However, for many parts, "programming" modifies the ''appearance'' member.) For example the number of shots of the phazer gun or character shown by the message computer. Meaning is different for rope parts, see below. Unused in TIM and TEMIM (except for ropes).
* '''unknown_26''': Probably unused, usually 0. Note that belt parts have a value of 1 in this position.
* '''belt_connect_pos_x''', '''belt_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Always positive or 0, because ''pos_x'' and ''pos_y'' are the coordinates of the top left corner where the sprite starts. Note that the formulas required for calculating the exact position of the belt are slightly different between TIM and TIM 2. Parts for which connection of a belt is allowed have a distinct circular area in their sprite, corresponding to the location where the belt is connected. In TIM / TEMIM, ''belt_connect_pos_x'' and ''belt_connect_pos_y'' is approximately the top left corner of its bounding rectangle, while in TIM 2 /3 it is close to the center of the circle.
* '''unknown_36''': Probably unused, usually 0.
* '''belt_line_distance''': The belts in the game appear as two, usually not perfectly parallel black (TIM / TEMIM) or gray (TIM 2 / 3) lines. This parameter determines the distance between the two segments, More precisely, it is either approximately the diameter of the circular area mentioned at ''belt_connect_pos_x'' and ''belt_connect_pos_y'' (TIM / TEMIM) or its radius (TIM 2 / 3).
* '''unknown_32''': Probably unused, usually 0.
* '''rope_1_connect_pos_x''', '''rope_1_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Similarly to belt_connect_pos_x/y, always positive or 0.
* '''rope_2_connect_pos_x''', '''rope_2_connect_pos_y''': The same as ''rope_1_connect_pos_x'', ''rope_1_connect_pos_y'', bit for another connected rope part.
* '''connected_1''', '''connected_2''': The index of one or two parts in the puzzle that are connected to this part with a rope. If the rope runs through pulleys, this is the part index of the first pulley. If no rope is connected or this is not possible for the part, the value of both structure members are -1. (Of course, if one rope is connected, the value of one structure member (usually connected_rope_1) is the index of the rope part and the other is -1) )In TIM 2 and 3, the "remote bomb" part actually corresponds to two entries in the puzzle file. The connected_rope_2 field contains the index of the another "element" of the bomb, in both entries.
* '''outlet_plugged_1''', '''outlet_plugged_2''': These structure members are only meaningful for electric outlet parts. Electric outlets always have 2 "sockets" for parts requiring electricity. It contains the index/indices of the part/parts plugged into the electric outlet, or -1 if the "socket" is free. If the part does not support this, both values are -1.

=== Belts ===

Belt parts (part 8) (except in the demo version of TIM, see below) use a 52-byte entry, with the following format:

UINT16LE part_type_num; /* 8 for belts */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
INT16LE belt_connected_part_1;
INT16LE belt_connected_part_2;
UINT16LE unknown_36;
UINT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0</code>, <code>flags_3 = 0</code>
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0</code>, <code>flags_3 = 0x40</code> (or <code>0</code> if in parts bin)
* '''appearance''': Always 0, belts have no true sprite (represented by two lines).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for belts, always 0.
* '''pos_x''', '''pos_y''' In TIM / TEMIM, either 0 or -1. In TIM 2, -1 or -100 (0xff9c). Meaning of these numbers is unclear, and the usage of the two different values do not correlate with the flags.
* '''behavior''': Not used, always 0.
* '''unknown_26''': Always 1, perhaps indicates that the part is a belt.
* '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''belt_connected_part_1''', '''belt_connected_part_2''': Index of the two parts in the puzzle connected by this belt. In TIM and TEMIM, both are -1 if the belt is placed into the parts bin.
* '''unknown_36''', '''unknown_38''', '''unknown_40''', '''unknown_42''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Ropes ===

Rope parts (part 10) (except in the demo version of TIM, see below) use a 54-byte entry. TIM 2 and 3 also have a "steel cable" part (part 76) which also behaves as a rope and the size of the part entry is also identical. The rope part entry has the following format:

UINT16LE part_type_num; /* 10 for rope, 76 for steel cable */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE rope_segment_length;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
UINT16LE unknown_36;
INT16LE rope_connected_part_1;
INT16LE rope_connected_part_2;
BYTE part_1_connect_field_usage;
BYTE part_2_connect_field_usage;
UINT16LE unknown_44;
UINT16LE unknown_46;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''': Same flags used as in the belt part structure.
* '''appearance''': Always 0, ropes have no true sprite (represented by one or more line segments).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for ropes, always 0.
* '''pos_x''', '''pos_y''': Similarly to belts, possible values are 0 and -1 in TIM / TEMIM; and -1 and -100 in TIM 2 / 3.
* '''rope_segment_length''': The length of the rope (Euclidean distance between the two ends) if the rope does not run through pulleys. Otherwise, the length of the rope segment between the part at one end (rope_connected_part_1 (?)) and the first pulley ({{TODO|additional testing needed}}).
* '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for pulleys.
* '''unknown_36''': Not used, always 0.
* '''rope_connected_part_1''', '''rope_connected_part_2''': Index of the two parts in the puzzle connected by this rope (never the pulleys). In TIM and TEMIM, both are -1 if the rope is placed into the parts bin.
* '''part_1_connect_field_usage''', '''part_2_connect_field_usage''': Whether ''connected_1'' or ''connected_2'' is used in the two connected parts for this rope. 0 if connected_1, 1 if connected_2. ({{TODO|additional testing needed}})
* '''unknown_44''', '''unknown_46''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Pulleys ===

The format of the 56-byte puzzle part entry for the pulley (part 7):

UINT16LE part_type_num; /* 7 for pulley */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
BYTE pulley_rope_1_connect_pos_x;
BYTE pulley_rope_1_connect_pos_y;
INT16LE unknown_36;
INT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
BYTE pulley_rope_2_connect_pos_x;
BYTE pulley_rope_2_connect_pos_y;
INT16LE pulley_connected_1;
INT16LE pulley_connected_2;
INT16LE unknown_50;
INT16LE unknown_52;
INT16LE rope_index;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0x4</code>, <code>flags_3 = 0x8</code> (<code>0x0</code> {{TODO|in some cases}})
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0x4</code>, <code>flags_3 = 0x48</code> (or <code>0x8</code> if in parts bin)
* '''appearance''': Pulleys can have four different sprites depending on the orientation. Possible values are 0-3.
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': The size of the pulley sprite. In TIM 2 / 3, also depends on the orientation.
* '''pos_x''', '''pos_y''': The position of the pulley, top left coordinates of the bounding rectangle.
* '''behavior''', '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for ropes.
* '''pulley_rope_1_connect_pos_x''', '''pulley_rope_1_connect_pos_y''': The coordinates of the point where one rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''. Depends on the orientation of the pulley, like ''appearance''.
* '''unknown_36''', '''unknown_38''': Not used, always -1.
* '''unknown_40'', ''unknown_42''': Not used, always 0.
* '''pulley_rope_2_connect_pos_x''', '''pulley_rope_2_connect_pos_y''': The coordinates of the point where the other rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''.
* '''pulley_connected_1''', '''pulley_connected_2''': Either the index of part at one of the two ends of the rope, or the index of next or previous pulley the rope is running through.
* '''unknown_50''', '''unknown_52''': Not used, always -1.
* '''rope_index''': In TIM 2 / 3, the index of the rope part. Not used (-1) in TIM and TEMIM.

=== Programmable ball (TIM 2 / 3) ===

The programmable ball part is present in TIM 2 and 3, and its part type number is 87. The size of the entry is 60 bytes in total. The first 48 bytes is the same as the default part data structure, which is followed by another, 12-byte structure specific to this part. The format of the programmable ball data is:

UINT16LE density;
UINT16LE elasticity;
UINT16LE friction;
INT16LE gravity_buoyancy;
UINT16LE mass;
UINT16LE appearance_2;

* '''density''': The density of the ball, affects the buoyant force acting on the ball.
* '''elasticity''': The elasticity of the ball.
* '''friction''': The friction.
* '''gravity_buoyancy''': A calculated parameter, using the density and the mass of the ball, as well as the gravity and the pressure set for the puzzle. If its value is negative, the ball will rise due to the buoyant force rather than fall.
* '''mass''': The mass of the ball.
* '''appearance_2''': Has the same value as the ''appearance'' field. The ball can have 7 different colors/patterns.

The game has a dialog for setting the four physical properties (mass, elasticity, density, friction, in this order). However, the number stored in the data structure is not the same as the numbers shown on the program dialog. For example, if following settings are used for the ball: <code>mass = 8</code>, <code>elasticity = 3</code>, <code>density = 7</code>, <code>friction = 3</code>; and the default values are used for gravity/pressure, the puzzle file will contain the following values: <code>density = 3000</code>, <code>elasticity = 128</code>, <code>friction = 16</code>, <code>gravity_buoyancy = 269</code>, <code>mass = 201</code>. (Note: There is an inconsistency in the game here, the programmable ball part uses <code>density = 2832</code> and <code>mass = 200</code> by default, which does not correspond exactly to any value that can be set in the dialog.)

=== TIM demo version ===

In the demo version of the (original) TIM (available at several DOS shareware game websites), the ''flags_3'', ''outlet_plugged_1'' and ''outlet_plugged_2'' fields are missing.
Instead, the 42-byte part data (46 for belts, 48 for ropes, 50 for pulleys) is followed by an another, variable length data structure of unknown significance consisting of 16-bit little endian integers. It is always at least 2 bytes long, and the first two bytes contain the number of additional 16-bit words after this size word. The reverse engineering of this structure is complicated by the fact that it is only present in a demo version containing only 8 puzzles.

== Puzzle solution information ==

Puzzle solution information is only present in TIM 2 and TIM 3 puzzles. Its size is always 132 bytes and can contain 8 different conditions that must be satisfied so that the game will recognize the puzzle as solved. The first two bytes contains the number of such conditions actually set, in a 16-bit little endian format. This is followed by 8 entries, 16 bytes each, containing the required information for solution checking by the game. The format of each entry is:

INT16LE part_index;
UINT16LE part_state_1;
UINT16LE part_state_2;
UINT16LE part_count;
INT16LE position_rect_x;
INT16LE position_rect_y;
INT16LE position_rect_width;
INT16LE position_rect_height;

* '''part_index''': The index of the part in the puzzle file involved in the solution. -1 (0xFF 0xFF) for unused entries.
* '''part_state_1''': An ID for a "physical state" of a part (for example a balloon was popped or a candle was lit). In many puzzles, one specific part must be in a specified "physical state" in order to complete the level. This is the same ID for a "part state" as the ''first_frame_id'' member found in the C section of the part's ANM file.
* '''part_state_2''': Another ID for a "physical state", the exact meaning is unclear.
* '''part_count''': The value of the "Part count" option set in the "program solution" dialog of the game.
* '''position_rect_x''', '''position_rect_y''': The top left corner of the "position rectangle". If such a solution specified puzzle part must be located within this rectangle in order to solve the puzzle.
* '''position_rect_width''', '''position_rect_height''': Width and height of the "position rectangle", see above.

For the last four members ("position rectangle"), there are "fixed" combinations of values with special meaning:

* <code>-1, -1, -1, -1</code>: "Off screen", the part must leave the area visible on the game screen.
* <code>-500, -2000, 1640, 2000</code>: "Off top", the part must leave the visible area at the top.
* <code>-500, 400, 1640, 3000</code>: "Off bottom"
* <code>0, 0, 0, 0</code>: No such solution programmed, either this is "part state" solution or an unused entry (<code>part_index = -1</code>).

The last 2 bytes of the section contain the value of the "Delay" option set in the "program solution" dialog of the game, in 16-bit little endian format.

'''Note on puzzle solution information in TIM and TEMIM''': TIM / TEMIM puzzles do not contain such data. This can also be demonstrated by extracting e.g. <tt>L1.LEV</tt> from the archive file and rename the file to change the number. After starting the game, the level with the same number as the renamed file will be replaced with level 1. When playing the modified level, the game will not be able to check whether the puzzle is solved. Depending on its number, the level can become unwinnable or winnable by just clicking on the start machine button. Sometimes the game freezes.

== Tools ==
{{BeginFileFormatTools|Type=map}}
{{FileFormatTool
| Name = [https://www.vogons.org/viewtopic.php?p=1089143#p1089143 The Incredible Machine level/image resource viewer]
| Platform = Windows, Linux
| canView = Yes

| canCreate = No
| canModify = No
| editHidden = N/A
| editMetadata = N/A
| notes =
}}
{{EndFileFormatTools}}

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

The Incredible Machine Level Format

2022-07-23T06:36:07Z

Knt47: /* Tools */ removed todo

{{Map Infobox
| Type =
| Layers =
| Tile size = Not tile based, the game uses a 16x16 grid for walls and a few other puzzle parts
| Viewport =
'''576×368''' (Levels in [[The Incredible Machine]] (TIM) and [[The Even More Incredible Machine]] (TEMIM))
'''640×400''' (.GKC files in TIM and TEMIM)
'''560×377''' (Levels in [[The Incredible Machine 2]] and 3)
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|The Incredible Machine 3}}
}}

This page discusses the '''level format''' of [[The Incredible Machine]], from the first DOS version (abbreviated as TIM 1) to [[The Incredible Machine 3|TIM 3]] (which is a 32-bit Windows game). Even if the format of some sections of the file vary significantly between the versions, the way how the parts are stored is highly similar. Level files have the extension <tt>.LEV</tt>.

The machines/puzzles saved from the "freeform machine" mode or the built-in level editor are also discussed here. The format of files saved from built-in editor may be identical to or slightly different from the levels, depending on the game version. Such files are saved by the game with extension <tt>.TIM</tt>.

The animated '''"title screen"''' (<tt>TITLE.GKC</tt>) and '''"credits screen"''' (<tt>CREDITS.GKC</tt>) files (inside the archive file) in TIM 1 and [[The Even More Incredible Machine]] (TEMIM) use a variant of the level file format, even if these are not playable levels.

== Magic number ==

TIM-TIM 3 level and GKC files always start with a 4-byte magic number. The following table summarizes the magic numbers found in various versions of the game.

{| class="wikitable"
! Magic number (hex) !! Usage in game versions
|-
| <code>ED AC 00 01</code>
|
* Puzzles in TIM demo version.
|-
| <code>ED AC 02 01</code>
|
* Puzzles in TIM.
* Saved freeform machines in TIM.
* GKC files in TIM.
* <tt>CREDITS.GKC</tt> in TEMIM.
|-
| <code>EE AC 05 01</code>
|
* New puzzles in TEMIM not found in TIM.
* Saved freeform machines in TEMIM.
* <tt>TITLE.GKC</tt> in TEMIM.
|-
| <code>EF AC 11 01</code>
<code>EF AC 12 01</code>
|
* A small number of puzzles in TIM 2 and 3.
|-
| <code>EF AC 13 01</code>
|
* The large majority of puzzles in TIM 2 and 3.
* Puzzles saved from the built-in editor of TIM 2.
|-
| <code>EF AC 14 01</code>
|
* A small number of puzzles in TIM 3.
* Puzzles saved from the built-in editor of TIM 3.
|}

== Structure of puzzle and GKC files ==

The level/puzzle/saved machine files consist of multiple sections. An overview of the file structure is provided below, separately for TIM / TEMIM and TIM 2 / TIM 3.

=== TIM and TEMIM ===

* Magic number, see above
* Puzzle title, null-terminated string. missing in .GKC files and "freeform machines" saved by the player.
* Goal description, null-terminated string. Absent from .GKC files and "saved freeform machines" with magic number of <code>ED AC 02 01</code>. Present in TEMIM "saved freeform machines" (magic number <code>EE AC 05 01</code>). An empty string in .GKC files with magic number <code>EE AC 05 01</code>.
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move ("fixed", e.g. walls) and are not found initially to the parts bin.
* List of part entry structures for parts that can move (e.g. balls), not in the parts bin.
* An additional 16-bit, little endian integer value in puzzles with magic number of <code>EE AC 05 01</code>. The meaning of this value is unclear. 0 in puzzles from the game archive file. In saved freeform machines, 1 if there are parts placed into the parts bin, 0 otherwise.
* List of part entry structures for parts initially placed into the parts bin.

=== TIM 2 and 3 ===

* Magic number, see above
* Two additional "header" bytes in files with magic number <code>EF AC 13 01</code> or <code>EF AC 14 01</code>. First byte is always 0, second is the background color from the 16-color palette.
* Puzzle title, null-terminated string
* Goal description, null-terminated string
* Hints, see below
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move
* List of part entry structures for parts that can move
* Solution information, see below

== Hints ==

Hints are supported only in TIM 2 and 3 puzzles. The first two bytes of the hint data contain the number of the hints in 16-bit little endian format. This is followed by 8 hint entries, some of them may be unused. A size of an unused entry is 7 bytes. One entry consists of three 16-bit integers and a null-terminated string containing the hint text. The three integer members are (all have a 16-bit little endian format):

* '''position_x''': The X position of the hand icon for the hint.
* '''position_y''': The Y position.
* '''hint_icon_flip''': The hand icon of a hint can be flipped and can have four different orientations. Possible values are 0-3.

In TIM 2, there are 3 (?) puzzles with magic number <code>EF AC 11 01</code>. Neither of these files contain hints. However, the size of the empty hints section is 42 bytes in them instead of the expected 58.

== Puzzle information data structure ==

=== In TIM and TEMIM ===

In TIM and TEMIM, there are two different puzzle header information data structures, one is used by the puzzles, and the another is found in saved "freeform" machines and the GKC files.

The information structure format in TIM / TEMIM puzzles:

[[UINT16LE]] bonus_1;
UINT16LE bonus_2;
[[INT16LE]] pressure;
INT16LE gravity;
INT16LE unknown_8;
INT16LE unknown_10;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

The information structure format in saved "freeform" machines and GKC files:

INT16LE pressure;
INT16LE gravity;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

* '''bonus_1''': The value of "Bonus 1" immediately after the puzzle is loaded (its value is constantly decreasing while the player is solving the puzzle).
* '''bonus_2''': The value of "Bonus 2" for the puzzle.
* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''unknown_8''', ''unknown_10'': The value of these two members is always -8. Perhaps the top left corner of the screen in the coordinate system used for puzzle parts, which is also (-8, -8).
* '''music''': ID of music track played. Valid values are 1001-1016 for TIM and 1001-1021 for TEMIM.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move (e.g. walls), not in the "parts bin".
* '''num_parts_moving''': Number of parts in the puzzles that move (e.g. balls), not in the "parts bin".
* '''num_parts_in_partsbin''': The number of parts that are placed into the parts bin. (The player needs to position them in order to solve the puzzle.)

=== In TIM 2 and 3 ===

The information structure format in TIM 2 and 3:

INT16LE pressure;
INT16LE gravity;
UINT16LE unknown_4;
UINT16LE unknown_6;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE unknown_14;

* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''music''': ID of music track played. Valid values are 1000-1023.
* '''unknown_4''', '''unknown_6''': Meaning is unknown, always 0.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move, regardless of whether they are placed initially into the parts bin or not.
* '''num_parts_moving''': Number of parts in the puzzles that can move.
* '''unknown_14''': Value is always 0. Likely this member corresponds to num_parts_in_partsbin in TIM / TEMIM puzzle header. Unlike TIM / TEMIM, parts placed into the parts bin are not a separate section in TIM 2 / 3, therefore, its value is always zero.

== Puzzle part data ==

As already discussed in the With the exception of TIM demo version (see below), the size of a part entry for the majority of puzzle parts is 48 bytes. However, there are exceptions, which are discussed in separate sub-sections. The format of the "default" part entry:

UINT16LE part_type_num;
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
[[BYTE]] belt_connect_pos_x;
BYTE belt_connect_pos_y;
UINT16LE belt_line_distance;
UINT16LE unknown_32;
BYTE rope_1_connect_pos_x;
BYTE rope_1_connect_pos_y;
UINT16LE unknown_36;
BYTE rope_2_connect_pos_x;
BYTE rope_2_connect_pos_y;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''part_type_num''': A number associated with the type of the part (e.g. 0 - bowling ball). Required for identifying parts with an entry size different from the default. See [[The Incredible Machine Level Format/Part Numbers]]
* '''flags_1''': A combination of flag bits.
** '''TIM''' / '''TEMIM''' uses the following flag bits:
*** <code>0x20</code>: Unknown meaning, used for a few "moving" parts (bucket, candle)
*** <code>0x40</code>: Set if the part is a wall.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x800</code>: Part is placed initially into the parts bin (see num_parts_in_partsbin in part information data structure)
*** <code>0x1000</code>: "Moving" part, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x2000</code>: Part cannot move, in fixed position, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x4000</code>: Part cannot move, in fixed position (see ''num_parts_fixed'')
*** <code>0x8000</code>: Set when 0x800 is not set ({{TODO|further testing needed}})
** In '''TIM 2 / 3''', the bits have a known meaning:
*** <code>0x40</code>: Meaning unclear, used for "moving" parts only, but not always set, even for a single type of part.***
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x1000</code>: "Moving" part, affected by gravity.
*** <code>0x2000</code>, 0x4000: Used in combination for parts that do not move and are not affected by gravity.
* '''flags_2''': Another word containing flag bits. The meaning of most flags is the same in all game versions.
** <code>0x1</code>: A belt can be connected to the part.
** <code>0x2</code>: A belt is connected to the part.
** <code>0x4</code>: A rope can be connected to the part.
** <code>0x8</code>: A second rope can be connected to the part (teeter-totter)
** <code>0x10</code>: The part sprite is drawn horizontally flipped.
** <code>0x20</code>: The part sprite is drawn vertically flipped. Note on flip flags: Flipping a part in the game does not necessarily mean that one of the flip flags will be changed. For several parts, especially in TIM 2 / 3, flipping will affect the value of the ''appearance'' member.
** <code>0x40</code>: Probably unused
** <code>0x80</code>: Part can be stretched in at least one direction: inclines, conveyor belt, walls.
** <code>0x100</code>: Parts that can be stretched both horizontally and vertically, the walls.
* '''flags_3''': Some flags are only present in TIM 2 / 3. This member of the part data structure is missing in the demo version of TIM.
** <code>0x1</code>: The part can be plugged into an electric outlet.
** <code>0x2</code>: The part is an electric outlet.
** <code>0x4</code>: The part can burn (e.g. candle) or has a fuse that can be lit (e.g. dynamite, cannon). Usually in combination with flag 0x8.
** <code>0x8</code>: Meaning of this flag is unclear. Used for several part types, but changing it has no apparent consequence (?)
** Flags present only in '''TIM 2 / 3''':
*** <code>0x40</code>: Part is "locked", i.e not placed into the part bin.
*** <code>0x80</code>: Sizable scenery part (?)
*** <code>0x100</code>: {{TODO|unknown meaning}}
*** <code>0x400</code>: A "program" icon is shown for the part (?)
*** <code>0x1000</code>: Scenery part
*** <code>0x2000</code>: Wall part (?)
*** <code>0x8000</code>: A "Puzzle solution" icon is shown for the part (?)
* '''appearance''': An identifier for the sprite that is shown for a part before the machine is started. (Once the machine is started, the state of the part can change and so can the sprite shown.) The meaning is different between TIM and TIM 2. In TIM, the sprite of some parts consists of only one image, in this case, this is often the number of the sub-image in the image resource file. ({{TODO|For other parts, this is probably an internal identifier for the sprite (?)}}). In TIM 2 and 3, the meaning of the appearance is an index in the A section of the [[The Incredible Machine 2-3 ANM File Format|.ANM file]] for the part, or if this is absent, an index in the B section. "Programming" a part in TIM 2 and 3 often results in the change of this field.
* '''unknown_10''': Probably unused, usually 0.
* '''width_1''', '''height_1''': The width and height of the selectable area of the part ({{TODO|more reverse engineering work needed}})
* '''width_2''', '''height_2''': At least in TIM 2, witdh_2 is used for calculating the position of part sprite when the part is flipped because of the horizontal flip bit is set in flags_2.
* '''pos_x''', '''pos_y''': The position of the part, usually the top left corner of the bounding rectangle.
* '''behavior''': In TIM 2 and 3, a programmed behavior of the part. (However, for many parts, "programming" modifies the ''appearance'' member.) For example the number of shots of the phazer gun or character shown by the message computer. Meaning is different for rope parts, see below. Unused in TIM and TEMIM (except for ropes).
* '''unknown_26''': Probably unused, usually 0. Note that belt parts have a value of 1 in this position.
* '''belt_connect_pos_x''', '''belt_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Always positive or 0, because ''pos_x'' and ''pos_y'' are the coordinates of the top left corner where the sprite starts. Note that the formulas required for calculating the exact position of the belt are slightly different between TIM and TIM 2. Parts for which connection of a belt is allowed have a distinct circular area in their sprite, corresponding to the location where the belt is connected. In TIM / TEMIM, ''belt_connect_pos_x'' and ''belt_connect_pos_y'' is approximately the top left corner of its bounding rectangle, while in TIM 2 /3 it is close to the center of the circle.
* '''unknown_36''': Probably unused, usually 0.
* '''belt_line_distance''': The belts in the game appear as two, usually not perfectly parallel black (TIM / TEMIM) or gray (TIM 2 / 3) lines. This parameter determines the distance between the two segments, More precisely, it is either approximately the diameter of the circular area mentioned at ''belt_connect_pos_x'' and ''belt_connect_pos_y'' (TIM / TEMIM) or its radius (TIM 2 / 3).
* '''unknown_32''': Probably unused, usually 0.
* '''rope_1_connect_pos_x''', '''rope_1_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Similarly to belt_connect_pos_x/y, always positive or 0.
* '''rope_2_connect_pos_x''', '''rope_2_connect_pos_y''': The same as ''rope_1_connect_pos_x'', ''rope_1_connect_pos_y'', bit for another connected rope part.
* '''connected_1''', '''connected_2''': The index of one or two parts in the puzzle that are connected to this part with a rope. If the rope runs through pulleys, this is the part index of the first pulley. If no rope is connected or this is not possible for the part, the value of both structure members are -1. (Of course, if one rope is connected, the value of one structure member (usually connected_rope_1) is the index of the rope part and the other is -1) )In TIM 2 and 3, the "remote bomb" part actually corresponds to two entries in the puzzle file. The connected_rope_2 field contains the index of the another "element" of the bomb, in both entries.
* '''outlet_plugged_1''', '''outlet_plugged_2''': These structure members are only meaningful for electric outlet parts. Electric outlets always have 2 "sockets" for parts requiring electricity. It contains the index/indices of the part/parts plugged into the electric outlet, or -1 if the "socket" is free. If the part does not support this, both values are -1.

=== Belts ===

Belt parts (part 8) (except in the demo version of TIM, see below) use a 52-byte entry, with the following format:

UINT16LE part_type_num; /* 8 for belts */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
INT16LE belt_connected_part_1;
INT16LE belt_connected_part_2;
UINT16LE unknown_36;
UINT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0</code>, <code>flags_3 = 0</code>
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0</code>, <code>flags_3 = 0x40</code> (or <code>0</code> if in parts bin)
* '''appearance''': Always 0, belts have no true sprite (represented by two lines).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for belts, always 0.
* '''pos_x''', '''pos_y''' In TIM / TEMIM, either 0 or -1. In TIM 2, -1 or -100 (0xff9c). Meaning of these numbers is unclear, and the usage of the two different values do not correlate with the flags.
* '''behavior''': Not used, always 0.
* '''unknown_26''': Always 1, perhaps indicates that the part is a belt.
* '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''belt_connected_part_1''', '''belt_connected_part_2''': Index of the two parts in the puzzle connected by this belt. In TIM and TEMIM, both are -1 if the belt is placed into the parts bin.
* '''unknown_36''', '''unknown_38''', '''unknown_40''', '''unknown_42''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Ropes ===

Rope parts (part 10) (except in the demo version of TIM, see below) use a 54-byte entry. TIM 2 and 3 also have a "steel cable" part (part 76) which also behaves as a rope and the size of the part entry is also identical. The rope part entry has the following format:

UINT16LE part_type_num; /* 10 for rope, 76 for steel cable */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE rope_segment_length;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
UINT16LE unknown_36;
INT16LE rope_connected_part_1;
INT16LE rope_connected_part_2;
BYTE part_1_connect_field_usage;
BYTE part_2_connect_field_usage;
UINT16LE unknown_44;
UINT16LE unknown_46;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''': Same flags used as in the belt part structure.
* '''appearance''': Always 0, ropes have no true sprite (represented by one or more line segments).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for ropes, always 0.
* '''pos_x''', '''pos_y''': Similarly to belts, possible values are 0 and -1 in TIM / TEMIM; and -1 and -100 in TIM 2 / 3.
* '''rope_segment_length''': The length of the rope (Euclidean distance between the two ends) if the rope does not run through pulleys. Otherwise, the length of the rope segment between the part at one end (rope_connected_part_1 (?)) and the first pulley ({{TODO|additional testing needed}}).
* '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for pulleys.
* '''unknown_36''': Not used, always 0.
* '''rope_connected_part_1''', '''rope_connected_part_2''': Index of the two parts in the puzzle connected by this rope (never the pulleys). In TIM and TEMIM, both are -1 if the rope is placed into the parts bin.
* '''part_1_connect_field_usage''', '''part_2_connect_field_usage''': Whether ''connected_1'' or ''connected_2'' is used in the two connected parts for this rope. 0 if connected_1, 1 if connected_2. ({{TODO|additional testing needed}})
* '''unknown_44''', '''unknown_46''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Pulleys ===

The format of the 56-byte puzzle part entry for the pulley (part 7):

UINT16LE part_type_num; /* 7 for pulley */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
BYTE pulley_rope_1_connect_pos_x;
BYTE pulley_rope_1_connect_pos_y;
INT16LE unknown_36;
INT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
BYTE pulley_rope_2_connect_pos_x;
BYTE pulley_rope_2_connect_pos_y;
INT16LE pulley_connected_1;
INT16LE pulley_connected_2;
INT16LE unknown_50;
INT16LE unknown_52;
INT16LE rope_index;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0x4</code>, <code>flags_3 = 0x8</code> (<code>0x0</code> {{TODO|in some cases}})
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0x4</code>, <code>flags_3 = 0x48</code> (or <code>0x8</code> if in parts bin)
* '''appearance''': Pulleys can have four different sprites depending on the orientation. Possible values are 0-3.
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': The size of the pulley sprite. In TIM 2 / 3, also depends on the orientation.
* '''pos_x''', '''pos_y''': The position of the pulley, top left coordinates of the bounding rectangle.
* '''behavior''', '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for ropes.
* '''pulley_rope_1_connect_pos_x''', '''pulley_rope_1_connect_pos_y''': The coordinates of the point where one rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''. Depends on the orientation of the pulley, like ''appearance''.
* '''unknown_36''', '''unknown_38''': Not used, always -1.
* '''unknown_40'', ''unknown_42''': Not used, always 0.
* '''pulley_rope_2_connect_pos_x''', '''pulley_rope_2_connect_pos_y''': The coordinates of the point where the other rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''.
* '''pulley_connected_1''', '''pulley_connected_2''': Either the index of part at one of the two ends of the rope, or the index of next or previous pulley the rope is running through.
* '''unknown_50''', '''unknown_52''': Not used, always -1.
* '''rope_index''': In TIM 2 / 3, the index of the rope part. Not used (-1) in TIM and TEMIM.

=== Programmable ball (TIM 2 / 3) ===

The programmable ball part is present in TIM 2 and 3, and its part type number is 87. The size of the entry is 60 bytes in total. The first 48 bytes is the same as the default part data structure, which is followed by another, 12-byte structure specific to this part. The format of the programmable ball data is:

UINT16LE density;
UINT16LE elasticity;
UINT16LE friction;
INT16LE gravity_buoyancy;
UINT16LE mass;
UINT16LE appearance_2;

* '''density''': The density of the ball, affects the buoyant force acting on the ball.
* '''elasticity''': The elasticity of the ball.
* '''friction''': The friction.
* '''gravity_buoyancy''': A calculated parameter, using the density and the mass of the ball, as well as the gravity and the pressure set for the puzzle. If its value is negative, the ball will rise due to the buoyant force rather than fall.
* '''mass''': The mass of the ball.
* '''appearance_2''': Has the same value as the ''appearance'' field. The ball can have 7 different colors/patterns.

The game has a dialog for setting the four physical properties (mass, elasticity, density, friction, in this order). However, the number stored in the data structure is not the same as the numbers shown on the program dialog. For example, if following settings are used for the ball: <code>mass = 8</code>, <code>elasticity = 3</code>, <code>density = 7</code>, <code>friction = 3</code>; and the default values are used for gravity/pressure, the puzzle file will contain the following values: <code>density = 3000</code>, <code>elasticity = 128</code>, <code>friction = 16</code>, <code>gravity_buoyancy = 269</code>, <code>mass = 201</code>. (Note: There is an inconsistency in the game here, the programmable ball part uses <code>density = 2832</code> and <code>mass = 200</code> by default, which does not correspond exactly to any value that can be set in the dialog.)

=== TIM demo version ===

In the demo version of the (original) TIM (available at several DOS shareware game websites), the ''flags_3'', ''outlet_plugged_1'' and ''outlet_plugged_2'' fields are missing.
Instead, the 42-byte part data (46 for belts, 48 for ropes, 50 for pulleys) is followed by an another, variable length data structure of unknown significance consisting of 16-bit little endian integers. It is always at least 2 bytes long, and the first two bytes contain the number of additional 16-bit words after this size word. The reverse engineering of this structure is complicated by the fact that it is only present in a demo version containing only 8 puzzles.

== Puzzle solution information ==

Puzzle solution information is only present in TIM 2 and TIM 3 puzzles. Its size is always 132 bytes and can contain 8 different conditions that must be satisfied so that the game will recognize the puzzle as solved. The first two bytes contains the number of such conditions actually set, in a 16-bit little endian format. This is followed by 8 entries, 16 bytes each, containing the required information for solution checking by the game. The format of each entry is:

INT16LE part_index;
UINT16LE part_state_1;
UINT16LE part_state_2;
UINT16LE part_count;
INT16LE position_rect_x;
INT16LE position_rect_y;
INT16LE position_rect_width;
INT16LE position_rect_height;

* '''part_index''': The index of the part in the puzzle file involved in the solution. -1 (0xFF 0xFF) for unused entries.
* '''part_state_1''': An ID for a "physical state" of a part (for example a balloon was popped or a candle was lit). In many puzzles, one specific part must be in a specified "physical state" in order to complete the level. This is the same ID for a "part state" as the ''first_frame_id'' member found in the C section of the part's ANM file.
* '''part_state_2''': Another ID for a "physical state", the exact meaning is unclear.
* '''part_count''': The value of the "Part count" option set in the "program solution" dialog of the game.
* '''position_rect_x''', '''position_rect_y''': The top left corner of the "position rectangle". If such a solution specified puzzle part must be located within this rectangle in order to solve the puzzle.
* '''position_rect_width''', '''position_rect_height''': Width and height of the "position rectangle", see above.

For the last four members ("position rectangle"), there are "fixed" combinations of values with special meaning:

* <code>-1, -1, -1, -1</code>: "Off screen", the part must leave the area visible on the game screen.
* <code>-500, -2000, 1640, 2000</code>: "Off top", the part must leave the visible area at the top.
* <code>-500, 400, 1640, 3000</code>: "Off bottom"
* <code>0, 0, 0, 0</code>: No such solution programmed, either this is "part state" solution or an unused entry (<code>part_index = -1</code>).

The last 2 bytes of the section contain the value of the "Delay" option set in the "program solution" dialog of the game, in 16-bit little endian format.

'''Note on puzzle solution information in TIM and TEMIM''': TIM / TEMIM puzzles do not contain such data. This can also be demonstrated by extracting e.g. <tt>L1.LEV</tt> from the archive file and rename the file to change the number. After starting the game, the level with the same number as the renamed file will be replaced with level 1. When playing the modified level, the game will not be able to check whether the puzzle is solved. Depending on its number, the level can become unwinnable or winnable by just clicking on the start machine button. Sometimes the game freezes.

== Tools ==
{{BeginFileFormatTools|Type=map}}
{{FileFormatTool
| Name = [https://www.vogons.org/viewtopic.php?p=1089143#p1089143 The Incredible Machine level/image resource viewer]
| Platform = Windows, Linux
| canView = Yes

| canCreate = No
| canModify = No
| editHidden = N/A
| editMetadata = N/A
| notes =
}}
{{EndFileFormatTools}}

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

The Incredible Machine 2-3 ANM File Format

2022-07-23T06:29:24Z

Knt47: viewer tool, small updates

The '''animation''' (<tt>.ANM</tt>) sub-files are found in the [[TIM Resource Format|archive file]] of [[The Incredible Machine 2]] (TIM 2) and [[Thie Incredible Machine 3|3]] (TIM 3). They contain the information required for drawing puzzle part sprites, which are often comprised of multiple sub-images of [[The Incredible Machine Image Format|image files]] and for animations of the puzzle parts. They are also used for animated parts of the game's user interface (for example the animated icons of the main menu). It can also contain commands for playing sound effects.

Most <tt>.ANM</tt> files (all in TIM 2) contain two chunks, starting with "<tt>ANM:</tt>" and "<tt>TAG:</tt>", respectively. Both use the typical "Dynamix chunk" format, starting with the 4-byte chunk type ("<tt>ANM:</tt>"/"<tt>TAG:</tt>", followed by the chunk size in 32-bit, little endian format. Unlike other Dynamix file formats, the most significant bit in the 32-bit size of the first chunk is not set. A small number of files in TIM 3 contain a third chunk, "<tt>LAB:</tt>", with an unclear meaning.

== The "ANM:" chunk ==

Not counting the chunk type and size, an "<tt>ANM:</tt> chunk has five parts, a 16 or 22 byte header, and four sections containing the actual sprite/animation frame/animation data, labeled here as A-D.

=== Header ===

The "<tt>ANM:</tt>" chunk (not counting the "<tt>ANM:</tt>" chunk type identifier and the chunk size) starts with a header, with a size of 16 or 22 bytes, depending on the magic number. It has the following Format:

[[UINT16LE]] magic_number_1;
UINT16LE magic_number_2;
UINT16LE size_section_a;
UINT16LE size_section_b;
UINT16LE size_section_c;
UINT16LE size_section_d;
UINT16LE anm_width;
UINT16LE anm_height;
/* 3 members, found only in files with a magic number of 0x54 0x42 0xEA 0x03: */
UINT16LE unknown_16;
UINT16LE unknown_18;
UINT16LE unknown_20;

* '''magic_number_1''', '''magic_number_2''': The header starts with a 4-byte magic number. The first two bytes are always 0x54 0x42. The second two bytes are a 16-bit little endian file version number. In TIM 2, the possible values 1000 (0x3E8) or 1001 (0x3E9). There is no obvious difference in the format of the files using these two numbers, however, 0x3E9 is much more common and 0x3E8 is mostly used for relatively small and simple files. In TIM 3, a small number of files use a newer version of the <tt>.ANM</tt> file format, with a magic_number_2 value of 1002 (0x3EA). Such files have a slightly different format compared to files with the other two numbers. The "newer" format is used in the user interface and the game menu, but never for puzzle part graphics.
* '''size_section_a''': The number of entries in the A section of the "<tt>ANM:</tt>" chunk, one entry is 2 byte (i.e. the section is an array of 16-bit integers). Several files do not have an A section (size_section_a == 0)
* '''size_section_b''': The number of entries in the B section. One entry is 12 bytes in the files in files with <code>magic_number_2 = 0x3EA</code>, 10 bytes in all other files.
* '''size_section_c''': The number of entries in the C section, one entry is 4 bytes.
* '''size_section_d''': The size of the D section in bytes.
* '''anm_width''', '''anm_height''': Width and height of the animation. In <tt>.ANM</tt> files for puzzle parts, the two structure members usually have the same value as width_1 and height_1 for the part in puzzle/level files.

Structure members found only in files with the longer header (<code>magic_number_2 = 0x3EA</code>):

* '''unknown_16''': 0x14 in all files, perhaps the size of header minus magic_number_1. Files with the longer header do not contain additional section in "<tt>ANM:</tt>" chunk, so it cannot be a size of such a section.
* '''unknown_18''': 0 in all files
* '''unknown_20''': 0x17 in one file, 0 in all others. Clearly not the size of an additional section in "<tt>ANM:</tt>" chunk. {{TODO|Additional research needed}}

=== Section A ===

Section A is empty in a large number of <tt>.ANM</tt> files. If present, it is an array of 16-bit little endian integers. It contains all numbers from 0 to the number of items in B section minus 1, in increasing order, with some numbers repeated. For example <code>0 1 1 1 2</code> means that the animation frame with index 1 in section B must be shown for the duration of 3 timer ticks instead of 1.

=== Section B ===

Section B is a list of structures containing 16 bit integer members, 6 if magic_number_2 is <tt>0x3EA</tt>, 5 in the other versions of the file format. It contains essential information about each animation frame. One structure has the following members:

[[INT16LE]] relative_pos_x;
INT16LE relative_pos_y;
UINT16LE width;
UINT16LE height;
UINT16LE section_d_offset;
/* Note that the last member is only present in files with */
/* magic number 0x54 0x42 0xEA 0x03 */
UINT16LE unknown_10;

* '''relative_pos_x''', '''relative_pos_y''': The coordinates where the animation frame must be drawn, relative to other frames. For the first item in the B section, the value of both tare typically 0, however there are a few exceptions. The relative position may be negative.
* '''width''', '''height''': The width and the height of the graphics in the specific animation frame.
* '''section_d_offset''': An offset in section D, points to the first command required for drawing the animation frame.
* '''unknown_10''': The meaning is unclear. Often, but not always a number divisible by 3. {{TODO|Additional research needed}}

=== Section C ===

A section C item has the following format:

UINT16LE first_frame_id;
UINT16LE state_id;

* '''first_frame_id''': The meaning of ''first_frame_id'' is slightly different between files containing or not containing an A section. If the A section is not present, this is the index in section B for the first animation frame for a particular animation. If there is an A section, ''first_frame_id'' is an index in the A section, and the 16-bit array item at this index is the required section B index. The section B indices determined this way essentially divide the B section into sub-sectons. One sub-section corresponds to the "animation" of a puzzle part or an user interface element in one specific state. If an "animation" has only one section B item, then the puzzle part or button/icon is not animated in this state.
* '''state_id''': An internal identifier used by the game for a state of the puzzle part or an user interface element. In a specific "state", the puzzle part (or user interface element) may or may not be animated, the animation frames belonging to such a state must be determined using the first_frame_id member.

=== Section D ===

The D section contains the instructions on how to draw each animation frame (or to play a sound). The section_d_offset field in the corresponding section B entry determines where the sequence of commands start for each animation frame. There are 6 different types of commands, numbered 0-5. Each command starts with its number in a 16-bit, little endian format. For commands 2-5, this is followed by a list of 16-bit integer parameters, the number of the parameters depends on command number.

==== Command 0: End of animation frame ====

Command 0 indicates the end of an animation frame in the file. It terminates the list of commands associated with a section B item. Command 0 has no parameters and is always 2 bytes long (the 16-bit command number).

==== Command 1: End of "ANM:" chunk ====

The last two bytes of section D (and the "<tt>ANM:</tt>" chunk) are always <code>01 00</code> (1 in 16-bit little endian format). These two bytes can be interpreted as a 2-byte command that terminates section D and the entire "<tt>ANM:</tt>" chunk. Command 1 is not found anywhere else in section D.

==== Command 2: Draw BMP sub-image ====

Command 2 is an instruction for the game engine to draw a sub-image from a <tt>.BMP</tt> image stored in the archive file of the game. It should be noted that a part sprite is often "cut into" multiple <tt>.BMP</tt> sub images, and in a few cases, they are stored in more than one file. Command 2 has five 16-bit integer parameters (size is 12 bytes, including the command number).

UINT16LE command_num; /* 2 */
UINT16LE bmp_file_num;
UINT16LE bmp_sub_image_num;
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE flip;

* '''bmp_file_num''': Index of the <tt>.BMP</tt> file in the TAG: chunk. The index of the first image is 1.
* '''bmp_sub_image_num''': The "sub-image" number of the <tt>.BMP</tt> file to draw. [[The Incredible Machine Image Format|<tt>.BMP</tt> images in TIM 2]] can have multiple sub images.
* '''draw_pos_x''', '''draw_pos_y''': The position of the image (top left corner), relative to the x and y coordinates in the corresponding section B item.
* '''flip''': The image can be drawn horizontally and/or vertically flipped relative to its original orientation. 1 = vertical flip, 2 = horizontal flip, 3 = both, 0 = no such transform is applied.

==== Command 3: Draw rectangle ====

Command 3 draws a rectangle with a border and fill color provided as arguments. It is mainly used in user interface elements and in the graphics shown in the part help screen, rarely in puzzle part graphics. It has the following format:

UINT16LE command_num; /* 3 */
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE rect_width;
UINT16LE rect_height;
UINT16LE border_color;
UINT16LE fill;

* '''draw_pos_x''', '''draw_pos_y''': Coordinates of the top left corner of the rectangle.
* '''rect_width''', '''rect_height''': The width and height of the rectangle.
* '''border_color''': The border color for the rectangle. In TIM 2, one color from the 16-color palette.
* '''fill''': The value of the ''fill'' parameter is either 0 - no fill, border only - or a value between 0x8000 and 0x800f where the least significant nibble contains the fill color.

==== Command 4: Draw line ====

Command 4 draws a line between two end points with a specific color. Like the rectangle command, it is mainly used for game interface graphics, not the puzzle parts. The format of the command is:

UINT16LE command_num; /* 4 */
INT16LE x1;
INT16LE y1;
INT16LE x2;
INT16LE y2;
UINT16LE line_color;

* '''x1''', '''y1''': The coordinates of one end point.
* '''x2''', '''y2''': The coordinates of the other end point.
* '''line_color''': The color of the line, one color from the 16-color palette in TIM 2.

==== Command 5: Play sound ====

If the command list for an animation frame includes command 5, a sound effect will be played when the particular frame is shown. It has one 16-bit parameter, the ID of the sound. TIM 2 contains sounds in two different formats. Sounds with a number >= 3000 are stored in the archive file of the game (<tt>SX_3???.RAW</tt>). <tt>.RAW</tt> files are uncompressed 8-bit PCM audio files without any header. The rest of the files (with numbers < 300) are found in <tt>TIM2.SX</tt>.
TIM 3 has <tt>.WAV</tt> files instead in the archive file an there is no <tt>TIM2.SX</tt>. ({{TODO|TIM 3 sounds with numbers below 3000}}).

== The "TAG:" chunk ==

The "<tt>TAG:</tt>" chunk contains the names of the <tt>.BMP</tt> sub-files (in the archive file of the game) required for displaying the animation. Not counting the "<tt>TAG:</tt>" chunk type identifier and the 32-bit chunk size, the first two bytes of the data contains the number of image file names in 16-bit little endian format. The remaining part of the data is the list of image file name entries. A single entry is a 16-bit image ID followed by a null-terminated string containing the name of the image. In TIM 2, the ID of the first image is always 1, however, there are exceptions to this rule in TIM 3 (but never in part graphics). There is no gap in the numbering of the images, this makes the image ID field somewhat redundant.

== The "LAB:" chunk ==

The "<tt>LAB:</tt>" chunk is present in a small number of <tt>.ANM</tt> files in TIM 3. <tt>.ANM</tt> files for puzzle parts never contain such a chunk. The structure of the "<tt>LAB:</tt>" chunk is similar to "<tt>TAG:</tt>", it consists of the number of entries stored as 16-bit integer, followed by item ID-null terminated string pairs. The strings are apparently not user interface texts visible to the player.

== Tools ==


[https://www.vogons.org/viewtopic.php?p=1089143#p1089143 The Incredible Machine level/image resource viewer] supports viewing animations in TIM 2-3 <tt>.ANM</tt> files.

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)


[[Category:All file formats]]
[[Category:The Incredible Machine 2]]
[[Category:The Incredible Machine 3]]

The Incredible Machine Level Format

2022-07-22T22:16:35Z

Knt47: Level viewer too, small updates

{{Map Infobox
| Type =
| Layers =
| Tile size = Not tile based, the game uses a 16x16 grid for walls and a few other puzzle parts
| Viewport =
'''576×368''' (Levels in [[The Incredible Machine]] (TIM) and [[The Even More Incredible Machine]] (TEMIM))
'''640×400''' (.GKC files in TIM and TEMIM)
'''560×377''' (Levels in [[The Incredible Machine 2]] and 3)
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|The Incredible Machine 3}}
}}

This page discusses the '''level format''' of [[The Incredible Machine]], from the first DOS version (abbreviated as TIM 1) to [[The Incredible Machine 3|TIM 3]] (which is a 32-bit Windows game). Even if the format of some sections of the file vary significantly between the versions, the way how the parts are stored is highly similar. Level files have the extension <tt>.LEV</tt>.

The machines/puzzles saved from the "freeform machine" mode or the built-in level editor are also discussed here. The format of files saved from built-in editor may be identical to or slightly different from the levels, depending on the game version. Such files are saved by the game with extension <tt>.TIM</tt>.

The animated '''"title screen"''' (<tt>TITLE.GKC</tt>) and '''"credits screen"''' (<tt>CREDITS.GKC</tt>) files (inside the archive file) in TIM 1 and [[The Even More Incredible Machine]] (TEMIM) use a variant of the level file format, even if these are not playable levels.

== Magic number ==

TIM-TIM 3 level and GKC files always start with a 4-byte magic number. The following table summarizes the magic numbers found in various versions of the game.

{| class="wikitable"
! Magic number (hex) !! Usage in game versions
|-
| <code>ED AC 00 01</code>
|
* Puzzles in TIM demo version.
|-
| <code>ED AC 02 01</code>
|
* Puzzles in TIM.
* Saved freeform machines in TIM.
* GKC files in TIM.
* <tt>CREDITS.GKC</tt> in TEMIM.
|-
| <code>EE AC 05 01</code>
|
* New puzzles in TEMIM not found in TIM.
* Saved freeform machines in TEMIM.
* <tt>TITLE.GKC</tt> in TEMIM.
|-
| <code>EF AC 11 01</code>
<code>EF AC 12 01</code>
|
* A small number of puzzles in TIM 2 and 3.
|-
| <code>EF AC 13 01</code>
|
* The large majority of puzzles in TIM 2 and 3.
* Puzzles saved from the built-in editor of TIM 2.
|-
| <code>EF AC 14 01</code>
|
* A small number of puzzles in TIM 3.
* Puzzles saved from the built-in editor of TIM 3.
|}

== Structure of puzzle and GKC files ==

The level/puzzle/saved machine files consist of multiple sections. An overview of the file structure is provided below, separately for TIM / TEMIM and TIM 2 / TIM 3.

=== TIM and TEMIM ===

* Magic number, see above
* Puzzle title, null-terminated string. missing in .GKC files and "freeform machines" saved by the player.
* Goal description, null-terminated string. Absent from .GKC files and "saved freeform machines" with magic number of <code>ED AC 02 01</code>. Present in TEMIM "saved freeform machines" (magic number <code>EE AC 05 01</code>). An empty string in .GKC files with magic number <code>EE AC 05 01</code>.
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move ("fixed", e.g. walls) and are not found initially to the parts bin.
* List of part entry structures for parts that can move (e.g. balls), not in the parts bin.
* An additional 16-bit, little endian integer value in puzzles with magic number of <code>EE AC 05 01</code>. The meaning of this value is unclear. 0 in puzzles from the game archive file. In saved freeform machines, 1 if there are parts placed into the parts bin, 0 otherwise.
* List of part entry structures for parts initially placed into the parts bin.

=== TIM 2 and 3 ===

* Magic number, see above
* Two additional "header" bytes in files with magic number <code>EF AC 13 01</code> or <code>EF AC 14 01</code>. First byte is always 0, second is the background color from the 16-color palette.
* Puzzle title, null-terminated string
* Goal description, null-terminated string
* Hints, see below
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move
* List of part entry structures for parts that can move
* Solution information, see below

== Hints ==

Hints are supported only in TIM 2 and 3 puzzles. The first two bytes of the hint data contain the number of the hints in 16-bit little endian format. This is followed by 8 hint entries, some of them may be unused. A size of an unused entry is 7 bytes. One entry consists of three 16-bit integers and a null-terminated string containing the hint text. The three integer members are (all have a 16-bit little endian format):

* '''position_x''': The X position of the hand icon for the hint.
* '''position_y''': The Y position.
* '''hint_icon_flip''': The hand icon of a hint can be flipped and can have four different orientations. Possible values are 0-3.

In TIM 2, there are 3 (?) puzzles with magic number <code>EF AC 11 01</code>. Neither of these files contain hints. However, the size of the empty hints section is 42 bytes in them instead of the expected 58.

== Puzzle information data structure ==

=== In TIM and TEMIM ===

In TIM and TEMIM, there are two different puzzle header information data structures, one is used by the puzzles, and the another is found in saved "freeform" machines and the GKC files.

The information structure format in TIM / TEMIM puzzles:

[[UINT16LE]] bonus_1;
UINT16LE bonus_2;
[[INT16LE]] pressure;
INT16LE gravity;
INT16LE unknown_8;
INT16LE unknown_10;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

The information structure format in saved "freeform" machines and GKC files:

INT16LE pressure;
INT16LE gravity;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

* '''bonus_1''': The value of "Bonus 1" immediately after the puzzle is loaded (its value is constantly decreasing while the player is solving the puzzle).
* '''bonus_2''': The value of "Bonus 2" for the puzzle.
* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''unknown_8''', ''unknown_10'': The value of these two members is always -8. Perhaps the top left corner of the screen in the coordinate system used for puzzle parts, which is also (-8, -8).
* '''music''': ID of music track played. Valid values are 1001-1016 for TIM and 1001-1021 for TEMIM.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move (e.g. walls), not in the "parts bin".
* '''num_parts_moving''': Number of parts in the puzzles that move (e.g. balls), not in the "parts bin".
* '''num_parts_in_partsbin''': The number of parts that are placed into the parts bin. (The player needs to position them in order to solve the puzzle.)

=== In TIM 2 and 3 ===

The information structure format in TIM 2 and 3:

INT16LE pressure;
INT16LE gravity;
UINT16LE unknown_4;
UINT16LE unknown_6;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE unknown_14;

* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''music''': ID of music track played. Valid values are 1000-1023.
* '''unknown_4''', '''unknown_6''': Meaning is unknown, always 0.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move, regardless of whether they are placed initially into the parts bin or not.
* '''num_parts_moving''': Number of parts in the puzzles that can move.
* '''unknown_14''': Value is always 0. Likely this member corresponds to num_parts_in_partsbin in TIM / TEMIM puzzle header. Unlike TIM / TEMIM, parts placed into the parts bin are not a separate section in TIM 2 / 3, therefore, its value is always zero.

== Puzzle part data ==

As already discussed in the With the exception of TIM demo version (see below), the size of a part entry for the majority of puzzle parts is 48 bytes. However, there are exceptions, which are discussed in separate sub-sections. The format of the "default" part entry:

UINT16LE part_type_num;
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
[[BYTE]] belt_connect_pos_x;
BYTE belt_connect_pos_y;
UINT16LE belt_line_distance;
UINT16LE unknown_32;
BYTE rope_1_connect_pos_x;
BYTE rope_1_connect_pos_y;
UINT16LE unknown_36;
BYTE rope_2_connect_pos_x;
BYTE rope_2_connect_pos_y;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''part_type_num''': A number associated with the type of the part (e.g. 0 - bowling ball). Required for identifying parts with an entry size different from the default. See [[The Incredible Machine Level Format/Part Numbers]]
* '''flags_1''': A combination of flag bits.
** '''TIM''' / '''TEMIM''' uses the following flag bits:
*** <code>0x20</code>: Unknown meaning, used for a few "moving" parts (bucket, candle)
*** <code>0x40</code>: Set if the part is a wall.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x800</code>: Part is placed initially into the parts bin (see num_parts_in_partsbin in part information data structure)
*** <code>0x1000</code>: "Moving" part, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x2000</code>: Part cannot move, in fixed position, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x4000</code>: Part cannot move, in fixed position (see ''num_parts_fixed'')
*** <code>0x8000</code>: Set when 0x800 is not set ({{TODO|further testing needed}})
** In '''TIM 2 / 3''', the bits have a known meaning:
*** <code>0x40</code>: Meaning unclear, used for "moving" parts only, but not always set, even for a single type of part.***
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x1000</code>: "Moving" part, affected by gravity.
*** <code>0x2000</code>, 0x4000: Used in combination for parts that do not move and are not affected by gravity.
* '''flags_2''': Another word containing flag bits. The meaning of most flags is the same in all game versions.
** <code>0x1</code>: A belt can be connected to the part.
** <code>0x2</code>: A belt is connected to the part.
** <code>0x4</code>: A rope can be connected to the part.
** <code>0x8</code>: A second rope can be connected to the part (teeter-totter)
** <code>0x10</code>: The part sprite is drawn horizontally flipped.
** <code>0x20</code>: The part sprite is drawn vertically flipped. Note on flip flags: Flipping a part in the game does not necessarily mean that one of the flip flags will be changed. For several parts, especially in TIM 2 / 3, flipping will affect the value of the ''appearance'' member.
** <code>0x40</code>: Probably unused
** <code>0x80</code>: Part can be stretched in at least one direction: inclines, conveyor belt, walls.
** <code>0x100</code>: Parts that can be stretched both horizontally and vertically, the walls.
* '''flags_3''': Some flags are only present in TIM 2 / 3. This member of the part data structure is missing in the demo version of TIM.
** <code>0x1</code>: The part can be plugged into an electric outlet.
** <code>0x2</code>: The part is an electric outlet.
** <code>0x4</code>: The part can burn (e.g. candle) or has a fuse that can be lit (e.g. dynamite, cannon). Usually in combination with flag 0x8.
** <code>0x8</code>: Meaning of this flag is unclear. Used for several part types, but changing it has no apparent consequence (?)
** Flags present only in '''TIM 2 / 3''':
*** <code>0x40</code>: Part is "locked", i.e not placed into the part bin.
*** <code>0x80</code>: Sizable scenery part (?)
*** <code>0x100</code>: {{TODO|unknown meaning}}
*** <code>0x400</code>: A "program" icon is shown for the part (?)
*** <code>0x1000</code>: Scenery part
*** <code>0x2000</code>: Wall part (?)
*** <code>0x8000</code>: A "Puzzle solution" icon is shown for the part (?)
* '''appearance''': An identifier for the sprite that is shown for a part before the machine is started. (Once the machine is started, the state of the part can change and so can the sprite shown.) The meaning is different between TIM and TIM 2. In TIM, the sprite of some parts consists of only one image, in this case, this is often the number of the sub-image in the image resource file. ({{TODO|For other parts, this is probably an internal identifier for the sprite (?)}}). In TIM 2 and 3, the meaning of the appearance is an index in the A section of the [[The Incredible Machine 2-3 ANM File Format|.ANM file]] for the part, or if this is absent, an index in the B section. "Programming" a part in TIM 2 and 3 often results in the change of this field.
* '''unknown_10''': Probably unused, usually 0.
* '''width_1''', '''height_1''': The width and height of the selectable area of the part ({{TODO|more reverse engineering work needed}})
* '''width_2''', '''height_2''': At least in TIM 2, witdh_2 is used for calculating the position of part sprite when the part is flipped because of the horizontal flip bit is set in flags_2.
* '''pos_x''', '''pos_y''': The position of the part, usually the top left corner of the bounding rectangle.
* '''behavior''': In TIM 2 and 3, a programmed behavior of the part. (However, for many parts, "programming" modifies the ''appearance'' member.) For example the number of shots of the phazer gun or character shown by the message computer. Meaning is different for rope parts, see below. Unused in TIM and TEMIM (except for ropes).
* '''unknown_26''': Probably unused, usually 0. Note that belt parts have a value of 1 in this position.
* '''belt_connect_pos_x''', '''belt_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Always positive or 0, because ''pos_x'' and ''pos_y'' are the coordinates of the top left corner where the sprite starts. Note that the formulas required for calculating the exact position of the belt are slightly different between TIM and TIM 2. Parts for which connection of a belt is allowed have a distinct circular area in their sprite, corresponding to the location where the belt is connected. In TIM / TEMIM, ''belt_connect_pos_x'' and ''belt_connect_pos_y'' is approximately the top left corner of its bounding rectangle, while in TIM 2 /3 it is close to the center of the circle.
* '''unknown_36''': Probably unused, usually 0.
* '''belt_line_distance''': The belts in the game appear as two, usually not perfectly parallel black (TIM / TEMIM) or gray (TIM 2 / 3) lines. This parameter determines the distance between the two segments, More precisely, it is either approximately the diameter of the circular area mentioned at ''belt_connect_pos_x'' and ''belt_connect_pos_y'' (TIM / TEMIM) or its radius (TIM 2 / 3).
* '''unknown_32''': Probably unused, usually 0.
* '''rope_1_connect_pos_x''', '''rope_1_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Similarly to belt_connect_pos_x/y, always positive or 0.
* '''rope_2_connect_pos_x''', '''rope_2_connect_pos_y''': The same as ''rope_1_connect_pos_x'', ''rope_1_connect_pos_y'', bit for another connected rope part.
* '''connected_1''', '''connected_2''': The index of one or two parts in the puzzle that are connected to this part with a rope. If the rope runs through pulleys, this is the part index of the first pulley. If no rope is connected or this is not possible for the part, the value of both structure members are -1. (Of course, if one rope is connected, the value of one structure member (usually connected_rope_1) is the index of the rope part and the other is -1) )In TIM 2 and 3, the "remote bomb" part actually corresponds to two entries in the puzzle file. The connected_rope_2 field contains the index of the another "element" of the bomb, in both entries.
* '''outlet_plugged_1''', '''outlet_plugged_2''': These structure members are only meaningful for electric outlet parts. Electric outlets always have 2 "sockets" for parts requiring electricity. It contains the index/indices of the part/parts plugged into the electric outlet, or -1 if the "socket" is free. If the part does not support this, both values are -1.

=== Belts ===

Belt parts (part 8) (except in the demo version of TIM, see below) use a 52-byte entry, with the following format:

UINT16LE part_type_num; /* 8 for belts */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
INT16LE belt_connected_part_1;
INT16LE belt_connected_part_2;
UINT16LE unknown_36;
UINT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0</code>, <code>flags_3 = 0</code>
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0</code>, <code>flags_3 = 0x40</code> (or <code>0</code> if in parts bin)
* '''appearance''': Always 0, belts have no true sprite (represented by two lines).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for belts, always 0.
* '''pos_x''', '''pos_y''' In TIM / TEMIM, either 0 or -1. In TIM 2, -1 or -100 (0xff9c). Meaning of these numbers is unclear, and the usage of the two different values do not correlate with the flags.
* '''behavior''': Not used, always 0.
* '''unknown_26''': Always 1, perhaps indicates that the part is a belt.
* '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''belt_connected_part_1''', '''belt_connected_part_2''': Index of the two parts in the puzzle connected by this belt. In TIM and TEMIM, both are -1 if the belt is placed into the parts bin.
* '''unknown_36''', '''unknown_38''', '''unknown_40''', '''unknown_42''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Ropes ===

Rope parts (part 10) (except in the demo version of TIM, see below) use a 54-byte entry. TIM 2 and 3 also have a "steel cable" part (part 76) which also behaves as a rope and the size of the part entry is also identical. The rope part entry has the following format:

UINT16LE part_type_num; /* 10 for rope, 76 for steel cable */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE rope_segment_length;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
UINT16LE unknown_36;
INT16LE rope_connected_part_1;
INT16LE rope_connected_part_2;
BYTE part_1_connect_field_usage;
BYTE part_2_connect_field_usage;
UINT16LE unknown_44;
UINT16LE unknown_46;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''': Same flags used as in the belt part structure.
* '''appearance''': Always 0, ropes have no true sprite (represented by one or more line segments).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for ropes, always 0.
* '''pos_x''', '''pos_y''': Similarly to belts, possible values are 0 and -1 in TIM / TEMIM; and -1 and -100 in TIM 2 / 3.
* '''rope_segment_length''': The length of the rope (Euclidean distance between the two ends) if the rope does not run through pulleys. Otherwise, the length of the rope segment between the part at one end (rope_connected_part_1 (?)) and the first pulley ({{TODO|additional testing needed}}).
* '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for pulleys.
* '''unknown_36''': Not used, always 0.
* '''rope_connected_part_1''', '''rope_connected_part_2''': Index of the two parts in the puzzle connected by this rope (never the pulleys). In TIM and TEMIM, both are -1 if the rope is placed into the parts bin.
* '''part_1_connect_field_usage''', '''part_2_connect_field_usage''': Whether ''connected_1'' or ''connected_2'' is used in the two connected parts for this rope. 0 if connected_1, 1 if connected_2. ({{TODO|additional testing needed}})
* '''unknown_44''', '''unknown_46''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Pulleys ===

The format of the 56-byte puzzle part entry for the pulley (part 7):

UINT16LE part_type_num; /* 7 for pulley */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
BYTE pulley_rope_1_connect_pos_x;
BYTE pulley_rope_1_connect_pos_y;
INT16LE unknown_36;
INT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
BYTE pulley_rope_2_connect_pos_x;
BYTE pulley_rope_2_connect_pos_y;
INT16LE pulley_connected_1;
INT16LE pulley_connected_2;
INT16LE unknown_50;
INT16LE unknown_52;
INT16LE rope_index;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0x4</code>, <code>flags_3 = 0x8</code> (<code>0x0</code> {{TODO|in some cases}})
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0x4</code>, <code>flags_3 = 0x48</code> (or <code>0x8</code> if in parts bin)
* '''appearance''': Pulleys can have four different sprites depending on the orientation. Possible values are 0-3.
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': The size of the pulley sprite. In TIM 2 / 3, also depends on the orientation.
* '''pos_x''', '''pos_y''': The position of the pulley, top left coordinates of the bounding rectangle.
* '''behavior''', '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for ropes.
* '''pulley_rope_1_connect_pos_x''', '''pulley_rope_1_connect_pos_y''': The coordinates of the point where one rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''. Depends on the orientation of the pulley, like ''appearance''.
* '''unknown_36''', '''unknown_38''': Not used, always -1.
* '''unknown_40'', ''unknown_42''': Not used, always 0.
* '''pulley_rope_2_connect_pos_x''', '''pulley_rope_2_connect_pos_y''': The coordinates of the point where the other rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''.
* '''pulley_connected_1''', '''pulley_connected_2''': Either the index of part at one of the two ends of the rope, or the index of next or previous pulley the rope is running through.
* '''unknown_50''', '''unknown_52''': Not used, always -1.
* '''rope_index''': In TIM 2 / 3, the index of the rope part. Not used (-1) in TIM and TEMIM.

=== Programmable ball (TIM 2 / 3) ===

The programmable ball part is present in TIM 2 and 3, and its part type number is 87. The size of the entry is 60 bytes in total. The first 48 bytes is the same as the default part data structure, which is followed by another, 12-byte structure specific to this part. The format of the programmable ball data is:

UINT16LE density;
UINT16LE elasticity;
UINT16LE friction;
INT16LE gravity_buoyancy;
UINT16LE mass;
UINT16LE appearance_2;

* '''density''': The density of the ball, affects the buoyant force acting on the ball.
* '''elasticity''': The elasticity of the ball.
* '''friction''': The friction.
* '''gravity_buoyancy''': A calculated parameter, using the density and the mass of the ball, as well as the gravity and the pressure set for the puzzle. If its value is negative, the ball will rise due to the buoyant force rather than fall.
* '''mass''': The mass of the ball.
* '''appearance_2''': Has the same value as the ''appearance'' field. The ball can have 7 different colors/patterns.

The game has a dialog for setting the four physical properties (mass, elasticity, density, friction, in this order). However, the number stored in the data structure is not the same as the numbers shown on the program dialog. For example, if following settings are used for the ball: <code>mass = 8</code>, <code>elasticity = 3</code>, <code>density = 7</code>, <code>friction = 3</code>; and the default values are used for gravity/pressure, the puzzle file will contain the following values: <code>density = 3000</code>, <code>elasticity = 128</code>, <code>friction = 16</code>, <code>gravity_buoyancy = 269</code>, <code>mass = 201</code>. (Note: There is an inconsistency in the game here, the programmable ball part uses <code>density = 2832</code> and <code>mass = 200</code> by default, which does not correspond exactly to any value that can be set in the dialog.)

=== TIM demo version ===

In the demo version of the (original) TIM (available at several DOS shareware game websites), the ''flags_3'', ''outlet_plugged_1'' and ''outlet_plugged_2'' fields are missing.
Instead, the 42-byte part data (46 for belts, 48 for ropes, 50 for pulleys) is followed by an another, variable length data structure of unknown significance consisting of 16-bit little endian integers. It is always at least 2 bytes long, and the first two bytes contain the number of additional 16-bit words after this size word. The reverse engineering of this structure is complicated by the fact that it is only present in a demo version containing only 8 puzzles.

== Puzzle solution information ==

Puzzle solution information is only present in TIM 2 and TIM 3 puzzles. Its size is always 132 bytes and can contain 8 different conditions that must be satisfied so that the game will recognize the puzzle as solved. The first two bytes contains the number of such conditions actually set, in a 16-bit little endian format. This is followed by 8 entries, 16 bytes each, containing the required information for solution checking by the game. The format of each entry is:

INT16LE part_index;
UINT16LE part_state_1;
UINT16LE part_state_2;
UINT16LE part_count;
INT16LE position_rect_x;
INT16LE position_rect_y;
INT16LE position_rect_width;
INT16LE position_rect_height;

* '''part_index''': The index of the part in the puzzle file involved in the solution. -1 (0xFF 0xFF) for unused entries.
* '''part_state_1''': An ID for a "physical state" of a part (for example a balloon was popped or a candle was lit). In many puzzles, one specific part must be in a specified "physical state" in order to complete the level. This is the same ID for a "part state" as the ''first_frame_id'' member found in the C section of the part's ANM file.
* '''part_state_2''': Another ID for a "physical state", the exact meaning is unclear.
* '''part_count''': The value of the "Part count" option set in the "program solution" dialog of the game.
* '''position_rect_x''', '''position_rect_y''': The top left corner of the "position rectangle". If such a solution specified puzzle part must be located within this rectangle in order to solve the puzzle.
* '''position_rect_width''', '''position_rect_height''': Width and height of the "position rectangle", see above.

For the last four members ("position rectangle"), there are "fixed" combinations of values with special meaning:

* <code>-1, -1, -1, -1</code>: "Off screen", the part must leave the area visible on the game screen.
* <code>-500, -2000, 1640, 2000</code>: "Off top", the part must leave the visible area at the top.
* <code>-500, 400, 1640, 3000</code>: "Off bottom"
* <code>0, 0, 0, 0</code>: No such solution programmed, either this is "part state" solution or an unused entry (<code>part_index = -1</code>).

The last 2 bytes of the section contain the value of the "Delay" option set in the "program solution" dialog of the game, in 16-bit little endian format.

'''Note on puzzle solution information in TIM and TEMIM''': TIM / TEMIM puzzles do not contain such data. This can also be demonstrated by extracting e.g. <tt>L1.LEV</tt> from the archive file and rename the file to change the number. After starting the game, the level with the same number as the renamed file will be replaced with level 1. When playing the modified level, the game will not be able to check whether the puzzle is solved. Depending on its number, the level can become unwinnable or winnable by just clicking on the start machine button. Sometimes the game freezes.

== Tools ==
{{BeginFileFormatTools|Type=map}}
{{FileFormatTool
| Name = [https://www.vogons.org/viewtopic.php?p=1089143#p1089143 The Incredible Machine level/image resource viewer]
| Platform = Windows, Linux
| canView = Yes

| canCreate = No
| canModify = No
| editHidden = N/A
| editMetadata = N/A
| notes =
}}
{{EndFileFormatTools}}

{{TODO|Level viewer will be published soon}}

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

The Incredible Machine Image Format

2022-07-22T21:39:54Z

Knt47: /* Tools */ New version of program

{{Tileset Infobox
| Hardware1 = EGA
| Hardware2 = VGA
| MaxTiles = 65535
| Palette = Shared
| Names = N
| TileMinSize = 1x1
| TileMaxSize = 65535×65535
| NumPlanes = 1
| PlaneArrangement = Linear
| HasTransparency = Y
| Metadata = None
| Subtilesets = N
| Compressed = Y
| Hidden = Y
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|Heart of China}}
}}

'''The Incredible Machine''' (TIM) '''bitmap images''' are stored in the <tt>RESOURCE.00?</tt> [[TIM Resource Format|resource files]] as sub-files. They have the extension <tt>.BMP</tt>.

(For full-screen images (<tt>*.SCR</tt>), see [[RES Format (Stellar 7)#SCR: Fullscreen image|Stellar 7 RES Format]].)

== Chunk format ==

The files are built up out of chunks, in the typical Dynamix chunk format: a 3-character ID, followed by a ':', followed by the chunk size in [[UINT32LE]] format. The highest bit of the chunk size value is not actually part of the chunk size: it is set to 1 if the chunk is a container-type chunk that contains more chunks inside itself. This chunk format is documented on the [[RES Format (Stellar 7)#BMP: images|Stellar 7 RES Format]] page.

The BMP file is contained inside one <tt>BMP</tt> chunk. This is a container chunk. None of chunks types embedded inside it are container chunks.

The first chunk inside the <tt>BMP</tt> data is the <tt>INF</tt> chunk. Its data starts with a [[UINT16LE]] indicating the number of sub-images inside the file, followed by two UINT16LE arrays containing respectively the widths and heights of all images.

Based on the chunk type that contains the image data, there are two types of images:

== SCN/OFF format ==

The majority of the image files in ''The Incredible Machine'', including the graphics for puzzle parts, contain an <tt>SCN</tt> and an <tt>OFF</tt> chunk. The image data is stored in the <tt>SCN</tt> chunk, while the <tt>OFF</tt> chunk contains an index for each sub-image's data inside the <tt>SCN</tt> chunk. The <tt>SCN</tt> chunk has its own compression format, described in the next section.

=== The SCN chunk ===

The <tt>SCN</tt> chunk contains the pixel data for each sub-image. Basically, it has an extended [[RLE Compression#Code|code-based run-length encoding]] format with 2-bit commands. This gives four commands; the classic "repeat" and "copy" ones, and two extra commands to skip ahead. These "skips" should always treat the skipped space as transparent. If the output buffer is not cleared in advance, and the decompression is not meant to directly paint the new graphics onto an existing image in the buffer, these commands might need to specifically write 0-values to fill the skipped pixels.

The data for each sub-image starts with an <code>addValue</code> byte that has a special meaning: its value is added to all non-transparent pixel values. It normally corresponds to the lowest pixel value found in the resulting image. The value of this byte is set to 0xFF in some "empty" images that contain only a few transparent pixels.
In 8-bit games, like [[Heart of China]], the result may be an 8-bit image, meaning <code>addValue</code>, and the resulting pixel values, can be larger than 0x0F. The compression itself is based on storage of 4-bit pixels, though, so even on 8-bit images, the final data can only contain values from <code>addValue</code> up to <code>addValue + 0x0F</code>, plus the background colour. This special handling of transparency makes sure that the full range of the 4 bits can be used for colours, without the need to sacrifice one for transparency. This does make it difficult to convert to classic image formats without upgrading the image to at least 8-bit.

The actual RLE codes start after this byte. The <code>command</code> is made from the upper two bits, with the lower six bits serving as the <code>value</code>.

Note that this <code>value</code> always denotes a number of ''pixels'', not bytes, which may be tricky to program for 4-bit images. An alternative approach could be to decompress the image to an 8-bit buffer, and post-process the result to compact it to 4-bit (unless the <code>addValue</code> makes the values too large for that, and it is intended to be 8-bit).

The four different commands are:

==== Command 0: Line skip ====

The <code>command</code> made from high bits <tt>00</tt> is meant to skip to the next line in the image. This command ''must'' be used to terminate a line in the image; the format does not seem to support automatic wraparound for progressing to a new line. This also means none of the other commands will ever write data that goes beyond the end of a line.

The line skip command will move the output pointer down one line on the image (ending up on the same X-coordinate on the next line), and then move back by the amount of pixels specified in <code>value</code>. With wraparound included, this means the operation simply jumps (or background-fills) to the position <code>width - value</code> pixels ahead of your current output write position.

There are some special cases in this, though. Since this should be able to move from the end of one line to the start of the next one, it needs to be able to address the entire width of the image, which, on large images, can't be done in one 6-bit value. Because of this, the data may contain two consecutive bytes with a 'line skip' command, and the values of both of these need to be taken together, with the second command providing the more significant seventh to twelfth bits to be added to the first read value, as <code>value = value1 | (value2 << 6)</code>.

However, if an image has several empty lines in it, it can be unclear whether or not such commands should be taken together. Because of this, if the second command has a <code>value</code> of 0, the rule is to always treat it as separate command. To avoid all ambiguity in these cases, and because a <code>value</code> 00 code ''can'' be extended by one with a higher <code>value</code>, if the non-empty pixels on that later line start at an X-coordinate earlier than the first empty pixel on that earlier line, the first line skip command will '''always''' align the X-coordinate with the point at which the data restarts after the gap, so that all commands following it can be non-ambiguous byte 00 full line skips. Note that if the pixel appears at an identical or higher X-coordinate, all line skips can be done with 00 bytes, and any remaining distance can simply be filled up with 'short skip' commands (see below), which can perfectly be placed after the 00 bytes.

==== Command 1: Short skip ====

The <code>command</code> you get when the high bits are <tt>01</tt> will skip (or background-fill) the amount of pixels specified in <code>value</code>. Numbers greater than 0x3F will simply be encoded in multiple 'short skip' commands. A 'short skip' command with a <code>value</code> of 0, resulting in a Code byte 0x40, is used to indicate the end of the decompression of the current sub-image.

==== Command 2: Repeat ====

A <code>command</code> made up of bits <tt>10</tt> will create a sequence of pixels of the same color. The repeat count is specified by <code>value</code>. A single byte follows the Code byte, containing the pixel value. Since this is a 4-bit format, the most significant 4 bits of this byte are always zero. Note that the <code>addValue</code> from the start of the data needs to be added to this to get the real pixel value to repeat.

==== Command 3: Copy ====

The <code>command</code> from high bits <tt>11</tt> is the Copy command. This simply copies a sequence of pixel values to the output. The amount of pixels is specified in <code>value</code>.

Since the amount is in pixels, the number of bytes after the Code byte does not match the <code>value</code>. It can be calculated as <code>(value + 1) >> 1</code>. Each byte contains two pixels, with the color of the leftmost pixel stored in the most significant nibble. If the number of pixels is odd, the most significant 4 bits of the last byte contains the color of the last pixel, and the less significant nibble is zero. Note that since the <code>addValue</code> from the start of the data needs to be added to every pixel in this range, and the starting position to write pixels to may be an odd number at the start of the command, this operation requires treating all data as nibbles to process them correctly.

==== Terminator ====

Nearly all sub-images are "terminated" by the byte sequence 0x00 0x40; a full line skip, followed by an empty short skip command. However, there are a few exceptions, where it ends on 0x40 alone. Do note that while a 0x40 can always be considered a terminator command, since it has no real meaning on its own, a 0x00 is a perfectly valid full-line skip, and should never be treated as a signal to end the decompression.

=== The OFF chunk ===

The <tt>OFF</tt> chunk contains the offsets for each sub-image in the <tt>SCN</tt> chunk, as [[UINT32LE]] values. The first one should always be zero.

The end of the current sub-image's compressed data in the <tt>SCN</tt> chunk can be determined from the start of the next offset in the list, or the length of the <tt>SCN</tt> chunk, if it's the final image. In practice, though, the data itself will always indicate the end with the 0x40 terminator value.

=== Format quirks ===

Since the 'line skip' command is the only valid way to progress to a new line, and this can only address up to 12 bits, images in this format are technically restricted to a width of up to 4095 pixels.

== BIN format ==

The remaining files in ''The Incredible Machine'' use a <tt>BIN</tt> chunk (e.g. <tt>MOUSE.BMP</tt>, <tt>PARTBIN.BMP</tt>).

The <tt>BIN</tt> chunk has a small header of one byte to indicate the compression algorithm, followed by a [[UINT32LE]] giving the uncompressed size. It supports the same compression algorithms as [[Dynamix Font Format v4-v5#Compression|Dynamix fonts]]. The header is immediately followed by the compressed 4bpp pixel data.

This format is the 4 bit per pixel version of [[RES Format (Stellar 7)#BMP: Image|the BIN/VGA-containing BMP format]] found in several 8-bit Dynamix games.

== Tools ==

{{BeginFileFormatTools|Type=image}}
{{FileFormatTool
| Name = [https://www.vogons.org/viewtopic.php?p=1089143#p1089143 The Incredible Machine level/image resource viewer]
| Platform = Windows, Linux
| canView = Yes
| canExport = Yes
| canImport = No
| editHidden = No
| editMetadata = N/A
| notes =
}}
{{FileFormatTool
| Name = [https://www.vogons.org/viewtopic.php?f=5&t=76910 The Incredible Machine image resource reader] Note: outdated version
| Platform = Windows, Linux
| canView = Yes
| canExport = Yes
| canImport = No
| editHidden = No
| editMetadata = N/A
| notes =
}}
{{FileFormatTool
| Name = [[Engie File Converter]]
| Platform = Windows
| canView = Yes
| canExport = Yes
| canImport = Yes
| editHidden = No
| editMetadata = N/A
| notes = Supports <tt>SCN/OFF</tt> files with a high <code>addValue</code> byte, treating them as 8-bit.
}}
{{EndFileFormatTools}}

== Credits ==
The SCN compression was reverse engineered by [[User:Knt47|Knt47]], with further detail research conducted by [[User:Nyerguds|Nyerguds]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

[[Category:Sierra/Dynamix File Formats]]

The Incredible Machine 2-3 ANM File Format

2022-07-21T16:14:19Z

Knt47: /* Credits */ category

The '''animation''' (<tt>.ANM</tt>) sub-files are found in the [[TIM Resource Format|archive file]] of [[The Incredible Machine 2]] (TIM 2) and [[Thie Incredible Machine 3|3]] (TIM 3). They contain the information required for drawing puzzle part sprites, which are often comprised of multiple sub-images of [[The Incredible Machine Image Format|image files]] and for animations of the puzzle parts. They are also used for animated parts of the game's user interface (for example the animated icons of the main menu). It can also contain commands for playing sound effects.

Most <tt>.ANM</tt> files (all in TIM 2) contain two chunks, starting with "<tt>ANM:</tt>" and "<tt>TAG:</tt>", respectively. Both use the typical "Dynamix chunk" format, starting with the 4-byte chunk type ("<tt>ANM:</tt>"/"<tt>TAG:</tt>", followed by the chunk size in 32-bit, little endian format. Unlike other Dynamix file formats, the most significant bit in the 32-bit size of the first chunk is not set. A small number of files in TIM 3 contain a third chunk, "<tt>LAB:</tt>", with an unclear meaning.

== The "ANM:" chunk ==

Not counting the chunk type and size, an "<tt>ANM:</tt> chunk has five parts, a 16 or 22 byte header, and four sections containing the actual sprite/animation frame/animation data, labeled here as A-D.

=== Header ===

The "<tt>ANM:</tt>" chunk (not counting the "<tt>ANM:</tt>" chunk type identifier and the chunk size) starts with a header, with a size of 16 or 22 bytes, depending on the magic number. It has the following Format:

[[UINT16LE]] magic_number_1;
UINT16LE magic_number_2;
UINT16LE size_section_a;
UINT16LE size_section_b;
UINT16LE size_section_c;
UINT16LE size_section_d;
UINT16LE anm_width;
UINT16LE anm_height;
/* 3 members, found only in files with a magic number of 0x54 0x42 0xEA 0x03: */
UINT16LE unknown_16;
UINT16LE unknown_18;
UINT16LE unknown_20;

* '''magic_number_1''', '''magic_number_2''': The header starts with a 4-byte magic number. The first two bytes are always 0x54 0x42. The second two bytes are a 16-bit little endian file version number. In TIM 2, the possible values 1000 (0x3E8) or 1001 (0x3E9). There is no obvious difference in the format of the files using these two numbers, however, 0x3E9 is much more common and 0x3E8 is mostly used for relatively small and simple files. In TIM 3, a small number of files use a newer version of the <tt>.ANM</tt> file format, with a magic_number_2 value of 1002 (0x3EA). Such files have a slightly different format compared to files with the other two numbers. The "newer" format is used in the user interface and the game menu, but never for puzzle part graphics.
* '''size_section_a''': The number of entries in the A section of the "<tt>ANM:</tt>" chunk, one entry is 2 byte (i.e. the section is an array of 16-bit integers). Several files do not have an A section (size_section_a == 0)
* '''size_section_b''': The number of entries in the B section. One entry is 12 bytes in the files in files with <code>magic_number_2 = 0x3EA</code>, 10 bytes in all other files.
* '''size_section_c''': The number of entries in the C section, one entry is 4 bytes.
* '''size_section_d''': The size of the D section in bytes.
* '''anm_width''', '''anm_height''': Width and height of the animation. In <tt>.ANM</tt> files for puzzle parts, the two structure members usually have the same value as width_1 and height_1 for the part in puzzle/level files.

Structure members found only in files with the longer header (<code>magic_number_2 = 0x3EA</code>):

* '''unknown_16''': 0x14 in all files, perhaps the size of header minus magic_number_1. Files with the longer header do not contain additional section in "<tt>ANM:</tt>" chunk, so it cannot be a size of such a section.
* '''unknown_18''': 0 in all files
* '''unknown_20''': 0x17 in one file, 0 in all others. Clearly not the size of an additional section in "<tt>ANM:</tt>" chunk. {{TODO|Additional research needed}}

=== Section A ===

Section A is empty in a large number of <tt>.ANM</tt> files. If present, it is an array of 16-bit little endian integers. It contains all numbers from 0 to the number of items in B section minus 1, in increasing order, with some numbers repeated. For example <code>0 1 1 1 2</code> means that the animation frame with index 1 in section B must be shown for the duration of 3 timer ticks instead of 1.

=== Section B ===

Section B is a list of structures containing 16 bit integer members, 6 if magic_number_2 is <tt>0x3EA</tt>, 5 in the other versions of the file format. It contains essential information about each animation frame. One structure has the following members:

[[INT16LE]] relative_pos_x;
INT16LE relative_pos_y;
UINT16LE width;
UINT16LE height;
UINT16LE section_d_offset;
/* Note that the last member is only present in files with */
/* magic number 0x54 0x42 0xEA 0x03 */
UINT16LE unknown_10;

* '''relative_pos_x''', '''relative_pos_y''': The coordinates where the animation frame must be drawn, relative to other frames. For the first item in the B section, the value of both tare typically 0, however there are a few exceptions. The relative position may be negative.
* '''width''', '''height''': The width and the height of the graphics in the specific animation frame.
* '''section_d_offset''': An offset in section D, points to the first command required for drawing the animation frame.
* '''unknown_10''': The meaning is unclear. Often, but not always a number divisible by 3. {{TODO|Additional research needed}}

=== Section C ===

A section C item has the following format:

UINT16LE first_frame_id;
UINT16LE state_id;

* '''first_frame_id''': The meaning of ''first_frame_id'' is slightly different between files containing or not containing an A section. If the A section is not present, this is the index in section B for the first animation frame for a particular animation. If there is an A section, ''first_frame_id'' is an index in the A section, and the 16-bit array item at this index is the required section B index. The section B indices determined this way essentially divide the B section into sub-sectons. One sub-section corresponds to the "animation" of a puzzle part or an user interface element in one specific state. If an "animation" has only one section B item, then the puzzle part or button/icon is not animated in this state.
* '''state_id''': An internal identifier used by the game for a state of the puzzle part or an user interface element. In a specific "state", the puzzle part (or user interface element) may or may not be animated, the animation frames belonging to such a state must be determined using the first_frame_id member.

=== Section D ===

The D section contains the instructions on how to draw each animation frame (or to play a sound). The section_d_offset field in the corresponding section B entry determines where the sequence of commands start for each animation frame. There are 6 different types of commands, numbered 0-5. Each command starts with its number in a 16-bit, little endian format. For commands 2-5, this is followed by a list of 16-bit integer parameters, the number of the parameters depends on command number.

==== Command 0: End of animation frame ====

Command 0 indicates the end of an animation frame in the file. It terminates the list of commands associated with a section B item. Command 0 has no parameters and is always 2 bytes long (the 16-bit command number).

==== Command 1: End of "ANM:" chunk ====

The last two bytes of section D (and the "<tt>ANM:</tt>" chunk) are always <code>01 00</code> (1 in 16-bit little endian format). These two bytes can be interpreted as a 2-byte command that terminates section D and the entire "<tt>ANM:</tt>" chunk. Command 1 is not found anywhere else in section D.

==== Command 2: Draw BMP sub-image ====

Command 2 is an instruction for the game engine to draw a sub-image from a </tt>.BMP</tt> image stored in the archive file of the game. It should be noted that a part sprite is often "cut into" multiple </tt>.BMP</tt> sub images, and in a few cases, they are stored in more than one file. Command 2 has five 16-bit integer parameters (size is 12 bytes, including the command number).

UINT16LE command_num; /* 2 */
UINT16LE bmp_file_num;
UINT16LE bmp_sub_image_num;
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE flip;

* '''bmp_file_num''': Index of the <tt>.BMP</tt> file in the TAG: chunk. The index of the first image is 1.
* '''bmp_sub_image_num''': The "sub-image" number of the <tt>.BMP</tt> file to draw. [[The Incredible Machine Image Format|<tt>.BMP</tt> images in TIM 2]] can have multiple sub images.
* '''draw_pos_x''', '''draw_pos_y''': The position of the image (top left corner), relative to the x and y
coordinates in the corresponding section B item.
* '''flip''': The image can be drawn horizontally and/or vertically flipped relative to its original orientation. 1 = vertical flip, 2 = horizontal flip, 3 = both, 0 = no such transform is applied.

==== Command 3: Draw rectangle ====

Command 3 draws a rectangle with a border and fill color provided as arguments. It is mainly used in user interface elements and in the graphics shown in the part help screen, rarely in puzzle part graphics. It has the following format:

UINT16LE command_num; /* 3 */
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE rect_width;
UINT16LE rect_height;
UINT16LE border_color;
UINT16LE fill;

* '''draw_pos_x''', '''draw_pos_y''': Coordinates of the top left corner of the rectangle.
* '''rect_width''', '''rect_height''': The width and height of the rectangle.
* '''border_color''': The border color for the rectangle. In TIM 2, one color from the 16-color palette.
* '''fill''': The value of the ''fill'' parameter is either 0 - no fill, border only - or a value between 0x8000 and 0x800f where the least significant nibble contains the fill color.

==== Command 4: Draw line ====

Command 4 draws a line between two end points with a specific color. Like the rectangle command, it is mainly used for game interface graphics, not the puzzle parts. The format of the command is:

UINT16LE command_num; /* 4 */
INT16LE x1;
INT16LE y1;
INT16LE x2;
INT16LE y2;
UINT16LE line_color;

* '''x1''', '''y1''': The coordinates of one end point.
* '''x2''', '''y2''': The coordinates of the other end point.
* '''line_color''': The color of the line, one color from the 16-color palette in TIM 2.

==== Command 5: Play sound ====

If the command list for an animation frame includes command 5, a sound effect will be played when the particular frame is shown. It has one 16-bit parameter, the ID of the sound. TIM 2 contains sounds in two different formats. Sounds with a number >= 3000 are stored in the archive file of the game (<tt>SX_3???.RAW</tt>). .RAW files are uncompressed 8-bit PCM audio files without any header. The rest of the files (with numbers < 300) are found in <tt>TIM2.SX</tt>.
TIM 3 has <tt>.WAV</tt> files instead in the archive file an there is no <tt>TIM2.SX</tt>. ({{TODO|TIM 3 sounds with numbers below 3000}}).

== The "TAG:" chunk ==

The "<tt>TAG:</tt>" chunk contains the names of the <tt>.BMP</tt> sub-files (in the archive file of the game) required for displaying the animation. Not counting the "<tt>TAG:</tt>" chunk type identifier and the 32-bit chunk size, the first two bytes of the data contains the number of image file names in 16-bit little endian format. The remaining part of the data is the list of image file name entries. A single entry is a 16-bit image ID followed by a null-terminated string containing the name of the image. In TIM 2, the ID of the first image is always 1, however, there are exceptions to this rule in TIM 3 (but never in part graphics). There is no gap in the numbering of the images, this makes the image ID field somewhat redundant.

== The "LAB:" chunk ==

The "<tt>LAB:</tt>" chunk is present in a small number of <tt>.ANM</tt> files in TIM 3. <tt>.ANM</tt> files for puzzle parts never contain such a chunk. The structure of the "<tt>LAB:</tt>" chunk is similar to "<tt>TAG:</tt>", it consists of the number of entries stored as 16-bit integer, followed by item ID-null terminated string pairs. The strings are apparently not user interface texts visible to the player.

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)


[[Category:All file formats]]
[[Category:The Incredible Machine 2]]
[[Category:The Incredible Machine 3]]

The Incredible Machine 2-3 ANM File Format

2022-07-21T16:12:53Z

Knt47: /* Credits */ category

The '''animation''' (<tt>.ANM</tt>) sub-files are found in the [[TIM Resource Format|archive file]] of [[The Incredible Machine 2]] (TIM 2) and [[Thie Incredible Machine 3|3]] (TIM 3). They contain the information required for drawing puzzle part sprites, which are often comprised of multiple sub-images of [[The Incredible Machine Image Format|image files]] and for animations of the puzzle parts. They are also used for animated parts of the game's user interface (for example the animated icons of the main menu). It can also contain commands for playing sound effects.

Most <tt>.ANM</tt> files (all in TIM 2) contain two chunks, starting with "<tt>ANM:</tt>" and "<tt>TAG:</tt>", respectively. Both use the typical "Dynamix chunk" format, starting with the 4-byte chunk type ("<tt>ANM:</tt>"/"<tt>TAG:</tt>", followed by the chunk size in 32-bit, little endian format. Unlike other Dynamix file formats, the most significant bit in the 32-bit size of the first chunk is not set. A small number of files in TIM 3 contain a third chunk, "<tt>LAB:</tt>", with an unclear meaning.

== The "ANM:" chunk ==

Not counting the chunk type and size, an "<tt>ANM:</tt> chunk has five parts, a 16 or 22 byte header, and four sections containing the actual sprite/animation frame/animation data, labeled here as A-D.

=== Header ===

The "<tt>ANM:</tt>" chunk (not counting the "<tt>ANM:</tt>" chunk type identifier and the chunk size) starts with a header, with a size of 16 or 22 bytes, depending on the magic number. It has the following Format:

[[UINT16LE]] magic_number_1;
UINT16LE magic_number_2;
UINT16LE size_section_a;
UINT16LE size_section_b;
UINT16LE size_section_c;
UINT16LE size_section_d;
UINT16LE anm_width;
UINT16LE anm_height;
/* 3 members, found only in files with a magic number of 0x54 0x42 0xEA 0x03: */
UINT16LE unknown_16;
UINT16LE unknown_18;
UINT16LE unknown_20;

* '''magic_number_1''', '''magic_number_2''': The header starts with a 4-byte magic number. The first two bytes are always 0x54 0x42. The second two bytes are a 16-bit little endian file version number. In TIM 2, the possible values 1000 (0x3E8) or 1001 (0x3E9). There is no obvious difference in the format of the files using these two numbers, however, 0x3E9 is much more common and 0x3E8 is mostly used for relatively small and simple files. In TIM 3, a small number of files use a newer version of the <tt>.ANM</tt> file format, with a magic_number_2 value of 1002 (0x3EA). Such files have a slightly different format compared to files with the other two numbers. The "newer" format is used in the user interface and the game menu, but never for puzzle part graphics.
* '''size_section_a''': The number of entries in the A section of the "<tt>ANM:</tt>" chunk, one entry is 2 byte (i.e. the section is an array of 16-bit integers). Several files do not have an A section (size_section_a == 0)
* '''size_section_b''': The number of entries in the B section. One entry is 12 bytes in the files in files with <code>magic_number_2 = 0x3EA</code>, 10 bytes in all other files.
* '''size_section_c''': The number of entries in the C section, one entry is 4 bytes.
* '''size_section_d''': The size of the D section in bytes.
* '''anm_width''', '''anm_height''': Width and height of the animation. In <tt>.ANM</tt> files for puzzle parts, the two structure members usually have the same value as width_1 and height_1 for the part in puzzle/level files.

Structure members found only in files with the longer header (<code>magic_number_2 = 0x3EA</code>):

* '''unknown_16''': 0x14 in all files, perhaps the size of header minus magic_number_1. Files with the longer header do not contain additional section in "<tt>ANM:</tt>" chunk, so it cannot be a size of such a section.
* '''unknown_18''': 0 in all files
* '''unknown_20''': 0x17 in one file, 0 in all others. Clearly not the size of an additional section in "<tt>ANM:</tt>" chunk. {{TODO|Additional research needed}}

=== Section A ===

Section A is empty in a large number of <tt>.ANM</tt> files. If present, it is an array of 16-bit little endian integers. It contains all numbers from 0 to the number of items in B section minus 1, in increasing order, with some numbers repeated. For example <code>0 1 1 1 2</code> means that the animation frame with index 1 in section B must be shown for the duration of 3 timer ticks instead of 1.

=== Section B ===

Section B is a list of structures containing 16 bit integer members, 6 if magic_number_2 is <tt>0x3EA</tt>, 5 in the other versions of the file format. It contains essential information about each animation frame. One structure has the following members:

[[INT16LE]] relative_pos_x;
INT16LE relative_pos_y;
UINT16LE width;
UINT16LE height;
UINT16LE section_d_offset;
/* Note that the last member is only present in files with */
/* magic number 0x54 0x42 0xEA 0x03 */
UINT16LE unknown_10;

* '''relative_pos_x''', '''relative_pos_y''': The coordinates where the animation frame must be drawn, relative to other frames. For the first item in the B section, the value of both tare typically 0, however there are a few exceptions. The relative position may be negative.
* '''width''', '''height''': The width and the height of the graphics in the specific animation frame.
* '''section_d_offset''': An offset in section D, points to the first command required for drawing the animation frame.
* '''unknown_10''': The meaning is unclear. Often, but not always a number divisible by 3. {{TODO|Additional research needed}}

=== Section C ===

A section C item has the following format:

UINT16LE first_frame_id;
UINT16LE state_id;

* '''first_frame_id''': The meaning of ''first_frame_id'' is slightly different between files containing or not containing an A section. If the A section is not present, this is the index in section B for the first animation frame for a particular animation. If there is an A section, ''first_frame_id'' is an index in the A section, and the 16-bit array item at this index is the required section B index. The section B indices determined this way essentially divide the B section into sub-sectons. One sub-section corresponds to the "animation" of a puzzle part or an user interface element in one specific state. If an "animation" has only one section B item, then the puzzle part or button/icon is not animated in this state.
* '''state_id''': An internal identifier used by the game for a state of the puzzle part or an user interface element. In a specific "state", the puzzle part (or user interface element) may or may not be animated, the animation frames belonging to such a state must be determined using the first_frame_id member.

=== Section D ===

The D section contains the instructions on how to draw each animation frame (or to play a sound). The section_d_offset field in the corresponding section B entry determines where the sequence of commands start for each animation frame. There are 6 different types of commands, numbered 0-5. Each command starts with its number in a 16-bit, little endian format. For commands 2-5, this is followed by a list of 16-bit integer parameters, the number of the parameters depends on command number.

==== Command 0: End of animation frame ====

Command 0 indicates the end of an animation frame in the file. It terminates the list of commands associated with a section B item. Command 0 has no parameters and is always 2 bytes long (the 16-bit command number).

==== Command 1: End of "ANM:" chunk ====

The last two bytes of section D (and the "<tt>ANM:</tt>" chunk) are always <code>01 00</code> (1 in 16-bit little endian format). These two bytes can be interpreted as a 2-byte command that terminates section D and the entire "<tt>ANM:</tt>" chunk. Command 1 is not found anywhere else in section D.

==== Command 2: Draw BMP sub-image ====

Command 2 is an instruction for the game engine to draw a sub-image from a </tt>.BMP</tt> image stored in the archive file of the game. It should be noted that a part sprite is often "cut into" multiple </tt>.BMP</tt> sub images, and in a few cases, they are stored in more than one file. Command 2 has five 16-bit integer parameters (size is 12 bytes, including the command number).

UINT16LE command_num; /* 2 */
UINT16LE bmp_file_num;
UINT16LE bmp_sub_image_num;
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE flip;

* '''bmp_file_num''': Index of the <tt>.BMP</tt> file in the TAG: chunk. The index of the first image is 1.
* '''bmp_sub_image_num''': The "sub-image" number of the <tt>.BMP</tt> file to draw. [[The Incredible Machine Image Format|<tt>.BMP</tt> images in TIM 2]] can have multiple sub images.
* '''draw_pos_x''', '''draw_pos_y''': The position of the image (top left corner), relative to the x and y
coordinates in the corresponding section B item.
* '''flip''': The image can be drawn horizontally and/or vertically flipped relative to its original orientation. 1 = vertical flip, 2 = horizontal flip, 3 = both, 0 = no such transform is applied.

==== Command 3: Draw rectangle ====

Command 3 draws a rectangle with a border and fill color provided as arguments. It is mainly used in user interface elements and in the graphics shown in the part help screen, rarely in puzzle part graphics. It has the following format:

UINT16LE command_num; /* 3 */
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE rect_width;
UINT16LE rect_height;
UINT16LE border_color;
UINT16LE fill;

* '''draw_pos_x''', '''draw_pos_y''': Coordinates of the top left corner of the rectangle.
* '''rect_width''', '''rect_height''': The width and height of the rectangle.
* '''border_color''': The border color for the rectangle. In TIM 2, one color from the 16-color palette.
* '''fill''': The value of the ''fill'' parameter is either 0 - no fill, border only - or a value between 0x8000 and 0x800f where the least significant nibble contains the fill color.

==== Command 4: Draw line ====

Command 4 draws a line between two end points with a specific color. Like the rectangle command, it is mainly used for game interface graphics, not the puzzle parts. The format of the command is:

UINT16LE command_num; /* 4 */
INT16LE x1;
INT16LE y1;
INT16LE x2;
INT16LE y2;
UINT16LE line_color;

* '''x1''', '''y1''': The coordinates of one end point.
* '''x2''', '''y2''': The coordinates of the other end point.
* '''line_color''': The color of the line, one color from the 16-color palette in TIM 2.

==== Command 5: Play sound ====

If the command list for an animation frame includes command 5, a sound effect will be played when the particular frame is shown. It has one 16-bit parameter, the ID of the sound. TIM 2 contains sounds in two different formats. Sounds with a number >= 3000 are stored in the archive file of the game (<tt>SX_3???.RAW</tt>). .RAW files are uncompressed 8-bit PCM audio files without any header. The rest of the files (with numbers < 300) are found in <tt>TIM2.SX</tt>.
TIM 3 has <tt>.WAV</tt> files instead in the archive file an there is no <tt>TIM2.SX</tt>. ({{TODO|TIM 3 sounds with numbers below 3000}}).

== The "TAG:" chunk ==

The "<tt>TAG:</tt>" chunk contains the names of the <tt>.BMP</tt> sub-files (in the archive file of the game) required for displaying the animation. Not counting the "<tt>TAG:</tt>" chunk type identifier and the 32-bit chunk size, the first two bytes of the data contains the number of image file names in 16-bit little endian format. The remaining part of the data is the list of image file name entries. A single entry is a 16-bit image ID followed by a null-terminated string containing the name of the image. In TIM 2, the ID of the first image is always 1, however, there are exceptions to this rule in TIM 3 (but never in part graphics). There is no gap in the numbering of the images, this makes the image ID field somewhat redundant.

== The "LAB:" chunk ==

The "<tt>LAB:</tt>" chunk is present in a small number of <tt>.ANM</tt> files in TIM 3. <tt>.ANM</tt> files for puzzle parts never contain such a chunk. The structure of the "<tt>LAB:</tt>" chunk is similar to "<tt>TAG:</tt>", it consists of the number of entries stored as 16-bit integer, followed by item ID-null terminated string pairs. The strings are apparently not user interface texts visible to the player.

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)


[[Category:All file formats]]

The Incredible Machine 2-3 ANM File Format

2022-07-21T16:10:30Z

Knt47: /* Section B */

The '''animation''' (<tt>.ANM</tt>) sub-files are found in the [[TIM Resource Format|archive file]] of [[The Incredible Machine 2]] (TIM 2) and [[Thie Incredible Machine 3|3]] (TIM 3). They contain the information required for drawing puzzle part sprites, which are often comprised of multiple sub-images of [[The Incredible Machine Image Format|image files]] and for animations of the puzzle parts. They are also used for animated parts of the game's user interface (for example the animated icons of the main menu). It can also contain commands for playing sound effects.

Most <tt>.ANM</tt> files (all in TIM 2) contain two chunks, starting with "<tt>ANM:</tt>" and "<tt>TAG:</tt>", respectively. Both use the typical "Dynamix chunk" format, starting with the 4-byte chunk type ("<tt>ANM:</tt>"/"<tt>TAG:</tt>", followed by the chunk size in 32-bit, little endian format. Unlike other Dynamix file formats, the most significant bit in the 32-bit size of the first chunk is not set. A small number of files in TIM 3 contain a third chunk, "<tt>LAB:</tt>", with an unclear meaning.

== The "ANM:" chunk ==

Not counting the chunk type and size, an "<tt>ANM:</tt> chunk has five parts, a 16 or 22 byte header, and four sections containing the actual sprite/animation frame/animation data, labeled here as A-D.

=== Header ===

The "<tt>ANM:</tt>" chunk (not counting the "<tt>ANM:</tt>" chunk type identifier and the chunk size) starts with a header, with a size of 16 or 22 bytes, depending on the magic number. It has the following Format:

[[UINT16LE]] magic_number_1;
UINT16LE magic_number_2;
UINT16LE size_section_a;
UINT16LE size_section_b;
UINT16LE size_section_c;
UINT16LE size_section_d;
UINT16LE anm_width;
UINT16LE anm_height;
/* 3 members, found only in files with a magic number of 0x54 0x42 0xEA 0x03: */
UINT16LE unknown_16;
UINT16LE unknown_18;
UINT16LE unknown_20;

* '''magic_number_1''', '''magic_number_2''': The header starts with a 4-byte magic number. The first two bytes are always 0x54 0x42. The second two bytes are a 16-bit little endian file version number. In TIM 2, the possible values 1000 (0x3E8) or 1001 (0x3E9). There is no obvious difference in the format of the files using these two numbers, however, 0x3E9 is much more common and 0x3E8 is mostly used for relatively small and simple files. In TIM 3, a small number of files use a newer version of the <tt>.ANM</tt> file format, with a magic_number_2 value of 1002 (0x3EA). Such files have a slightly different format compared to files with the other two numbers. The "newer" format is used in the user interface and the game menu, but never for puzzle part graphics.
* '''size_section_a''': The number of entries in the A section of the "<tt>ANM:</tt>" chunk, one entry is 2 byte (i.e. the section is an array of 16-bit integers). Several files do not have an A section (size_section_a == 0)
* '''size_section_b''': The number of entries in the B section. One entry is 12 bytes in the files in files with <code>magic_number_2 = 0x3EA</code>, 10 bytes in all other files.
* '''size_section_c''': The number of entries in the C section, one entry is 4 bytes.
* '''size_section_d''': The size of the D section in bytes.
* '''anm_width''', '''anm_height''': Width and height of the animation. In <tt>.ANM</tt> files for puzzle parts, the two structure members usually have the same value as width_1 and height_1 for the part in puzzle/level files.

Structure members found only in files with the longer header (<code>magic_number_2 = 0x3EA</code>):

* '''unknown_16''': 0x14 in all files, perhaps the size of header minus magic_number_1. Files with the longer header do not contain additional section in "<tt>ANM:</tt>" chunk, so it cannot be a size of such a section.
* '''unknown_18''': 0 in all files
* '''unknown_20''': 0x17 in one file, 0 in all others. Clearly not the size of an additional section in "<tt>ANM:</tt>" chunk. {{TODO|Additional research needed}}

=== Section A ===

Section A is empty in a large number of <tt>.ANM</tt> files. If present, it is an array of 16-bit little endian integers. It contains all numbers from 0 to the number of items in B section minus 1, in increasing order, with some numbers repeated. For example <code>0 1 1 1 2</code> means that the animation frame with index 1 in section B must be shown for the duration of 3 timer ticks instead of 1.

=== Section B ===

Section B is a list of structures containing 16 bit integer members, 6 if magic_number_2 is <tt>0x3EA</tt>, 5 in the other versions of the file format. It contains essential information about each animation frame. One structure has the following members:

[[INT16LE]] relative_pos_x;
INT16LE relative_pos_y;
UINT16LE width;
UINT16LE height;
UINT16LE section_d_offset;
/* Note that the last member is only present in files with */
/* magic number 0x54 0x42 0xEA 0x03 */
UINT16LE unknown_10;

* '''relative_pos_x''', '''relative_pos_y''': The coordinates where the animation frame must be drawn, relative to other frames. For the first item in the B section, the value of both tare typically 0, however there are a few exceptions. The relative position may be negative.
* '''width''', '''height''': The width and the height of the graphics in the specific animation frame.
* '''section_d_offset''': An offset in section D, points to the first command required for drawing the animation frame.
* '''unknown_10''': The meaning is unclear. Often, but not always a number divisible by 3. {{TODO|Additional research needed}}

=== Section C ===

A section C item has the following format:

UINT16LE first_frame_id;
UINT16LE state_id;

* '''first_frame_id''': The meaning of ''first_frame_id'' is slightly different between files containing or not containing an A section. If the A section is not present, this is the index in section B for the first animation frame for a particular animation. If there is an A section, ''first_frame_id'' is an index in the A section, and the 16-bit array item at this index is the required section B index. The section B indices determined this way essentially divide the B section into sub-sectons. One sub-section corresponds to the "animation" of a puzzle part or an user interface element in one specific state. If an "animation" has only one section B item, then the puzzle part or button/icon is not animated in this state.
* '''state_id''': An internal identifier used by the game for a state of the puzzle part or an user interface element. In a specific "state", the puzzle part (or user interface element) may or may not be animated, the animation frames belonging to such a state must be determined using the first_frame_id member.

=== Section D ===

The D section contains the instructions on how to draw each animation frame (or to play a sound). The section_d_offset field in the corresponding section B entry determines where the sequence of commands start for each animation frame. There are 6 different types of commands, numbered 0-5. Each command starts with its number in a 16-bit, little endian format. For commands 2-5, this is followed by a list of 16-bit integer parameters, the number of the parameters depends on command number.

==== Command 0: End of animation frame ====

Command 0 indicates the end of an animation frame in the file. It terminates the list of commands associated with a section B item. Command 0 has no parameters and is always 2 bytes long (the 16-bit command number).

==== Command 1: End of "ANM:" chunk ====

The last two bytes of section D (and the "<tt>ANM:</tt>" chunk) are always <code>01 00</code> (1 in 16-bit little endian format). These two bytes can be interpreted as a 2-byte command that terminates section D and the entire "<tt>ANM:</tt>" chunk. Command 1 is not found anywhere else in section D.

==== Command 2: Draw BMP sub-image ====

Command 2 is an instruction for the game engine to draw a sub-image from a </tt>.BMP</tt> image stored in the archive file of the game. It should be noted that a part sprite is often "cut into" multiple </tt>.BMP</tt> sub images, and in a few cases, they are stored in more than one file. Command 2 has five 16-bit integer parameters (size is 12 bytes, including the command number).

UINT16LE command_num; /* 2 */
UINT16LE bmp_file_num;
UINT16LE bmp_sub_image_num;
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE flip;

* '''bmp_file_num''': Index of the <tt>.BMP</tt> file in the TAG: chunk. The index of the first image is 1.
* '''bmp_sub_image_num''': The "sub-image" number of the <tt>.BMP</tt> file to draw. [[The Incredible Machine Image Format|<tt>.BMP</tt> images in TIM 2]] can have multiple sub images.
* '''draw_pos_x''', '''draw_pos_y''': The position of the image (top left corner), relative to the x and y
coordinates in the corresponding section B item.
* '''flip''': The image can be drawn horizontally and/or vertically flipped relative to its original orientation. 1 = vertical flip, 2 = horizontal flip, 3 = both, 0 = no such transform is applied.

==== Command 3: Draw rectangle ====

Command 3 draws a rectangle with a border and fill color provided as arguments. It is mainly used in user interface elements and in the graphics shown in the part help screen, rarely in puzzle part graphics. It has the following format:

UINT16LE command_num; /* 3 */
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE rect_width;
UINT16LE rect_height;
UINT16LE border_color;
UINT16LE fill;

* '''draw_pos_x''', '''draw_pos_y''': Coordinates of the top left corner of the rectangle.
* '''rect_width''', '''rect_height''': The width and height of the rectangle.
* '''border_color''': The border color for the rectangle. In TIM 2, one color from the 16-color palette.
* '''fill''': The value of the ''fill'' parameter is either 0 - no fill, border only - or a value between 0x8000 and 0x800f where the least significant nibble contains the fill color.

==== Command 4: Draw line ====

Command 4 draws a line between two end points with a specific color. Like the rectangle command, it is mainly used for game interface graphics, not the puzzle parts. The format of the command is:

UINT16LE command_num; /* 4 */
INT16LE x1;
INT16LE y1;
INT16LE x2;
INT16LE y2;
UINT16LE line_color;

* '''x1''', '''y1''': The coordinates of one end point.
* '''x2''', '''y2''': The coordinates of the other end point.
* '''line_color''': The color of the line, one color from the 16-color palette in TIM 2.

==== Command 5: Play sound ====

If the command list for an animation frame includes command 5, a sound effect will be played when the particular frame is shown. It has one 16-bit parameter, the ID of the sound. TIM 2 contains sounds in two different formats. Sounds with a number >= 3000 are stored in the archive file of the game (<tt>SX_3???.RAW</tt>). .RAW files are uncompressed 8-bit PCM audio files without any header. The rest of the files (with numbers < 300) are found in <tt>TIM2.SX</tt>.
TIM 3 has <tt>.WAV</tt> files instead in the archive file an there is no <tt>TIM2.SX</tt>. ({{TODO|TIM 3 sounds with numbers below 3000}}).

== The "TAG:" chunk ==

The "<tt>TAG:</tt>" chunk contains the names of the <tt>.BMP</tt> sub-files (in the archive file of the game) required for displaying the animation. Not counting the "<tt>TAG:</tt>" chunk type identifier and the 32-bit chunk size, the first two bytes of the data contains the number of image file names in 16-bit little endian format. The remaining part of the data is the list of image file name entries. A single entry is a 16-bit image ID followed by a null-terminated string containing the name of the image. In TIM 2, the ID of the first image is always 1, however, there are exceptions to this rule in TIM 3 (but never in part graphics). There is no gap in the numbering of the images, this makes the image ID field somewhat redundant.

== The "LAB:" chunk ==

The "<tt>LAB:</tt>" chunk is present in a small number of <tt>.ANM</tt> files in TIM 3. <tt>.ANM</tt> files for puzzle parts never contain such a chunk. The structure of the "<tt>LAB:</tt>" chunk is similar to "<tt>TAG:</tt>", it consists of the number of entries stored as 16-bit integer, followed by item ID-null terminated string pairs. The strings are apparently not user interface texts visible to the player.

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)


[[Category:File Formats]]

The Incredible Machine 2-3 ANM File Format

2022-07-21T16:10:08Z

Knt47: credits

The '''animation''' (<tt>.ANM</tt>) sub-files are found in the [[TIM Resource Format|archive file]] of [[The Incredible Machine 2]] (TIM 2) and [[Thie Incredible Machine 3|3]] (TIM 3). They contain the information required for drawing puzzle part sprites, which are often comprised of multiple sub-images of [[The Incredible Machine Image Format|image files]] and for animations of the puzzle parts. They are also used for animated parts of the game's user interface (for example the animated icons of the main menu). It can also contain commands for playing sound effects.

Most <tt>.ANM</tt> files (all in TIM 2) contain two chunks, starting with "<tt>ANM:</tt>" and "<tt>TAG:</tt>", respectively. Both use the typical "Dynamix chunk" format, starting with the 4-byte chunk type ("<tt>ANM:</tt>"/"<tt>TAG:</tt>", followed by the chunk size in 32-bit, little endian format. Unlike other Dynamix file formats, the most significant bit in the 32-bit size of the first chunk is not set. A small number of files in TIM 3 contain a third chunk, "<tt>LAB:</tt>", with an unclear meaning.

== The "ANM:" chunk ==

Not counting the chunk type and size, an "<tt>ANM:</tt> chunk has five parts, a 16 or 22 byte header, and four sections containing the actual sprite/animation frame/animation data, labeled here as A-D.

=== Header ===

The "<tt>ANM:</tt>" chunk (not counting the "<tt>ANM:</tt>" chunk type identifier and the chunk size) starts with a header, with a size of 16 or 22 bytes, depending on the magic number. It has the following Format:

[[UINT16LE]] magic_number_1;
UINT16LE magic_number_2;
UINT16LE size_section_a;
UINT16LE size_section_b;
UINT16LE size_section_c;
UINT16LE size_section_d;
UINT16LE anm_width;
UINT16LE anm_height;
/* 3 members, found only in files with a magic number of 0x54 0x42 0xEA 0x03: */
UINT16LE unknown_16;
UINT16LE unknown_18;
UINT16LE unknown_20;

* '''magic_number_1''', '''magic_number_2''': The header starts with a 4-byte magic number. The first two bytes are always 0x54 0x42. The second two bytes are a 16-bit little endian file version number. In TIM 2, the possible values 1000 (0x3E8) or 1001 (0x3E9). There is no obvious difference in the format of the files using these two numbers, however, 0x3E9 is much more common and 0x3E8 is mostly used for relatively small and simple files. In TIM 3, a small number of files use a newer version of the <tt>.ANM</tt> file format, with a magic_number_2 value of 1002 (0x3EA). Such files have a slightly different format compared to files with the other two numbers. The "newer" format is used in the user interface and the game menu, but never for puzzle part graphics.
* '''size_section_a''': The number of entries in the A section of the "<tt>ANM:</tt>" chunk, one entry is 2 byte (i.e. the section is an array of 16-bit integers). Several files do not have an A section (size_section_a == 0)
* '''size_section_b''': The number of entries in the B section. One entry is 12 bytes in the files in files with <code>magic_number_2 = 0x3EA</code>, 10 bytes in all other files.
* '''size_section_c''': The number of entries in the C section, one entry is 4 bytes.
* '''size_section_d''': The size of the D section in bytes.
* '''anm_width''', '''anm_height''': Width and height of the animation. In <tt>.ANM</tt> files for puzzle parts, the two structure members usually have the same value as width_1 and height_1 for the part in puzzle/level files.

Structure members found only in files with the longer header (<code>magic_number_2 = 0x3EA</code>):

* '''unknown_16''': 0x14 in all files, perhaps the size of header minus magic_number_1. Files with the longer header do not contain additional section in "<tt>ANM:</tt>" chunk, so it cannot be a size of such a section.
* '''unknown_18''': 0 in all files
* '''unknown_20''': 0x17 in one file, 0 in all others. Clearly not the size of an additional section in "<tt>ANM:</tt>" chunk. {{TODO|Additional research needed}}

=== Section A ===

Section A is empty in a large number of <tt>.ANM</tt> files. If present, it is an array of 16-bit little endian integers. It contains all numbers from 0 to the number of items in B section minus 1, in increasing order, with some numbers repeated. For example <code>0 1 1 1 2</code> means that the animation frame with index 1 in section B must be shown for the duration of 3 timer ticks instead of 1.

=== Section B ===

Section B is a list of structures containing 16 bit integer members, 6 if magic_number_2 is <tt>0x3EA</tt>, 5 in the other versions of the file format. It contains essential information about each animation frame. One structure has the following members:

INT16LE relative_pos_x;
INT16LE relative_pos_y;
UINT16LE width;
UINT16LE height;
UINT16LE section_d_offset;
/* Note that the last member is only present in files with */
/* magic number 0x54 0x42 0xEA 0x03 */
UINT16LE unknown_10;

* '''relative_pos_x''', '''relative_pos_y''': The coordinates where the animation frame must be drawn, relative to other frames. For the first item in the B section, the value of both tare typically 0, however there are a few exceptions. The relative position may be negative.
* '''width''', '''height''': The width and the height of the graphics in the specific animation frame.
* '''section_d_offset''': An offset in section D, points to the first command required for drawing the animation frame.
* '''unknown_10''': The meaning is unclear. Often, but not always a number divisible by 3. {{TODO|Additional research needed}}

=== Section C ===

A section C item has the following format:

UINT16LE first_frame_id;
UINT16LE state_id;

* '''first_frame_id''': The meaning of ''first_frame_id'' is slightly different between files containing or not containing an A section. If the A section is not present, this is the index in section B for the first animation frame for a particular animation. If there is an A section, ''first_frame_id'' is an index in the A section, and the 16-bit array item at this index is the required section B index. The section B indices determined this way essentially divide the B section into sub-sectons. One sub-section corresponds to the "animation" of a puzzle part or an user interface element in one specific state. If an "animation" has only one section B item, then the puzzle part or button/icon is not animated in this state.
* '''state_id''': An internal identifier used by the game for a state of the puzzle part or an user interface element. In a specific "state", the puzzle part (or user interface element) may or may not be animated, the animation frames belonging to such a state must be determined using the first_frame_id member.

=== Section D ===

The D section contains the instructions on how to draw each animation frame (or to play a sound). The section_d_offset field in the corresponding section B entry determines where the sequence of commands start for each animation frame. There are 6 different types of commands, numbered 0-5. Each command starts with its number in a 16-bit, little endian format. For commands 2-5, this is followed by a list of 16-bit integer parameters, the number of the parameters depends on command number.

==== Command 0: End of animation frame ====

Command 0 indicates the end of an animation frame in the file. It terminates the list of commands associated with a section B item. Command 0 has no parameters and is always 2 bytes long (the 16-bit command number).

==== Command 1: End of "ANM:" chunk ====

The last two bytes of section D (and the "<tt>ANM:</tt>" chunk) are always <code>01 00</code> (1 in 16-bit little endian format). These two bytes can be interpreted as a 2-byte command that terminates section D and the entire "<tt>ANM:</tt>" chunk. Command 1 is not found anywhere else in section D.

==== Command 2: Draw BMP sub-image ====

Command 2 is an instruction for the game engine to draw a sub-image from a </tt>.BMP</tt> image stored in the archive file of the game. It should be noted that a part sprite is often "cut into" multiple </tt>.BMP</tt> sub images, and in a few cases, they are stored in more than one file. Command 2 has five 16-bit integer parameters (size is 12 bytes, including the command number).

UINT16LE command_num; /* 2 */
UINT16LE bmp_file_num;
UINT16LE bmp_sub_image_num;
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE flip;

* '''bmp_file_num''': Index of the <tt>.BMP</tt> file in the TAG: chunk. The index of the first image is 1.
* '''bmp_sub_image_num''': The "sub-image" number of the <tt>.BMP</tt> file to draw. [[The Incredible Machine Image Format|<tt>.BMP</tt> images in TIM 2]] can have multiple sub images.
* '''draw_pos_x''', '''draw_pos_y''': The position of the image (top left corner), relative to the x and y
coordinates in the corresponding section B item.
* '''flip''': The image can be drawn horizontally and/or vertically flipped relative to its original orientation. 1 = vertical flip, 2 = horizontal flip, 3 = both, 0 = no such transform is applied.

==== Command 3: Draw rectangle ====

Command 3 draws a rectangle with a border and fill color provided as arguments. It is mainly used in user interface elements and in the graphics shown in the part help screen, rarely in puzzle part graphics. It has the following format:

UINT16LE command_num; /* 3 */
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE rect_width;
UINT16LE rect_height;
UINT16LE border_color;
UINT16LE fill;

* '''draw_pos_x''', '''draw_pos_y''': Coordinates of the top left corner of the rectangle.
* '''rect_width''', '''rect_height''': The width and height of the rectangle.
* '''border_color''': The border color for the rectangle. In TIM 2, one color from the 16-color palette.
* '''fill''': The value of the ''fill'' parameter is either 0 - no fill, border only - or a value between 0x8000 and 0x800f where the least significant nibble contains the fill color.

==== Command 4: Draw line ====

Command 4 draws a line between two end points with a specific color. Like the rectangle command, it is mainly used for game interface graphics, not the puzzle parts. The format of the command is:

UINT16LE command_num; /* 4 */
INT16LE x1;
INT16LE y1;
INT16LE x2;
INT16LE y2;
UINT16LE line_color;

* '''x1''', '''y1''': The coordinates of one end point.
* '''x2''', '''y2''': The coordinates of the other end point.
* '''line_color''': The color of the line, one color from the 16-color palette in TIM 2.

==== Command 5: Play sound ====

If the command list for an animation frame includes command 5, a sound effect will be played when the particular frame is shown. It has one 16-bit parameter, the ID of the sound. TIM 2 contains sounds in two different formats. Sounds with a number >= 3000 are stored in the archive file of the game (<tt>SX_3???.RAW</tt>). .RAW files are uncompressed 8-bit PCM audio files without any header. The rest of the files (with numbers < 300) are found in <tt>TIM2.SX</tt>.
TIM 3 has <tt>.WAV</tt> files instead in the archive file an there is no <tt>TIM2.SX</tt>. ({{TODO|TIM 3 sounds with numbers below 3000}}).

== The "TAG:" chunk ==

The "<tt>TAG:</tt>" chunk contains the names of the <tt>.BMP</tt> sub-files (in the archive file of the game) required for displaying the animation. Not counting the "<tt>TAG:</tt>" chunk type identifier and the 32-bit chunk size, the first two bytes of the data contains the number of image file names in 16-bit little endian format. The remaining part of the data is the list of image file name entries. A single entry is a 16-bit image ID followed by a null-terminated string containing the name of the image. In TIM 2, the ID of the first image is always 1, however, there are exceptions to this rule in TIM 3 (but never in part graphics). There is no gap in the numbering of the images, this makes the image ID field somewhat redundant.

== The "LAB:" chunk ==

The "<tt>LAB:</tt>" chunk is present in a small number of <tt>.ANM</tt> files in TIM 3. <tt>.ANM</tt> files for puzzle parts never contain such a chunk. The structure of the "<tt>LAB:</tt>" chunk is similar to "<tt>TAG:</tt>", it consists of the number of entries stored as 16-bit integer, followed by item ID-null terminated string pairs. The strings are apparently not user interface texts visible to the player.

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)


[[Category:File Formats]]

The Incredible Machine 2-3 ANM File Format

2022-07-21T16:01:15Z

Knt47: additional information

The '''animation''' (<tt>.ANM</tt>) sub-files are found in the [[TIM Resource Format|archive file]] of [[The Incredible Machine 2]] (TIM 2) and [[Thie Incredible Machine 3|3]] (TIM 3). They contain the information required for drawing puzzle part sprites, which are often comprised of multiple sub-images of [[The Incredible Machine Image Format|image files]] and for animations of the puzzle parts. They are also used for animated parts of the game's user interface (for example the animated icons of the main menu). It can also contain commands for playing sound effects.

Most <tt>.ANM</tt> files (all in TIM 2) contain two chunks, starting with "<tt>ANM:</tt>" and "<tt>TAG:</tt>", respectively. Both use the typical "Dynamix chunk" format, starting with the 4-byte chunk type ("<tt>ANM:</tt>"/"<tt>TAG:</tt>", followed by the chunk size in 32-bit, little endian format. Unlike other Dynamix file formats, the most significant bit in the 32-bit size of the first chunk is not set. A small number of files in TIM 3 contain a third chunk, "<tt>LAB:</tt>", with an unclear meaning.

== The "ANM:" chunk ==

Not counting the chunk type and size, an "<tt>ANM:</tt> chunk has five parts, a 16 or 22 byte header, and four sections containing the actual sprite/animation frame/animation data, labeled here as A-D.

=== Header ===

The "<tt>ANM:</tt>" chunk (not counting the "<tt>ANM:</tt>" chunk type identifier and the chunk size) starts with a header, with a size of 16 or 22 bytes, depending on the magic number. It has the following Format:

[[UINT16LE]] magic_number_1;
UINT16LE magic_number_2;
UINT16LE size_section_a;
UINT16LE size_section_b;
UINT16LE size_section_c;
UINT16LE size_section_d;
UINT16LE anm_width;
UINT16LE anm_height;
/* 3 members, found only in files with a magic number of 0x54 0x42 0xEA 0x03: */
UINT16LE unknown_16;
UINT16LE unknown_18;
UINT16LE unknown_20;

* '''magic_number_1''', '''magic_number_2''': The header starts with a 4-byte magic number. The first two bytes are always 0x54 0x42. The second two bytes are a 16-bit little endian file version number. In TIM 2, the possible values 1000 (0x3E8) or 1001 (0x3E9). There is no obvious difference in the format of the files using these two numbers, however, 0x3E9 is much more common and 0x3E8 is mostly used for relatively small and simple files. In TIM 3, a small number of files use a newer version of the <tt>.ANM</tt> file format, with a magic_number_2 value of 1002 (0x3EA). Such files have a slightly different format compared to files with the other two numbers. The "newer" format is used in the user interface and the game menu, but never for puzzle part graphics.
* '''size_section_a''': The number of entries in the A section of the "<tt>ANM:</tt>" chunk, one entry is 2 byte (i.e. the section is an array of 16-bit integers). Several files do not have an A section (size_section_a == 0)
* '''size_section_b''': The number of entries in the B section. One entry is 12 bytes in the files in files with <code>magic_number_2 = 0x3EA</code>, 10 bytes in all other files.
* '''size_section_c''': The number of entries in the C section, one entry is 4 bytes.
* '''size_section_d''': The size of the D section in bytes.
* '''anm_width''', '''anm_height''': Width and height of the animation. In <tt>.ANM</tt> files for puzzle parts, the two structure members usually have the same value as width_1 and height_1 for the part in puzzle/level files.

Structure members found only in files with the longer header (<code>magic_number_2 = 0x3EA</code>):

* '''unknown_16''': 0x14 in all files, perhaps the size of header minus magic_number_1. Files with the longer header do not contain additional section in "ANM:" chunk, so it cannot be a size of such a section.
* '''unknown_18''': 0 in all files
* '''unknown_20''': 0x17 in one file, 0 in all others. Clearly not the size of an additional section in "<tt>ANM:</tt>" chunk. {{TODO|Additional research needed}}

=== Section A ===

Section A is empty in a large number of <tt>.ANM</tt> files. If present, it is an array of 16-bit little endian integers. It contains all numbers from 0 to the number of items in B section minus 1, in increasing order, with some numbers repeated. For example <code>0 1 1 1 2</code> means that the animation frame with index 1 in section B must be shown for the duration of 3 timer ticks instead of 1.

=== Section B ===

Section B is a list of structures containing 16 bit integer members, 6 if magic_number_2 is <tt>0x3EA</tt>, 5 in the other versions of the file format. It contains essential information about each animation frame. One structure has the following members:

INT16LE relative_pos_x;
INT16LE relative_pos_y;
UINT16LE width;
UINT16LE height;
UINT16LE section_d_offset;
/* Note that the last member is only present in files with */
/* magic number 0x54 0x42 0xEA 0x03 */
UINT16LE unknown_10;

* '''relative_pos_x''', '''relative_pos_y''': The coordinates where the animation frame must be drawn, relative to other frames. For the first item in the B section, the value of both tare typically 0, however there are a few exceptions. The relative position may be negative.
* '''width''', '''height''': The width and the height of the graphics in the specific animation frame.
* '''section_d_offset''': An offset in section D, points to the first command required for drawing the animation frame.
* '''unknown_10''': The meaning is unclear. Often, but not always a number divisible by 3. {{TODO|Additional research needed}}

=== Section C ===

A section C item has the following format:

UINT16LE first_frame_id;
UINT16LE state_id;

* '''first_frame_id''': The meaning of ''first_frame_id'' is slightly different between files containing or not containing an A section. If the A section is not present, this is the index in section B for the first animation frame for a particular animation. If there is an A section, ''first_frame_id'' is an index in the A section, and the 16-bit array item at this index is the required section B index. The section B indices determined this way essentially divide the B section into sub-sectons. One sub-section corresponds to the "animation" of a puzzle part or an user interface element in one specific state. If an "animation" has only one section B item, then the puzzle part or button/icon is not animated in this state.
* '''state_id''': An internal identifier used by the game for a state of the puzzle part or an user interface element. In a specific "state", the puzzle part (or user interface element) may or may not be animated, the animation frames belonging to such a state must be determined using the first_frame_id member.

=== Section D ===

The D section contains the instructions on how to draw each animation frame (or to play a sound). The section_d_offset field in the corresponding section B entry determines where the sequence of commands start for each animation frame. There are 6 different types of commands, numbered 0-5. Each command starts with its number in a 16-bit, little endian format. For commands 2-5, this is followed by a list of 16-bit integer parameters, the number of the parameters depends on command number.

==== Command 0: End of animation frame ====

Command 0 indicates the end of an animation frame in the file. It terminates the list of commands associated with a section B item. Command 0 has no parameters and is always 2 bytes long (the 16-bit command number).

==== Command 1: End of "ANM:" chunk ====

The last two bytes of section D (and the "<tt>ANM:</tt>" chunk) are always 01 00 (1 in 16-bit little endian format). These two bytes can be interpreted as a 2-byte command that terminates section D and the entire "<tt>ANM:</tt>" chunk. Command 1 is not found anywhere else in section D.

==== Command 2: Draw BMP sub-image ====

Command 2 is an instruction for the game engine to draw a sub-image from a </tt>.BMP</tt> image stored in the archive file of the game. It should be noted that a part sprite is often "cut into" multiple </tt>.BMP</tt> sub images, and in a few cases, they are stored in more than one file. Command 2 has five 16-bit integer parameters (size is 12 bytes, including the command number).

UINT16LE command_num; /* 2 */
UINT16LE bmp_file_num;
UINT16LE bmp_sub_image_num;
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE flip;

* '''bmp_file_num''': Index of the <tt>.BMP</tt> file in the TAG: chunk. The index of the first image is 1.
* '''bmp_sub_image_num''': The "sub-image" number of the <tt>.BMP</tt> file to draw. [[The Incredible Machine Image Format|<tt>.BMP</tt> images in TIM 2]] can have multiple sub images.
* '''draw_pos_x''', '''draw_pos_y''': The position of the image (top left corner), relative to the x and y
coordinates in the corresponding section B item.
* '''flip''': The image can be drawn horizontally and/or vertically flipped relative to its original orientation. 1 = vertical flip, 2 = horizontal flip, 3 = both, 0 = no such transform is applied.

==== Command 3: Draw rectangle ====

Command 3 draws a rectangle with a border and fill color provided as arguments. It is mainly used in user interface elements and in the graphics shown in the part help screen, rarely in puzzle part graphics. It has the following format:

UINT16LE command_num; /* 3 */
INT16LE draw_pos_x;
INT16LE draw_pos_y;
UINT16LE rect_width;
UINT16LE rect_height;
UINT16LE border_color;
UINT16LE fill;

* '''draw_pos_x''', '''draw_pos_y''': Coordinates of the top left corner of the rectangle.
* '''rect_width''', '''rect_height''': The width and height of the rectangle.
* '''border_color''': The border color for the rectangle. In TIM 2, one color from the 16-color palette.
* '''fill''': The value of the ''fill'' parameter is either 0 - no fill, border only - or a value between 0x8000 and 0x800f where the least significant nibble contains the fill color.

==== Command 4: Draw line ====

Command 4 draws a line between two end points with a specific color. Like the rectangle command, it is mainly used for game interface graphics, not the puzzle parts. The format of the command is:

UINT16LE command_num; /* 4 */
INT16LE x1;
INT16LE y1;
INT16LE x2;
INT16LE y2;
UINT16LE line_color;

* '''x1''', '''y1''': The coordinates of one end point.
* '''x2''', '''y2''': The coordinates of the other end point.
* '''line_color''': The color of the line, one color from the 16-color palette in TIM 2.

==== Command 5: Play sound ====

If the command list for an animation frame includes command 5, a sound effect will be played when the particular frame is shown. It has one 16-bit parameter, the ID of the sound. TIM 2 contains sounds in two different formats. Sounds with a number >= 3000 are stored in the archive file of the game (<tt>SX_3???.RAW</tt>). RAW files are uncompressed 8-bit PCM audio files without any header. The rest of the files (with numbers < 300) are found in <tt>TIM2.SX</tt>.
TIM 3 has <tt>.WAV</tt> files instead in the archive file an there is no <tt>TIM2.SX</tt>. ({{TODO|TIM 3 sounds with numbers below 3000}}).

== The "TAG:" chunk ==

The "<tt>TAG:</tt>" chunk contains the names of the <tt>.BMP</tt> sub-files (in the archive file of the game) required for displaying the animation. Not counting the "<tt>TAG:</tt>" chunk type identifier and the 32-bit chunk size, the first two bytes of the data contains the number of image file names in 16-bit little endian format. The remaining part of the data is the list of image file name entries. A single entry is a 16-bit image ID followed by a null-terminated string containing the name of the image. In TIM 2, the ID of the first image is always 1, however, there are exceptions to this rule in TIM 3 (but never in part graphics). There is no gap in the numbering of the images, this makes the image ID field somewhat redundant.

== The "LAB:" chunk ==

The "<tt>LAB:</tt>" chunk is present in a small number of <tt>.ANM</tt> files in TIM 3. <tt>.ANM</tt> files for puzzle parts never contain such a chunk. The structure of the "<tt>LAB:</tt>" chunk is similar to "<tt>TAG:</tt>", it consists of the number of entries stored as 16-bit integer, followed by item ID-null terminated string pairs. The strings are apparently not user interface texts visible to the player.

{{TODO|This is a work in progress}}


[[Category:File Formats]]

The Incredible Machine 2-3 ANM File Format

2022-07-21T15:45:34Z

Knt47: Created page with " The '''animation''' (<tt>.ANM</tt>) sub-files are found in the archive file of The Incredible Machine 2 (TIM 2) and [[Thie Incredible Machine 3|3]..."

The Incredible Machine Level Format

2022-07-21T15:28:59Z

Knt47: /* Puzzle part data */

{{Map Infobox
| Type =
| Layers =
| Tile size = Not tile based, the game uses a 16x16 grid for walls and a few other puzzle parts
| Viewport =
'''576×368''' (Levels in [[The Incredible Machine]] (TIM) and [[The Even More Incredible Machine]] (TEMIM))
'''640×400''' (.GKC files in TIM and TEMIM)
'''560×377''' (Levels in [[The Incredible Machine 2]] and 3)
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|The Incredible Machine 3}}
}}

This page discusses the '''level format''' of [[The Incredible Machine]], from the first DOS version (abbreviated as TIM 1) to [[The Incredible Machine 3|TIM 3]] (which is a 32-bit Windows game). Even if the format of some sections of the file vary significantly between the versions, the way how the parts are stored is highly similar.

The machines/puzzles saved from the "freeform machine" mode or the built-in level editor are also discussed here. The format of files saved from built-in editor may be identical to or slightly different from the levels, depending on the game version. The animated '''"title screen"''' (<tt>TITLE.GKC</tt>) and '''"credits screen"''' (<tt>CREDITS.GKC</tt>) files (inside the archive file) in TIM 1 and [[The Even More Incredible Machine]] (TEMIM) use a variant of the level file format, even if these are not playable levels.

== Magic number ==

TIM-TIM 3 level and GKC files always start with a 4-byte magic number. The following table summarizes the magic numbers found in various versions of the game.

{| class="wikitable"
! Magic number (hex) !! Usage in game versions
|-
| <code>ED AC 00 01</code>
|
* Puzzles in TIM demo version.
|-
| <code>ED AC 02 01</code>
|
* Puzzles in TIM.
* Saved freeform machines in TIM.
* GKC files in TIM.
* <tt>CREDITS.GKC</tt> in TEMIM.
|-
| <code>EE AC 05 01</code>
|
* New puzzles in TEMIM not found in TIM.
* Saved freeform machines in TEMIM.
* <tt>TITLE.GKC</tt> in TEMIM.
|-
| <code>EF AC 11 01</code>
<code>EF AC 12 01</code>
|
* A small number of puzzles in TIM 2 and 3.
|-
| <code>EF AC 13 01</code>
|
* The large majority of puzzles in TIM 2 and 3.
* Puzzles saved from the built-in editor of TIM 2.
|-
| <code>EF AC 14 01</code>
|
* A small number of puzzles in TIM 3.
* Puzzles saved from the built-in editor of TIM 3.
|}

== Structure of puzzle and GKC files ==

The level/puzzle/saved machine files consist of multiple sections. An overview of the file structure is provided below, separately for TIM / TEMIM and TIM 2 / TIM 3.

=== TIM and TEMIM ===

* Magic number, see above
* Puzzle title, null-terminated string. missing in .GKC files and "freeform machines" saved by the player.
* Goal description, null-terminated string. Absent from .GKC files and "saved freeform machines" with magic number of <code>ED AC 02 01</code>. Present in TEMIM "saved freeform machines" (magic number <code>EE AC 05 01</code>). An empty string in .GKC files with magic number <code>EE AC 05 01</code>.
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move ("fixed", e.g. walls) and are not found initially to the parts bin.
* List of part entry structures for parts that can move (e.g. balls), not in the parts bin.
* An additional 16-bit, little endian integer value in puzzles with magic number of <code>EE AC 05 01</code>. The meaning of this value is unclear. 0 in puzzles from the game archive file. In saved freeform machines, 1 if there are parts placed into the parts bin, 0 otherwise.
* List of part entry structures for parts initially placed into the parts bin.

=== TIM 2 and 3 ===

* Magic number, see above
* Two additional "header" bytes in files with magic number <code>EF AC 13 01</code> or <code>EF AC 14 01</code>. First byte is always 0, second is the background color from the 16-color palette.
* Puzzle title, null-terminated string
* Goal description, null-terminated string
* Hints, see below
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move
* List of part entry structures for parts that can move
* Solution information, see below

== Hints ==

Hints are supported only in TIM 2 and 3 puzzles. The first two bytes of the hint data contain the number of the hints in 16-bit little endian format. This is followed by 8 hint entries, some of them may be unused. A size of an unused entry is 7 bytes. One entry consists of three 16-bit integers and a null-terminated string containing the hint text. The three integer members are (all have a 16-bit little endian format):

* '''position_x''': The X position of the hand icon for the hint.
* '''position_y''': The Y position.
* '''hint_icon_flip''': The hand icon of a hint can be flipped and can have four different orientations. Possible values are 0-3.

In TIM 2, there are 3 (?) puzzles with magic number <code>EF AC 11 01</code>. Neither of these files contain hints. However, the size of the empty hints section is 42 bytes in them instead of the expected 58.

== Puzzle information data structure ==

=== In TIM and TEMIM ===

In TIM and TEMIM, there are two different puzzle header information data structures, one is used by the puzzles, and the another is found in saved "freeform" machines and the GKC files.

The information structure format in TIM / TEMIM puzzles:

[[UINT16LE]] bonus_1;
UINT16LE bonus_2;
[[INT16LE]] pressure;
INT16LE gravity;
INT16LE unknown_8;
INT16LE unknown_10;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

The information structure format in saved "freeform" machines and GKC files:

INT16LE pressure;
INT16LE gravity;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

* '''bonus_1''': The value of "Bonus 1" immediately after the puzzle is loaded (its value is constantly decreasing while the player is solving the puzzle).
* '''bonus_2''': The value of "Bonus 2" for the puzzle.
* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''unknown_8''', ''unknown_10'': The value of these two members is always -8. Perhaps the top left corner of the screen in the coordinate system used for puzzle parts, which is also (-8, -8).
* '''music''': ID of music track played. Valid values are 1001-1016 for TIM and 1001-1021 for TEMIM.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move (e.g. walls), not in the "parts bin".
* '''num_parts_moving''': Number of parts in the puzzles that move (e.g. balls), not in the "parts bin".
* '''num_parts_in_partsbin''': The number of parts that are placed into the parts bin. (The player needs to position them in order to solve the puzzle.)

=== In TIM 2 and 3 ===

The information structure format in TIM 2 and 3:

INT16LE pressure;
INT16LE gravity;
UINT16LE unknown_4;
UINT16LE unknown_6;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE unknown_14;

* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''music''': ID of music track played. Valid values are 1000-1023.
* '''unknown_4''', '''unknown_6''': Meaning is unknown, always 0.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move, regardless of whether they are placed initially into the parts bin or not.
* '''num_parts_moving''': Number of parts in the puzzles that can move.
* '''unknown_14''': Value is always 0. Likely this member corresponds to num_parts_in_partsbin in TIM/TEMIM puzzle header. However, parts found in the parts bin are not a separate section in TIM 2 / 3,

== Puzzle part data ==

As already discussed in the With the exception of TIM demo version (see below), the size of a part entry for the majority of puzzle parts is 48 bytes. However, there are exceptions, which are discussed in separate sub-sections. The format of the "default" part entry:

UINT16LE part_type_num;
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
[[BYTE]] belt_connect_pos_x;
BYTE belt_connect_pos_y;
UINT16LE belt_line_distance;
UINT16LE unknown_32;
BYTE rope_1_connect_pos_x;
BYTE rope_1_connect_pos_y;
UINT16LE unknown_36;
BYTE rope_2_connect_pos_x;
BYTE rope_2_connect_pos_y;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''part_type_num''': A number associated with the type of the part (e.g. 0 - bowling ball). Required for identifying parts with an entry size different from the default. See [[The Incredible Machine Level Format/Part Numbers]]
* '''flags_1''': A combination of flag bits.
** '''TIM''' / '''TEMIM''' uses the following flag bits:
*** <code>0x20</code>: Unknown meaning, used for a few "moving" parts (bucket, candle)
*** <code>0x40</code>: Set if the part is a wall.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x800</code>: Part is placed initially into the parts bin (see num_parts_in_partsbin in part information data structure)
*** <code>0x1000</code>: "Moving" part, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x2000</code>: Part cannot move, in fixed position, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x4000</code>: Part cannot move, in fixed position (see ''num_parts_fixed'')
*** <code>0x8000</code>: Set when 0x800 is not set ({{TODO|further testing needed}})
** In '''TIM 2 / 3''', the bits have a known meaning:
*** <code>0x40</code>: Meaning unclear, used for "moving" parts only, but not always set, even for a single type of part.***
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x1000</code>: "Moving" part, affected by gravity.
*** <code>0x2000</code>, 0x4000: Used in combination for parts that do not move and are not affected by gravity.
* '''flags_2''': Another word containing flag bits. The meaning of most flags is the same in all game versions.
** <code>0x1</code>: A belt can be connected to the part.
** <code>0x2</code>: A belt is connected to the part.
** <code>0x4</code>: A rope can be connected to the part.
** <code>0x8</code>: A second rope can be connected to the part (teeter-totter)
** <code>0x10</code>: The part sprite is drawn horizontally flipped.
** <code>0x20</code>: The part sprite is drawn vertically flipped. Note on flip flags: Flipping a part in the game does not necessarily mean that one of the flip flags will be changed. For several parts, especially in TIM 2 / 3, flipping will affect the value of the ''appearance'' member.
** <code>0x40</code>: Probably unused
** <code>0x80</code>: Part can be stretched in at least one direction: inclines, conveyor belt, walls.
** <code>0x100</code>: Parts that can be stretched both horizontally and vertically, the walls.
* '''flags_3''': Some flags are only present in TIM 2 / 3. This member of the part data structure is missing in the demo version of TIM.
** <code>0x1</code>: The part can be plugged into an electric outlet.
** <code>0x2</code>: The part is an electric outlet.
** <code>0x4</code>: The part can burn (e.g. candle) or has a fuse that can be lit (e.g. dynamite, cannon). Usually in combination with flag 0x8.
** <code>0x8</code>: Meaning of this flag is unclear. Used for several part types, but changing it has no apparent consequence (?)
** Flags present only in '''TIM 2 / 3''':
*** <code>0x40</code>: Part is "locked", i.e not placed into the part bin.
*** <code>0x80</code>: Sizable scenery part (?)
*** <code>0x100</code>: {{TODO|unknown meaning}}
*** <code>0x400</code>: A "program" icon is shown for the part (?)
*** <code>0x1000</code>: Scenery part
*** <code>0x2000</code>: Wall part (?)
*** <code>0x8000</code>: A "Puzzle solution" icon is shown for the part (?)
* '''appearance''': An identifier for the sprite that is shown for a part before the machine is started. (Once the machine is started, the state of the part can change and so can the sprite shown.) The meaning is different between TIM and TIM 2. In TIM, the sprite of some parts consists of only one image, in this case, this is often the number of the sub-image in the image resource file. ({{TODO|For other parts, this is probably an internal identifier for the sprite (?)}}). In TIM 2 and 3, the meaning of the appearance is an index in the A section of the [[The Incredible Machine 2-3 ANM File Format|.ANM file]] for the part, or if this is absent, an index in the B section. "Programming" a part in TIM 2 and 3 often results in the change of this field.
* '''unknown_10''': Probably unused, usually 0.
* '''width_1''', '''height_1''': The width and height of the selectable area of the part ({{TODO|more reverse engineering work needed}})
* '''width_2''', '''height_2''': At least in TIM 2, witdh_2 is used for calculating the position of part sprite when the part is flipped because of the horizontal flip bit is set in flags_2.
* '''pos_x''', '''pos_y''': The position of the part, usually the top left corner of the bounding rectangle.
* '''behavior''': In TIM 2 and 3, a programmed behavior of the part. (However, for many parts, "programming" modifies the ''appearance'' member.) For example the number of shots of the phazer gun or character shown by the message computer. Meaning is different for rope parts, see below. Unused in TIM and TEMIM (except for ropes).
* '''unknown_26''': Probably unused, usually 0. Note that belt parts have a value of 1 in this position.
* '''belt_connect_pos_x''', '''belt_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Always positive or 0, because ''pos_x'' and ''pos_y'' are the coordinates of the top left corner where the sprite starts. Note that the formulas required for calculating the exact position of the belt are slightly different between TIM and TIM 2. Parts for which connection of a belt is allowed have a distinct circular area in their sprite, corresponding to the location where the belt is connected. In TIM / TEMIM, ''belt_connect_pos_x'' and ''belt_connect_pos_y'' is approximately the top left corner of its bounding rectangle, while in TIM 2 /3 it is close to the center of the circle.
* '''unknown_36''': Probably unused, usually 0.
* '''belt_line_distance''': The belts in the game appear as two, usually not perfectly parallel black (TIM / TEMIM) or gray (TIM 2 / 3) lines. This parameter determines the distance between the two segments, More precisely, it is either approximately the diameter of the circular area mentioned at ''belt_connect_pos_x'' and ''belt_connect_pos_y'' (TIM / TEMIM) or its radius (TIM 2 / 3).
* '''unknown_32''': Probably unused, usually 0.
* '''rope_1_connect_pos_x''', '''rope_1_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Similarly to belt_connect_pos_x/y, always positive or 0.
* '''rope_2_connect_pos_x''', '''rope_2_connect_pos_y''': The same as ''rope_1_connect_pos_x'', ''rope_1_connect_pos_y'', bit for another connected rope part.
* '''connected_1''', '''connected_2''': The index of one or two parts in the puzzle that are connected to this part with a rope. If the rope runs through pulleys, this is the part index of the first pulley. If no rope is connected or this is not possible for the part, the value of both structure members are -1. (Of course, if one rope is connected, the value of one structure member (usually connected_rope_1) is the index of the rope part and the other is -1) )In TIM 2 and 3, the "remote bomb" part actually corresponds to two entries in the puzzle file. The connected_rope_2 field contains the index of the another "element" of the bomb, in both entries.
* '''outlet_plugged_1''', '''outlet_plugged_2''': These structure members are only meaningful for electric outlet parts. Electric outlets always have 2 "sockets" for parts requiring electricity. It contains the index/indices of the part/parts plugged into the electric outlet, or -1 if the "socket" is free. If the part does not support this, both values are -1.

=== Belts ===

Belt parts (part 8) (except in the demo version of TIM, see below) use a 52-byte entry, with the following format:

UINT16LE part_type_num; /* 8 for belts */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
INT16LE belt_connected_part_1;
INT16LE belt_connected_part_2;
UINT16LE unknown_36;
UINT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0</code>, <code>flags_3 = 0</code>
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0</code>, <code>flags_3 = 0x40</code> (or <code>0</code> if in parts bin)
* '''appearance''': Always 0, belts have no true sprite (represented by two lines).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for belts, always 0.
* '''pos_x''', '''pos_y''' In TIM / TEMIM, either 0 or -1. In TIM 2, -1 or -100 (0xff9c). Meaning of these numbers is unclear, and the usage of the two different values do not correlate with the flags.
* '''behavior''': Not used, always 0.
* '''unknown_26''': Always 1, perhaps indicates that the part is a belt.
* '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''belt_connected_part_1''', '''belt_connected_part_2''': Index of the two parts in the puzzle connected by this belt. In TIM and TEMIM, both are -1 if the belt is placed into the parts bin.
* '''unknown_36''', '''unknown_38''', '''unknown_40''', '''unknown_42''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Ropes ===

Rope parts (part 10) (except in the demo version of TIM, see below) use a 54-byte entry. TIM 2 and 3 also have a "steel cable" part (part 76) which also behaves as a rope and the size of the part entry is also identical. The rope part entry has the following format:

UINT16LE part_type_num; /* 10 for rope, 76 for steel cable */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE rope_segment_length;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
UINT16LE unknown_36;
INT16LE rope_connected_part_1;
INT16LE rope_connected_part_2;
BYTE part_1_connect_field_usage;
BYTE part_2_connect_field_usage;
UINT16LE unknown_44;
UINT16LE unknown_46;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''': Same flags used as in the belt part structure.
* '''appearance''': Always 0, ropes have no true sprite (represented by one or more line segments).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for ropes, always 0.
* '''pos_x''', '''pos_y''': Similarly to belts, possible values are 0 and -1 in TIM / TEMIM; and -1 and -100 in TIM 2 / 3.
* '''rope_segment_length''': The length of the rope (Euclidean distance between the two ends) if the rope does not run through pulleys. Otherwise, the length of the rope segment between the part at one end (rope_connected_part_1 (?)) and the first pulley ({{TODO|additional testing needed}}).
* '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for pulleys.
* '''unknown_36''': Not used, always 0.
* '''rope_connected_part_1''', '''rope_connected_part_2''': Index of the two parts in the puzzle connected by this rope (never the pulleys). In TIM and TEMIM, both are -1 if the rope is placed into the parts bin.
* '''part_1_connect_field_usage''', '''part_2_connect_field_usage''': Whether ''connected_1'' or ''connected_2'' is used in the two connected parts for this rope. 0 if connected_1, 1 if connected_2. ({{TODO|additional testing needed}})
* '''unknown_44''', '''unknown_46''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Pulleys ===

The format of the 56-byte puzzle part entry for the pulley (part 7):

UINT16LE part_type_num; /* 7 for pulley */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
BYTE pulley_rope_1_connect_pos_x;
BYTE pulley_rope_1_connect_pos_y;
INT16LE unknown_36;
INT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
BYTE pulley_rope_2_connect_pos_x;
BYTE pulley_rope_2_connect_pos_y;
INT16LE pulley_connected_1;
INT16LE pulley_connected_2;
INT16LE unknown_50;
INT16LE unknown_52;
INT16LE rope_index;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0x4</code>, <code>flags_3 = 0x8</code> (<code>0x0</code> {{TODO|in some cases}})
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0x4</code>, <code>flags_3 = 0x48</code> (or <code>0x8</code> if in parts bin)
* '''appearance''': Pulleys can have four different sprites depending on the orientation. Possible values are 0-3.
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': The size of the pulley sprite. In TIM 2 / 3, also depends on the orientation.
* '''pos_x''', '''pos_y''': The position of the pulley, top left coordinates of the bounding rectangle.
* '''behavior''', '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for ropes.
* '''pulley_rope_1_connect_pos_x''', '''pulley_rope_1_connect_pos_y''': The coordinates of the point where one rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''. Depends on the orientation of the pulley, like ''appearance''.
* '''unknown_36''', '''unknown_38''': Not used, always -1.
* '''unknown_40'', ''unknown_42''': Not used, always 0.
* '''pulley_rope_2_connect_pos_x''', '''pulley_rope_2_connect_pos_y''': The coordinates of the point where the other rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''.
* '''pulley_connected_1''', '''pulley_connected_2''': Either the index of part at one of the two ends of the rope, or the index of next or previous pulley the rope is running through.
* '''unknown_50''', '''unknown_52''': Not used, always -1.
* '''rope_index''': In TIM 2 / 3, the index of the rope part. Not used (-1) in TIM and TEMIM.

=== Programmable ball (TIM 2 / 3) ===

The programmable ball part is present in TIM 2 and 3, and its part type number is 87. The size of the entry is 60 bytes in total. The first 48 bytes is the same as the default part data structure, which is followed by another, 12-byte structure specific to this part. The format of the programmable ball data is:

UINT16LE density;
UINT16LE elasticity;
UINT16LE friction;
INT16LE gravity_buoyancy;
UINT16LE mass;
UINT16LE appearance_2;

* '''density''': The density of the ball, affects the buoyant force acting on the ball.
* '''elasticity''': The elasticity of the ball.
* '''friction''': The friction.
* '''gravity_buoyancy''': A calculated parameter, using the density and the mass of the ball, as well as the gravity and the pressure set for the puzzle. If its value is negative, the ball will rise due to the buoyant force rather than fall.
* '''mass''': The mass of the ball.
* '''appearance_2''': Has the same value as the ''appearance'' field. The ball can have 7 different colors/patterns.

The game has a dialog for setting the four physical properties (mass, elasticity, density, friction, in this order). However, the number stored in the data structure is not the same as the numbers shown on the program dialog. For example, if following settings are used for the ball: <code>mass = 8</code>, <code>elasticity = 3</code>, <code>density = 7</code>, <code>friction = 3</code>; and the default values are used for gravity/pressure, the puzzle file will contain the following values: <code>density = 3000</code>, <code>elasticity = 128</code>, <code>friction = 16</code>, <code>gravity_buoyancy = 269</code>, <code>mass = 201</code>. (Note: There is an inconsistency in the game here, the programmable ball part uses <code>density = 2832</code> and <code>mass = 200</code> by default, which does not correspond exactly to any value that can be set in the dialog.)

=== TIM demo version ===

In the demo version of the (original) TIM (available at several DOS shareware game websites), the ''flags_3'', ''outlet_plugged_1'' and ''outlet_plugged_2'' fields are missing.
Instead, the 42-byte part data (46 for belts, 48 for ropes, 50 for pulleys) is followed by an another, variable length data structure of unknown significance consisting of 16-bit little endian integers. It is always at least 2 bytes long, and the first two bytes contain the number of additional 16-bit words after this size word. The reverse engineering of this structure is complicated by the fact that it is only present in a demo version containing only 8 puzzles.

== Puzzle solution information ==

Puzzle solution information is only present in TIM 2 and TIM 3 puzzles. Its size is always 132 bytes and can contain 8 different conditions that must be satisfied so that the game will recognize the puzzle as solved. The first two bytes contains the number of such conditions actually set, in a 16-bit little endian format. This is followed by 8 entries, 16 bytes each, containing the required information for solution checking by the game. The format of each entry is:

INT16LE part_index;
UINT16LE part_state_1;
UINT16LE part_state_2;
UINT16LE part_count;
INT16LE position_rect_x;
INT16LE position_rect_y;
INT16LE position_rect_width;
INT16LE position_rect_height;

* '''part_index''': The index of the part in the puzzle file involved in the solution. -1 (0xFF 0xFF) for unused entries.
* '''part_state_1''': An ID for a "physical state" of a part (for example a balloon was popped or a candle was lit). In many puzzles, one specific part must be in a specified "physical state" in order to complete the level. This is the same ID for a "part state" as the ''first_frame_id'' member found in the C section of the part's ANM file.
* '''part_state_2''': Another ID for a "physical state", the exact meaning is unclear.
* '''part_count''': The value of the "Part count" option set in the "program solution" dialog of the game.
* '''position_rect_x''', '''position_rect_y''': The top left corner of the "position rectangle". If such a solution specified puzzle part must be located within this rectangle in order to solve the puzzle.
* '''position_rect_width''', '''position_rect_height''': Width and height of the "position rectangle", see above.

For the last four members ("position rectangle"), there are "fixed" combinations of values with special meaning:

* <code>-1, -1, -1, -1</code>: "Off screen", the part must leave the area visible on the game screen.
* <code>-500, -2000, 1640, 2000</code>: "Off top", the part must leave the visible area at the top.
* <code>-500, 400, 1640, 3000</code>: "Off bottom"
* <code>0, 0, 0, 0</code>: No such solution programmed, either this is "part state" solution or an unused entry (<code>part_index = -1</code>).

The last 2 bytes of the section contain the value of the "Delay" option set in the "program solution" dialog of the game, in 16-bit little endian format.

'''Note on puzzle solution information in TIM and TEMIM''': TIM / TEMIM puzzles do not contain such data. This can also be demonstrated by extracting e.g. <tt>L1.LEV</tt> from the archive file and rename the file to change the number. After starting the game, the level with the same number as the renamed file will be replaced with level 1. When playing the modified level, the game will not be able to check whether the puzzle is solved. Depending on its number, the level can become unwinnable or winnable by just clicking on the start machine button. Sometimes the game freezes.

== Tools ==

{{TODO|Level viewer will be published soon}}

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

The Incredible Machine Level Format

2022-07-21T15:25:49Z

Knt47: /* In TIM and TEMIM */

{{Map Infobox
| Type =
| Layers =
| Tile size = Not tile based, the game uses a 16x16 grid for walls and a few other puzzle parts
| Viewport =
'''576×368''' (Levels in [[The Incredible Machine]] (TIM) and [[The Even More Incredible Machine]] (TEMIM))
'''640×400''' (.GKC files in TIM and TEMIM)
'''560×377''' (Levels in [[The Incredible Machine 2]] and 3)
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|The Incredible Machine 3}}
}}

This page discusses the '''level format''' of [[The Incredible Machine]], from the first DOS version (abbreviated as TIM 1) to [[The Incredible Machine 3|TIM 3]] (which is a 32-bit Windows game). Even if the format of some sections of the file vary significantly between the versions, the way how the parts are stored is highly similar.

The machines/puzzles saved from the "freeform machine" mode or the built-in level editor are also discussed here. The format of files saved from built-in editor may be identical to or slightly different from the levels, depending on the game version. The animated '''"title screen"''' (<tt>TITLE.GKC</tt>) and '''"credits screen"''' (<tt>CREDITS.GKC</tt>) files (inside the archive file) in TIM 1 and [[The Even More Incredible Machine]] (TEMIM) use a variant of the level file format, even if these are not playable levels.

== Magic number ==

TIM-TIM 3 level and GKC files always start with a 4-byte magic number. The following table summarizes the magic numbers found in various versions of the game.

{| class="wikitable"
! Magic number (hex) !! Usage in game versions
|-
| <code>ED AC 00 01</code>
|
* Puzzles in TIM demo version.
|-
| <code>ED AC 02 01</code>
|
* Puzzles in TIM.
* Saved freeform machines in TIM.
* GKC files in TIM.
* <tt>CREDITS.GKC</tt> in TEMIM.
|-
| <code>EE AC 05 01</code>
|
* New puzzles in TEMIM not found in TIM.
* Saved freeform machines in TEMIM.
* <tt>TITLE.GKC</tt> in TEMIM.
|-
| <code>EF AC 11 01</code>
<code>EF AC 12 01</code>
|
* A small number of puzzles in TIM 2 and 3.
|-
| <code>EF AC 13 01</code>
|
* The large majority of puzzles in TIM 2 and 3.
* Puzzles saved from the built-in editor of TIM 2.
|-
| <code>EF AC 14 01</code>
|
* A small number of puzzles in TIM 3.
* Puzzles saved from the built-in editor of TIM 3.
|}

== Structure of puzzle and GKC files ==

The level/puzzle/saved machine files consist of multiple sections. An overview of the file structure is provided below, separately for TIM / TEMIM and TIM 2 / TIM 3.

=== TIM and TEMIM ===

* Magic number, see above
* Puzzle title, null-terminated string. missing in .GKC files and "freeform machines" saved by the player.
* Goal description, null-terminated string. Absent from .GKC files and "saved freeform machines" with magic number of <code>ED AC 02 01</code>. Present in TEMIM "saved freeform machines" (magic number <code>EE AC 05 01</code>). An empty string in .GKC files with magic number <code>EE AC 05 01</code>.
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move ("fixed", e.g. walls) and are not found initially to the parts bin.
* List of part entry structures for parts that can move (e.g. balls), not in the parts bin.
* An additional 16-bit, little endian integer value in puzzles with magic number of <code>EE AC 05 01</code>. The meaning of this value is unclear. 0 in puzzles from the game archive file. In saved freeform machines, 1 if there are parts placed into the parts bin, 0 otherwise.
* List of part entry structures for parts initially placed into the parts bin.

=== TIM 2 and 3 ===

* Magic number, see above
* Two additional "header" bytes in files with magic number <code>EF AC 13 01</code> or <code>EF AC 14 01</code>. First byte is always 0, second is the background color from the 16-color palette.
* Puzzle title, null-terminated string
* Goal description, null-terminated string
* Hints, see below
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move
* List of part entry structures for parts that can move
* Solution information, see below

== Hints ==

Hints are supported only in TIM 2 and 3 puzzles. The first two bytes of the hint data contain the number of the hints in 16-bit little endian format. This is followed by 8 hint entries, some of them may be unused. A size of an unused entry is 7 bytes. One entry consists of three 16-bit integers and a null-terminated string containing the hint text. The three integer members are (all have a 16-bit little endian format):

* '''position_x''': The X position of the hand icon for the hint.
* '''position_y''': The Y position.
* '''hint_icon_flip''': The hand icon of a hint can be flipped and can have four different orientations. Possible values are 0-3.

In TIM 2, there are 3 (?) puzzles with magic number <code>EF AC 11 01</code>. Neither of these files contain hints. However, the size of the empty hints section is 42 bytes in them instead of the expected 58.

== Puzzle information data structure ==

=== In TIM and TEMIM ===

In TIM and TEMIM, there are two different puzzle header information data structures, one is used by the puzzles, and the another is found in saved "freeform" machines and the GKC files.

The information structure format in TIM / TEMIM puzzles:

[[UINT16LE]] bonus_1;
UINT16LE bonus_2;
[[INT16LE]] pressure;
INT16LE gravity;
INT16LE unknown_8;
INT16LE unknown_10;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

The information structure format in saved "freeform" machines and GKC files:

INT16LE pressure;
INT16LE gravity;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

* '''bonus_1''': The value of "Bonus 1" immediately after the puzzle is loaded (its value is constantly decreasing while the player is solving the puzzle).
* '''bonus_2''': The value of "Bonus 2" for the puzzle.
* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''unknown_8''', ''unknown_10'': The value of these two members is always -8. Perhaps the top left corner of the screen in the coordinate system used for puzzle parts, which is also (-8, -8).
* '''music''': ID of music track played. Valid values are 1001-1016 for TIM and 1001-1021 for TEMIM.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move (e.g. walls), not in the "parts bin".
* '''num_parts_moving''': Number of parts in the puzzles that move (e.g. balls), not in the "parts bin".
* '''num_parts_in_partsbin''': The number of parts that are placed into the parts bin. (The player needs to position them in order to solve the puzzle.)

=== In TIM 2 and 3 ===

The information structure format in TIM 2 and 3:

INT16LE pressure;
INT16LE gravity;
UINT16LE unknown_4;
UINT16LE unknown_6;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE unknown_14;

* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''music''': ID of music track played. Valid values are 1000-1023.
* '''unknown_4''', '''unknown_6''': Meaning is unknown, always 0.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move, regardless of whether they are placed initially into the parts bin or not.
* '''num_parts_moving''': Number of parts in the puzzles that can move.
* '''unknown_14''': Value is always 0. Likely this member corresponds to num_parts_in_partsbin in TIM/TEMIM puzzle header. However, parts found in the parts bin are not a separate section in TIM 2 / 3,

== Puzzle part data ==

As already discussed in the With the exception of TIM demo version (see below), the size of a part entry for the majority of puzzle parts is 48 bytes. However, there are exceptions, which are discussed in separate sub-sections. The format of the "default" part entry:

UINT16LE part_type_num;
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
[[BYTE]] belt_connect_pos_x;
BYTE belt_connect_pos_y;
UINT16LE belt_line_distance;
UINT16LE unknown_32;
BYTE rope_1_connect_pos_x;
BYTE rope_1_connect_pos_y;
UINT16LE unknown_36;
BYTE rope_2_connect_pos_x;
BYTE rope_2_connect_pos_y;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''part_type_num''': A number associated with the type of the part (e.g. 0 - bowling ball). Required for identifying parts with an entry size different from the default. See [[The Incredible Machine Level Format/Part Numbers]]
* '''flags_1''': A combination of flag bits.
** '''TIM''' / '''TEMIM''' uses the following flag bits:
*** <code>0x20</code>: Unknown meaning, used for a few "moving" parts (bucket, candle)
*** <code>0x40</code>: Set if the part is a wall.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x800</code>: Part is placed initially into the parts bin (see num_parts_in_partsbin in part information data structure)
*** <code>0x1000</code>: "Moving" part, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x2000</code>: Part cannot move, in fixed position, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x4000</code>: Part cannot move, in fixed position (see ''num_parts_fixed'')
*** <code>0x8000</code>: Set when 0x800 is not set ({{TODO|further testing needed}})
** In '''TIM 2 / 3''', the bits have a known meaning:
*** <code>0x40</code>: Meaning unclear, used for "moving" parts only, but not always set, even for a single type of part.***
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x1000</code>: "Moving" part, affected by gravity.
*** <code>0x2000</code>, 0x4000: Used in combination for parts that do not move and are not affected by gravity.
* '''flags_2''': Another word containing flag bits. The meaning of most flags is the same in all game versions.
** <code>0x1</code>: A belt can be connected to the part.
** <code>0x2</code>: A belt is connected to the part.
** <code>0x4</code>: A rope can be connected to the part.
** <code>0x8</code>: A second rope can be connected to the part (teeter-totter)
** <code>0x10</code>: The part sprite is drawn horizontally flipped.
** <code>0x20</code>: The part sprite is drawn vertically flipped. Note on flip flags: Flipping a part in the game does not necessarily mean that one of the flip flags will be changed. For several parts, especially in TIM 2 / 3, flipping will affect the value of the ''appearance'' member.
** <code>0x40</code>: Probably unused
** <code>0x80</code>: Part can be stretched in at least one direction: inclines, conveyor belt, walls.
** <code>0x100</code>: Parts that can be stretched both horizontally and vertically, the walls.
* '''flags_3''': Some flags are only present in TIM 2 / 3. This member of the part data structure is missing in the demo version of TIM.
** <code>0x1</code>: The part can be plugged into an electric outlet.
** <code>0x2</code>: The part is an electric outlet.
** <code>0x4</code>: The part can burn (e.g. candle) or has a fuse that can be lit (e.g. dynamite, cannon). Usually in combination with flag 0x8.
** <code>0x8</code>: Meaning of this flag is unclear. Used for several part types, but changing it has no apparent consequence (?)
** Flags present only in '''TIM 2 / 3''':
*** <code>0x40</code>: Part is "locked", i.e not placed into the part bin.
*** <code>0x80</code>: Sizable scenery part (?)
*** <code>0x100</code>: {{TODO|unknown meaning}}
*** <code>0x400</code>: A "program" icon is shown for the part (?)
*** <code>0x1000</code>: Scenery part
*** <code>0x2000</code>: Wall part (?)
*** <code>0x8000</code>: A "Puzzle solution" icon is shown for the part (?)
* '''appearance''': An identifier for the sprite that is shown for a part before the machine is started. (Once the machine is started, the state of the part can change and so can the sprite shown.) The meaning is different between TIM and TIM 2. In TIM, the sprite of some parts consists of only one image, in this case, this is often the number of the sub-image in the image resource file. ({{TODO|For other parts, this is probably an internal identifier for the sprite (?)}}). In TIM 2 and 3, the meaning of the appearance is an index in the A section of the [[The Incredible Machine 2-3 ANM File Format|.ANM file]] for the part, or if this is absent, an index in the B section. "Programming" a part in TIM 2 and 3 often results in the change of this field.
* '''unknown_10''': Probably unused, usually 0.
* '''width_1''', '''height_1''': The width and height of the selectable area of the part ({{TODO|more reverse engineering work needed}})
* '''width_2''', '''height_2''': At least in TIM 2, witdh_2 is used for calculating the position of part sprite when the part is flipped because of the horizontal flip bit is set in flags_2.
* '''pos_x''', '''pos_y''': The position of the part, usually the top left corner of the bounding rectangle.
* '''behavior''': In TIM 2 and 3, a programmed behavior of the part. (However, for many parts, "programming" modifies the ''appearance'' member.) For example the number of shots of the phazer gun or character shown by the message computer. Meaning is different for rope parts, see below. Unused in TIM and TEMIM (except for ropes).
* '''unknown_26''': Probably unused, usually 0. Note that belt parts have a value of 1 in this position.
* '''belt_connect_pos_x''', '''belt_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Always positive or 0, because ''pos_x'' and ''pos_y'' are the coordinates of the top left corner where the sprite starts. Note that the formulas required for calculating the exact position of the belt are slightly different between TIM and TIM 2. Parts for which connection of a belt is allowed have a distinct circular area in their sprite, corresponding to the location where the belt is connected. In TIM / TEMIM, ''belt_connect_pos_x'' and ''belt_connect_pos_y'' is approximately the top left corner of its bounding rectangle, while in TIM 2 /3 it is close to the center of the circle.
* '''unknown_36''': Probably unused, usually 0.
* '''belt_line_distance''': The belts in the game appear as two, usually not perfectly parallel black (TIM / TEMIM) or gray (TIM 2 / 3) lines. This parameter determines the distance between the two segments, More precisely, it is either approximately the diameter of the circular area mentioned at ''belt_connect_pos_x'' and ''belt_connect_pos_y'' (TIM / TEMIM) or its radius (TIM 2 / 3).
* '''unknown_32''': Probably unused, usually 0.
* '''rope_1_connect_pos_x''', '''rope_1_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Similarly to belt_connect_pos_x/y, always positive or 0.
* '''rope_2_connect_pos_x''', '''rope_2_connect_pos_y''': The same as ''rope_1_connect_pos_x'', ''rope_1_connect_pos_y'', bit for another connected rope part.
* '''connected_1''', '''connected_2''': The index of one or two parts in the puzzle that are connected to this part with a rope. If the rope runs through pulleys, this is the part index of the first pulley. If no rope is connected or this is not possible for the part, the value of both structure members are -1. (Of course, if one rope is connected, the value of one structure member (usually connected_rope_1) is the index of the rope part and the other is -1) )In TIM 2 and 3, the "remote bomb" part actually corresponds to two entries in the puzzle file. The connected_rope_2 field contains the index of the another "element" of the bomb, in both entries.
* '''outlet_plugged_1''', '''outlet_plugged_2''': These structure members are only meaningful for electric outlet parts. Electric outlets always have 2 "sockets" for parts requiring electricity. It contains the index/indices of the part/parts plugged into the electric outlet, or -1 if the "socket" is free. If the part does not support this, both values are -1.

=== Belts ===

Belt parts (part 8) (except in the demo version of TIM, see below) use a 52-byte entry, with the following format:

UINT16LE part_type_num; /* 8 for belts */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
INT16LE belt_connected_part_1;
INT16LE belt_connected_part_2;
UINT16LE unknown_36;
UINT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0</code>, <code>flags_3 = 0</code>
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0</code>, <code>flags_3 = 0x40</code> (or <code>0</code> if in parts bin)
* '''appearance''': Always 0, belts have no true sprite (represented by two lines).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for belts, always 0.
* '''pos_x''', '''pos_y''' In TIM/TEMIM, either 0 or -1. In TIM 2, -1 or -100 (0xff9c). Meaning of these numbers is unclear, and the usage of the two different values do not correlate with the flags.
* '''behavior''': Not used, always 0.
* '''unknown_26''': Always 1, perhaps indicates that the part is a belt.
* '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''belt_connected_part_1''', '''belt_connected_part_2''': Index of the two parts in the puzzle connected by this belt. In TIM and TEMIM, both are -1 if the belt is placed into the parts bin.
* '''unknown_36''', '''unknown_38''', '''unknown_40''', '''unknown_42''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Ropes ===

Rope parts (part 10) (except in the demo version of TIM, see below) use a 54-byte entry. TIM 2 and 3 also have a "steel cable" part (part 76) which also behaves as a rope and the size of the part entry as also identical. The rope part entry has the following format:

UINT16LE part_type_num; /* 10 for rope, 76 for steel cable */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE rope_segment_length;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
UINT16LE unknown_36;
INT16LE rope_connected_part_1;
INT16LE rope_connected_part_2;
BYTE part_1_connect_field_usage;
BYTE part_2_connect_field_usage;
UINT16LE unknown_44;
UINT16LE unknown_46;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''': Same flags used as in the belt part structure.
* '''appearance''': Always 0, ropes have no true sprite (represented by one or more line segments).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for ropes, always 0.
* '''pos_x''', '''pos_y''': Similarly to belts, possible values are 0 and -1 in TIM / TEMIM; and -1 and -100 in TIM 2 / 3.
* '''rope_segment_length''': The length of the rope (Euclidean distance between the two ends) if the rope does not run through pulleys. Otherwise, the length of the rope segment between the part at one end (rope_connected_part_1 (?)) and the first pulley ({{TODO|additional testing needed}}).
* '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for pulleys.
* '''unknown_36''': Not used, always 0.
* '''rope_connected_part_1''', '''rope_connected_part_2''': Index of the two parts in the puzzle connected by this rope (never the pulleys). In TIM and TEMIM, both are -1 if the rope is placed into the parts bin.
* '''part_1_connect_field_usage''', '''part_2_connect_field_usage''': Whether ''connected_1'' or ''connected_2'' is used in the two connected parts for this rope. 0 if connected_1, 1 if connected_2. ({{TODO|additional testing needed}})
* '''unknown_44''', '''unknown_46''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Pulleys ===

The format of the 56-byte puzzle part entry for the pulley (part 7):

UINT16LE part_type_num; /* 7 for pulley */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
BYTE pulley_rope_1_connect_pos_x;
BYTE pulley_rope_1_connect_pos_y;
INT16LE unknown_36;
INT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
BYTE pulley_rope_2_connect_pos_x;
BYTE pulley_rope_2_connect_pos_y;
INT16LE pulley_connected_1;
INT16LE pulley_connected_2;
INT16LE unknown_50;
INT16LE unknown_52;
INT16LE rope_index;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0x4</code>, <code>flags_3 = 0x8</code> (<code>0x0</code> {{TODO|in some cases}})
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0x4</code>, <code>flags_3 = 0x48</code> (or <code>0x8</code> if in parts bin)
* '''appearance''': Pulleys can have four different sprites depending on the orientation. Possible values are 0-3.
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': The size of the pulley sprite. In TIM 2 / 3, also depends on the orientation.
* '''pos_x''', '''pos_y''': The position of the pulley, top left coordinates of the bounding rectangle.
* '''behavior''', '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for ropes.
* '''pulley_rope_1_connect_pos_x''', '''pulley_rope_1_connect_pos_y''': The coordinates of the point where one rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''. Depends on the orientation of the pulley, like ''appearance''.
* '''unknown_36''', '''unknown_38''': Not used, always -1.
* '''unknown_40'', ''unknown_42''': Not used, always 0.
* '''pulley_rope_2_connect_pos_x''', '''pulley_rope_2_connect_pos_y''': The coordinates of the point where the other rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''.
* '''pulley_connected_1''', '''pulley_connected_2''': Either the index of part at one of the two ends of the rope, or the index of next or previous pulley the rope is running through.
* '''unknown_50''', '''unknown_52''': Not used, always -1.
* '''rope_index''': In TIM 2 / 3, the index of the rope part. Not used (-1) in TIM and TEMIM.

=== Programmable ball (TIM 2 / 3) ===

The programmable ball part is present in TIM 2 and 3, and its part type number is 87. The size of the entry is 60 bytes in total. The first 48 bytes is the same as the default part data structure, which is followed by another, 12-byte structure specific to this part. The format of the programmable ball data is:

UINT16LE density;
UINT16LE elasticity;
UINT16LE friction;
INT16LE gravity_buoyancy;
UINT16LE mass;
UINT16LE appearance_2;

* '''density''': The density of the ball, affects the buoyant force acting on the ball.
* '''elasticity''': The elasticity of the ball.
* '''friction''': The friction.
* '''gravity_buoyancy''': A calculated parameter, using the density and the mass of the ball, as well as the gravity and the pressure set for the puzzle. If its value is negative, the ball will rise due to the buoyant force rather than fall.
* '''mass''': The mass of the ball.
* '''appearance_2''': Has the same value as the ''appearance'' field. The ball can have 7 different colors/patterns.

The game has a dialog for setting the four physical properties (mass, elasticity, density, friction, in this order). However, the number stored in the data structure is not the same as the numbers shown on the program dialog. For example, if following settings are used for the ball: <code>mass = 8</code>, <code>elasticity = 3</code>, <code>density = 7</code>, <code>friction = 3</code>; and the default values are used for gravity/pressure, the puzzle file will contain the following values: <code>density = 3000</code>, <code>elasticity = 128</code>, <code>friction = 16</code>, <code>gravity_buoyancy = 269</code>, <code>mass = 201</code>. (Note: There is an inconsistency in the game here, the programmable ball part uses <code>density = 2832</code> and <code>mass = 200</code> by default, which does not correspond exactly to any value that can be set in the dialog.)

=== TIM demo version ===

In the demo version of the (original) TIM (available at several DOS shareware game websites), the ''flags_3'', ''outlet_plugged_1'' and ''outlet_plugged_2'' fields are missing.
Instead, the 42-byte part data (46 for belts, 48 for ropes, 50 for pulleys) is followed by an another, variable length data structure of unknown significance consisting of 16-bit little endian integers. It is always at least 2 bytes long, and the first two bytes contain the number of additional 16-bit words after this size word. The reverse engineering of this structure is complicated by the fact that it is only present in a demo version containing only 8 puzzles.

== Puzzle solution information ==

Puzzle solution information is only present in TIM 2 and TIM 3 puzzles. Its size is always 132 bytes and can contain 8 different conditions that must be satisfied so that the game will recognize the puzzle as solved. The first two bytes contains the number of such conditions actually set, in a 16-bit little endian format. This is followed by 8 entries, 16 bytes each, containing the required information for solution checking by the game. The format of each entry is:

INT16LE part_index;
UINT16LE part_state_1;
UINT16LE part_state_2;
UINT16LE part_count;
INT16LE position_rect_x;
INT16LE position_rect_y;
INT16LE position_rect_width;
INT16LE position_rect_height;

* '''part_index''': The index of the part in the puzzle file involved in the solution. -1 (0xFF 0xFF) for unused entries.
* '''part_state_1''': An ID for a "physical state" of a part (for example a balloon was popped or a candle was lit). In many puzzles, one specific part must be in a specified "physical state" in order to complete the level. This is the same ID for a "part state" as the ''first_frame_id'' member found in the C section of the part's ANM file.
* '''part_state_2''': Another ID for a "physical state", the exact meaning is unclear.
* '''part_count''': The value of the "Part count" option set in the "program solution" dialog of the game.
* '''position_rect_x''', '''position_rect_y''': The top left corner of the "position rectangle". If such a solution specified puzzle part must be located within this rectangle in order to solve the puzzle.
* '''position_rect_width''', '''position_rect_height''': Width and height of the "position rectangle", see above.

For the last four members ("position rectangle"), there are "fixed" combinations of values with special meaning:

* <code>-1, -1, -1, -1</code>: "Off screen", the part must leave the area visible on the game screen.
* <code>-500, -2000, 1640, 2000</code>: "Off top", the part must leave the visible area at the top.
* <code>-500, 400, 1640, 3000</code>: "Off bottom"
* <code>0, 0, 0, 0</code>: No such solution programmed, either this is "part state" solution or an unused entry (<code>part_index = -1</code>).

The last 2 bytes of the section contain the value of the "Delay" option set in the "program solution" dialog of the game, in 16-bit little endian format.

'''Note on puzzle solution information in TIM and TEMIM''': TIM / TEMIM puzzles do not contain such data. This can also be demonstrated by extracting e.g. <tt>L1.LEV</tt> from the archive file and rename the file to change the number. After starting the game, the level with the same number as the renamed file will be replaced with level 1. When playing the modified level, the game will not be able to check whether the puzzle is solved. Depending on its number, the level can become unwinnable or winnable by just clicking on the start machine button. Sometimes the game freezes.

== Tools ==

{{TODO|Level viewer will be published soon}}

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

The Incredible Machine

2022-07-21T15:16:32Z

Knt47: /* Files inside the RESOURCE.00? archive files */

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

This section lists the file formats used in the game.

=== Resource file format ===
See [[TIM Resource Format]]. Resource sub-files are stored in files named <tt>RESOURCE.00?</tt>. The Incredible Machine has four such files: <tt>RESOURCE.001</tt>-<tt>.004</tt>. (However, the demo versions of both The Incredible Machine and The Even More Incredible Machine has only one. {{TODO|Add information for The Even More Incredible Machine.}}) The <tt>RESOURCE.MAP</tt> file contains the offsets for the sub-files.

=== Files inside the RESOURCE.00? archive files ===
{|class="wikitable"
! File name or extension !! Description
|-
| <tt>*.BMP</tt> || 16-color images. See [[The Incredible Machine Image Format]].
|-
| <tt>MEMOFNT8.FNT</tt> || 1BPP font, [[Dynamix Font Format v4-v5|Dynamix Font Format v4]].
|-
| <tt>CREDITS.GKC</tt> <tt>TITLE.GKC</tt> || Title screen and credits animation. This is a variant of the [[The Incredible Machine Level Format|level format]].
|-
| <tt>SX.OVL</tt> <tt>VM.OVL</tt> || {{TODO|TODO: Add information}}
|-
| <tt>*.PAL</tt> || VGA palettes. Similar to the palette format of [[RES Format (Stellar 7)#PAL: Palette|Stellar 7]].
|-
| <tt>*.SCR</tt> || Full-screen image (640x480x16 color). See [[RES Format (Stellar 7)#SCR: Fullscreen image|RES Format (Stellar 7)]].
|-
| <tt>TIM.SX</tt> || Sound and music. {{TODO|TODO: Add information}}
|-
| <tt>L*.TIM</tt> || [[The Incredible Machine Level Format|Level/puzzle files]]
|-
| <tt>PASSWORD.TXT</tt> || Plain text file. Contains passwords for each level.
|-
|}

== See also ==
* [[RES Format (Stellar 7)]] - Contains the documentation for several identical or related file formats.

[[Category:Sierra/Dynamix]]
[[Category:Puzzle]]

The Incredible Machine Level Format

2022-07-21T15:11:25Z

Knt47: credits, other small changes

{{Map Infobox
| Type =
| Layers =
| Tile size = Not tile based, the game uses a 16x16 grid for walls and a few other puzzle parts
| Viewport =
'''576×368''' (Levels in [[The Incredible Machine]] (TIM) and [[The Even More Incredible Machine]] (TEMIM))
'''640×400''' (.GKC files in TIM and TEMIM)
'''560×377''' (Levels in [[The Incredible Machine 2]] and 3)
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|The Incredible Machine 3}}
}}

This page discusses the '''level format''' of [[The Incredible Machine]], from the first DOS version (abbreviated as TIM 1) to [[The Incredible Machine 3|TIM 3]] (which is a 32-bit Windows game). Even if the format of some sections of the file vary significantly between the versions, the way how the parts are stored is highly similar.

The machines/puzzles saved from the "freeform machine" mode or the built-in level editor are also discussed here. The format of files saved from built-in editor may be identical to or slightly different from the levels, depending on the game version. The animated '''"title screen"''' (<tt>TITLE.GKC</tt>) and '''"credits screen"''' (<tt>CREDITS.GKC</tt>) files (inside the archive file) in TIM 1 and [[The Even More Incredible Machine]] (TEMIM) use a variant of the level file format, even if these are not playable levels.

== Magic number ==

TIM-TIM 3 level and GKC files always start with a 4-byte magic number. The following table summarizes the magic numbers found in various versions of the game.

{| class="wikitable"
! Magic number (hex) !! Usage in game versions
|-
| <code>ED AC 00 01</code>
|
* Puzzles in TIM demo version.
|-
| <code>ED AC 02 01</code>
|
* Puzzles in TIM.
* Saved freeform machines in TIM.
* GKC files in TIM.
* <tt>CREDITS.GKC</tt> in TEMIM.
|-
| <code>EE AC 05 01</code>
|
* New puzzles in TEMIM not found in TIM.
* Saved freeform machines in TEMIM.
* <tt>TITLE.GKC</tt> in TEMIM.
|-
| <code>EF AC 11 01</code>
<code>EF AC 12 01</code>
|
* A small number of puzzles in TIM 2 and 3.
|-
| <code>EF AC 13 01</code>
|
* The large majority of puzzles in TIM 2 and 3.
* Puzzles saved from the built-in editor of TIM 2.
|-
| <code>EF AC 14 01</code>
|
* A small number of puzzles in TIM 3.
* Puzzles saved from the built-in editor of TIM 3.
|}

== Structure of puzzle and GKC files ==

The level/puzzle/saved machine files consist of multiple sections. An overview of the file structure is provided below, separately for TIM / TEMIM and TIM 2 / TIM 3.

=== TIM and TEMIM ===

* Magic number, see above
* Puzzle title, null-terminated string. missing in .GKC files and "freeform machines" saved by the player.
* Goal description, null-terminated string. Absent from .GKC files and "saved freeform machines" with magic number of <code>ED AC 02 01</code>. Present in TEMIM "saved freeform machines" (magic number <code>EE AC 05 01</code>). An empty string in .GKC files with magic number <code>EE AC 05 01</code>.
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move ("fixed", e.g. walls) and are not found initially to the parts bin.
* List of part entry structures for parts that can move (e.g. balls), not in the parts bin.
* An additional 16-bit, little endian integer value in puzzles with magic number of <code>EE AC 05 01</code>. The meaning of this value is unclear. 0 in puzzles from the game archive file. In saved freeform machines, 1 if there are parts placed into the parts bin, 0 otherwise.
* List of part entry structures for parts initially placed into the parts bin.

=== TIM 2 and 3 ===

* Magic number, see above
* Two additional "header" bytes in files with magic number <code>EF AC 13 01</code> or <code>EF AC 14 01</code>. First byte is always 0, second is the background color from the 16-color palette.
* Puzzle title, null-terminated string
* Goal description, null-terminated string
* Hints, see below
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move
* List of part entry structures for parts that can move
* Solution information, see below

== Hints ==

Hints are supported only in TIM 2 and 3 puzzles. The first two bytes of the hint data contain the number of the hints in 16-bit little endian format. This is followed by 8 hint entries, some of them may be unused. A size of an unused entry is 7 bytes. One entry consists of three 16-bit integers and a null-terminated string containing the hint text. The three integer members are (all have a 16-bit little endian format):

* '''position_x''': The X position of the hand icon for the hint.
* '''position_y''': The Y position.
* '''hint_icon_flip''': The hand icon of a hint can be flipped and can have four different orientations. Possible values are 0-3.

In TIM 2, there are 3 (?) puzzles with magic number <code>EF AC 11 01</code>. Neither of these files contain hints. However, the size of the empty hints section is 42 bytes in them instead of the expected 58.

== Puzzle information data structure ==

=== In TIM and TEMIM ===

In TIM and TEMIM, there are two different puzzle header information data structures, one is used by the puzzles, and the another is found in saved "freeform" machines and the GKC files.

The information structure format in TIM / TEMIM puzzles:

[[UINT16LE]] bonus_1;
UINT16LE bonus_2;
[[INT16LE]] pressure;
INT16LE gravity;
INT16LE unknown_8;
INT16LE unknown_10;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

The information structure format in saved "freeform" machines and GKC files:

INT16LE pressure;
INT16LE gravity;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

* '''bonus_1''': The value of "Bonus 1" immediately after the puzzle is loaded (its value is constantly decreasing while the player is solving the puzzle).
* '''bonus_2''': The value of "Bonus 2" for the puzzle.
* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''unknown_8''', ''unknown_10'': The value of these two members is always -8. Perhaps the top left corner of the screen in the coordinate system used for puzzle parts, which is also (-8, -8).
* '''music''': ID of music track played. Valid values are 1001-1016 for TIM and 1001-1021 for TEMIM.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move (e.g. walls), not in the "parts bin".
* '''num_parts_moving''': Number of parts in the puzzles that move (e.g. balls), not in the "parts bin".
* '''num_parts_in_partsbin1''': The number of parts that are placed into the parts bin. (The player needs to position them in order to solve the puzzle.)

=== In TIM 2 and 3 ===

The information structure format in TIM 2 and 3:

INT16LE pressure;
INT16LE gravity;
UINT16LE unknown_4;
UINT16LE unknown_6;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE unknown_14;

* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''music''': ID of music track played. Valid values are 1000-1023.
* '''unknown_4''', '''unknown_6''': Meaning is unknown, always 0.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move, regardless of whether they are placed initially into the parts bin or not.
* '''num_parts_moving''': Number of parts in the puzzles that can move.
* '''unknown_14''': Value is always 0. Likely this member corresponds to num_parts_in_partsbin in TIM/TEMIM puzzle header. However, parts found in the parts bin are not a separate section in TIM 2 / 3,

== Puzzle part data ==

As already discussed in the With the exception of TIM demo version (see below), the size of a part entry for the majority of puzzle parts is 48 bytes. However, there are exceptions, which are discussed in separate sub-sections. The format of the "default" part entry:

UINT16LE part_type_num;
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
[[BYTE]] belt_connect_pos_x;
BYTE belt_connect_pos_y;
UINT16LE belt_line_distance;
UINT16LE unknown_32;
BYTE rope_1_connect_pos_x;
BYTE rope_1_connect_pos_y;
UINT16LE unknown_36;
BYTE rope_2_connect_pos_x;
BYTE rope_2_connect_pos_y;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''part_type_num''': A number associated with the type of the part (e.g. 0 - bowling ball). Required for identifying parts with an entry size different from the default. See [[The Incredible Machine Level Format/Part Numbers]]
* '''flags_1''': A combination of flag bits.
** '''TIM''' / '''TEMIM''' uses the following flag bits:
*** <code>0x20</code>: Unknown meaning, used for a few "moving" parts (bucket, candle)
*** <code>0x40</code>: Set if the part is a wall.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x800</code>: Part is placed initially into the parts bin (see num_parts_in_partsbin in part information data structure)
*** <code>0x1000</code>: "Moving" part, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x2000</code>: Part cannot move, in fixed position, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x4000</code>: Part cannot move, in fixed position (see ''num_parts_fixed'')
*** <code>0x8000</code>: Set when 0x800 is not set ({{TODO|further testing needed}})
** In '''TIM 2 / 3''', the bits have a known meaning:
*** <code>0x40</code>: Meaning unclear, used for "moving" parts only, but not always set, even for a single type of part.***
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x1000</code>: "Moving" part, affected by gravity.
*** <code>0x2000</code>, 0x4000: Used in combination for parts that do not move and are not affected by gravity.
* '''flags_2''': Another word containing flag bits. The meaning of most flags is the same in all game versions.
** <code>0x1</code>: A belt can be connected to the part.
** <code>0x2</code>: A belt is connected to the part.
** <code>0x4</code>: A rope can be connected to the part.
** <code>0x8</code>: A second rope can be connected to the part (teeter-totter)
** <code>0x10</code>: The part sprite is drawn horizontally flipped.
** <code>0x20</code>: The part sprite is drawn vertically flipped. Note on flip flags: Flipping a part in the game does not necessarily mean that one of the flip flags will be changed. For several parts, especially in TIM 2 / 3, flipping will affect the value of the ''appearance'' member.
** <code>0x40</code>: Probably unused
** <code>0x80</code>: Part can be stretched in at least one direction: inclines, conveyor belt, walls.
** <code>0x100</code>: Parts that can be stretched both horizontally and vertically, the walls.
* '''flags_3''': Some flags are only present in TIM 2 / 3. This member of the part data structure is missing in the demo version of TIM.
** <code>0x1</code>: The part can be plugged into an electric outlet.
** <code>0x2</code>: The part is an electric outlet.
** <code>0x4</code>: The part can burn (e.g. candle) or has a fuse that can be lit (e.g. dynamite, cannon). Usually in combination with flag 0x8.
** <code>0x8</code>: Meaning of this flag is unclear. Used for several part types, but changing it has no apparent consequence (?)
** Flags present only in '''TIM 2 / 3''':
*** <code>0x40</code>: Part is "locked", i.e not placed into the part bin.
*** <code>0x80</code>: Sizable scenery part (?)
*** <code>0x100</code>: {{TODO|unknown meaning}}
*** <code>0x400</code>: A "program" icon is shown for the part (?)
*** <code>0x1000</code>: Scenery part
*** <code>0x2000</code>: Wall part (?)
*** <code>0x8000</code>: A "Puzzle solution" icon is shown for the part (?)
* '''appearance''': An identifier for the sprite that is shown for a part before the machine is started. (Once the machine is started, the state of the part can change and so can the sprite shown.) The meaning is different between TIM and TIM 2. In TIM, the sprite of some parts consists of only one image, in this case, this is often the number of the sub-image in the image resource file. ({{TODO|For other parts, this is probably an internal identifier for the sprite (?)}}). In TIM 2 and 3, the meaning of the appearance is an index in the A section of the [[The Incredible Machine 2-3 ANM File Format|.ANM file]] for the part, or if this is absent, an index in the B section. "Programming" a part in TIM 2 and 3 often results in the change of this field.
* '''unknown_10''': Probably unused, usually 0.
* '''width_1''', '''height_1''': The width and height of the selectable area of the part ({{TODO|more reverse engineering work needed}})
* '''width_2''', '''height_2''': At least in TIM 2, witdh_2 is used for calculating the position of part sprite when the part is flipped because of the horizontal flip bit is set in flags_2.
* '''pos_x''', '''pos_y''': The position of the part, usually the top left corner of the bounding rectangle.
* '''behavior''': In TIM 2 and 3, a programmed behavior of the part. (However, for many parts, "programming" modifies the ''appearance'' member.) For example the number of shots of the phazer gun or character shown by the message computer. Meaning is different for rope parts, see below. Unused in TIM and TEMIM (except for ropes).
* '''unknown_26''': Probably unused, usually 0. Note that belt parts have a value of 1 in this position.
* '''belt_connect_pos_x''', '''belt_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Always positive or 0, because ''pos_x'' and ''pos_y'' are the coordinates of the top left corner where the sprite starts. Note that the formulas required for calculating the exact position of the belt are slightly different between TIM and TIM 2. Parts for which connection of a belt is allowed have a distinct circular area in their sprite, corresponding to the location where the belt is connected. In TIM / TEMIM, ''belt_connect_pos_x'' and ''belt_connect_pos_y'' is approximately the top left corner of its bounding rectangle, while in TIM 2 /3 it is close to the center of the circle.
* '''unknown_36''': Probably unused, usually 0.
* '''belt_line_distance''': The belts in the game appear as two, usually not perfectly parallel black (TIM / TEMIM) or gray (TIM 2 / 3) lines. This parameter determines the distance between the two segments, More precisely, it is either approximately the diameter of the circular area mentioned at ''belt_connect_pos_x'' and ''belt_connect_pos_y'' (TIM / TEMIM) or its radius (TIM 2 / 3).
* '''unknown_32''': Probably unused, usually 0.
* '''rope_1_connect_pos_x''', '''rope_1_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Similarly to belt_connect_pos_x/y, always positive or 0.
* '''rope_2_connect_pos_x''', '''rope_2_connect_pos_y''': The same as ''rope_1_connect_pos_x'', ''rope_1_connect_pos_y'', bit for another connected rope part.
* '''connected_1''', '''connected_2''': The index of one or two parts in the puzzle that are connected to this part with a rope. If the rope runs through pulleys, this is the part index of the first pulley. If no rope is connected or this is not possible for the part, the value of both structure members are -1. (Of course, if one rope is connected, the value of one structure member (usually connected_rope_1) is the index of the rope part and the other is -1) )In TIM 2 and 3, the "remote bomb" part actually corresponds to two entries in the puzzle file. The connected_rope_2 field contains the index of the another "element" of the bomb, in both entries.
* '''outlet_plugged_1''', '''outlet_plugged_2''': These structure members are only meaningful for electric outlet parts. Electric outlets always have 2 "sockets" for parts requiring electricity. It contains the index/indices of the part/parts plugged into the electric outlet, or -1 if the "socket" is free. If the part does not support this, both values are -1.

=== Belts ===

Belt parts (part 8) (except in the demo version of TIM, see below) use a 52-byte entry, with the following format:

UINT16LE part_type_num; /* 8 for belts */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
INT16LE belt_connected_part_1;
INT16LE belt_connected_part_2;
UINT16LE unknown_36;
UINT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0</code>, <code>flags_3 = 0</code>
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0</code>, <code>flags_3 = 0x40</code> (or <code>0</code> if in parts bin)
* '''appearance''': Always 0, belts have no true sprite (represented by two lines).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for belts, always 0.
* '''pos_x''', '''pos_y''' In TIM/TEMIM, either 0 or -1. In TIM 2, -1 or -100 (0xff9c). Meaning of these numbers is unclear, and the usage of the two different values do not correlate with the flags.
* '''behavior''': Not used, always 0.
* '''unknown_26''': Always 1, perhaps indicates that the part is a belt.
* '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''belt_connected_part_1''', '''belt_connected_part_2''': Index of the two parts in the puzzle connected by this belt. In TIM and TEMIM, both are -1 if the belt is placed into the parts bin.
* '''unknown_36''', '''unknown_38''', '''unknown_40''', '''unknown_42''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Ropes ===

Rope parts (part 10) (except in the demo version of TIM, see below) use a 54-byte entry. TIM 2 and 3 also have a "steel cable" part (part 76) which also behaves as a rope and the size of the part entry as also identical. The rope part entry has the following format:

UINT16LE part_type_num; /* 10 for rope, 76 for steel cable */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE rope_segment_length;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
UINT16LE unknown_36;
INT16LE rope_connected_part_1;
INT16LE rope_connected_part_2;
BYTE part_1_connect_field_usage;
BYTE part_2_connect_field_usage;
UINT16LE unknown_44;
UINT16LE unknown_46;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''': Same flags used as in the belt part structure.
* '''appearance''': Always 0, ropes have no true sprite (represented by one or more line segments).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for ropes, always 0.
* '''pos_x''', '''pos_y''': Similarly to belts, possible values are 0 and -1 in TIM / TEMIM; and -1 and -100 in TIM 2 / 3.
* '''rope_segment_length''': The length of the rope (Euclidean distance between the two ends) if the rope does not run through pulleys. Otherwise, the length of the rope segment between the part at one end (rope_connected_part_1 (?)) and the first pulley ({{TODO|additional testing needed}}).
* '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for pulleys.
* '''unknown_36''': Not used, always 0.
* '''rope_connected_part_1''', '''rope_connected_part_2''': Index of the two parts in the puzzle connected by this rope (never the pulleys). In TIM and TEMIM, both are -1 if the rope is placed into the parts bin.
* '''part_1_connect_field_usage''', '''part_2_connect_field_usage''': Whether ''connected_1'' or ''connected_2'' is used in the two connected parts for this rope. 0 if connected_1, 1 if connected_2. ({{TODO|additional testing needed}})
* '''unknown_44''', '''unknown_46''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Pulleys ===

The format of the 56-byte puzzle part entry for the pulley (part 7):

UINT16LE part_type_num; /* 7 for pulley */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
BYTE pulley_rope_1_connect_pos_x;
BYTE pulley_rope_1_connect_pos_y;
INT16LE unknown_36;
INT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
BYTE pulley_rope_2_connect_pos_x;
BYTE pulley_rope_2_connect_pos_y;
INT16LE pulley_connected_1;
INT16LE pulley_connected_2;
INT16LE unknown_50;
INT16LE unknown_52;
INT16LE rope_index;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0x4</code>, <code>flags_3 = 0x8</code> (<code>0x0</code> {{TODO|in some cases}})
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0x4</code>, <code>flags_3 = 0x48</code> (or <code>0x8</code> if in parts bin)
* '''appearance''': Pulleys can have four different sprites depending on the orientation. Possible values are 0-3.
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': The size of the pulley sprite. In TIM 2 / 3, also depends on the orientation.
* '''pos_x''', '''pos_y''': The position of the pulley, top left coordinates of the bounding rectangle.
* '''behavior''', '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for ropes.
* '''pulley_rope_1_connect_pos_x''', '''pulley_rope_1_connect_pos_y''': The coordinates of the point where one rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''. Depends on the orientation of the pulley, like ''appearance''.
* '''unknown_36''', '''unknown_38''': Not used, always -1.
* '''unknown_40'', ''unknown_42''': Not used, always 0.
* '''pulley_rope_2_connect_pos_x''', '''pulley_rope_2_connect_pos_y''': The coordinates of the point where the other rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''.
* '''pulley_connected_1''', '''pulley_connected_2''': Either the index of part at one of the two ends of the rope, or the index of next or previous pulley the rope is running through.
* '''unknown_50''', '''unknown_52''': Not used, always -1.
* '''rope_index''': In TIM 2 / 3, the index of the rope part. Not used (-1) in TIM and TEMIM.

=== Programmable ball (TIM 2 / 3) ===

The programmable ball part is present in TIM 2 and 3, and its part type number is 87. The size of the entry is 60 bytes in total. The first 48 bytes is the same as the default part data structure, which is followed by another, 12-byte structure specific to this part. The format of the programmable ball data is:

UINT16LE density;
UINT16LE elasticity;
UINT16LE friction;
INT16LE gravity_buoyancy;
UINT16LE mass;
UINT16LE appearance_2;

* '''density''': The density of the ball, affects the buoyant force acting on the ball.
* '''elasticity''': The elasticity of the ball.
* '''friction''': The friction.
* '''gravity_buoyancy''': A calculated parameter, using the density and the mass of the ball, as well as the gravity and the pressure set for the puzzle. If its value is negative, the ball will rise due to the buoyant force rather than fall.
* '''mass''': The mass of the ball.
* '''appearance_2''': Has the same value as the ''appearance'' field. The ball can have 7 different colors/patterns.

The game has a dialog for setting the four physical properties (mass, elasticity, density, friction, in this order). However, the number stored in the data structure is not the same as the numbers shown on the program dialog. For example, if following settings are used for the ball: <code>mass = 8</code>, <code>elasticity = 3</code>, <code>density = 7</code>, <code>friction = 3</code>; and the default values are used for gravity/pressure, the puzzle file will contain the following values: <code>density = 3000</code>, <code>elasticity = 128</code>, <code>friction = 16</code>, <code>gravity_buoyancy = 269</code>, <code>mass = 201</code>. (Note: There is an inconsistency in the game here, the programmable ball part uses <code>density = 2832</code> and <code>mass = 200</code> by default, which does not correspond exactly to any value that can be set in the dialog.)

=== TIM demo version ===

In the demo version of the (original) TIM (available at several DOS shareware game websites), the ''flags_3'', ''outlet_plugged_1'' and ''outlet_plugged_2'' fields are missing.
Instead, the 42-byte part data (46 for belts, 48 for ropes, 50 for pulleys) is followed by an another, variable length data structure of unknown significance consisting of 16-bit little endian integers. It is always at least 2 bytes long, and the first two bytes contain the number of additional 16-bit words after this size word. The reverse engineering of this structure is complicated by the fact that it is only present in a demo version containing only 8 puzzles.

== Puzzle solution information ==

Puzzle solution information is only present in TIM 2 and TIM 3 puzzles. Its size is always 132 bytes and can contain 8 different conditions that must be satisfied so that the game will recognize the puzzle as solved. The first two bytes contains the number of such conditions actually set, in a 16-bit little endian format. This is followed by 8 entries, 16 bytes each, containing the required information for solution checking by the game. The format of each entry is:

INT16LE part_index;
UINT16LE part_state_1;
UINT16LE part_state_2;
UINT16LE part_count;
INT16LE position_rect_x;
INT16LE position_rect_y;
INT16LE position_rect_width;
INT16LE position_rect_height;

* '''part_index''': The index of the part in the puzzle file involved in the solution. -1 (0xFF 0xFF) for unused entries.
* '''part_state_1''': An ID for a "physical state" of a part (for example a balloon was popped or a candle was lit). In many puzzles, one specific part must be in a specified "physical state" in order to complete the level. This is the same ID for a "part state" as the ''first_frame_id'' member found in the C section of the part's ANM file.
* '''part_state_2''': Another ID for a "physical state", the exact meaning is unclear.
* '''part_count''': The value of the "Part count" option set in the "program solution" dialog of the game.
* '''position_rect_x''', '''position_rect_y''': The top left corner of the "position rectangle". If such a solution specified puzzle part must be located within this rectangle in order to solve the puzzle.
* '''position_rect_width''', '''position_rect_height''': Width and height of the "position rectangle", see above.

For the last four members ("position rectangle"), there are "fixed" combinations of values with special meaning:

* <code>-1, -1, -1, -1</code>: "Off screen", the part must leave the area visible on the game screen.
* <code>-500, -2000, 1640, 2000</code>: "Off top", the part must leave the visible area at the top.
* <code>-500, 400, 1640, 3000</code>: "Off bottom"
* <code>0, 0, 0, 0</code>: No such solution programmed, either this is "part state" solution or an unused entry (<code>part_index = -1</code>).

The last 2 bytes of the section contain the value of the "Delay" option set in the "program solution" dialog of the game, in 16-bit little endian format.

'''Note on puzzle solution information in TIM and TEMIM''': TIM / TEMIM puzzles do not contain such data. This can also be demonstrated by extracting e.g. <tt>L1.LEV</tt> from the archive file and rename the file to change the number. After starting the game, the level with the same number as the renamed file will be replaced with level 1. When playing the modified level, the game will not be able to check whether the puzzle is solved. Depending on its number, the level can become unwinnable or winnable by just clicking on the start machine button. Sometimes the game freezes.

== Tools ==

{{TODO|Level viewer will be published soon}}

== Credits ==

This file format was reverse engineered by [[User:Knt47|knt47]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

The Incredible Machine Level Format

2022-07-21T14:53:37Z

Knt47: Part info part 3, puzzle solution

{{Map Infobox
| Type =
| Layers =
| Tile size = Not tile based, the game uses a 16x16 grid for walls and a few other puzzle parts
| Viewport =
'''576×368''' (Levels in [[The Incredible Machine]] (TIM) and [[The Even More Incredible Machine]] (TEMIM))
'''640×400''' (.GKC files in TIM and TEMIM)
'''560×377''' (Levels in [[The Incredible Machine 2]] and 3)
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|The Incredible Machine 3}}
}}

This page discusses the '''level format''' of [[The Incredible Machine]], from the first DOS version (abbreviated as TIM 1) to [[The Incredible Machine 3|TIM 3]] (which is a 32-bit Windows game). Even if the format of some sections of the file vary significantly between the versions, the way how the parts are stored is highly similar.

The machines/puzzles saved from the "freeform machine" mode or the built-in level editor are also discussed here. The format of files saved from built-in editor may be identical to or slightly different from the levels, depending on the game version. The animated '''"title screen"''' (<tt>TITLE.GKC</tt>) and '''"credits screen"''' (<tt>CREDITS.GKC</tt>) files (inside the archive file) in TIM 1 and [[The Even More Incredible Machine]] (TEMIM) use a variant of the level file format, even if these are not playable levels.

== Magic number ==

TIM-TIM 3 level and GKC files always start with a 4-byte magic number. The following table summarizes the magic numbers found in various versions of the game.

{| class="wikitable"
! Magic number (hex) !! Usage in game versions
|-
| <code>ED AC 00 01</code>
|
* Puzzles in TIM demo version.
|-
| <code>ED AC 02 01</code>
|
* Puzzles in TIM.
* Saved freeform machines in TIM.
* GKC files in TIM.
* <tt>CREDITS.GKC</tt> in TEMIM.
|-
| <code>EE AC 05 01</code>
|
* New puzzles in TEMIM not found in TIM.
* Saved freeform machines in TEMIM.
* <tt>TITLE.GKC</tt> in TEMIM.
|-
| <code>EF AC 11 01</code>
<code>EF AC 12 01</code>
|
* A small number of puzzles in TIM 2 and 3.
|-
| <code>EF AC 13 01</code>
|
* The large majority of puzzles in TIM 2 and 3.
* Puzzles saved from the built-in editor of TIM 2.
|-
| <code>EF AC 14 01</code>
|
* A small number of puzzles in TIM 3.
* Puzzles saved from the built-in editor of TIM 3.
|}

== Structure of puzzle and GKC files ==

The level/puzzle/saved machine files consist of multiple sections. An overview of the file structure is provided below, separately for TIM / TEMIM and TIM 2 / TIM 3.

=== TIM and TEMIM ===

* Magic number, see above
* Puzzle title, null-terminated string. missing in .GKC files and "freeform machines" saved by the player.
* Goal description, null-terminated string. Absent from .GKC files and "saved freeform machines" with magic number of <code>ED AC 02 01</code>. Present in TEMIM "saved freeform machines" (magic number <code>EE AC 05 01</code>). An empty string in .GKC files with magic number <code>EE AC 05 01</code>.
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move ("fixed", e.g. walls) and are not found initially to the parts bin.
* List of part entry structures for parts that can move (e.g. balls), not in the parts bin.
* An additional 16-bit, little endian integer value in puzzles with magic number of <code>EE AC 05 01</code>. The meaning of this value is unclear. 0 in puzzles from the game archive file. In saved freeform machines, 1 if there are parts placed into the parts bin, 0 otherwise.
* List of part entry structures for parts initially placed into the parts bin.

=== TIM 2 and 3 ===

* Magic number, see above
* Two additional "header" bytes in files with magic number <code>EF AC 13 01</code> or <code>EF AC 14 01</code>. First byte is always 0, second is the background color from the 16-color palette.
* Puzzle title, null-terminated string
* Goal description, null-terminated string
* Hints, see below
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move
* List of part entry structures for parts that can move
* Solution information, see below

== Hints ==

Hints are supported only in TIM 2 and 3 puzzles. The first two bytes of the hint data contain the number of the hints in 16-bit little endian format. This is followed by 8 hint entries, some of them may be unused. A size of an unused entry is 7 bytes. One entry consists of three 16-bit integers and a null-terminated string containing the hint text. The three integer members are (all have a 16-bit little endian format):

* '''position_x''': The X position of the hand icon for the hint.
* '''position_y''': The Y position.
* '''hint_icon_flip''': The hand icon of a hint can be flipped and can have four different orientations. Possible values are 0-3.

In TIM 2, there are 3 (?) puzzles with magic number <code>EF AC 11 01</code>. Neither of these files contain hints. However, the size of the empty hints section is 42 bytes in them instead of the expected 58.

== Puzzle information data structure ==

=== In TIM and TEMIM ===

In TIM and TEMIM, there are two different puzzle header information data structures, one is used by the puzzles, and the another is found in saved "freeform" machines and the GKC files.

The information structure format in TIM / TEMIM puzzles:

[[UINT16LE]] bonus_1;
UINT16LE bonus_2;
[[INT16LE]] pressure;
INT16LE gravity;
INT16LE unknown_8;
INT16LE unknown_10;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

The information structure format in saved "freeform" machines and GKC files:

INT16LE pressure;
INT16LE gravity;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

* '''bonus_1''': The value of "Bonus 1" immediately after the puzzle is loaded (its value is constantly decreasing while the player is solving the puzzle).
* '''bonus_2''': The value of "Bonus 2" for the puzzle.
* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''unknown_8''', ''unknown_10'': The value of these two members is always -8. Perhaps the top left corner of the screen in the coordinate system used for puzzle parts, which is also (-8, -8).
* '''music''': ID of music track played. Valid values are 1001-1016 for TIM and 1001-1021 for TEMIM.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move (e.g. walls), not in the "parts bin".
* '''num_parts_moving''': Number of parts in the puzzles that move (e.g. balls), not in the "parts bin".
* '''num_parts_in_partsbin1''': The number of parts that are placed into the parts bin. (The player needs to position them in order to solve the puzzle.)

=== In TIM 2 and 3 ===

The information structure format in TIM 2 and 3:

INT16LE pressure;
INT16LE gravity;
UINT16LE unknown_4;
UINT16LE unknown_6;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE unknown_14;

* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''music''': ID of music track played. Valid values are 1000-1023.
* '''unknown_4''', '''unknown_6''': Meaning is unknown, always 0.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move, regardless of whether they are placed initially into the parts bin or not.
* '''num_parts_moving''': Number of parts in the puzzles that can move.
* '''unknown_14''': Value is always 0. Likely this member corresponds to num_parts_in_partsbin in TIM/TEMIM puzzle header. However, parts found in the parts bin are not a separate section in TIM 2 / 3,

== Puzzle part data ==

As already discussed in the With the exception of TIM demo version (see below), the size of a part entry for the majority of puzzle parts is 48 bytes. However, there are exceptions, which are discussed in separate sub-sections. The format of the "default" part entry:

UINT16LE part_type_num;
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
[[BYTE]] belt_connect_pos_x;
BYTE belt_connect_pos_y;
UINT16LE belt_line_distance;
UINT16LE unknown_32;
BYTE rope_1_connect_pos_x;
BYTE rope_1_connect_pos_y;
UINT16LE unknown_36;
BYTE rope_2_connect_pos_x;
BYTE rope_2_connect_pos_y;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''part_type_num''': A number associated with the type of the part (e.g. 0 - bowling ball). Required for identifying parts with an entry size different from the default.
* '''flags_1''': A combination of flag bits.
** '''TIM''' / '''TEMIM''' uses the following flag bits:
*** <code>0x20</code>: Unknown meaning, used for a few "moving" parts (bucket, candle)
*** <code>0x40</code>: Set if the part is a wall.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x800</code>: Part is placed initially into the parts bin (see num_parts_in_partsbin in part information data structure)
*** <code>0x1000</code>: "Moving" part, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x2000</code>: Part cannot move, in fixed position, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x4000</code>: Part cannot move, in fixed position (see ''num_parts_fixed'')
*** <code>0x8000</code>: Set when 0x800 is not set ({{TODO|further testing needed}})
** In '''TIM 2 / 3''', the bits have a known meaning:
*** <code>0x40</code>: Meaning unclear, used for "moving" parts only, but not always set, even for a single type of part.***
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x1000</code>: "Moving" part, affected by gravity.
*** <code>0x2000</code>, 0x4000: Used in combination for parts that do not move and are not affected by gravity.
* '''flags_2''': Another word containing flag bits. The meaning of most flags is the same in all game versions.
** <code>0x1</code>: A belt can be connected to the part.
** <code>0x2</code>: A belt is connected to the part.
** <code>0x4</code>: A rope can be connected to the part.
** <code>0x8</code>: A second rope can be connected to the part (teeter-totter)
** <code>0x10</code>: The part sprite is drawn horizontally flipped.
** <code>0x20</code>: The part sprite is drawn vertically flipped. Note on flip flags: Flipping a part in the game does not necessarily mean that one of the flip flags will be changed. For several parts, especially in TIM 2 / 3, flipping will affect the value of the ''appearance'' member.
** <code>0x40</code>: Probably unused
** <code>0x80</code>: Part can be stretched in at least one direction: inclines, conveyor belt, walls.
** <code>0x100</code>: Parts that can be stretched both horizontally and vertically, the walls.
* '''flags_3''': Some flags are only present in TIM 2 / 3. This member of the part data structure is missing in the demo version of TIM.
** <code>0x1</code>: The part can be plugged into an electric outlet.
** <code>0x2</code>: The part is an electric outlet.
** <code>0x4</code>: The part can burn (e.g. candle) or has a fuse that can be lit (e.g. dynamite, cannon). Usually in combination with flag 0x8.
** <code>0x8</code>: Meaning of this flag is unclear. Used for several part types, but changing it has no apparent consequence (?)
** Flags present only in '''TIM 2 / 3''':
*** <code>0x40</code>: Part is "locked", i.e not placed into the part bin.
*** <code>0x80</code>: Sizable scenery part (?)
*** <code>0x100</code>: {{TODO|unknown meaning}}
*** <code>0x400</code>: A "program" icon is shown for the part (?)
*** <code>0x1000</code>: Scenery part
*** <code>0x2000</code>: Wall part (?)
*** <code>0x8000</code>: A "Puzzle solution" icon is shown for the part (?)
* '''appearance''': An identifier for the sprite that is shown for a part before the machine is started. (Once the machine is started, the state of the part can change and so can the sprite shown.) The meaning is different between TIM and TIM 2. In TIM, the sprite of some parts consists of only one image, in this case, this is often the number of the sub-image in the image resource file. ({{TODO|For other parts, this is probably an internal identifier for the sprite (?)}}). In TIM 2 and 3, the meaning of the appearance is an index in the A section of the animation file for the part, or if this is absent, an index in the B section. "Programming" a part in TIM 2 and 3 often results in the change of this field.
* '''unknown_10''': Probably unused, usually 0.
* '''width_1''', '''height_1''': The width and height of the selectable area of the part ({{TODO|more reverse engineering work needed}})
* '''width_2''', '''height_2''': At least in TIM 2, witdh_2 is used for calculating the position of part sprite when the part is flipped because of the horizontal flip bit is set in flags_2.
* '''pos_x''', '''pos_y''': The position of the part, usually the top left corner of the bounding rectangle.
* '''behavior''': In TIM 2 and 3, a programmed behavior of the part. (However, for many parts, "programming" modifies the ''appearance'' member.) For example the number of shots of the phazer gun or character shown by the message computer. Meaning is different for rope parts, see below. Unused in TIM and TEMIM (except for ropes).
* '''unknown_26''': Probably unused, usually 0. Note that belt parts have a value of 1 in this position.
* '''belt_connect_pos_x''', '''belt_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Always positive or 0, because ''pos_x'' and ''pos_y'' are the coordinates of the top left corner where the sprite starts. Note that the formulas required for calculating the exact position of the belt are slightly different between TIM and TIM 2. Parts for which connection of a belt is allowed have a distinct circular area in their sprite, corresponding to the location where the belt is connected. In TIM / TEMIM, ''belt_connect_pos_x'' and ''belt_connect_pos_y'' is approximately the top left corner of its bounding rectangle, while in TIM 2 /3 it is close to the center of the circle.
* '''unknown_36''': Probably unused, usually 0.
* '''belt_line_distance''': The belts in the game appear as two, usually not perfectly parallel black (TIM / TEMIM) or gray (TIM 2 / 3) lines. This parameter determines the distance between the two segments, More precisely, it is either approximately the diameter of the circular area mentioned at ''belt_connect_pos_x'' and ''belt_connect_pos_y'' (TIM / TEMIM) or its radius (TIM 2 / 3).
* '''unknown_32''': Probably unused, usually 0.
* '''rope_1_connect_pos_x''', '''rope_1_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Similarly to belt_connect_pos_x/y, always positive or 0.
* '''rope_2_connect_pos_x''', '''rope_2_connect_pos_y''': The same as ''rope_1_connect_pos_x'', ''rope_1_connect_pos_y'', bit for another connected rope part.
* '''connected_1''', '''connected_2''': The index of one or two parts in the puzzle that are connected to this part with a rope. If the rope runs through pulleys, this is the part index of the first pulley. If no rope is connected or this is not possible for the part, the value of both structure members are -1. (Of course, if one rope is connected, the value of one structure member (usually connected_rope_1) is the index of the rope part and the other is -1) )In TIM 2 and 3, the "remote bomb" part actually corresponds to two entries in the puzzle file. The connected_rope_2 field contains the index of the another "element" of the bomb, in both entries.
* '''outlet_plugged_1''', '''outlet_plugged_2''': These structure members are only meaningful for electric outlet parts. Electric outlets always have 2 "sockets" for parts requiring electricity. It contains the index/indices of the part/parts plugged into the electric outlet, or -1 if the "socket" is free. If the part does not support this, both values are -1.

=== Belts ===

Belt parts (part 8) (except in the demo version of TIM, see below) use a 52-byte entry, with the following format:

UINT16LE part_type_num; /* 8 for belts */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
INT16LE belt_connected_part_1;
INT16LE belt_connected_part_2;
UINT16LE unknown_36;
UINT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0</code>, <code>flags_3 = 0</code>
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0</code>, <code>flags_3 = 0x40</code> (or <code>0</code> if in parts bin)
* '''appearance''': Always 0, belts have no true sprite (represented by two lines).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for belts, always 0.
* '''pos_x''', '''pos_y''' In TIM/TEMIM, either 0 or -1. In TIM 2, -1 or -100 (0xff9c). Meaning of these numbers is unclear, and the usage of the two different values do not correlate with the flags.
* '''behavior''': Not used, always 0.
* '''unknown_26''': Always 1, perhaps indicates that the part is a belt.
* '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''belt_connected_part_1''', '''belt_connected_part_2''': Index of the two parts in the puzzle connected by this belt. In TIM and TEMIM, both are -1 if the belt is placed into the parts bin.
* '''unknown_36''', '''unknown_38''', '''unknown_40''', '''unknown_42''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Ropes ===

Rope parts (part 10) (except in the demo version of TIM, see below) use a 54-byte entry. TIM 2 and 3 also have a "steel cable" part (part 76) which also behaves as a rope and the size of the part entry as also identical. The rope part entry has the following format:

UINT16LE part_type_num; /* 10 for rope, 76 for steel cable */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE rope_segment_length;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
UINT16LE unknown_36;
INT16LE rope_connected_part_1;
INT16LE rope_connected_part_2;
BYTE part_1_connect_field_usage;
BYTE part_2_connect_field_usage;
UINT16LE unknown_44;
UINT16LE unknown_46;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''': Same flags used as in the belt part structure.
* '''appearance''': Always 0, ropes have no true sprite (represented by one or more line segments).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for ropes, always 0.
* '''pos_x''', '''pos_y''': Similarly to belts, possible values are 0 and -1 in TIM / TEMIM; and -1 and -100 in TIM 2 / 3.
* '''rope_segment_length''': The length of the rope (Euclidean distance between the two ends) if the rope does not run through pulleys. Otherwise, the length of the rope segment between the part at one end (rope_connected_part_1 (?)) and the first pulley ({{TODO|additional testing needed}}).
* '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for pulleys.
* '''unknown_36''': Not used, always 0.
* '''rope_connected_part_1''', '''rope_connected_part_2''': Index of the two parts in the puzzle connected by this rope (never the pulleys). In TIM and TEMIM, both are -1 if the rope is placed into the parts bin.
* '''part_1_connect_field_usage''', '''part_2_connect_field_usage''': Whether ''connected_1'' or ''connected_2'' is used in the two connected parts for this rope. 0 if connected_1, 1 if connected_2. ({{TODO|additional testing needed}})
* '''unknown_44''', '''unknown_46''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Pulleys ===

The format of the 56-byte puzzle part entry for the pulley (part 7):

UINT16LE part_type_num; /* 7 for pulley */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
BYTE pulley_rope_1_connect_pos_x;
BYTE pulley_rope_1_connect_pos_y;
INT16LE unknown_36;
INT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
BYTE pulley_rope_2_connect_pos_x;
BYTE pulley_rope_2_connect_pos_y;
INT16LE pulley_connected_1;
INT16LE pulley_connected_2;
INT16LE unknown_50;
INT16LE unknown_52;
INT16LE rope_index;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0x4</code>, <code>flags_3 = 0x8</code> (<code>0x0</code> {{TODO|in some cases}})
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0x4</code>, <code>flags_3 = 0x48</code> (or <code>0x8</code> if in parts bin)
* '''appearance''': Pulleys can have four different sprites depending on the orientation. Possible values are 0-3.
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': The size of the pulley sprite. In TIM 2 / 3, also depends on the orientation.
* '''pos_x''', '''pos_y''': The position of the pulley, top left coordinates of the bounding rectangle.
* '''behavior''', '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for ropes.
* '''pulley_rope_1_connect_pos_x''', '''pulley_rope_1_connect_pos_y''': The coordinates of the point where one rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''. Depends on the orientation of the pulley, like ''appearance''.
* '''unknown_36''', '''unknown_38''': Not used, always -1.
* '''unknown_40'', ''unknown_42''': Not used, always 0.
* '''pulley_rope_2_connect_pos_x''', '''pulley_rope_2_connect_pos_y''': The coordinates of the point where the other rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''.
* '''pulley_connected_1''', '''pulley_connected_2''': Either the index of part at one of the two ends of the rope, or the index of next or previous pulley the rope is running through.
* '''unknown_50''', '''unknown_52''': Not used, always -1.
* '''rope_index''': In TIM 2 / 3, the index of the rope part. Not used (-1) in TIM and TEMIM.

=== Programmable ball (TIM 2 / 3) ===

The programmable ball part is present in TIM 2 and 3, and its part type number is 87. The size of the entry is 60 bytes in total. The first 48 bytes is the same as the default part data structure, which is followed by another, 12-byte structure specific to this part. The format of the programmable ball data is:

UINT16LE density;
UINT16LE elasticity;
UINT16LE friction;
INT16LE gravity_buoyancy;
UINT16LE mass;
UINT16LE appearance_2;

* '''density''': The density of the ball, affects the buoyant force acting on the ball.
* '''elasticity''': The elasticity of the ball.
* '''friction''': The friction.
* '''gravity_buoyancy''': A calculated parameter, using the density and the mass of the ball, as well as the gravity and the pressure set for the puzzle. If its value is negative, the ball will rise due to the buoyant force rather than fall.
* '''mass''': The mass of the ball.
* '''appearance_2''': Has the same value as the ''appearance'' field. The ball can have 7 different colors/patterns.

The game has a dialog for setting the four physical properties (mass, elasticity, density, friction, in this order). However, the number stored in the data structure is not the same as the numbers shown on the program dialog. For example, if following settings are used for the ball: <code>mass = 8</code>, <code>elasticity = 3</code>, <code>density = 7</code>, <code>friction = 3</code>; and the default values are used for gravity/pressure, the puzzle file will contain the following values: <code>density = 3000</code>, <code>elasticity = 128</code>, <code>friction = 16</code>, <code>gravity_buoyancy = 269</code>, <code>mass = 201</code>. (Note: There is an inconsistency in the game here, the programmable ball part uses <code>density = 2832</code> and <code>mass = 200</code> by default, which does not correspond exactly to any value that can be set in the dialog.)

=== TIM demo version ===

In the demo version of the (original) TIM (available at several DOS shareware game websites), the ''flags_3'', ''outlet_plugged_1'' and ''outlet_plugged_2'' fields are missing.
Instead, the 42-byte part data (46 for belts, 48 for ropes, 50 for pulleys) is followed by an another, variable length data structure of unknown significance consisting of 16-bit little endian integers. It is always at least 2 bytes long, and the first two bytes contain the number of additional 16-bit words after this size word. The reverse engineering of this structure is complicated by the fact that it is only present in a demo version containing only 8 puzzles.

== Puzzle solution information ==

Puzzle solution information is only present in TIM 2 and TIM 3 puzzles. Its size is always 132 bytes and can contain 8 different conditions that must be satisfied so that the game will recognize the puzzle as solved. The first two bytes contains the number of such conditions actually set, in a 16-bit little endian format. This is followed by 8 entries, 16 bytes each, containing the required information for solution checking by the game. The format of each entry is:

INT16LE part_index;
UINT16LE part_state_1;
UINT16LE part_state_2;
UINT16LE part_count;
INT16LE position_rect_x;
INT16LE position_rect_y;
INT16LE position_rect_width;
INT16LE position_rect_height;

* '''part_index''': The index of the part in the puzzle file involved in the solution. -1 (0xFF 0xFF) for unused entries.
* '''part_state_1''': An ID for a "physical state" of a part (for example a balloon was popped or a candle was lit). In many puzzles, one specific part must be in a specified "physical state" in order to complete the level. This is the same ID for a "part state" as the ''first_frame_id'' member found in the C section of the part's ANM file.
* '''part_state_2''': Another ID for a "physical state", the exact meaning is unclear.
* '''part_count''': The value of the "Part count" option set in the "program solution" dialog of the game.
* '''position_rect_x''', '''position_rect_y''': The top left corner of the "position rectangle". If such a solution specified puzzle part must be located within this rectangle in order to solve the puzzle.
* '''position_rect_width''', '''position_rect_height''': Width and height of the "position rectangle", see above.

For the last four members ("position rectangle"), there are "fixed" combinations of values with special meaning:

* <code>-1, -1, -1, -1</code>: "Off screen", the part must leave the area visible on the game screen.
* <code>-500, -2000, 1640, 2000</code>: "Off top", the part must leave the visible area at the top.
* <code>-500, 400, 1640, 3000</code>: "Off bottom"
* <code>0, 0, 0, 0</code>: No such solution programmed, either this is "part state" solution or an unused entry (<code>part_index = -1</code>).

The last 2 bytes of the section contain the value of the "Delay" option set in the "program solution" dialog of the game, in 16-bit little endian format.

'''Note on puzzle solution information in TIM and TEMIM''': TIM / TEMIM puzzles do not contain such data. This can also be demonstrated by extracting e.g. <tt>L1.LEV</tt> from the archive file and rename the file to change the number. After starting the game, the level with the same number as the renamed file will be replaced with level 1. When playing the modified level, the game will not be able to check whether the puzzle is solved. Depending on its number, the level can become unwinnable or winnable by just clicking on the start machine button. Sometimes the game freezes.

{{TODO| This is a work in progress.}}

The Incredible Machine Level Format

2022-07-21T14:38:40Z

Knt47: part data, part 2

{{Map Infobox
| Type =
| Layers =
| Tile size = Not tile based, the game uses a 16x16 grid for walls and a few other puzzle parts
| Viewport =
'''576×368''' (Levels in [[The Incredible Machine]] (TIM) and [[The Even More Incredible Machine]] (TEMIM))
'''640×400''' (.GKC files in TIM and TEMIM)
'''560×377''' (Levels in [[The Incredible Machine 2]] and 3)
| Games =
{{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
{{Game|The Incredible Machine 3}}
}}

This page discusses the '''level format''' of [[The Incredible Machine]], from the first DOS version (abbreviated as TIM 1) to [[The Incredible Machine 3|TIM 3]] (which is a 32-bit Windows game). Even if the format of some sections of the file vary significantly between the versions, the way how the parts are stored is highly similar.

The machines/puzzles saved from the "freeform machine" mode or the built-in level editor are also discussed here. The format of files saved from built-in editor may be identical to or slightly different from the levels, depending on the game version. The animated '''"title screen"''' (<tt>TITLE.GKC</tt>) and '''"credits screen"''' (<tt>CREDITS.GKC</tt>) files (inside the archive file) in TIM 1 and [[The Even More Incredible Machine]] (TEMIM) use a variant of the level file format, even if these are not playable levels.

== Magic number ==

TIM-TIM 3 level and GKC files always start with a 4-byte magic number. The following table summarizes the magic numbers found in various versions of the game.

{| class="wikitable"
! Magic number (hex) !! Usage in game versions
|-
| <code>ED AC 00 01</code>
|
* Puzzles in TIM demo version.
|-
| <code>ED AC 02 01</code>
|
* Puzzles in TIM.
* Saved freeform machines in TIM.
* GKC files in TIM.
* <tt>CREDITS.GKC</tt> in TEMIM.
|-
| <code>EE AC 05 01</code>
|
* New puzzles in TEMIM not found in TIM.
* Saved freeform machines in TEMIM.
* <tt>TITLE.GKC</tt> in TEMIM.
|-
| <code>EF AC 11 01</code>
<code>EF AC 12 01</code>
|
* A small number of puzzles in TIM 2 and 3.
|-
| <code>EF AC 13 01</code>
|
* The large majority of puzzles in TIM 2 and 3.
* Puzzles saved from the built-in editor of TIM 2.
|-
| <code>EF AC 14 01</code>
|
* A small number of puzzles in TIM 3.
* Puzzles saved from the built-in editor of TIM 3.
|}

== Structure of puzzle and GKC files ==

The level/puzzle/saved machine files consist of multiple sections. An overview of the file structure is provided below, separately for TIM / TEMIM and TIM 2 / TIM 3.

=== TIM and TEMIM ===

* Magic number, see above
* Puzzle title, null-terminated string. missing in .GKC files and "freeform machines" saved by the player.
* Goal description, null-terminated string. Absent from .GKC files and "saved freeform machines" with magic number of <code>ED AC 02 01</code>. Present in TEMIM "saved freeform machines" (magic number <code>EE AC 05 01</code>). An empty string in .GKC files with magic number <code>EE AC 05 01</code>.
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move ("fixed", e.g. walls) and are not found initially to the parts bin.
* List of part entry structures for parts that can move (e.g. balls), not in the parts bin.
* An additional 16-bit, little endian integer value in puzzles with magic number of <code>EE AC 05 01</code>. The meaning of this value is unclear. 0 in puzzles from the game archive file. In saved freeform machines, 1 if there are parts placed into the parts bin, 0 otherwise.
* List of part entry structures for parts initially placed into the parts bin.

=== TIM 2 and 3 ===

* Magic number, see above
* Two additional "header" bytes in files with magic number <code>EF AC 13 01</code> or <code>EF AC 14 01</code>. First byte is always 0, second is the background color from the 16-color palette.
* Puzzle title, null-terminated string
* Goal description, null-terminated string
* Hints, see below
* Puzzle information data structure, see below
* List of part entry structures for parts that cannot move
* List of part entry structures for parts that can move
* Solution information, see below

== Hints ==

Hints are supported only in TIM 2 and 3 puzzles. The first two bytes of the hint data contain the number of the hints in 16-bit little endian format. This is followed by 8 hint entries, some of them may be unused. A size of an unused entry is 7 bytes. One entry consists of three 16-bit integers and a null-terminated string containing the hint text. The three integer members are (all have a 16-bit little endian format):

* '''position_x''': The X position of the hand icon for the hint.
* '''position_y''': The Y position.
* '''hint_icon_flip''': The hand icon of a hint can be flipped and can have four different orientations. Possible values are 0-3.

In TIM 2, there are 3 (?) puzzles with magic number <code>EF AC 11 01</code>. Neither of these files contain hints. However, the size of the empty hints section is 42 bytes in them instead of the expected 58.

== Puzzle information data structure ==

=== In TIM and TEMIM ===

In TIM and TEMIM, there are two different puzzle header information data structures, one is used by the puzzles, and the another is found in saved "freeform" machines and the GKC files.

The information structure format in TIM / TEMIM puzzles:

[[UINT16LE]] bonus_1;
UINT16LE bonus_2;
[[INT16LE]] pressure;
INT16LE gravity;
INT16LE unknown_8;
INT16LE unknown_10;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

The information structure format in saved "freeform" machines and GKC files:

INT16LE pressure;
INT16LE gravity;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE num_parts_in_partsbin;

* '''bonus_1''': The value of "Bonus 1" immediately after the puzzle is loaded (its value is constantly decreasing while the player is solving the puzzle).
* '''bonus_2''': The value of "Bonus 2" for the puzzle.
* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''unknown_8''', ''unknown_10'': The value of these two members is always -8. Perhaps the top left corner of the screen in the coordinate system used for puzzle parts, which is also (-8, -8).
* '''music''': ID of music track played. Valid values are 1001-1016 for TIM and 1001-1021 for TEMIM.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move (e.g. walls), not in the "parts bin".
* '''num_parts_moving''': Number of parts in the puzzles that move (e.g. balls), not in the "parts bin".
* '''num_parts_in_partsbin1''': The number of parts that are placed into the parts bin. (The player needs to position them in order to solve the puzzle.)

=== In TIM 2 and 3 ===

The information structure format in TIM 2 and 3:

INT16LE pressure;
INT16LE gravity;
UINT16LE unknown_4;
UINT16LE unknown_6;
UINT16LE music;
UINT16LE num_parts_fixed;
UINT16LE num_parts_moving;
UINT16LE unknown_14;

* '''pressure''': The pressure set for the puzzle, the default value is 67.
* '''gravity''': Gravity set for the puzzle, the default value is 272.
* '''music''': ID of music track played. Valid values are 1000-1023.
* '''unknown_4''', '''unknown_6''': Meaning is unknown, always 0.
* '''num_parts_fixed''': Number of parts in the puzzles that cannot move, regardless of whether they are placed initially into the parts bin or not.
* '''num_parts_moving''': Number of parts in the puzzles that can move.
* '''unknown_14''': Value is always 0. Likely this member corresponds to num_parts_in_partsbin in TIM/TEMIM puzzle header. However, parts found in the parts bin are not a separate section in TIM 2 / 3,

== Puzzle part data ==

As already discussed in the With the exception of TIM demo version (see below), the size of a part entry for the majority of puzzle parts is 48 bytes. However, there are exceptions, which are discussed in separate sub-sections. The format of the "default" part entry:

UINT16LE part_type_num;
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
[[BYTE]] belt_connect_pos_x;
BYTE belt_connect_pos_y;
UINT16LE belt_line_distance;
UINT16LE unknown_32;
BYTE rope_1_connect_pos_x;
BYTE rope_1_connect_pos_y;
UINT16LE unknown_36;
BYTE rope_2_connect_pos_x;
BYTE rope_2_connect_pos_y;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''part_type_num''': A number associated with the type of the part (e.g. 0 - bowling ball). Required for identifying parts with an entry size different from the default.
* '''flags_1''': A combination of flag bits.
** '''TIM''' / '''TEMIM''' uses the following flag bits:
*** <code>0x20</code>: Unknown meaning, used for a few "moving" parts (bucket, candle)
*** <code>0x40</code>: Set if the part is a wall.
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x800</code>: Part is placed initially into the parts bin (see num_parts_in_partsbin in part information data structure)
*** <code>0x1000</code>: "Moving" part, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x2000</code>: Part cannot move, in fixed position, not placed into the pars bin initially ({{TODO|further testing needed}})
*** <code>0x4000</code>: Part cannot move, in fixed position (see ''num_parts_fixed'')
*** <code>0x8000</code>: Set when 0x800 is not set ({{TODO|further testing needed}})
** In '''TIM 2 / 3''', the bits have a known meaning:
*** <code>0x40</code>: Meaning unclear, used for "moving" parts only, but not always set, even for a single type of part.***
*** <code>0x200</code>: Part can be flipped vertically
*** <code>0x400</code>: Part can be flipped horizontally.
*** <code>0x1000</code>: "Moving" part, affected by gravity.
*** <code>0x2000</code>, 0x4000: Used in combination for parts that do not move and are not affected by gravity.
* '''flags_2''': Another word containing flag bits. The meaning of most flags is the same in all game versions.
** <code>0x1</code>: A belt can be connected to the part.
** <code>0x2</code>: A belt is connected to the part.
** <code>0x4</code>: A rope can be connected to the part.
** <code>0x8</code>: A second rope can be connected to the part (teeter-totter)
** <code>0x10</code>: The part sprite is drawn horizontally flipped.
** <code>0x20</code>: The part sprite is drawn vertically flipped. Note on flip flags: Flipping a part in the game does not necessarily mean that one of the flip flags will be changed. For several parts, especially in TIM 2 / 3, flipping will affect the value of the ''appearance'' member.
** <code>0x40</code>: Probably unused
** <code>0x80</code>: Part can be stretched in at least one direction: inclines, conveyor belt, walls.
** <code>0x100</code>: Parts that can be stretched both horizontally and vertically, the walls.
* '''flags_3''': Some flags are only present in TIM 2 / 3. This member of the part data structure is missing in the demo version of TIM.
** <code>0x1</code>: The part can be plugged into an electric outlet.
** <code>0x2</code>: The part is an electric outlet.
** <code>0x4</code>: The part can burn (e.g. candle) or has a fuse that can be lit (e.g. dynamite, cannon). Usually in combination with flag 0x8.
** <code>0x8</code>: Meaning of this flag is unclear. Used for several part types, but changing it has no apparent consequence (?)
** Flags present only in '''TIM 2 / 3''':
*** <code>0x40</code>: Part is "locked", i.e not placed into the part bin.
*** <code>0x80</code>: Sizable scenery part (?)
*** <code>0x100</code>: {{TODO|unknown meaning}}
*** <code>0x400</code>: A "program" icon is shown for the part (?)
*** <code>0x1000</code>: Scenery part
*** <code>0x2000</code>: Wall part (?)
*** <code>0x8000</code>: A "Puzzle solution" icon is shown for the part (?)
* '''appearance''': An identifier for the sprite that is shown for a part before the machine is started. (Once the machine is started, the state of the part can change and so can the sprite shown.) The meaning is different between TIM and TIM 2. In TIM, the sprite of some parts consists of only one image, in this case, this is often the number of the sub-image in the image resource file. ({{TODO|For other parts, this is probably an internal identifier for the sprite (?)}}). In TIM 2 and 3, the meaning of the appearance is an index in the A section of the animation file for the part, or if this is absent, an index in the B section. "Programming" a part in TIM 2 and 3 often results in the change of this field.
* '''unknown_10''': Probably unused, usually 0.
* '''width_1''', '''height_1''': The width and height of the selectable area of the part ({{TODO|more reverse engineering work needed}})
* '''width_2''', '''height_2''': At least in TIM 2, witdh_2 is used for calculating the position of part sprite when the part is flipped because of the horizontal flip bit is set in flags_2.
* '''pos_x''', '''pos_y''': The position of the part, usually the top left corner of the bounding rectangle.
* '''behavior''': In TIM 2 and 3, a programmed behavior of the part. (However, for many parts, "programming" modifies the ''appearance'' member.) For example the number of shots of the phazer gun or character shown by the message computer. Meaning is different for rope parts, see below. Unused in TIM and TEMIM (except for ropes).
* '''unknown_26''': Probably unused, usually 0. Note that belt parts have a value of 1 in this position.
* '''belt_connect_pos_x''', '''belt_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Always positive or 0, because ''pos_x'' and ''pos_y'' are the coordinates of the top left corner where the sprite starts. Note that the formulas required for calculating the exact position of the belt are slightly different between TIM and TIM 2. Parts for which connection of a belt is allowed have a distinct circular area in their sprite, corresponding to the location where the belt is connected. In TIM / TEMIM, ''belt_connect_pos_x'' and ''belt_connect_pos_y'' is approximately the top left corner of its bounding rectangle, while in TIM 2 /3 it is close to the center of the circle.
* '''unknown_36''': Probably unused, usually 0.
* '''belt_line_distance''': The belts in the game appear as two, usually not perfectly parallel black (TIM / TEMIM) or gray (TIM 2 / 3) lines. This parameter determines the distance between the two segments, More precisely, it is either approximately the diameter of the circular area mentioned at ''belt_connect_pos_x'' and ''belt_connect_pos_y'' (TIM / TEMIM) or its radius (TIM 2 / 3).
* '''unknown_32''': Probably unused, usually 0.
* '''rope_1_connect_pos_x''', '''rope_1_connect_pos_y''': The coordinates of the point where a rope is connected to the part, relative to ''pos_x'' and ''pos_y''. Similarly to belt_connect_pos_x/y, always positive or 0.
* '''rope_2_connect_pos_x''', '''rope_2_connect_pos_y''': The same as ''rope_1_connect_pos_x'', ''rope_1_connect_pos_y'', bit for another connected rope part.
* '''connected_1''', '''connected_2''': The index of one or two parts in the puzzle that are connected to this part with a rope. If the rope runs through pulleys, this is the part index of the first pulley. If no rope is connected or this is not possible for the part, the value of both structure members are -1. (Of course, if one rope is connected, the value of one structure member (usually connected_rope_1) is the index of the rope part and the other is -1) )In TIM 2 and 3, the "remote bomb" part actually corresponds to two entries in the puzzle file. The connected_rope_2 field contains the index of the another "element" of the bomb, in both entries.
* '''outlet_plugged_1''', '''outlet_plugged_2''': These structure members are only meaningful for electric outlet parts. Electric outlets always have 2 "sockets" for parts requiring electricity. It contains the index/indices of the part/parts plugged into the electric outlet, or -1 if the "socket" is free. If the part does not support this, both values are -1.

=== Belts ===

Belt parts (part 8) (except in the demo version of TIM, see below) use a 52-byte entry, with the following format:

UINT16LE part_type_num; /* 8 for belts */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
INT16LE belt_connected_part_1;
INT16LE belt_connected_part_2;
UINT16LE unknown_36;
UINT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0</code>, <code>flags_3 = 0</code>
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0</code>, <code>flags_3 = 0x40</code> (or 0 if in parts bin)
* '''appearance''': Always 0, belts have no true sprite (represented by two lines).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for belts, always 0.
* '''pos_x''', '''pos_y''' In TIM/TEMIM, either 0 or -1. In TIM 2, -1 or -100 (0xff9c). Meaning of these numbers is unclear, and the usage of the two different values do not correlate with the flags.
* '''behavior''': Not used, always 0.
* '''unknown_26''': Always 1, perhaps indicates that the part is a belt.
* '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''belt_connected_part_1''', '''belt_connected_part_2''': Index of the two parts in the puzzle connected by this belt. In TIM and TEMIM, both are -1 if the belt is placed into the parts bin.
* '''unknown_36''', '''unknown_38''', '''unknown_40''', '''unknown_42''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Ropes ===

Rope parts (part 10) (except in the demo version of TIM, see below) use a 54-byte entry. TIM 2 and 3 also have a "steel cable" part (part 76) which also behaves as a rope and the size of the part entry as also identical. The rope part entry has the following format:

UINT16LE part_type_num; /* 10 for rope, 76 for steel cable */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE rope_segment_length;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
UINT16LE unknown_36;
INT16LE rope_connected_part_1;
INT16LE rope_connected_part_2;
BYTE part_1_connect_field_usage;
BYTE part_2_connect_field_usage;
UINT16LE unknown_44;
UINT16LE unknown_46;
INT16LE connected_1;
INT16LE connected_2;
INT16LE outlet_plugged_1;
INT16LE outlet_plugged_2;

* '''flags''': Same flags used as in the belt part structure.
* '''appearance''': Always 0, ropes have no true sprite (represented by one or more line segments).
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': Not used for ropes, always 0.
* '''pos_x''', '''pos_y''': Similarly to belts, possible values are 0 and -1 in TIM / TEMIM; and -1 and -100 in TIM 2 / 3.
* '''rope_segment_length''': The length of the rope (Euclidean distance between the two ends) if the rope does not run through pulleys. Otherwise, the length of the rope segment between the part at one end (rope_connected_part_1 (?)) and the first pulley ({{TODO|additional testing needed}}).
* '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for pulleys.
* '''unknown_36''': Not used, always 0.
* '''rope_connected_part_1''', '''rope_connected_part_2''': Index of the two parts in the puzzle connected by this rope (never the pulleys). In TIM and TEMIM, both are -1 if the rope is placed into the parts bin.
* '''part_1_connect_field_usage''', '''part_2_connect_field_usage''': Whether ''connected_1'' or ''connected_2'' is used in the two connected parts for this rope. 0 if connected_1, 1 if connected_2. ({{TODO|additional testing needed}})
* '''unknown_44''', '''unknown_46''': Not used, always 0.
* '''connected_1''', '''connected_2''', '''outlet_plugged_1''', '''outlet_plugged_2''': Not used, always -1.

=== Pulleys ===

The format of the 56-byte puzzle part entry for the pulley (part 7):

UINT16LE part_type_num; /* 7 for pulley */
UINT16LE flags_1;
UINT16LE flags_2;
UINT16LE flags_3;
UINT16LE appearance;
UINT16LE unknown_10;
UINT16LE width_1;
UINT16LE height_1;
UINT16LE width_2;
UINT16LE height_2;
INT16LE pos_x;
INT16LE pos_y;
UINT16LE behavior;
UINT16LE unknown_26;
UINT16LE unknown_28;
UINT16LE unknown_30;
UINT16LE unknown_32;
BYTE pulley_rope_1_connect_pos_x;
BYTE pulley_rope_1_connect_pos_y;
INT16LE unknown_36;
INT16LE unknown_38;
UINT16LE unknown_40;
UINT16LE unknown_42;
BYTE pulley_rope_2_connect_pos_x;
BYTE pulley_rope_2_connect_pos_y;
INT16LE pulley_connected_1;
INT16LE pulley_connected_2;
INT16LE unknown_50;
INT16LE unknown_52;
INT16LE rope_index;

* '''flags''' (see meaning of the individual flags at the "default" part data structure):
** '''TIM''' / '''TEMIM''': <code>flags_1 = 0xe000</code> (or <code>0x4800</code> if in parts bin), <code>flags_2 = 0x4</code>, <code>flags_3 = 0x8</code> (<code>0x0</code> {{TODO|in some cases}})
** '''TIM 2 / 3''': <code>flags_1 = 0x6000</code>, <code>flags_2 = 0x4</code>, <code>flags_3 = 0x48</code> (or <code>0x8</code> if in parts bin)
* '''appearance''': Pulleys can have four different sprites depending on the orientation. Possible values are 0-3.
* '''unknown_10''': Not used, always 0.
* '''width_1''', '''height_1''', '''width_2''', '''height_2''': The size of the pulley sprite. In TIM 2 / 3, also depends on the orientation.
* '''pos_x''', '''pos_y''': The position of the pulley, top left coordinates of the bounding rectangle.
* '''behavior''', '''unknown_26''', '''unknown_28''', '''unknown_30''': Not used, always 0.
* '''unknown_32''': Always 1, same value is used for ropes.
* '''pulley_rope_1_connect_pos_x''', '''pulley_rope_1_connect_pos_y''': The coordinates of the point where one rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''. Depends on the orientation of the pulley, like ''appearance''.
* '''unknown_36''', '''unknown_38''': Not used, always -1.
* '''unknown_40'', ''unknown_42''': Not used, always 0.
* '''pulley_rope_2_connect_pos_x''', '''pulley_rope_2_connect_pos_y''': The coordinates of the point where the other rope segment is connected to the pulley, relative to ''pos_x'' and ''pos_y''.
* '''pulley_connected_1''', '''pulley_connected_2''': Either a the index of part at one of the two ends of the rope, or the index of next or previous pulley the rope is running through.
* '''unknown_50''', '''unknown_52''': Not used, always -1.
* '''rope_index''': In TIM 2 / 3, the index of the rope part. Not used (-1) in TIM and TEMIM.

{{TODO| This is a work in progress.}}

The Incredible Machine Level Format

2022-07-21T14:15:42Z

Knt47: Puzzle part data

The Incredible Machine Level Format

2022-07-21T13:55:29Z

Knt47: puzzle information structure, TIM 2 / 3 hints

The Incredible Machine Level Format

2022-07-21T13:45:20Z

Knt47: TIM level file structure

The Incredible Machine Level Format

2022-07-21T13:35:56Z

Knt47: /* Magic number */

The Incredible Machine Level Format

2022-07-21T13:34:16Z

Knt47:

The Incredible Machine Level Format

2022-07-21T13:24:17Z

Knt47: Created page with "{{Map Infobox | Type = | Layers = | Tile size = Not tile based, the game uses a 16x16 grid for walls and a few other puzzle parts | Viewport = '''576×368''' (Levels..."

TIM Resource Format

2021-01-24T23:09:44Z

Knt47: /* Bitmap Subfiles */ add link to new page

{{NeedMoreInfo}}
{{Archive Infobox
| MaxFiles = 65,535
| FAT = External + embedded
| Names = Yes, 8.3
| Metadata = None
| Subdirectories = N
| Compressed = N
| Encrypted = N
| Hidden = N
| Games =
{{Game|The Incredible Machine}}
}}
The '''TIM Resource Format''' is used by [[The Incredible Machine]] to store much of the game data.

== File format ==

The format comprised of multiple files. The index file is a <tt>.MAP</tt> file which stores the offsets of each subfile. The subfile data is split between a number of real files, and the <tt>.MAP</tt> file also provides the filenames of these real files. In [[The Incredible Machine]], the index file is called <tt>RESOURCE.MAP</tt> and the data files are <tt>RESOURCE.001</tt> to <tt>RESOURCE.004</tt>.

In theory data can be read from the data files alone (without the <tt>.MAP</tt> file) however if the data is to be modified then the <tt>.MAP</tt> file will have to be updated with the new offsets.

=== Signature ===

There is no known signature, other than carefully reading the file structure and verifying it seems correct (e.g. offsets don't go past the end of the file.) The data filenames can also be read from the <tt>.MAP</tt> file and checked to see whether they exist in the current directory.

=== Structure ===

The <tt>.MAP</tt> file begins with a header:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[BYTE]][4] || hash_idx || Hash string indexes
|-
| [[UINT16LE]] || fileCount || Number of data files
|}

Note that hash indexes are hardcoded in the game execuatable file as sequences <tt>0, 1, '''6''', 7</tt>, but the actual .MAP file uses <tt>0, 1, '''5''', 7</tt> so the internal table will be overwritten with these new values.

This is then followed by a file structure, repeated <tt>fileCount</tt> times:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[char]][13] || filename || Filename of real data file (DOS 8.3, null terminated)
|-
| [[UINT16LE]] || count || Number of file entries
|-
| FILE_ENTRY[count] || entry || Actual file entries
|}

A single <tt>FILE_ENTRY</tt> is defined as:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[INT32LE]] || hash || Filename hash (see below)
|-
| [[UINT32LE]] || offset || Offset of file from start of data
|}

To read the subfile data, the filename must be read from the <tt>.MAP</tt> file (the <tt>filename</tt> field above) along with the <tt>offset</tt>. The file identified by <tt>filename</tt> must then be opened. It should
be in the same directory as the <tt>.MAP</tt> file. Seeking to <tt>offset</tt> in this newly opened file will result in the file pointer being at the start of the subfile header:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[char]][13] || filename || Filename of subfile (DOS 8.3, null terminated)
|-
| [[UINT32LE]] || len || Length of subfile data, in bytes
|-
| [[BYTE]][len] || content || Subfile content
|}

If the <tt>.MAP</tt> file is not being used, the data files simply consist of the above subfile header and data concatenated one after the other. Subfiles aren't split between real files, so each data file can be considered independent (with the exception that the <tt>.MAP</tt> file contains the offsets for all the subfiles across all the data files.)

The game search for required file (like <tt>VM.OVL</tt>) in the current folder and if it didn't there then it calc a hash from filename (<tt>0x564CF4C0</tt> in this example) and search inside the <tt>.MAP</tt> file index.

Here is a hash routine for the filenames:
<source lang="c">
/*
input:
s - pointer to ASCIIZ filename string
idx - pointer to an array of 4 bytes (hash indexes)
return:
hash - filename hash
*/
int32_t tim_hash(char *s, uint8_t *idx) {
int32_t i, c;
int16_t isum, ixor;
isum = 0;
ixor = 0;
for (i = 0; s[i]; i++) {
c = toupper(s[i]);
isum += c;
ixor ^= c;
}
/* both types here MUST be int16_t */
isum *= ixor;
c = 0;
for (ixor = 0; ixor < 4; ixor++) {
c <<= 8;
/* can use only existing characters
("i" holds the string length now) */
if (i > idx[ixor]) {
c |= toupper(s[idx[ixor]]);
}
}
c += isum;
return(c);
}

/*
// this MUST be overwritten with the correct one from the .MAP file!
uint8_t idx[4] = {0, 1, 6, 7}; // 0, 1, 5, 7
// example of usage
printf("%08X\n", tim_hash("vm.ovl", idx));
*/
</source>

== Bitmap Subfiles ==

See [[The Incredible Machine image format]].

This is an example of PART23.BMP which is the smalles of the bitmap files. It contains one sprite which is 16x16 pixels in size.

If anyone knows the compression used in the SCN section, please let me know. The length of the compressed data is 127:
https://cloud.githubusercontent.com/assets/1974959/25874475/03651bf0-3513-11e7-98bb-b3640c20fb6f.png

PART28.BMP, the second largest bitmap and only 16x15 px in size, contains 137 compressed bytes:
https://cloud.githubusercontent.com/assets/1974959/25874624/9f622b10-3513-11e7-8f24-d66877c0ad84.png

== Tools ==

{{BeginFileFormatTools|Type=group}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| canExtract = Yes
| canDecompress = N/A
| canCreate = Yes
| canModify = Yes
| canCompress = N/A
| editHidden = N/A
| editMetadata = N/A
}}
{{EndFileFormatTools}}

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

The Incredible Machine Image Format

2021-01-24T23:01:56Z

Knt47: add category

{{Image Infobox
| Hardware1 = VGA
| Depth = 4-bit

| Palette = Shared

| HasTransparency = Yes
| HasHitmap = No
| Games = {{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
}}

'''The Incredible Machine''' (TIM) '''bitmap images''' are stored in the <tt>RESOURCE.00?</tt> [[TIM Resource Format|resource files]] as sub-files. They have the extension <tt>.BMP</tt>.

(For full-screen images (<tt>*.SCR</tt>), see [[RES Format (Stellar 7)#SCR: Fullscreen image|Stellar 7 RES Format]].)

== Chunk format ==

The files have a small header (8 bytes long): "<tt>BMP:</tt>" followed by a 32-bit integer number stored in little-endian format. The more significant 16 bits of the number are always 0x8000.

The first chunk after the header is the "<tt>INF:</tt>" chunk. It has a typical Dynamix chunk format: The chunk name is followed by the chunk size (unsigned 32-bit integer in little-endian format). It contains the number of "sub-images", and two arrays containing the width and height of each (all values are encoded in a 16-bit little-endian format). This chunk format is documented here: [[RES Format (Stellar 7)#BMP: images]]. Based on the chunk type that contains the image data, there are two "types" of images:

* The majority of the image files in TIM, including the graphics for puzzle parts, contain an "<tt>SCN:</tt>" and an "<tt>OFS:</tt>" chunk. The image data is stored in the "<tt>SCN:</tt>" chunk while the "<tt>OFS:</tt>" contains the 32-bit offsets for each sub image. The "<tt>SCN:</tt>" chunk type has its own compression format, described in the next section.
* The remaining files contain a "BIN:" chunk (e.g. <tt>MOUSE.BMP</tt>, <tt>PARTBIN.BMP</tt>).

(Note: All chunks mentioned above start with the chunk size (32-bit unsigned integer), similarly to "<tt>INF:</tt>".)

== Images containing an "SCN:" and an "OFS:" chunk ==

=== The "SCN:" chunk ===

The <tt>"SCN:"</tt> chunk contains the pixel data for each sub-image. Basically, it has a run-length encoded format, with a special treatment of transparency. The data for each sub-image starts with a byte that has a special meaning: its value is added to all pixel values. Typical values are 1-5. The value of this byte is 0xFF in some "empty" images containing only a few transparent pixels. The next byte is the first "control" byte. A control byte can encode four "commands" depending on its most significant two bits.

*<tt>00......</tt>: Start a new line in the image, and move the current "x" position to the left with a number of pixels stored in the least significant 6 bits. The file may contain two consecutive bytes where the most significant 2 bits are zero. The meaning of such a sequence depends on the width of the sub-image. If the image is at least 64 pixels wide, it is interpreted as a single jump with a 12-bit size. {{TODO|This may need additional testing, but the result seems to be pixel-exact for a large number of images.}} Otherwise, the two bytes are treated as two separate command bytes. The remaining pixels in current line, as well as the first "new x position" bytes in the next one will be transparent.

*<tt>01......</tt>: Add transparent pixels, the number is determined by the least significant 6 bits. Numbers greater than 63 can be encoded as e.g. 0x7F 0x47. A control byte of 0x40 is (part of a) terminator (see below).

*<tt>10......</tt>: A sequence of pixels of the same color. The repeat count is specified by the least significant 6 bits of the control byte. A single byte follows the control byte, containing the pixel color. As the game uses a 16-color palette, the most significant 4 bits of this byte are always zero.

*<tt>11......</tt>: A sequence of pixel values with a specified length. The length (in pixels, not bytes) is determined by the least significant 6 bits of the "control" byte. The number of the "data" bytes after the "control" byte can be calculated as: <code>(length_in_pixels + 1) >> 1</code>. Each byte encodes two pixels, the color of leftmost pixel is stored in the most significant nibble. If the number of pixels is odd, the most significant 4 bits of the last byte contains the color of the last pixel, and the less significant nibble is zero.

Nearly all sub-images are "terminated" by the byte sequence 0x00 0x40, however there are a few exceptions (0x40 alone.)

=== The "OFS:" chunk ===

The "<tt>OFS:</tt>" chunk contains the offsets for each sub-image in the "SCN:" chunk (each offset is a 32-bit integer). The first is always zero.

== Images containing a "BIN:" chunk ==

The "BIN:" chunk has a small header containing the compression algorithm (1 byte) and uncompressed size (4 bytes, unsigned, little-endian). It supports the same compression algorithms as [[Dynamix Font Format v4-v5#Compression|Dynamix fonts]]. The header is followed by the compressed 4BPP pixel data. (Note: This format is related to the [[RES Format (Stellar 7)#BMP: Image|BMP images in Stellar 7]]).

== Tools ==

* A viewer and converter program has been uploaded to the VOGONS forum: [https://www.vogons.org/viewtopic.php?f=5&t=76910]
* [[Engie File Converter]] can open files that contain a <tt>"BIN:"</tt> chunk. However, it does not support the <tt>"SCN:"</tt> data format.

[[Category:Sierra/Dynamix File Formats]]

The Incredible Machine Image Format

2021-01-24T22:58:51Z

Knt47: Add content #2

User:Knt47

2021-01-24T22:08:51Z

Knt47: fix link

I'm working on the reverse engineering of some file formats found in the The Incredible Machine game series. I have already reverse engineered the "SCN:" chunk format found in many image resources in TIM, TEMIM and TIM2. This format is mentioned on the page [[TIM_Resource_Format]], but no reverse engineering tool I'm aware of seems to support it. I'm also interested in other file formats in these games, especially the level/puzzle files.

The Incredible Machine

2021-01-24T22:05:07Z

Knt47:

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

This section lists the file formats used in the game.

=== Resource file format ===
See [[TIM Resource Format]]. Resource sub-files are stored in files named <tt>RESOURCE.00?</tt>. The Incredible Machine has four such files: <tt>RESOURCE.001</tt>-<tt>.004</tt>. (However, the demo versions of both The Incredible Machine and The Even More Incredible Machine has only one. {{TODO|Add information for The Even More Incredible Machine.}}) The <tt>RESOURCE.MAP</tt> file contains the offsets for the sub-files.

=== Files inside the RESOURCE.00? archive files ===
{|class="wikitable"
! File name or extension !! Description
|-
| <tt>*.BMP</tt> || 16-color images. See [[The Incredible Machine image format]].
|-
| <tt>MEMOFNT8.FNT</tt> || 1BPP font, [[Dynamix Font Format v4-v5|Dynamix Font Format v4]].
|-
| <tt>CREDITS.GKC</tt> <tt>TITLE.GKC</tt> || Title screen and credits animation. File format seems to be related to the levels.
|-
| <tt>SX.OVL</tt> <tt>VM.OVL</tt> || {{TODO|TODO: Add information}}
|-
| <tt>*.PAL</tt> || VGA palettes. Similar to the palette format of [[RES Format (Stellar 7)#PAL: Palette|Stellar 7]].
|-
| <tt>*.SCR</tt> || Full-screen image (640x480x16 color). See [[RES Format (Stellar 7)#SCR: Fullscreen image|RES Format (Stellar 7)]].
|-
| <tt>TIM.SX</tt> || Sound and music. {{TODO|TODO: Add information}}
|-
| <tt>L*.TIM</tt> || Level/puzzle files. 
|-
| <tt>PASSWORD.TXT</tt> || Plain text file. Contains passwords for each level.
|-
|}

== See also ==
* [[RES Format (Stellar 7)]] - Contains the documentation for several identical or related file formats.

[[Category:Sierra/Dynamix]]
[[Category:Puzzle]]

The Incredible Machine Image Format

2021-01-24T21:57:55Z

Knt47: Add content

{{Image Infobox
| Hardware1 = VGA
| Depth = 4-bit

| Palette = Shared

| HasTransparency = Yes
| HasHitmap = No
| Games = {{Game|The Incredible Machine}}
{{Game|The Even More Incredible Machine}}
{{Game|The Incredible Machine 2}}
}}

'''The Incredible Machine''' (TIM) '''bitmap images''' are stored in the <tt>RESOURCE.00?</tt> [[TIM Resource Format|resource files]] as sub-files. They have the extension <tt>.BMP</tt>.

(For full-screen images (<tt>*.SCR</tt>), see [[RES Format (Stellar 7)#SCR: Fullscreen image|Stellar 7 RES Format]])

== Chunk format ==

The files have a small header (8 bytes long): "<tt>BMP:</tt>" followed by a 32-bit integer number stored in little-endian format. The more significant 16 bits of the number are always 0x8000.

The first chunk after the header is the "<tt>INF:</tt>" chunk. It has a typical Dynamix chunk format: The chunk name is followed by the chunk size (unsigned 32-bit integer in little-endian format). It contains the number of "sub-images", and two arrays containing the width and height of each (all values are encoded in a 16-bit little-endian format). This chunk format is documented here: [[RES Format (Stellar 7)#BMP: images]]. Based on the chunk type that contains the image data, there are two "types" of images:

* The majority of the image files in TIM, including the graphics for puzzle parts, contain an "<tt>SCN:</tt>" and an "<tt>OFS:</tt>" chunk. The image data is stored in the "<tt>SCN:</tt>" chunk while the "<tt>OFS:</tt>" contains the 32-bit offsets for each sub image. The "<tt>SCN:</tt>" chunk type has its own compression format, described in the next section,
* The remaining files contain a "BIN:" chunk (e.g. <tt>MOUSE.BMP</tt>, <tt>PARTBIN.BMP</tt>). The "BIN:" chunk has a small header containing the compression algorithm (1 byte) and uncompressed size (4 bytes).

(Note: All chunks mentioned above start with the chunk size, (32-bit unsigned integer) similarly to "<tt>INF:</tt>").

== Images containing an "SCN:" and an "OFS:" chunk ==

=== The "SCN:" chunk ===

The <tt>"SCN:"</tt> chunk contains the pixel data for each sub-image. Basically, it has a run-length encoded format, with a special treatment of transparency. The data for each sub-image starts with a byte that has a special meaning: its value is added to all pixel values. Typical values are 1-5. The value of this byte is 0xFF in some "empty" images containing only a few transparent pixels. The next byte is the first "control" byte. A control byte can encode four "commands" depending on its most significant two bits.

*<tt>00......</tt>: Start a new line in the image, and move the current "x" position to the left with a number of pixels stored in the least significant 6 bits. The file may contain two consecutive bytes where the most significant 2 bits are zero. The meaning of such a sequence depends on the width of the sub-image. If the image is at least 64 pixels wide, it is interpreted as a single jump with a 12-bit size. {{TODO|This may need additional testing, but the result seems to be pixel-exact for a large number of images.}} Otherwise, the two bytes are treated as two separate command bytes. The remaining pixels in current line, as well as the first "new x position" bytes in the next one will be transparent.

*<tt>01......</tt>: Add transparent pixels, the number is determined by the least significant 6 bits. Numbers greater than 63 can be encoded as e.g. 0x7F 0x47. A control byte of 0x40 is (part of a) terminator (see below).

*<tt>10......</tt>: A sequence of pixels of the same color. The repeat count is specified by the least significant 6 bits of the control byte. A single byte follows the control byte, containing the pixel color. As the game uses a 16-color palette, the most significant 4 bits of this byte are always zero.

*<tt>11......</tt>: A sequence of pixel values with a specified length. The length (in pixels, not bytes) is determined by the least significant 6 bits of the "control" byte. The number of the "data" bytes after the "control" byte can be calculated as: <code>(length_in_pixels + 1) >> 1</code>. Each byte encodes two pixels, the color of leftmost pixel is stored in the most significant nibble. If the number of pixels is odd, the most significant 4 bits of the last byte contains the color of the last pixel, and the less significant nibble is zero.

Nearly all sub-images are "terminated" by the byte sequence 0x00 0x40, however there are a few exceptions (0x40 alone.)

=== The "OFS:" chunk ===

The "OFS:" chunk contains the offsets for each sub-image in the "SCN:" chunk (each offset is a 32-bit integer). The first is always zero.

The Incredible Machine Image Format

2021-01-24T21:13:35Z

Knt47: First version, will be expanded soon

The Incredible Machine

2021-01-24T19:32:44Z

Knt47:

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

This section lists the file formats used in the game.

=== Resource file format ===
See [[TIM Resource Format]]. Resource sub-files are stored in files named <tt>RESOURCE.00?</tt>. The Incredible Machine has four such files: <tt>RESOURCE.001</tt>-<tt>.004</tt>. (However, the demo versions of both The Incredible Machine and The Even More Incredible Machine has only one. {{TODO|Add information for The Even More Incredible Machine.}}) The <tt>RESOURCE.MAP</tt> file contains the offsets for the sub-files.

=== Files inside the RESOURCE.00? archive files ===
{|class="wikitable"
! File name or extension !! Description
|-
| <tt>*.BMP</tt> || 16-color images. See [[The Incredible Machine image format]].
|-
| <tt>MEMOFNT8.FNT</tt> || 1BPP font, [[Dynamix Font Format v4-v5|Dynamix Font Format v4]].
|-
| <tt>CREDITS.GKC</tt> <tt>TITLE.GKC</tt> || Title screen and credits animation. File format seems to be related to the levels.
|-
| <tt>SX.OVL</tt> <tt>VM.OVL</tt> || {{TODO|Add documentation}}
|-
| <tt>*.PAL</tt> || VGA palettes. Similar to the palette format of [[RES Format (Stellar 7)#PAL: Palette|Stellar 7]].
|-
| <tt>*.SCR</tt> || Full-screen image (640x480x16 color). See [[RES Format (Stellar 7)#SCR: Fullscreen image|RES Format (Stellar 7)]].
|-
| <tt>TIM.SX</tt> || Sound and music. {{TODO|Add documentation}}
|-
| <tt>L*.TIM</tt> || Level/puzzle files. 
|-
| <tt>PASSWORD.TXT</tt> || Plain text file. Contains passwords for each level.
|-
|}

== See also ==
* [[RES Format (Stellar 7)]] - Contains the documentation for several identical or related file formats.

[[Category:Sierra/Dynamix]]
[[Category:Puzzle]]