+  RHDN Forum Archive
|-+  Romhacking
| |-+  General Romhacking
| | |-+  Non-Standard Tim Format
Pages: [1]
Author Topic: Non-Standard Tim Format  (Read 776 times)
weissvulf
Guest
« on: December 16, 2006, 03:05:30 pm »

I'm trying to translate some menu text which is stored as a graphic for the Playstation game Brigandine Grand Edition.

It seems to be some non-standard 4bpp TIM format; at least it doesn't match klarth's TIM format breakdown. Its header has the TIM ID tag, and the tag for 4bpp,  but where a 4bpp TIM should have a hex 10 to signify 16 colors per CLUT, it has hex 30, and though its header says it should have 16 CLUTS (by klarth's doc) TimViewer says it has 48.

Anyways, every TIM tool I've used extracts it intact (it's sandwiched with a traditional TIM) but if I try any conversion process, it gets corrupted (at least in part because the TIM tools give it the standard 4bpp TIM header).

Does anyone have any info or know of any reference materials about this format?

It is a different size than a lot of TIMs:
Klarth
Guest
« Reply #1 on: December 16, 2006, 03:34:57 pm »

Yeah, that doesn't seem usual.  But there were some TIMs that I wasn't able to figure out...I'm thinking of a huge CT TIM that contained boss sprites where the palettes were weird.

But there might be something you can do...

1. Dump it to an editable format using the CLUT used for the menu graphics in question...It looks like those menu items in Japanese should use the same CLUT.  The Sony TIMUtil tool will do this and possibly others.

2. Open it with your editor as a BMP (or other uncompressed format)

3. Edit the menu graphics as you like, making sure you only use those 16 colors.  (The header is weird, but it's still 4bpp)

4. Save as a 1 palette TIM.

5. Replace that header with the original's header, CLUTs, etc, and all.

I hope that works.
Gemini
Guest
« Reply #2 on: December 17, 2006, 05:59:23 am »

Is it possible to post the original TIM? I'd like to give it a try personally.
weissvulf
Guest
« Reply #3 on: December 17, 2006, 06:14:12 am »

Thanks klarth. It makes sense that that might work; I'll give it a try and see what happens.


Gemini: Here's a link to the file. This is the unaltered (2 TIMs together) data as it is on the disk. The first one in the stack is the TIM in question.  You'll cave to copy it into the address bar because the free server doesn't allow direct linking.
http://www.angelfire.com/art3/weissvulf/STAY.zip

I'd be grateful if you could post your findings here, as will I Smiley
Feitan
Guest
« Reply #4 on: December 17, 2006, 12:03:42 pm »

Well, the CLUT size for the first image is 1536 bytes, 48 palette in total.
Here you are the real image saved (palette #11)



You got an error somewhere, this is a normal TIM file.
Skeud
Guest
« Reply #5 on: December 17, 2006, 01:06:29 pm »

There is another image inside the file :
weissvulf
Guest
« Reply #6 on: December 17, 2006, 02:53:26 pm »

Quote
You got an error somewhere, this is a normal TIM file.
As far as I can tell, the header data doesn't seem to match common TIM conventions. Every automated TIM converter I've found corrupts the TIM by adding standard headers on the 'graphic.xxx to TIM' conversion step. Were you able to successfully convert the .png back into a TIM that was identical to the original TIM?
Feitan
Guest
« Reply #7 on: December 17, 2006, 03:37:34 pm »

In this case, maybe I'm wrong.
I've not tried to convert it back yet.
weissvulf
Guest
« Reply #8 on: December 17, 2006, 06:57:47 pm »

I've figured out a method that works, and what part of the problem was.  As klarth's doc said, usually:
'[17-18] - Number of colors in each CLUT (always 16)    [19-20] - Number of CLUTs'

But in this case the two values were switched.

17-18 (which was Hex 30) = number of CLUTs (48), and 19-20 (hex10)= colors per CLUT (16).

I switched these values to their usual order in a hex editor, without changing anything else, but the game would not handle the TIM correctly (most game text wouldn't display).

As a work around, I pulled STAY.BIN off the disk,
reversed the two values in a HEX editor so that converter programs would have the header tags in the order they were expecting,
used TIMViewer to extract,
converted to BMP,
translated BMP,
converted back to TIM,
reinserted TIM into STAY.BIN,
then used HEX editor to change the order of the header tags back to how they originally were.

The game now displays the translated TIM fine.

I’ve never seen a TIM arranged like that; I wonder what the significance was. Thanks for your help everyone Smiley
Klarth
Guest
« Reply #9 on: December 17, 2006, 08:57:18 pm »

Perhaps I mixed up the docs a bit...staring at image files in a hex editor messes with your head, especially when you don't double check it with a program.  I don't remember whether the doc was exactly accurate when I wrote TIMmay, which has really sloppy source.
weissvulf
Guest
« Reply #10 on: December 17, 2006, 10:30:32 pm »

I'm pretty sure your doc is right on; that's one of the first things I checked. Every other TIM I looked at matched your doc. (Thanks for writing it by the way. It's one of the most valuable Playstation translation resources I've found. Smiley)

I've worked on hundreds of TIMS and never had this conversion problem, and every tool I tried had the same problem, so I believe this TIM was definitely different than normal - luckily, it just wasn't very different.

Here's how it turned out.



Thanks again everyone!
Klarth
Guest
« Reply #11 on: December 17, 2006, 11:06:07 pm »

np.  PSX resources are hard to come by and I tried to do my part to get some information out there, but unfortunately the PSX translation scene is still pretty lacking.  Sad

And wow, nice results.  Glad it worked out.
Kitsune Sniper
Guest
« Reply #12 on: December 18, 2006, 04:11:56 am »

Quote from: Klarth on December 17, 2006, 11:06:07 pm
np.  PSX resources are hard to come by and I tried to do my part to get some information out there, but unfortunately the PSX translation scene is still pretty lacking.  Sad
Not if I have anything to say about it! Grin
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC