From 9062e0aae9f2f576b7a237c28028aa6b09feee5e Mon Sep 17 00:00:00 2001 From: Fox Caminiti Date: Wed, 17 Aug 2022 23:41:08 -0400 Subject: undo and pen development --- bitmap_calls.cpp | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) (limited to 'bitmap_calls.cpp') 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. -- cgit v1.2.3