Sign in to follow this  
Plethora

Changing colors at runtime in with SDL

Recommended Posts

So this is potentially a multi-part question so I'll cut right to the chase. Basically in my 2d sprite based turn based strategy game, I'm wondering about the best method to recolor specific portions of my unit sprites to reflect player color. I've thought of a couple of different methods but am unsure what the "typical" solution would be. 1) My sprites are not all that large, mainly 64x64 with a few 96x64 sprinkled in. Maybe its worth taking the memory hit and just having a prototype of each possible color stored in memory? 2) If 1 is not really the preferred method of doing such things, then I would assume the next most straightforward method would be to loop through the surface pixel by pixel, check the color with SDL_getRGB() or SDL_getRGBA() and draw a new pixel whenever I encountered the color that needs changing. This seems like it would be awfully draining if I was doing this for every unit on the screen, but perhaps I could just do it once and save the "new" surface to memory, this would improve upon the above method as it would only be saving the surfaces I genuinely need and would reduce the need to distribute files 8x as large as they need to be with my game. 3) I haven't really thought this through entirely, but I also thought that maybe I could include a "map" file of some sort which details exactly which pixels need to be changed in any given surface, thus eliminating the looping and checking. So... any thoughts? lol

Share this post


Link to post
Share on other sites
Options:

1 - move it to opengl (which is relatively easy with SDL) where you can use colors to change the shades of textures. you will wind up with grayscale versions of whatever you want to change the color of overlaid on the base image (almost impossible to describe this in words, hopefully you'll get what I mean)

2 - cache the recolored sprites on new surfaces. you may wish to limit the number of surfaces you use for this, so you may wish to use an STL queue, and bring up any surface used to the front whenever it is needed, and have them fall off the back and deallocated when not in use. advantage is that you don't need to precolor everything ever. disadvantage, you do get a minor hit on the first time an image is colored.

Share this post


Link to post
Share on other sites
Caching recolored sprites is the way to do it if you're not using hardware acceleration (e.g., OpenGL mode) but you have to consider how you're going to determine which pixels to recolor.

Internally I don't know how Blizzard did it with StarCraft but if you ever get a chance to look at their sprites you'll see that they use shades of Magenta for the areas that are to be recolored.

Basically, you'd want to determine which shades of which particular color to look for when you parse through the pixels of a Sprite. Say, for instance, that you're going to use Magenta. Simple, RGB value == 255, 0, 255. Simply look for that color in the sprite and then reset the color to some other RGB value in your new surface.

I'm not sure how clear all of that was (5:45am, no sleep) but hopefully this is helpful somehow.

Share this post


Link to post
Share on other sites
Hello there,

I suggest doing two things:
1) Making an alpha or 1-bit mask for the areas to be coloured then
2) Blitting in a solid color unto the Sprite-to-be-recoloured using that mask, at runtime.

That way, you only draw into areas intended on the sprite. You need solid colour swatches to blit from and you can prepare the bitmap for that in memory by FillRect(chosenColor) or similar functions.

Greetings.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this