jminos/doc/files_format.md

Files format

Pieces

Note: the current algorithm has been adapted to use file compression. There is currently no documentation on how the compression work, but you can check the code in the src/Common folder.

Generating polyominoes of size n is exponential in regard to n. Because of this, we will store the pieces beforehand and load them upon launching the game.

We want the pieces to be always sorted in the same order, always attributed the same block type, and always set at the same spawn position, no matter how they were generated. We also want them to be separated in 3 categories : convex, not convex but without a hole, and with a hole. Theses problematics are already solved internally, but will be calculated before storage as to not need extra calculcations upon load (except for the block type which is trivially computed).

Pieces are stored in binary files. Each file simply contains every polyomino of one size, one after the other. Since each file contains all polyominoes of the same size, we know how much stuff to read and don't need delimiters. We know we've read all pieces simply when we reach the end of file character.

Each piece is stored as follows:

• 1 byte for the characteristics of the piece: ABCCCCCC where A indicates if the piece is convex, B indicates if it has a hole, and C is the length of the piece
• 1 byte for each position: XXXXYYYY where X is the x coordinate of the position and Y is the y coordinate of the position

The current implementation only allows to generate polyominoes up to size 16, but can be upgraded by storing coordinates on 8 bits instead of 4.
It has been currently choosen to use pieces only up to size 15 for this game.

Config

When compiling a release version, default files will be used, theses will then be impacted by the user and used for their next sessions.

Keybinds

The games has 4 keyboard configs by default that never changes, and a modifiable 5th one, but theses are all stored the same.

Each keybinds files has the the following format:

• The number of the action (converted from an Enum), stored with 1 byte
• The number of each binded keys (also converted from an Enum), stored with 1 byte
• A separator characters which is 0xFF

Repeat for every avaible actions.

Settings

The settings file has the following format:

• The versions of the file format, stored with 1 byte
• The previous maximum pieces size selected, stored with 1 byte
• The number of the chosen keybinds (from 0 to 4), stored with 1 byte
• The DAS of the player, stored with 1 byte
• The ARR of the player, stored with 1 byte
• The SDR of the player, stored with 1 byte
• The window size mode, stored with 1 byte
• The master volume, stored with 1 byte
• The number of the last selected gamemode (converted from an Enum), stored with 1 byte
• The last selected width of the board, stored with 1 byte
• The last selected height of the board, stored with 1 byte
• The uniformity mode (0 for default distribution, 1 for uniformous distribution, 2 for custom distribution), stored with 1 byte
  • For each size, store the custom proportion (from 0 to 20) (15x1 byte total)
• Every selected pieces
  • For every groupe of piece (ALL, CONVEX, HOLELESS, OTHER), use 1 byte for the type (once again converted from an Enum) and 1 byte for the size
  • For every single piece, use 1 byte for (the size + encoding that it is a single piece), and 3 bytes to store the number of the piece (allows number up to 16M, size 15 has 6M pieces).

When starting the game, it will verify if the current settings file is in the latest format, if it is not it will be regenerated with default values.