21 lines
1.6 KiB
Markdown
21 lines
1.6 KiB
Markdown
# Pieces storage
|
|
|
|
## What is stored
|
|
|
|
If you don't know what a polyomino is, check [this other file](Pieces_representation.md#what-are-polyominoes).
|
|
|
|
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 resolved internally, but will be calculated before storage as to not need extra calculcations upon load (except for the block type which is trivially computed).
|
|
|
|
## How is it stored
|
|
|
|
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.
|