Printable View
Sorry if this seems a bit of a newb question, but how do I use GDI to paint a BMP to the window, I already created the bmp in memory at lets say &BitMap
Again I appologize for the probable simplicity of this question, i mostly do networking and multithreading , never had to draw images before.
Perhaps using DrawDibDraw as I do? If you have transparency (a bitmap with an alpha channel included), then you'd use AlphaBlend instead.
Woot, thanks, the windows help file was not being very forthcoming with info about anything more than drawing some lines.
Yeah, I know, searching for things in the documentation is a pain. I find it easier, faster, and more convenient to just ask on a forum. I've been told DrawDibDraw is the fastest method for drawing images on screen without DirectX with only DirectX being faster.
Ulillillia,
I don't know where you got the idea of using "special" functions to draw a simple bitmap, maybe it's a bit faster, but the standard way is BitBlt, and it is fast enough for most uses.
Your post is just based on information you got from someone who told you about DrawDibDraw, and on the information you got from me (AlphaBlend). But you seem to have missed any basic knowledge of GDI.
The by far common way of drawing a bitmap is using GDI functions like BitBlt. That's fast enough for everyone that doesn't need to use DirectX, I had never heard of DrawDib before, and every code I have seen that draws a bitmap onto a window uses BitBlt.Quote:
using DrawDibDraw as I do? If you have transparency (a bitmap with an alpha channel included), then you'd use AlphaBlend instead.
Maybe this is for you: http://www.winprog.org/tutorial/bitmaps.html
I don't know what the standards are or what is commonly done. I'm still fairly new to C programming stuff. I'm not necessarily new to programming though as I've been doing it since January of 2005 using another tool. At least DrawDibDraw still does the same thing.
DrawDibDraw was originally part of Video for Windows. It was envisaged to be a function that provided the fastest way to get a bitmap on screen (in the days when graphics hardware acceleration was on the whole non-existant). BitBlt was and still is an integral part of Windows GDI, but at the time was slower due to having to perform conversions between colour depths and performing lots of checks.
Fast forward to today, and DrawDibDraw is pretty much obsolete. If you're writing a video codec you might want to use it, but DirectShow can give you a whole gamut of better stuff. BitBlt, thanks to 99.9999% of modern video cards supporting basic hardware acceleration, is an awful lot faster than 15 years ago.
well, since drawdibdrab turned otu to be a non-starter, Im actually using bitblt. I found a sample somewhere that I got working. Now the problem is that the only image I can blit to the screen is my prefab resource bmp. Im trying to get it to let me use a generated BMP, but I havent nailed it down yet. Here is the code :
the buffer BYTE bufNoSignal[] contains the BMP that I loaded from disk, including the initial 42 4D (BM) tagCode:void DrawFrame(HDC hdc){
HDC hdcMemory;
hdcMemory = CreateCompatibleDC(hdc);
//hdc = GetDC( hwnd );
hbmNoSignal = CreateDIBitmap(hdc , (BITMAPINFOHEADER *)&bufNoSignal[2] , CBM_INIT , &bufNoSignal[54] , (BITMAPINFO *)&bufNoSignal[2] , DIB_RGB_COLORS );
//ReleaseDC( hwnd , hdc );
SelectObject(hdcMemory, hbmNoSignal);
BitBlt(hdc, BMPX, BMPY, bm.bmWidth, bm.bmHeight, hdcMemory, 0, 0, SRCCOPY);
DeleteDC(hdcMemory);
}
If it is a standard bitmap, you don't need to load it manually. You can use LoadImage with LR_LOADFROMFILE.
well, the image it self will be modified by the program, so I wrote the code to work with a memory image.
If you want to dynamically modify an image, you should modify the image data part, the pixel data. I do this with my "Interactive Animation" program to get dynamic fog. I change the pixel color data (leaving the alpha unaffected) to get the fog. Remember that BMPs are read bottom to top, left to right and the pixel color values are read in BGR order. BGRA is used for those with alpha.
Yup, I know the format of the BMP files, having worked on some custom compression programs before. I was just having problems with converting a BMP memory image to something that GDI wouldnt cry about. Since I was using CxImage to convert the original image from JPG to BMP I also had to hack together a simple image parser since CxImage likes to append the decoded BMP to the buffer you feed it. Made for some really odd looking out of sync BMP's until I fixed that problem.
Ulillillia, you see you'd better use GDI instead of this obsolete stuff, as I already thought.