Wow, it looks like things are really coming along for you!

Just know that alpha blitting is really slow in DirectDraw and there is no hardware support of ralpha blitting... so you will want to do this as little as possible if performance is a priority.

In code, you really only need R,G, or B of that alpha image to obtain the correct level of alpha for the real image, so it might be easiest to just have the alpha image look like a grayscale image, even though you really only need about one third of the color values the grayscale image will give you. In other words, I would use the B value of the alpha image as the A value to apply to the real image versus the background.

Example: say you want your image to be a solid circle with edges that become more translucent as you get farther from the center until the circle is inivisble at the outermost edges.

The alpha image for that circle, depending on how you code your custom mask blitting function, can look solid black in the center with the edges getting lighter and lighter until the outermost edges are pure white.... or you can go for a solid white in the center with the edges getting darker and darker until the outermost edges are pure black.

I'm not quite sure how artists create these alpha images, but there might be some tool in photoshop or something that allows artists to save out the alpha channel as a grayscale image. I wish I knew how they did this.

Originally posted by Kain
I'm not quite sure how artists create these alpha images, but there might be some tool in photoshop or something that allows artists to save out the alpha channel as a grayscale image. I wish I knew how they did this.

There is and it's piss easy to do. Just hold down Ctrl while you click on the layer that contains the image with the alpha blend. Under the "Windows" menu you should find an option to make the Channels window visible. In the Channels window you will find a buttons at the bottom. If you hover over each of them you will find one that says use selection or something like that, clicking on that will create your black and white alfa channel for you. Make the rest of the channels invisible and then save the channel as a gif or whatever format you are using.

There are many ways to accomplish this sort of thing but it's been so long since I have used Photoshop for anything complex so I forget. Also this sort of thing also exists in other imaging packages, so you don't need Photoshop. If your looking for a free alternative you should check out The Gimp, which btw has a Windows port.

Ahh too perfect:
gamedev.net/community/forums/t…pic_id=110813&forum_id=18

That is perfect! Thanks, Gerry.

If performance becomes an issue for you, then you should keep your original Sprite Copy around just in case. It is nice and fast. CopyAlpha has no hardware acceleration, and so it will be a slow and expensive process... best suited for sprites that do not have to be rendered every frame, like static sprites that blend with the background.

But for your sprites that move around a lot or sprites that stand still and have other sprites moving around under them, you'll want to just do the fastblt.

This really only applies to you if you care about the people that don't have the latest and greatest machines.

Go ahead and try the CopyAlpha method on all sprites if you don't care about lower end machines, but keep your original method around as you may end up needing to use that, still.

That code looks really familiar! You've got the hang of it. That is exactly what I did when I was faced with the same problem. If I could write that code again, though... I would have done things differently.

I would have made two separate sprite classes, one class would do the alpha mask thing and the other class would do the fastblt thing.

That way, you don't need to have that extra if-else evaluation on 'm_pAlphaSurface' every time the sprite's virtual draw function gets called... also, memory usage would be slightly more efficient because the regular sprite class would not have a wasted m_pAlphaSurface member taking up 32 bits of memory per instantiated sprite.

But you could go on forever coming up with ways to just make your code better and better to the point where you never get anything done, so you should probably ignore this post. I am beginning to babble.

Tic Tac Toe Extreme!!!!!!!!!!

Matthew Lamari (ex-Retro Studios and the person who instilled the seeds of thought for smart pointers and beyond, even though I was kicking and screaming at first) once told me that a class heirarchy should be broad and flat as opposed to thin and long.

He was very much in favor of not wasting member variables in a base class that do not get used in all of the derived classes.

INITIATE BABBLING SEQUENCE 01093728428...

This made me question him about what to do when you end up having duplicate code all over the place as a result since a lot of Sprites draw the same way and if the sprites are not sharing a common base class, then how can I avoid copying and pasting draw duplicate draw code in different places? It was there that he pointed out the bridge pattern. Lamari was also the person who introduced "Design Patterns" to me. My head almost asploded; I was still very much a raw pointer, do what works kind of coder at the time. The bridge pattern is when you encapsulate an action into an object instead of making that action a function of the class that performs the action.

For example, your sprites have a Draw function, but some use CopyAlpha, some might render a 3D model onto a 2D surface, and some just do good ole simple fastblt. I think this might be a bad example because if you only have one of each type of Sprite class (3 total), then you're good as it is. But let's just say that you're crazy and you've got 10 Sprite classes that use fastblt and 20 that use CopyAlpha and 30 that use 3DRender. And your class heirarchy is flat so that you have 10+20+30 = 60 total sprite classes that inherit from a common base class (ISprite).

In this class, you create a new class called IDrawer. IDrawer will have three classes deriving from it. BltDrawer, AlphaDrawer, and 3DDrawer. Each drawer has a unique draw function (it doesn't have to be virtual, and it can even be a static function) that takes the right number of parameters and knows how to do its thing. Your 10 fastblt sprite classes will use BltDrawer:: Draw to do its thing; your 20 CopyAlpha sprite classes will use AlphaDrawer:: Draw to do its thing, and your 30 3D sprite classes will use 3DDrawer:: Draw to render.

Looking back, I guess you don't even need a base IDrawer class in this case as I don't see a need for members in your Drawers.

This is the bridge pattern, and it is really hard to wrap my head around this. You basically use this design pattern when you find yourself copying and pasting duplicate code in various places.

... END BABBLING SEQUENCE 01093728428

Duplicate code? Why not just wrap them into a function that happens to be outside of a class? You could use friend functions and be done with it, from the sound of it. I don't see why everything needs to be inside a class (unless you are writing in Java). Perhaps I am wrong (or just Linux-ized)

Yep, that would be fine, too. I didn't mean to sound so class happy. Having classless functions is just fine.

I, too, was taught to use the "friends" keyword sparingly.



friends do violate encapsulation... or more specifically, they violate the reasons for there being a private/protected keyword in the first place. I try not to use them for that reason just like I try not to use gotos.

But sometimes I do end up using "friend" because I don't have time to do things the right way at that time.

Note that I do not ever claim to be an expert on what the right thing to do is. Whether you use the friends keyword or not, due to principle, borders on the religious... as do most coding standards that fall beyond the realm of syntax. I just like to talk about these things in the hopes of checking my sanity with other programmers and maybe even being corrected. Sorry for morphing this thread so much, but I like this thread

Friends ARE a concern, yes, but that doesn't mean you shouldn't use them. Just use them properly. If you are talking about a group of classes that all share a common function, then you aren't really violating encapsulation, the friend class is merely a part of the package, if you look at it that way.

Oh, and screw encapsulation