Archived

This topic is now archived and is closed to further replies.

Sprite color-rehashing in DX? Is it possible?

This topic is 5972 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I know Blizzard has done it in StarCraft and Diablo 2.. Is it possible for me to do? I don''t know what they did, friends have suggested things like editing a memory-loaded image, or altering RGB values of the root image file before loading them, so far I have no clue. I would prefer something that allowed me to load, say, 16-bit images, using a fixed-value palette, then switching out those specific colors in the image, tho then loading them to a 32-bit surface, giving me full range of colors. Y''know what I mean? Then from there I could select the exact colors, making modifying the numbers for lighting, effects, things like that. I''m no heavy-duty programmer, (Meaning you can''t spout code and expect me to do anything but nod my head,) so far I''ve only taken an intro to Java class, but I''m planning on taking a course on VB6. That''s what I''ll be using, preferably, with the DX7 VB API. But I''d like to know, sooner rather than later, if this kind of thing is possible. In all honesty, I''d rather just grab a programmer, but I can never find anyone cooperative. I''m preferably an artist, I''ve done my own programming just to get my stuff actually running. I''ve even used the pre-existing stuff in VB5 to make and animate to a set of surfaces, by manually switching the positions of two image objects, and drawing to the one currently behind, using the ImageList object''s .Draw function. I could probably get by with merely that (it works prety fast. I don''t count framerates, but it looks good enough for me.), except I can''t do the color-changing.

Share this post


Link to post
Share on other sites
I''ve never played either of those games, but I know what effect you mean. The way I''d do it is convert the image to HSB (hue, saturation and brightness values (don''t remember the formula to convert from RGB, but you can probably find it if you do a search on this board)), then change those values, convert it back to RGB and use it.
Or an even easier way is just make all images that need to be changed in 256 color, modify the palette, and convert to 16-bit when copying to a surface. 256 colors per image (global palettes are bad though) is plenty to look good in a 2D game.



-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

Share this post


Link to post
Share on other sites
Yeah! That second method is what I meant, is that 8-bit or 16-bit? I thought 16.. Either way, that''s what I meant. I want to be able to edit the slotted colors'' RGB values.

Yeah, the global palette is bad. Which is why I said I wanted to be able to draw to a 32-bit surface. I like full color.

Share this post


Link to post
Share on other sites
Well, the image will be stored in 8-bit in a file, and then converted to 16-bit while loading to be used in the actual game. Just load it as 8-bit, make whatever changes to the palette you want, make a blank 16/24/32-bit surface, and go through each pixel of the 8-bit one setting each pixel of the 16-bit to the value of the 8-bit''s color index, as in:
  
for(int j = 0; j < h; j++)
{
for(int i = 0; i < w; i++)
{
image16.pixel[i][j] = palette[image8.pixel[i][j]];
}
}


You won''t be able to modify it in the middle of the game though, only while loading. Unless you want to just store surfaces as 8-bit and blit them (similar to that code snippet) to a 16-bit backbuffer, which would save on memory, but be slightly slower (one more memory reference per pixel, to get the value from the palette). Plus then you can modify an image''s palette to get instant color changes. Of course, then you''d have to write your blitting routines yourself, but IMO, that can be kinda fun^^



-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

Share this post


Link to post
Share on other sites
Actually, if you were to use DekuTree64''s (play much N64, Deku ?) method of blitting 8 bit surfaces to a 16 bit back buffer, you may gain speed in some cases. Say you were going to do some sort of special effect that required you to get and set pixels of the 8 bit surfaces, that would be a good deal faster than doing it on a 16 bit surface. Just thought I''d add that.

Share this post


Link to post
Share on other sites