DirectX:Loading bitmaps the C++ way

I've been reading through TOTWGPG, and I've come to the loading bitmaps in directdraw part, except when Andre LaMothe writes the function for loading a bitmap, it's in C! Or, well maybe it's that and I'm not used to it.
It uses lread, and lseek, and all that other stuff. And I don't want to always have to link the GDI to directdraw to BitBlt the bitmap.
So I was wondering:
Can anyone put up a bitmap loading function that uses ifstream?

Thanks.

I haven't read the book, and I am not familiar with the 2d aspects of direct draw, but it seems to me that the easiest way to load a graphics file into DirectX would be to use D3DXCreateTextureFromFile() or D3DXCreateTextureFromFileEx() and then just use it as the texture of a quad. However, as I said, I am not familiar with the 2d aspects of the API.

Actually, since your doing DirectDraw, you're using the Windows API in which case I'm 99% sure that GDI is being linked in your project anyways... So that's not really a reason to write your own loading code. Also, it's not a fun process to write loading code, and you'll end up with code that probably doesn't work as well and is slower (mine was really unreliable and everything ended up tinted yellow and sometimes slanted, based on the dimensions of the bitmap, for some reason). GDI is, IMO, the easiest, fastest and most reliable way of loading bitmaps.

Quote:

---

And I don't want to always have to link the GDI to directdraw to BitBlt the bitmap.

---

You don't, you use GDI to load it once and then keep the surface in your closet till you need to draw it again ;)

**EDIT**
In my lamothe book (Windows Game Programming for Dummies), there's some bitmap loading code... I estimate that, with all the functions/structs/all that included, it's about 100-200 lines of gibberish. And, for that matter, I believe it only loads an 8-bit bitmap, no support for 16, 24, 32 bits (that code comes later). Sample line:

Code:

---

memcpy(&primary_buffer[y*ddsd.lPitch], &bitmap16bit.buffer[y*640],640);

---

Ugly, unsexy.

Quote:

---

..tinted yellow and sometimes slanted...

---

Not converting 24 bit color to the correct color depth. Not accounting that all BMPs are padded to the nearest 4 byte boundary.

Ah yes, you're probably right. But then, in order to make code that is as versatile as GDI, you're going to have to account for it, and also add support for every different bitmap format, which is (IMHO) a very big pain in the anal canal.

**EDIT**
Oh well, Stan100 if you still want to know how to load bitmaps, go to wotsit and look up the file format. Reading should be fairly simple:
file.open(fileName, std::ios::binary | std::ios::in)
file.read(buffer, amount)

Good luck.

I haven't checked wotsit yet, but I knew I should of in the back of my mind. Along with another thing:

Quote:

---

Actually, since your doing DirectDraw, you're using the Windows API in which case I'm 99% sure that GDI is being linked in your project anyways... So that's not really a reason to write your own loading code. ...

---

I knew I worded my question wrong too. Of course I use some GDI, but I meant something else. When I get to my home computer I'll post the code from my book.

I looked up _lread in the MSVC++ help and it says I should use readfile(), but I'm having a hard time with it. I can't even do basic things like reading in a string. BTW here's the code from my book:

Code:

---

int Load_Bitmap_File(BITMAP_FILE_PTR bitmap, char *filename)
{
int file_handle,  index;
UCHAR  *temp_buffer = NULL;
OFSTRUCT file_data;       
if ((file_handle = OpenFile(filename,&file_data,OF_READ))==-1)
  return(0);
_lread(file_handle, &bitmap->bitmapfileheader,sizeof(BITMAPFILEHEADER));
if (bitmap->bitmapfileheader.bfType!=BITMAP_ID)
  {
  _lclose(file_handle);
  return(0);
  }
_lread(file_handle, &bitmap->bitmapinfoheader,sizeof(BITMAPINFOHEADER));
if (bitmap->bitmapinfoheader.biBitCount == 8)
  {
  _lread(file_handle, &bitmap->palette,MAX_COLORS_PALETTE*sizeof(PALETTEENTRY));
  for (index=0; index < MAX_COLORS_PALETTE; index++)
      {
      int temp_color                = bitmap->palette[index].peRed;
      bitmap->palette[index].peRed  = bitmap->palette[index].peBlue;
      bitmap->palette[index].peBlue = temp_color;
      bitmap->palette[index].peFlags = PC_NOCOLLAPSE;
      }
    }
_lseek(file_handle,-(int)(bitmap->bitmapinfoheader.biSizeImage),SEEK_END);

if (bitmap->bitmapinfoheader.biBitCount==8 || bitmap->bitmapinfoheader.biBitCount==16 ||
    bitmap->bitmapinfoheader.biBitCount==24)
  {
  if (bitmap->buffer)
      free(bitmap->buffer);
  if (!(bitmap->buffer = (UCHAR *)malloc(bitmap->bitmapinfoheader.biSizeImage)))
      {
      _lclose(file_handle);
      return(0);
      }
  _lread(file_handle,bitmap->buffer,bitmap->bitmapinfoheader.biSizeImage);

  } // end if
else
  {
  return(0);

  }

_lclose(file_handle);

Flip_Bitmap(bitmap->buffer,
            bitmap->bitmapinfoheader.biWidth*(bitmap->bitmapinfoheader.biBitCount/8),
            bitmap->bitmapinfoheader.biHeight);

return(1);

}

---

Sorry it's so long, but thanks in advance for any help

*EDIT*
Took out long comments/big whitespace. BTW the struct for bitmap is only what members are in the code above

Quote:

---

Flip_Bitmap(...

---

;) And the code for that function is another 10-20 lines, right? I too tried using that loading function (or a stl-erized version of it by me), and it came out as previously mentioned, tinted yellow and skewed depending on what the dimensions of the bitmap were. Probably I made a slight error somewhere, but my rule is if I can't understand how to make it work, I don't use it.

Umm, about ReadFile:

Code:

---

HANDLE file = CreateFile(fileName, GENERIC_READ, 0, NULL,
                  OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

char buf[BUFFER_SIZE];
DWORD bytesRead;

ReadFile(file, (LPVOID)buf, numberOfBytesToRead, &bytesRead,
        NULL);
//If you want to make a null-terminated string out of it instead
//of having a block of raw data:
buf[bytesRead] = '\0';

CloseHandle(file);

---

I'd stick with fread. I don't see why everything has to be an object other than just because of those little "++" behind the C =)

I don't trust classes that overwrite the binnary operators *fg*

Huh? Come again? I don't see ANY classes in that code. HANDLE is (I believe) a 32-bit integral value, or else a typedef for a pointer of some sort (which is still a 32-bit integral value). CreateFile uses a const char*, and a whole bunch of ints/unsigned longs. ReadFile, same thing, and CloseHandle just takes another HANDLE. ReadFile reads in binary mode by default, I believe, or else there's no other mode. So what do you have against ReadFile()? It's a Windows API function, so it should be the fastest implementation possible, given that you're running Windows.

Quote:

---

Originally posted by Hunter2
Reading should be fairly simple:
file.open(fileName, std::ios::binary | std::ios::in)
file.read(buffer, amount)

---

ifstream, isn't it ?

Yes. And not everything has to be an object; it just makes things easier by sticking everything together, you know, put all your peas in a container so they don't spill all over the place and mix with the apricots :D

Probably also has speed reasons.

And besides, I was talking about ReadFile, which you should have no problem with.

And besides, what overloaded binary operators are you talking about??