[SpookyElectric]

So I was attempting to edit some of the graphics in Community Pom the other day, when I came across a snag.

The way I've been doing it is, I convert the TIM files into BMPs with TimViewer, edit the BMPs in Usenti, convert back to TIM, then replace the original TIM file within the BIN image using Tim2View. I was successfully able to insert my edited 'Now loading' screen into the game using this method, no problems. However, inserting my edited title screen graphic would cause the game to reset right before it's supposed to display (also caused the music not to play during the intro, for some reason...)

It would appear the culprit is the multiple CLUT files stored inside the title graphic. CLUT #1 is the image itself, CLUTs #2-16 just look like a black screen. Here's the original graphic next to my English edit, to prove they're identical in every other regard.



To the best of my knowledge, there are no programs that can edit the TIM image directly, and no way to convert the TIM to any other format that won't strip it of all additional CLUTs. I did track down a program to merge TIM files together, but no matter what I did, it would only bring the number of CLUTs up to 2. Any possible solution to this conundrum?

[FAST6191]

If indeed all the later ones are blank (though check with a hex editor) it is hopefully easy enough to do a manual insertion of your edited file.

[PhOeNiX]

I find very strange that it even makes the game reset, in the worst case I would expect graphics would be messed up. The issue might be that you are reinserting the TIM in the disc image directly. This should always be avoided. Always extract the game's main files first and then work on them. Finally, reinsert the game files in the bin image.

I already edited Multiclut TIMs with TimViewer by rvech, and I had no issues.

[SpookyElectric]

The issue might be that you are reinserting the TIM in the disc image directly. This should always be avoided. Always extract the game's main files first and then work on them. Finally, reinsert the game files in the bin image.

Heeding your advice, I popped open the BIN image in CDmage, extracted the PCK file which contains my needed TIMs, then edited them using my usual methods. This time, it kept the CLUT info, but.... it still resets when the title graphic is supposed to load, music still doesn't play. Doesn't matter whether I reinsert them via TimViewer or Tim2View, same results. Even more baffling, I tested it on actual hardware to see if it made a difference, it wouldn't register any of the edits, even the 'Now Loading' screen. Just displayed all the original Japanese files. 

Is there something I can do via hex editing, perhaps? That might be within my powers, if I knew what exactly I was looking for...

[Klarth]

For the time being, if TimViewer doesn't work, you can edit via TileShop if you are knowledgeable enough to manually define a TIM and palette(s) as offsets. The direct editing features are currently a bit lacking, but you can import images with some caveats. I'll be adding features over the coming weeks to address some of those shortcomings.

[SpookyElectric]

Hmmm, I might be getting to the bottom of it finally...

Just got through editing a bunch of MultiCLUT TIMs in Harmful Park. Not only do they display perfectly in emulation, but on legit hardware as well.

Went back to edit the Community Pom title graphic from scratch. This time, I sort of hollowed out the hiragana, didn't erase or alter it in any other way. The game loads up as if I hadn't changed anything; doesn't register the edit at all. Then, when I re-did the english edit seen in my last post, same as before. No music, restart before the image can load.

Is it safe to assume there's some process going on here that tells the game "no, that's wrong" if you mess with the hiragana characters? Or perhaps the PCK format is to blame?

[Klarth]

Is it safe to assume there's some process going on here that tells the game "no, that's wrong" if you mess with the hiragana characters? Or perhaps the PCK format is to blame?

The pack format could have checksums/CRCs to validate data. Have you modified any other files within said pack file with success?

[SpookyElectric]

The pack format could have checksums/CRCs to validate data. Have you modified any other files within said pack file with success?

I have not, no. Only the loading screen was able to be modified, which coincidentally is the game's sole isolated TIM...

[PhOeNiX]

I have not, no. Only the loading screen was able to be modified, which coincidentally is the game's sole isolated TIM...

Then, Klarth is probably right. You should first check whether the game verifies some kind of checksum on the files of the archive. This should be relatively easy. Pick an emulator with a good debugger (either no$psx or pcsx1.5 with debugger). Look in RAM where your TIM file is loaded, set a read breakpoint on that address, and try to see at which point the game decides to call the intro routine.
April 12, 2020, 06:41:06 am - (Auto Merged - Double Posts are not allowed before 7 days.)By the way, I had a look at the game, and although I can find the title screen TIM in RAM, there is no trace of it in the disk images. How are you actually replacing this image? I fear there is some compression going on, and you are just replacing the compressed version of this image or even some other image, and that's why the game complains. If no compression were involved, I would at least see the title screen in the disk image with TimViewer.

Here is the TIM file I get by scanning the RAM while in the title screen. There is also a gray scale png version of it. However, there is no trace of this TIM in the disk image.
https://www.dropbox.com/s/pdtylr4d1onzzf3/SLPS_00817.000_000001_04b_01c.zip?dl=1

The image you are modifying is something else. It is not the TIM the game uses for the title screen.
April 12, 2020, 08:33:30 am - (Auto Merged - Double Posts are not allowed before 7 days.)I can confirm the game uses an LZSS compression for its files.

Compressed files all start with a sequence of 3 magic bytes "RUX". Your title screen compressed TIM file can be found in OP1.PAK at address 0xBB26.

This is the structure of RUX files, you might need some background on how LZSS works, I did not have time to polish these notes.
The main routine decompressing RUX files can be found in RAM at address 0x8003E9C4

struct header{
    uint8_t magic[3] //RUX;
    uint8_t is_big_endian; //if 0, the next int32_t is read in little endian, otherwise big endian
    int32_t decompressed_size; //if it is negative, the game gives up decompressing.
}

Structure of compressed stream:

XX XX .... XX XX ...

XX XX are the decompression flags typical from LZSS decompressions. XX XX is always read as a uint16_t in little endian, independently from the is_big_endian flag. After it is read, each bit, from the most significant to the least significat determines whether next there is a plaintext byte to be copied in the output, or a sequence of bytes specifying how to decompress.

If the bit is 0, juts copy the next byte, if it is 1, then read the next uint16_t in little endian. Let this value be the two bytes AB CD. If A is not zero,  then A+1 denotes how many bytes to recover from the current output stream, and BCD+1 is the jump back in the current output stream.
If A is zero, then use ABCD as jump, read the next byte, sum 0x11 to it, and the result is the amount of bytes to recover.

Keep going until all flags in XX XX are over or the decompressed size is reached.
Then, move to the next flags XX XX, and keep going until the decompressed size is reached.

Regarding PAK files, they are quite easy. THey start with a sequence of uint32_t's, each being the address of a file inside the PAK (the addresses are stored in little endian).

-EDIT-
Here is a quick decompressor for RUX files (it's a command line tool). I tried it over the RUX with the title screen, and I get a 1:1 match with the original decompressed TIM found in RAM, and when recompressing it back, I get exactly the same RUX file, so I believe it compresses in the same way as the devs tools.

https://www.dropbox.com/s/95fpe8txmrlipki/CommunityPOMDecompressor.zip?dl=1

As you can see, the decompressor works as intended. I made a slight modification to the title screen using usenti and TimView2:


"Fall in Cafe" is the new dev group for the game XD.

[SpookyElectric]

Thank you so much for that detailed write-up, as well as the decompression tool! I'll mess around with it later tonight, see if editing the opening credits is within my capabilities.

(Also, changed the topic to better reflect where the conversation ended up )

[PhOeNiX]

Good! Here is the source code, in case someone is interested.

https://github.com/marco-calautti/CommunityPOMTools