After rechecking the masks for correct RGB values (transparent and mask), and verifying they are correct, I still am having a problem at the right edge of the mask used in MAKE_MOVING for the horizon marker:http://forums.avsim.net/user_files/152215.jpgI'm using these image flags in the sprites and moving elements: IMAGE_USE_TRANSPARENCY | IMAGE_USE_ERASE | IMAGE_BILINEAR_COLOR,and these in the STATIC IMAGE_USE_TRANSPARENCY | IMAGE_USE_LUMINOUS,actually, I need to add the luminous to the others now that I think about it.Any ideas? I am assuming the bilinear flag just allows bilinear resampling if the bitmap is reduced.Patrick

It's just a thought but double check not only that the mask and the image are the same size but that their axis and positions line up pixel for pixel as well.If I had to guess, I'd think that error in the above image was the result of the mask being 1 px to the left of the image... it could be in 1 left in position or 1 right in axis, either would do it.Scott / Vorlin...Who is still alive, buried in a learning curve and we should be releasing a project this weekend (we freaking hope *finally*! LOL).Bill, still no joy on TS... I keep trying! ;)

I seem to have this problem with all gauges I compile with MSVC++ .NET 2003 (and I have to assume that .NET 2005 has the same problem).For some reason, the 'rightmost column' of pixels sometimes becomes non-transparent. Extracting the bitmap directly from the gauge and loading into Photoshop will show those pixels as 1,1,1 or 2,2,2... Until a better solution is discovered (so the problem never occurs!), I add two pixels to the width of the affected bitmaps, compile, use FS Panel Studio to extract, send to Photoshop, trim the two pixel width from the right edge, and re-insert via FS Panel Studio.I know that the bitmaps are "clean" in the gauge's res folder, but "dirty" after compiling. Obviously, something in MSVC++ .NET 2003 is causing the problem, but I have no idea what it might be...

Interesting.While the mask and sprite are the same width, they are and 'even' width which means the exact center is at 0.5 of a pixel. I think this may be the issue, as I have not experienced it on any of my other gauges, I believe that this may be the root cause that results in the behavior by the compiler as it converts the resource.I will change the bmp widths to an even one and see if this fixes it and report back later.Patrick

Wonderful news guys. :-beerchugI hereby contribute (finally) some useful knowledge to the collective wisdom here. :-bigangelUsing an even size bitmap & mask fixes the problem with the black added to the edge. So, henceforth all my bitmaps will be even.Patrick:-rotor

You said in one post that an even number may be a problem because it places the center on a .5 pixel line... then in the next say that an even number is the way to fix it.Obviously one's a typo, no big deal. I'm assuming that an odd number fixes the issue?On that note, there opens the door to odd number scalability issues. Might I suggest that if you need to use odd numbers, make sure that they're divisible by 3 for the best possible scaling.Scott / Vorlin

>You said in one post that an even number may be a problem>because it places the center on a .5 pixel line... then in the>next say that an even number is the way to fix it.My brain at 3am on too much caffine.>Obviously one's a typo, no big deal. I'm assuming that an odd>number fixes the issue?Sorry, you are correct. ODD = BAD. EVEN = GOOD.>On that note, there opens the door to odd number scalability>issues. Might I suggest that if you need to use odd numbers,>make sure that they're divisible by 3 for the best possible>scaling.Thanks for this, but since I can confirm it is odd numbers that caused the problem, we are ok.Patrick

After getting a similar problem with even sized textures, I did more research and have discovered that all I have to do is make the sprite/moving bmp smaller than the mask.Basically instead of flood filling it to the edge with RGB(0,0,0), just leaving a border that is transparent in photoshop. The texture doesn't even have to be resized which makes placement easy.This compiles and displays perfectly everytime.Patrick