Writing out a .bmp file

This is a discussion on Writing out a .bmp file within the Game Programming forums, part of the General Programming Boards category; Okay, I was thinking about this today, and I was mostly curious: Say I made a paint program and I ...

  1. #1
    I am he who is the man! Stan100's Avatar
    Join Date
    Sep 2002
    Posts
    361

    Writing out a .bmp file

    Okay, I was thinking about this today, and I was mostly curious:

    Say I made a paint program and I wanted to save a picture. For arguments sake, any settings will do (50x50 16 color 255 color 755x098879, etc).

    Would I go about it like I would read it in? Write out the header etc? Has anyone else here done this before?
    Stan The Man. Beatles fan

    When I was a child,
    I spoke as a child,
    I thought as a child,
    I reasoned as a child.
    When I became a man,
    I put childish ways behind me"
    (the holy bible, Paul, in his first letter to the Cor. 13:11)

  2. #2
    Pursuing knowledge confuted's Avatar
    Join Date
    Jun 2002
    Posts
    1,916
    You just need to get the specs for a .bmp (or whatever) image. Try wotsit.org
    Away.

  3. #3
    Registered User
    Join Date
    Apr 2002
    Posts
    1,571
    Yea it's not too bad. You just need the information for the headers which you can get almost anywhere. It's setup like this:

    BITMAPFILEHEADER
    BITMAPINFOHEADER
    PALETTE DATA ( optional )
    PIXEL DATA

    Just remember the pixel data is almost always stored in a bottom up fashion. If you read the information on the params of those header structs it will tell you details like that.
    "...the results are undefined, and we all know what "undefined" means: it means it works during development, it works during testing, and it blows up in your most important customers' faces." --Scott Meyers

  4. #4
    Registered User RussMan's Avatar
    Join Date
    Sep 2003
    Posts
    14

    Advice

    One piece of advice. If your going to write a program that saves bitmaps i would suggest learning the bitmap file format. MrWizard gave you the complete structure but there is still more information needed. And yes try to stay with standard of writing the image upside down. I just finished writing a bitmap loader function. Also remember that when writing the image file its has to be on the 4byte boundary limits. So if you have a image that is say 10 pixels wide you will need and extra to 2 bytes of information that are blank. You could change this though if you write you on image loader and maybe rename it from bitmap to your own file format. If you need more information you can email me at carnieltd@shaw.ca. I am very aware of how images (bitmap only actually) work.

  5. #5
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,590
    Personally I'm not a big fan of the BMP because it has a lot of overhead with it thats not necessary in games. The best format I've found for high color bitmaps is simply a raw format - no headers, etc.

    The only information you need is the x and y sizes of the image which can be stored at the very beginning of the file. From then on you simply read in the RGB components either a byte at a time or by 32-bit longs at a time. The problem with the longs is that you must extract the RGBs out of the long, but AFAIK storing longs would save more space than storing individual bytes. Either way its up to you.

    This way your loader function does not have to worry about all that header and palette crap at the beginning, nor the 4 byte boundary annoyance - which is not necessary for a simple bitmap loader in a game.

    Also you can still do some run-length encoding with your data because all of your ARGB components will be from 0 to 255 which just happens to be the same number of colors that were allowed in the old mode 13h. So you don't have to change the RLE scheme - now you just remember that after you uncompress the file, each number represents a color component, not a palette entry.

  6. #6
    Registered User RussMan's Avatar
    Join Date
    Sep 2003
    Posts
    14
    Yes i would have to agree. Personally all my bitmap for games are stripped into 16bit format of 565 this way even if the format is 555 i can just strip the extra bit. I store the width, height, and a tag to let me know there my format so that i don't open something else. But he only asked how to load them lol.

  7. #7
    Visionary Philosopher Sayeh's Avatar
    Join Date
    Aug 2002
    Posts
    212
    As I recall, .BMP uses RLE. As others have said, it's not very effecient. It would be better to just save the raw pixmap data and the associated color table.

    One Color table for your game, and then nothing but pixmap data. it's very compressible if you want to go that route.
    It is not the spoon that bends, it is you who bends around the spoon.

  8. #8
    Registered User
    Join Date
    Apr 2002
    Posts
    1,571
    Originally posted by Sayeh
    As I recall, .BMP uses RLE. As others have said, it's not very effecient. It would be better to just save the raw pixmap data and the associated color table.

    One Color table for your game, and then nothing but pixmap data. it's very compressible if you want to go that route.
    Not all bitmaps use RLE. If you use the 24-32 bit versions the pixel data is just after all of the header information. Note most of the time it is stored bottom-up. I agree bitmap is not good for games because it is uncompressed and even if it is compressed using RLE, RLE is not that great of a compression method compared to Huffman, LZW or LZ77 for instance.

    The reason most people use BMP files is because of its' simplicity. You don't have to worry about a bunch of complex decoding if you are manually loading the images yourself. Its a good exercise to write a BMP loader and then maybe try to expand to PCX ( also simple ) and other formats.
    "...the results are undefined, and we all know what "undefined" means: it means it works during development, it works during testing, and it blows up in your most important customers' faces." --Scott Meyers

  9. #9
    Banned frenchfry164's Avatar
    Join Date
    Oct 2001
    Posts
    1,552
    I working on a format very close to a raw image format. It's got a very lightweight header and then raw image data stored in RGBA format, 8 bit per channel.

    I agree with the raw format fully. I always use RAW for everything I do involving image loading. You can always add a header of your own to it if you want it to store extra information. Usually the header only needs the width and height of the image.

    I hate bmp files. I loathe them. I despise them.

  10. #10
    Visionary Philosopher Sayeh's Avatar
    Join Date
    Aug 2002
    Posts
    212
    Some clarification:

    bitmap-- this is black & white. A "bit" only has 2 values. 0 or 1, black or white.

    pixmap-- this is a bitmap, but with "depth". Each pixel can range from 2-bits (4-colors), to 64-bits (trillions of colors). Games most commonly use 8-bit or 16-bit pixmaps.

    The reason more depth isn't used in games is because a) the human eye can't distinguish more than 16-bit color, and b) the amount of date needing moved per frame becomes prohibitive. For example, if you're moving 32-bit pixmap frames of just 640x480 in size, that's 4-bytes per pixel. So, 4x640x480 = 1,228,800 bytes. Not every computer can throw 1,2MB up on screen 30 times per second. And nowadays, games are usually run at 800x600, 1024x768, and 1280x1024 resolutions-- a lot more data.

    I recommend mastering using 8-bit pixmaps (256 colors per pixel) and then moving to 16-bit.

    In order to accurately represent a pixmap you _must_ retain 3 pieces of information.

    1) dimensions (x/y)
    2) color table, and
    3) raw pixmap data.

    In any given bitmap or pixmap, the value of the pixel is nothing more than an index into a color table (which each application has) that contains RGB values that the display driver compromises into the Device's Color Table (of which there is only one which all concurrently applications share).

    If you don't keep track of a color table (what index value corresponds to what RGB value), then you are at the mercy of whatever colors the O/S provides as default.


    ---

    I agree bitmap is not good for games because it is uncompressed
    I have no problems with bitmaps-- they are fine. .BMP isn't. Just work with the raw data (a pixmap is consecutive in RAM, anyway) and compress it however you like, or not.
    It is not the spoon that bends, it is you who bends around the spoon.

  11. #11
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,590
    If you don't keep track of a color table (what index value corresponds to what RGB value), then you are at the mercy of whatever colors the O/S provides as default.
    Unless DX inits the video card to reset its color values, which AFAIK it does on a mode change - most cards re-init their 256 color mode palette tables on mode changes. For high color modes I see no advantage to using a color table and I'm sure you were only talking about 256 color mode.

    There used to be ways to re-init the color table via interrupt 10h, but that method is since long gone.

  12. #12
    Banned frenchfry164's Avatar
    Join Date
    Oct 2001
    Posts
    1,552
    I thought that the eye could see up to 24 bit graphics. At least that's what I've read at a million other places.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Data Structure Eror
    By prominababy in forum C Programming
    Replies: 3
    Last Post: 01-06-2009, 08:35 AM
  2. opening empty file causes access violation
    By trevordunstan in forum C Programming
    Replies: 10
    Last Post: 10-21-2008, 11:19 PM
  3. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 06:39 AM
  4. Batch file programming
    By year2038bug in forum Tech Board
    Replies: 10
    Last Post: 09-05-2005, 03:30 PM
  5. Simple File encryption
    By caroundw5h in forum C Programming
    Replies: 2
    Last Post: 10-13-2004, 10:51 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21