iPhone sprite ripping

[puggsoy]

Thanks, although I would advise you to take that down (or at least remove the link from your post), as it is in a sense piracy to upload it. Downloading it to rip sprites from is another matter, but uploading a game that would originally be bought, without permission from the creators, is (to my knowledge) illegal. It might have been better to ask that you send it in a PM, actually.

I have it now though, thank you. I'll see what I can do.

[jirachiband]

Links removed. If anyone needs the link, just say the word and ill pm it over.

[puggsoy]

Here's what I've found so far; BAR doesn't seem to be a consistent format. It's simply an extension used for most of the resources. For example, looking at res_character.bar and strings.bar (in a hex editor), you can see that they're pretty different and their first few bytes have no resemblance to each other.

On the other hand, however, some files do look similar. res_character.bar and res_worldmap.bar both share "DF 05 31 25 01" as the first 5 bytes, suggesting that they have some sort of header. res_manparts.bar has the same first 3 bytes, so may also be similar in structure.

However, it appears so far that only files with "sprites" in the name contain any, uh, sprites. Looking in Texture Finder reveals some things like this:



I imagine that files like res_manparts.bar and res_womanparts.bar contain information on how to use these sprites.

It's not all that wonderful though, some things are shoved around to the other side:



And others are just plain screwed up:



So yeah, we're getting somewhere, but not quite there yet. If I could figure out the format of these files I could probably get the images out nicely but that'll take some work.

I'm kinda busy so I'm gonna have to leave this for a wee while but yeah, hopefully that's somewhat helpful.

[jirachiband]

Wow, good job! Too bad this wasn't in like png format or id just get this myself. Sorry if this turned out to be more of a request :-/

[puggsoy]

No worries, I don't mind. I like figuring this sort of stuff out, it's kinda fun

Anyway, I have some progress. By fiddling around with widths and shifts in Texture Finder, I managed to piece these two together:





I found these in res_splash.bar (the only exception I know of the "must have 'sprites' in name to contain images" rule), so I assume they're splash screens for the game. I have no idea why there are two and why they have such different art styles, but that hardly matters anyway.

Anyway, these were all in chunks, and I had to fiddle around with Texture Finder to get each chunk looking right, then put them together by hand in GIMP. I won't explain the details, but in short it took some work that would ideally be automated. I'm still not sure how the format works, but I found some patterns while getting these and have some values I can look for, so that should help in figuring it out.

EDIT: Wow, this is really exciting. I'm getting some nice results, found dimensions and coordinates in what I suspect to be image headers. It's making my head hurt a bit (I have to keep switching between hex and decimal, even with a converter it gets confusing), but it looks promising.

[jirachiband]

Wow. Just...wow. They really didn't want people to get in I guess huh? But everything looks great so far!

[puggsoy]

Either that, or this is just a convenient or otherwise advantageous way of storing them. I do admit I don't see a reason not to use PNG though

This might not mean much to you, but I'll just put this here anyway. If not for anyone else, then for myself. Numbers preceded by "0x" are in hexadecimal and all values are little-endian unless stated otherwise.

---

Here's what I've figured out so far, from res_splash.bar. The image header contains info on how the images should be arranged, there are two in this particular file. These both start with 0xDF0539250100, as read in big-endian (0x0001253905DF in little-endian). After that comes a 16-bit unsigned integer, which designates the length of the following array (let's call it "arrayLength").

Now comes an array of "chunks", each chunk containing the coordinates and dimensions of a part of the image. The structure of each chunk goes like this:

1 byte - always 0x00, haven't seen anything else. Looks like some sort of separator.
16-bit unsigned integer - X coordinate
16-bit unsigned integer - Y coordinate
16-bit unsigned integer - width in pixels
16-bit unsigned integer - height in pixels

So there are [arrayLength] of these chunks. The X and Y coordinates are relative to the top-left of the image part.

After that come a bunch of bytes, whose meaning I have yet to discover. I don't know how to figure out the length either, however I can tell where it ends by finding the first part of the pixel data. In this file I can find that easily since the first colour in the pixel data should match the colour of the top-left pixel in the images I pieced together in my last post.

This pixel data is stored in 32-bit big-endian ARGB format (so that'd be BGRA when reading in little-endian). These are just like most image formats, you simply draw the pixels from left to right, row by row. You do this for each chunk, in the order the chunks are.
Again I'm not sure yet how to find out the length. I could probably multiply the dimensions for all the chunks, add them together, and multiply by 4, but there's probably a better way.

---

So yeah, that's what I've got so far. Theoretically it's already enough to get the images, but it really would be much better if I could figure out those bytes between the chunk array and pixel data. The first 5 bytes also look different in other files (e.g. res_chinatown_sprites.bar has 0xDF0531250100 instead of 0xDF0539250100) so that might have some significance as well.

I'm really glad how well this is going though!

[jirachiband]

Can't wait to see them! This should be amazing

[puggsoy]

New discovery! Apparently the pixel data itself is also organised in chunks. Each chunk is preceded by a 32-bit unsigned integer stating the chunk's length.
Not only is this useful for reading in the pixel data, but it also explains why I had to increase the shift by 4 bytes for each chunk when I was ripping them with Texture Finder.

(By the way, when I say "unsigned integer", usually I actually have no idea whether it's signed or not. I haven't seen the highest bit set yet, so reading them as signed or unsigned shouldn't matter, but I don't see a use for negative numbers here so I'm just assuming it's unsigned.)

EDIT: Also fixed some errors that I just noticed in my last post.

[jirachiband]

So how's it going? Can't wait to see these sprites, they're very cute

[puggsoy]

I have successfully written code that generates the splash screens as PNGs from the BAR files. Works very well and is a good bit quicker than by hand

The only issue is that while I can see the data for the image dimensions in the file, I don't know how to derive it's position automatically. The only reason I could get the splash screens is because I know their dimensions already and can just type them in.

So yeah, now I'm just trying to figure out how to get the dimensions. Once I know that though, I'm pretty sure it should work with any BAR file.

EDIT: BARExtractor0.1
There ya go. I didn't figure out how to get the dimensions data, but I figured out an alternative way of deriving the width and height using the chunk data. I'm pretty proud of myself to be honest

This will, hopefully, extract the images from res_splash.bar, and any file with the word "sprites" in its name. I would like to stress the point that any other BAR files will most likely fail to extract anything, that includes res_sprite_pic.bar. I've tried this one in specific and while it does indeed have sprites, they're in a different format. Unfortunately this one seems to contain character parts, which are put together with other files. Since you'll probably want these as well, I will try and see what I can do.

But for now, this should be able to extract most of the backgrounds and environments. Due to things like layering and collisions, stuff won't necessarily be all nice and dandy right away (bits and pieces might be separate, like the bench in res_centralpark.bar), but it's perfect for ripping and submitting here. It should be fairly easy to put it together yourself though.
(By the way, if you don't intend on submitting these here yourself please say, then I might be able to.)

In any case, enjoy! Usage instructions can be found in the readme. Be sure to tell me if you encounter any bugs or something doesn't work right.

[jirachiband]

Ohmagoodness, it's reached fruition. The time is nigh, thanks so much! Will likely post here, probably will at least do the character sprites! Thankies!

[jirachiband]

Everything seems to be in working order
Unfortunately you were right about getting the character sprites out, those definitely don't work. If it helps, it says "EOF" in the error message. Ive tried several bar files that use sprites (But not all) and the only one that seems not to work is "res_global_sprites.BAR" Otherwise ive tried it on other maps, and its worked
So whats the plan for the character sprites? I suppose I shouldn't ask since itll sound like gibberish to me, lol. :-/

EDIT: Also, I notived that the "res_cabride_sprites.BAR" didn't work either, it gave me the EOF error as well.

[puggsoy]

Yeah, that EOF error is the only one you should be getting. It is due to the file being in a different format, but the technical cause (trying to read past the last byte) shouldn't be happening. I did something that's supposed to make it fail more elegantly, but for some reason that isn't working. In any case, thanks for telling me.

I've been looking into res_sprite_pic.bar. Could still take a while to figure out, but the good news is that it does look somewhat similar. I'm pretty sure I'm on my way figuring out headers, and pixel data looks pretty straightforward. I think the biggest challenge will be finding out how to put the parts together to form proper sprites.

[jirachiband]

Hmm, well that's a plus. I send you luck