News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - PhOeNiX

Pages: [1] 2 3 4 5
Newcomer's Board / Re: Not a noob but having hell with Xdelta
« on: May 10, 2020, 05:49:38 pm »
In DeltaPatcher you can choose to apply the patch by ignoring the checksum check. You can at least see if the patch works, after disabling the check.

Newcomer's Board / Re: Community Pom file compression
« on: April 13, 2020, 02:40:40 pm »
Good! Here is the source code, in case someone is interested.

Newcomer's Board / Re: Can't Create PPFs!
« on: April 12, 2020, 10:15:05 am »
If you change the size of the game after your modifications, PPF is not going to work. Use xdelta instead. You can use either Delta Patcher (not lite) or xdelta UI.

Newcomer's Board / Re: Editing PS1 TIM files with multiple CLUTs?
« on: April 12, 2020, 06:03:01 am »
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.

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).

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.

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.

Newcomer's Board / Re: Editing PS1 TIM files with multiple CLUTs?
« on: April 10, 2020, 11:46:38 am »
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.

Programming / Re: (PSP) FF4 - LZTX Compression
« on: March 29, 2020, 07:20:15 pm »
I might be wrong, I am not an expert in Graphics APIs, but as far as I know (at least according to all sources I came up during my research) mipmaps are *precomputed*. In fact, It is also a big deal how much more storage mipmaps require (1/3 of the original image).

Of course no one prevents the game to generate them on the fly with HW, but what probably a game does at run-time is to interpolate between two mipmaps, to obtain one that is of the right resolution, given the distance from the camera. But the base power-of-two smaller images are usually stored on disk, I believe.
This would also allow the game to have very high quality scaled-down versions of the original texture, since they are computed offline, and time is not a constraint in that case.

I went all software because I wanted as less dependencies as possible on external APIs, so to have a portable codebase. Given that Rainbow is not a real-time tool, but mostly meant for format conversion, there was no need to rely on HW acceleration.

Moreover, for some formats, like Gamecube's DXT1, there were some subtle differences with the PC one that using the graphics API (e.g., DirectX) would result in not accurate decoded images.

This is actually the same exact reason why the dolphin-emu went the software route as well, according to their comments in their texture decoder:

Programming / Re: (PSP) FF4 - LZTX Compression
« on: March 28, 2020, 05:28:50 am »
The reason why mipmaps are stored in the tm2 files is just efficiency. It does not make much sense for a game to generate them on the fly, all the time. Now, images can be scaled down with different approaches, and the resulting images can be slightly different. If your goal is 1:1 fidelity with the original game, it makes sense using the original mipmaps. However, I don't remember any mipmapped tm2 in ff4 psp, being mostly a 2d game.

Regarding filters, I think I chose the wrong term for these objects. They are meant to preprocess image and palette data, to make them all uniform w.r.t. the internal representation used by rainbow. For example, tile-based images need a TileFilter to be converted in linear form (i.e. pixel rows stored one after the other), which is how Rainbow interprets image data internally. Similarly, TIM2PaletteFilter is needed to preprocess the scrambled palettes to linear (which is how Rainbow interprets palettes internally).

That's why it is all software, it is not some kind of "aesthetic" filter, but more "structural".

Generally, the user of Rainbow should not be concerned with filters. They are used internally to support the graphics format at hand. An exception is when the file format provides not information on the filter needed, and then the user needs to choose one. An example is swizzling for tm2. The tm2 header has no flag indicating if swizzling is used. This is solved e.g. in Game Graphic Studio, by choosing the interlace mode (PS2, PSP, etc.).

Nevertheless, the interface is general enough to allow also for "aesthetic" filters, in case the specific file format allows for such a thing.

Programming / Re: (PSP) FF4 - LZTX Compression
« on: March 27, 2020, 05:05:24 pm »
Yes, that's my github repository. Regarding TIM2 files with multiple frames (images), yes they are reasonably common, and I know at least two games that make extensive use of multi-frame TIM2 files. Regarding multi-palette images, yes Rainbow supports them (FF4 PSP actually contains some, see e.g., the TIM2's containing characters portrait like Golbez). Actually, Rainbow supports almost any configuration of TIM2 files. The only thing it does not support at the moment, although it is not difficult to implement, is mipmapped TIM2's, which contain different scaled down versions of the same image. These are quite rare, and generally not worth modifying (at least for translation purposes), as they are usually used for texturing materials, objects from the distance, etc.

Programming / Re: (PSP) FF4 - LZTX Compression
« on: March 27, 2020, 01:55:51 pm »
Here is the Goblin image previewed in Rainbow

You can see the palette is not "linear", and you need to "linearize" it with the code I mentioned in my reply above.

Programming / Re: (PSP) FF4 - LZTX Compression
« on: March 27, 2020, 08:10:04 am »
You might find my two repositories below useful. We have been using it with my translation group for an italian translation of the game. (toolset to dearchive and decompress essentially everything in FF4 PSP, supports LZTX as well)
FF4Archiver is the (de)archiver of the PAC0/1.bin archive inside the game. Its command line usage might be a bit complex, but it is quite fast in rearchiving everyting, as it does not create the archive from scratch, but only inserts the modified files.

FF4Decompressor: decompresses every file compressed with the LZSS variant used by the game (without the LZTX header)

FF4MiniArchiver: (de)archives the small archive files found inside the main game archive. It automatically decompresses and recompresses LZTX textures, whenever it finds any in the given archive.

CompressionLibrary: contains the main LZSS (de)compression functions, in case you might need them.

Unfortunately I did not ship any binary for the above tools, but I can provide, in case you need them.

and (opens and converts TIM2 files back and forth to png)

You might use the ImgLib subproject in Rainbow, and embed it in your tool.
Latest binaries are provided in the project readme, under "latest dev build".

P.S. Strangely enough, even GameGraphic Studio is somehow limited on TIM2 support.
In fact, the color palette is messed up for some images, because it has been reordered for fast access on hardware. Take a look at on how to reorder it.

Rainbow takes care of everything, and supports opening TIM2 files either in swizzled or linear form (which are both used by the game).

Programming / Re: Help with \"DTE - you can do it, we can help\"
« on: February 13, 2020, 04:17:08 pm »
I'm working with like six 00 bytes and I still am not sure where to find more, but I'll mess with RAM and message back. Thanks!
One option is to extract some text from the game, compress it with your DTEs before even writing down your DTE routine, and putting it back into the ROM. The remaining space after/before the new compressed text should be enough to implement your routine in the ROM.

Newcomer's Board / Re: .tim pixel editor
« on: July 11, 2019, 05:32:35 am »
Use TIMViewer:

Convert to BMP, edit and convert back to TIM.

ROM Hacking Discussion / Re: Something like xdelta that can stack patches?
« on: February 07, 2019, 03:52:38 am »
If checksum validation is your only problem, xdelta allows you to disable it completely.

Gaming Discussion / Re: De-patching?
« on: September 22, 2018, 04:25:47 pm »
xdelta and the size of it's patches really largely depends on how it has been used, if you use the commandline "-B ****" (***being the scan block size here) that defines the maximum block size to be the same size as the image file itself, it will compare differendials between the whole image as opposed to the default setting which to my knowledge is not very large.

for example, my translation patch for evangelion: girlfriend of steel for psp, with default settings of xdelta, produced a patch of the size of 220MB
and by using the switch "-B 536870912" (536870912 meaning 536,8MB, the size of the .iso file) reduced the patch from 220MB to 40MB

I agree, indeed Delta Patcher was designed exactly for this reason, to have a more fine grained control on the patching process, without relying on the command line. You can choose the Source Window Size in Delta Patcher as big as 1 GB.

In my experience, BPS patches (at least the ones generated with current encoders) are always bigger than properly tweaked xdelta3 patches.

Newcomer's Board / Re: xdelta patched roms with genplus gx
« on: January 11, 2018, 11:14:52 am »
The patched ROM might have not a right checksum. You can try fixing the checksum of the ROM with this.

You might want to have a look at this.

Newcomer's Board / Re: Reduce data size of a graphic?
« on: June 06, 2016, 02:41:42 am »
If your image has the same resolution, there is no way your new image will get bigger, unless the game uses some kind of lossless compression like LZSS. In that case the real problem is to write an optimized compressor and not reduce image quality.

Newcomer's Board / Re: How to create a .TIM image? (PSX)
« on: May 24, 2016, 05:35:59 am »
In my experience, the easiest way of dealing with paletted TIMs is to convert the TIM to BMP with TIMViewer. Then the critical part is to edit and save the bmp by preserving the color depth (4bpp, 8bpp etc.), for this I find very useful with its LowColor FileType plugin. This allows you to save low color bmp by choosing the right maximum amount of colors you need in your bmp.

Newcomer's Board / Re: Tim and clut
« on: March 30, 2016, 12:45:06 pm »
Tim2View does not properly support some TIM files. The only tool I am aware of it is fully capable of handling TIM files is TIMViewer by rveach.

Pages: [1] 2 3 4 5