Hi, I have been able to load various bmp into my projects with no issues for a while. However recently, I one of my bmp files seems to be unable to load. I tried many things to fix it like re-exporting the file or renaming the file. The only thing that fixed it was redrawing it from scratch. The issue that is occurring is that the header struct seems only to be partially filled out when I look at the information. Things like width, height, and compression are not there, but fields like file_type and file_size are filled in. Is there a chance that bmp files export with a different header? Is there a way to export a bmp with the header my importer uses (which is close to the one shown in handmade hero) 100% of the time?

This is really weird to me as the images I am loading in are all glyphs to a font I drew and only 1 glyph (upper case L) was having trouble being read in. It might also be important to note that these images where all png file that I then converted to bmps with a python script. The issue might have come from there. I am still surprised reexporting the image both in png or bmp form from an image editor did not fix it.

Any thoughts on what might have happened?

bmp file format has multiple versions - and each of them have a bit different headers. See the table here: https://en.wikipedia.org/wiki/BMP_file_format#DIB_header_(bitmap_information_header)

But basic fields like width & height are always there.

You should really look inside file as raw bytes in some hexeditor to see what's there. Saying "width, height are not there" does not make much sense. Because those are just 2 byte integers in specific file location. Bytes are always there.

Looking at the raw bytes in a hex editor is a skill I will need to work on. When I open both my working image and my image that won't load, they do seem to have some different bytes in the hex editor, despite supposedly being the same image. Both images do start with BM, so I am guessing that the image that would not load was being exported in a different bitmap format. I will have to look into this a little more.

Hey, I think I figured out the issue and just wanted to post my findings here. I think the issue was that I was using a function to read in files in like so:

char * read_file(char* filename) { FILE* f = fopen(filename, "r"); char* result;

Assert(f != NULL);

fseek(f, 0, SEEK_END);
long fsize = ftell(f);
fseek(f, 0, SEEK_SET); 

result = malloc(fsize + 1); Assert(result != NULL);

fread(result, fsize, 1, f); fclose(f);

result[fsize] = 0; return result; }

It looks like changing the function to use fopen(filename, "rb") instead of fopen(filename, "r") fixed the issue. (Although now I just use ReadFile function). This issue had also been causing wav files I loaded to have a weird clipping sound at the end of them.

Yes, putting b in open mode for reading binary files is required. Otherwise C runtime is allowed to change bytes you read to "fix" newlines - as newlines \n vs \r\n and similar has differences between OS. Opening file in binary mode does not change any bytes, everything will be read exactly as it is on the disk.

Yeah, normally I usually use binary mode by default, so I must have just had a typo this time. This was an annoying bug since sometimes it reads in files just fine. It has caused a lot of small errors this week lol.

Anyway, thanks for the help!