My goal is to write a simple image converter from bmp files created by Aseprite into images that can be displayed natively on a Commodore 64. But before I can even do that, I've run into a problem - the test images I've created don't follow what I expected the BMP file format to do. After reading the relevant Wikipedia article, I created some test images and opened them in a hex editor to see where all the metadata is stored, as well as the actual graphics data. The images were drawn so that the pixels at the beginning and end would be different than the rest, allowing me to see just where the data begins and ends, and if it matches the pointers at the start of the file contents.
And therein lies the problem - there appears to be extra padding before and after the actual file data - yet the pointers imply that the data range is larger than the first and last pixels I drew. (From experimenting with other drawings prior to this one, I've learned that depending on the pixel depth, the pixels get "packed" as much as possible, and are stored backwards, yet for some reason I've never encountered this phenomenon of extra padding with a palette of 256 colors.)
Here, I've circled in red the file size and the pointer to the end of the data range, and circled the associated offsets in the file in red as well (the file size is basically a pointer to the beginning of the data), and in blue I've circled the total bytes of bitmap data that actually exist. In black are where the beginning and end actually are - you can see that they're not quite where I expected them to be. (In the hex editor I highlighted in light blue the data range as given by the BMP file).
Is there something I'm missing here? Why is this extra padding present in the bitmap file?
