Thread: Rendering 32-bit images - alpha is ignored

Originally Posted by ulillillia

Of course I know that, but some functions, like alpha blend, will not work when height is negative. The main thing is that it matches BMP files which otherwise helps keep the consistancy in style and retain maximum support. If I want bottom-up coordinates instead of top down (as most graphics edittors use), just take the image height, then subtract the coordinate and 1 extra. The coordinate (0, 255) on a 256x256 image is the bottom left pixel. 256 minus 255 gives 1 but the actual position is 0. It's simple math at about the 4th grade level.

Um, I know that. Didn't know that some functions couldn't work with top-down bitmaps. Sounds like those functions are badly broken.

As I explained you don't need to specify a color table of 1 entry (not that useful), so you don't need RGBQUAD.

If I don't include RGBQuad, then AlphaBlend fails because the bitmapinfo thing has something uninitialized. If I do include it, then I just get compiler errors (cannot convert along with some others). You're saying I don't need it, but there's an uninitialized value if I don't include it. Please explain what I need to do.... You're only giving conflicting information.

Originally Posted by ulillillia

If I don't include RGBQuad, then AlphaBlend fails because the bitmapinfo thing has something uninitialized.

So initialize it. Set it to NULL. The documentation clearly says this.

Originally Posted by ulillillia

Of course I know that, but some functions, like alpha blend, will not work when height is negative.

Not if you try to mirror it vertically while drawing, by passing a negative height. But you can mirror it while creating a bitmap. For example, you can pass a negative height to CreateDIBitmap() to specify that the bitmap is top-down. That works fine.

Yes, it's working now and I calculated the resulting color displayed (after snagging a screenshot) and it is exactly what I'm expecting it to be. I ran my alpha transparency formula with the original on the background and the colors were off by fractions and rounding them gives identical values. I wonder what the premultiplication is used for and why it's needed.... Maybe for simplification of the formula (as, looking at my formula there, it's a little lengthy).

Yes, it was the placement of InitializeDrawing that messed things up. I moved it by using copy paste then commented out the original and it then worked. Yay! Now let's see if I can do the hills correctly which also has alpha. The bitmap font will be more complex since it gets cropped out with random amounts (for each character). I know how to get the character and location needed, cropping the image would be new. I'll try figuring that out on my own but if I'm unable to resolve it for some reason, then I'll ask about it again. Thanks for the assistance.

Yeah, finally, victory!! Pretty simple solution, actually.

I also noticed I misplaced the "initialize object positions" function. The two merely needed to be switched around. I've added the fog (and had a bug since I forgot to declare a char as unsigned then I had a copy paste mistake where I forgot to fix the array. The mountain's scaling is 1125 (exactly 10 miles distance) and the visibility is 1350 (exactly 12 miles). The fog now works exactly as expected. Yep, I've got the formula for fog as well, another derivative of the fundamental color-averaging formula. Next up, the hills (of which have a scaling of 900 (exactly 8 miles).

Great, it does not look hard at all to understand, your fog thing, if I'd only know what those words mean.

What are you confused about with the fog? The formula? What the fog does? I'm figuring out text displaying which uses AlphaBlend. I'm only having trouble getting wordwrap working right (infinite loops - oy!). The text stuff is a more complex usage of AlphaBlend. Everything is now working outside the text.

I only meant that I wouldn't know what BC, PDIST or VIS are.

Ok thanks for that information, maybe I could use that some day.