I have extracted the contents of a iOS game, and it gave me a lot of .obm files. I opened them with TiledGGD and all sprites are there, but it can't load the proper palettes. Can someone help me here?

I'm trying to rip from Double Dragon, by the way.

Upload some and we'll check 'em out

It's always possible the palette is in a different file, too. So taking a look might not wield full results but it'll be a good start!

I doubt, since they only files that come come out are the obm, plus some unreadable pngs and wavs.

The game isn't big, so it's easier to just download it than for me to upload the files, since the iOS games can be opened with WinRAR.

At first glance it looks like the first 4 bytes are a magic/stamp/identifier. There are two little-endian shorts after that, probably width and height. After that is the pixel data I guess, in linear 8bpp.

EDIT: At the end of the pixel data there are an extra 512 bytes, which I would suspect are 2-byte palette values (which makes 256 colours). However if I try using this in Tile Molester as BGR555 it doesn't look very right, so I'm not sure. I mean, I could say that it might be BGR565 or some other variation but that shouldn't matter much, the main issue is that there's just too much black.

EDIT2: Aha, I got it. Instead of those 512 bytes at the end being the palette data, it was actually the first 512 bytes after the dimensions; then comes the pixel data until the end of the file.

   
AREA1_CHIP.obm

   
avg_billy.obm

This is what Tile Molester gives with 8bpp linear, 2-dimensional, and a 15bpp BGR (555) palette at an offset of 8 with length of 256 (Intel order). Go to 0x208 since that's where the pixel data starts.

Taking a close look at the palette data, it appears to use all 16 bits so it's probably BGR565 instead of 555. That's probably what's causing the corruption (it can make a big difference). Possibly RGB instead of BGR too, since I'm not sure whether Billy should look that blue.

I can maybe make something for this, although I'm a bit busy at current. I'll make it once I have the time, but if someone else wants to do it first then feel free.

Messed with it a bit, apparently you just have to reverse the alpha location to the end in the alpha settings:

Ah, awesome! That confused me for a bit but looks like it's RGB555 with the last (least significant) bit being the alpha value. The only colour which has this at 0 should usually be the first one (although if this system exists then maybe not always).

Strangely though, TiledGGD says it's read as big-endian RGB. However when looking at the palette myself, I had to read it as little-endian to get the proper values. I looked at the TiledGGD source code and it actually seems to be reading palettes backwards, i.e. big-endian as little-endian and vice versa:



The wiki (on Google Code) also states:

Quote:99 out of 100 (if not more) of the games have their data stored BigEndian; which means that the bytes that provide the most information are stored at the end of a set of bytes.

Weird. He might just be confused? But whatever, looks like you got it sorted so well done

Would this work with the Final Fantasy releases on iOS?

No, it uses a different format...

Foiled again.

Hey, umm....

I know it's kinda weird to bump here of all places, but I believe this is very relevant for this thread.

So, the .obm1 files from the Zeebo version of Double Dragon basically uses the nearly identical TiledGGD setup to the regular .obm files from the iOS version of the game.
You can extract the .obm1 files from the .ggz Zeebo files via a quickbms script you can find online (through google and the wayback machine).

Here's my setup for the smaller sprites, as an example (bigger sprites use the exact setup as iOS):


I hope this helps anyone looking to rip sprites from this very specific and obscure version... I guess.