diff options
author | Fox Caminiti <fox@foxcam.net> | 2022-08-17 23:41:08 -0400 |
---|---|---|
committer | Fox Caminiti <fox@foxcam.net> | 2022-08-17 23:41:08 -0400 |
commit | 9062e0aae9f2f576b7a237c28028aa6b09feee5e (patch) | |
tree | 98b37bd442b9b6477f8061690744d73efeaa7d0b /bitmap_calls.cpp | |
parent | e89dc91182a94e48ca9220a2fe075db680ddff04 (diff) |
undo and pen development
Diffstat (limited to 'bitmap_calls.cpp')
-rw-r--r-- | bitmap_calls.cpp | 22 |
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. |