In case the title didn''t give it away, I am having a problem with my alpha blending routine. I have a really simple one: lock the surface, split the colors using my home-grown SplitColor16() function, average with alpha blend color, and put back on the surface. I unlock it, btw . I have three problems with it. 1) As a test, I tried making it blend an NxN rectangle of the backbuffer with RGB16BIT(255,255,255). It works, but it averages EVERYTHING, not just the overlays. Do I need to write my own transparency code? There must be a better way. 2) I can''t control the blend ratio (or maybe intermix ratio ). I would really like to know how to do that. I am using a formula like this: Surface[x * (y + lPitch << 1)] = (Original + New) << 1; to average the new and old colors. 3) It is as slow as molasses in January! With a 200x200 rectangle (square ), I get 5.4fps. Needless to say, 5.4fps just isn''t good enough. I am doing every optimization I know of, without effect. Thanks ahead of time for helping to solve yet another of my problems. --------------------

You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming

You are unique. Just like everybody else.

Yanroy@usa.com

Visit the ROAD Programming Website for more programming help.

1) If you are going to blend without an actual alpha controlling it then yes you have to do your own color keying, i.e. check for a background color in the overlay and don''t change the destination if it is the color key.

2) Your blend ratio is 50% if you >>1 to divide by two instead of multiplying by two with <<1. If you want to control the ratio you need a number to control it with, i.e. an alpha map. Assuming 256 shades then (((original * alpha) / 255) + ((original * (255 - alpha)) / 255)) >> 1. I would just use >>8 to do the divide figuring the differance wouldn''t be noticable.

3) This doesn''t give much information to go on. What frame rate do you get without doing the alpha blend? Without the code it is difficult to say what you could do to further optimize it, but using a pointer and incrementing it rather than an expression in an array subscript would be one. For the length of a line x * (y + lPitch << 1) is most likely a fixed increment from the previous pass through the loop. I don''t really understand that formula though, i.e. why it isn''t x + (y * lPitch). x should be your column and y should be your row, not the other way around and the lPitch should be the length of a line in bytes. Assuming it somehow produces the right number it should be a fixed increment each time through the loop.

Hehe, oops

With 1 you would mark the background as 100% transparent in the alpha map. In 2 you would use original and new rather than original and original. Assuming new is the source then the first original would be new, i.e. zero equals no change to the destination.

I can see why you would be confused with some of my code. Being the all-knowing (I can see your eyes rolling ) programmer that I am, I switched the bitshift operators. Maybe I am too used to cout and cin Pay no attention to the nerd in fron of the computer...

The reason for (attempting) diving the lPitch by 2 (aka lPitch >> 1; <- I fixed it!), that is because I have a 16 bit surface, and some odd thing or another makes me do that. Thanks for the help, and I will look into using a pointer. I should add that I get 45-50fps without the alpha blending (on a PIII 700 with a TNT2). If I change my framerate lockdown from 60 (which produces 50fps, go figure) to 100, or even 1000, I can get up to about 80fps (no alpha).

What do you mean by alpha control? Do you mean an opacity (sp?) percentage. And what is the dwAlphaBlendBitDepth or whatever in the DDBLTFX structure?

--------------------


You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming

You are unique. Just like everybody else.

Yanroy@usa.com

Visit the ROAD Programming Website for more programming help.