• Advertisement

Archived

This topic is now archived and is closed to further replies.

GDI: Pixels Not Showing On Some Systems

This topic is 5747 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''m writing a simple program to give me an idea of how graphs of two complex planes look like and the first version of the program works fine on my machine (graphics card: TNT2, OS Win98) and on Jesper T''s machine however the two planes will not show on a machine at my school (unknown graphics card, OS Win98) and on another friend''s machine (OS: Win98, graphics card: unknown, whatever came with his HP when he bought it) I''m using the GDI functions Bitblt(), GetPixel() and SetPixelV(). I know Bitblt() works because both machines were able to see the bitmap loaded from a resource in the about box, the only thing that does not show are the bitmaps that are created using CreateCompatibleBitmap() and then colored using GetPixel() and SetPixelV(). I added some code to check the device caps to see if the graphics card supported BitBlt() and then had my friend re-run the program but he said that no error occured (which is what I was expecting since he could see the resource bitmap) I''m not very familiar with GDI errors and am out of ideas on this one. Do any of you have any idea what could be the cause? If you''d like to look at the full source and/or see the executable you can download them here
I will not make a list of links... I will not make a list of links... I will not make a list of links... Invader''s Realm

Share this post


Link to post
Share on other sites
Advertisement
All graphics cards support BitBlt. Other kinds of devices might not (maybe certain printer drivers).

Is there perhaps a NULL value being returned for the CreateCompatibleBitmap? In fact, there is no call to CreateCompatibleBitmap in the code you posted, just to CreateBitmap.

One way to figure out what''s going on is to dump all parameter and return values to disk. (Assuming you don''t have a debugger available on the systems you''re running on)

Share this post


Link to post
Share on other sites
I''m sorry, I was thinking of a previous implimentation where I did use CreateCompatibleBitmap()

I''ll try checking for NULL returns and failed returns from all the GDI functions and printing those out and then I''ll have my friend just copy and send me the text in the file.

Thanks



I will not make a list of links... I will not make a list of links... I will not make a list of links...
Invader''s Realm

Share this post


Link to post
Share on other sites
Also, make sure you dump the actual parameters you''re sending to the functions as well. For example:

CreateBitmap: NULL

means less than

CreateBitmap (32, 32, 2, 46, NULL) -> NULL

(Assuming creating a bitmap with 2 channels of 23 bits each will fail )

Share this post


Link to post
Share on other sites
Ok, my friend tested the program with the new error codes (not on the site right now, but nothing was changed except I added more error checking code) and this is the only error that was put out:

DrawZ(), SetPixelV(00001466, 0, 1, 65536) failed!

Recall, this is coming from this line of code:

SetPixelV(hMem, i, j, RGB(i, 0, j))

hMem is an HDC to a bitmap created with CreateBitmap(255, 255, 1, 32, NULL)

You mentioned that other devices might not support parts of GDI, would I use GetDeviceCaps() to check RC_BITBLT or is there another function I would need to use? Currently I''m using GetDeviceCaps() at the beginning of the app (before the window even loads) but am checking it using a DC created with CreateCompatibleDC(NULL). MSDN says that that will make a DC compatible with the app''s current screen, if there is nothing currently displayed then what is GetDeviceCaps checking? (I assumed the desktop)



I will not make a list of links... I will not make a list of links... I will not make a list of links...
Invader''s Realm

Share this post


Link to post
Share on other sites
GDI supports plotters, raster displays (which is what you use), raster printers, raster cameras, character streams, metafiles and display files. If you use a raster display, you don''t need to check for BITBLT. It is always supported. When using CreateCompatibleDC (NULL), you are simply creating a raster display DC.

Anyway, it''s still not quite clear to me what exactly is going on, but here''s what I think:

When you create a device context using CreateCompatibleDC, its display surface is a 1x1 pixel monochrome bitmap. Selecting an appropriate bitmap into it changes that. Somewhere in your program, this goes wrong and the second pixel drawn has a value (0x010000) which is outside the {0,1} range of a monochrome bitmap, causing SetPixelV to fail.

Using CreateCompatibleBitmap with a DC that has its default (monochrome) bitmap selected into it creates a mono bitmap. If you use CreateCompatibleBitmap, try this instead:


  
HDC displayDC = GetDC (NULL);
Z = CreateCompatibleBitmap(displayDC, ZWidth, ZHeight);
ReleaseDC (NULL, displayDC);


Still, there should be no reason why this code shouldn''t work with CreateBitmap. I have not been able to reproduce the problem. (I did manage to have a monochrome bitmap displayed, but that didn''t cause SetPixelV to fail, perhaps because I''m running WinXP)

In my own stuff, I don''t generally use CreateBitmap, but CreateDIBSection instead, like this:


  
//A pointer to the bitmap data

COLORREF *data = NULL;

//Set up the bitmap data

BITMAPINFOHEADER bmih = { sizeof (BITMAPINFOHEADER) };
bmih.biPlanes = 1;
bmih.biBitCount = 32;
bmih.biCompression = BI_RGB;
bmih.biWidth = ZWidth;
bmih.biHeight = ZHeight;

Z = CreateDIBSection (hMem, (BITMAPINFO *)&bmih, DIB_RGB_COLORS, (void **)&data, NULL, 0);


That way, you can change the colour data yourself without having to do the horribly slow SetPixelV.

Share this post


Link to post
Share on other sites

  • Advertisement