I know this question should be on such forums as gamedev rather than here, but I've come to trust the info provided here so I'll ask it anyway.
A while back there was a discussion about alpha blending in DX7 and previous versions in 2D. I have implimented this function using info provided in that discussion. And for the past month I had thought it was working fine, only to find out that it works great on some computers and awful on others. On other computers it looks like it is rendering lines of my sprite all over the place.

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

kinda like this.

The actual routine breaks apart each 16 bit pixel into its rgb values and then mixes that with the destination rgb values and puts them back together in place of the destination pixel. It works beautifully on my machine and a few others. Anyone run into this problem?? or know what could be causing it?
If this is too far off topic, just let me know.
Thanks,
Bruno

have you checked if the video card supports 555 or 565 formats?

apart from that, maybe it would be a good idea to post the code used?

Something more descriptive than "lines of my sprite all over the place" would be great :)

Anyway, I have the Blind Fighting skill (or is it a feat now?), so here it goes. If you're RLE encoding alpha values, you might have a bug in the decoder. This should fail in any machine, anyway.

Other thing I can think of is about the images pitch. If you're using DD surfaces as images, remember that the pitch may or may not be the same as the width, depending on the video card. This can mix up indexes real bad.

This may or may not have anything to do with your problem, but it's all I can say with the given info. Feel free to email me if you want to.

read image pitch and use this value instead width.
image pitch often differs from width.

Hmmm, I am checking 555 or 565 color encoding and I encode the color pixel accordingly... I am not using RLE method
But this 'image pitch' idea sounds like it may be the case. I hadn't even realized this existed and I definitely wouldn't have known that it changes according to video card. I am using the image width right now, so you guys are probably right. If changing over to image pitch doesn't work, I will post the code (I'm at work now and don't have access to my code)

Thanks,
Bruno

Just for the sake of completeness : the pitch of an image is the width of the "allocated" image, which can be different to the actual width. For example, your driver can choose to allocate a 128 pixel wide image if you requested a 117 pixel wide image, to improve performance when accessing the surface, or to comply with memory alignment restrictions placed by the video hardware, or for whatever reason.

I haven't used DirectDraw for 3 or 4 years, so this can be inaccurate or not an issue anymore.

Hi, I've just been experimenting, trying to correct my alpha blending problems by using the image pitch instead of the image width. The problem is definitely in this area, but I'm having trouble figuring out how to access the image pitch value directly. Does anyone know in what struct its stored and what its called? Thanks,
Bruno

The Pitch member of D3DLOCKED_RECT, which you get from surface->LockRect().

aah, I finally figured it out. I used the ddsd.lPitch and ddsd.dwWidth, but this only solved the problems i was having with the source surface. Then I found the lPitch for the back surface and this was the one causing problems. for 640x480 resolution in 16 bit you would expect the lpitch to be 1280 (2 bytes X 640 pixels), but on some video cards I was getting numbers like 1536 for the pitch. :confused: So I used the actual pitch and everything worked great on the couple of systems that were causing problems. Thanks

Ggambett - thanks for explaining everything in a detailed manor... it helped me figure things out alot quicker.

Originally posted by BrewKnowC
but on some video cards I was getting numbers like 1536 for the pitch. This is just a guess on my part, but 1536 is 3x512. Notice that 512 is one of of those powers of two. Perhaps having the memory aligned this way improves caching performince in some way.