Sponsored Links

Sponsored Links

Page 52 of 80 FirstFirst ... 242505152535462 ... LastLast
Results 511 to 520 of 793



  1. #511
    Senior Member Tidusnake666's Avatar
    Join Date
    Sep 2008
    Posts
    802
    Sponsored Links
    Sponsored Links
    Currently, I'm working on eboot dissassembling with IDA and xorloser's plugins.

    Also, I made a program which automaticaly translates (Microsoft Translator API) blocks of japanese text to english and corrects byte-size (if output english file is bigger, it truncates it, if smaller - adds spaces). Maximum chunk size - 70 KB at once. Speed is also decent. If it'll help Alexmagno, I'll release it.

  2. #512
    Senior Member Alexmagno's Avatar
    Join Date
    Sep 2011
    Posts
    73
    Sponsored Links
    Sponsored Links
    Nah don't bother Tidus, i'll finish the tranlation manually. After the revision, we can start thinking about how to reinsert it.

    On that note, sorry for taking so long, it's just that i had A LOT of work during these last weeks.

    Thankfully, i'll be able to catch a little break to resume the work this week.

  3. #513
    Contributor zoidran's Avatar
    Join Date
    Jan 2011
    Posts
    7
    Sponsored Links
    Sponsored Links
    Thanks for your work!

    Alexmango: BTW, you posted a message on XeNTaX, right? I left you a PM there.

  4. #514
    Registered User asdfen's Avatar
    Join Date
    Oct 2011
    Posts
    3
    thank you guys.. quick question is there currently a way to somehow understand whats going on in cutscenses? I've patched the sound and replaced all the files mentioned with US equivalents but I have no idea whats up in cut scenes.

  5. #515
    Senior Member Tidusnake666's Avatar
    Join Date
    Sep 2008
    Posts
    802
    just listen up carefully. Dialogues are not messed up, they are just going forward wneh picture is lagging.
    One or two cutscenes and you get the idea. It'll be more-or-less fixed in nearest release (beta), but it's the best we can do for you to understand he plot for now.

    Also, dissassembling eboot in IDA gave 0-result, I'm totaly unfamilliar with PPC mnemonics, although I've managed to dig into some algos, searching for message loading procedure is an overkill. Moreover, because the string table is at the end of file (and not near corresponding call-function like in almost every x86 Windows executable), it only adds difficulty

  6. #516
    Senior Member Alexmagno's Avatar
    Join Date
    Sep 2011
    Posts
    73

    talk.dat / font.lzs file

    A friend of mine, who'd rather remain unknown, helped me quite a lot on insight regarding those 2 files.

    He said, and i quote: I think I've figured out a somewhat-clumsy-yet-efficient solution to the "square glyph" problem, which is responsible for the letter repetition when using half-width characters in the dialogue lines. I don't know what you've figured out and what you didn't, so I'll explain things from the beginning. Please be patient with me even if you know most or all of what follows. I only mean to be of assistance.

    I've read in the first post of the "Disgaea 4 PS3 Translation / Fix Project WIP" thread at PS3 News that the square glyph issue is an encoding related problem, resulting of the fact that SJIS has 2 bytes per character for most of the characters. I think that's not quite it -- it is more of a rendering problem. In the dialogues, all glyphs are rendered as squares. And since half-width characters have smaller textures, they just "warp around". On the other hand, encoding is respected since all of the characters of an ASCII string are printed. One would expect one letter skipped out of two if the game where not "encoding aware enough".

    I think it would be very difficult to solve this problem through disassembling and modifying the "EBOOT.BIN" file, because the buffer used to store the dialogue text is likely too small. The "bugs" one can observe by using the US "talk.dat" with the Japanese version are probably due to buffer overruns. So even if one managed to halve the character width, the maximum number of displayed characters would stay the same. Unless of course the size of the buffer is increased. All in all, this seems very difficult to do to me.

    So I propose another solution: overwriting the glyphs found in the "font.lzs" file so as to substitute some of the characters (e.g., the kanjis) with letter pairs. For instance, the first kanji of the font file is "亜", which could be substituted by a square glyph representing the letter pair "Th". The next kanji would be replaced by "e ", then "fr", "es", "h ", and so on, in order to display on the screen "The fresh, dripping blood...", which is Valvatorez's first line. Of course, those same pairs could be reused later, should they appear in other dialogues. According to my estimations, the font file is big enough to contain all the pairs needed. Were it not, it could still be resized (but adding extra glyphs would also require to modify "font.ffm", which would make things more complicated).

    I'll move to the technical aspects. Such a hack would require to understand the formats of the ".lzs", ".txf" and "talk.dat" files. Here is the information I could gather:

    + LZS is an already well understood format. See this page: www.cetramod.it/forum/viewtopic.php?f=52&t=266. I don't understand Italian, so I don't really know who to credit for the information (the author of the post?), but in summary it is a 254-bytes sliding-window compression scheme. To be specific:

    - bytes 0x0 to 0x2: the expected extension of the decompressed file; should be "txf" for "font.lzs"
    - byte 0x3: should be '\0'
    - bytes 0x4 to 0x7 (little endian uint32): decompressed file size
    - bytes 0x8 to 0xb (little endian uint32): (compressed file size) - 4
    - bytes 0xc to 0xf (little endian uint32): flag value; must be less than 255, which means that bytes 0xd to 0xf are always "\0\0\0"
    - the rest is compressed data; to decompress it, all the characters are to be copied as is except the flag byte which indicates a match, and is followed by the distance/length pair (unless it is followed by another flag byte, in which case a single byte with the flag value should be added to the uncompressed data); the distance and length are one uint8 each; the distance is given from the current position, and should be substracted 1 if it is greater than the flag (to account for the two-consecutive-flags special case); see for instance LZ77 on Wikipedia if you're not familiar with such compression methods

    + TXF is a very simple bitmap format:
    - bytes 0x0 to 0xf are the header; the big-endian-encoded uint16 at offsets 0x4 and 0x6 are the image width and height, respectively; it is 10242272 for "font.txf"
    - the rest is pixel data in the usual scanline order; when it comes to the "font.txf" file, there are two channels: the first is alpha and the other is value, I guess (it is worth 0xff for all the pixels)

    + "talk.dat" has the following structure:
    - bytes 0x0 to 0x3 (big endian): the number of conversations (?)
    - bytes 0x4 to 0x7 (big endian): should be the same as bytes 0x0 to 0x3
    - following 56(number of conversations) bytes: an array of conversation (?) structures; the first 4 bytes of each element (big endian) are the offset of the conversation start in the conversation data, in bytes (so if it is n, the conversation starts at n+8+56(number of conversations) from the beginning of the file)
    - the rest is conversation data; in particular, spoken lines begin with '\1' and end with '\0' (but of course, not all the '\1' indicate the beginning of a spoken line)

    That's basically it. I've also got some very basic understanding of "font.ffm", but normally one should not need to mess with it. It is necessary to associate the glyph position in the "font.txf" bitmap with its SJIS byte sequence. The kanji table given below should be enough. Ask me I you really need to know.

    Some kanjis of "font.lzs", in order (starting from glyph 486):
    Code:
    亜唖阿哀愛挨逢葵悪握圧扱宛姐綾安暗案
    闇以伊位依偉囲委..尉意慰易椅為畏異移維緯胃萎衣違遺医井域育磯一壱溢逸稲茨
    芋鰯允印員因姻引飲淫院陰隠右宇烏羽迂雨鵜丑臼渦嘘姥浦瓜噂運雲餌叡営影映栄
    永泳瑛英衛詠鋭液疫益駅悦謁越閲厭円園宴延怨援沿演炎焔煙燕猿縁艶遠鉛塩汚凹
    央奥往応押旺横殴王黄岡沖荻億屋憶臆牡乙俺恩温穏音下化仮何価佳加可嘉夏嫁家
    寡科暇果架歌河火禍稼箇花苛茄荷華菓課嘩貨迦過霞我牙画芽蛾賀雅餓駕介会解回
    塊壊廻快怪悔恢懐戒拐改魁械海灰界皆絵開階貝凱外咳害崖概涯蓋街該鎧骸垣嚇各
    拡格核殻獲確穫覚角較閣隔革学岳楽額顎掛笠樫割喝恰括活渇滑葛轄叶鞄株兜蒲釜
    鎌噛刈瓦乾冠寒刊勘勧巻喚..姦完官寛干幹患感慣換敢棺歓汗漢環甘監看竿管簡緩
    スw肝艦観貫還鑑間関陥韓館丸含岸巌玩眼岩頑顔願企伎危喜器基奇嬉寄岐希幾忌揮
    机旗既期棋棄機帰毅気祈季稀紀規記貴起軌輝飢騎鬼亀偽儀宜戯技擬欺犠疑義蟻議
    菊吉喫詰却客脚虐逆丘久仇休及吸宮弓急救朽求汲泣球究窮級給旧牛去居巨拒拠挙
    虚許距漁魚京供競共凶協叫境強怯恐挟教橋況狂狭矯胸脅興郷鏡響饗驚仰凝暁業局
    曲極玉桐勤均巾錦琴禁禽筋緊菌謹近金吟銀九倶句区狗苦駆駒具愚喰空偶遇隅串屑
    屈掘窟靴熊栗繰勲君薫訓群軍卦袈係傾刑兄啓圭型契形径恵慶慧憩掲携敬景渓稽系
    経継繋蛍計警軽鶏芸迎劇戟撃激隙桁..欠決潔穴結血訣月件健兼券剣喧圏堅嫌建憲
    懸拳検権犬献研県肩見謙賢軒遣鍵険顕験鹸元原厳幻弦減源玄現舷言限個古呼固姑
    孤己庫弧戸故枯湖狐股胡虎誇雇顧鼓五互伍午吾娯後御悟檎語誤護醐乞鯉交侯候光
    公功効厚口向喉垢好孔孝宏工巧幸広康弘恒慌抗拘控攻晃更杭校構江浩港甲皇硬紅
    絞綱耕考肯膏航荒行講貢購郊鉱鋼降項香高鴻剛劫号合拷豪轟克刻告国酷黒獄腰惚
    骨込此頃今困坤婚恨懇昏昆根混痕紺魂些佐叉左差査沙砂詐鎖裟座挫催再最塞妻彩
    才採栽歳済災采砕砦祭斎細菜裁載際剤在材罪財冴坂阪咲崎作削昨窄策索錯桜冊刷
    察拶撮擦札殺雑捌錆皿晒三傘参山惨撒散産算..賛酸餐斬暫残仕仔使刺司史四士始
    姉姿子屍市師志思指支施旨枝止死氏獅祉私糸紙紫肢脂至視詞詩試誌資賜雌飼歯事
    似侍児字寺慈持時次滋治磁示耳自蒔辞鹿式識軸雫七叱執失嫉室湿漆疾質実篠芝舎
    写射捨赦斜煮社者謝車遮蛇邪借杓灼爵釈錫若寂弱惹主取守手殊狩珠種趣酒首受呪
    寿授樹需囚収周宗就州修愁拾秀秋終繍習臭蒐衆襲讐蹴週酬集醜住充十従柔汁渋獣
    縦重銃宿淑祝縮粛塾熟出術述俊峻春瞬駿循旬楯殉淳準潤盾純巡醇順処初所暑庶緒
    書諸助女序徐除傷償勝匠召哨商唱奨宵将小少尚庄床彰承招掌捷昇昌晶松梢沼消渉
    焼焦照症省硝礁祥称章笑粧紹肖衝証詳象賞醤鍾鐘障上..乗冗剰城場嬢常情条杖浄
    状畳穣蒸譲醸錠飾拭植殖織職色触食蝕辱尻伸信侵唇娠寝審心慎振新晋森浸深申真
    神紳臣薪親診身辛進針震人仁刃塵尋甚尽迅陣靭須酢図厨吹垂推水炊睡粋衰遂酔随
    髄崇数枢雛据杉澄摺寸世瀬是凄制勢征性成政整星晴棲正清牲生盛精聖声製西誠誓
    請逝醒青静斉税脆席惜戚斥昔析石積籍績責赤跡切拙接摂折設節説雪絶舌蝉仙先千
    占宣専尖川戦扇栓泉浅洗染潜旋穿線羨船薦詮選遷銭閃鮮前善然全繕膳噌措狙疎礎
    祖粗素組蘇訴阻僧創双叢倉喪壮奏爽層想捜掃挿掻操早曹巣槍燥争痩相窓総聡草荘
    葬蒼藻装走送遭霜騒像増憎臓蔵贈造促側則即息捉束測足速俗属..族続卒袖其揃存
    孫尊損村遜他多太汰堕妥惰打舵陀駄体対耐帯待怠態戴替泰滞袋貸退逮隊鯛代台大
    第醍題鷹滝卓宅択拓沢濯琢託濁諾茸只叩達奪脱竪辿棚谷樽誰丹単嘆担探旦淡炭短
    端耽胆誕鍛団壇弾断暖段男談値知地恥智池痴稚置致蜘遅馳築畜竹蓄逐秩茶着中仲
    宙忠抽昼柱注虫駐猪著貯丁兆喋帖帳庁弔張彫徴懲挑朝潮町眺聴腸蝶調諜超跳長頂
    鳥直沈珍賃鎮津墜槌追痛通塚掴漬椿潰壷爪吊釣鶴亭低停偵剃貞呈定帝底庭廷弟抵
    挺提程締訂諦蹄邸釘泥摘擢敵滴的笛適溺哲徹撤鉄典填天展店添纏貼転点伝殿田電
    兎吐塗妬屠徒斗渡登賭途都努度土奴怒倒党冬凍刀唐塔套島嶋悼投搭東桃..盗淘湯
    涛灯燈当等答筒糖統到董藤討豆踏逃透陶頭騰闘働動同堂導憧洞瞳童胴道銅峠匿得
    徳涜特督篤毒独読凸突届屯沌豚頓呑曇鈍奈那内薙謎捺鍋馴縄南軟難汝二弐匂肉虹
    日乳入如尿任妊忍認濡寧猫熱年念捻燃粘乃之悩濃納能脳膿農覗巴把播覇波派破婆
    罵馬俳廃拝排敗杯盃背肺輩配倍培媒梅買売賠這萩伯剥博拍泊白箔薄迫漠爆縛莫麦
    箱箸肌畑八鉢発髪伐罰抜閥伴判半反帆板氾汎版犯班繁般販範煩飯挽晩番盤蛮卑否
    妃庇彼悲扉披斐比疲皮碑秘緋肥被費避非飛備尾微眉美鼻匹彦膝肘必筆逼姫紐百ス{
    標氷漂票表評豹描病秒苗鋲品浜瀕貧賓頻敏瓶不付夫婦富冨布府怖敷斧普浮父符腐
    ..譜負赴阜附侮撫武舞部封風伏副復幅服福腹複覆淵払沸仏物分吻噴憤焚奮粉紛雰
    文聞併兵幣平弊柄並蔽閉陛米僻壁癖別蔑偏変片編辺返便勉弁保舗捕歩補穂募墓慕
    暮母簿包呆報奉宝峰崩抱捧放方法泡砲縫胞芳萌蜂褒訪豊飽鳳乏亡傍剖坊妨帽忘忙
    房暴望某棒冒紡肪膨謀貌防吠頬北僕墨撲朴牧勃没堀奔本翻凡盆摩磨魔麻埋妹昧枚
    毎幕膜枕又抹末繭万慢満漫蔓味未魅巳密蜜脈妙民眠務夢無矛霧婿娘冥名命明盟迷
    銘鳴滅免綿面麺模茂妄毛猛盲網耗蒙儲木黙目戻貰問悶紋門也冶夜爺野弥矢厄役約
    薬訳躍柳愉油癒輸唯優勇友幽悠憂有湧涌猶由祐裕誘遊郵雄融夕予余与誉預傭幼妖
    容揚揺擁..様洋溶用羊葉要踊遥陽養抑欲浴翌翼淀羅螺裸来頼雷絡落乱卵嵐欄濫覧
    利履李梨理璃裏里離陸律率立略流溜留粒隆竜龍侶慮旅虜了亮僚両凌料梁涼猟療瞭
    糧良遼量領力緑林臨輪隣鱗麟瑠塁涙累類令例冷励礼鈴隷零霊麗齢暦歴列劣烈裂廉
    恋憐煉練蓮連錬呂炉賂路露労廊弄朗楼浪漏牢狼篭老郎六禄録論倭和話歪賄脇
    With some more dedicated programming, we could actually make the whole game text translated. I'll look into it after i'm done dumping/translating the eboot, but if anyone is interested/able to do something with this info, by all means, go for it.

  7. #517
    Senior Member Tidusnake666's Avatar
    Join Date
    Sep 2008
    Posts
    802
    Wow! OMFG! I had some vague thoughts about this file containing glyphs info, but I've never thought, it could be possibly edited to achieve such goal. The post is awesome and perfectly clear to me. I have some idea of the algorithm, maybe I'll work out when I'll have free time.

    Just one question, to assure I've read it right,

    Some kanjis of "font.lzs", in order (starting from glyph 486):
    means, this is the text inside txf-file, I mean, "inside" bitmap?

  8. #518
    Senior Member Alexmagno's Avatar
    Join Date
    Sep 2011
    Posts
    73
    yep.

  9. #519
    Senior Member Tidusnake666's Avatar
    Join Date
    Sep 2008
    Posts
    802
    I've drafted some quick algo for this process, but have problem with unpacking LZS. I know it's preety basic compression methof, and I had written some packers myself ages ago, but now it just don't work out

    If someone would supply me with unpacked txf ot (better) Kanji glyph full dump (as in previous message "Code" section), that would be awesome.

    Also, what should we do, if the number of chars in sentence (message) is odd? Should we add more bytes and reconstruct the whole message system?

    Moreover, japanese talk.dat has more conversation messages than US. It was obvious, since there are more japanese sound files for dialogues
    Last edited by Tidusnake666; 10-20-2011 at 05:03 AM Reason: Automerged Doublepost

  10. #520
    Senior Member Alexmagno's Avatar
    Join Date
    Sep 2011
    Posts
    73
    My friend would like to add: "I have probably not been clear enough when discussing the LZS file format, earlier. Here a few hints to decompress the "font.lzs" file:

    + the correct MD5 for the decompressed "font.txf" file is "bb0ba777897592907c95ba6aac750407"

    + its header (first 16 bytes) is "0c 01 01 01 04 00 08 e0 00 01 00 00 00 47 00 00"

    Here is the code, if you feel like using it:
    Code:
    #!/usr/bin/perl
    
    use strict;
    
    if ((scalar @ARGV) != 2) {
            print "Usage: d4unlzs SRC.lzs DEST\n";
            exit(1);
    }
    
    my $infile;
    my $outfile;
    
    if (!open($infile, "<$ARGV[0]")) {
            print "Error: cannot open input file.\n";
            exit(1);
    }
    
    binmode ($infile);
    
    my $dest_size;
    my $src_size;
    my $flag;
    
    # Parsing 16-byte header:
    # ----------------------
    
    sub readU32Le {
            my $c;
            my $rv = 0;
            read($infile, $c, 1); $rv += ord($c);
            read($infile, $c, 1); $rv += ord($c) * 256;
            read($infile, $c, 1); $rv += ord($c) * 256 * 256;
            read($infile, $c, 1); $rv += ord($c) * 256 * 256 * 256;
            return $rv;
    }
    
    &readU32Le; # Extension and unused byte -- safe to ignore
    $dest_size = &readU32Le; # Uncompressed size
    $src_size = &readU32Le; # Compressed size (file size - 4 bytes)
    $flag = &readU32Le; # Flag
    
    if ($flag > 255) {
            print "Error: flag not valid. Bad LZS file?\n";
            exit(1);
    }
    
    # Opening output file:
    # -------------------
    
    if (!open($outfile, ">$ARGV[1]")) {
            print "Error: cannot open output file.\n";
            exit(1);
    }
    
    binmode ($outfile);
    
    # Uncompression loop:
    # ------------------
    
    my $pos = 0;
    my $c;
    my $val;
    my @dest = ();
    for (my $i = 0; $i < ($src_size - 12); ++$i) {
            read($infile, $c, 1) or die "File too short!\n";
            $val = ord($c);
            if ($val == $flag) {
                    read($infile, $c, 1) or die "File too short!\n";
                    $val = ord($c);
                    $i++;
                    if ($val == $flag) {
                            push @dest, $val;
                    } else {
                            my $jump = $val;
                            my $n_copied;
                            $jump-- if ($jump > $flag);
                            read($infile, $c, 1) or die "File too short!\n";
                            $n_copied = ord($c);
                            $i++;
                            for (my $j = 0; $j < $n_copied; ++$j) {
                                    my $idx = (scalar @dest) - $jump;
                                    push @dest, $dest[$idx];
                            }
                    }
            } else {
                    push @dest, $val;
            }
    }
    
    # Writing output file:
    # -------------------
    
    foreach (@dest) {
            print $outfile pack('C', $_);
    }
    And to answer Tidus' question: for lines containing and odd-number of characters, adding a space after the last character seems to work well enough."

 

Sponsored Links
Page 52 of 80 FirstFirst ... 242505152535462 ... LastLast
Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News