コメントありがとうございます♪
ラジオ中継を聞いていてもレアなはずのやけくそチャンテ、なぜ両球団の応援団はよく使うのでしょうかね…連敗中…大差の終盤…暗黒期…あっ（察し）※ファンが元気なのはいいことです！
本日から試合中止がなければ神宮に赴く予定でいますが、天気は微妙。そして、もしかすると成瀬だけでなくわくわくさの登板日にも見に行けるかもとの情報を掴み、わくわくしていますので今日はブログ日和とみて改造ネタをちょっと書いてみます。
なぜ、SYMなのか？ということです
ツール作れやゴルァ！とか、せめてテキストコンバーターにしてほしいぉとか、そういう声があるのは知っていますが、ぶっちゃけ中身がよくわからんものについてツール作るよりは解析段階で構築するSYMを使うほうが早いし確実です。
SYMというのはTSXBINというシンボル表示が優秀すぎるバイナリエディタ用に作ったシンボル表示スクリプト（マクロ）ファイルのことです。
基本的にはC言語で作られており、表示用の命令さえマスターすれば色んなことができるテキストファイルなのです。
そう、ここが重要！
もしお暇でしたらSYMファイルをテキストエディタで開いて中身を読んでみてください。
シンボル表示にしたときに表示されるラベル（シンボル）名をいじるだけなら超簡単です。
ラベルに細工をしてマスクされたName部分をテキスト表示させてみたSYMも幾つかありますので、まずはそこからいじってみるのもいいでしょう。
解析段階のデータに正しい名前をつけるのは現実的ではありませんので、実際にデータを見て編集する方が解りやすい名前をつけなおす、SYMだからこそソレが簡単にできるのです。
また、バージョンアップや未知のバージョンなどSYMが対応していない形式に出会ったときもif文やswitch文を使うことで対応、または独自のSYMを作って解析することもできるでしょう。
また、SYMを使ってデータの加工をすることもできます。
圧縮データの展開や暗号解除などを組み込み、元のデータを加工し、別名で保存する。あるいはマクロファイルで二重に処理をする。
ここまで来るとツールになってる感じもしますよね。
TSXBINを使いこなし、SYMを自由に書き換えることができるなら、もうハッカーの入り口へ辿り着いたも同然ですね！
また、SYM内のコメントにも重要と思われるメモを残していますので、全体の構造を知る上でも、SYMファイルの中身を一度じっくり読んでみるのもいいんじゃないかなーなんて思うのです。
C言語なんてわかんないお！という方も、基礎の基礎はかじっておいて損はないでしょう。
数学の教科書を開くと、プログラミングっぽいものもあるように、今や常識になりつつある「情報処理」、そんなに難しく考える必要はありません。
例えば数値の単位intやchar、浮動小数点float、このあたりはマクロヘルプに掲載されているものを参照してください。
例えばif～else文やswitch文で条件分岐、for文またはwhile文でループ、break-return-continueで脱出し…と基礎知識があれば、eyesなどの短いSYMくらいならおおよその構成がわかるはずです。
ちょっと難しい部分があるとすれば構造体？structのコンテナ構造や[]配列、既知の類似データを複数まとめて処理するのに使います。
例えばMatrixの場合はxyzwの二次元配列（縦横各４つ）をひとつの構造体として登録しています。
入れ子構造として、構造体を構造体のなかに組み込むこともできます。
ただし、イリュージョンのName部分のように固定長データでないものを含む場合は構造体として記述できない仕様（SYMの）なので注意してください。
構造体の内部にある名称も自由に書き換えることができます。
注意したいことは、同じ名前を複数箇所で使っている場合、最初に使ったものの値を参照している可能性があります。
なので、リネームするときは検索コマンドを使って既存の名前と重複していないことを確認、置換コマンドを使ってすべてをリネーム、のような慎重さもときには必要です。
この界隈で特に重宝されているSYMファイル、あんなファイルやこんなファイルも構造が分かっていた！？そりゃ見るっきゃない、触るっきゃないでしょう！
当面の目標として、３D表示に関する部分とか色々あるんですが、９月のイベントを区切りとして色々やっていきたいな～という感じに予定しています。
バグ報告とか機能追加要望とかまあ、するだけならタダですのでどんどんしてもらって構いません。
でも当面はUnity以外のファイルをいじっていくつもりなので新作はパスで。旧作のコンバーター、モーフ、モーションあたりを中心に開発できたらいいなっとぼんやり思っていたりするのですが、今はお絵描きのほうとやきうかな～あ、あと部屋の掃除wゆっくりまったり、スローリーではありますが、どうぞよろしく♪
たぶん次回はやきう記事だねwでも、エロゲも買うよ！ノシ
- 2015/05/19(火) 10:01:57|
- 改造
-
| トラックバック:0
-
| コメント:0
ひさびさにPCからブログ更新でつ。HPのほう放置してるのだけど、まあこっちでも報告くらいはできるってことで。
・どりふ fpkDecrypt
昔のイリュのパッケージを開けたり中身いじって再梱包したりします
TBLつきのFPK、最古のPP（base.ppとか）、TBLつきのPPに対応
対応してないのは最近のPP（PPVER形式の鍵つきPPね・・・あれどうなってんだろ？）
一部の暗号化されたFPKはPPと同じなのでPPにリネームすると読めるようになります
めんどいのでそのへんは各自で対応してくださいすまんこ
TBLの圧縮には対応してないので、再梱包するとでっかくなっちゃった！でも正常です
そのうちXファイルとXANファイルからXXとかXAにコンバートしたいとか考えてます
・CE ２０１５GWパッチ
黄金週間は終わったとかハハの日とかまあ、細けえことはいいんだよ！
かねてから要望のあったｂｐｓEditor（編集できるとはいってない）をちょっと更新
こっちのEXEを差し替えて（追加して）使うことでJG2の表示できなかったbpsの構造を見れたりするゾ
表示できてたものが表示できない場合は、元に戻して、どうぞ（どっちも無理？ならファイル教えてホッシーゾ☆）
あいかわらずよくわかんないので、編集はSYMでやって、どうぞ
とかそういう投げっぱなしになってるけどイベント案内が来たので９月までには何か作れるように頑張る模様
でもエロゲーが足りてないので次のヤク戦にあわせて補給の旅に出ます☆今から交流戦が楽しみなんじゃ～＾＾
- 2015/05/10(日) 01:32:27|
- 改造
-
| トラックバック:0
-
| コメント:0
徹夜でツールいじってたお！
コナンの映画TV放映楽しみでつ。
くりますす？ピッツァならもう買いました！
そんなかんじでねぼけたまま記事かいてむる。誤字も愛嬌！
TBLとPPのかんけい
これ、もしかしてと思ってTBLEditorを確認したらありました詳しい説明！
やっぱりTBLはPPのファイル名、サイズ、位置情報が入ってたんです。
そしてふしぎなのはPPに生データ入れててTBLに辞書式圧縮掛けて更に暗号化（XOR）までしてるっちゅー念の入れよう。
やっぱ衣装追加ディスクとかで一儲け狙ってたんですかねぇ。
圧縮するなら画像データとかアニメとかスッカスカなのに放置だし。いや、XAのPPだけ圧縮とかもしてましたっけ。
すべては過去の遺物なのだ…
そう、すべてを過去の暗黒へと葬り去るべく「むす…はっp…ハーレムめいとが来るんですよぉ～！
そうです
人工２のファイル構造が一番めんどかったと抜かした方、いらっしゃいましたけどTBLは全げーむ共通らしいっす。
尾行３？そうA-GAもね。
改造したい！そう多くの人が望まないようなげーむは見向きもされず解析もされずただ朽ちるのみよ…
ということで刻の涙をちょちょぎらせながら、冷える指先をサスサスしながら、今夜もまたTBLとの戦いをやるってんだよぉー！
すいませんマジムズいっす堪忍してぇ～！
そうそうPPはずっと使い回しの形式らしく、base.ppとかw.ppの中身は同じ暗号化（）でした。
うん…素人にも分かるから暗号解析の初心者はクイズがてらやってみるといいっすよ。
あとはPPVERなPPの構造もおおよそ分かってるらしいんで、今後は遠慮なしに改造三昧できるんじゃないかしら。
圧縮とか展開とかうわーもーって頭のなか満開しちゃってますSUN華しちゃってますうわーいヘ(゜ο°;)ノ…
PP展開してたらイリュ…ゴミふぁいる混ざってんよーw
世の中には体験版が製品版になってしまうようなミラクルオウンゴールもたびたびでてますし☆ミねっ！
あーはらぁへったな…ぼくもうねむいんだ…（フラグを立てれば大丈夫ぅぇ～ぃw
ビット演算子「＆」がいっぴービット演算子「＞＞」がにぴービット演算子「＾」がさんp
- 2014/12/06(土) 17:36:14|
- 改造
-
| トラックバック:0
-
| コメント:4
イリュゲーのみならず、エロゲはＤｉｒｅｃｔＸを使ったプログラムがほとんどです（なんと、２Ｄでも！）
ということで、ＤｉｒｅｃｔＸな３Ｄについてのおさらいなど、つらつら～とメモっていきます。
なんでここでやるのかって？・・・そりゃ、こういうのやるとウケが悪いでしょｗ
ＰＮＧ汎用画像形式。Ｚｉｐと同じ圧縮形式で、ライセンスフリー！
ＩＥＮＤチャンク以降は独自データを追加することができる。
イリュゲーではＰＮＧ形式でポーズやシーンのセーブをすることがある。
＜画像ＰＮＧ～ＩＥＮＤ＞＋＜イリュ独自データ＞＋＜独自データのサイズ：４ＢｙｔｅＵＩｎｔ＞
きゃらコレの場合、簡単に構造を書くとこんなかんじになる。
独自データの中身はゲームによりけりだが、ＰＮＧっぽい書き方の箇所もある。
ＰＮＧ部分はＢｉｇＥｎｄｉａｎだけど、イリュはいつも通りＬｉｔｔｌｅＥｎｄｉａｎです。
ＰＮＧの中のブロックをチャンクといい、形式が決まってるんだけども、
＜サイズ＞＋＜４文字の識別子＞＋＜データ＞＋＜ＣＲＣ／チェックサム＞
仕様書に従って作るチャンクはこんな感じの構造なのです。
イリュの独自データはちょっと違うんだなぁ。
＜ＵＩｎｔ／チャンク先頭のチェック用固定値＞＋＜２文字の識別子＞＋＜データ＞
ということなので、ＩＥＮＤなＣＲＣの次に来る固定値＋識別子を検索すれば解析しやすいってことね。
イリュはもっと圧縮画像を使うべきだと思うんだ・・・なんでＢＭＰなんすかー！？
ＵｎｋｎｏｗｎＨｅｘってなによ？
わけわからんデータ、ではあるんやけども、それが何に影響してるのか分からんだけで、
そのバイナリがどういうデータなのか？というのは
（暗号化でもされてない限り）だいたい分かるので、ＴＳＸＢＩＮなんかに打ち込んで見てみよう！
・・・でも、めんどくさいよね。
ということで、それがどんなデータなのか？というのを解析するツールがあればいいと思うのです。
例えば、法線データはＦｌｏａｔ＊３（長さ＝１）だから、（－１，０，０）みたいな並びになる。
ｕｖデータは０～１（？±０．５）になるし、頂点位置でほとんど＋だけなのはＹ座標だし。
こういうのが重なると、解析しやすくなってくるわけですね。
色がＲＧＢＡだと１，１，１，０みたいな並び多いしね。
分かり易いのはええんやけど、ラジアン角とかの謎の１～３になる数値とかどうすんべ？と。
アドレス→データ長→数値変換 みたいなバイナリ表示＆書き込みができたらええなと。
で、とりあえず「俺主」とかの移植キャラに輪郭線を好き勝手につけるためのＨｅｘエディタ。
シェーダー用のパラメータで、輪郭線の色とか太さとか自由に入力できるかな？
できたらええなあ・・・そんな感じのエディタをXXMiniConverterに付けたいね。
法線・・・？なんやねん、それは（困惑）
頂点はわかるけど法線がわからん人が多いね。
３つの頂点で作る△の面から生える垂線のベクトルを考えるとしようか。
これは面の法線、向き、わかりやすいわな。
頂点１つに法線１つを割り当てたらどうなるか？
つまり、３つの法線の向きが揃った△は見掛け上も実際も平面やな。
でも、もし３つの法線の向きがバラバラだったら・・・見掛けはどうなるか？
近接する頂点の法線がバラバラの場合は別の面に見える。
近接する頂点の法線が揃っている場合は連続した面に見える。
ローポリをハイポリっぽく見せるのが頂点ごとに法線を割り当てた利点やね。
法線を使って輪郭線（トゥーンシェーディング）を描画してる場合はその影響も顕著です。
法線（Ｎｏｒｍａｌ）マッピングといって、画像から見掛けの法線を貼りつける手法がＰＰＤで使われているように、結構面白いことができる法線。
じっくり考えつつ、パーツを分割するといいですよ！
裏面・・・！？
法線の続きになるけど、全く同じ位置に頂点がある△の表と裏を区別するのは何やろか。
それが面の向き。頂点を繋ぐ面は頂点番号３つの順番で表がどっちか区別しております。
面に材質（Ｍａｔｅｒｉａｌ）が適応され、テクスチャが貼られるわけやな。
裏はどうなってるかというと、なにもない！ふしぎ！！
裏面を描画するシェーダーを使うと裏も自動で表示されるけど・・・
スカートの裏地を表現するには別の面を使ったほうがいいよね。
この両面をひとつのＭｅｓｈにしたとき、困るのは法線のベクトルです。
裏と表のベクトルは普通に計算したら全く逆方向になるから・・・
もし、近接頂点の法線を平均化してしまうと、法線ベクトルが０になってしまう！？
無理やり法線の長さを１に戻すともっと悲惨なことになります。
めんどくさいけど、近くて別のＭｅｓｈは分けて入れないとアカンのよね。
顔モーフを作るには？
全頂点をモーフすると某大なデータが必要なので、なんとか最適化したい。
標準顔と頂点を動かした顔のメッシュを比較して、位置が違う頂点のIDを記録すればエエねん！
でもって、次はモーフした頂点位置＋法線ベクトルの情報が必要になるね。
最後は、それらの組み合わせを仕様にあわせて構築する。
表情パーツID、表情番号、Open／Closeの数値とモーフ名、頂点IDのパーツ名を綺麗に並べたらOK！
でもまあ、現状やとメッシュの出し入れにはXXが無いとダメだし、表情みながら作業したいし。
３Ｄなツール、または代用品が必要やね。それは・・・つまり・・・ｗ
モーションって何なのさ？
ダンスとか、反復運動（アレ）とか、３Ｄのキャラクターをどうやって動かしているか？
・・・というと、ほとんどは「骨格」を動かしているんだよね。
中の人がモーションキャプチャで動かした頂点座標を取りこんで、骨格の動きにする。
なめらかな補間（球形線形補間）ができるのが、コマアニメとの差ですなぁ。
モーフは頂点や法線といった皮膚（Ｓｋｉｎ－Ｍｅｓｈ）を動かしているんだけども、
こっちは骨格（Ｓｋｅｌｅｔａｌ－Ｆｒａｍｅ）を動かす。
４×４の姿勢行列（Ｍａｔｒｉｘ）を４元数（Ｑｕａｔｅｒｎｉｏｎ）という形式と変えて
中間姿勢を綺麗につなぐ、これは数値を見ただけでは全くわからんな。
大事なのは「骨格（Ｆｒａｍｅ）」を識別しているのは名前であること。
骨の名前を書き換えれば、別のゲームからモーションを移植できる！って奴やな。
そして、キャラクターによって骨格が違うこと。
関節の位置（Ｔｒａｎｓｌａｔｅ）を差分計算して位置合わせするツールは作ったやろ？
でも、関節の数が違う場合、二重関節になってる場合と互換するにはどうするか？
関節の親子関係から、回転の合成（積）または回転の分割をせにゃならん！難問よ。
ツール開発で避けて通れないところ（数学！）がんばりましょう。
ウエイトってなんなのよ・・・うまくいかへん。
Ｍｅｓｈと骨（Ｂｏｎｅ）の関連付けが＜頂点ウエイト＞Ｗｅｉｇｈｔやな。
どの骨にどれだけ乗っかってるか？という情報のことです。
１．０の荷重を骨３本に分けたり、２本だったり、４本だったり色々ですな。
で、この骨は骨格と対応してるんやけども・・・全く同じなのは名前だけ！やねん。
ＳｋｅｌｅｔａｌＦｒａｍｅのＭａｔｒｉｘをいじるのと、ＢｏｎｅのＭａｔｒｉｘをいじるのは同じように見えて違うということやな。
Ｓｋｅｌｅｔａｌはアニメで動かす部分。ＸＡやＫＹＳやＢＰＳやＴＴＹで書き変わる。
Ｂｏｎｅを動かすのはＭｅｓｈを変形させたい時やねんな。
ＭｅｓｈごとにＢｏｎｅがあるということは、別の数値を入れて部分変形もできるんや。
ウエイトが均等に乗ったＭｅｓｈはだいたいの形を保つように見える。
Ｂｏｎｅ１本にＷｅｉｇｈｔ１全部乗せればカチーンと硬化したまま動く。
逆に、肘みたいな関節に上手くウエイト載せないと、ゴム人間みたいになるｗ
ＳＢ３Ｕでウエイト表示させながらＳｋｅｌｅｔａｌの変形をすると分かり易いかな？
ＳＢ３Ｕは元々のＭｅｓｈにあったウエイト情報から数値をコピペしてるだけなのよね。
だから、ハイポリ化しただけじゃ滑らかに追従しない。
このへんの計算を綺麗にやれればハイポリ化に対応できそうなのになぁと考え中。
右手座標系と左手座標系うん、突然コアな話題ｗＯｐｅｎＧＬ系（右手）とＤｉｒｅｃｔＸ系（左手）やね。
最古の３Ｄイリュゲーが何かはわかりませんが、人工２まで（ＢＲ２まで）のイリュと、
レイレイ以降のイリュでは大きな違いがあります。
ＴＢＬを使ったＸファイルがＬＳＴを使ったＸＸになったりといった形式もそうですが、
開発ツールの変更による座標系の変更が過渡期のＢＲ２を見るとよくわかります。
簡単にいえば、親指＝Ｘ、人差し指＝Ｙ、中指＝Ｚ軸とすると、
右手と左手はひとつの軸が対称になります。
これは、平面（Ｘ，Ｙ）を固定すると必然的に奥行きのＺ軸で向き（±）が逆になるということです。
Ｚ軸の向きが逆のデータでは、面の向きも、法線の方向も、なにもかもあべこべです。
ですが！
変換の法則さえ掴めば、ＭｅｓｈでもＭａｔｒｉｘでもＱｕａｔｅｒｎｉｏｎでも計算できるんですねえ。
いやあ、計算機っていいものですね。
反転の公式ここから本題ｗ忘れないうちにメモっておこうと思いましたので、めも～る。
軸の方向を反転させたＭａｔｒｉｘは、タテヨコ両軸について符号を反転し、重なった部分はそのままの符号になる。
（ －１ × －１ ＝ ＋１ ）
matrix0;
rot-X' rot-Y' rot-Z' W
X m00 , m01 , m02 , m03
Y m10 , m11 , m12 , m13
Z m20 , m21 , m22 , m23
T m30 , m31 , m32 , m33
左右反転（Ｘ軸／ＹＺ平面）
matrixX;
rot-X' rot-Y' rot-Z' W
X m00 , -m01 , -m02 , m03
Y -m10 , m11 , m12 , m13
Z -m20 , m21 , m22 , m23
T -m30 , m31 , m32 , m33
座標系の反転（Ｚ軸／ＸＹ平面）
matrixＺ;
rot-X' rot-Y' rot-Z' W
X m00 , m01 , -m02 , m03
Y m10 , m11 , -m12 , m13
Z -m20 , -m21 , m22 , m23
T m30 , m31 , -m32 , m33
４元数による回転 ＋ スケール ＋ 移動
Q0( w, x, y, z) Scale-0( X, Y, Z) Translate-0( X, Y, Z)
左右反転（Ｘ軸／ＹＺ平面）
Qz( w, x,-y,-z) Scale-Z( X, Y, Z) Translate-Z(-X, Y, Z)
座標系の反転（Ｚ軸／ＸＹ平面）
Qz( w,-x,-y, z) Scale-Z( X, Y, Z) Translate-Z( X, Y,-Z)
どや？手首がクルクルーやろ？ｗ
最近のイリュゲーは左手系、昔のイリュゲーは右手系、そういうかんじやでー。
４元数―
回転行列の
相互変換４元数では姿勢がわかりにくいが、補間の計算がしやすい。
回転行列はその逆で、姿勢はわかるが、補間は難しい。
この両者のいいとこどりをするためには、相互変換をする必要がある。
四元数 → 回転行列（３×３） または 回転行列（３×３）→四元数
の公式で、ＯｐｅｎＧＬ系（右手）とＤｉｒｅｃｔＸ系（左手）を変換する行列を転置すればいい。
転置とは、つまり、回転軸の配列とベクトルの配置を逆にするということ。
もっというと、回転Ｍａｔｒｉｘの行と列を入れ変えるということ。
式が複雑なため、それぞれのリンクを貼って〆にします。
ＤｉｒｅｃｔＸ／左手系 （行方向が軸の向き）
その58 やっぱり欲しい回転行列⇔クォータニオン相互変換
見比べると、途中に出てくる回転行列の内容が・・・！？
ＯｐｅｎＧＬ／右手系（列方向が軸の向き）
回転行列からクォータニオン（四元数）に戻す
そこで気になるのが、スケールと移動と回転のタイミングなんよね・・・
数学オンチの私にとって道は険しい＾＾；まだまだ試行錯誤はつづいております。
で、きゃらコレのセーブいじってて「もしや？」と思ったことが幾つかあるので、実験しつつツールを完成させていきたいと思います。
・どこのフォルダに入れても、ロードすると部分セーブはちゃんと適応される
ならば → アイテムセーブは本当に部分セーブをロードできないのか？
・セーブの内容は回転だけのＭａｔｒｉｘと初期姿勢（移動アリ）のＭａｔｒｉｘと整数値のフラグ
回転Ｍａｔｒｉｘしか読んでないならば → 回転部分を拡大したセーブデータを使うと・・・？
もしかすると、きゃらめいくが出来るのかも！？
なんにせよ、４元数→回転行列への変換も実装しなくちゃいけませんね。
今まで避け続けていた禁断の領域に足を踏み入れたその後は一体どうなってしまうのか。
もしかしてアタシ、消されちゃうカモ！？ｗ
使い方によってはかな～り危険なツールばかりのため、コソコソしておりましたが、はてさて。
- 2013/04/26(金) 21:18:10|
- 改造
-
| トラックバック:0
-
| コメント:0
