「ふにゃさん」に関する日記(14)

全てのQ＆Aにそれぞれ対応するページからリンクしました。
そうそう、今日はメテオスでダウナスのチャレンジやってたら５００万点超えました。
アキヤメまた一つ消えました。
ふにゃさん間に合うだろうか。
いろんな性格のステージが作りたいと思えばいろんな人に作ってもらえばそれがそのまま性格付けされるという考え方で少し早めに公開してプレイヤーの立場の人に作ってもらうとか。

ナマライザの解析処理部を改良しました。
以前のだと複数のファイルを読み込むと一つ読み込むたびに解析を行っていたのですが、今回で全てのファイルを読み終わった後に解析を行いようにしたのでたぶん回数分だけ軽くなっています。
ついでに、ステータス表示に現在の読み込み状況を表示していたのですが、その表示そのものを受け持つ部分と表示される文字列を作る部分とを分け、ステータス作成部分では現在の状態のリスト(通常は0～1項目)をStringArrayクラスにつんで一番新しいものだけを表示させるようにしました。

それに伴ってStringArrayクラスも改良しました。
戻り値の一部がVariant型になっていたりしたのを修正して、新しいメソッドDeleteValueを追加しています。
DeleteValueでは指定した値を持つ要素を全部消去してその分を詰めます。

ふにゃさんのBGMをループできるようにしました。
設定項目を増やしてそれを認識してループフラグを操作するだけだったのですが、設定プログラムのほうでyaneLineParserと同じはずのクラスで読み取りポインタが増加しないバグがあったので正しく読み取れない事態が発生していました。
もちろん即行で原因を見つけて直しておきましたが。
標準BGMのほうはどうしようかなぁ。
敵が周りにいて変化、というのは難しいかもしれないし重いかもしれないし。
ふにゃ本人の状態だけで変化させるんなら簡単で軽いはずなんですよ。
例えば眠ったときに静かな曲調にするとか…。

メテオスのスタッフロールにあった楽譜、あれオープニングの一部なんですね。
MIDIに打ち込んで気付きました。

ふにゃさんステージエディタにゲームオーバー時のペナルティの設定項目をつけました。
ペナルティというのは１でもあったように、ゲームオーバーのときコンティニューしてやり直すために消費されるバナナの数で、今回はステージファイルごとに決められたりします。
今回は１のような１ステージバナナ５個の制限がないので、標準ペナルティは100です。
１のときの10はやさしすぎました。
コンティニューしたくない、だけどどうしてもコンティニューしなくてはクリアできない、そんなときの最後の手段にしたかったのです。
ただ、任意に変えられるようにすると０にしたり何万にもしたりする人が現れそうなので、一応制限をつけて、10～999の間にしています。
そうそう、設定項目の値に制限をつける機能もちゃんと今回つけてます。
しかし、実は困ったことに、ゲーム本体のほうではペナルティはおろか、ペナルティに使うバナナの数の保存すらできていないのです。
急がねば。

レゴで6835のUFOをLDrawに入れてから、本体をばらして箱の裏にあった組み換えバージョンを一個だけ作ってみました。
本当は３つあったのですが１つしか再現できませんでした。
あと、昔作っていたオリジナルの海洋警備隊本部兼自宅も再現してみました。
なんだかところどころ微妙に違ってたり一番大切な浮き輪マークの部品が見つからなかったりしているのですが、近いうちには完成しそうです。

今日は爆ボンのページ二箇所更新しました。
レッドマウンテンのボス、スプリガン。
採掘ロボです。ハッチが開いた上体でマグマの中から出てくるあたり、ハウトの高温への強さが伺えます。
ホワイトアイスのボス、リッパー。
蜘蛛です。子供は使い捨てという鬼のような母です。

ふにゃさん、今度は残り人数の表示を作りました。
今更？と思われるかもしれませんが、実際遅いです。
今までずっと見えないのが不便で不便で仕方なかったのですが、残り人数が1になったとき後がないことを明確にしつつナビゲーションバーのデザインが崩れないようにするための方法がなかなか思いつかなくて先送り先送りになってしまいました。
で、結局実装した方法というのは、残り人数を"x"+3桁で表示し、残り一人のときは"LAST"、ゲームオーバーのときは"OOPS"とすることで文字数を一定にすることにしました。
最新の画像でもアップしようとも思ったのですが今一「新しい！」って思えるものがなかったのでやめておきました。

バンジョーとカズーイの大冒険を結局ゴビには関わらずにクリアしてしまいました。
ラクダのゴビが関わるのはジグソーピース3つとハニカム1個。
そのうちゴビをいじめないのはジグソー1個のみ。
これを手に入れておけばゴビをいじめずに完璧クリアができるはずだったのですが、一応全然関わらないようにして、ジグソー97個でグランチルダ戦に挑みます。
グランチルダに挑むために必要最低限のジグソーは94個なのですが、98個集めてゆくと体力が2倍になるため非常に楽な戦いになるのですが、ゴビがいろんなところに現れるおかげで1個足りません。
もっともグランチルダの攻撃なんて見切れて当然なので体力が半分以下でも別に問題ないのですが、さすがに一度は負けました。
最終段階までは追い詰めたんですけどね。
そしてクリア。エンディングでたった一度だけ敵キャラ紹介が出るのでそれを全部記録してやろうとメモを用意して意気込んでいたのですが見事玉砕。
ほとんどのキャラはメモし損ねてしまいました。

ふにゃさんのエディタのステージ全般設定を改革しました。
今までのは拡張するたびにあらゆる場所に散らばった変数・コントロール群を全部変更しなくてはいけなくて、見た目も悪かったのですが、今度で全般設定は一箇所で管理しているものをそれぞれの場所で得て使い、見た目は、項目名と値をリストにして表示しておき、ダブルクリックで変更するようにしたため、非常に使い勝手がよくなっています。
文字列の項目はデフォルト値の設定が効かなくて困ったものなのですが直そうと思えば直せますし、変える必要も別にないので必要なときが車では放置プレイでいきましょう。
さりげなく残り人数の設定項目も増やしたりしました。

ふにゃさんの設定読み込みができました。
今のところBGMを鳴らすかどうかとフルスクリーンにするかどうかだけですが、快調に動いています。
もっとも、セーブの方法がすぐには見つからなかったためセーブはまだですが、その代わり設定プログラムのほうでは読み書きの処理は慣れていたのですぐに読み書き共にできました。
ついでにウィンドウの大きさに合わせて設定項目の大きさを変えられるようにしたり、BGMの設定にコモンダイアログを使ったりするように改良もしました。

MusicPlayer3に自動バックアップ機能をつけました。
1分おきにリストに変化がないかどうか調べ、変化があったらセーブし、なければ何もしません。
終了処理も同じ仕様で、変化があったらセーブし、なければ何もしません。
チェックも含めたセーブの処理をタイマーと終了の2つの条件で呼び出すようにしたのです。
変化があれば、というのは単純に変化を起こす処理でDirty=Trueをしただけです。
面倒なのでアップはしていません。
というよりここのところますます自分仕様に拍車がかかっていまやどこをどう変更したのか自分でも把握しきれていないのです。
まあ、要望があればアップしないでもないですが。

爆ボンのページをまた更新しました。
今度はブラックシティ1面ですが、正直、言えることは「死ぬな」だけなので書きにくかったのですが、なんとかそれなりに書くことはできました。
ついでに、マスターの攻撃についても書いてみました。
これはちゃんと書こうとすると攻略本の通りになってしまうので、自分の耳で聞いた言葉をタロットの名前として表記し、攻略本を見るまでもなく実物を見れば一目瞭然の攻撃の実体は、適当にお馬鹿な解釈をつけて楽しんでみました。

部屋を掃除しました。
本当はレゴで遊んでやろうかと思っていたのですが、レゴを入れた箱を出すともうそれ以上のスペースがなくなるので床面積を広げるため掃除に踏み切ったのです。
窓付近に机があるのですが、実は数年間机としては使われておらず、椅子には埃が積もっていました。
使っていないのならその場所に荷物でも積めばよかろうものでしょうが、現実にはその場所にある窓は唯一の採光場所であり唯一の通風孔であり唯一の避難経路でもあるので、壁をふさぐ面積、高さなどから見て、現状の机以外に選択肢はありませんでした。
しかし机としてはもう使っていないので椅子は撤去します。
そうなると、机は単なる避難経路への足場という役割しかなくなるので、その部分に何とかして光と風と避難の邪魔にならないように物を置く方法を考えなければなりません。
実はその机は机としての役割を失ってからはいつか使うかもしれないがおそらく二度と必要ないもの(主にプリント類)を積んでおく倉庫となっており、つみあがる高さから言っても倉庫利用で問題はなさそうです。
唯、これからは乱雑に置かず、倉庫として機能するよう、それなりに整理して置くのです。
とはいえ、元々雑多なものを置く場所なので分類はできません。単純に大きさだけで置く場所を決めるのです。
元々置いてあったものは当然ほとんどが本当に必要のないものだったので、裏が白紙のものを選んで適当な大きさに切り、メモ用紙として再生することにしました。
机より下側にある壁は光を取り込むためガラス張りになっているので、机の下にも物を置くことはできません。
椅子も撤去したので常に空き場所となるのですが、ここは一時的に物を置く場所として使うことにしましょう。
用が済んだらそこだけは必ず片付けるようにすれば最低一箇所床がある状態になります。
次は床掃除。
しかし、散らかっている荷物は3分の2が弟のものだし、今散らかしている自分の荷物も、非常によく使うから床に山積みにしているので、片付けてしまうわけにはいきません。
ということで後は棚の整理だけして、本来の目的である床面積の確保はほとんど実現されなかったのです。

ふにゃさんのセーブデータの問題、答えを出しました。
データには何の加工も施さず、それと明らかに分かる名前で、ゲーム本体と同じフォルダに作ります。
取ったバナナの数はそのまま数字として書き込まれますし、シークレット情報も一つ一つ個別に記録します。
別に不正チェック機構なんかもつけたりはしません。
ですから、テキストエディタ等で開けば、データの意味が分かる人なら簡単に改竄ができてしまうのです。
しかし、改竄したい人には改竄させておけばよいのです。
こういうことを批判する言い方として、「本来の楽しみ方ではない」という言葉をよく聞きますが、他人のプレイに迷惑(例えば不正に得たデータで他人と競う行為など)をかけたりしない限り、本来とは違う楽しみ方をしても良いと思うのです。
レースゲームでは逆走は本来の楽しみ方じゃありませんし、アクションゲームで亀を踏み続けて無限にリトライ回数を増やすのも元々の難易度を完全に崩す行為ですが、それなりに受け入れられています。
他人に迷惑をかけないのなら、不正の範囲が自分一人にしか及ばないのなら、データ改竄もまた、逆走や無限1アップと同じだと思うのです。
確かに開発者としては、プレイヤーには本来の楽しみ方で楽しんでもらいたいのですが、だからといって自由な楽しみ方を阻害するのも意味がないように感じるのです。
それに何より、改竄ができるとデバッグが楽です。

クイズαをバージョンアップしました。
http://www.hyuki.com/d/200510.html#i20051020190000にあったアルゴリズムを見て、昔から正しいかどうか不安に思っていつか正しいかどうか調べてみようと思いつつ結局調べなかったアルゴリズムがどうやら本当に正しくなかったらしいので、書き換えようと思って自分のソースを見たらこっちは計算するまでもなく誤ったアルゴリズムだったため、もう、修正するしかありませんでした。
以前のアルゴリズムでは、全くシャッフルされない場所が大量に残る可能性があるばかりでなく、n^2乗のオーダーで処理時間が長くなり、元々クイズとしてはありえないのですが、数千問を超える問題集だとかなりの時間がかかってしまうため、全く実用的ではなかったのですが、改良版では乱数さえまともに出れば必ず均等にシャッフルされますし、処理時間も、処理数がnのオーダーであり、更に乱数を使う回数も半分にしているため最低でも２倍以上の高速化にはなっているはずです。
一応正解のアルゴリズムは、自分が考えていた、多分前のアルゴリズムよりはよい結果になるはずのアルゴリズムとほぼ同じものでした。

ふにゃのページ更新しましたよ。
機知のバグとインストール・アンインストール方法を掲載しました。

そして、実はアクセス解析により訪問者の見るページの傾向に、説明をほとんど見ずにダウンロードする人と、説明ばかり読んでダウンロードしない人の二極化が見られたので、それに合わせるよう、リストのページからさっさとダウンロードできるようにはして、なおかつ紹介ページは紹介ページで充分なボリュームを持たせ、その上更に、私のことだからこんなことをしたらきっとリストのページか紹介ページのどちらかを更新し忘れたりすると思うので、リストのページのほうは紹介ページから必要な部分を抜き出して自動生成するようにしようかと考えています。
幸い、リストのページは完全に型にはまった書き方をしているので、プログラムによる作成が容易です。
ついでに言うと、ファイルサイズは更新し忘れ率が非常に高いのでこれもプログラムで自動生成するようにしたいです。
しかしこれを実現するにはまずダウンロードページ全般の構成を見直さねばなりません。
専用ディレクトリを作るか作らないか、どちらかに統一しないと不規則でプログラムには扱いづらいのです。
もちろんパネルγのように紹介ページにやたらと多くのファイルを使っているものもあるのでここはディレクトリ作成に統一で。
しかし、数少ないとはいえ検索サイトからHTMLページに直接飛んでくる人も多いのです（どっちや）。
いきなりディレクトリに移行して前のページを消してしまっては何かと不便でしょう。
だったら両方作ればいいのだけれど、例によって片っぽの更新を忘れるのでやはり同じファイルは作るべきではなさそうです。
それならばリダイレクトを使って、HTMLページに飛んできたら自動的にディレクトリに飛ばしてやればよいのです。

Bomber丸Worldのキャラのページを誤って削除してしまいました。
手元にもサーバーにももちろんゴミ箱にもファイルが残っていないのでキャラ紹介ページは１から作り直しになります。
まあ別にいいでしょう。
あんまり気合入れて作ってなかったし、半分忘れかけてたし、アキヤメのほうにもっと詳しいのがあるし。

ふにゃさんのセーブデータを作ろうとしているのですが、仕様がなかなか固まりません。
セーブデータと設定は分離すべきか。
シークレット機能によりセーブデータと設定は連動しているのですが、設定はエディタで変更されてもいいけど、セーブデータでは簡単には改変されたくない。
既にユーザー定義BGMの設定は分離することが決まっています。
はっきりと分離するメリットがあったためです。
セーブデータは簡単には改変されたくないのですが、デバッグのためや、ゲームを破壊的に楽しむ人を思うと、ここは別に一緒くたにして改変されてもいいかなと。
だけど、普通の人が設定ファイルを開いてついうっかり、は避けたいし。
暗号化も面倒だし、意味もあまりないし。
う～ん、簡単な符号化とチェックサムとか。

ふにゃさんの設定プログラム、BGMが読み書きできるようになりましたよ～。
yaneSDKのCLineParserをほぼそのまま持ってきました。

女郎蜘蛛ですよ女郎蜘蛛！でっかいの！
一匹は大きい女郎蜘蛛。もう一匹は今まで見た中でも1・2を争うぐらいのもっとでかいの。一匹はそれに匹敵するぐらい大きいの。
蜘蛛は元々好きなんだけどこれまで立派なのは数年ぶりだったので、それも小学校以来だったので手でつかむ気にはなれませんでしたがそこらの棒切れでちょっといたずらしていました。
蜘蛛は棒切れをガリガリ噛んでて、その感触が棒を通して指に伝わってくるのが面白かったですわ。

ふにゃさんのステージエディタにシフト移動機能を追加しました。
その他ボタンを押すとポップアップメニューが出てきます。
マップウィンドウに直接メニューを入れるとメインウィンドウのメニューが消えてしまうのでその対策でメニュー専用のフォームを作っています。
メニュー専用フォームはマップウィンドウごとに割り当てられていて、相互に連携しています。
シフト移動機能そのものは再帰を使って1ずつ移動しているため効率はよくないです。
しかも1ずつ動かす処理も馬鹿正直にマップチップ一つ一つを移動しているため効率は悪いです。
気が向けば効率のよいアルゴリズムで書き直すかもしれません。

ふにゃさん、ステージ内に埋め込まれた画像を読み込む処理の改良に成功しました。
やはりこの前考えたとおり、GlobalAllocで確保したメモリアドレスと違う位置を渡していたのが原因だったようです。
mapを使って識別子とデータを関連付け、データクリア時にはそれぞれを別々にメモリ解放します。
要するに今回はこの関連付けるデータを一つ一つGlobalAllocで確保したというわけです。
また、確認はしていませんしその必要もないと思うのですが、以前のものだとデータの長さ(というよりデータの要素数)にほぼ比例した検索時間が必要でしたが、新しいほうだとその対数オーダーでの増加になるので大きなステージでは読み込みが速くなるはずなのです。
もしかしたらメモリの解放忘れがあるかも。でも多分無いかと。うん。自分を信じよう。スペル間違い以外に不具合は無かったんだし。

ミディビのMIDI受信プログラムを少し改良しました。
データを簡単に検査することでMIDIかどうかを判別し、MIDIデータでなければ保存しないのです。
MIDIには必ず存在するデータというものがあるのです。
それが存在するかどうかさえ調べればおかしなデータが送られてきたときにエラーを出すことができるというものです。
ミディビは一応完成したら配布するつもりなので悪意のあるデータを排除するというのも必要になってくるわけです。
そういえばPerlの正規表現ってバイナリデータに対してはどう動くんだろう？
PHPについてはどうやら一行のデータを前提にしているらしいのですが。
ん？でも掲示板とかで複数行のデータを渡したときもちゃんと動いてる？どーなってんだろー。
しかしもしバイナリデータでも正規表現が使えるなら強いですよ。
なにせ正規表現だけで曲名も作者もコメントも抜き出せるのです。
JavaのおかげでMIDIのバイナリデータを直接扱うことはありませんでしたがやはりいずれにせよMIDIファイルの知識は必要だったようです。
それでも一応MIDIメッセージの段階まではMIDIに踏み込むことができたのでできる自信はあります。
正規表現の挙動しだいですが…。

ふにゃさんの設定プログラムを作り始めました。
今本体に実装されている設定項目はBGMだけなのでそちら優先で。
設定項目が増えても更に増やす手間が必要以上に増えないように、作業時間がO(n^2)じゃなくO(n)になるように、追加された設定の画面への反映を半自動化するようにしてみました。
ただ、少しばかり本体と設定プログラムでデータの読み書きの勝手が違うのでそこらへんまた手間が増えそうです。

ミディビ、ついに保存できるようになりました。
実際は昨日日記を書いた直後にできたのですが、プログラミングのページの更新と微調整とかで時間をとられました。
今後の方針としてはそろそろいい加減ビュークラスも本番用にして、あと、保存する前に聞けるようにしたりというのも、複数のトラックを編集できるようにしたりとか、音色を変えたり、そこらあたりを最優先事項として作っていくことにしています。

ふにゃさんステージデータ改訂版。
ステージファイルに埋め込まれたGIF・JPEG画像は読み込めませんでした。
それで必死に原因を探して、原因がOleLoadPictureでエラー-2146827807が発生していることだということを突き止めました。
しかし、そのエラー、ヘルプにも記載されていなければ、どこのヘッダファイルを見てもそのエラーを返すコードもなし。
そこで、エラー番号で検索を掛けてみたら、唯一http://72.14.207.104/search?q=cache:geyhWb4AH8QJ:www.eggheadcafe.com/ng/microsoft.public.vc.atl/post22719515.asp+2146827807&hl=ja&inlang=jaが見つかりました。
ここのフォーラムのやり取りを要約すると、
「OleLoadPictureでエラー-2146827807が発生しているがこの意味が分からない」
「GlobalAllocを使いなされ」
ということだったのですが、実は今回、既にメモリ確保にはGlobalAllocを使っていたんですよね。
それで完全にわけが分からなくなってやけくそになってテンポラリファイルを使って読み込んで、普通のファイルならバッチリ問題なく読めるので一応解決はしました。
しかし、今考えてみると、ステージファイルに埋め込まれた画像というのは、GlobalAllocで確保されたメモリの途中にあるんですよね。必ず。
そして、グローバルメモリオブジェクトを扱うAPIを見てみると、どれもこれもGlobalAllocやGlobalReAllocで得たハンドルを使っているんですよね。
グローバルメモリオブジェクトをバイト配列とみなした途中の変数のアドレスじゃないんですよ。
まあ、分かりやすく言えば、
int *p = malloc(256);
free(&p[1]);
みたいなことをしていたというわけですね。正しく動くわけがありません。
だったら画像を読むときはテンポラリファイルの代わりに、改めて画像データだけを入れるメモリ領域をGlobalAllocで確保してそこにステージに埋め込まれたデータをコピーして使えばよさそうな気がしますがまだ実行していません。

ミディビの開発のため色々調べものをしていました。
CGIに渡すデータは、ヘッダ→空行→データ、という形式。CGIが返すデータとよく似た形式です。
具体的には、Content-Type: multipart/form-data;～だとかContent-Length:～をヘッダに記述して、データ部にMIDIのバイナリデータを書いてやればCGIにMIDIのデータが送られるわけです。
しかしOutputStreamに書き込まれる前にデータサイズが分からないためSocketでサーバに接続して得られたOutputStreamに直接書き込むのは危険そうです。
一応テスト用のOutputStream派生クラスでMidiSystem.writeはOutputStream.write(byte[] b, int off, int len)しか呼ばないことが分かっているので、MIDIデータを一時保存するためのOutputStreamを用意してそこから改めてサーバに接続して得られたOutputStreamに書き込むのがよさそうです。
これを日曜日あたりにプログラムとして書くつもり。

爆ボンやってました。
今度はどきどきモードでドラゴとリバイアを倒しました。
攻略ページのほうの更新はありません。
やっぱりどきどきモードだと強くなっています。

爆ボンの地下水路の主のページを作りました。
今までの分に加えてわくわくモードとどきどきモードでの正攻法での攻略法も載せています。
あと、タイトルをちょっと改良。「 - 」だと横に伸びすぎるので「>」を区切り文字に使用しました。
今後順次タイトルをこの方式に変更してゆきます。

ふにゃさん、マップの処理が著しく非効率的だったので表示される部分だけを描画するように改良しました。
これで速度的な効率は大幅アップ。
ただでさえ敵味方の相互作用に時間がとられるので、描画ごときに時間をとられている暇は無いのです。
そして、そのついでに、数値計算の都合で少し誤差がおきて背景が1ドットずれるバグを修正しました。
しかし、そのついでにメモリ使用量を見てみると、結構メモリ消費が大きく(もっとも、yaneSDKを使っている時点で10MBは最低使うのですが)、プレイしているうちにどんどん、本当に1面クリアするたびに何MBぐらいの勢いで増えてゆくのです。
そこで私はメモリリークを疑い(何しろメモリリークを起こすようなプログラムを平気で書く人ですから…)、デバッグのためnew/deleteのログを吐き出すようにしてやったのですが、どうもメモリリーク箇所は無い模様でした。
BGMはまあ適当に結構平気で10MBぐらい食いそうだからと考えて、とりあえずBGMを切って勢いはゆるくなったのですが、やはり増えるものは増えるわけで。
実際のところ、新しく敵が登場すると、そのときにプログラム終了まで開放されないメモリを確保するのですが、それにしても多い気が…でもやっぱりメモリリークやらをしていない以上、大きくメモリを食うのはここぐらいのものなので、これが原因なのでしょうか…。
それと、ステージファイルは保存のときにプレイ用と編集用の2つを同時に出力するようにして、標準以外の画像を使うときは画像データそのものも書き込むようにしました(配布時に画像を添付する必要をなくすため)。

慣れないことをしたため早速失敗しました。
爆ボンマップ作成プログラム、マップチップの演算子をオーバーロードしてsetに入れたときうまく動作するようにする手はずだったんですけど、オーバーロードのやり方を間違えていたためオーバーロードではなく無関係な演算子を定義したということにされ、定義したはずの演算子が定義されていないことにされてしまっていました。
どうも、比較演算子の使用中に比較すべきデータそのものが変更されてしまってはまずい(例えば、a<bという比較をしただけでaやbの値が変更されてしまっては比較の意味がなくなる)ため、データに勝手な変更ができないようconstを付けて作らねばならなかったようです。
しかしそこがそれ、constを書き込み禁止程度にしか理解していない私のこと、constをつける位置を間違えてしまいまして。
bool operator<(const CMapData& rhs) const { return m_Depth<rhs.m_Depth; }
とすべきところをあろうことか
const bool operator<(const CMapData& rhs) { return m_Depth<rhs.m_Depth; }
としてしまっていたのです。
前者は{ return m_Depth<rhs.m_Depth; }を書き込み禁止に、後者はbool型の比較結果を書き込み禁止にしているのですが、boolは値を返した後即座にコピーが作られ、そのコピーのほうが使われるため、constはあってもなくても関係ないんですよね。
でまあ、そこんとこはうまくいったので、今度はエディットに必要不可欠なカーソル位置と選択中のチップデータと範囲選択の範囲を用意。
そしてカーソル表示用のレイヤも作り始めています。

ふにゃさん、ふにゃ第一作のステージを引き継いだり配布用のステージを用意したり、そういうことを手軽に行えるように、と思い、方法を考えてみました。
まず、配布用のステージは現在では編集用のステージを作成した後に「圧縮」を選ぶことで配布用のステージを作成します。
しかし、この方法だと、編集用ファイルと配布用ファイルを別個に用意することになり、テストプレイは編集用、それとは別に配布用、と分けて使うと、ステージ作成者の手元には内容がほぼ同じの2つのステージができることになり、プレイに支障が出ることは必至です。
そこで考えたのですが、保存するときに編集用と配布用の両方を同時に記録して、本体のほうからは配布用＝プレイ用のステージしか読み込まないようにすれば、配布用は常に最新だし、テストプレイも楽々、他人のステージは編集ファイルが無いのでプレイはできても編集不可能、というわけで、ディスク容量を考えなければこちらのほうがずっとよい方法なのです。
そして、1からのデータの引き継ぎについては、1のステージメーカーのほうでふにゃさん用の編集ファイルを作れるようにしておき、それをふにゃさんエディタで改めて読み直して保存するとプレイ用ファイルができて引き継ぎ成功ということになるわけです。

ふにゃさんのミスターフレームのグラフィックが本家のふにゃについてきていなかったので修正しました。

爆ボンのマップ作成ツールのための画像を一日掛けて用意していました。
そして、これから3Dマップエディタを作る予定です。

ふにゃさん、MIDIも鳴らせるようになりました。
なんのことはない。自分でライブラリのMIDI再生機能を使わない設定にしたのを自分で忘れていただけでした。
それで、無事MIDIも鳴らせるようになったのですが、今度は一部のMP3に問題が出てしまいました。
サウンドのストリーム再生を使うと、一部のMP3の場合、延々と後半部分を中途半端に再生し続けるのです。
ストリーム再生をやめれば正しく再生されるのですが、そうするとBGMに使うほどの巨大な音声ファイルを丸々メモリに読み込んでしまうことになり、動作が果てしなく不安定になってしまいます。

爆ボンのマップを作るのが結構大変なので、マップ作成ツールを作ろうと考えて、マップの下地となる枠を作って。

ふにゃさん、BGMが鳴るようになりました！
ライブラリ側が結構しっかりしてるので結構いろんなファイル形式で使えたりするのですが、なぜか唯一MIDIだけがならなかったりします。

というわけでBGMの実装中です。
BGM.datを読んで、「BGM名 "ファイル名" 必要と有らばその他の情報」という形式で一行ごとにデータが入っていて、BGM名とファイル名があった場合はそのBGMが有効になります。
一応音声データもBGMに使えるようにするつもりですが、基本はMIDIだと思います。
もし読み込めなくてもライブラリ側が結構しっかりしてるので大丈夫だとは思いますが。

RPG±0にはRPGツクールのオートタイルは使わないことにしました。
最大の理由は、作り方がわからない＆面倒くさいということだけれど、ほかにも、実際のところエンターブレインが特許を取っているかもしれないし、そうでなくてもあからさまに方法をパクっているもあるので。
あと、RPG±0ではいろんなものに名前をつけることができます。
例えばイベントに名前をつけたり、キャラクタチップに名前をつけたり、サウンドに名前をつけたり、敵パーティにまで名前を付けられたりします。
デフォルトネームは通し番号と同じものをつけます。

ふにゃさんのBGMは、パネルγのときのように色々面白い仕掛けを入れようと思っていたのですが、いや、今も入れるつもりですが、ゲームプレイ中にBGMを切ったりユーザーが自由に変えられるBGMに切り替えたりできるようにするつもりなので、切り替えたそのときにどのBGMが再生されているかを保持しておかなくてはならなくて、結局それはBGM番号であり、どっちみちBGMは番号で管理することになりそうです。
そりゃ番号をつけるということ自体はパネルγでも同じことですが、こちらはゲーム本体ではサウンド管理クラスにパネルが消えたとか今ピンチだとか、そういうことを通知してサウンド管理クラス側で番号を決めていたのですが、ふにゃさんの場合はそれを通知する側で決めてやら無ければならないということです。
そうなればユーザー指定のBGMとも互換性を図るためBGMはある程度決まった簡単な方式で作らなければならないので、あんまり特殊なことはできなくなるのです。