1 files changed, 20 insertions, 2 deletions
diff --git a/bitmap_calls.cpp b/bitmap_calls.cpp
index 6425e6d..5d549c2 100644
--- a/bitmap_calls.cpp
+++ b/bitmap_calls.cpp
@@ -1,5 +1,23 @@
-// NOTE(fox): Pay attention to how the Y pitch differs between the unpacked
-// bitmaps and the 4x4 packed bitmaps, since odd-sized bitmaps are padded.
+// Bitmaps are curently stored two ways in this program, which I'm calling
+// "packed" and "unpacked." Both are 0xAAGGBBRR little endian. Unpacked bitmaps
+// use the typical method of storage, rows of X that you increment by
+// Width*BytesPerPixel to look up the Y coordinate. "Packed" bitmaps encode
+// pixels as 4x4 chunks. To illustrate this clearly with an 8x4 bitmap:
+
+//  A1 A2 A3 A4 E1 E2 E3 E4
+//  B1 B2 B3 B4 F1 F2 F3 F4
+//  C1 C2 C3 C4 G1 G2 G3 G4
+//  D1 D2 D3 D4 H1 H2 H3 H4
+
+// Unpacked would be stored in memory order as A1 A2 A3 A4 E1 E2 E3 E4...
+// while packed would be stored as A1 A2 A3 A4 B1 B2 B3 B4...
+
+// In cases where the bitmap is a non-divisible-by-four size, we simply treat
+// the bitmap as if it's the right size and add the extra pixels in the allocation.
+
+// This wasn't an optimization I necessarily _needed_ to make this early on--I
+// never even did any measuring to see if there was any speedup-- but I
+// couldn't resist it. I like doing the software rendering stuff.
 
 // TODO(fox): I could write an AVX version of this function, but it may not be
 // that much faster since we have to do a bit of uninterleaving.