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 - NERV Agent

Pages: 1 [2] 3 4 5
26
I am dealing with the ".TIM" file that contains the hand cursor graphics in "WINDOW.BIN". This ".TIM" has 16 CLUTs, each with 16 colors. I would like to extract some of these CLUTs and have them in ".PspPalette" or ".pal" format that can be used with Jasc Paint Shop Pro 9.

I realize I can always take an existing 16 color Paint Shop Pro palette and just change the index values to match what is in the CLUT, but that is time consuming. (Also, if this was a 256 color CLUT, that would be an arthritis inducing nightmare.)

Is there a way to extract CLUTs from a ".TIM" and have it in a palette format that can be loaded into Jasc Paint Shop Pro 9?

27
I am making this post for documentation purposes, in case this information can be useful for someone out there.

I've made some progress in analyzing the hand cursors, and discovered a few oddities.

However, first I need to get out of the way the issue of compression before proceeding.

Making seemingly simple changes to the ".TIM" file results in a larger "WINDOW.BIN" after compression (which is bad).

I couldn't figure out how to properly resize the CD image, but came up with a rudimentary MacGyver solution.

If my understanding is correct, the compression in FF7 works by "compacting" redundant data. So if there is a chunk of data that is pretty much a repetitive sequence, it can be "compacted".

Here is the US tile map, ripped with Tim2View with CLUT [02/16] loaded:



Here is the Japanese tile map, ripped with Tim2View with CLUT [02/16] loaded:



Notice how there are graphics in the US version that are not present in the Japanese version? And where the additional graphics in the US version are present, chunks of "gray blocks" are in the same place in the Japanese version instead. With the idea of redundant data being "compacted", I figure I can just "gray out" graphics in the US version that are not in the Japanese version. If Japanese gamers can play the game without these additional graphics, why can't we?

Here is the US tile map with the "grayed out" areas, ripped with Tim2View with CLUT [02/16] loaded:



After compressing into a new "WINDOW.BIN", the result is a smaller "WINDOW.BIN" which gives me some room to make edits.

I made a ".IPS" file that creates these blanks to save time for future work here.

And with that out of the way, here is the US tile map with the exact locations of the hand cursors marked, ripped with Tim2View with CLUT [02/16] loaded:



You can get my copy of this ".TIM" here, although I haven't tested this recently "cleaned up" version in game yet.

While analyzing these hand cursors, I noticed some strange things.

The field cursor seems normal.

The menu cursors are weird.

First off, I noticed that the cursors are not fully rendered all the time. For example, the hand cursor "pointing right" is 24 x 16 pixels, but at the opening "NEW GAME / Continue?" screen it is rendered as 21 x 16. But elsewhere in the game the full 24 x 16 pixels is rendered in the game, and sometimes it is rendered in a completely different resolution. The "jail cell bars" you see in that cursor mark columns of pixels that are omitted at the opening "NEW GAME / Continue?" screen, when I first noticed this oddity.

The next set of oddities are confusing and can be problematic for anyone who wants to completely change the graphics on this tile map.

The CLUT data observed in programs like Tim2View and Tile Molester are inconsistent with what is rendered.

In the hand cursors that are pointing left and right near the top right corner, I have replaced the transparency with blue. However, when this is rendered in game the blue color doesn't appear, but a transparent red tint in its place instead.

Here is a screenshot using an older ".TIM" I made (this one is "messy" so please excuse other messed up menu stuff) while analyzing this:



A similar discrepancy is present with the "red X" hand cursor.

Here is the US tile map with the exact locations of the hand cursors marked, ripped with Tim2View with CLUT [08/16] loaded:



I have replaced the transparency with gray, but when this is rendered in game it comes out as black. Here is a screenshot using the same ".TIM" from the gameplay screenshot from before:



I guess my next mission is to experiment with the CLUT.

28
Hi there.

I'm a newbie to FF7 hacking an am currently experimenting with stuff.

I made a modified "WINDOW.BIN" that is larger than the original.

I tried adjusting the size of "WINDOW.BIN" accordingly in "YAMADA.BIN", rebuilt the ISO with psximager, and ran it through ECCRegen. The game still won't load.

I think I need to change the LBA value, too. How do I calculate what value to change it too? And would I need to change the LBA values off all the files listed after "WINDOW.BIN"?

29
Troubleshooting / Re: psximager doesn't work. :(
« on: 2017-05-14 09:31:13 »
Even more updates:

I tried using TOC Changer v1.2, and it didn’t fix it.

I tried using Mass ISO Update, and it will either give me an ISO that causes a BSoD when loaded in an emulator, or an ISO that doesn’t load after “Sony Computer Entertainment America Presents”.

30
Troubleshooting / Re: psximager doesn't work. :(
« on: 2017-05-14 08:57:27 »
An update to things.

So I edited "YAMADA.BIN".

My modified “WINDOW.BIN” that is 0x00003422 bytes will be designated as “22 34”, so I replace "D2 33" with "22 34".

I ran psxbuild again, then I ran ECCRegen with the same settings I used before. It doesn't seem to detect any errors.

The ISO I have now still does not load in an emulator.

What else should I try?

UPDATE: I think I need to change the LBA value, too. How do I calculate what value to change it too?

31
Troubleshooting / Re: psximager doesn't work. :(
« on: 2017-05-14 05:47:34 »
Thanks for the response.

Can I edit "yamada.bin" directly with a hex editor, or do I need to decompress it first?

I'm new to FF7 hacking and it seems to me that nearly everything in this game is compressed.

32
Troubleshooting / Re: psximager doesn't work. :(
« on: 2017-05-13 01:36:56 »
Ugh. So I've been told that FF7 stores LBA values into various modules. Is this true?

IIRC from reading the psximager documentation, that means the game code needs to be rewritten to accommodate for new LBNs.

>_<

33
Troubleshooting / Re: psximager doesn't work. :(
« on: 2017-05-12 04:20:41 »
Could the issue be with "WINDOW.BIN"?

My modified "WINDOW.BIN" is here:

http://www.mediafire.com/file/ywe6qmltx0zf81z/WIP_borders_flooded_0x220_clut_02-16_WINDOW.BIN

(Of course, when I reinserted it the file was named "WINDOW.BIN".)

When I insert it in CDmage, it "truncates" the file. The game loads at "Sony Computer Entertainment Presents", then hangs after that.

After using psximager, the game just doesn't load at all.

34
Troubleshooting / Re: psximager doesn't work. :(
« on: 2017-05-12 03:44:47 »
Unfortunately, it didn't work.

In ECCRegen, I opened the new ".BIN", marked  "MODE 2 (PSX/PC)", under settings I checked "Fix mode 2 Form 2 sectors", and hit Scan. The program does something and then suddenly closes.

The ISO still won't load in an emulator.

35
Troubleshooting / psximager doesn't work. :(
« on: 2017-05-12 03:21:01 »
If you've been following my posts, you would know that recently I've been experimenting with modifying the hand cursor for Final Fantasy VII (PSX).

The data is stored in "WINDOW.BIN", and after working on the ".TIM" and creating a new "WINDOW.BIN" with my changes, the new file is larger than the original. You know what that means....

Simply using CDmage will not fix this.

I tried using psximager, and I can rip the file system off the ISO with "psxrip".

So then I replaced the "WINDOW.BIN" in the filesystem it dumped with my own "WINDOW.BIN" with my changes.

I then tried to rebuild the ISO with "psxbuild".

It seemed to be working as it did generate a new ISO. But when I load this ISO into a PSX emulator, the game doesn't run at all.

What could of gone wrong?

Is the problem with the ISO I was initially using (before using psximager)? If so, is there a proper way to generate a PSX ISO in ".BIN" format that can be loaded into psximager?

Or could there be an alternative to psximager?

36
Completely Unrelated / Re: Megaman Music Fans?
« on: 2017-04-11 10:05:08 »
https://www.protoman.com/

They used to have an Internet radio station, and I used to listen to it a long time ago while working on PSX ROM hacks! Really helped my productivity!

It went down, so I went to The Mega Man Network and listened to Rockman Radio. But that, too, went down.

I guess I have to settle for YouTube playlists being set to random.

Also, the Mega Man Zero tunes are my favorite OSTs of all time.

https://youtu.be/nl5Odk8whtk?t=1m3s

Freaking epic! When I was younger Zero was my idol, and still is!

37
I seem to have a streak of bad luck, as lasyan's Tool Hack7 has been giving me errors and BSoDs. I was able to extract the graphics from "WINDOW.BIN" with it though, but I can't put it back in since it gives me errors and blue screens. So I reinserted it using luksy's program and CDMage.

Anyway, I think I solved this shifting problem!

Tile Molester is primarily used for ROM hacking, not general graphics editing. When Tile Molester loads a file, it makes ALL THE RAW DATA viewable and EDITABLE.



You see that "TV static" at the top of the image? I believe that is the header and CLUT data. So when I used the flood fill tool, I must of unwittingly altered this data.

What I did to fix this was create an “.ips” file that is supposed to restore headers back to their normal state.

I researched the header info and came across the following resources:

http://rveach.romhack.org/PSXInfo/tim.html

http://www.romhacking.net/documents/timgfx.txt

The headers and CLUTs are organized like this:

1.) 1st Header Block
2.) CLUT data
3.) 2nd Image Header Block

The CLUT data is "sandwiched" in-between 2 blocks of header data.

I intend to edit the CLUT at some point, so my ".ips" file should only revert the 1st and 2nd Header Blocks.

I extracted the ".TIM" file from "WINDOW.BIN" using Hack7. Then, I zeroed out portions of the header data in this file. I specifically zeroed out data as such:

The 1st Header Block is 20 bytes, so I zeroed out the first 20 bytes of the file.

Then I had to account for the CLUT. This ".TIM" file has 16 CLUTS, each with 16 colors each, so the CLUT data here is 512 bytes. I identify the 512 bytes after the first 20 bytes, as this is the CLUT data I wish to retain.

Right after the CLUT data is the 2nd Header Image Block, which is 12 bytes. I zero out those 12 bytes, and save this zeroed out file.

Then, I use Lunar IPS to make an ".ips" patch as such:

“ORIGINAL UNMODIFIED” (target): 0ed “.TIM” file.
“NEW MODIFIED” (containing desired changes): Original “.TIM” file.

Here it is: https://www.mediafire.com/?31svwkz7z1ppzbe

I applied it to that corrupted ".TIM" from my initial post. Here is the result:


38
This reply is way late because I've been inundated with IRL issues as of late and have had zero free time for hobbies.

OK so you just want to replace the Hand icon above your head with something else ? As long as what you are trying to replace it with is in the same colour palette it should work but the .TIM you posted seems corrupt (at least no normal TIM viewer or editor will open it so i recommend you try editing the TIM with something else) so i cant really look at it but i spent 5mins trying a few things and i replaced the cursor above clouds head with the buster sword icon as shown in this picture

seems easy enough with a working TIM file, but with your TIM file it was really messed up.

I use Tile Molester because it allows me to specify which sub-palette I want to load from the CLUT.

I know there is an Adobe Photoshop plugin that can handle ".TIM" files, but I don't have Photoshop.

I do know that GIMP has a plugin that can handle ".TIM" files, but I am not too familiar with using GIMP. Is there a way to specify which sub-palette to load from the CLUT in GIMP?

39
Even if a tilemap program shows me the coordinates or what not, if I wanted to change the hand cursor in the future it would still be shifted over.

I'm guessing the shifting over is a side effect of the compression?

I'm starting to think that hacking the hand cursor might actually be impossible.

40
The issue is not the blue color. I want to leave the blue color in to see where exactly that cursor sprite is located.

The issue is that the cursor is shifted over to one side. You should notice that the right side of the hand cursor is cutoff, and that cutoff side carries over to the left side.

41
You mean alter the CLUT so that "blue" becomes transparency? If that's the case, then I would not be able to see the "box" where the hand is located. I am trying to determine the exact pixel locations of the hand cursor graphics. Another way of saying it is, I am trying to find the exact "coordinate range" where the cursor graphics are in the ".TIM" file. I figure that doing a "flood fill" around the hand cursors will let me see the exact "box" that it is contained in when it loads up in the game.

"Aooeatence"? Do you mean "appearance"? I've been told that "WINDOW.BIN" is where the cursor graphics are stored along with other UI elements, and the other two subfiles contain the whole font and width tables.

42
Okay, so I tried to make a ".ips" file (using Lunar IPS) that was supposed to repair this, but to no success.

A re-encoded "WINDOW.BIN" containing no changes somehow turns out to 13,187 bytes, but still seems to work in game as far as I know (I only got as far as getting off the train). CDMage pads out the difference with zeroes.

I decoded and re-encoded “WINDOW.BIN” with luksy’s program, to get the smaller yet functional version of that file.

Then, I made an “.ips” file that is supposed to restore the file to its normal state. The “.ips” file’s intent is to restore a smaller file back to its normal size.

“ORIGINAL UNMODIFIED” (target): Re-encoded “WINDOW.BIN”
“NEW MODIFIED” (containing desired changes): Original “WINDOW.BIN”

“WINDOW.BIN” just gets reverted to its original state after applying the patch, which is weird because the patch was only supposed contain the differences between the 2 files. My modifications should of remained, but that didn't happen.

I'd really like to solve this confusing problem.

UPDATE: I tried making the patch again, but with accounting for the padded zeroes that CDMage adds to the re-encoded file.

Same result as before.

43
I still haven't found a solution to this, but I thought I'd update the thread in the hopes that someone out there does know a solution.

The original “WINDOW.BIN” is 13,266 bytes. This “offset” version is 13,244 bytes. This is a 22 byte difference.

In the original version, the header entries are:
00 00 1F 8B 08
00 00 1F 8B 08
01 00 1F 8B 08

I made 2 edited versions. One has 22 bytes of 0s at the end of the first header. The other has 22 bytes of 0s before the second header--which is just adding zeroes to the end of the first compressed file.

The one with the 0s after the first header doesn’t even load after "Sony Computer Entertainment Presents". The one with the 0s before the second header end doesn’t load, either.

Some help in figuring this out would be appreciated.

44
Thanks to luksy, I was finally able to "edit" the PSX FF7 hand cursor, but not with total success.

I used Tile Molester to flood fill the area surrounding the field hand cursor (the one that points at the player's head), so I could see the box where the hand is located in.



Here is the ".TIM" file I modified:

https://www.mediafire.com/?a78wacii38dibir

I generated a new "WINDOW.BIN" using luksy's program.

The good part, the game no longer freezes (to my knowledge).

The bad part?



The hand cursors in the menu and field seem to be shifted. Also not seen in the picture, all the text is garbled in game.

What's going on? How do I go about fixing this? Has anyone else modified the PSX hand cursor before, or am I the first one?

Anyway, it's late and I gotta sleep soon.

45
I recommend you to insert the modified files using CD-Mage.
It will give you the option to "zero-padd" the free space in case the files you modified are smaller than the original files.
Use the "zero-padding" and the image should work fine.

I've been using CDmage this entire time, and the game still freezes if the file is padded out with zeroes.

46
I don't get to work on game hacking much with my busy schedule, but I attempted to solve this right now with psxinject (included with PSXImager V2.0), but to no results.

I recompressed as usual, then changed the headers for the smaller "WINDOW.BIN" that was generated.

My copy of Final Fantasy VII PSX was ripped with CloneCD per these instructions, and I get a ".img" ISO. (I own the discs, so this isn't piracy FYI.)

Code: [Select]
\psximager>psxinject ff7-1us.cue INIT/WINDOW.BIN edit_headers_after_e.bin
++ WARN: could not retrieve file info for `ff7-1us.bin': No such file or directory
++ WARN: init failed
Error opening input image "ff7-1us.cue", or image has wrong type

So I changed the ".img" extension to ".bin".

Code: [Select]
\psximager>psxinject ff7-1us.cue INIT/WINDOW.BIN edit_headers_after_e.bin
File 'INIT/WINDOW.BIN' replaced in "ff7-1us.bin"

Virtual CloneDrive cannot load the ".ccd" file, even after I change "ff7-1us.img" to "ff7-1us.bin" in the ".cue" file.

I just set Virtual CloneDrive to open "Other Images" instead of "CloneCD/DVD Images", and load "ff7-1us.bin".

I run pSX to load the game from the virtual drive.

Same failtastic result. The game freezes after "Sony Entertainment America Presents".

47
I'm right in assuming you have edited data?

Nope. The data is unedited. After recompressing, it still turns out smaller.

The only time I started to edit the data was when I got curious and tinkered with the headers.

48
Still exploring all my options here.

In the original version, the header entries are:
00 00 1F 8B 08
00 00 1F 8B 08
01 00 1F 8B 08

But after decompressing and recompressing, the entries in the newly generated file are:

00 00 1F 8B 08
01 00 1F 8B 08
02 00 1F 8B 08

I had an idea. Change modify the headers of the original file as thus:
00 00 1F 8B 08 -> 00 00 1F 8B 08
00 00 1F 8B 08 -> 01 00 1F 8B 08
01 00 1F 8B 08 -> 02 00 1F 8B 08

I intended to decompress, then recompress, then see what happens.

Decompressed, and got this output:

WINDOW.BIN0 (33 KB)
WINDOW.BIN1 (33 KB)
WINDOW.BIN2 (2 KB)

I attempted to recompress it, but the program crashes. But the program then changes files in the directory to:

WINDOW.BIN0.gz (10 KB)
WINDOW.BIN1 (33 KB)
WINDOW.BIN2 (2 KB)

I renamed those files to match what it was before (removed ".gz" from the first file), and tried to encode it again. I got the same results.

49
I checked the files it extracted now, "WINDOW.BIN0", "WINDOW.BIN1", "WINDOW.BIN2".

I recompress it with the appropriate command line, and I get a smaller file.

will create 3 files... the files that are part of window.bin.  You need to make changes -

If you are referring to the headers (like in that other thread), I cannot find any instance of "1F8B08" where I would change a header.

50
I followed the correct syntax as the program describes:

Code: [Select]
Syntax: ff7dec d file.bin

        decodes file.bin in file.bin0, file.bin1, file.bin2, etc etc

        ff7dec e file.bin

        encodes file.bin0, file.bin1, file.bin2, etc etc in file.bin

There is a text file, "Notes.txt", but "WINDOW.BIN" is not mentioned anywhere in that text file.

Pages: 1 [2] 3 4 5