[19:47][Continue to step through ComputeHuffman() where it enters the Huffman codes into the symbol table][:compression :run]
[23:48][LSB vs MSB Huffman][:blackboard :compression :memory]
[29:09][Change ComputeHuffman() to put the bit-flipped Huffman code before its entry index, before bit-flipping that whole thing][:compression :memory]
[30:02][Step through ComputeHuffman() to see that it decompresses all our symbols][:compression :run]
[32:37][Let ParsePNG() read to the end of the file, :run it and crash on the second time through the loop][:compression :programming]
[34:00][Consult the Huffman decode part of the DEFLATE specification[ref
site=IETF
page="DEFLATE Compressed Data Format Specification version 1.3"
[35:05][Make ParsePNG() copy the data to output, renaming ConsumeBits() to ConsumeSize() and introducing a u16 version of EndianSwap()][:compression]
[39:06][Inspect the disassembly for EndianSwap(LEN) to see that it was optimised out][:asm :compression :memory :run]
[39:31][Prevent the compiler from optimising out the EndianSwap(LEN)][:compression :memory]
[40:34][Inspect the disassembly for EndianSwap(LEN) to see that it it didn't do the expected byte-swap][:asm :compression :memory :run]
[41:19][Fix the u16 version of EndianSwap()][:compression :memory]
[41:42][Inspect the disassembly for EndianSwap(LEN) to see that it it did a rol][:asm :compression :memory :run]
[42:05][Begin to enable ParsePNG() to perform the Huffman decompress using a LengthExtra table of pre-subtracted lengths, in conjunction with the DEFLATE specification[ref
site=IETF
page="DEFLATE Compressed Data Format Specification version 1.3"
[1:36:08][Let AllocatePixels() allocate space for the filter][:memory]
[1:38:54][Hit an assertion in ParsePNG()][:compression :run]
[1:39:36][Q&A][:speech]
[1:40:05][@ratchetfreak][Q: LitLen-256 should be LitLen-257][:compression]
[1:40:15][Fix the LenTabIndex initialisation in ParsePNG() to LitLen - 257][:compression]
[1:40:30][Step through ParsePNG()][:compression :run]
[1:41:16][@alexkelbo][Q: Once this works, do you think it could be SIMDied?][:optimisation]
[1:41:46][@nothings2][Q: That LitLen bug came from me. It'll also be clearer if you write "LitLen >= 257" instead of "LitLen > 256"][:compression]
[1:41:55][Change "LitLen > 256" to "LitLen >= 257" in ParsePNG()][:compression]
[1:42:28][@iantjac][Q: When you are making a PNG reader, I assume you want game textures to be in PNG format. For my projects I create uncompressed image data, and then archive all of them with some compressor. Is my approach a bad one? (I ask because you have decided to use PNGs)][:art]
[1:43:16][@mmozeiko][Q: Should ReverseBits table be u16 and not u32?][:compression]
[1:43:21][Reduce the ReverseBits table size from u32 to u16][:compression]
[1:44:05][@nothings2][Q: No bit reversal is needed. See Deflate spec 3.1.1 first two bullet points[ref
site=IETF
page="DEFLATE Compressed Data Format Specification version 1.3"
[1:45:44][@vaualbus][Q: By the way the <= I was referring to at the begin is in the loop in the Huffman decode function, the one with BitIndex in the spec. That loop has <= whereas you have <][:compression]
[1:47:07][@mtsmox][Q: BTYPE==0 should read from CompData I think, instead of At?][:compression]
[1:47:21][Fix ParsePNG() to read from CompData rather than At in the BTYPE==0 case][:compression]
[1:48:08][@nothings2][Q: "the extra bits, after being unpacked as described in 3.1.1, should be interpreted as a machine integer stored...", I guess is what they meant]
[1:48:25][Prevent ParsePNG() from reversing the extra bits][:compression :memory]
[1:48:53][Step through ParsePNG() to see that we're sort of okay, but not quite right][:compression :run]
[1:50:45][@vaualbus][Q: Yes, that loop]
[1:52:58][Stop now with a glimpse into the future][:speech]