Creating a custom filetype

[martianxx]

Hi, I am making a level editor that needs to output a custom map file for use with source code that I will write for a graphics library.

My question is: What do I need to bear in mind when deciding how to structure a custom file type? Also how can I encode a standard bitmap image into my file (the tile set) so that it can all be contained in a single file rather two files; the map file and tile set (.bmp file).

Thanks.

[Kronus]

Well for one it would help to have a header. The header would contain information you'd find helpful before you'd actually load it. Such as size of the file, how many tiles, 24-bit or 32-bit bitmap, the size of the bitmap file stored inside, the number of tiles. Let me help you out:

typedef struct LVLHEADER {
    int sz_file;
    int sz_bmp;
    int format;
    int tiles;
} LVLHEADER;

Just a sample of where/how you'd store some of the data. As for the bmp I am un aware of how to do this.

[martianxx]

I found this: http://www.magicdb.org/filedesign.html which game me more insight in how to design a new file type.

The magic value mentioned: Is this an ID value for the file or the file type? If the file type how can one keep track of other files created to ensure a unique ID? - EDIT of course it means the file type not each file...

When an OS sees a file type what information does it look for in its header to get information to display to the user? Is it just the meta data examples given in the above link?

If so does it expect a certain format? i.e order of the data or names for the data eg does it look for Title, title or is it case insensitive?

I assume I can mess around creating files with just this info to see what works best.

EDIT: If I encode a bmp file into my file does it matter how I store the data as long as I store all the information needed and provide the functions for reading and writing?

[zb0S216C]

martianxx wrote:

"Also how can I encode a standard bitmap image into my file (the tile set) so that it can all be contained in a single file rather two files; the map file and tile set (.bmp file)."

Sounds like you could use an archive. I suggest the following:

-- Convert each tile into a format that can be stored into a file, like so:

struct TileInformation
{
  int ColourDepth;
  Pixel *Graphic;
  unsigned int ResolutionX;
  unsigned int ResolutionY;
  int BaseID;
};

Note: "TileInformation::BaseID" is used to identify the tile when we need to create an instance. When you've converted each base-tile type, load each base-tile into a file. Also, for the information pointed-to by "TileInformation::Graphic" you'd load that information after, like so:

| -------------------------- |
| Depth | Res-X | Res-Y | ID |
| -------------------------- |
| Pixel Information          |
| -------------------------- |

| -------------------------- |
| Depth | Res-X | Res-Y | ID |
| -------------------------- |
| Pixel Information          |
| -------------------------- |

-- Now, convert each tile instance into a format that can be stored into a file then export all tile instances into the same file below where you stored the base-tile information.

struct TileInstanceInformation
{
  int BaseTileID;
  int InstanceID;
  Pixel *Graphic;
  unsigned int PositionX;
  unsigned int PositionY;
  int BehaviourFlags; // Do something when X happens, etc. 
};

Here's an example of a tile instance within a file:

| ----------------------------------------- |
| Base-ID | Inst-ID | Pos-X | Pos-Y | Flags |
| ----------------------------------------- |

Here, there's no need to export the information pointed-to by "TileInstanceInformation::Graphic" because it's already been saved when the base-tile information was exported, so we just skip this data-member.

Here's what your file might look like after exporting all of your information:

  | ----------- |
  | Base Tile 1 |
  | ----------- |
  | Base Tile N |
  | ----------- |

| --------------- |
| Tile Instance 1 |
| --------------- |
| Tile Instance 2 |
| --------------- |
| Tile Instance N |
| --------------- |

When the time comes to import all of your data tile, you'd read the base-tile information first followed by the tile instance information. This way, when you load your instance information, you have the base-tile information the tile instance needs.

This isn't the best guide in the world, nor is it the most favourable, but at least you have some idea what to expect.

_Wazzak