Subj : Re: Screen Capture function
To   : borland.public.cpp.borlandcpp
From : Jeff Baker
Date : Sat Jul 03 2004 05:56 pm

> Padding is adding space to align data structures. You do such in the
> following statement in the color palet.  It is also needed in the bmp
> data, but in this case the width is 640, and is already aligned, so no
> padding is needed there.
>    fputc((short)spacer,out);
I see, so padding is just another term for byte alignment. Thanks for adding
to my programming vocabulary. :o)

> It performs how?
Well it's the strangest thing. The resulting bmp file looks as if it is
zoomed in and is only displaying every other pixel. Seeing the created file
makes me think that I'm not padding the data section of the file correctly.
I am unable to find information telling me if each pixel is represented by a
byte or an int but in either case the program captures the screen
identically. This leads me to believe that two or more pixels are contained
in a single byte/int. So I'll have to tinker with shifting a pixel left and
adding the next to it then write the byte or int to the file. My other
problem is I suspect the header information is incorrectly representing the
data section. That might be why it has that "zoomed in" appearance.

> >typedef struct {
> >char id[2];
> >long file_size,
> reserved,
> offset, /*everything below this is header*/
> header_size,
> width,
> height;
> >short planes,
> bpp;
> >long compression,
> bitmap_size,
> hres,
> vres,
> colors,
> important;
> >} bmp_file;
>
> Is this structure aligned (packed) correctly?
I looked up the structure from the wotsit web site. I've use information
from them before an I trust it as a good source of information
(http://www.wotsit.org/search.asp?s=graphics)

> Is file_size at bmp_file+2?
I'm not sure what you mean but the file size is suppose to be the complete
file size in bytes. However I've noticed that this is never the case with
any bitmap I've looked at. The bmp_file is supposed to be the size of the
bitmap data in bytes but agin, this is never the case.

> You can remove all doubt by removing the 'BM' id and just writing it
> to the file.
I can and will do that. The only reason it is there now was because I was
using this structure to view other bmp files to get a feel for the data.

> >bmp.file_size = 22326;
>
> Is that the correct file size?
> 640*480 alone is bigger than that.
Yes, I found this to be very interesting as well. If I create a 640x480x16
bmp using M$ Paint the size is always 150K but the bmp.file_size is also
always 22326. I don't pretend to understand why this is but it is. When I
disassemble the file using debug then I compare the header data from one bmp
file to another of the same type it appears exactly the same.


> >bmp.width = 640;
> >bmp.height = 480;
> >bmp.planes = 1;
> >bmp.bpp = 4;
> >bmp.compression = 0;
> >bmp.bitmap_size = 22208;
>
> Is that the correct size?
> You are writting 640*480 bytes!
Yes, the function should capture the entire screen (640x480x16) but as I've
covered above bmp.bitmap_size does not seem to actually represent the size
correctly in any BMP I've looked at.

>
> >bmp.hres = 3780;
> >bmp.vres = 3780;
>
> >   for (x = 0; x <= (bmp.width-1); x++)
> >      {
> >      pixel = getpixel(x,y);
> >      fwrite(&pixel,sizeof(pixel),1,out);
> >      }
>
> I think your pixels need to go into the file as 4bit values.
> That means you need to pack them 2 pixels per byte/write.
I suspect this is true as well. Do you recommend shifting the pixel data to
the left twice then add the next? Like this...
for (x = 0; x <= (bmp.width-1); x+=2)
    {
    pixel = getpixel(x,y) << 2;
    pixel += getpixel(x,y);
    fwrite(&pixel,sizeof(pixel),1,out);
    }

.