Talk:Inverse Frequency Sound format

2022-01-29T14:07:30Z

Videogamer555: /* There appears to be a discrepency here. */

How does this sound format handle sounds who's period is zero (frequency is infinite)? This causes a divide-by-zero error when actually computed.
[[User:Videogamer555|Videogamer555]] ([[User talk:Videogamer555|talk]]) 13:27, 29 January 2022 (GMT)

== There appears to be a discrepency here. ==

In the Sound Definitions section, in the table it says "UINT8 rate Defines the update rate of the timer generating the sound interrupt. Usually set to 8. "

However in the paragraph right after that table, it says "The PC Speaker is updated at a rate of usually 140 Hz". So which is it? Is it 8Hz or 140Hz update rate? Or does the 8 mean something else? Does it scale the update rate, where 140Hz is represented by that field containing the number 8, so each increment of 1 in that field changes the PC speaker's update rate by 17.5Hz, with 0 meaning never update the PC speaker?

[[User:Videogamer555|Videogamer555]] ([[User talk:Videogamer555|talk]]) 14:07, 29 January 2022 (GMT)

Talk:Inverse Frequency Sound format

2022-01-29T14:06:37Z

Videogamer555: /* There appears to be a discrepency here. */ new section

Talk:Inverse Frequency Sound format

2022-01-29T13:27:54Z

Videogamer555: Created page with "How does this sound format handle sounds who's period is zero (frequency is infinite)? This causes a divide-by-zero error when actually computed. ~~~~"

ProGraphx Toolbox tileset format

2022-01-29T11:36:31Z

Videogamer555: /* Header */

{{Tileset Infobox
| ImageNativeWidth = Y
| Hardware1 = EGA
| MaxTiles = 255 per subtileset, unlimited subtilesets
| Palette = Default EGA
| Names = N
| TileMinSize = 0×0
| TileMaxSize = 2040×255
| NumPlanes = 5
| PlaneArrangement = [[Byte-planar EGA]]
| HasTransparency = Y
| HasHitmap = N
| Metadata = None
| Subtilesets = Y
| Compressed = N
| Hidden = N
| Games =
{{Game|Operation: Airlift}}
{{Game|Dark Ages}}
{{Game|Duke Nukem}}
{{Game|Crystal Caves}}
{{Game|FBI Fred}}
{{Game|Secret Agent}}
}}
This file format is used by the ProGraphx Toolbox to store images used for map tiles in a game.
__TOC__
The ProGraphx Toolbox, written by Peder Jungck, is used by the following games:

* [[Operation: Airlift]] - <tt>AIRLIFT.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox''
* [[Dark Ages]] - <tt>DA3.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox'' (DA1.EXE and DA2.EXE contain gibberish)
* [[Duke Nukem]] - <tt>DN1.EXE</tt> contains the string ''Version 1.0 EGA/VGAProGraphx EGA/VGA Toolbox''
* [[Crystal Caves]] - <tt>CC1.EXE</tt> contains the string ''Version 1.5 320x200 PAN EGA/VGAProGraphx EGA/VGA Toolbox''
* [[FBI Fred]] - <tt>FBIFRED.EXE</tt> contains the string ''Version 1.5 EGA/VGAProGraphx EGA/VGA Toolbox (c) 1990''
* [[Secret Agent]] - <tt>SAM1.EXE</tt> contains the string ''ProGraphx EGA/VGA Toolbox Version 2.0 320x200 EGA/VGA Copyright 1991 by Peder Jungck''

== File format ==

The file consists of a number of tilesets one after the other. Each tileset is made up of a collection of small images (usually 8×8 or 16×16, but the format supports up to 2040×255.)

In '''Secret Agent''' the files are encrypted with [[Secret Agent encryption]]. In the other games there is no encryption.

=== Signature ===

There is no signature, however careful processing of the header can be used to check whether the last tileset ends at exactly the end of the file (allowing for padding in some versions of the format.) If not, it is unlikely to be in this format. Be careful that files with zero values don't cause an endless loop when calculating offsets.

=== Header ===

Each tileset begins with the following header.

{|class="wikitable"
!Data type!!Description
|-
|[[BYTE]] count||Number of sprites in this chunk (50 in most cases)
|-
|[[BYTE]] width||Sprite width, in bytes (not in pixels)
|-
|[[BYTE]] height||Sprite height, in pixels
|}

The image data for the tileset follows the header. After the image data either the next header begins, or the file ends.

'''Operation: Airlift:''' Each tileset is padded up to the nearest multiple of 128 bytes.

'''Dark Ages:''' Each tileset is padded up to 8064 bytes, except for the last tileset which contains 2 sprites and is padded up to 384 bytes.

'''Duke Nukem:''' Each tileset is padded up to 8064 bytes, except for <tt>NUMBERS.DN?</tt> (7186 bytes) and the backdrop files (<tt>DROP*.DN?</tt>) which have no padding. The backdrop files also have all three header bytes set to zero. For these files, the number of sprites is always 130, the width is always 2 (bytes) and the height is always 16. The background tileset files (those that are called BACKx.DNx ) have an inaccurate sprite count (first byte of the header). There may actually be more sprites in the tileset. I discovered that at least in BACK0.DN1 it indicates there should be 50 tiles in the set, but if you actually try to use this number, read 50 tiles, and then interpret the next 3 bytes as the header for the next chunk of tiles, you will get wildly wrong header values, because those are not actually header values. They are the next 3 bytes of tile data in the files. The only way to extract the files from these background tile files, is to ignore the first byte in the header, and just read all the tiles in the file until you reach the end of the file.

'''Crystal Caves:''' The file ends after the last tile's image data, there is no padding.

'''FBI Fred:''' Each tileset is padded up to 8064 bytes, except for the last tileset which contains 23 sprites and is padded up to 3712 bytes.

'''Secret Agent:''' Each tileset is padded up to 8064 bytes for 16×16 sprite files (<tt>SAM?01.GFX</tt>), and 2048 bytes for 8×8 sprite files (<tt>SAM?02.GFX</tt>).

For those files with padding at the end, be careful not to interpret the padding as the presence of more tiles.

=== Image data ===

The image data is in [[Byte-planar EGA]] format with five planes, so reading <tt>width × height × 5</tt> bytes will read in enough data for a single image (one tile.) This value multiplied by the number of tiles (<tt>count</tt>) will yield the number of bytes in the entire tileset, which can be used to skip directly to the next tileset in the file (if any.)

The first byte in each tile's data is the transparency plane (1 == opaque, 0 == transparent), and the following four bytes/planes are blue, green, red and intensity. The MSB in each byte (10000000) is the first/left-most pixel, and the eighth pixel is the LSB (00000001). This means if the bits are processed in a loop, as the X direction increases to the right (0, 1, 2) the bit value decreases (0x80, 0x40, 0x20.)

== Notes ==

* For at least '''Duke Nukem''', the game seems to ignore the header of ''all'' files in this format. You can set the entire header of any tileset file to zero values and the game will still load them properly. This also means that you cannot use larger tilesets without modifying the executable.

== Credits ==

This file format has been reverse engineered by many people over the years. [[User:K1n9_Duk3|K1n9_Duk3]] discovered that Duke Nukem uses this format. [[User:Frenkel|Frenkel]] identified the similarities amongst all the games using the file format, and realised they all use the ProGraphx Toolbox. 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!)

ModdingWiki - User contributions [en-gb]

Talk:Inverse Frequency Sound format

Talk:Inverse Frequency Sound format

Talk:Inverse Frequency Sound format

ProGraphx Toolbox tileset format