2007年2月の日記

NeoMupl、VB版の最終バージョンをアップしました。
本当にバグフィックスしかしていませんがこれからはC#でやっていきます。
そういえばMusicPlayerもなんとかしないとなー。
MusicPlayer1のリメイクとなるMusicPlayer6は公開していないみたいだし、そのほかの開発終了したものもソースを含めて公開しておきたいし。

そんなわけでクリアして、2周目やってます。夢をみる島(「みる」が正しいらしい)。
前回はマリンとあんまり一緒に歩き回れなかったので今回はマリンと一緒になるまでは記憶と情報を頼りに一気に進めて、マリンが一緒になってからはいろんなところで色々試してます。

そういえばNeoMuplのVB版、今見るとスキップ情報の管理が滅茶苦茶で、間違ったところからコピーしてきたり関係ないところに書き込み処理を入れてたりして、全然設定が反映されていませんでした。
VB版の更新はこのバグフィックスが最後になりますかね。

今日も夢を見る島やってました。
カラー専用ダンジョンで青い服を手に入れたり、レベル7までクリアしたり。
前まで単純なリンクの夢オチだと思っていたんですが、案外深い内容だったんですね。
風の魚の夢であることは間違いない。
だけどその夢は自分たちにとっての現実であり、夢が覚めるということは自分たちの存在自体が消えてしまうということ。
だから魔物たちは抵抗するんだけど、無邪気な住民は手を貸してくれる。
でもリンクは風の魚を叩き起こし、島を消すことでしか外へ出ることはできない。
そうしないと自分も島の土になってしまうから…。

今日はゼルダの伝説やってました。
夢を見る島です。
それもDX。カラーです。
手っ取り早くレベル2までクリアして、レベル3に入ったところで今日のところは終わりにしました。
そうそう、名前は「あいしてる」にしました。

いやー。ListBox、stringの配列しか受け付けなくて融通が利かないと思っていたら、まるっきり逆で、ToStringさえ実装されていればどんなobjectでも受け入れるのでめっちゃくちゃ融通が利くみたいですね。
思ったより楽に進みそうです。

そうそう、パネルγのプレイ動画をアップしてみました。
さすがにマシンの性能が足りずコマ落ちが激しい状態になりましたが、せっかくなのでアップしておきました。

NeoMuplのC#移植は順調です。
とりあえず今日は一番重要なファイル再生と停止を作りました。
もう、VBにあったのをほぼそのままC#に書き直しただけなんで簡単でしたね。

CharaBox3のバグ修正なんかもやってたり。
本当は前のバージョンで消したつもりだったのですが、バグ回避コードを書く場所を間違えていました(詳しく言えば、問題の変数のコピーの値だけをいじっていた)。

なーんもやってません。
.NETなら.NETらしいやり方でDirectShow使えるかなと思っていたのですが、やっぱり今までの方法と変わらなかったようで、結局NeoMuplは大部分単なる移植になりそうだということになりました。

ナマライザ、ふと思いついて読み込みを本体とは別スレッドにしようとして、BackgroundWorkerを配置して、読み込み待ちのファイル名のキューを作ったところで急にやる気がなくなって、突然LDrawのデータをMetasequoiaの形式に変換するLDR2MQOを作り始めてしまいました。

なんだかListViewのSortの挙動が怪しかったので、Array.Sortを使って自前で並び替えを実装しました。
そして今度は一度読み込んだログの破棄を実装してみました。

そうそう、最近NeoMuplもC#で作り直そうとたくらんでいます。
別に現在のVB版では致命的な問題があるわけではないのですが、どうにもセーブデータのいじるのが果てしなく面倒なのですよ。
いえ、果てしなくというほどでもないのですが、新要素の追加は行いたいのですが、それに伴う色々な部分の細かい改変が面倒なんですよ。
機械的な作業なのに自動化できなくて、面倒なだけの入力が続き、こういうのがつまらないミスを生み出して、つまらないがゆえに、もっとすごいところでミスしているのだろうと思い、見当違いなところばかり探す羽目になって、無駄な苦労を増やすばかりになってしまうのです。
で、そういうところを自動化するようなプログラムはVBではなかなか書きにくいので、他の言語に移そうということなのです。
特に曲の情報の入力フォームの統一は今のプログラムでは非常にやりにくいので、ユーザーコントロールを簡単に作れるVisualC#で開発したいということなのです。

LDrawのレゴのデータをMetasequoiaに移そうと頑張ってたんですが、標準で普通の3Dデータに変換できるPOV-Rayを使ってみてもMetasequoiaはPOV-Rayのデータは読み込めないし、DXFやLWOとかのデータ経由でインポートしても全然正確なデータが得られず、こうなったら自分で一肌脱いでLDrawのデータから直接Metasequoiaのデータに変換するソフトを自分で作るしかないと考え、とりあえず双方のファイルフォーマットを確認していたのですが、これがまた面白いですね。
LDrawのデータには実はテクスチャの概念がなく、絵に見える部分も実は全部ポリゴンで表現していたりするんですね。
それに、線の引き方にしても、境界線のみを表示するために線に追加データを付け加えたりしているところあたり、興味深いです。
で、実際に色々なことを自分のソフトでやるのは面倒くさいので、単なるポリゴンデータの塊にするところまではLDraw側のソフトでやってもらい、その先のLDraw式のポリゴンをMetasequoia式のポリゴンにするところだけを自分で作ろうと思い、ためしにLDraw式のポリゴンにまで変換して結果をMLCADで開きなおしてみると、見事に色が消えてしまいました。とほほ。
どうにも全部自分で変換するしかなさそうですが、どうにも色の概念だけがいまだによくわかりません。
説明がなんだかねぇ…。

そうそう、ナマライザのエクスプローラ表示は結構いい具合にほぼ完成しました。
最初びっくりするようなデータが出てきて、プログラムのミスではないかと思ったのですが、どうやらびっくりするほどおばかさんなロボットがやってきて歩き回った記録が残っていただけのようでした。
表示アイコンはディレクトリとファイルの2種類にそれぞれステータスコードごとに3種類ずつ割り当てて計6種類使っています。
ステータスコードごとの割り当て方は、2xx系が普通のアイコンで、3xx系が青いマーク、4xx以降を赤マークにしています。

1171897159.png

ふにゃさんが一区切りついたのでナマライザ作ってました。
ListViewでもDataBindingが使えるかなと思ったのですが、どうにもDataBindingが適用できるのはどうでもいいプロパティばかりで、肝心のItemsプロパティには適用できなかったようです。
おかげで自分で表示を更新するプログラムを書かねば…って、本来これが当たり前なんですけどね。
まあ、表示そのもののプログラムは、表示するべきデータを用意するプログラムと比べればずっと単純で楽な作業であるはずなのでいいと思うんですけどね。

ふにゃさん更新しました。
まだやるべきことはあったのですが小出しにしていきます。
ファイルサイズが結構大きくなっていますが、これは一部ファイルの形式をプログラムから使いやすい形式にしたのと、いちいちステージデータをコピーして作っているリプレイデータの同梱が大きく出ています。
それで、今回から、最新版に限って、最小限のファイルのみを入れたアーカイブも配布し始めました。
需要はなさそうな気もしますが、一応色々バリエーションがあるほうがいいと思いまして。
今日プログラム的にやったのは、エディタのシフト移動の改善と、操作説明でのシークレット機能の無効化です。
一方まだできていないのは、
・せっかくなのでもう一つぐらいシークレット
・無重力室へようこそ！
・ステージ遷移時のフェードアウト
・エディタからネット上に自作ステージを公開
・エディタでネット上からみんなのステージをダウンロード
などなど。
やりたいこと全部できたら、今度こそ本当に本当の完成で、開発終了ということになります。

本当は今日やろうと思えば更新できたのですが、やっぱり時間がなくてうまくチェックできていない状態でアップするのはよくないので明日更新することにしました。
今日やったことは、リプレイの演出の改良、つまり本当のリプレイの完成。
そして、今更ながらふにゃの動きに関する不具合の修正。
この不具合は本当はずっと前からわかっていたことなのですが、それによってふにゃの動きが変わってしまうため、改善に踏み切れないでいました。
ただ、今度リプレイを実装するともう本格的に手遅れになるため、今回を改善の最後のチャンスとして、思い切ってみました。
もちろん、今まで放置できたのだから重大なバグであるはずがないのですが、ふにゃの向きに関するバグなので、見た目に左右非対称で不自然ですし、もしかしたらどこかで向きが違うために変な動きになる可能性もあるということで、修正することにしました。
あと、リプレイに関しては、にっこりキーが記録されていなかったので、それも記録するようにしました。
これもこれで一度公開してからでは修正できない部分だったので、なんとか間に合ったというところです。
あと、内部的にゲーム本編とテストプレイのプログラムを統合しました。
これによる大きな違いはありませんが、今後の改良の際に両方に反映するのを忘れてテストプレイだけ古いということはなくなるはずです。

そういえば、そろそろスクリプトのほうも進めてやるかと思い、久しぶりに見てみたら、全然わからなくなっていました。
元々方針を間違えていたのは明らかだったのですが、ちょっと今はそれを修正することはできそうにもありません。

なんだか色々ありましたがとうとうリプレイが完成しました！
細かい演出は後回しにしているため多少そっけないところがありますが、基本機能としては十分に出来上がっているはずです。
listにpush_backしたらそれまでのendイテレータが無効になることに気付かずデータが壊れてしまったりとか、設定を使ってしまった後に設定変更を入れてしまって実際には設定が反映されなかったりとか、面倒くさい設計にしていたのを忘れて簡単に実装したらうまく動かなかったりとかしましたが、なんとか原因を突き止めて全部何とかしました。
ところで今気になっているのですが、ふにゃさんについて実装したい機能は現在結構たくさんあって、全部入れてこうとすると次の更新がどんどん先延ばしになっちゃうんですよね。
結構すぐ修正が必要だったものもあるし、こまめに更新していったほうがいいのか、それともどっちみち後でアップデートするから後でまとめて公開したほうがいいのか、悩みどころなのであります。

リプレイは最初のメインメニューのところで流れますが、今回録画した中にはかなりの割合で弟の作った面が混じってます。

今日はなぜかVBがよく落ちます。
実行した瞬間に不正な処理をしたためどうのこうのと因縁をつけられて。
まあ、実行する直前に保存する癖をつけてるので実害はないのですが、やはりどこか気持ち悪いです。
VBじゃなくて私のプログラム自体に問題があるならば実害があるわけですしね。

ふにゃさんの本編のほうは、リプレイの記録が出来上がったところで、記録しながらテストプレイ中です。
リプレイデータは、ステージデータの必要な部分を切り出して、更にキー入力情報や更に必要なデータなどを付加して、形式上はステージファイルと同じ方法で記録されます。
リプレイデータの記録に関しては設定プログラムで設定してやらないと全く保存されないので、プレイする前に、クリアしたときに自動的にリプレイ記録する確率、ミスしたときの確率、記録するファイルの最大個数、手動で保存するときに使うボタンを設定してやります。
クリアしたときの自動セーブは適当でいいのですが、ミスしたときの記録はあまり確率を高くすると難しいステージなどでは全部が一つのステージの苦難の記録になってしまって楽しくないので、確率を低めに設定しておくとよさそうです。

ふにゃさん、リプレイデータ記録のため、内部的に地味なところで改良を重ねていました。
それはもう、ステージファイル中の画像読み込みとか、クラス同士の無駄な依存関係を減らしたりとか。

ふにゃさんのリプレイ記録・再生を作ってました。
最初記録と再生は別々のクラスで別々のファイルに作っていたのですが、同じデータを扱うのに別々のファイルにプログラムを書いていたのでは不都合があるということで同じファイルにまとめて書くことにして、そうすると別々のクラスに書くこと自体がなんだか面倒になってきて、結局同じクラスに記録・再生の両方の機能を持たせることにしました。
とりあえず今日のところは両方ともキー状態の保持と再生は出来上がり、対応するステージデータとまとめてファイルに記録することが出来ればもう完成になるということになります。

えっとですね。
まずふにゃさんの反則的シークレット機能2つが、非常に高い確率で、両方同時に出てしまうことがわかったので、ある程度の期間はどっちか片方だけが出ている状態にするために、全く違う条件を設定しました。
で、現在考えているシークレット機能に関する実装は全て終わって、あとはシークレット以外の追加項目を作るだけになりました。
これがまた難儀なのですがね…。

んで、ドラクエ8やってました。
深緑の巨竜倒しましたよぉ。
ただ、レティス戦の時のようにまたハーゴン(主人公)が肝心なところで倒れて経験値が得られませんでした。
大事なところでククールの回復が遅いんですよね。
ゼシカもザオリクを覚えるそうですが好みの問題からザオリクを覚えるスキルには手をつけていませんし。

ふにゃさんのほうは、シークレット出現条件が全て出来上がり、そのうち内容を実装していないのは残り2つ、プログラム自体の変更を伴う部分です。
ちなみにあんこのグラフィックではバナナがブドウに変わったりします。

1171119063.png

ふにゃさんは今度の更新でかなりたくさんの部分を改良したり追加したりします。
それはもう、なんで今まで1年間以上も未完成を提供していたんだと思わせるほどに…したいのですが。
とりあえず、昨日の続きで、無重力状態での上下左右の接続はさすがにむちゃくちゃすぎるので廃止し、逆に場外負けを上方向にもつけるようにしました。
そして、キャラ絵をあんこ、サングラスをかけたふにゃの2バージョンを作ってオプションで変更できるようにしてみたりもしました。
あと、操作説明のところで、終了できなくなるバグを修正したつもりが、更に別の操作をするともっと悪い状態になってしまうことがわかったので、逆にどんな悪い状態になっても終われるように修正しておきました。
で、サングラスのことなんですが、サングラスをかけさせると黒背景のタイトルではサングラスが見えなくなるんですよね。
そこで、絶対に改悪にならないように、背景を黒以外にする方法を考えていると、デモプレイを背景に流すというのを思いつきました。
なんだか難しそうな気もしますが、しかし何とかできるような気もします。

1171033149.png

を、今日勢いで一気に動くところまで作ってしまいました。
ふにゃさんの話です。
地上のアクションができない以外は普通のふにゃよりも明らかに性能が高く、最高速も大きければ加速もよく、ステージの上下左右が繋がっているとみなして動くから、場外負けもなければステージ端の部分に反対側から侵入することもできてしまいます。
シークレット機能のうち、かなり条件が厳しいほうに入る予定なので、それ相応にかなりむちゃくちゃな性能にしてあります。
ちなみに、移動性能のよさは、普通と同じ性能だとものすごくとろかったために調整したものです。
動画を見てわかるとおり、移動しているとくるくる回りますが、とりあえずこれに関しては今後実装する氷の息の射出方向に影響を与えるようにしようかなと思っています。

ふにゃさんのグラフィックやらなにやらを作っていました。
なんとなく余ったスペースがもったいなく感じたので使わなかった絵を入れてみたりけち臭く他の画像リソースも空きスペースに詰め込んでみたり。
使わない画像を入れるというのは実際のところファイル容量的にはよくないのですが。
そして、ふわふわふにゃ計画とかグラフィック差し替えようの画像も作ってみたり。

1170859738.gif

昨日言っていたauto_resourceですが、書き換えられるところを全部書き換えたところで、実は一番威力を発揮するはずだった場所でauto_resourceが全く役に立たず、そこで使わなかったせいでauto_resourceがその最大の特徴を活かすことができなくなり、せっかく全部書き換えたのですがまた全部書き直すことになってしまいました。
まあ、せっかくまた全部書き直すことになったので、今までともまた違う方法でリソースの効率のよい管理を考えてみました。
元々ふにゃさんのリソースは必要になったときに初めて読み込まれ、その後は必要なくなってもプログラム終了までは解放せず、ずっと使いまわすようにしていました。
そこで、必要がなくなったら解放できるように、しかし使いまわしは効率よくできるように、という2つを両立させるためにauto_resourceの利用を考えたわけです。
ところがauto_resourceの仕組みはいらなくなったリソースが増えてきたらいらないもののうち古いものから消していくというものだったのですが、増えていくべきいらないリソースはauto_resourceの管轄外でいらなくなった瞬間に解放され、一方auto_resouce適用可能なリソースはいつでも必要になる可能性が高くてあまり増えたり減ったりしないということで、どのみちauto_resourceではうまくいかないということだったのです。
結局のところよく使われるリソースはいつでもメモリ上に常駐しているということになり、それだったらいちいちプレイ中に動的に読み込んだりせずに最初に一気に全部読み込んでしまおうというのが、新しく考えた方法です。
結局一番古臭い方法に行き着いてしまったわけですが、プレイを一時中断して画像を読みにいったりしなくて済むし、一気に読み込む画像は全部同じファイル内にあるのでディスクキャッシュを使って非常に高速に読み込めるはずなので、実は一番効率がよいのではないかと思います。
実際計測してみると、読み込み時間は0.1秒程度で、GIFのデコードにそれなりの時間がかかることを考えれば、十分な読み込み時間だと考えられます。
そうそう、操作説明である操作をすると、操作説明が終わらなくなるというバグを発見したので修正しておきました。

ふにゃさんの画像をauto_resourceに移行中です。
ただ、主人公の絵だけは特別な処理をしているためにauto_resourceへの移行は無理そうです。
それと、ヒートゾーンやアイスゾーンなどの半透明グラフィックは、実行時にYGAを生成していましたが、これを最初からYGAファイルにすることによってちょっとぐらいは読み込み負荷を減らせたような気がします。

CharaBox3バージョン1.01をアップしました。
いくらなんでも改良したのに何ヶ月も放置というのはいけない気がしまして。

そうそう、今、ふにゃさんのプログラムの見直しをやっています。
何しろCDIB32を使っているはずなのにCPlaneBaseの機能しか今まで使っていなかったので。
とりあえず今度は回転系を使って何かしてみようと考えてます。
リソース関係も、Bomber丸Worldに使う予定のauto_resourceを使って色々改善していきたいと思っています。

爆ボンのアブソリュート戦の動画をアップしました。
どうにもこれもまた運がかなり絡むようで、運がよければタイム3000前半が出たり、もしかしたら3000すら切ることができるかもしれません。

そういえば今日マウスを見てきたんですが、色々あるものですね。
横スクロールもできるマウスや手に負えないほどの多機能マウスなど、色々ありました。
マウスパッド不要のレーザーマウスはちょっとほしいかも。

プロフィールの基本機能がひとまず出来上がりました。
まず、スパム対策のためフォームはname属性をスクランブルした上、フォームの並び順そのものもシャッフルして、コンピュータから見てほとんど意味のわからない、しかしそれでいて人間から見ればあまり違和感のないインターフェースにすることができました。
しかもこのスクランブル＆シャッフルはフォームの構成をパラメータとして渡せば掲示板などにも応用できる優れものです。
しかも、色やアイコンを選ぶフォームは設定から自動的に内容を調べてきて適切な表示ができるように、ことにアイコンについてはJavaScriptを利用して項目を切り替えるたびにアイコンのプレビューが出るようにしました。
で、それで、いよいよプロフィール書き込みを作ろうかと思って作ったところ、記録されるには記録されたようなのですが、画面に反映されないんですよね。
どうにも特定のIDのときにクッキーに保存したデータが読み出せなかったみたいなんですね。
暗号化が悪かったのか、復号処理に問題があったのか、それともシリアライズがおかしかったのか、見当もつかなかったんですよ。
それで、とりあえず全ての元凶を暗号・復号処理だと決め付けて、それらの処理を取っ払ってみたところ、やっぱりうまくいかなかったんですね。
でも暗号化されていない分、記録されたデータは丸見えだからクッキーの内容を記録した変数を見ればわかるだろうと思ったんですよ。
すると、データ中には不自然な「\"」があったというわけです。
どうやらPHPはクッキーのデータに対しても特殊文字をバックスラッシュでエスケープする機能がついていたらしく、暗号化されたら暗号化されたで暗号化された結果が特殊文字だったり、しなかったらしなかったでデータ中に元々あった特殊文字がエスケープされ、うまく動かなかったというわけです。
そんなわけで、めでたく動くようになったはずなのでよろしければ試してみてください～。

ドラクエ8やってました。
ちょっとした発見です。
おどかして追い払った敵からは経験値はもらえないがアイテムはもらえる、というのはよく知られたことですが、メタル系の敵はおどかし損ねたときに自らの意思で逃げることはしないのです。
つまり、普通に戦えばアイテムごと逃げられて得られなかったアイテムも、おどかして逃がせば手に入る可能性が高くなるのです。
だから、経験値よりもアイテムがほしい場合なんかは、下手に戦うよりもおどかしたほうが確実ということになるのです。
もっとも、レベルも上げたいので普通に戦いましたが。

PHPのarray_merge関数、仕様上重複する配列の要素が配列だった場合、古い配列は新しい配列でそっくり置き換えられて古い配列は残らなくなりますが、その点を改善して重複する配列の要素が配列だった場合、更にその配列同士をmergeする、mixed_mergeを作ってみました。
添字が数値だった場合array_mergeと全く異なる挙動を示すのが少し問題ですが、まあ、そっちのほうがTGscriptには合っているので。