00:03
I get it, I am only checking one side in grow, I need to handle more of it.
00:29
This time I get 'X' (88) instead of 'T'.
10:56
T is 0h54 or 0b1010100. And X is 0b10110000 or 0h58. So I am pretty much a bit off by a single bit being in the wrong location. These are huffman codes so what I want is 0b10000100. What is something though is that I get that desired value when it is being read.
11:02
So it appears my read value from readFirstInt is shifted too high it seems. Since I read 0b100 which is 4, but I instead return 8 from it.
11:08
Changing the read to MSB fixes the issue. Normally I should not need to do it such as that, so the int conversion is lost somewhere.
11:12
Actually I get it. I offer integers with LSB so they get added in that order, although when I get those integers they are read in the same order.
11:15
When placing the lowest values are pushed in...
0011001001111
^^^^^^^^ -- 0b11110010
Then when reading the same order is used.
11 (0b1011) is added to become
11010000
Then 73 (0b1001001) is added
11010000 10010010
Then it is read as
11010000 10010010
F
TT
HHhhh hhh
Reading first values results in 0b00100001, which is 33. However the lowest six bits get chopped off so it is instead read as: 0b0000100. This is 4.
11:25
Thinking about it: 0b0010000 from lowest order. This is 16.
11:31
Just going to go with reading it as MSB since it works.
12:47
Must create the sliding window code and put bytes in there, also need to figure out how the sliding window reading works also.
12:52
For reading the distance, I can use an algorithm for that. Each distance group appears in sets of 4 extra bits, the first 8 values have zero extra bits and represent single directories. So essentially instead of a lookup table I can use a linear sequence calculator to determine the distance to use. Then if there are any extra bits then they can be read.
13:02
This graphing calculator I have is very handy during programming.
13:19
And the distance and length handling was actually quite simple. What I need to do now is have the actual sliding window implemented.
14:09
The distance starts at the furthest byte back, because otherwise it would not make sense.
14:25
So now I have a working sliding window. I just need to figure out where an infinite loop occurs now, most likely at the end of the read.
14:39
Was actually caused by the stop value being treated as an output byte value. So now the inflation algorithm passes and the resulting bytes are given. Now I need longer sequences that do other things. One thing I will need is random unique bytes that have nothing in common.
14:46
Ok so I have a random data input which is completely terrible at compressing as it ends up being larger.
21:12
Was doing lots of outside work before, rather tired.
22:47
I believe the ZIP is reading data from the incorrect location.