very well., I''m totally confused with those two concept.... thanks,

hmm.., okey,

what makes-up/constitutes a Device Dependent Bitmap and what makes up a device Independent Bitmap?

Surely you went to MSDN?

The first links were Device-Independent Bitmaps and Device-Dependent Bitmaps

Better luck with searching next time.

[edited by - IndirectX on May 9, 2002 10:25:57 AM]

ack! nonono stop..., plz you have to explain that to me., i have read dozen books about DDB and DIBs, Petzold''s, Black Art, etc., and yes MSDN! I just couldn''t understand very well between the two...

and hmm.., IndirectX, no offense but you seems to think people don''t read here ye know, i always see your posts and you always tell people to read etc., probably they didn''t understand what they read, like me so they asked here on the board..,

hope you could help me here instead of telling me to read coz i''ve done that,

quote:Original post by mickey
you seems to think people don''t read here ye know, i always see your posts and you always tell people to read etc.

Some people don''t. I remember posting a page full of links to "unresolved external symbol _main" posts after someone claimed to have searched the forums and found nothing.

quote: probably they didn''t understand what they read, like me so they asked here on the board..,

The way you phrased your question was very vague. Basically, in your first post you didn''t even ask a question, and your second post logically lead to the two links I posted. If you asked a more specific question or told us what you''ve already read, you might have gotten a more useful answer.

quote:
hope you could help me here instead of telling me to read coz i''ve done that,

OK, I''ll try. Consider this: a bitmap can live either in memory (let''s say selected in a DC) or on disk (as a file). Now a bitmap that is selected in a DC is known as a device-dependent bitmap, aka compatible bitmap, because it has the same color layout as the DC it''s selected into. If you have 16-bit screen resolution, your DCs have 16 bits per every pixel so that Windows can draw them directly on screen. If you have 32-bit screen resolution, you have 32 bits per every pixel. The point of matching color formats is that doing so allows for faster operations, as no 16<->32 bit conversions need to be performed. So the format in which a data in a compatible, or device dependent, bitmap is stored depends on the DC in which it is selected, hence the name. Because of that, you can''t generally use a compatible bitmap on a DC that is not compatible with the bitmap''s pixel format, like you can''t use a 16-bit surfaces in 32-bit display modes. A DDB has only enough information to make it possible to draw the bitmap on a DC with precisely the same color format.

A DIB is something like a file. You want to store your data independently of the screen resolution and format that your game uses, right? So DIBs have a set format and contain enough information to render them properly on any DC.

Two most important pieces of information that are present in a DIB are 1) color palette, and 2) color/index data in a known format. You need the palette so that you can uniquely map color data to RGB colors, and you need to specify the exact format of the color data so that all loaders can load all BMP files. Color data can be conposed of palette indices, RGBQUADs, RLE compressed data or other compressed data (Win98+ and 2k+ support JPEG and PNG compression, I believe, in bitmaps).

On the contrary, a device-dependent bitmap doesn''t have its own palette data. It doesn''t need it, because the device on which it is rendered already has a palette (if any), and you can''t have two palettes active at the same time. Also, the format of bitmap data must match for format of the bitmap data for the DC using which this bitmap was created. If a DC has some weird format, the bitmap will have that format as well. You really can''t expect compatible bitmaps to store data in any predefined format, because as I said changing screen depth may change that format. Different video cards also may dictate different formats (ie, 555 vs 565 and so on).

To summarize: DIBs store data in a well-known format (RGBQUAD for BI_RGB compression) and have a palette among other information that is required to be able to draw this bitmap on any DC. DDBs store data in a device-dependent format on which you should not rely and don''t have a palette. They are intended to be displayed only on DCs compatible with the one which was used for their creation.

Let me just repeat that you will probably get more useful/related answers if you ask more specific questions.

**wow** IndirectX, i never thought you're going to help me out as i was thinking like we're going to start an argument scene here or something, that was my very first response to contradict someone else's post. I was even thinking if i would submit this or not because i might get someone(ie, you) to argue with me hehe but heck i tried and see what will the result be,

anyway, again thanks a lot for the very long and informative explaination but... err., i'd just like to explain what you just posted so i'd know if I, once and for all, understand really what a DIB AND DDB is so plz don't go away yet..,

all graphics files are either DDBs and DIBs...,

DDBs... are now.. gone! okey not gone, people don't use DDBs anymore because their inefficent, they depend on the system/os. So for example, OSA can only support 16bpp, and our DDB is 32bpp, this DDB can not be used on this OSA right? or probably, OSA is not the right term? maybe it should be 'DC'?

but DIBS, they are different, they can be of any bpp because, they have enough information to work on any kind of screen(ie, resolution etc.,) so, this means, all of them can be selected onto a DC...

but this has no connection on what i asked on the other thread here., i was aking, after getting the graphic datas on a say, JPG, how will i put it on a DC? and the guy gave me links to DIBs and DDBs...,

also, should it be decompressed first(jpg) before i go and use it?

and last, can i see a sample of a DDB?

thanks a lot!!!

[edited by - mickey on May 10, 2002 6:17:52 AM]

hi,

what does this thing mean?

''Bitmaps are an exception to the object realization process; although they have the device-independent bitmap (DIB) logical form, bitmap objects are always device specific and are never actually realized.''

something that has to do with how the GDI works..,

thanks,

quote:Original post by mickey
all graphics files are either DDBs and DIBs...,

I''ve never seen a DDB file, and I doubt that there are any. That''s because there is no way of knowing the bitmap''s data format. In your program, you keep a DC around on which you paint DDB, but once you write DDB to a file, you can''t recover its internal format using just the DDB. So, I think that all graphics files are saved DIBs. HBITMAPs can be DDBs or DIBs, not files.

quote:
DDBs... are now.. gone! okey not gone, people don''t use DDBs anymore

You use DDBs every time you call CreateCompatibleBitmap.

quote:
because their inefficent

On the contrary, because DDBs have the same format as the DC they are painted on, they are more efficient than DIBs.

quote: they depend on the system/os.

This is true, but you should never need to examine internal DDB data in your programs.

quote:
So for example, OSA can only support 16bpp, and our DDB is 32bpp, this DDB can not be used on this OSA right?

Exactly.

quote:
or probably, OSA is not the right term? maybe it should be ''DC''?

I suppose. What''s OSA again?

quote:
but DIBS, they are different, they can be of any bpp

DDBs can also be of different bpps. It''s just that you know memory layout of color data in DIBs and you don''t know this for DDBs.

quote:
because, they have enough information to work on any kind of screen(ie, resolution etc.,)

This part is right.

quote:
so, this means, all of them can be selected onto a DC...

I doubt that you can select DIBs into DCs. Why do you suppose there are SetDIBitsToDevice and similar functions?

quote:
after getting the graphic datas on a say, JPG, how will i put it on a DC?

You have to decompress it and then blit it. You can use either one of freely available JPEG libraries, or Win32 functions if you''re runing Win98/2k+.

quote:
also, should it be decompressed first(jpg) before i go and use it?

Yes.

quote:
and last, can i see a sample of a DDB?

I''m already late for school, I''ll post some code when I get home (after 7 hours or so).

Here''s a function to save screen contents as a DDB in a file:

quote:Original post by mickey
what does this thing mean?

''Bitmaps are an exception to the object realization process; although they have the device-independent bitmap (DIB) logical form, bitmap objects are always device specific and are never actually realized.''

I may be able to answer this if you post a link to where you got this from. I have a feeling that realization refers to "palette realization", and since today you''re not generally using palettes, it''s not something you should be worrying about.

hi indirectx,

quote:
You use DDBs every time you call CreateCompatibleBitmap

so all DIB's, upon invoking the SelectObject, are automatically converted to a DDB too?

okey i'm confuse.., this is a description from MSDN,

quote:
The SelectObject function selects an object into the specified device context (DC). The new object replaces the previous object of the same type.

since all files now are DIB., so after i load my bmp using LoadImage, i get a Handle to a bitmap right? but before i use this, i must select it onto the DC using SelectObject, and you say that

quote:
You use DDBs every time you call CreateCompatibleBitmap

and MSDN says that SlectObject replaces the previous object of the same type, but they are not the same are they?

but hey, i think everything is quite clear now, just want to undertand more..,

thanks,


[edited by - mickey on May 11, 2002 1:46:31 AM]