Printable View
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?
You just need to get the specs for a .bmp (or whatever) image. Try wotsit.org
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.
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 [email protected]. I am very aware of how images (bitmap only actually) work.
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.
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.
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.Quote:
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.
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.
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.
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 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.Quote:
I agree bitmap is not good for games because it is uncompressed
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.Quote:
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.
There used to be ways to re-init the color table via interrupt 10h, but that method is since long gone.
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.