FWEffectSequenceを作ってます

時間が空いてしまいましたが、大量のダウンロードがございまして、それ以外のネット関係がままならない状態にありました。
我が家は未だにISDNのため、すぐに回線がテンパってしまうのです。

大量ダウンロードの原因は、出来心でDAZ Platinum Clubに入ってみたのですよ（←アフィリエイトも始めてみました）。
入会特典で、いろいろ3Dデータをもらえるのはありがたいのですけれども、あまりに多すぎて辟易していたという次第です。
おかげで、当初の目論見であった、Platinum Clubに入ったら$1.99アイテムの大人買いをしまくろう、という友達百人できるかなみたいなウキウキ気分は、くじけてしまってまだ実行できておりません。

もちろん、ダウンロードしながら、その裏でプログラムもしておりました。
C++をやっている時に思いついたことですけれども、FWEffectSequenceクラスを、メインウインドウのオフスクリーンにしようかなと。
v3もv4も、FWEffectSequenceの結果をメインウインドウのオフスクリーンにコピーし、そこからメインウインドウに転送しておりますので、これを統合することにより、メモリ消費と転送時間が少し減る想定です。
実は、前回のv3でそれをやりかけておったのですが、あまりいじると各所との絡みが破綻しそうなので、テスト用の別プロジェクトを作って始めました。

それから、C++でやった時間軸の管理が、我ながら面白い物ができたと思っておりますので、それをRbに持ってまいりました。
画面効果と時間軸というのは、密接な関係にありますからね。
そこまでやったら、時間軸つながりでアニメもやりたくなって、今それを作っている段階です。
アニメデータは、Poserで使ったアニメーションを連番画像で書き出すと、それがそのままFamous Writerで使えますから、ある意味データ作り放題でいい感じです。

このところの私の動きはそんな所です。
ほぼ日記のような内容ですけど(笑)、生存報告ということで。お目汚し失礼いたしました。

Poserと六角大王の座標

週の前半は、Poserをいじって遊んでおりました。
攻略対照の3人娘を作ろうと思いつつ、Poserと六角大王の連携を研究したりいたしました。
六角モーフを作ることができたらいいなと思ったんです。
素材を作ることより、ファイルの仕様とかに興味が移ってしまうのが、私の悪い癖でしょうか(笑)。

まず座標の単位ですが、六角で144倍で読み込むと、気持ちよく作業ができそうです。
フィギュアの高さが、だいたい六角のグリッドの立方体に収まります。
これは、六角で100*100*100の立方体（グリッドの立方体の大きさ）を作って、Poserで「フィギュアの高さ」にして読み込んで、それぞれの数値を比較することで確認いたしました（厳密には、143.なんたら倍になる）。

そこまではいいとして、問題はobjファイルの頂点座標の精度です。
Poserは、浮動小数点になっているようで（精度は不明）、六角は「0.0000」のように小数点以下4桁の値を吐きます。
六角の方が精度が粗いのですが、Poserのように小数点5桁以下がある数値は「四捨五入」で読み込まれているようです。
切り捨てや切り上げではなく、四捨五入ですな。
従って、Poserに戻す時に1/144しても、小数点5桁以下が失われるので、微妙にずれることが考えられます。

そして、モーフは頂点の順番が変わらないことが条件になりますが、これが六角で読み込むと変わります。
従って、六角でPoserのモーフを作ることは、それぞれ単体では不可能という結論になります。

ただ、プログラムを書いて、objのfコマンドなどから座標順を導き出し、変換することは可能かと思われます。
1.Poserで吐き出したobjから、座標値を144倍にし、さらに小数点5桁で四捨五入したobjを作成
　　→頂点順が変わらぬまま、六角の座標系に変換
2.144倍のobjを六角で「等倍」で読み込んで、すぐobjを書き出す
　　→座標系が変わらないので、1で作ったobjと比較することにより、頂点順がどう変わったかわかる
3.六角で作業し、objで書き出す
4.2の情報を元に、3で作ったobjの頂点順を並び替え、座標値を1/144すると、Poserのモーフターゲットとして使えるファイルになる

あと、問題はobjのvnコマンドの値です。
1,2は、vを単純に任意倍し、vnはいじらないプログラムを書いて実験したのですが、問題なさそうでした。
ベクトルですから、数値が違っても、比率が同じなら大丈夫だろうと思いまして。
ここで面倒くさくなってやめたんですが(笑)、ベクトルがそのままだと、4の時点で問題が発生するかもしれません。
だめなら、手抜きをせず、きちんとベクトルを計算すべきでしょうな。

方針はなんとなく見えており、変換プログラムさえ作れば、六角でPoserのモーフターゲットを作ることは可能でしょう。
が、私としては、生活や時間的な都合もございますので、そこに労力を割くなら素直にCarraraかHexagonを買った方がいいかなと思い、現時点でこれ以上は突っ込まないつもりです。
というわけで、今日からFamous Writerを再開します。


4/15追記：
よく考えたら、Poserのモーフターゲットになるobjは、vだけあればいいんです。
従って、4は考えなくていいことになりますな。
あとは、テクスチャの位置は変わらないという特性を利用して、fから頂点順も整合できそうです。
ちょっとやってみたんですが、私の頭ではどれがどのデータだか把握できなくなったんで、あえなく玉砕ということで(笑)。

ThinkPadが

今週の頭に、Windowsノートパソコンが、ACアダプターを認識しなくなりました。
一週間ぐらい前から調子が悪いなとは思っており、今週サードパーティ製のACアダプターを買ってきて試してみても、うんともすんとも言いません。
修理に出そうと思っておりますが、Visual C++がインストールされているPCでもあるため、修理中はWindows版の開発ができません。
なお、調子が悪いなと思った時点で、ソースコードはバックアップしてありますので、開発への影響は軽微です。

という経緯のもと、C++のほうはお休みして、週の後半はv3をいじり始めました。
もう、前からv3は見たくないコードになってるとか申し上げておりますが(笑)、C++で作ってみた経験を踏まえ、アプリケーションとVMとコンパイラを分けてみたらどうかなと思い、半ば出来心でチャレンジを始めました。
特に前の二者は、C++を経験する前は一体で考えておりましたので、明確に分ける事により、少し見やすくなるかなと。
あと、最近は難度の高いプログラムをしてたんで、有り物をいじるような楽なプログラムをしたいなと(笑)。
とはいえ、v3のソースは45万文字2万行強ありますから、なでるだけでも時間がかかっております。

それから、ある方からご指摘いただいて、Windows Vistaのプログラムの本を買って参りました。
OSのバージョンを見て処理を振り分ける箇所があるのですが、今までVistaのバージョン番号が不明だったので、v3.09までは明確にVistaには対応しておりません。
まずはそこから解消しつつ、APIを洗い直したいと思っておりますが、REALbasic自体がVistaでの動作は不明です。
この辺は徐々に情報を集め、対応できるところからして行きたいと思っております。

と、いうわけで、次のアップはv3になると思います。

シューティングほぼ移植完了

一応これで、シューティングの基本的な所は再現したつもりでございます。
・C++実験室

まだ修正というか、命令の追加でやりたいことがございますので、もうしばらくこのシューティングをいじってゆきます。

一点目は、スコア表示がStr関数で左揃えなので、sprintfの%8dっぽい仕組みを作って、右揃えにしたいと思っております。
いや、作ってはみたのですが、Windowsでヒープを壊す代物になり(笑)、今回のビルドでは外してあります。

二点目は、まだESCキーでのPAUSEを作っておりません。
これは、READY/GAME OVERのウエイトや、タイトルのRETURNキー待ちと併せて、v3のWAIT命令みたいなものを作り、それで書き直そうと思っております。
確かにウエイト関係、C++ではこのようにハードコーディングしておりましたが、改めて移植すると面倒だなと。

三点目は、オフスクリーンのスクロール命令を持たせようと思っております。
このゲームですと、すでに描画した背景はスクロール命令を使い、一番上の行だけスプライト描画で書き換えれば、すっきりするかなと。
ただ、やってみないと、速度的にどうなのかというのがございますので、この件はどうなるかわかりません。

そんなところを、来週はやってゆく予定です。

チュートリアルができました

範囲境界を使った文字描画でございますが、REALbasicのMid関数に相当する物がないと厳しいので、しばしペンディングです。
Midを作ろうと思ったんですが、例によって文字列なので、一歩間違えるとシステムごと死んだりするため、遅々として進みません。
副産物と申しますか、文字列クラスは新しい物になり、より強固になりました。

文字関係が煮詰まったので、再び配列に手を出したところ、これがうまくいきました。
従って、チュートリアルのシューティングゲームの、敵機を作る事が出来、先ほどタイトル等も含め、全て終わりました。
これからC++をWindowsに移植して、明日には公開できるかと思います。

当ブログで何度か書いておりますが、Windows/Mac OS X/Mac OS 9と、それぞれ違うコンパイラで作っております。
最近の私のスタイルは、Mac OS Xでメインの開発をし、Windowsで全機種共通のクラス等を作っております。
メインをOS Xでやると、REALbasicでのコンパイラも同時に作る事が出来ます。
Windowsでクラスを作っているのは、Visual C++はデバッガが強力ですから。
OS 9版は、プロジェクトにOS X版と同じファイルを組み込んでありますので、機種依存の部分をのぞき、OS X版での変更がそのまま反映されます。

プログラムに関しては、あと大きな機種依存の部分というのは、キーボード・マウスの取得と、音やムービーぐらいですか。
とはいえ、後者はQuickTimeなので、Win/Macともに大差ないコードになるかと予想しております。
その他のハイレベルな機能・命令等は、全機種共通のコードで行けるのではないかなと。
C++で作る事が出来る目途が立ってきたかな、と実感しております。
とはいえ、文字列操作など、もっと勉強は必要ですかな(笑)。