ドンキーコングリターンズ　バイナリ解析

1 ：2011/09/11 〜 最終レス ：2013/06/12

かつての改造ドンキーを夢見てドンキーコングリターンズのバイナリを解析するスレ
解析っていってもデータの構造を調べるって意味です

2 ：

まとめ　http://www18.atwiki.jp/dkhax/
ちなみに現在俺一人で頑張った成果↓
ドンキーコングリターンズ　音楽ハック〜とげとげタルめいろ〜
http://www.nicovideo.jp/watch/sm15530573

3 ：

ぜんぜん人がこないから、いろいろ説明しとく
ドンキーコングリターンズ(以下DKR)のISOをWiiScrubber,WiiBrowseで展開すると.pakという拡張子のファイルがでてくる
それがDKRのステージファイルで、ステージ構成・画像・モデル・アニメーション等が圧縮されて入っている
.pakファイルは上のWikiのDKDKというソフトで展開できて、データの種類ごとに分類し、抽出やら置き換えができる
で、それらデータの構造を知れば改造が可能になるから、みんなで相談や意見交換しながら解析していこう、というのがこのスレの趣旨

4 ：

構造というのは、何バイト目に何のデータがあるのか、ということ
データとしてはそのデータに関するデータ(サイズ・オフセット・子データの数など)、識別子、実際のデータ、などがある
一応言っておくと、ファイルのバイナリデータはバイナリエディタで見ることができる
バイナリエディタにはStirlingなどがあり、一応上のDKDKもバイナリ表示機能がある

5 ：

ちなみに、ISOには.pak以外にもいろいろな拡張子のファイルがあって.rasという音楽ファイルはもうデコード・エンコードが可能

6 ：

まあ、今の説明だとわからない人も多いだろうから最初のうちは質問にも答えるよ

7 ：

ファイル上げた方がいいかなー
ひとまずこれからはスプライトのデータを探そうと思う
そもそもスプライトで障害物や敵が管理されてるかわからないけど

8 ：

それっぽいのを発見した
MREAデータは最初に何かのテーブルがあって、そのあとで名前付きの何セクションかに別れて圧縮データが入ってる
圧縮方法はDeflateでzlibを使って圧縮してあった
MREAファイルは.pakファイルに1つだけ入っているし、セクションの圧縮データを見るかぎり、オブジェクトの配置を管理していると思う。

9 ：

人寄せage
これがファイル編集のためのソフトDKDK
http://www18.atwiki.jp/dkhax?cmd=upload&act=open&pageid=18&file=DKDK.zip
これが1-1のステージデータ
http://ll.la/f9SV

10 ：

もういいや
外人でも探して解析することにするわ
てか、俺しかレスしてなくてワロタｗｗｗｗｗｗｗ
俺興味ひこうと必死ｗｗｗｗｗｗｗ

11 ：

見ているほうが楽しいんだ

12 ：

お、レスだ
一緒に解析しようぜ！
たぶん俺より経験豊富な人もいるだろうけど、やっぱり興味ないんだろうな

13 ：

MREAのテーブルの意味が分からないorz
誰か意味が分かった人がいれば教えてくれ
俺はひとまずUSB Geckoでアセンブリの泥沼をさまようことにした
ステップ実行はできるがサーチがなぜか途中で止まるという…

14 ：

サーチできるようになってた…
テーブルの意味は単純にMREAの解凍データにおけるエントリーのサイズっぽい。
解凍データが何を表しているかはまだわからないけど

15 ：

テーブルのエントリ数はどこに書いてあるんだろう？
ヘッダ部にはエントリ数らしき数字があるものの、微妙にテーブル部のエントリ数と一致しない
ちなみに今解析しているMREAデータはこちら
http://www1.axfc.net/uploader/Ne/so/117801.bin

16 ：

はいはい、メモリダンプ見たら分かりました
ここに書きこむと自己解決するみたいだな
ヘッダ部の0x40の数字はエントリ数その1。各エントリは4バイトで、解凍後のデータのサイズを表す。
ヘッダ部の0x44の数字はエントリ数その2。各エントリは16バイトで、用途は不明。サイズらしきデータと、謎の整数値が含まれる。
エントリその2はエントリその1の真下に書きこまれている。
ヘッダ部の0x48の数字はテーブルの下にある文字列の個数。これら文字列はおそらく解凍後のデータの種類を更に細かく分類するためのもの。
WOBJ(World OBJect),COLI(Collision)とかがあるけど、詳細は不明。
ヘッダ部にまだわからない整数値があるからモヤモヤするけど、RASファイルの場合はわからないのを適当に0で埋めても正常に動作したから
適当にやって大丈夫かもしれない
ひとまず圧縮データの詳細を調べることにしようと思う
解析を手伝ってくれる奴はいつでも歓迎

17 ：

解析をしていてずっと思っていたのが、このゲームはいろいろな制御にスクリプトを使っているのではないかということ
文字列らしきデータがところどころ格納されているし、PARTやらCSKRはほとんど文字列で構成されている(どうもこれらの場合はプロパティを設定しているっぽいが)
MREAの解凍データにも多くの文字列があった
ただし、デバッグ用の文字列かもしれないが

18 ：

俺は>>11だけが支えで解析をしている
解析には直接関係ないが、.NET用zlibの"zlib.NET"が不具合持ちで自分でzlibのラッパーを作ることにしたわ
あんなのがいかにも正当な.NETにおける実装だぜ、って言ってるみたいなのが悲しい

19 ：

DKDKのおかげでrasを再生できました。
解析頑張ってください。
応援してます。

20 ：

やっとまともな文章のレスが…
はい、がんばります
でも、一緒に解析していいんだよ？
zlibの使い方になれるまで手間取ったがラッパーはできた。
引き続きMREAの解析を続けようと思う

21 ：

http://www1.axfc.net/uploader/Li/so/109750.dat
Zlibのラッパーを作成して晴れてMREAの解凍データを得ることができたのでアップしとく

22 ：

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の変換に挑戦するべきだろうか

23 ：

画像は思ったより簡単そうだが、ややわからない所がある
そこがわかれば煮るなり焼くなり好きにできるんだが、、、

24 ：

コロコロと解析対象を変えているから今何をやっているかわからないかもしれないが、
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 不明

25 ：

普通に考えて車輪の再発明を避けるためドンキーコングリターンズの画像は広く使われる画像フォーマットを採用しているはずなんだが…
更に疑問なのはたまにヘッダの解凍サイズの値と実際の解凍データのサイズが一致しない時があること。
メモリダンプではデータは正常に解凍されていた。ということは>>24の内容は間違っているということか？

26 ：

申し訳ない、こないだ作ったzlibのラッパーのミスで実際より大きくデータサイズが膨らんだようだ…

27 ：

TXTRはおそらく基本的にはビットマップだと思う
データサイズがピクセル数の倍数になっているものがほとんどだから
ピクセルあたりのデータサイズは最小で4ビットがあるっぽい
そうでなければピクセル数がバイト数を上回る場合を説明できない
画像に詳しい人、吸い出し経験がある人のアドバイスがほしい…

28 ：

明らかにゲームキューブのテクスチャのフォーマットを採用しているな
devkitProのgxtexconv.exeでビットマップ画像をCMPRフォーマットに変換してみたところ、TXTRに非常に似たバイナリが生成された。
ちょっくらソース参照してコーデック作ってくるわ

29 ：

コーデック作るのに10個のフォーマットに対応しなけりゃいけないのが想像以上に面倒だったので、
ここはマリオカートハックのChadderzのソースを流用することにした。
ライセンス的にはOKなはず

30 ：

変換できたわ
まだ上下が逆なんで修正したらアップする

31 ：

今回のはわけわからんバイナリじゃなくて普通の画像だから安心してクリックしてくれｗ
専ブラならサムネがでるかな
豚テクスチャ
http://up3.viploader.net/ippan/src/vlippan236539.png
ドンキーテクスチャ
http://viploader.net/ippan/src/vlippan236540.png

32 ：

ふむ　いい感じだね頑張れ

33 ：

>>32
ありがとう
テクスチャハックが可能になったら人寄せもしやすくなる…はず
気になるのは、ヘッダの情報に画像フォーマットが含まれていないのではないかということ
ほとんどの画像がCMPRで一部RGB5A3だが、ヘッダに共通性がみられない
さらに一部の画像は未知の形式で、ゲームキューブ・Wiiの形式のどれでも変換不能だった
まあ、どうせ俺の勘違いか間違いで終わるだろうが

34 ：

どうもミップマップが関係してるっぽい
マリオカートやらスマブラで使われているtex0フォーマットは通常画像に加えて、縮小画像を保持している
それと同様に幾つか縮小画像を保持しているならサイズが合わない説明がつく
ちなみに未知の形式といってたやつはRGB5A3でデコードできた。

35 ：

ひとまずパレットなしの画像の読み書きを実装した
実装したと言ってもコーデックはChadderzのを使い、ビットマップの拡大縮小は.NET Frameworkがやって、俺がしたのはヘッダ情報の記入と
データの圧縮くらいで、手間はかかってない
テストして動作したらデモ動画とTXTRに対応したDKDKをアップするわ
パレット画像は今のところ実装予定なし！
ステージに含まれる枚数的にはかなり少ないし、
Wiiの画像フォーマットで一番優れているのはおそらくCMPRで、ユーザーはそれ一択でおｋだから

36 ：

細かい修正をするのに手間取ったが、一応バグはなくなったと見える
テストは明日か明後日しようと思う

37 ：

先に言っておくが、画像を開いていくとメモリのドカ食いが起こる
100MBとか余裕で食うんで注意

38 ：

テストに失敗した。
どういうことかというと、まずファイルロード画面(ドンキーやディディーが左から右へと走る画面)から先に進まなかった
かといってフリーズしたわけではない。
以下、原因の推定
1.内部的にファイルサイズを保持し、ファイルサイズがそれ以上だったらエラーとしてリロードを試みる
　これは無い。なぜかというとRASはキチンと読み込み、再生することができたからだ。
2.Riivolutionに問題がある
　これも1と同様の理由で否定されるほか、正規のファイルを配置したところキチンと読み込んだ。
　これはRiivolutionにファイルサイズの限界があるからだ、といった推測は誤りとなる
3.PAKデータの先頭の16バイトの数字(キーと呼んでいる)が間違っていた
　正規のファイルのキーを適当な値にいじって読み込ませたところ、動作した。よってキーの値は適当でも良いことになる
4.DKDKのファイル組み立てが間違っていた
　これは微妙であるがオフセットの値がありえないところを指している、といったことがあった場合、ゲームはおそらくフリーズするはずである。
　とはいえ、これしか原因はありえない。
テクスチャのミップマップの扱いが怪しいと思う。データサイズが、同じ縦と横、ミップマップの画像数をもつ画像と異なっていた。
よく調べて修正しようと思う。

39 ：

応援しかできないって、なんかいやだな

40 ：

応援してくれるだけでもいいと思うようになった
ステージ改造が可能になれば多分人は増えるだろうし、それまでの辛抱だと思う
TXTRのリビルドに間違いが見つからない…わからんorz

41 ：

今週は私用で活動時間がとれない
やめたわけではないのでご心配なく
ところでRiivolutionの速度の遅さが目に余る
どんな実装したら3倍程度の読み込み時間になるんだ

42 ：

ISO直下のファイルがあることに今気づいた
PAKファイルがあったので見てみたが、ステージのPAKとやや構造が異なっていてDKDKの手直しが必要っぽい
こんな所にファイルがあると知っていたならそれに合わせて最初から作ってたのに…

43 ：

テクスチャのサイズがオリジナルと異なっていたのが読み込み失敗の原因だったぽい
なぜだ？　RASファイルは問題なく読めたのに、PAKは大きさを揃えないと読めない
ひとまずデモ動画つくるわ

44 ：

>>43
朝から乙です

45 ：

だめだ、なぜサイズによって成功不成功が決まるかわからないと進めない、というか進みたくない
読み込みプロセスがわかればヒントがあるかもなー
でも逆汗はしたくねえな
誰か助けてください。

46 ：

やっとわかりました、読み込みエラーの本当の原因が
答えは単純、データサイズは0x40バイトにアラインしなければならない、という規則を破っていた
データのテーブルを見てみると、データサイズの末尾2バイトが00,40,80,C0のものしかなかった
そこで、データをすべて0x40に揃えたところ、やっと読み込むことができた
これで意気揚々とデモ動画をつくれるぜ

47 ：

渾身の人寄せage
テクスチャハック動画
つhttp://www.nicovideo.jp/watch/sm15833993
DKDK本体はちょっと待って

48 ：

気力があるならどこをハックしたか動画中に説明文いれたほうがわかりやすいかもね

49 ：

>>48
わかりにくいって意見が出たら作ろうかな
まあ、空に大きくHello Worldって出してるから問題ないと思うけど

お次は何をしましょうかね
MREAは最後に回した方がいい気がしてきた
あれはステージを組み立てる設計図みたいなもんだし、いろいろわかってないと難しい
モデルいくか？
ちなみに俺はコード書けるだけで、画像処理やら音楽変換は完全な素人だから常にググってる
言語や知識は問わないからコード書ける人は手伝ってくれるとうれしい
3ヶ月かけてまだRAS(STRM)とTXTRしか実装できてなくて、正直一人じゃ気が遠い

50 ：

一応TXTRの編集と、ステージ以外のPAKに対応したDKDK最新版(変更はDKUtils,DKUtils.Native,DKUtils.Handlersのみ)
http://www18.atwiki.jp/dkhax?cmd=upload&act=open&pageid=18&file=DKDK.zip
テクスチャハックして動画作って宣伝、知り合いに紹介などどんどんしてください

51 ：

バグ見つけたorz
ちょっと待って

52 ：

http://www18.atwiki.jp/dkhax?cmd=upload&act=open&pageid=18&file=DKDK.zip
もう大丈夫だと思うけど…

53 ：

CMDLを現在解析中
モデル関連でわかっていることを挙げると、
CHAR:
モデルの設計図。このキャラの名前は何、モデルは何を使う、アニメーションは何を使う、といったことが記述されている
CINF:
ボーン(開発者はどうやらジョイントと呼んでいたっぽい)の情報
CMDL:
モデルのいろいろ。テクスチャなど
CSKR:
スキンの情報
関係あるかわからないデータ:
CPRM、CSMP、CAUD

54 ：

難しいな〜CMDL
ていっても一番最初にあるスクリプトっぽいデータだけ難しくて後は単調な配列っぽいから、
最初さえ何とかなれば簡単そうだ
わかってることを書くと、
スクリプトは「データ型」「データサイズ」「データの種類」「データ」の順で並んでいる
データ型にはPASS、INT、CLRがあってPASSはデータのキー、INTは整数を表す。CLRはわからん
データサイズはバイト単位で指定される
データの種類はいろいろあり、CLR(データ型とは別みたい)、DIFF(Diffuse)、RFLV、RFLD、OPAC(Opacity)、TRAN(Transparent? Transformation?)などがある
ただ厄介なのが、データにはデータ型で指定されたもの以外にデータの種類に応じてプロパティが含まれる
これらの意味を一つ一つ理解していかないとモデルのインポート、エクスポートは実現できないだろう
また、スクリプト群の前と、個々のスクリプトの前にそれぞれヘッダが用意されており、それもほとんど意味が分からない
開発者はデータを一般的なモデリングソフト(3DS Maxやらmayaやら)で作成しているだろうからそれらのフォーマットを理解すればこのデータの理解にも役立つと思う
一応呼びかけるけど、3Dモデリングに詳しい人、どんどんご協力ください

55 ：

いちおうCMDLでぐぐってみたら、なんと、メトロイドプライム2はCMDLを使用するらしい
他にも被るデータが大量にあり、おそらくゲームエンジンは同じのを使っている
製作元は両方レトロスタジオ社で、過去の資産を有効に活用してるっぽい
ここらを調べればいろいろわかるかも

56 ：

俺が一生懸命調べてたのはマテリアルのデータだったらしい
メトロイドプライム2のファイル解析プロジェクトMPxViewer(最新リリースが5月だが)のソースがクソ役立つ
これは解析が捗るわ

57 ：

今mayaのチュートリアルを見て色々調べてる
RFLVやRFLDは反射が関係してそうだ、とかわかってきた
チラシの裏にでも書いてろって感じですねｗｗｗ
要は活動してるよってことです

58 ：

MPxViewerの助けでCMDLの構造はほぼ理解してしまった
スキニングやアニメーションは後回しにするから、ひとまずビューワーを作成していこうと思う
そのためにはまず3Dプログラミングを学ぶところから始めなけりゃならないが

59 ：

構造自体は大体わかったけど所々にある数値の意味が分からない
それに、メッシュデータの1エントリごとのサイズがまちまちで、どこに見分けるためのフラグなり文字列なりがあるかもわからない
一つ朗報なのはバーテックスデータの変換はできるようになった
テストしてみたところ花っぽいものが出てきた

60 ：

俺が一番嫌いなのはバイナリ中にフラグが含まれている場合なのだが、CMDLはフラグだらけで非常に煩わしい
しかもビット単位でフラグが指定されているから8ビットすべて理解するにはかなり手間がかかる
ドンキー開発者の方は何ら困らないからしょうがないんだけれども…

61 ：

ふとどこかに開発者のデータとかないかなーって思うことあるよね
まぁ頑張れ

62 ：

そうだね
開発者のデータは無いけどWiiに関してはリバースエンジニアリングが進んでいるからその情報を元に推測してる
それにS○Kのドキュメントが流出してるからそれも参照しながらやってる
CMDLの状況だが、フラグは大体わかってきた
それでもまだ理解できていない数字がたくさんある
手伝ってくれるという人がいるなら、現在わかっていることを詳細に書くが…
いい加減しつこいかな

63 ：

wiiマリオみたいにｴﾃﾞｨﾀｰまで出来るのは時間がかかりそうだね
でも応援しているよ

64 ：

まあ、多人数でやってるわけじゃないしな
といってもwiiマリオのエディタも一人だった気がするし頑張ろうと思う
俺の見積もりで最も時間がかかると見たのがRAS音楽で、TXTR画像やCMDLモデルはその次にかかると見ていたから
ここを終えればエディタにだいぶ近づくはず

65 ：

現在の進捗状況
ヘッダ部：ほぼ解析完了
マテリアル：結構残ってる。CMDL内では統一された数値でもMREAでは違うという値がある(MREAにもマテリアルがあることは前に言ったと思う)
バーテックス：解析完了
ノーマル：解析完了
UV：解析完了
メッシュ：ほぼ解析完了。謎のベクトルあり。ヘッダ部にはマテリアルや幾つかの項目への参照がある

66 ：

http://viploader.net/ippan/src/vlippan242711.jpg
だいぶ前に可能になってたバーテックスの表示画像
JPG画像なので心配しなくていいよｗ

67 ：

あ〜　メッシュがわからん
CMDL先頭のフラグによってメッシュのエントリのバイト数が1〜2バイト変化するが、それら増えたエントリの意味が分からない
そのフラグが付いているCMDLの個数を調べてみたところ、CSKR(スキン)データの個数とほぼ同一となった
面白い事にどのステージデータでもCSKRの個数はフラグonのCMDL数から3引いた数になっている
これらのことから判断して増えた1、2バイトはスキンメッシュアニメーションに関係する値であることは想像できる

68 ：

「ドンキーコングリターンズ　改造」でググったら俺の動画とこのスレが一ページ目にきた
まあ、そんなキーワードで調べる奴はいないだろうし、あまり人寄には役にたたないな
CMDLのメッシュのエントリの先頭につく1バイトは必ず3の倍数になることがわかった
何を表しているんだろう
1.列挙体
3の倍数にする意味がない
2.データサイズ
なんのデータサイズだろうか？　スキンメッシュアニメーションに関連があるという過程からすると、全く的はずれな推測になるが…
3.データの個数
同様に、なんのデータの個数だろうか？
4.オフセット
これはありえない　3の倍数だけ進んだデータはまだ同じエントリ内だから
5.フラグ
ありえる　だが、3の倍数が(ry
6.ID
IDであればそれぞれ違う値になるはずだが、同じ数値を持ったエントリが大量にあることからこの推測は否定される
7.数値自体がメッシュの形状やアニメーションに影響する
この場合非常に厄介である。ゲームを動かしてみて実際に実験をしながらやっていくか、アセンブラを読みといて必死に解析するか、
運が良ければ他のモデルフォーマットから相当しそうな値を探し出すことが出来るか
いずれの場合でも非常に手間がかかるのは事実
しかも、「運がよければ」の選択肢である他のモデルフォーマットを参照する、という手段はとうの昔にやっているので残り2つの泥沼しか残っていない
数値自体が影響を与えていないことを願っている
そもそも、この追加の1〜2バイトがメッシュデータ内に存在するかどうか判定するためのフラグやらなんやらがヘッダ内に存在しない
ということは他のデータ部にそれが存在するか、あるいは「このデータが存在するから追加の1〜2バイトも存在する」といったデータ間の関連付けが存在するか

69 ：

行き詰って行き詰って、もうだめかと思ったけど、スマブラやマリオカートで使用されているmdl0に類似したデータを発見した
というより、もろにCMDLのメッシュデータと同様の構造があった
ちょっとChadderzやKryalのソースコードを覗いてくるわ
これがダメだったらRる

70 ：

わかってきた　わかってきたぞ
まず、メッシュデータに含まれる謎の1〜2バイトはやはりスキンメッシュアニメーションに関係ある
どう関係があるかはまだ調べてる
スキンメッシュアニメーションを疑い始めてずっと平行してCSKRデータの解析に挑戦してきたがようやくわかってきた
これは挫折せずに済みそうだ

71 ：

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のヘッダにある謎の整数値が鍵となってくるはず

72 ：

考えてみれば非常に簡単なことだ
・メッシュデータの値が10段階の値しか取らない
・メッシュデータはすべてのスキンのデータにアクセスできなくてはならない
この2つのことを考えると、メッシュデータはスキンデータに次のようにアクセスするはずである(というよりそうでなければおかしい)
スキンデータのインデックス＝メッシュヘッダの整数値×10+メッシュデータの値÷3

73 ：

メッシュエントリの解析が完了したのでフォーマットを書く
ヘッダ
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のインデックス

74 ：

それにしても、まだ見てくれている人はいるのだろうか
最近停滞し続けていたからもう見限られたかなｗｗ
残ったマテリアルを解析できればいよいよビューワーの製作に取り掛かれる
一部不明な値を残しつつ来たが、それはエクスポートを実装して実験すればいいし、RAS音楽のように色々入力する必要のない値も存在する
(RASにも音量関係の数値=重要な数値がありそうだと最近思い始めたが)

75 ：

>>74
何もできなくてすまん (´･ω･`)

76 ：

いいんだ、定期的に書き込んでくれればモチベが保てる
欲を言うならDKDKを使ってみての感想やバグ報告なんかをしてくれると嬉しい

77 ：

ここいらでToDoリストを書いとく
・RAS音楽のコーデック作成←済
・TXTRのコーデック作成←パレット付き以外済　パレット付きは実装予定なし
・CMDLのコーデック←50％(把握は80％)　CSKRのコーデック←ほぼ済
・CINF(ジョイントデータ)のコーデック
・ANIMデータのコーデック
・CHARデータのコーデック
・PARTデータ及びSWHCデータのコーデック
・MREAデータのコーデック
全体としてみるとスーファミ時代のドンキー並みに改造可能になるまでの道のりのうち半分以下ってところか
とはいえ、最難関の一つと見ていたCMDLの把握がそろそろ完了することを考えると、結構早く終わるかもな
半年以上必要だったら事情でそれ以降は一年以上作業ができないがorz
その場合はDKDKのソースを公開するか…

78 ：

マテリアルわかんねー
わかったことを羅列する
1.マテリアルにはヘッダがあり、フラグ、列挙体等が含まれる
2.ヘッダの後はアトリビュート(属性)とおぼしきものが存在する
3.属性にはCLR(データにキーを持つものとマテリアルの色をRGBAで表現するデータを持つものの場合がある)、TRAN(透過部分を示すテクスチャの情報)、INCA(発光部分を示すテクスチャの情報)
　RFLV(反射？)、RFLD(反射？)、RIML(Rim Light、縁どりの光？)、DIFF(Diffuse?)などがある。
ヘッダの内容と属性は少なからず関係していて、因果関係をつかめないことにはインポータ、エクスポータは作れない
この中で特に意味が分からないのはRIMLで、必ず球体(例えばこんなの　http://viploader.net/ippan/src/vlippan245103.bmp)が指定されている
この球体を使ってどうやって縁取りを描画しろと言うのだろうか？
そもそも、反射やらDiffuseやらはマテリアル自体に適用されるものであってテクスチャに適用されるものではない。
それなのに、あたかもテクスチャそれぞれに反射光やら拡散光やらを設定してそれを合成することで、マテリアルを構成するかのごとくデータが並んでいるのはどういうことだろう？

79 ：

うん？ちょっとまてよ
例のS○Kのドキュメントにはテクスチャそれぞれに光を設定できるようなことが書いてあるぞ
俺の勉強不足か？

80 ：

ひとまずビューワーを実装中
これが出来ればいろいろ実験できるし、モデルが表示できる事自体が楽しいはず

81 ：

DirectXに関しては全くの初心者なので試行錯誤してようやく三角形のレンダリングまで行えるようになった
モデル表示の基礎部分はできたので、続けて作っていこうと思う

82 ：

どうもモデルデータのフォーマットに間違いがあるっぽい
ドンキーのモデルが穴だらけになってしまった

83 ：

下らんバグのせいで3、4日悩まされ続けて例のごとく諦めようかと思っていた…
ようやく正しくモデルを読み込めた
まだテクスチャがおかしいのでそこを修正したら画像を上げる

84 ：

問題はほとんど解決したが、まだ一部問題が残っているので明日画像をアップしようと思う
まあ、ゆったり待っててくれ

85 ：

ここですかさず人寄せage
ようやくドンキーコングリターンズの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

86 ：

http://www1.axfc.net/uploader/Sc/so/297366.zip
一応CMDLの表示に対応したDKDK最新版(正式ではない)

87 ：

…絶賛ダウンロードありがとうございます
今のところ解析と関係ないDirectXで詰まってる
その問題が解決したらディディーのテクスチャの以上の原因を調べようと思う

88 ：

いつもの人がダウンロードしてくれたみたいだｗ
すぐ解決すると思ってたDirectXの問題が思ったより難しい
解決したらまた進捗状況を書くから少々お待ちを

89 ：

DirectXの問題は解決した
テクスチャに関しては進展がない
見てる方も楽しくないだろうから画像を上げる
http://uploader.sakura.ne.jp/src/up71256.png
http://uploader.sakura.ne.jp/src/up71257.png

90 ：

テクスチャ座標(UV)には二種類ある
一つは普通に32ビット浮動小数点型で記述されており、そのままUV座標として使える
もう一つは16ビット整数型で、浮動小数点型に変換した後何らかの数で除算するとUV座標に相当する値が算出できる
そして今日はその「何らかの数」を大量のデータから推測、実験して導出することに成功した
その結果がこちら
Kalimba
http://up3.viploader.net/ippan/src/vlippan248647.png
DK
http://up3.viploader.net/ippan/src/vlippan248646.png
DKは一目瞭然、kalimbaの方は一見正常だが、公式サイトで確認したところまだうまくいっていなかった
うーん、わからん

91 ：

本日の成果
Diddy Kong
http://up3.viploader.net/ippan/src/vlippan248772.png
Donkey Kong
http://viploader.net/ippan/src/vlippan248773.png
単純にテクスチャが上下反対だったみたいだ
ただ、ドンキーのネクタイを見てみればわかるように、部分部分では反転している
もうそろそろテクスチャの基本的なところは終わりそう

92 ：

ドンキー
http://up3.viploader.net/ippan/src/vlippan248868.png
画像が左右反転していた理由が判明した
DirectXにおける座標系は左手座標系だが、Wiiゲームでは右手座標系らしい…
テクスチャの問題だったわけではないということ
ようやく異常がなくなったので、シェーダー作成にとりかかろうと思う
TRANあたりは簡単に実装できると思う

93 ：

TRANの実装が終わったがどうもよろしくない
どうやらTRANで透過する対象のテクスチャがCLRで指定されているもの以外の場合もあるようだ

94 ：

TRANで透過しているものの以外にCLRにアルファチャンネルを含む場合があるようだ…
そこまではわからないのでひとまず置いといて次のシェーダ作りに進むことにする…

95 ：

DirectXの仕様にはCMDLビューワーの実装を始めてから何度となくつまずかされてきたが、
今回テクスチャがまともに表示されない問題の原因をようやく突き止めた
テクスチャが正方形になっていないと自動的に正方形になるよう画像が切り取られるみたいだ…
(まあ、正確にはDirectXというよりD3DXの仕様だが)
まあ、まともに表示できそうなので、近いうちにアニメーションの実装に移る

96 ：

CINFの解析を始めたが例によって難しい
最初にあるものは明らかにジョイントの名前のテーブルだが、そのあとは単なる整数の羅列にしか見えない
しかも複雑なバージョンと単純なバージョンがあって更に複雑にしている

97 ：

…明けましておめでとうございます
このスレを見てる人はどれくらいいるかわからないけどまだ解析続けます
まあ、今年は徐々に厳しくなってくだろうけど

98 ：

>>97
一人でよく頑張るなぁ、なにもしてあげられないけれど
とりあえず、明けましておめでとうございます

99 ：

ここ最近忙しくて解析をしてない
まあ、焦ってもわかるものではないが、4月までくらいしか解析できないから少し頑張ろうかな
4月になったら解析を一年程中断する予定
一年後ヤル気があったらまたスレ立てして解析するかな…

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

ウォーシップガンナー２　ポータブル　改造コード２ (154)
[CWC]ウイニングイレブン 2013[改造] (126)
■ 改造ロックマンについて語るスレ ■Stage16 (815)
KH BBSFM 解析 【CWC】 (504)
【PSP】ヴィオラートのアトリエ【CWC】 (165)
新ギレンの野望 改造コードスレ2 (111)
--log9.info------------------
ビートルズに勝てる現代音楽ってあんの？ (148)
タモリ倶楽部でジョンケージ特集！ (122)
ECMレーベル　ＥＣＭ (112)
【IRCAM】スペクトル楽派【フランス】その２ (106)
4分33秒は駄作 (107)
現音っぽいクラシック曲を挙げていくスレ (145)
眠る時に聴く現代音楽 (124)
４分３３秒に最適のｺﾝｻｰﾄﾎｰﾙ (112)
NAXOSとｹﾞｿｦｿ (106)
ｹﾞｿｵｿとｸﾗｼｯｸの違いについて (147)
ウェーベルン＾点描主義 (177)
【ﾍﾟﾙﾄ】新しい単純性【癒しの音楽】 (167)
イオニザシオン (105)
【シルクロード】喜多郎【グラミー賞】 (105)
ｹﾞｿｵｿﾁｯｸな即興をうｐするスレ (160)
ユン･イサンよ、永遠に！ (132)
--log55.com------------------
〒030青森中央　その３
日本郵便 職場のムカつく人
【西八の】八王子郵便局Part2【吉牛】
郵便局による保険の詐欺、押し売りの被害者の会
非正規社員たちが正社員を目指す（人生のTP30）
今年の年賀販売状況
期間雇用社員(旧ゆうメイト)外務情報交換268 ★２
川越西郵便局　ゆうメイト集まれ！