Translucent gfx (i.e. for explosion)

Hi guys! I'm working on some stuff right now (my cheesy "space-shooterz" game to be specific) with DirectDraw, and I've come to a point where I want to add cool explosions. In my head, I'm picturing the screen brightening (as in everything turns just a shade closer to white) for a sec, and a translucent explosion blossoming out and engulfing the sad-looking hand-drawn aliens that look like strange turnips. Ok, so it's not so practical :p But that's the idea.

So my question is, how could I achieve this translucent effect? Would I:
A) just draw a bitmap that has alternating transparent/non-transparent pixels (don't think so, but who knows...)?
B) Use alpha-blending or something?
C) Other

If (B), how could I go about doing so? (from DirectX docs: The IDirectDrawSurface7::Blt method performs a bit block transfer (blit). This method does not support z-buffering or alpha blending (see alpha channel) during blit operations.)

P.S. Or, if it's your real opinion, should I just give up and go home? :rolleyes:

Give up? Hardly.

Gamma:
You mentioned something about everything brightening one shade. This can be done easily. Simply lock the back buffer and walk through the pixels incrementing the RGB components by 1. Make sure to check for overflow though! This is basically a gamma effect. This may not be what you want though. One shade brighter will barely be noticeable IMO.

Alpha Blending:
Alpha blending isn't that bad either! Even if you don't use 32bpp bitmaps you can fake an alpha channel by a constant value. If you want I can write you out a brief overview on alpha blending and some pseudo code you can use. Let me know.

Not sure exactly if that is what you were looking for or not. If not, let me know and I'll re-gather my messy thoughts and try again.

MrWizard to the rescue again! :D I'm thinking that gamma should work fine (as long as it doesn't slow things down, which it doesn't sound like it should), although I guess I'd be brightening it several shades instead of just one ;)

But about the alpha-blending, how would I go about creating a 32-bit bitmap? Paint didn't seem to be capable of using 32 bits the last time I checked :eek: And also, what about the ominous warning in the docs about alpha-blending not being supported by Blt()?

windows bitmaps are only able to go up to 24BPP. But that is not what he was talking about. You can use any bit depth for your images. You make the screen itself 32bit. Then you can apply alpha junk to it.

Hmm, so the alpha stuff isn't built into the bitmap file? You mean it has to be manually entered pixel by pixel in the code or something? :confused:

**EDIT**
I tried doing gamma and made a huge mess of it... then I searched for gamma stuff on Google, and I ended up at the archived DirectX 7 docs, with gammaramps, gammacontrol, and other gammabohemianarchbishopcoinheadgongs. If I'm trying to do gamma stuff, am I supposed to be using gammaramps, or am I supposed to be doing the manual pixel-setting that MrWizard suggested?

no, don't think of it that way. You are thinking on a sprite level, you need to break from that. Think about the screen.

But the common way of this is you have a 24 bit bitmap. You use alpha to blit the 24 bit bitmap to the screen. It makes all the pixels of the bitmap to be blitted with the specified alpha value.

Hmm, what I was referring to was this:

Quote:

---

Even if you don't use 32bpp bitmaps

---

It sounds like you're talking about this:

Quote:

---

fake an alpha channel by a constant value

---

Am I right? But my question is, how would I create/generate/acquire/whatever such a "32bpp bitmap" that doesn't use a "fake" alpha channel?

Quote:

---

Originally posted by Hunter2
Hmm, what I was referring to was this:
It sounds like you're talking about this:

Am I right? But my question is, how would I create/generate/acquire/whatever such a "32bpp bitmap" that doesn't use a "fake" alpha channel?

---

Ah, this thread has expanded since I last was here!

Alpha:
You can have 32bpp bitmaps. I don't see the problem. If you aren't using 32bpp bitmaps ( i.e. 24-bit / 16-bit ) then you'll need to fake it. I'm just going to write up a paper on it and attach it to this post when I get home in a few hours. Hopefully it'll explain everything clearly.

Gamma:
You can use the GammaRamp functions ( using hardware ) or emulate it in software. If you are having trouble with this I can post you a snippet of code later tonight.

Well I have some work to do but when I leave I will post some things on alpha-blending in software and gamma stuff.


I just read where you said something about being warry with DirectX not supporting alpha-blends. This is why you do it yourself in software!

Heh, well, as for the gamma I've already sort of added GammaRamp functionality to my GFX class, with two different intensity-level calculating algorithms :p But any help on the software-emulation version would be greatly appreciated, as well as the essay on alpha :)

Well the Gamma in software is actually pretty easy. Its very easy but if you need to see the code I can e-mail / post some source. Basically all you need to do is use the Lock method to get a pointer to the actual surface bits. Then just go through the pixels incrementing each component ( B G R ordering ) by a certain amount. Not much to it.

I have attached a very simple alpha blending document. I wrote it up real quick and may have made some mistakes, who knows. If it helps then great. I should have took more time but I know you wanted to read something on it.

DirectDraw is an obsolete interface.

Use DirectGraphics/Direct3D and you can use alternative A) with hardware support = very fast

Here's a good article:

http://www.gamasutra.com/features/20010629/geczy_01.htm

DirectGraphics??? Strange, I've never heard of it... and I thought that Direct3D was only for 3D... But what is alternative A)? If it's gamma, I dunno what you mean because I thought gammaramps were hardware.

*Also, I can't go to the link because I'm not a member...

P.S. Thanks for the help on alpha MrWizard. But about the manual-pixel-setting gamma, I tried that but found it a bit hard to figure out while trying to maintain support for all of 8-bit, 16-bit, and 32-bit resolutions :(

DirectDraw is no longer being updated by Microsoft. Instead all graphics, 3D and 2D should use the same set of interfaces, DirectX Graphics. It's actually Direct3D.
I recommend reading that article, it taught me alot. I didn't know membership was required, but it's free anyway.

IMO, Direct3D is superior to DirectDraw for 2D. It's much faster and easier to set up. It has built-in support for sprites etc. It is also possible to use nice hardware-features like alpha-blending and rotation, scaling and "color blending" (don't know what it's called).

Forget all about manual alpha blending and let DirectX do it for you.

Quote:

---

Originally posted by Hunter2
P.S. Thanks for the help on alpha MrWizard. But about the manual-pixel-setting gamma, I tried that but found it a bit hard to figure out while trying to maintain support for all of 8-bit, 16-bit, and 32-bit resolutions :(

---

Try getting it working with one format then try to add support for the others. This is usually done be keeping track of the user's bits per pixel. Then you need to get the channels ( BPP / 8 ). So lets so I'm running in 24-bpp and you wanted to support that. Whenever you are going to manipulate the bits you need something like this.

NOTE: Assume lpR, lpG, lpB to be pointers to the RGB components of the surface. Assume lPitch to already been initialized to the pitch of the surface.

Code:

---

unsigned char channels = BPP / 8;
lpB = (lpPixelBits + (y * lPitch) + (x * channels));
lpG = (lpPixelBits + (y * lPitch) + (x * channels) + 1);
lpR = (lpPixelBits + (y * lPitch) + (x * channels) + 2);

// MAKE SURE YOU CLAMP THESE VALUES! ( 0 - 255 )
*lpB += 25; // Brighten by 25
*lpG += 25;
*lpR += 25;

---

Good luck and if you get stuck I'll take a look at the code.

Sang-drax:

While I do agree with you that Direct3D is taking over for not only 3D graphics ( obviously ) but also the 2D graphics seeing as DirectDraw is no longer supported. Learning DirectDraw before I learned Direct3D made the transition easier for me though. Don't you also think its important to understand how things work in software before using hardware support ( i.e. Alpha-Blending )? I think that is very important.

No, I don't think that is extremly important.

If you don't use alpha-blending "automatically" with Direct3D without knowing the underlying technique, then why do you use DirectDraw without extrensible knowlege of graphic driver programming or video memory allocation for different hardware brands?
DirectDraw is not low-level. I'm sure you are using Blt() without knowing exacly how the hardware handles the memory.

The whole point in using API's (and the whole OOP concept) is that you don't have to care about what's going on beneath the surface; you only have to care about the interface.

Although knowlege is never wrong (I myself has programmed DirectDraw once) it is not imperative

Sang-drax, I agree that sometimes it's not needed to know what goes on under the hood, but I've already started with DirectDraw, and I don't feel like abandoning my half-ported game just yet :( And also, I just feel like doing DirectDraw first, since I once took a course with Direct3D and it went right over my head with matrix world/universe axis-level transform boundary checking, and other confusing stuff like that, and I'm sort of scared :D

And I think I'll stop saying "Thanks for the help MrWizard", because it's getting repetitive :p

**EDIT**
MrWizard, looking at the transparency tut you attached, I'm looking at this line:

unsigned short AlphaVal = lpSourceLine[ ALPHA_OFFSET ];

Is that just retreiving the alpha value of a certain pixel? If so, I'm sort of confused about how to put the alpha value there to begin with, since Paint doesn't support 32 bit bitmaps, and neither does Paintshop Pro 7 (or at least I don't think so).

**EDIT2**
Hmm, new idea: loading a greyscale image for the alpha channel. Would this work?

And another thing, on the second line ( :rolleyes: ), you have Alphaval * Opacity (...). You mentioned that it is combining the two, but how exactly..? Is it something like "50% of 50% of the pixel gets copied"?

Quote:

---

Originally posted by Hunter2
And also, I just feel like doing DirectDraw first, since I once took a course with Direct3D and it went right over my head with matrix world/universe axis-level transform boundary checking, and other confusing stuff like that, and I'm sort of scared :D

---

Dont be scared! :)
Now listen to me: 2D programming in Direct3D is easier than in DirectDraw. Direct3D is only complicated when dealing with 3D-graphics. No matrices are needed, no transform is needed and no other confusing stuff like that are needed when dealing with 2D graphics.

There are many interfaces like ID3DXSprite and ID3DXFont that are really easy to use.

I know this, because I've ported my DirectDraw game engine to Direct3D 8 and I got more functionality, faster execution with less code. With Direct3D, there's no need to worry about clipping, locking surfaces, using GDI for drawing text and double buffering.

But since you've already started, I guess the choice is easy. :(

About Mr Wizard's way of increasing lightness of a pixel.

Code:

---

// MAKE SURE YOU CLAMP THESE VALUES! ( 0 - 255 )
*lpB += 25; // Brighten by 25
*lpG += 25;
*lpR += 25;

---

To brighten a pixel by just adding values is wrong, and could alter the color of the pixel etc.
Instead convert the RBG to HSL (hue,saturation,lightness) and alter the lightness parameter.

http://www.cprogramming.com/cboard/s...ght=saturation

Hmm, I guess Direct3D is the next stop for me. But first I have to fulfill my purpose here on Earth :D

But about converting to HLS, how would I do this?

Code:

---

//loop through thing
COLORREF temp = ColorRGBToHLS(*currentPixel);
temp = RGB(GetBValue(temp), GetGValue(temp) + 5, GetRValue(temp));
*currentPixel = temp;

++currentPixel;

---