Spritley Old Guy
in [Visual Basic]
|
Prev: Simple Obfuscation
Next: Flag test
From: Bee on 17 Mar 2010 19:47 Not from my experience. My sprites can work on any background, solid or not. I am not filling the mask image area, just leaving it the same as the sprite. "Mike Williams" wrote: > "Bee" <Bee(a)discussions.microsoft.com> wrote in message > news:A9FCF81A-88A9-4F96-97F2-F5EF41DF2208(a)microsoft.com... > > > As far as I have gone, it does not seem that the > > mask needs a "hole". The image can be on the > > mask too. Just the transparency areas need to > > be complement colors. > > That'll be because you are blitting your sprite onto an area of solid colour > that does not contrast too much (bitwise) with the main body colours of your > sprite. Try blitting it onto various other solid colours, or better still > onto a background picture, and you will clearly see the problem with that > method which at the moment just happens to be hiding from you. Stick with > the proper mask. > > Mike > > > . >
From: Larry Serflaten on 17 Mar 2010 22:49 "Bee" <Bee(a)discussions.microsoft.com> wrote > Not from my experience. > My sprites can work on any background, solid or not. > I am not filling the mask image area, just leaving it the same as the sprite. Can you post an example of your method? LFS
From: Mike Williams on 18 Mar 2010 09:59 "Bee" <Bee(a)discussions.microsoft.com> wrote in message news:78939086-A0A2-41E2-A1D9-C0B81E4C4B2C(a)microsoft.com... > Not from my experience. > My sprites can work on any background, solid or not. > I am not filling the mask image area, just leaving it the > same as the sprite. Actually I think you can do that with an image on a white background and the same image on a black background and if you blit the white one first using vbSrcAnd followed by the black one using vbSrcPaint. I've never actually given that one much thought, but if that's what you are doing then it will probably work. I'll have to get a notepad and paper and work out the logic of it later, when my head gets better from the effects of fighting the Micro$oft newsgroup filters for my recent posts in the endian routine thread ;-) If the method you are using is similar to the one I've just outlined then I think it should work okay for images / masks you are preparing by hand (although I'll reserve judgement on it until I've had time to think about out the logic of it some more), but if you're creating the mask from the image in code (after the user has selected an image to load for example) then although you could create one in such a way it might be eaiser to do it the standard "black on white" mask way. As I've said, I'll get my thinking cap on later when my head gets better ;-) Mike
From: Mike Williams on 18 Mar 2010 14:07 "Bee" <Bee(a)discussions.microsoft.com> wrote in message news:78939086-A0A2-41E2-A1D9-C0B81E4C4B2C(a)microsoft.com... > Not from my experience. My sprites can work on > any background, solid or not. I am not filling the > mask image area, just leaving it the same as the sprite. What a day! First I waste most of the morning farting around in microsoft.public.test.here posting more than twenty binary chops of my Endian Swap thread message in order to determine which perfectly innocuous and innocent word the stupid Micro$oft newsgroup filters have taken offence at today, then my wife chases me out for a haircut because she says I look scruffy (I mean, scruffy! I'm a programmer for God's sake, programmers are supposed to be scruffy, that's what they do!) and then as soon as I get back I have to dig around inside this old head of mine for some half remembered scraps of Boolean Algebra from about a quarter of a century ago in order to answer a post about Bee's bloody sprites! Sheesh! Anyway, after all that messing around it turns out that your "image on white" and "image on black" will work fine if you blit the white one using AND (vbSrcAnd) followed by the black one using OR (vbSrcPaint). Since you have said that you are interested in how and why these things work, here is a brief explanation: In this small explanation I'm calling each of the main background pixels B and each of the "sprite part" of the small images pixels A (simply because I always worked using A and B all those years ago!). We don't need to call the "white in one and black in the other" pixels anything at all, because we always know what they are and we can assign real values to them in our reasoning. When you blit the "sprite on white" image into the background using AND then for every bit of each pixel that is white in the "sprite on white" image you get the result (B AND 1) because white pixels have all bits set to 1. If you draw a simple truth table you will see that (B AND 1) is equal to B. Therefore, for every white pixel in the "sprite on white" image, the background pixel (B) remains unchanged. Also, for every bit of every "sprite" pixel in the "sprite on white" image (we've called those A) you get the result (B AND A). So, after the first blit (the "sprite on white" image using AND) the background where the sprite image was white remains unchanged, and the background where the sprite pixels were not white have been changed to (B AND A). On the second blit you are blitting a "sprite on black" image onto the same part of the background, directly over the top of the previous blit, but this time you are using OR. Therefore, in the areas of the sprite that you want to be transparent (which were left unchanged by the previous blit and which are still B) you will get the result (B OR 0), since all the black pixels in the "sprite on black" image have all bits set to 0. If you draw the simple truth table for (B OR 0) you will see that it is equal to B. In other words, the background pixel in the areas you want transparent have not been changed at all by this second blit either (which is of course what you want). As far as the actual sprite pixels of the "sprite on black" image are concerned they are the same as those pixels in the "sprite on white" image, in other words they are A as well. The background pixels they are being OR'd with were changed to (B AND A) by the first blit, and so they will now be changed to (B AND A) OR A. If you draw the simple truth table for (B AND A) and if you call the result X (for example) and if below it you draw the truth table for X AND A and look at the result you will see that (B AND A) OR A is actually very simply equal to A. So, that means all background pixels under the "sprite portion" of the two images will be A. In other words the background at those pixel positions will have been changed to display the actual sprite. All other background pixels that were under the "white in the first image and black in the second image" will, as we have already described, be left unchanged. All of the above of course is exactly what you want in order to draw a sprite transparently. Therefore, your own method of drawing your sprite using "sprite on white" and "sprite on black" images will work, using AND for the blit of the "sprite on white" followed by OR for the blit of the "sprite on black". It doesn't really help you a great deal when loading a sprite with a specific "these pixels need to be transparent" colour and where you need to create the mask in code, at least it gives you no advantage over the more standard method, but I can see that it might actually be easier for you to use when you are drawing both the sprite and mask images by hand or in a drawing program, as you appear to be doing. Hurray! We've got all that sorted at last! And of course I've sorted out the daft Micro$oft newsgroup filter by changing one word in my quite large Endian Swap thread message, and I've had my haircut as well! A nice, eventful day ;-) By the way, when you are moving further into this stuff the drawing of small "truth tables" can be a very handy tool, and it doesn't require any real Boolean algebra for most tasks, so if you don't know what I am talking about when I say "truth tables" (something which you may or may not already know about) then post again. These kind of truth tables are extremely simple to draw and to analyse, and they are worth getting to know. Mike
From: Bee on 21 Mar 2010 20:17
Thanks Larry. Still fiddling. Ultimately I want to try to get the sprite alpha to work so I can get ghostly images. "Larry Serflaten" wrote: > > "Bee" <Bee(a)discussions.microsoft.com> wrote > > Well, except when I google I see where it talks about using other colors. > > So are they doing something different? > > See Mike's response for TransparentBlt which could be what you've seen > > > Terminology limited here so it is all still a little confusing. > > I have my code set up to do black and white but was considering alternatives. > > What I have works for the case where black and white are NOT in the original > > sprite. Some images already have those as areas of non-transparency. > > Your first post mentioned using SRCAND and SRCPAINT so that is the method > I posted. It works for any / all available colors in the 'positive' image. If you > noticed, the red symbol had a black outline. If you want to see it also using white, > make the change below to the earlier posted example: > > > > ' Positive > > > Line (0, 0)-(50, 50), 0, BF > > > DrawWidth = 7 > > > Circle (25, 25), 18, vbRed > > > Line (15, 36)-Step(20, -20), vbRed ' < < Change to vbWhite > > > DrawWidth = 1 > > You'd then have a red circle with a white diagonal line, all outlined with black. > As I said, any available color in the 'positive' will work, as long as that area is > black in the mask image. > > If you want to understand how it works, it may help to think of the bit values > of the colors you are using. The mask is black (no bits on) on white (all bits on). > Whenever you AND the mask to whatever colors, the black area ANDed with any > color results in black, where the white area ANDed with any color results in the > original color. > > After copying the mask to the destination you get a black image on the destination > matching the opaque area of the positive image. You can then OR the positive image > where anything ORed with black results in the original color. Comment out those > PaintPicture lines (one at a time), to see what they do.... > > HTH > LFS > > > > > > > . > |