| ムギ | Date: Tuesday, 2011-07-26, 6:16 PM | Message # 1 |
Rank: Nerdy Presence
Messages: 203
Reputation: 2
Status: Offline
| EDIT: im going to hold back releasing data about this one until I get my own project done.
sorry.
|
| |
| |
| ムギ | Date: Sunday, 2013-05-12, 2:35 PM | Message # 2 |
Rank: Nerdy Presence
Messages: 203
Reputation: 2
Status: Offline
| im releasing these tools since my own translation of this game died along with my translator vanishing into thin air.
ExRebTHFS, contains 2 php scripts and a set of bat files for easy use.
the php install directory in bats is set to "C:\Program Files\php",
if you use a different folder, edit bat files accordingly.
usage:
copy thfs files into same folder with php and bat files, run a bat to extract archive.
for rebuild, make sure to have a file.thfs.original file in the same folder,
it is required to copy unknown bytes for file table.
tool is coded by lmz, based on my reverse data of the thfs container, it is able to handle the file extraction,
rebuilding and zlib compression management. everything needed to more or less fully edit the game.
game's event scripts are plain txt files, notepad is sufficient for editing.
for graphics files, use gimconv or equivalent, to convert .gim graphics to .png and vise versa.
.
|
| |
| |
| ムギ | Date: Friday, 2013-09-20, 11:10 PM | Message # 3 |
Rank: Nerdy Presence
Messages: 203
Reputation: 2
Status: Offline
| the tools on the above post are a little dated, so i figured i'll write up something about this game while im at it.
so all in all, the game uses the same THFS filesystem as the first game of the series does. (structure here: http://mce.do.am/forum/25-19-1)
i've been poking at this engine in an attempt to utilize it for my projects, and so far it's progressing rather smoothly. There's pretty much one thing i dont know about it currently, but i'll get on to that sometime too, in the meantime, here's the full inner workings of it.
the THFS file structure.
--Header:
0x00: THFS file signature (4 Bytes || 5448 4653)
0x04: File size (4 Bytes)
0x08: Number of files (4 Bytes)
0x0c: blank (0000 0000)
--Data starts at 0x10, Each file entry is 0x40 in size:
0x10: File indexing string (8 Bytes)
0x18: Filename (28 Bytes) *padded with zeroes*
0x40: File Start address (4 Bytes)
0x44: Filesize -compressed- (4 Bytes)
0x48: Compression flag (4 Bytes) *it's either 0100 0000 or 0000 0000 for enable/disable*
0x4c: Filesize -uncompressed- (4 Bytes)
** If compression is disabled, both size indicators have the same value.
** Compression used is zLib (file signature, 789C)
Thats about it for the THFS. No unknown bytes left.
edit: on a side note, while you dont actually need to edit the indexing strings when attempting a translation or whatnot, i dug a little deeper into it and it seems to be some form of hash falue of the filename.
you can load files from the event scripts based on the hash values alone, and the actual filenames presented in the THFS table bear no meaning whatsoever.
i've yet to figure out how to generate them though :P
------------------------------------------------------------
*dat files inside BMP.THFS
These small files are image layout data configurations.
If you examine the game's main script, you'll occasionally run into lines that call these configs, such as "bmp.overlap title_bg". This line is found from title.txt which is the main menu script. What it does is call the title_bg.dat from BMP.THFS.
we'll be examining this file as i attempt to explain to you how it works.
keep in mind that these are binary files, and editing them with notepad or a text editor will just break them.
--here's what title_bg.dat looks like in hex editor:
0x00: 0004 01E0 0110 1A91 017A 576C 7336 0000
0x10: 0000 0000 0000 0001 0001 C7DB 5173 2E05
0x20: D082 0001 0000 0000 0000 E000 0001 32C9
0x30: 9CA0 AB8D 25C5 0000 0001 0000 B400 0001
0x40: 1000 32C9 9CA0 AB8D 25C5 0001 0001 0000
0x50: C600 E000 1000
Different segments of the hex are color coded to make it easier to read.
Lets break it down a little:
RED
0x00: number of entries (plain HEX)
0x02: area size X (plain HEX)
0x04: area size Y (plain HEX)
this is the first segment that defines the number of entries in the file and the screen draw area size.
note that these bytes are PLAIN so DO NOT flip them in hex editor.
number of files 0004 stands for 4 entries.
size X 1E0 stands for x size (1E0 HEX = 480 in Decimal)
size Y 110 stands for y size (110 HEX = 272 in Decimal)
GREEN
these are simply a 8-Byte string that stands for source image indexing value (see THFS container structure above for it.) These configs call the source images by the indexing number instead of filename.
Followed by the indexing number is the addresses to draw. its 0x0c (12) bytes and 6 values, so 2 Bytes per value, These are not Plain unlike the start of the file, so remember to flip these to get real numbers.
lets take a look at the first ones:
0000 0000 0000 0000 0001 0001
now lets flip them:
0000 0000 0000 0000 0100 0100
lets change them to Decimal:
0, 0, 0, 0, 256, 256
the values decode as follows:
first 2 are the X/Y coordinates where the source image will be pasted to on the screen.
second 2 values are the X/Y coordinates of the start location of the area to display.
third 2 values are the X/Y size of the displayed area of the source image.
what this means is that the image with index 1A91 017A 576C 7336 is layed on 0,0 of source screen, the visible area of the source image starts from 0,0 and the size of the visible area is 256x256 pixels. This is the left half of the main menu background.
second set of parameters follows this same pattern:
image with an index value of C7DB 5173 2E05 D082 is layed on 256, 0 of source screen,
the visible area of the source image starts from 0,0
and the size of the visible area is 224x256 pixels. This is the right side of the main menu background.
when you look at the hex of the source .dat file, you'll notice that the last 2 green index values are the same.
since psp's screen is 480x272 in size, and the images in this game are built out of 256x256 pixel tiles, after laying 2 tiles, we have a 16 pixel blank at the bottom. The last 2 strings are present to load the additional pieces from another menu source file, that contains the bottom of the menu background along with few other menu graphics. (see below for the actual file.)
the game has several things hardcoded that i didnt really bother looking at since they're more or less irrelevant, such as the code that makes the "press start button" button blink. Or the position of the main menu.
You should be able to move them around with the .dat files but the initial values are propably hardcoded int othe executable.
|
| |
| |
