C++ Windows API: Is there any alternative of the SetDIBits for device-dependent Bitmap? RRS feed

  • Question

  • I am trying to make a graphics engine for a Windows API window (something like a game, I've not decided yet), and I do this because I want to practice my math skills and I want to learn more about how this stuff works.

    I wanted just a fast-enough function to put a pixel on it. Setpixel, as you may know, is very slow when used to fill a screen, even without calculations. So I've been searching for a long time, until I found this function (SetDIBits) which puts an array of pixel data (I use 24-bit because it has many colors and it's simple) into a HBITMAP class, device-independently (I don't know what this really means), but there says that device-dependent bitmaps work faster. ("Probably the biggest limitation of DIBs is that they are slower than device-dependent bitmaps.")

    Here is the address: http://msdn.microsoft.com/en-us/library/ms969901.aspx .

    I have some questions:

    1. Is the time difference big, I mean, for making animations?

    2. Does it help me if I use device-dependent instead of device-independent, as far as I work only on one window?

    3. I have a small problem: I am trying to make a blue screen, and it works for some weight and height values, such as 100 x 100, 600 x 100, but for 150 x 150 bitmap, there appear some red lines, green lines, and I don't know exactly why. I think this may be because I use this index (width * bottom + left) * 3, so the image would have a size of (width * height * 3) bytes, and in the page, it says biSizeImage = ((((biWidth * biBitCount) + 31) & ~31) >> 3) * biHeight. I don't understand this, but I think that here is the problem. What do you think?

    (Here is my code:http://pastebin.com/Skdv7KGS , and here is a screenshot: http://imageshack.us/content_round.php?page=done&l=img843/5690/screenshothc.png&via=mupload&newlp=1# )

    I use Code::Bocks MinGW GCC compiler (http://www.codeblocks.org/).

    Thank you!

    Saturday, September 24, 2011 2:23 PM


All replies