Archived

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

Pallette question

This topic is 5016 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

Hi all, I want to know how to change an image color into another automatically (is this have something to do with ''pallette''?). You know, like having a sprite image, but you can change the color of the sprite, just like in the 2D fighting games. If anybody understands how pallette works, please let me know. And if there is an efficient way to implement this using MIDP 2, please kindly let me know. Thanks very much.

Share this post


Link to post
Share on other sites
In MIDP 2.0 you don''t have to play around with palletes. You can accomplish it with brute force by using Image.getRGB() to get an array of the pixels, then loop through the array and change the colors as you wish, then you can either create an Image with the pixel array with Image.createRGBImage(), or just use Graphics.drawRGB() to draw the array directly.
In MIDP 1.0 you can''t do this without using extension APIs (like Nokia''s DirectGraphics class). But you could read the image as a byte array with Class.getResourceAsStream() (instead of creating it with Image.createImage()), and then mess around with the pallette as you said. You''ll need to know how the png format works to do that, and you can get that info from www.wotsit.org.

shmoove

Share this post


Link to post
Share on other sites
You can do this in MIDP1.0. There are two ways, both of which I''ve used in games, neither are real time though - they''re more suited to the loading phase only.

The first method is to load the raw image data into a byte array, the image is assumed to be a paletted PNG file. I add a word to the start of the file to store the file size as there''s no way to detemine the size. Then, I replace the palette chunk with the required palette. Finally, the byte array is passed to createImage.

The second method was developed for the Series 40 where there''s a memory leak in the image class whereby the application will run out of memory if images are created/destroyed a lot. This method creates an image in the normal way:

createImage (width, height);

Then, a file is loaded that contains the palette indices for each pixel, a byte array. The image is then created by using:

setColor (colour);
fillRect (x, y, 1, 1);

for each pixel. Not the fastest of methods.

Skizz

P.S. It was a football game and I needed to change the player''s colours each game.

Share this post


Link to post
Share on other sites
@Skizz
S40 devices don''t have any memory leaks with createImage(). What you are talking about is caused by memory fragmentation, since the garbage collector is not a compacting one. If there is enough space then you can solve this by simply loading all the images (or at least all the big images) you need at the beginning and keeping them in memory. But this has nothing to do with the pallete issue in question.
About your method for creating the images though, I wonder why you didn''t use DirectGraphics to do the pixel manipulations.

shmoove

Share this post


Link to post
Share on other sites
I didn''t use DirectGraphics because it needed to run on non-Nokia phones as well. I didn''t think the slower speed of using fillRect justified using the Nokia specific API (although in the end it was for a Nokia phone). I like to keep away from platform specific code unless I really have to use them. That way, I can port applications to new handsets quicker.

Skizz

P.S. Memory leak / fragmentation, either way, I ended up running out of memory, and therefore needed a way to recolour images without destroying them.

Share this post


Link to post
Share on other sites