2005年10月の日記

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

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

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

今日も引き続き部屋の掃除をしていました。
今日はなんとなく箪笥の後ろを見ていたら本が山積みにされていたので箪笥をどけてみると、そこは長年手を触れられていなかったことにより埃の城と化していました。
先ほど見た本は全て元埃であったと想像されるふかふかの繭に包まれ、よく埃に包まれたものの汚さの表現として用いられる、ふっと息を吹いて埃を飛ばすことすら全くできない状態となっていました。
そして繭の中から救出した本は幼い頃読んでいた懐かしい本の数々。
ばいきんまんの逆襲なんてものが出てきましたよ。アンパンマンの。
ヤーダ国のヤーダ姫がメコイスの壷を手に入れたらバイキンマンに奪われて悪用されるという物語です。
ヤーダ姫の話によると、メコイスの壷を使えば滅びてしまったヤーダ国を復活させることができるそうですが、バイキン仙人の話によるとバイキンマン(仙人)が手にするとバイキン帝国の帝王になれるそうです。
ヤーダ姫は見たところ高く見積もっても十代前半、悪くすると一桁の年齢に見えますが、メーヴェと少し似た感じの一人乗りの飛行機に乗って砂漠を颯爽と飛んでいました。
この行動力は若い好奇心と王族の権力によるものでしょうか。
しかし後者の権力はヤーダ国が滅亡し、あまっさえ遺跡として完全に人の住めない場所になっているため、どう考えても不自然です。
あんな便利な乗り物を用意できるかどうかすら怪しいものです。
そもそも滅亡したヤーダ国を復活させることは果たして正しいのでしょうか。
ヤーダ姫はヤーダ国の王女と名乗るくらいですから、ヤーダ王族の血筋のものでしょう。
国が滅びても王族が生きているということは亡命して逃げのびたに違いありません。
そうするとヤーダ姫を一人で砂漠へメコイスの壷をとりに行かせるなんて親たちはいかれているとしかいえません。
そんないかれた行為をさせるため、水すら満足に持っていかせられないのにあの高度な乗り物を使わせるのは、やっぱりいかれています。
しかし、もし経済力がありメコイスの壷を探させる必然性がありそのくせ取りに行く当人のことをちっとも考えない人物が他にいれば全て辻褄は合います。
そういえばヤーダ姫がメコイスの壷を見つけたとき、バイキンマンが都合よく即座にやってきてメコイスの壷を奪っていました。
バイキンマンがメカを用意できることは一目見て明らかです。
バイキンマンはメコイスの壷を使って最強の大魔王になることができます。
バイキンマンがヤーダ姫の無事を考えているはずがありません。
バイキンマンがメコイスの壷を取りに行くことになった話の後にヤーダ姫が登場しました。
私は本でずいぶんと端折ったあらすじしか見ていないので映画本編ではもしかしたら詳しく描かれていたのかもしれませんが、本を見た限りの印象では、バイキンマンがヤーダ姫に入れ知恵してメコイスの壷を探させたと考えると非常に自然です。
なぜわざわざヤーダ姫を使ったのかというと、きっと子どもだから口車に乗せやすく、見つけたときに力ずくで奪えたからなのでしょう。
なんでも力と餌で解決しようとして不利になったら集団でかかるどこぞのパンとは大違いで、非常に狡猾で合理的なやり口です。
そして、物語が終わった後、ヤーダには残酷な運命が待っています。
どんなに建物が美しくとも、国民がいなければ国ではないのです。
いまやヤーダ国民といえるのはヤーダ一族のみ。
一家族で住むには広すぎるその建物は、美しく生まれ変わってもやはり遺跡は遺跡でしかないのです。
メコイスの壷、それはたとえ表面上は願いをかなえたようでも、実はスイコメの一言で消えてしまう儚い虚像しか作り出せない幻覚の壷だったのです。
（その後の掃除の過程はもう省略）
で、そんなこんなで掃除が終わって、今度こそ床面積を増やすことに成功したのでレゴで遊ぶことができたというわけです。
昔作っていた家を再現しようとしたのですが、どう試行錯誤してもどこかで矛盾が出てしまい、作業は難航しています。
ああそうだ。アキヤメにレゴの企画加しようかな。

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

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

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

飽きたのでアキタラヤメル企画２つほど消しました。
あえてどれが消えたかは言いません。
復活させる予定もありません。
例によって予定は未定です。

レゴでうちの持っているモデルを一つLDrawでコンピュータに保存しました。
これで今あるのを壊してもまた作り直せるのです。
こうやって作っては壊し、作っては壊しを繰り返すことがレゴの良さだと思っています。
一度作ったら作りっぱなし、だったら作る楽しみがありませんものね。

爆ボンのレッドマウンテンの見えない床のバグ確認しました。
ロックだらけのマップで場外に向かってボムジャンプをするとなんと空中に立てるのです！
あと、アルタイル戦の簡単な方法をどっかの掲示板で見たのでそれも試してみました。
レインボーパレス３面のフルパワーにも挑戦し、成功しました。どきどきでも試さないと。

爆ボンのマスターのページを作りました。
えーっと、本当ならこれをネタに日記を書くはずだったのですが、今日は、なんと！
うち以上の爆ボンサイトを見つけたのです！！
アドレスはhttp://www.angelfire.com/ga/bmbrmn64/。海外のサイトです。
全てのカスタムパーツ入手法を詳細に記述しているほか、バグについても詳しく書いてあります。
難点があるなら、それは広告がうるさいことですね。
これでうちの爆ボンサイト世界一は無くなったわけですが満足です。
作った理由が理由ですから。

爆ボンのページ更新しましたよ。
レインボーパレス3面のマップ２の島への渡り方です。

ブラウザによっては分かると思いますが、TGWS全体のfavicon.icoを作りました。
バナーと同じギヤバネ君プロトタイプです。

レゴ用のCADソフトLDrawを入れてみました。
いやもう、昔から作ってみたかったんですよ、レゴの組み立て図。
最初に触ってみてまず思ったのは、「本物のほうが面白いな」でした。
組み立て図は組み立て図で、レゴで遊ぶのとは別にしようと思います。
せっかくだからオリジナル作品でも作って見せようかと思ってずっと部品を探していたのですが結局見つからなかったため断念。
まずは分類が必要そうです。

日記CGIを機能制限して軽くしました。
まず、コメント＆トラックバック機能除去。
コメントはいらないしリファラを見ればトラックバックも不要だし、そもそもブログじゃないので最初から不要な機能だったのです。
そして次に、管理者の私にしか日記は更新できないため公開サーバーに置く利点がないということで、ローカルサーバーでのみ動作するようにしました。
それに伴い、同じサーバーを共有する他のユーザーに気を使って重い処理を避ける必要がなくなったので、自分で使うのに便利なように多機能にしてみました。
まあ、分割していた処理を一括で実行するようにしただけなんですが。
こうして書いた日記をあとでFTPでアップするのです。
公開サーバー側では一切書き込み処理をしないのでミラーリングアップロードが使えます。

チャットもリロード処理を改良しています。
リロードをログ表示側の処理ではなく、投稿フォーム側でJavaScriptにより処理することで、そのときの気分次第で自由にリロード時間を変えられるようになります。
勝手にリロードされると困る場合はリロードなしにすればよいのです。
ちなみに、JavaScriptが無効化されている場合は自動リロードは行われません。

メテオスのMIDIを取り扱っているサイトを探していました。
ついでにチャレンジで新記録出しまして…。
それで、時間が、レポートをやる時間が…
メテオスめぇ！

Bomber丸Worldに使うBGM作ってました。
パネルγの基本音楽の面影なしアレンジです。
一応コード進行だけ同じにして変拍子でよくわからないことになっています。

爆ボンのページにピックに関する考察を追加しました。
レッドマウンテンにいるあの方です。
敵キャラのページからどうぞ。

えーと、あと、今日はメテオスやってフロリアスでがんばってて、選挙にも一応２０代の投票率を上げるためだけに行ってきて、漫画読んでて、えーと、え－と、学校のレポートはやってなくて、そうだ、寝坊もしてた。
今日はこのくらいかな。
これからの予定は、必死でレポートを終わらす。
以上。

1130074182.mid

ダウンロードページを改装しました。
それぞれのディレクトリのインデックスページを解析して、各種情報を取得し、リストのページを生成します。
最近更新した順に並べるのも要約の抽出もファイルサイズ計算もバージョン・更新日の表示も、ソフト本体のページを書き換えることで半自動的に行われるのでほぼ更新を忘れることはありません。
しかも、自宅サーバーでしか動かないようにしているので他のユーザーと共有である公開サーバーには負担がかからないため、多少重い処理でも気兼ねなく使えます。
ついでに、今のところはkBのファイルしかないのですが、実は1kB未満のファイルや1MB以上の大きなファイルのサイズも問題なく表示されます。
あと、この仕様に合わせるため、複数のソフトを公開しているページでは詰め合わせ版を用意することにしました。
詰め合わせ版があるのは、MusicPlayerシリーズとその他のソフトです。
現在では、リストのページから直接ダウンロードできますし、バージョンや更新日も一目で分かり、無駄足や余計なステップを踏む必要もなくなりました。
とにかく、こちらの利便性と共に、閲覧者側の見易さ・使いやすさも改良されているの思うのでぜひ見てみてください～。

日記とプログラムに関する私の生活リズムを見てみると、10時ごろ、日記に書くため何かをしようとする、11時ごろ、結局何もできず計画だけ日記に書く、12時過ぎてから、ようやく作業に取り掛かる、翌朝、眠い、という悪いサイクルになっているようです。
今日はキャスパーを見ていたためこの時間になったのですが、このサイクル、10時の分をなくして11時の分を持ってきたら良いペースでできそうな気がしてきました。
つまり、今日明日の行動計画をさっさと日記に書いてしまう。
なんだか私、切羽詰るかすることを宣言するとペースが上がるようなので、あせるだけで何もしない時間を日記に当ててその後の時間を有効に使えるようにしたいです。

昨日の日記に書いていたディレクトリ統一、日記を書いた後に急いでやりました。
日付は今日です。
きちっと前のファイルのリダイレクトもできているはずですので、あとは解析用のファイルを作って、リスト生成プログラムを完成させるだけです。

そうそう、LineConstructorバージョンアップしました。
横スクロールがなんだかニョキニョキしてカッコ悪いのですがまあただ単に右側を見るためだけに作ったので気にしません。
貴方も気にしないでください。

ところで先ほど言っていたキャスパー、何度か見ていたんですが面白いですよね。
殺すのを思いとどまった次の瞬間勝手に死んでるパパさんナイスです。

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

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

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

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

バンジョーとカズーイの大冒険、ゴビにも会わずカッチコッチな森にも入ることなくチューティの救出に成功してしまいました。
音符は全て回収。ジグソーとハニカムもゴビ関連を除き全て手に入れました。
そしてグランチルダのクイズショーへ。
はっきり言ってブレンチルダの話なんか聞いていなかったし当社比6倍のいい加減さで漫然と進めていたため案の定大苦戦。
マグマ風呂の常連さんになってしまいました。
もっとも、ボス戦だけは金の羽根使いっぱなしで余裕でしたが。
ええ、もう、ボス・ブーム・ボックスがパカパカ開いていくんです。痛快です。
ええ、もう、ザバス隊がペシペシ叩き落とされていくのです。愉快です。
あぁ、でも、グラちゃんぬいぐるみほしかったなぁ。
結局卵＆鍵は用途不明だし。

メテオスのヒュージィのMIDIの002番を修正しました。
ちょっと勘違いしていて最初の4小節で終わりだと思っていたのですが実はその4倍もありまして。
ついでに色々他にも間違っていたので修正しています。

Bomber丸Worldの海ダンジョンの曲を公開しました。
開発室ですよ～。
気力があればゲームに組み込むときに色々仕掛けを施したりもするでしょうが一応これで完成かも。

そうそう今日散髪してきました。
頭サッパリです。

爆ボンの敵キャラページを分離しました。
以上。

ダウンロードページ一部改装しました。
横書きの文章は左上から右下へ読み進めていくものだということを踏まえ、読む必要の無い画像は右上と左下に配置、そうすると下側のメニューが使いにくくなるのでメニューは上で横に並べています。
あぁ～。バグのページも作らなきゃ。

爆ボンのページ更新しました。
昨日作ったツールでマップを描いて、レインボーパレス３面のページができました。
いや、できてなくて準備中だったりするんですが。

爆ボンのための3Dマップエディタできました～♪
爆ボンのマップの図を描くためのものなので見えない部分は特に考慮していません。
それなりに操作性は悪いのですが、自動ロード＆セーブがあったり範囲選択があったりして多分それなりに操作性は良いと思われます(何
見た目さえ作れればそれでよいので同じ場所に二つ以上のチップを重ねるという暴挙もできてしまいます。
いえ、暴挙ではありません。これにも意味があるのです。
編集単位がブロックごとなので壁だけとか床だけとかのブロックを用意してそれらを組み合わせることができればよいかなと思っていたのです。
なかなかどうしてそんなこんなでどっちみちマップ作りは時間がかかってしまうのですがおそらくそれなりに比較上は量的問題として前が恐ろしくやる気をなくすほど時間がかかってしまっていたので多分結構はるかに劇的に感動的なほど時間短縮できてしまったりしているに違いないのでしょうがでも私は結局前どれだけ時間がかかったかすら忘れてしまっていると思われますので別に時間が短縮できても実感が今一湧かずやっぱりしんどいなと思っていたりするのでしょう。
頑張ってください(他人事？

1129473584.png

バンジョーとカズーイの大冒険でゴビを無視したらどこまでいけるか挑戦中です。
現在ゴビ抜きでゴビバレー砂漠をオンプ100ジグソー8ハニカム1で出たところです。
ジグソー二つとハニカム一個はゴビがらみなので取れません。

アキヤメのキャラページを廃止して舞台設定のページに移動しました。
企画IDはworldです。
移動ついでにキャラだけでなく地域や歴史的なことにも触れていったりしています。
まあ、主にBomber丸Worldの世界観ですね。

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

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

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

LineConstructor、選択した場所が変わったときスクロールが付いてきていなくて不便だったので追随するようにしてみました。
今のところマウスのボタンを押したまま画面外までカーソルを持っていってスクロールさせる方法が中途半端にしかできていないのでSetCapture/ReleaseCapture系のAPIを用いて画面外でも正しく位置を検知できるようにするのが当面の課題、って、すぐできますが。
ByteEditでもそのうち同じ機能をつけるつもりです。
それと、必要なのは閉じるときの保存確認ですね。
ついつい保存を忘れて閉じちゃいます。
そうそう。横スクロールもつけないと。

ミディビ受信プログラムの正規表現の件、バッチリOKみたいです。
\x00のような記法でバイナリデータ全部問題なく正規表現に使えそうです。
テキストを抜き出すのも比較的簡単にできそうですよ。

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

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

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

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

ミディビ作ってました。
もうほんとに色々あって。

OutputStream探し。
MIDIデータをbyte配列としてメモリ上に一時置いておかなければならないんですが、可変長byte配列を扱うのに便利なクラスが無かったんです。
まずLinkedList。
これはオブジェクトなら何でも要素にできるし項目の追加が高速。
そしてデータは一気に配列としてもらうことができる！！
というものだったのですが、LinkedListで扱えるのはオブジェクトだけなんですよね。
byteはオブジェクトじゃないので扱えないんです。
そりゃByteオブジェクトにすれば入れられなくは無いけどそうすれば高速化が無意味ということで。
第二候補がByteBuffer。
名前の通りbyte型のバッファを扱うクラスで、こちらは正真正銘プリミティブ型のbyteなのです。
ところがどっこい抽象クラス。
何か実装しなきゃならないそうです。
実装が嫌だから既にあるクラスから探しているというのに！！
仕方なく自作。
経験上MIDIは数十キロバイト程度の大きさになるのでバッファを10kBごとに増やす方法で不必要にメモリの使用量を増やさず高速化を図っていました。
OutpurStreamのサブクラスとして作っていたんですよ。
そこでどんでん返し。
ByteArrayOutputStreamという私のやろうとしていたことまるっきりそのままの名前のクラスを発見したんですよ。
その内容を見てみてビックリ。
私が自作していたOutputStreamと同じことができて、さらに私が思いもしなかったさらに便利なメソッドまであるじゃありませんか！
速度は自作のほうが出せそうな気がしますけど、速度が何だってんです！
ここまで理想どおりのものをあつらえてもらいながら使わないというのはJavaに対して失礼というものです。

CGIに渡すデータをどうするか。
ここはお絵描き掲示板をお手本に。
というわけでしぃペインターの出力をそのままファイルに書き出すCGI作成。
binmodeを忘れたりして出力がおかしなことになったりしてました。
識別子・サイズ・実データが順番に並んでいるようです。
MIDIにはテキストとしていろんな情報が入れられるのでもろもろの情報はMIDIに埋め込んでしまえばミディビが受け取るデータはMIDIデータだけでよくなります。
そうすりゃオエビのように面倒な処理は抜きにしてデータ受け取りCGIは受け取ったデータをそっくりそのままファイルに出力することを考えればよいのです。

で、関係ないMIDI。
出だしの部分だけ。
後半で発展させてゆきます。

1128783251.mid

爆ボンのマップを作成するための素材を作っていました。
EDGEでテクスチャを使って塗りつぶす方法を見つけて、というより、きっとあるはずだと信じて探したら本当にあって、その機能のおかげでずいぶんと作成速度が上がりました。
いろいろとマップチップ作成に便利な部品を作ったということも作成速度向上の一因には違いないでしょうが。
まだまだ調整が必要だけどここまでできてます。

1128696113.png

ふにゃさんステージデータ改訂版。
ステージファイルに埋め込まれた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のステージメーカーのほうでふにゃさん用の編集ファイルを作れるようにしておき、それをふにゃさんエディタで改めて読み直して保存するとプレイ用ファイルができて引き継ぎ成功ということになるわけです。

ミディビで保存ができなかった原因がほぼ特定できました。
http://support.microsoft.com/default.aspx?scid=kb;ja;175622で見てみると、どうも我々のアプレットは信頼されていないため、クライアントであろうとサーバーであろうと関係なく保存できないようです。
お絵描き掲示板はどうなっているのかと見てみると、アプレットから画像ファイルのデータの中身がそっくりそのまま送られてきていて、それをCGI側で保存するようになっていたのですが、これは今回のようなセキュリティの問題だったのかもしれません。
そこで自分もそれに倣ってCGIにデータを渡す方法を考えることにしました。
MidiSystemのwriteメソッドにはFileクラスを渡して直接ファイルに書き出してもらうものともう一つ、OutputStreamの派生クラスを渡して自分で作った出力ルーチンに書き出すものがあって、それを使うと、出力先を自由に変えることができるんですね。
ここで、Socket通信によってデータ受け取りCGIに出力すると、セキュリティに問題の無いCGIから保存ができるようになるということです。
アプレットからCGIにデータを渡す方法などについてはhttp://www.sm.rim.or.jp/~shishido/cgij.htmlなど。

LineConstructorを使っていたら、大きなファイルを開いたときにエラーが起こりました。
機能の足りない部分があってもバグはない自信があったので少しショックだったのですが、原因はどうやらスクロールバーが大きな数に耐えられなかったことが原因だったようです。

今日はチャットにクッキー保存機能をつけました。
本当ならGBBSのプロフィール機能と連動させたかったのですが、それぞれで必須とされている要素が異なり、GBBSのプロフィール自体もまだ発展途上であるため、連携するようにするのは控えておくことにしました。
まあそんなこんなでアルニックはレベル24達成。
目指せレベル30です。

爆ボンのための3Dマップソフトを作成中です。
3Dマップはどの方向にどのようにマップが広がるか分からないし、マップのほとんどの部分は空白状態なので、2Dのときのように二次元配列を用意してそれぞれにマップチップを、というわけにはいかないので、STLのsetに、マップ上の位置とチップ情報を詰め込んだクラスを入れて、順序付けされた配列として扱っています。
なぜ順序付けされた配列にする必要があるかというと、描画段階において確実に奥のチップから表示するためには奥行きでのソート(Zソート)が不可欠であり、マップチップが動かず、視点も動かないことを考えると、描画の時点でソートするより、最初からソートされた配列に順序を狂わさないようにデータを入れてゆけばそのまま最初の要素から順番に描画してゆくことで簡単に描画ができるようになるためです。
しかし、クラスはそのままでは大小関係を見て順序付けすることができないので、operator<だとかoperator>だとかを使って大小関係をつける関数を自作(いや、この場合演算子を定義か)。
なにしろsetにぶち込んで利用するからには値のように扱えるようにしなければならないので、他にもコピーコンストラクタやらoperator=なども考える必要があったりして、結構いい刺激になりました。
もっとも、コピーコンストラクタとoperator=についてはC++が勝手に書いてくれてるので自分で書く必要はないはずですが。

ブラウザで確認したら保存されなかったorz