Skip to content

Latest commit

 

History

History
129 lines (99 loc) · 4.16 KB

FORMATS.md

File metadata and controls

129 lines (99 loc) · 4.16 KB
Raw

File Formats

Below is a bit of information about how each of the files is laid out.

Tileset

The tileset is arguably the most complicated type of file to deal with for map creation purposes.

Each tileset is made of many 2 bit-per-pixel bytes, with a single tile being made up of 16 bytes.

  • 8 pixels tall x 8 pixels wide = 64 total pixels per tile
  • 64 pixels * 2 bits per pixel = 128 total bits per tile
  • 128 bits / 8 bits per byte = 16 bytes per tile

Let's take the following tile as an example:

        db      081h,07eh,0e7h,018h,0ffh,000h,0feh,001h
        db      097h,060h,0fbh,004h,000h,0ffh,000h,011h

The tile data is processed in byte pairs, with each pair making up a whole row of pixels. This means that the first tile row will be made up of the bytes 081h,07eh.

To find the pixel values for each byte pair, convert each to binary and then combine the bits of each one.

081h = 10000001
07eh = 01111110

Now, going left to right, take each vertical bit and combine them, with the first byte's bit coming first.

This produces:

Pixel 1 = 1,0   (leftmost pixel)
Pixel 2 = 0,1
Pixel 3 = 0,1
Pixel 4 = 0,1
Pixel 5 = 0,1
Pixel 6 = 0,1
Pixel 7 = 0,1
Pixel 8 = 1,0   (rightmost pixel)

The final step is to replace the pair values with their corresponding white values, which can be one of 4 possible values:

1,1 = White        (W)
1,0 = Light Grey   (L)
0,1 = Dark Grey    (D)
0,0 = Black        (B)

Using this guide, we can see that the pixels are going to be:

L D D D D D D L

Or, for a more visual representation of it:
top row

Now if we keep doing this process for each of the remaining byte pairs, we'll eventually deduce each of the 8 rows of pixels.

Using this method, the values will be:

L D D D D D D L
L L L D D L L L
L L L L L L L L
L L L L L L L D
L D D L W L L L
L L L L L D L L
D D D D D D D D
W W W D W W W D

Which visually translates to:
first tile

This process needs to be done for every group of 16 bytes, which will produce the entirety of the tileset.

Cells

Cells are much easier to work with, and similarly to the tileset, a single cell consists of 16 bytes.

Each cell is made up of a 4x4 array of tiles, making each cell a total of 32px tall and 32px wide.

Let's take the cell and tileset below as an example.

Cell:

        db      030h,031h,00fh,038h,032h,033h,01fh,039h
        db      017h,017h,017h,017h,017h,017h,017h,017h

Tileset:
tileset

Since the cell is arranged as a 4x4 grid of tiles, this equates to the following, for ease of translation:


        db      030h,031h,00fh,038h
        db      032h,033h,01fh,039h
        db      017h,017h,017h,017h
        db      017h,017h,017h,017h

Now, all we have to do is simply replace each byte with the associated tile, with the top-left tile being 000h and the tile below it being 010h.

After placing all of the tiles, the cell will look like this:
cell

Map

The map is probably the easiest part of everything, since it's just an array of cells in a certain order.

The map can be any number of bytes large, and the the width and height of the map must be specified in the game's code in order for the map to work correctly in-game.

Let's take the following map as an example:

        db      02ah,02bh,028h,029h

This may seem like a small map, and it is for demonstration purposes.

If the map was defined to be 2 cells tall and 2 cells wide, then the data could also be presented this way for readability:

        db      02ah,02bh
        db      028h,029h

Now if we were to replace each of those bytes with the corresponding cell, we'd end up with a map that looked like this:
map