[theflyingzamboni]

I'm having TIM troubles. I'm trying to deal with character textures, but the format doesn't match the usual one that all of the TIM exporting/inserting/editing programs I've found expect.

Here's the header:

Code: [Select]

10 00 00 00 08 00 00 00 0C 08 00 00 00 02 F0 01 40 00 10 00Type: 4 bpp
CLUT size: 2048
Palette Org X: 512
Palette Org Y: 496
# colors in CLUT: 64
# CLUTs: 16

But according to everything I've found, 4bpp images should only have 16 colors per CLUT. TimViewer seems to assume this, and treats it as 64 16-color CLUTs instead of the other way round. Tim2View at least recognizes the correct specs. The way they're organized, the first color is black (transparency), then the colors are in the next 15 indices, and the rest are black transparencies.

This causes the problem that any program I use to edit the image exports 16-color palettes (and keeps reordering them). I've tried the GIMP plugin, low-color bmps with paint.net, and usenti, but I'm not having any luck preserving the palette. The one time I managed to replace the texture without the game breaking (using GIMP), the palette was still corrupted, leaving transparencies in weird places because certain pixels got changed to black.

The other issue is that the first 5 CLUTs have non-zero values in the first 16 indices, which means there are 5 UV maps (am I thinking of this correctly?). The last 11 64-color CLUTs are all 00s. But every time I edit the TIM, it chops off the last UV map. So when I save a new TIM, I end up with a CLUT that's 512 bytes long instead of 2048, and contains only 4 color-filled CLUTs, instead of 5. I got the one palette-corrupted texture to work by adding in 1536 bytes of 00s, but that still meant I was missing one of my UV maps (or rather it was fully transparent).

Is there any way I can work with these files to preserve them correctly? Also, how do you work with colors in a multi-palette TIM, when you can't see the true colors as they appear in the game?

[theflyingzamboni]

Any ideas, fellow PSX hackers? These TIMs still have me at a loss. 

[NERV Agent]

What game are you hacking?

Also, are you familiar with Tile Molester? That program can edit ".TIM" files.

I was tinkering with a ".TIM" file in FF7 that had multiple CLUTs, and was a nightmare to keep track of.

http://www.romhacking.net/forum/index.php?topic=23177

http://forums.qhimm.com/index.php?topic=17498.0

I rely on Tile Molester and Jasc Paint Shop Pro 9.

Try viewing the ".TIM" file in Tile Molester with the proper settings, and load the appropriate CLUT. Also, take a screenshot of Tile Molester with the proper CLUT shown. You will need to build a new palette file based on what Tile Molester shows you.

Tile Molester loads ALL THE RAW DATA AND MAKES IT EDITABLE. If you see "TV static" at the top of the image, that is the header data that you should not fuck with. Jump to where the sprites actually start (in my case, it was 0x00000220). Use the “Copy To” function in TM and export that portion of the sprite sheet.

To make the palette, use Jasc Paint Shop Pro 9 to open that sprite sheet, and Decrease Color Depth to 16 Colors (don't save the image file). Then go to Image --> Palette --> "Edit Palette..." and make your changes to the palette to match the CLUT you saw in Tile Molester. Save the palette file by going to Image --> Palette --> "Save Palette..."

To get the sprite sheet to refer to the proper color index, open that sprite sheet again, Decrease Color Depth to 16 Colors, then select everything and go to Image --> Palette --> "Load Palette..." and load the palette file that has the same colors as the CLUT and save. Now you have a file that you can edit and reinsert via Tile Molester.

I hope this helps. I don't know if I forgot to mention anything, because yes, dealing with these ".TIM" files is a fucking convoluted mess.

EDIT: 420th POST!!!

[Gemini]

What is exactly unusual with this TIM? It has 1024 colors (64 palettes), which is only 4 times the max that could be created with the official Photoshop plugin when artists were to create a 4 bit image with multiple palettes. Don't waste time with GIMP, its TIM plugin was completely useless and could never recreate anything even remotely similar.

With Photoshop the trick was that you would have several 16 color palettes arranged "vertically" and use only the colors in a range to produce functional multi-clut segments. The plugin would then take care of ignoring the upper nibble of the original image when converting to TIM. In other words, take the original image, export it as 8 bpp with a palette of your choice, make edits with only a specified range that belongs to a subpalette, save as TIM in 4 bit mode and insert the original vram values.

In your case you could extract the texture with the original indices as a 4bpp bitmap, make your changes without altering the palette or index order, then import only the texture to the original TIM. This would let any palette swap to remain functional.

[cralso]

Most of today's graphic editors do not preserve the color index correctly, details like this make the program useless for my tastes
Anyway you can use Paint Shop Pro, I prefer some of the older versions, like 4 or 5.
Or PictBear, an newer graphic editor wich preserve the color index too.
I think Photoshop preserves this too, although I think is too bloated software.

About the TIM I think you should leave a sample file so that those who want can check it and give you information.

[NERV Agent]

If you are gonna go the Tile Molester route, there is a way to extract a 16 color CLUT as a ".pal" file without having to "build" one in Jasc Paint Shop Pro.

Make an ePSXe save state, and use a program called "PVV" to look through the save state VRAM to find the appropriate CLUT.

[Gemini]

Most of today's graphic editors do not preserve the color index correctly, details like this make the program useless for my tastes

Unless you change the bitmap mode from indexed to RGB and then back to indexed, all the editors out there should preserve color information correctly.

[theflyingzamboni]

What is exactly unusual with this TIM? It has 1024 colors (64 palettes), which is only 4 times the max that could be created with the official Photoshop plugin when artists were to create a 4 bit image with multiple palettes. Don't waste time with GIMP, its TIM plugin was completely useless and could never recreate anything even remotely similar.

With Photoshop the trick was that you would have several 16 color palettes arranged "vertically" and use only the colors in a range to produce functional multi-clut segments. The plugin would then take care of ignoring the upper nibble of the original image when converting to TIM. In other words, take the original image, export it as 8 bpp with a palette of your choice, make edits with only a specified range that belongs to a subpalette, save as TIM in 4 bit mode and insert the original vram values.

In your case you could extract the texture with the original indices as a 4bpp bitmap, make your changes without altering the palette or index order, then import only the texture to the original TIM. This would let any palette swap to remain functional.

According to the documentation I found on this site for TIM headers, the last 4 bytes of the header specify, in order, number of colors per CLUT and number of CLUTs. In my case that's 64 colors per CLUT and 16 CLUTS, not 16 colors per CLUT and 64 CLUTs. I have 16 palettes, not 64. It also seems odd to me that in all these texture files, only the first 16 indices of the first several CLUTs contain actual colors. The other 48 indices of those first few CLUTs are transparencies, and the last several CLUTs are nothing but transparency values. Why all the extraneous values?

And you're right about the GIMP plugin. It and everything else I've tried always tries to reorder the palettes, and corrupts the image.

What game are you hacking?

Also, are you familiar with Tile Molester? That program can edit ".TIM" files.

I was tinkering with a ".TIM" file in FF7 that had multiple CLUTs, and was a nightmare to keep track of.

http://www.romhacking.net/forum/index.php?topic=23177

http://forums.qhimm.com/index.php?topic=17498.0

I rely on Tile Molester and Jasc Paint Shop Pro 9.

Try viewing the ".TIM" file in Tile Molester with the proper settings, and load the appropriate CLUT. Also, take a screenshot of Tile Molester with the proper CLUT shown. You will need to build a new palette file based on what Tile Molester shows you.

Tile Molester loads ALL THE RAW DATA AND MAKES IT EDITABLE. If you see "TV static" at the top of the image, that is the header data that you should not fuck with. Jump to where the sprites actually start (in my case, it was 0x00000220). Use the “Copy To” function in TM and export that portion of the sprite sheet.

The game is The Legend of Dragoon. Here's the TIM I've been trying to work with: http://www.mediafire.com/file/0q40entzya63j78/182.tim/file

Do you mean Corel PaintShop Pro? Or is 9 an old version, pre-acquisition? Is there a free version?

NOTE: I do not have Photoshop.

[Gemini]

According to the documentation I found on this site for TIM headers, the last 4 bytes of the header specify, in order, number of colors per CLUT and number of CLUTs. In my case that's 64 colors per CLUT and 16 CLUTS, not 16 colors per CLUT and 64 CLUTs. I have 16 palettes, not 64.

You can't have 4 bits textures and palettes of 64 colors, which means it's 4 palettes one after another in reality. The TIM documentation is either wrong or you misread it, because clut size defines simply how stuff ends up in vram. That means you have 4x16 16 color palettes in your TIM, hence why 64 palettes in total. For example, if you had an 8 bit image with 512x2 in the clut header, that would mean it's 2 palettes in a row * 2 columns, so 4 palettes.

It also seems odd to me that in all these texture files, only the first 16 indices of the first several CLUTs contain actual colors. The other 48 indices of those first few CLUTs are transparencies, and the last several CLUTs are nothing but transparency values. Why all the extraneous values?

Blending effects?

[theflyingzamboni]

You can't have 4 bits textures and palettes of 64 colors, which means it's 4 palettes one after another in reality. The TIM documentation is either wrong or you misread it, because clut size defines simply how stuff ends up in vram. That means you have 4x16 16 color palettes in your TIM, hence why 64 palettes in total. For example, if you had an 8 bit image with 512x2 in the clut header, that would mean it's 2 palettes in a row * 2 columns, so 4 palettes.

That's why I think it's unusual. My understanding is that 4bpp has max 16 colors per palette, but that's not what the header says.

Here's the TIM description I've been looking at.

This is my header: 10 00 00 00 08 00 00 00 0C 08 00 00 00 02 F0 01 40 00 10 00

And this is a header of an 8bpp single-palette image: 10 00 00 00 09 00 00 00 0C 02 00 00 00 03 F7 01 00 01 01 00

Since I know the second image has one (01 00 LE) 256-color (00 01 LE) palette, by byte position I know that the first header reads 16 (10 00 LE) 64-color (40 00 LE) palettes.

And obviously Tim2View is not PSX hardware, but that's how it interprets the header as well:


Maybe the game is subdividing those into 4x16 palettes as you say, but the header has no way to specify that. And hence at least some of my difficulty in editing it, since programs expect 4bpp images to have only 16 colors per palette.


NOTE: I guess I should specify, since people keep suggesting things like Photoshop and PaintShop Pro: Is there a way to properly edit these images without screwing up the palettes that doesn't involve software that I have to pay for, and otherwise don't need?

[Gemini]

The TIM clut section only represents a RECT of the area where those palettes will end in VRAM. It's up to the game to decide how cluts are then used to draw the associated texture, but if the texture is 4bpp it simply can't use 64 colors.

[theflyingzamboni]

The TIM clut section only represents a RECT of the area where those palettes will end in VRAM. It's up to the game to decide how cluts are then used to draw the associated texture, but if the texture is 4bpp it simply can't use 64 colors.

Ah, alright. That makes sense then. Still makes them hard to edit, since everything I've used: a) reorders the palettes, and b) deletes all but the first 512 bytes (because programs think it should only be 16 colors x 16 palettes). Which means one of the active palettes gets removed entirely.

[NERV Agent]

I got my copy of Jasc Paint Shop Pro 9 off of torrents a decade ago, and later via some other download site. Sorry I can't post links (forum rules), but scour Google or torrents until you find it.

It's also still being sold on Amazon for about $40.

[theflyingzamboni]

It's all academic anyway, because apparently PaintShop Pro 9 won't install on Windows 10 unless I do something ridiculous like  install an old Intel driver.

[Gemini]

You could use PSP7, works like a charm.

[theflyingzamboni]

Thanks, that version installed no problem!

EDIT: I spoke too soon. The image is not properly importing into Tile Molester, which is why I have to change the palette again. Once I edit an image in PSP, how do I get it back into TM?

EDIT 2: I've actually had a bit of success using only Tile Molester, suddenly. So I could just use that if I have to, but considering its limited toolset, I'd like to figure out something better.

[NERV Agent]

Good luck finding one. The only other tile editor I know of that would edit ".TIM" files is still a WIP.

[theflyingzamboni]

Okay, so I was successful. I ended up doing all the editing in TileMolester, and then I just copy/pasted the image bytes back into the appropriate file. Not very elegant, but it worked. Mostly.


(Before anyone asks, yes, it's awful. The texture was a joke resulting from someone's remark that we could brand the monsters now that I'd found the textures. They didn't think I'd take them seriously. And now this is the first and currently only reskin that exists for The Legend of Dragoon.  )

Anyway, the texture I worked on came out normal. But the other monster in the encounter had its texture corrupted, even though I didn't change any of its bytes at all. The way the game organizes enemy textures, they're grouped by encounter. So this encounter file had two texture files. The first texture I edited. The second is identical to the original. Anyone have any ideas why editing one texture corrupted a different one that was "grouped" with it, even though it itself was unchanged?

[mz]

Maybe you changed some of your bitmap/CLUT coordinates and overwrote something on the other texture?

You should take a look at VRAM and see what changed there.