| Ticket Hash: | bc5a45dcf8aaa0279ed30f2c5d2080f61c0b2201 | |||
| Title: | encode and decode line format | |||
| Status: | Open | Type: | Feature_Request | |
| Severity: | Critical | Priority: | ||
| Subsystem: | Resolution: | |||
| Last Modified: | 2013-02-24 16:53:13 | |||
| Version Found In: | ||||
| Description: | ||||
|
Many of the maze drawings may have many long lines. In fact, they may consist primarily of long lines. This suggests a method to serialize mazes more efficiently. Instead of storing every pixel of the drawing in a binary string, we store a list of lines which compose the final drawing. Assuming the composition of the maze drawing follows these patterns, this will be a much more efficient way of representing the information.
The envisioned method represents all drawing information in an array of integers. in 3 parts: Metadata - dimensions, start location(s), end location(s), end destination(s) Horizontal lines Vertical lines Before the list of start locations, end locations, and end destinations respectively, there is an integer entry indicating the length of the corresponding list. End destination refers to the index of the start location that reaching the corresponding end location will teleport the player to. See also the description of proposed maze sequences below. Lines are stored in the following 2 entry format: Index offset from last line head, line length. When the running index exceeds the size of the array, that means we have moved on to the new section. In the raw format a length entry of 1 may be omitted. Optionally, an extra section for manually flipping the value of individual pixels after the other sections of the maze have been drawn could be considered. The hoped benefit is that we can encode much longer lines and then only specify breaks in those lines to express the maze more efficiently. Also, lines may either be specifying a positive or negative image, which is determined by assuming the first starting location always is placed on empty space. The raw integer array format would be comma delimited with standard base 10 integers with no extra characters at the start or end of the array. This follows the basic csv format. Also, we may add the capability for encoding the integer array in a base64 encoding and back. The leading recommended version for this encoding actually encodes numbers using base 32, but the second half of base64 characters have a built in ending delimiter. It is also proposed that we allow encoding multiple mazes in sequence to create a maze sequence. Multiple encoded mazes are delimited by semicolons in both the raw array notation and the base64 encoding (semicolon should not be one of the normal encoding characters). Also, read the above about end destinations. If no end destinations are specified, the first ending location of a maze refers to the first starting location of the next maze in the sequence. Starting location indexes are assigned sequentially following the order of the mazes. | ||||