News: 11 March 2016 - Forum Rules

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 - weissvulf

Pages: 1 [2] 3 4 5 6 7 ... 12
Personal Projects / Re: PS1 tools
« on: February 19, 2018, 03:30:30 am »
it's not a big deal for me though since i have the ps2 edition of imagestudio with actual tim/tm2 support
Oh sure, show of with your fancy-schmancy new PS2 generation tools! ;D

And how did you find out that there are 104 of them, each 32 bytes? I mean, there must of been some logic behind finding this specific info.
Other than 24bit, all TIMs use 16bit color. Indexed images still use 16bit color in their palettes.

That means each color entry in a palette is 2bytes long (aka 16bits). So a 16 color TIM has 32 bytes per CLUT (aka 0x20). For 256 colors, that's 512 bytes per CLUT (aka 0x100). In Tomb Raider, the block of CLUTs is separated from other stuff by a field of 00s, so it's easy to measure its total size of 0x2080. Divide that by 0x20 per CLUT = 0x104. Incidentally, there was a typo earlier. The block of CLUTs actually begins at 0xC44b8.

As far as knowing that CLUT1 went with texture1, that was an educated guess. Games are assembled by computers and computers usually do things in a patterned way.

As far as how to find the CLUT block to begin with, I looked a the VRAM and saw what looked like the CLUT block. They're almost always stored near the image data in a file, so I just scanned before and after the image data using nana, and saw the same 'shape' as in VRAM.

How do you inject new CLUTs into a TIM?
A 16 color TIM header looks like the picture below. I just copied the entire chunk of CLUTs from Level1 and inserted it over the original single CLUT. Then edited the other values to match the new CLUT size and count.
You may know the PS1 is 'little endian' meaning the byte order is reversed, so 0x104 CLUTs x 0x20 bytes each = 0x2080. Reversed and +0xC = 0x208C. Number of CLUTs = 0x104, reversed is 0x0401.

Another useful trick, since indexed palettes are identical in format to a 16bit TIM, you can extract/insert them with RAWtoTIM as a 16bit TIM. The 'number of colors' becomes width, and 'number of CLUTs' becomes height. Because the tool wasn't specifically designed for this, you may lose the 'transparency', but most TIMs don't use this feature anyways.

Also, how do you cycle through all the different CLUTs in Jasc Paint Shop Pro 9 (if it is even possible)?
Unfortunately the plugin doesn't support cycling through CLUTs. You also have to be careful about preserving the VRAM coordinates. One way to simplify this is to use RAWtoTIM to extract a TIM from the TIM. It sounds silly, but will leave all the header data intact since it only inserts the image data.

I was searching for the reason my copy won't load (anti-mod) and ran into what looks like the same compression you've been describing. If this is compression, it's just about the crummiest scheme I've ever seen. There seems to be a pattern where 00 means the next 8 letters are to be copied as is. Have you tried adding that code to your text? When the 00 is replaced with 80 (aka  1000 0000), it causes a fluctuation 8 letters later. Just like you said, a bitwise 'countdown'.

F8 0F 20 20 20 20 20 53 00
?--?-- -- -- -- -- --S

4F 46 54 57 41 52 45 20 00

54 45 52 4D 49 4E 41 54 00

45 44 0A 43 4F 4E 53 4F 00
E--D-- --C--O--N--S--O 

4C 45 20 4D 41 59 20 48 00
L--E-- --M--A--Y-- --H

41 56 45 20 42 45 45 4E 80
A--V--E-- --B--E--E--N

20 4D 4F 44 49 46 49 E1 0F 01 C8

2F 43 41 4C 4C 20 31 2D 00
/--C--A--L--L-- --1- -

38 38 38 2D 37 38 30 2D 00
8--8--8- - --7--8--0- -

37 36 39 30 00 00 00 00 00 

Personal Projects / Re: PS1 tools
« on: February 18, 2018, 11:17:37 pm »
WHaAAAaaaAAAaaaaTTTTTtttt!!!!! :D Jasc made very good software. If it aint broke, don't fix it!
I assume you tried the TIMFMTE.8BI plugin file for older versions?

Personal Projects / Re: PS1 tools
« on: February 18, 2018, 11:00:34 pm »
Yep, the ".TIMproject" file is just a TXT document which saves the settings for the given file.

HERE is a copy of the tool with the width/height limits removed. I tested it on the full-length span from Level1, and it seems to work. But keep in mind, the TIM format wasn't necessarily designed for such large sizes so quirks may show up.

So I loaded LEVEL1.PSX and it loads. However, only one 16 color CLUT was extracted, not all 11.
Unfortunately that's all the tool was designed to do since text-graphics rarely have more that one CLUT. Also note that the tool does not re-insert CLUTs so any edits to the palette will not be transfered back into the file.

Also, how did you figure out how to find where the CLUT starts? This is something I could never figure out.
I didn't really, :P The CLUTs are in a big block starting at 0x44b8 which holds 104 CLUTs at 0x20 bytes each. They are listed in the same sequence as used in the textures. In other words, CLUT1 is used for texture1 on sheet1, CLUT2 for texture2 on sheet1. The pattern begins to break down when you come to textures which reuse previous CLUTs (such as the wolf tracks) so matching a texture in the middle would be pretty hard. I'm sure the information linking texture to palette is somewhere in the file, but I don't know where.

Oh, and the plugin you linked to is for Adobe Photoshop, not Jasc Paint Shop Pro 9.
PSP is compatible with Photoshop plugins. If you go to 'Help > Help Topics' and search for "setting plug-in locations" you should see directions for installation.

Just for the fun of it, I injected all the CLUTs into the Level1 texture TIM HERE. TimViewer opens it, but I think official TIMs were capped at 16 CLUTs max.

Mugi, what version of PSP are you using?

It sounds like you're certainly on the right track!
It either loads bytes directly from the "compressed" zone and stores them into the other zone, loops loading bytes from the compressed zone until it finds the appropriate byte to load and store, or it uses a loaded byte to calculate (with some ANDs and ORs and shifts and values in other registers) an address pointing to the byte that must be stored. I've seen this address end up pointing to the uncompressed zone,
I would think figuring out the trigger for these three paths would be the key. If one patch copies directly from compressed to decompressed area, perhaps you can discover how to make it the only path that is triggered.

The bitwise operations you mention may work toward the pattern Vehek mentioned earlier. You may already know, but AND operations are usually for 'bitmasks' - extracting bits out of a larger number. It's common to see an AND followed by a SRL to move the extracted bits into their proper place before testing.

If you don't already have a resource for tracking such operations, the HexDecBin converter HERE might help.

On a related note, I get the anti-mod lockup screen when I load this game in pSX 1.13, even when using a Japanese BIOS. Which is especially strange because the Redump database doesn't list is as anti-modchip. Has anyone been successful in booting this game with the pSX emulator?

Gaming Discussion / Re: Cheat for Aubirdforce PS1?
« on: February 18, 2018, 05:00:30 pm »
Vergil2012 Thanks a BUNCH! One of the sites you found (HERE) had the answer. You enter the Japanese name すごくえらいひと and LATER your name changes to へんしん with level 99 stats. The 'later' part is what I was getting wrong. You have to play into the first mission before the change takes effect. The cheat name means roughly "great person". There's no change in character portrait, just stats. I'll try to make sure I don't break it  :)

tvtoon This particular game has around 10 exe files that it juggles into memory as needed. I had already scanned the exe that is active during the name-screen for the cheat name/stats. But as mentioned above, the code doesn't become active until later in the game when a different exe is loaded. So I was looking in the wrong place  :P

Anyways, thank you two for taking the time to answer  :thumbsup:

Personal Projects / Re: PS1 tools
« on: February 18, 2018, 01:25:33 pm »
Is the "invalid TIM header error" from a TIM produced with RAWtoTIM? I just tested the Tomb Raider extracts I made and they seemed to open fine. Pictured is the 1st sheet from the opening level - you can see the wolf tracks on the right.

As far as the TombRaider texture height, that 2816 is probably 11 different 256 tall sheets. That's how it's loaded into VRAM. They're just stacked on top of each other with no header in between. But if you would like to extract them as a single image, I can make a special build with the 3-digit cap removed. It's not an 'functional limit'. I put it there to help people avoid making mistakes.  :)

By the way, do you know that Jasc PSP supports TIM natively using the plugin HERE?

Gaming Discussion / Re: Cheat for Aubirdforce PS1?
« on: February 18, 2018, 12:48:17 pm »
Sorry if I wasn't clear. What I'm looking for is anyone who can tell me how to apply the name-entry cheat so that I can make sure not to break it during my work. Even a gameshark-type code to play as the Captain Henshin would be useful though. It would help me locate the Captain's data which which I could probably trace back to the name-entry that triggered it.  :)

Gaming Discussion / Cheat for Aubirdforce PS1?
« on: February 18, 2018, 03:31:11 am »
There's a widely reported cheat for Aubirdforce (PS1) saying to enter "Sugokueraihito" for the player name to play as Lv99 Captain Henshin. As far as I can tell, the cheat is bogus. The name has too many letters to enter in English, and converting it to Japanese doesn't seem to work either. Also, I have yet to find any internal reference to 'Henshin' or a stat table for a level 99 character.

I only care because I'm having to 'gut' the old text system to convert to English and it has the potential to break this code. I can dig further, but I thought I'd ask if anyone ever used it successfully.

I think that simplifies things. Like Mugi said, going 16 to true=color should be lossless for the image. As you edit the true color version though, PSP won't limit you to the original 16 colors so you're likely to end up with more colors due to blending etc.

One possible way around this is to import a copy of the original 16 color palette into PSP (Image > Palette > Load Palette) before you start editing. If you do that, PSP should lock you into only using the 16 colors available and maintain the palette order. Save as a 16 color PNG. Assuming TileMolestor will import 16 color PNGs, you should end up with no problems whatsoever.

Some variables could could go wrong there. Often converting to true-color and then back to 4bit will reorder the palette and thus change the image data. In other words, if black=00 and white=01 originally, after the conversion the editor may have changed it to white=00, black=01. The image will look identical, until it switches to one of the other CLUTs that expect the image data to be using the original palette order. The best bet is to just try it and see what happens.

Are you editing the CLUTs or just the image?

it's getting the value to write from another location in memory, already decompressed/decrypted.
I've found multiple copies like that to be very common. Usually the text goes through a series of tests each time it is copied, and variables like names are filled in etc. If you keep going, you should get to the original 'compressed' text as loaded from the CD. You might get lucky and find some simple compression or encryption routine that can be bypassed all together.

Personal Projects / Re: PS1 tools
« on: February 17, 2018, 04:18:52 am »
But I have a question of my own, pertaining to RawToTIM. If this is capable of ripping the textures out of the Tomb Raider level files, will it also extract all the CLUTs along with it?
Not in a convenient way. The tool was made for translating text images mainly. As such, it only generates TIMs with a single palette.

In the case of Tomb Raider, the image data is 256x256, with each sheet holding multiple textures- and using multiple 4bit palettes. For example, in Level1.psx, the first textures at 0x5c4b8 would be properly extracted as 256x256 with something like 11 CLUTs. This tool could extract 11 copies of the texture, each with a different CLUT, but that would rarely be worth the effort.  :-[

HERE is the project file for the first texture in LEVEL1.PSX if you want to see what I mean. Just put it in the same folder with LEVEL1.PSX and load the psx file.

Personal Projects / Re: PS1 tools
« on: February 16, 2018, 05:21:57 pm »
Added a re-written version of AutoASM. Significantly faster, supports variable end-bytes, removed unnecessary options, fixed a bug that would endlessly loop if scanning an empty area, added a generic 2byte search mode which increases pointer detection capabilities, etc.

Added '2bit' tool which converts 2 color BMP fonts (similar to the PS1 BIOS font) into raw binary data, ready for insertion.

I almost wonder if it's encryption rather than compression. Since you know the RAM location of the 'decompressed' text, have you tried putting a 'breakpoint on memory-write' at that location? That would let you discover the tail-end of the routine generating the final text. From there you should be able to trace backwards to see how it's being produced.

Nice stuff! Here's what little I know:
PS1 data is almost always aligned to 32bit chinks. Because of that, if you use HxD hex editor, and set the view to 'byte group size=4', you'll be able to spot patterns easier.

Like Valendian said, the 00s after the names are 'end-text' markers, filled to the next 32bit boundary. You can usually write over these 00s with more text, as long as you leave at least one 00 at the end. Other than the names and their fill, there are three 4byte chunks left. Keep in mind, the PS1 is little endian, meaning byte order is reversed.

If the variable length names are at the end of the structure (like Valendian says), the entries would look like this:

F4210280 044A 0404 0404 020B.....594F5348 494D4954 53550000..YOSHIMITSU
0C220280 051E 0505 0505 090C.....4E494E41 00000000...............NINA
20220280 0647 0606 0606 040D.....48574F41 52414E47 00000000..HWOARANG

The PS1 memory addresses usually end in 0x80 (aka have the highest bit set), so the first 4 bytes are a RAM address. The converter tool HERE should help you locate where these addresses are pointing to. EDIT: I checked, and they are pointers to the character names. That verifies that the names are listed at the END of each structure.

That leaves 8 bytes. They are likely NOT full memory addresses, but maybe 'relative' addresses to look up combat moves in a table. They are probably 1 or 2 bytes long (not 4) but I have seen such tables use 1bit tags. There's an obvious pattern counting up by 1 for each new character (04 > 05 > 06 etc)- perhaps progressing through a table list of moves. I would try to edit them, 1byte or 2bytes at a time and see what changes.

Cross referencing the Headspin's link with the No$GBA, it looks like the different formats are decompressed though distinct BIOS routines. If the compression method is not formatted properly for the BIOS routine that it is sent through, it makes perfect sense to me that it would produce a SWI error. Like FAST6191 says, the different decompression 'paths' seem to have different alignment requirements. Neat info!

For example, it says of the SWI 10 routine:
r0  Source Address      (no alignment required)
  r1  Destination Address (must be 32bit-word aligned)

For SWI 16, it says:
r0  Source address (must be aligned by 4)

You might try narrowing down what is causing the problem by reversing all modifications except for 1 small sprite and seeing if the crash still happens. If it does, you at least know where to look for a solution. If the crash doesn't happen, add back your modifications 1 by 1 until the problem shows up. Narrowing down the issue is always a good place to start on a solution.  :)   

What mz said is the most common issue I've seen that makes a game run on emulators but crash on real hardware. Specifically, the op-code 'load word' (which loads 4 bytes into a register) requires that the read location start at a multiple of 4 (0x0,0x4,0x8,0xC). Since that's a limitation of MIPS processors, it's usually not enforced by emulators running on different processors. A compressed graphic is likely to have data in a header needs to be 'aligned' like this.

Programming / Re: Any good editors that save 16bit BMPs?
« on: February 06, 2018, 11:50:10 pm »
Neat stuff Squall! I'll add this to my 'speed test' list when I rework the tool and see how it works. I've been working on a crude 'bitmap-font' text writing tool lately, and these tips may come in handy for it also.

I read a bunch of that guide too and learned some things so thanks to FAST6191 too  :thumbsup:

Pages: 1 [2] 3 4 5 6 7 ... 12