Jump to content
  • Advertisement

Archived

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

SkyDruid

Yet another DDraw 16-bit question. :)

This topic is 6472 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

IDirectDrawSurface7::GetPixelFormat() is used to find the pixel format of a surface, and is useful for figuring out whether a 16-bit DirectDraw setup is in alpha.5.5.5, dummy.5.5.5, or 5.6.5 format. However, I''m developing a class hierarchy that uses a different derived class for each format. This is simple with 8-bit, 24-bit, and 32-bit--simply "new DDSurface8/24/32" or whatever. But GetPixelFormat doesn''t work unless you already have a surface to call it on. My question: Is there any way to find out what the pixel format is before you create the primary surface? IOW, can you query DirectDraw (or Windows) rather than a DirectDrawSurface to figure out the pixel format? I had one idea--set the video mode for 16-bit, create a temporary offscreen surface of 0x0 pixels (or 1x1, 2x1, or whatever is possible and most efficient), query that surface for the format, then delete it. That seems kinda silly, but if there''s no other way, would it work?

Share this post


Link to post
Share on other sites
Advertisement
You might have to do that; I can''t think of anything that returns a DDPIXELFORMAT except for calls from IDirectDrawSurface7. Of course, I haven''t been working with DirectX too long, so maybe I''m overlooking something...

-Ironblayde
 Aeon Software

Share this post


Link to post
Share on other sites
As far as I know, the pixel format varies only from card to card, so all surfaces on any one computer would have the same format. Thus, I would say it would be easiest to do what you were saying - Create a temporary surface and get it''s pixel format. Then you can use that info whatever you need. Don''t forget to destroy the temporary surface once your done with it. Also, I''m pretty sure a surface must be at least 1x1 pixels. Hope I got all this right, and good luck.

Share this post


Link to post
Share on other sites
Use GetSurfaceDesc and the pixel format member of DDSURFACEDESC2 instead of GetPixelFormat. GetPixelFormat doesn''t seem to work properly.

Share this post


Link to post
Share on other sites
GetPixelFormat() works fine for this purpose, but the difference between 555 and 565 is not reflected in the dwRGBBitCount member. You just have to look at one of the bit masks, like dwGBitMask. If it''s 0x07E0 you have a 565 pixel format; if it''s 0x03E0 you have a 555 format.

-Ironblayde
 Aeon Software

Share this post


Link to post
Share on other sites
quote:

You just have to look at one of the bit masks, like dwGBitMask. If it''s 0x07E0 you have a 565 pixel format; if it''s 0x03E0 you have a 555 format.



This is a very dangerous assumption. Let''s say that one 555 mode has the format ARGB and another has RGBA the green mask wouldn''t be the same for those, and there are almost an unlimited number of different variations.

Share this post


Link to post
Share on other sites
I was afraid of that, too. TotWGPG "forgot" to mention this, but I noticed the different formats while browsing the DirectX 7.0 docs. It does that for just about any format--24-bit might be xRGB, but it could also be xBGR. 32-bit even has a couple with 16-bit alpha and 15- or 16-bit RGB.

What I have works for now, but I''ll have to whip up a couple of rearranged color conversions and add another level to my surface hierarchy. Fun.

Oh, btw, the temporary surface thing seemed to work; I checked the surface description to get the green pixel mask, and it came up okay. Now, of course, I''ll have to check all three masks to be absolutely sure.

Thanks for all the help; this board has a heroic tolerance for 10000-times-asked questions.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!