Printable View
I'm using DirectX 7 for this, since I have at least a vauge notion of what I'm doing with it...
What determines the color depth of a surface? If I load a 24 bit per pixel image into a surface but DirectX is chugging along at 16bpp, will the image be 'scaled back' to 16 bits? Will GetPixel (GetLockedPixel, whatever) return a 16 bit or 24 bit value?
~Zero the Inestimable
I'm not sure- it may be handled internally as 24-bit and then "scaled back" as you say to 16bpp to display, but I'm not sure. I don't think it does though, because when I load a 256-colour bitmap in a 24bpp environment, palettes don't work. Any other input?
When you lock a surface buffer and then try to directly accesss the memory there (don't know if that works in VB), you must take care of the color depth yourself. There is neither a GetPixel nor a GetLockedPixel function in pure DX (at least not DX6, maybe 7), this must be part of the VB wrapper. I can't help you with this.
The API GetPixel function always returns a 24-bit value.
Yes, but if you needed to find out, look at the locked array and divide the X number by the width of the image. Then you will have the bpp of the picture. x8 is the colour depth.
You have the bytes per pixel (bpp is bits per pixel). You have to multiply it with 8 to get the bpp form.
1: 8 bpp, 256 colors
2: 16 bpp, 65000 colors
3: 24 bpp, 16 Mio. colors
4: 32 bpp, (theoretically) 4 billion colors, only 24 bits used, last is padding
Yea, thats what I said :rolleyes:
But, the last 8 bits is for the Alpha channel if there is one.
Actually, it's the first 8 bits that are the alpha channel.
I suppose experimentation is the only way to do it. I was just wondering if I'll have to do extra math on pictures outside the current colordepth (I'm designing a DX driven paint application). Since I have to run windowed I get my colordepths handed to me on a rusty platter by Windows, and there ain't much I can do about it. If the user loads a 24 bit picture but has the display set to 16 bits, I need to know how accurate GetLockedPixel will be with pulling stuff from the surface I put the picture on...
~Zero the Inestimable
Yes, you have to calculate that yourself.
But as long as you don't need to convert a 16+ bit bitmap to a 256 color one, it's not that hard.
When talking bytes and bits, you don't use "first" and "last". You use "high order" and "low order" or "most significant" and "least significant". Actually, the last version is the clearest, because it is independent of little/big endian format.
Zero, I'm just saying that because it happens to be that way on MY configuration - each computer will vary. It is either ARGB, ABGR, RGBA, BGRA. I believe ARGB is the usual way, in order of most significant bit to least significant bit.
Happy now? :)
It varies? Aw, hell...
~Zero the Inestimable
Well there is a way to detect WHERE they are, using the Bitshifts provided by the Pixel Format. I'm not exactly sure, but it gives you a hex value back and you can find if its the most significant, least significant, or an in-between bit. In this way you can construct where you get certain values from.
If I can find something, I'll let you know...
In C++, I usually define my colors:
Z.Code:0xff00ff99
0xff 00 ff 99
A R G B
Yeah, that's the DirectX color format.
The GDI uses COLORREF which is a hybrid value: FRGB. F is a flag that can be 0 for simple RGB, 1 for an RGB that needs to be mapped to a palette or 2, which means the other bytes are the index in a palette.
shouldn't that beQuote:
Originally posted by Zaei
In C++, I usually define my colors:
Z.Code:0xff00ff99
0xff 00 ff 99
A R G B
0x99ff00ff
why should it?
0xFF is what the DX tutorials use...
Yeah, you turned it around, kedaman. Now you have an alpha of 0x99, red of 0xff, green of 0x00, and a blue of 0xff
Z.
no, if B is the high order byte, it should come first in a hexa decimal notation, etc..
Code:0xff00ff99
B G R A
But DX format is ARGB, not BGRA
ok.. haven't used DX in a while :p