Heyas,
Never posted here, but always enjoy browsing the site. I usually find my answers via search, so haven't had a need to post. And I'm not even sure if this is the right place to ask this, but I'm sure you all will have ideas

I'm currently working on reversing a texture file format for a game. The file format seems pretty easy to parse and supports both 32bit and Indexed images. The 32bit images are read in bottom-to-top like a DIB and render perfectly in my utility. The Indexed images have a color table, followed by 1byte per pixel that represents an offset in the color table. The problem though, is that the scan for indexed images doesn't seem sequential and the rendering is all jumbled. The color lookups seem to be correct though (by ratio of colors in the output). I've noticed a few patterns in the final rendering, but none that will clue me in on the scan order. Any clues on why the pixels wouldn't be represented in a linear fashion or has anyone exprienced something like this w/ another graphics files format? Below are my notes on the format (.img) and links to 2 jpg's that show the correct texture and my parsed texture - right and wrong (the correct one was taken from an older version of the game, when they used .png's). I've yet to figure out any use for the 4 unknown DWORD's listed below. Both 32 bit and Indexed images usually have a value < 0x0F in them.

right: hxxp://linux.wku.edu/~sporadic/gfx/right.jpg
wrong: hxxp://linux.wku.edu/~sporadic/gfx/wrong.jpg




i'm looking for help on this, as it's kinda kicking my arse atm
thanks!,
-sporadic

And you are sure it's not compressed in any way? If you do a statistical analysis of the raw data, does it have more random characteristics than non-compressed images? In that case it might very well be compressed, which might explain your failed attempts to reverse it "by hand".

Just a suggestion, but how about debugging the game to see how what it does (i.e. how it processes and stores) the image on loading it? Or, how about replacing some image files in the game directory with ones you create yourself, this will give you clue if it is some weird non-linear scan. e.g. what you think is a simple image with a horizontal line gets mapped to...? personally, i think delta is on the right track and that the data is compressed somehow.

JH

p.s. and another thing - you mention an older version of the game using pngs, are there are graphics (logos etc) that are the same as in the new version? if so, you should be able to compare these to determine the scan.

I would think that using compression on the image would somehow alter the color table, unless the before and after color similarities are coincidental.

Have you checked the other data files for anything that may be of any help (there may be encode/decode information in other files, such as byte order or build pattern).

If you think that it is just the pixel order that is incorrect, try coding a small app to count the number of each pixel of each color in the image. If they're equal then its likely not that huge of a problem to correct, else everything takes a turn for the worse

Compression normally involves the reduction of data size (or at least an alteration in data size), and from what you've posted, the image looks to have dimensions in-tact. And the fact that the data stretches to the extremities of the image show pretty conclusively that the algorithm (if any) hasn't padded the data to keep size.

I cant really help without seeing the raw data, but i'm not sure if posting that is permitted (no posting of target file). This is an image rather than a reversing problem though, so i don't see why it would be disallowed.

You can post data from sample images here, no problem.