DirectDraw RGB in 32 bpp modes

Alright, when I enter 32 bpp mode in directdraw, I try to use the RGB macro, but sometimes I need to make colors opposite to make some appear right. Example:

RGB(0,0,255)-Makes Red (Sometimes makes blue)

But I've seen some source (space shooterz, among source from here), that uses a plain old RGB macro. No special RGB32 macro that isn't predefined. But when my friend tries out the programs, everything is normal

RGB(0,0,255)-Make blue

Which makes my game look junky. I'm using WINDOWS 98

NOT SECOND EDITION

People seem to miss OS's

Quote:

---

But I've seen some source (space shooterz, among source from here), that uses a plain old RGB macro.

---

Actually, I used a colorMatch() function to get the DWORD colors for DirectDraw. Otherwise, the functions I was using probably called GDI functions, which use the RGB macro anyways. ;)

Basically (I can't recall the exact code at the moment), the colormatch function did something like this:
Use GDI GetPixel() to get the color at (0,0)
Use GDI SetPixelV() to set the color at (0,0) to the closest match for the RGB color you used
(?)Lock the buffer, get the pixel at (0,0), unlock it
Use GDI SetPixelV() to set the color at (0,0) back to the original.

I don't think that's exactly what my code does (I can't check because my harddrive burned out yesterday and I'm still trying to get my stuff reinstalled), but it's something to that effect.

I do not recommend calling any GDI functions from within DirectX if you can help it.

You need to create a buffer; lock it and get a pointer to it - from DirectX and then write to it like an array.


For 32 bit color - it should be:

#define RGBA(a,r,g,b) ((a<<24)+(r<<16)+(g<<8)+b))

if alpha is in the most significant byte of the 32 bits.

Screen[location]=RGBA(0,255,255,255)

Should be bright white.

If you are not getting these colors with your code then you are not shifting the values correctly.

(0,255,0,0)=Bright red
(0,0,255,0)=Bright green
(0,0,0,255)=Bright blue

Quote:

---

Originally posted by Bubba

For 32 bit color - it should be:

#define RGBA(a,r,g,b) ((a<<24)+(r<<16)+(g<<8)+b))

---

Use Get/SetPixelFormart (I think it's called) to get the exact bit format of the pixels. It may vary (especially in 16-bit color mode)

Quote:

---

DirectDraw RGB in 32 bpp modes

---

He is not using 16-bit color modes so 555 and 565 do not matter here.

Thats right only time you should have different format is in 16bit mode. 32bit mode with direct draw will always be Alpha, Reg, Green, Blue. So shifting is the only thing that could be wrong. If your using 32bit modem with no alpha just store FFFF in alpha (I believe or 0000).

You could only store 00h to FFh in alpha since it is an 8-bit value. 00h alpha represents an opaque color that is not blended - FFh would give max blend were you to mix colors later.

Quote:

---

I do not recommend calling any GDI functions from within DirectX if you can help it.

---

But you must admit, they do come in quite handy sometimes, i.e. when loading bitmaps. And, I didn't mean to call the colorMatch() thing all the time, just at init and then store the return in a variable so that you can refer to it later if you want. No, not a terribly good way of doing it, but it should work for any color mode you want.

Quote:

---

You need to create a buffer; lock it and get a pointer to it - from DirectX and then write to it like an array.

---

Yes, but you need the color value first... and if you don't want a user-defined macro (i.e. RGBA), you're going to have to manually enter the colors or else substitute the bit-shifting in instead of the macro. Or, as I suggested, make a colorMatch() function if you're not sure what mode you're going into.

Otherwise, I agree with Bubba... make a RGBA macro or inline function

Thats right my bad. I didn't mean to put 16bit lol

Thats right my bad. I didn't mean to put 16bit lol

Quote:

---

But you must admit, they do come in quite handy sometimes, i.e. when loading bitmaps.

---

Yes. However, they are extremely slow. Most of MS functions do everything but take out the trash for you - which is not necessary for games. We only care about 1/100th of the possible uses for our code wheras MS wants their code to work with everything out there and for everything out there which amounts to a lot of code bloat.

Code bloat for loading bitmaps? I thought that it rather shrank the size and complexity of the code... Besides, reliability counts for more than speed does in initialization, doesn't it?

But aside from that, I agree with you about not using GDI (although I'm too lazy to come up with my own line-drawing functions).

Well if your game programming and drawing lines i suggest learning how to write the code. Thats the joy of being a game programmer lol. And yes MS bloats there code. DirectX is probably the only systemt hat is wide spread that is fairly non bloated or at least very well setup to show not much. As for bitmap and games we don't need all the extra information plus it will be taking up space that we could use so why keep it. Strip the stuff off and don't worry about it. Keep only what you need. This way nothing will bloat your program.