ドンキーコングリターンズ バイナリ解析
解析っていってもデータの構造を調べるって意味です
ちなみに現在俺一人で頑張った成果↓
ドンキーコングリターンズ 音楽ハック～とげとげタルめいろ～
http://www.nicovideo.jp/watch/sm15530573
ドンキーコングリターンズ(以下DKR)のISOをWiiScrubber,WiiBrowseで展開すると.pakという拡張子のファイルがでてくる
それがDKRのステージファイルで、ステージ構成・画像・モデル・アニメーション等が圧縮されて入っている
.pakファイルは上のWikiのDKDKというソフトで展開できて、データの種類ごとに分類し、抽出やら置き換えができる
で、それらデータの構造を知れば改造が可能になるから、みんなで相談や意見交換しながら解析していこう、というのがこのスレの趣旨
データとしてはそのデータに関するデータ(サイズ・オフセット・子データの数など)、識別子、実際のデータ、などがある
一応言っておくと、ファイルのバイナリデータはバイナリエディタで見ることができる
バイナリエディタにはStirlingなどがあり、一応上のDKDKもバイナリ表示機能がある
ひとまずこれからはスプライトのデータを探そうと思う
そもそもスプライトで障害物や敵が管理されてるかわからないけど
MREAデータは最初に何かのテーブルがあって、そのあとで名前付きの何セクションかに別れて圧縮データが入ってる
圧縮方法はDeflateでzlibを使って圧縮してあった
MREAファイルは.pakファイルに1つだけ入っているし、セクションの圧縮データを見るかぎり、オブジェクトの配置を管理していると思う。
これがファイル編集のためのソフトDKDK
http://www18.atwiki.jp/dkhax?cmd=upload&act=open&pageid=18&file=DKDK.zip
これが1-1のステージデータ
http://ll.la/f9SV
外人でも探して解析することにするわ
てか、俺しかレスしてなくてワロタｗｗｗｗｗｗｗ
俺興味ひこうと必死ｗｗｗｗｗｗｗ
一緒に解析しようぜ！
たぶん俺より経験豊富な人もいるだろうけど、やっぱり興味ないんだろうな
誰か意味が分かった人がいれば教えてくれ
俺はひとまずUSB Geckoでアセンブリの泥沼をさまようことにした
ステップ実行はできるがサーチがなぜか途中で止まるという…
テーブルの意味は単純にMREAの解凍データにおけるエントリーのサイズっぽい。
解凍データが何を表しているかはまだわからないけど
ヘッダ部にはエントリ数らしき数字があるものの、微妙にテーブル部のエントリ数と一致しない
ちなみに今解析しているMREAデータはこちら
http://www1.axfc.net/uploader/Ne/so/117801.bin
ここに書きこむと自己解決するみたいだな
ヘッダ部の0x40の数字はエントリ数その1。各エントリは4バイトで、解凍後のデータのサイズを表す。
ヘッダ部の0x44の数字はエントリ数その2。各エントリは16バイトで、用途は不明。サイズらしきデータと、謎の整数値が含まれる。
エントリその2はエントリその1の真下に書きこまれている。
ヘッダ部の0x48の数字はテーブルの下にある文字列の個数。これら文字列はおそらく解凍後のデータの種類を更に細かく分類するためのもの。
WOBJ(World OBJect),COLI(Collision)とかがあるけど、詳細は不明。
ヘッダ部にまだわからない整数値があるからモヤモヤするけど、RASファイルの場合はわからないのを適当に0で埋めても正常に動作したから
適当にやって大丈夫かもしれない
ひとまず圧縮データの詳細を調べることにしようと思う
解析を手伝ってくれる奴はいつでも歓迎
文字列らしきデータがところどころ格納されているし、PARTやらCSKRはほとんど文字列で構成されている(どうもこれらの場合はプロパティを設定しているっぽいが)
MREAの解凍データにも多くの文字列があった
ただし、デバッグ用の文字列かもしれないが
解析には直接関係ないが、.NET用zlibの"zlib.NET"が不具合持ちで自分でzlibのラッパーを作ることにしたわ
あんなのがいかにも正当な.NETにおける実装だぜ、って言ってるみたいなのが悲しい
解析頑張ってください。
応援してます。
はい、がんばります
でも、一緒に解析していいんだよ？
zlibの使い方になれるまで手間取ったがラッパーはできた。
引き続きMREAの解析を続けようと思う
Zlibのラッパーを作成して晴れてMREAの解凍データを得ることができたのでアップしとく
0x0 子エントリ数
子エントリの詳細
0x0 サイズ
0x4 常に4？
0x8、0xc 常に0？
0x10 常に0xF0F?
0x14～0x18 パディング
以下文字列と値
文字列は予約語的な役割をしているらしく、次に続く値はその予約語に対応するものでなければならない
文字列の中身としてはPASS,DIFF,DIFFB,CLR,ENDなどがある。
ENDはどのデータの終端にもついていて、ここまでがこの子データの中身であるが、0x0に於けるサイズの値はこれを除いたものとなる
値の中身としては整数値、キーなどがある。ただし、キーは見た限りではTXTRデータのみを指しており、
CMDLや、CINFなどのキャラ関連のデータを指していない。
このことからMREA解凍データの一番最初のエントリはステージのシーン情報の管理をしていると推定できる(DIFFなんかもおそらく"Diffuse"の略だろう)。
なんて書いてみたが、結局よくわからない。TXTRをjpgやらpngやらに変換できたらなんの画像で何のためにこのデータがあるのかわかるのになあ
先にTXTRの変換に挑戦するべきだろうか
そこがわかれば煮るなり焼くなり好きにできるんだが、、、
TXTRのデコードに挑戦している。なんの画像かわかれば、MREAや他のファイルの解析の役に立つしね
TXTRは他のデータとは異なる圧縮ヘッダを持っている。それについて
1.パレットなし
0x0 dpiX(常に0xC)
0x4 dpiY(常に0xC)
0x8 圧縮サイズ(上位4ビットはフラグ)
0xC 解凍サイズ
0x10 不明
0x14 横
0x16 縦
0x18 画像フォーマット？
2.パレットあり
0x0 dpiX(常に0x14)
0x4 dpiY(常に0x14)
0x8 パレットの圧縮サイズ(上位4ビットはフラグ)
0xC パレットの解凍サイズ
0x10 画像の圧縮サイズ(上位4ビットはフラグ)
0x14 画像の解凍サイズ
0x18 不明
0x1C 横
0x1E 縦
0x20～0x28 不明
更に疑問なのはたまにヘッダの解凍サイズの値と実際の解凍データのサイズが一致しない時があること。
メモリダンプではデータは正常に解凍されていた。ということは>>24の内容は間違っているということか？
データサイズがピクセル数の倍数になっているものがほとんどだから
ピクセルあたりのデータサイズは最小で4ビットがあるっぽい
そうでなければピクセル数がバイト数を上回る場合を説明できない
画像に詳しい人、吸い出し経験がある人のアドバイスがほしい…
devkitProのgxtexconv.exeでビットマップ画像をCMPRフォーマットに変換してみたところ、TXTRに非常に似たバイナリが生成された。
ちょっくらソース参照してコーデック作ってくるわ
ここはマリオカートハックのChadderzのソースを流用することにした。
ライセンス的にはOKなはず
まだ上下が逆なんで修正したらアップする
専ブラならサムネがでるかな
豚テクスチャ
http://up3.viploader.net/ippan/src/vlippan236539.png
ドンキーテクスチャ
http://viploader.net/ippan/src/vlippan236540.png
ありがとう
テクスチャハックが可能になったら人寄せもしやすくなる…はず
気になるのは、ヘッダの情報に画像フォーマットが含まれていないのではないかということ
ほとんどの画像がCMPRで一部RGB5A3だが、ヘッダに共通性がみられない
さらに一部の画像は未知の形式で、ゲームキューブ・Wiiの形式のどれでも変換不能だった
まあ、どうせ俺の勘違いか間違いで終わるだろうが
マリオカートやらスマブラで使われているtex0フォーマットは通常画像に加えて、縮小画像を保持している
それと同様に幾つか縮小画像を保持しているならサイズが合わない説明がつく
ちなみに未知の形式といってたやつはRGB5A3でデコードできた。
実装したと言ってもコーデックはChadderzのを使い、ビットマップの拡大縮小は.NET Frameworkがやって、俺がしたのはヘッダ情報の記入と
データの圧縮くらいで、手間はかかってない
テストして動作したらデモ動画とTXTRに対応したDKDKをアップするわ
パレット画像は今のところ実装予定なし！
ステージに含まれる枚数的にはかなり少ないし、
Wiiの画像フォーマットで一番優れているのはおそらくCMPRで、ユーザーはそれ一択でおｋだから
テストは明日か明後日しようと思う
100MBとか余裕で食うんで注意
どういうことかというと、まずファイルロード画面(ドンキーやディディーが左から右へと走る画面)から先に進まなかった
かといってフリーズしたわけではない。
以下、原因の推定
1.内部的にファイルサイズを保持し、ファイルサイズがそれ以上だったらエラーとしてリロードを試みる
これは無い。なぜかというとRASはキチンと読み込み、再生することができたからだ。
2.Riivolutionに問題がある
これも1と同様の理由で否定されるほか、正規のファイルを配置したところキチンと読み込んだ。
これはRiivolutionにファイルサイズの限界があるからだ、といった推測は誤りとなる
3.PAKデータの先頭の16バイトの数字(キーと呼んでいる)が間違っていた
正規のファイルのキーを適当な値にいじって読み込ませたところ、動作した。よってキーの値は適当でも良いことになる
4.DKDKのファイル組み立てが間違っていた
これは微妙であるがオフセットの値がありえないところを指している、といったことがあった場合、ゲームはおそらくフリーズするはずである。
とはいえ、これしか原因はありえない。
テクスチャのミップマップの扱いが怪しいと思う。データサイズが、同じ縦と横、ミップマップの画像数をもつ画像と異なっていた。
よく調べて修正しようと思う。
ステージ改造が可能になれば多分人は増えるだろうし、それまでの辛抱だと思う
TXTRのリビルドに間違いが見つからない…わからんorz
やめたわけではないのでご心配なく
ところでRiivolutionの速度の遅さが目に余る
どんな実装したら3倍程度の読み込み時間になるんだ
PAKファイルがあったので見てみたが、ステージのPAKとやや構造が異なっていてDKDKの手直しが必要っぽい
こんな所にファイルがあると知っていたならそれに合わせて最初から作ってたのに…
なぜだ？ RASファイルは問題なく読めたのに、PAKは大きさを揃えないと読めない
ひとまずデモ動画つくるわ
朝から乙です
読み込みプロセスがわかればヒントがあるかもなー
でも逆汗はしたくねえな
誰か助けてください。
答えは単純、データサイズは0x40バイトにアラインしなければならない、という規則を破っていた
データのテーブルを見てみると、データサイズの末尾2バイトが00,40,80,C0のものしかなかった
そこで、データをすべて0x40に揃えたところ、やっと読み込むことができた
これで意気揚々とデモ動画をつくれるぜ
テクスチャハック動画
つhttp://www.nicovideo.jp/watch/sm15833993
DKDK本体はちょっと待って
わかりにくいって意見が出たら作ろうかな
まあ、空に大きくHello Worldって出してるから問題ないと思うけど
お次は何をしましょうかね
MREAは最後に回した方がいい気がしてきた
あれはステージを組み立てる設計図みたいなもんだし、いろいろわかってないと難しい
モデルいくか？
ちなみに俺はコード書けるだけで、画像処理やら音楽変換は完全な素人だから常にググってる
言語や知識は問わないからコード書ける人は手伝ってくれるとうれしい
3ヶ月かけてまだRAS(STRM)とTXTRしか実装できてなくて、正直一人じゃ気が遠い
http://www18.atwiki.jp/dkhax?cmd=upload&act=open&pageid=18&file=DKDK.zip
テクスチャハックして動画作って宣伝、知り合いに紹介などどんどんしてください
ちょっと待って
もう大丈夫だと思うけど…
モデル関連でわかっていることを挙げると、
CHAR:
モデルの設計図。このキャラの名前は何、モデルは何を使う、アニメーションは何を使う、といったことが記述されている
CINF:
ボーン(開発者はどうやらジョイントと呼んでいたっぽい)の情報
CMDL:
モデルのいろいろ。テクスチャなど
CSKR:
スキンの情報
関係あるかわからないデータ:
CPRM、CSMP、CAUD
ていっても一番最初にあるスクリプトっぽいデータだけ難しくて後は単調な配列っぽいから、
最初さえ何とかなれば簡単そうだ
わかってることを書くと、
スクリプトは「データ型」「データサイズ」「データの種類」「データ」の順で並んでいる
データ型にはPASS、INT、CLRがあってPASSはデータのキー、INTは整数を表す。CLRはわからん
データサイズはバイト単位で指定される
データの種類はいろいろあり、CLR(データ型とは別みたい)、DIFF(Diffuse)、RFLV、RFLD、OPAC(Opacity)、TRAN(Transparent? Transformation?)などがある
ただ厄介なのが、データにはデータ型で指定されたもの以外にデータの種類に応じてプロパティが含まれる
これらの意味を一つ一つ理解していかないとモデルのインポート、エクスポートは実現できないだろう
また、スクリプト群の前と、個々のスクリプトの前にそれぞれヘッダが用意されており、それもほとんど意味が分からない
開発者はデータを一般的なモデリングソフト(3DS Maxやらmayaやら)で作成しているだろうからそれらのフォーマットを理解すればこのデータの理解にも役立つと思う
一応呼びかけるけど、3Dモデリングに詳しい人、どんどんご協力ください
他にも被るデータが大量にあり、おそらくゲームエンジンは同じのを使っている
製作元は両方レトロスタジオ社で、過去の資産を有効に活用してるっぽい
ここらを調べればいろいろわかるかも
メトロイドプライム2のファイル解析プロジェクトMPxViewer(最新リリースが5月だが)のソースがクソ役立つ
これは解析が捗るわ
RFLVやRFLDは反射が関係してそうだ、とかわかってきた
チラシの裏にでも書いてろって感じですねｗｗｗ
要は活動してるよってことです
スキニングやアニメーションは後回しにするから、ひとまずビューワーを作成していこうと思う
そのためにはまず3Dプログラミングを学ぶところから始めなけりゃならないが
それに、メッシュデータの1エントリごとのサイズがまちまちで、どこに見分けるためのフラグなり文字列なりがあるかもわからない
一つ朗報なのはバーテックスデータの変換はできるようになった
テストしてみたところ花っぽいものが出てきた
しかもビット単位でフラグが指定されているから8ビットすべて理解するにはかなり手間がかかる
ドンキー開発者の方は何ら困らないからしょうがないんだけれども…
まぁ頑張れ
開発者のデータは無いけどWiiに関してはリバースエンジニアリングが進んでいるからその情報を元に推測してる
それにS○Kのドキュメントが流出してるからそれも参照しながらやってる
CMDLの状況だが、フラグは大体わかってきた
それでもまだ理解できていない数字がたくさんある
手伝ってくれるという人がいるなら、現在わかっていることを詳細に書くが…
いい加減しつこいかな
でも応援しているよ
といってもwiiマリオのエディタも一人だった気がするし頑張ろうと思う
俺の見積もりで最も時間がかかると見たのがRAS音楽で、TXTR画像やCMDLモデルはその次にかかると見ていたから
ここを終えればエディタにだいぶ近づくはず
ヘッダ部：ほぼ解析完了
マテリアル：結構残ってる。CMDL内では統一された数値でもMREAでは違うという値がある(MREAにもマテリアルがあることは前に言ったと思う)
バーテックス：解析完了
ノーマル：解析完了
UV：解析完了
メッシュ：ほぼ解析完了。謎のベクトルあり。ヘッダ部にはマテリアルや幾つかの項目への参照がある
だいぶ前に可能になってたバーテックスの表示画像
JPG画像なので心配しなくていいよｗ
CMDL先頭のフラグによってメッシュのエントリのバイト数が1～2バイト変化するが、それら増えたエントリの意味が分からない
そのフラグが付いているCMDLの個数を調べてみたところ、CSKR(スキン)データの個数とほぼ同一となった
面白い事にどのステージデータでもCSKRの個数はフラグonのCMDL数から3引いた数になっている
これらのことから判断して増えた1、2バイトはスキンメッシュアニメーションに関係する値であることは想像できる
まあ、そんなキーワードで調べる奴はいないだろうし、あまり人寄には役にたたないな
CMDLのメッシュのエントリの先頭につく1バイトは必ず3の倍数になることがわかった
何を表しているんだろう
1.列挙体
3の倍数にする意味がない
2.データサイズ
なんのデータサイズだろうか？ スキンメッシュアニメーションに関連があるという過程からすると、全く的はずれな推測になるが…
3.データの個数
同様に、なんのデータの個数だろうか？
4.オフセット
これはありえない 3の倍数だけ進んだデータはまだ同じエントリ内だから
5.フラグ
ありえる だが、3の倍数が(ry
6.ID
IDであればそれぞれ違う値になるはずだが、同じ数値を持ったエントリが大量にあることからこの推測は否定される
7.数値自体がメッシュの形状やアニメーションに影響する
この場合非常に厄介である。ゲームを動かしてみて実際に実験をしながらやっていくか、アセンブラを読みといて必死に解析するか、
運が良ければ他のモデルフォーマットから相当しそうな値を探し出すことが出来るか
いずれの場合でも非常に手間がかかるのは事実
しかも、「運がよければ」の選択肢である他のモデルフォーマットを参照する、という手段はとうの昔にやっているので残り2つの泥沼しか残っていない
数値自体が影響を与えていないことを願っている
そもそも、この追加の1～2バイトがメッシュデータ内に存在するかどうか判定するためのフラグやらなんやらがヘッダ内に存在しない
ということは他のデータ部にそれが存在するか、あるいは「このデータが存在するから追加の1～2バイトも存在する」といったデータ間の関連付けが存在するか
というより、もろにCMDLのメッシュデータと同様の構造があった
ちょっとChadderzやKryalのソースコードを覗いてくるわ
これがダメだったらRる
まず、メッシュデータに含まれる謎の1～2バイトはやはりスキンメッシュアニメーションに関係ある
どう関係があるかはまだ調べてる
スキンメッシュアニメーションを疑い始めてずっと平行してCSKRデータの解析に挑戦してきたがようやくわかってきた
これは挫折せずに済みそうだ
ヘッダ
0x0 タグ(ASCII文字列でSKIN)
0x4 バージョン(整数値0x3)
0x8 総エントリ数
エントリ
0x0 子エントリの個数
子エントリ
0x0 ボーンID
0x4 重みの値(浮動小数点数)
エントリのフッタ
0x0 参照カウント(だと思う)
エントリが並んだ後テーブルが2つある
最初のテーブルの先頭にはテーブルのエントリ数があり、符号付き16ビット整数値のエントリが続く
0xFFFFのエントリが含まれるがこれは何も参照していないエントリ
このエントリがバイト境界を合わせるために存在するのか、それとも他の用途があるのかは不明
テーブルのエントリ数は必ずスキンのエントリの個数に等しいことから、これは順番が重要になってくるはず
次のテーブルも同様に先頭にエントリ数があり、後に符号なし8ビット整数値のエントリが続く
これもエントリ数はスキンのエントリ数と等しくなるが、単純に0から1ずつ数え上げるだけなので、意味は不明
構造からしてCSKRのスキンのエントリをCMDLのメッシュデータが参照しているはず
何度も言うとおり、CMDLのメッシュデータは3の倍数になっていて、0～0x1B、すなわち10段階の値しか取らない
しかしCSKRのスキンのエントリは何十個とある
したがってCMDLのヘッダにある謎の整数値が鍵となってくるはず
・メッシュデータの値が10段階の値しか取らない
・メッシュデータはすべてのスキンのデータにアクセスできなくてはならない
この2つのことを考えると、メッシュデータはスキンデータに次のようにアクセスするはずである(というよりそうでなければおかしい)
スキンデータのインデックス＝メッシュヘッダの整数値×10+メッシュデータの値÷3
ヘッダ
0x0 サイズベクトル(多分)
0xC 不明(常に0x8000)
0xE メッシュデータのサイズ
0x10、0x14 パディング
0x18 CSKRエントリインデックスの10の位(>>72参照)
0x1A マテリアルのインデックス
0x1C 不明(常に0xFF)
0x1D CMDL先頭の文字列との対応を表す整数値
0x1E ステージのオブジェクトかどうか(多分)
これ以降はメッシュデータが続く
メッシュデータのヘッダ
0x0 コマンド(WiiのS○KにおけるGX関数のコマンド)
0x1 エントリ数
以下にエントリが続く
エントリは前から言っているように、バイト数が場合によって異なる
すべての内容が揃っている場合
0x0 CSKRエントリインデックスの1の位を3倍した数
0x1 上の数値に0x1E足した数
0x2 バーテックスのインデックス
0x4 ノーマルのインデックス
0x6 UVのインデックス
最近停滞し続けていたからもう見限られたかなｗｗ
残ったマテリアルを解析できればいよいよビューワーの製作に取り掛かれる
一部不明な値を残しつつ来たが、それはエクスポートを実装して実験すればいいし、RAS音楽のように色々入力する必要のない値も存在する
(RASにも音量関係の数値=重要な数値がありそうだと最近思い始めたが)
何もできなくてすまん (´･ω･`)
欲を言うならDKDKを使ってみての感想やバグ報告なんかをしてくれると嬉しい
・RAS音楽のコーデック作成←済
・TXTRのコーデック作成←パレット付き以外済 パレット付きは実装予定なし
・CMDLのコーデック←50％(把握は80％) CSKRのコーデック←ほぼ済
・CINF(ジョイントデータ)のコーデック
・ANIMデータのコーデック
・CHARデータのコーデック
・PARTデータ及びSWHCデータのコーデック
・MREAデータのコーデック
全体としてみるとスーファミ時代のドンキー並みに改造可能になるまでの道のりのうち半分以下ってところか
とはいえ、最難関の一つと見ていたCMDLの把握がそろそろ完了することを考えると、結構早く終わるかもな
半年以上必要だったら事情でそれ以降は一年以上作業ができないがorz
その場合はDKDKのソースを公開するか…
わかったことを羅列する
1.マテリアルにはヘッダがあり、フラグ、列挙体等が含まれる
2.ヘッダの後はアトリビュート(属性)とおぼしきものが存在する
3.属性にはCLR(データにキーを持つものとマテリアルの色をRGBAで表現するデータを持つものの場合がある)、TRAN(透過部分を示すテクスチャの情報)、INCA(発光部分を示すテクスチャの情報)
RFLV(反射？)、RFLD(反射？)、RIML(Rim Light、縁どりの光？)、DIFF(Diffuse?)などがある。
ヘッダの内容と属性は少なからず関係していて、因果関係をつかめないことにはインポータ、エクスポータは作れない
この中で特に意味が分からないのはRIMLで、必ず球体(例えばこんなの http://viploader.net/ippan/src/vlippan245103.bmp)が指定されている
この球体を使ってどうやって縁取りを描画しろと言うのだろうか？
そもそも、反射やらDiffuseやらはマテリアル自体に適用されるものであってテクスチャに適用されるものではない。
それなのに、あたかもテクスチャそれぞれに反射光やら拡散光やらを設定してそれを合成することで、マテリアルを構成するかのごとくデータが並んでいるのはどういうことだろう？
例のS○Kのドキュメントにはテクスチャそれぞれに光を設定できるようなことが書いてあるぞ
俺の勉強不足か？
これが出来ればいろいろ実験できるし、モデルが表示できる事自体が楽しいはず
モデル表示の基礎部分はできたので、続けて作っていこうと思う
ドンキーのモデルが穴だらけになってしまった
ようやく正しくモデルを読み込めた
まだテクスチャがおかしいのでそこを修正したら画像を上げる
まあ、ゆったり待っててくれ
ようやくドンキーコングリターンズの3Dモデルの表示に成功した
まだシェーダを実装していなかったり、異常なところがあるが…
バナナを吐く塔
http://img823.imageshack.us/img823/5066/15099378.jpg
バナナエアーシップ
http://img213.imageshack.us/img213/2020/27341263.jpg
ディディー
http://img440.imageshack.us/img440/462/65467377.jpg
ドンキーのDS
http://img534.imageshack.us/img534/3058/51824129.jpg
バルーン
http://img507.imageshack.us/img507/3529/50441872.jpg
出だしのアレ
http://img525.imageshack.us/img525/1055/75729111.jpg
樽
http://img202.imageshack.us/img202/2402/88213877.jpg
葉っぱ
http://img265.imageshack.us/img265/3899/36157535.jpg
一応CMDLの表示に対応したDKDK最新版(正式ではない)
今のところ解析と関係ないDirectXで詰まってる
その問題が解決したらディディーのテクスチャの以上の原因を調べようと思う
すぐ解決すると思ってたDirectXの問題が思ったより難しい
解決したらまた進捗状況を書くから少々お待ちを
テクスチャに関しては進展がない
見てる方も楽しくないだろうから画像を上げる
http://uploader.sakura.ne.jp/src/up71256.png
http://uploader.sakura.ne.jp/src/up71257.png
一つは普通に32ビット浮動小数点型で記述されており、そのままUV座標として使える
もう一つは16ビット整数型で、浮動小数点型に変換した後何らかの数で除算するとUV座標に相当する値が算出できる
そして今日はその「何らかの数」を大量のデータから推測、実験して導出することに成功した
その結果がこちら
Kalimba
http://up3.viploader.net/ippan/src/vlippan248647.png
DK
http://up3.viploader.net/ippan/src/vlippan248646.png
DKは一目瞭然、kalimbaの方は一見正常だが、公式サイトで確認したところまだうまくいっていなかった
うーん、わからん
Diddy Kong
http://up3.viploader.net/ippan/src/vlippan248772.png
Donkey Kong
http://viploader.net/ippan/src/vlippan248773.png
単純にテクスチャが上下反対だったみたいだ
ただ、ドンキーのネクタイを見てみればわかるように、部分部分では反転している
もうそろそろテクスチャの基本的なところは終わりそう
http://up3.viploader.net/ippan/src/vlippan248868.png
画像が左右反転していた理由が判明した
DirectXにおける座標系は左手座標系だが、Wiiゲームでは右手座標系らしい…
テクスチャの問題だったわけではないということ
ようやく異常がなくなったので、シェーダー作成にとりかかろうと思う
TRANあたりは簡単に実装できると思う
どうやらTRANで透過する対象のテクスチャがCLRで指定されているもの以外の場合もあるようだ
そこまではわからないのでひとまず置いといて次のシェーダ作りに進むことにする…
今回テクスチャがまともに表示されない問題の原因をようやく突き止めた
テクスチャが正方形になっていないと自動的に正方形になるよう画像が切り取られるみたいだ…
(まあ、正確にはDirectXというよりD3DXの仕様だが)
まあ、まともに表示できそうなので、近いうちにアニメーションの実装に移る
最初にあるものは明らかにジョイントの名前のテーブルだが、そのあとは単なる整数の羅列にしか見えない
しかも複雑なバージョンと単純なバージョンがあって更に複雑にしている
このスレを見てる人はどれくらいいるかわからないけどまだ解析続けます
まあ、今年は徐々に厳しくなってくだろうけど
一人でよく頑張るなぁ、なにもしてあげられないけれど
とりあえず、明けましておめでとうございます
まあ、焦ってもわかるものではないが、4月までくらいしか解析できないから少し頑張ろうかな
4月になったら解析を一年程中断する予定
一年後ヤル気があったらまたスレ立てして解析するかな…
スレ立てしなくても1、2ヶ月くらいに1回保守してスレを再利用したほうがいいよ
1年後にはきっと外人がスマブラレベルの解析してくれてる・・・はず
100～のスレッドの続きを読む