rle optimization I made
Posted: September 5th, 2026, 10:08 am
first let me define that a chunk is a row of cells of the same type.
the types of these chunks must alternate, so thus that means the only row you have to specify the type of is the first chunk in a row.
and also to save same precious bits the header or whatever it's called is now x-y-rb-s- and the - are placeholders for numbers.
first to make sure that you know how it looks like it looks like this for a glider: x3y3rb3s23/b12$o111$b21
and also for multidigit numbers you use a. a means you take the digit infront (which I have cleverly called the digindicator) and then take the next digindicator digit after the digindicator and turn them into one number so e.g., a217 means 17. also now that there's a and b, o is now c because abc
d and e are to repeat. so d means you take (digindicator of d) and that's how much times you repeat the next digit. and e is for repeating a sequence of chunks. so e means you take the next (digindicator of e) digits after the digindicator and you clump those into a repeatable thing so d42 is 2,2,2,2 and d4e214 is 1,4,1,4,1,4,1,4 which is NOT d4a14, that's 14,14,14,14. and finally there's f, to skip rows. f means you look at (digindicator of f), take (digindicator of f) digit after, tahst how much rows you skip. now a funny coincidence is that that's exactly 16 things, the digits, and a-f so you can pack them into nybbles (half a byte) with 0-9 being the digits and 10-16 being a-f, also forgot to say but $ and ! are redundant now as the x and y can work too and blanks atthe end are now handled with the b and c at the start of rows as they are at the start of a row so when you see one, you go down a row so you don't even need the x and y tracking now. anyway now that it can be stored in a nybble you can either represent it as binary or merge two of them into an ascii byte but some ascii charcters are control characters so instead I decided to use base 64 encoding so you or a parser will just convert the b64 characters into binary then group four bytes into the lil nybble thing from earlier and if the byte count isn't a multiple of four then chances are the b64 thing added extra 0s at the end to make it a multiple of 6 so yeah
oh boy that was a big yap
the types of these chunks must alternate, so thus that means the only row you have to specify the type of is the first chunk in a row.
and also to save same precious bits the header or whatever it's called is now x-y-rb-s- and the - are placeholders for numbers.
first to make sure that you know how it looks like it looks like this for a glider: x3y3rb3s23/b12$o111$b21
and also for multidigit numbers you use a. a means you take the digit infront (which I have cleverly called the digindicator) and then take the next digindicator digit after the digindicator and turn them into one number so e.g., a217 means 17. also now that there's a and b, o is now c because abc
d and e are to repeat. so d means you take (digindicator of d) and that's how much times you repeat the next digit. and e is for repeating a sequence of chunks. so e means you take the next (digindicator of e) digits after the digindicator and you clump those into a repeatable thing so d42 is 2,2,2,2 and d4e214 is 1,4,1,4,1,4,1,4 which is NOT d4a14, that's 14,14,14,14. and finally there's f, to skip rows. f means you look at (digindicator of f), take (digindicator of f) digit after, tahst how much rows you skip. now a funny coincidence is that that's exactly 16 things, the digits, and a-f so you can pack them into nybbles (half a byte) with 0-9 being the digits and 10-16 being a-f, also forgot to say but $ and ! are redundant now as the x and y can work too and blanks atthe end are now handled with the b and c at the start of rows as they are at the start of a row so when you see one, you go down a row so you don't even need the x and y tracking now. anyway now that it can be stored in a nybble you can either represent it as binary or merge two of them into an ascii byte but some ascii charcters are control characters so instead I decided to use base 64 encoding so you or a parser will just convert the b64 characters into binary then group four bytes into the lil nybble thing from earlier and if the byte count isn't a multiple of four then chances are the b64 thing added extra 0s at the end to make it a multiple of 6 so yeah
oh boy that was a big yap