ある程度、データ保存の用意が整ってきました。 ので、某音ゲーを見て作りたくなった「多関節モデル」のデータ構造を思案して書き込むトピ。 作りきれるといいなぁ(

プチコン3号が発売されてすぐの頃、初音ミクが走るアニメを関節付き2Dモデルで作っている人がいましたね。 あの作品はどうなったのだろう

今さっきそれの動画を見ましたが、公開キーも作った人のNNIDも解りませんでした…… 捜索範囲動画サイト内だけだし、もう少し探せば見つかるかな？今日はもうしないけど。

とりあえず保存形式から考えましょ。 モデルに必要なデータはおおまかに分けて「画像」と「パラメタ」。なので、ファイルとして保存する際に 1,画像とパラメタを統合したファイル 2,画像とパラメタを別々で保存したファイル 二通りの保存形式がある。1を選ぶ場合のメリットとして、フォルダ内のファイルの数がある程度軽減される点と、「参照する」という処理が少なくすむ点。2の場合、同じパラメタを扱うモデルが多いときは容量が減る点や、わざわざ配列を切り分けずに別々の処理ができる点。 大雑把にまとめると1は処理が楽。2は解りやすい。

悩むけど、これは2のやり方でいいかな。画像増やしてパラメタそのまま～って出来ればエディタ使わなくても創作がかなり捗るはずだし。 となると、画像とパラメタそれぞれでどのような中身にするか…… 画像はGSAVEしたやつをアレコレしたやつでいいとして、パラメタに要る情報は (画像上の)X,Y,幅,高さ,リンク先SPID,(リンク先SPからの相対的な)X,Y,Z,R ９つ。数の範囲は-512~511がいいかな。文字列化処理が要るってなったら圧縮のこと含めると大変そう。 オブジェクトの数は[配列の長さ]/9で出せばいっか。1の方法だと個数の情報必要だったけどこっちだと要らないね。

とりあえず、二つのファイル○○○.grp(画像)、○○○.pmt(パラメタ)があるとしてー ○○○.grp 画素1,画素2,画素3,… ○○○.pmt {X,Y,W,H,LINKNUM,X_,Y_,Z_,R_},{X,Y,W,H,LINKNUM,X_,Y_,Z_,R_},… 中身を含めたファイルの構造はこんなんで。 ねむい。

【余談】 実際に作ろうとすると、ファイルのロードにいちいち間が空くのは嫌なので、別スロットにコード化したデータと参照用サブルーチンを書くことになりそうですねー。 プログラムの初期設定→指定したファイル名からデータを読み込み→別スロットにファイル名と同じ名のサブルーチンを記述。→データを文字列にして書く。 こういうとき、画像とパラメタそれぞれのサブルーチンを作るよりは、DATA文ではない、データをあれこれする命令を作って、それらを二つでセットにしたサブルーチンを作るようにすれば見やすいですねー。多分。疲れ

sayさんだったかな。そういうの作ってましたね。

おいらできるのなんて、せいぜいこれくらいだよぅ 【ZR8X7K3E】 ☆少しいじってるので、スクショとはちょっと違います。

最初の主コメ» 某動画サイトのは、あんへるたんさん(NNID:ANGELTAN72)ですね。 後、かいしゅうさん(NNID:kaikai.jp)も画像のものを作っていました。自分はダウンロード出来ましたが、まだ公開されているかは分かりません。

これのことかい？ 元々ゲーム作れるツクールっぽいの作る時にスプライト24個までを多関節で自由にSPANIMできるやつ作ってそれのデモ用だったんだけど、あまりに扱いにくくて封印しちまったんよ、これは動画のやつにラスタースクロールのテスト足したやつ。

sayさんのプログラムを見させていただきました。パラメタ的に、今考えている構造と似ているようで少し安心しました。 使い辛いというのは、具体的にはどのようなことを指していられるのでしょう？ 結局のところ、サブルーチンは画像とパラメタで分けることになりそうです。

使い辛い、というか扱いにくい、ですね。 私がなんとなーくGUIの機能を先に考えていたときは、アニメデータの配列の編集方法や、関節部の回転方向の固定など、色々大変そうとは思いましたが。

お米 もしかして、ポケモンBWのバトルの時のモンスターの動きみたいな感じかな?

そんな感じですねー。 そういえば、モデルには回転運動以外にも、定義番号の変更(別のスプライトへ切り替える)のも必要だということを今になって思い出した。 モデルに必要なパーツの情報だけを作るのではなくて、一度全てのパーツの情報を作ってから、モデルにくっつくパーツのパラメタを設定するようにした方が良さそうですね。

一度閉めます。 アニメーションのタイムテーブルとか勉強した方がいいかな……