「爆ボン」に関する日記(7)

チャットを配布用に改造中です。
配布用ということでとりあえず的にロック処理を作ったりマニュアルを書き直したりしています。

爆ボンのページブルーリゾート３面を更新しました。
ここは攻略ネタが少ないため簡単でしたが実はここ、面白いネタがあったりします。
まあそのことについては後日ということで…。

ミディビ、今日更新するつもりでしたがeclipseのあまりの遅さにすっかり参ってしまい、軽くするための設定変更だけで終わってしまいました。
一応今回のことを実現する方法は調べ上げたのですが。
名前をMIDIAPからMIDIALに変更しようかと思ったけどMIDIALSPAなんてサイトがあったのでやめることにしました。

爆ボンのページにきょくの情報を追加しました。

爆ボンのページリニューアル完了しました。
ステージ紹介がそれぞれ別のページになったことですね。

レゴのエレベータ。どうもゴムタイヤの摩擦力が足りないらしく動かすと滑り落ちます。
この滑りやすさは多少押し付ける力を増やしたところでどうにもなりそうにないのでこれは失敗作ということに…。
構造そのものは結構よかったのですが現実とはこういうものでしょうか。

ミディビ、いや、MIDIAPの新デザインについて考えています。
まず、出てきた最初の画面に楽譜(ピアノロール)を配置することは決定事項です。
トラック画面を出してもトラック画面から直接編集はできませんから。
大事だと思うのがツールバー。
再生ボタンとストップボタンは常に表示しておきたいのです。
そしてミディビで作るMIDIには著作権表示とシーケンス名を入れたいのでそれを入力する画面も。
う～む、じゃあ入力画面から全部編集できるようにすれば・・・？

パネルγの遊び方をやっと完成させました。
最後は12番「化石化させるな！」です。
実際のところバグに近いものですがもろもろの理由があってわざわざ残したものです。

爆ボンのページをリニューアル中です。
いずれ全ステージ制覇するつもりだし、隠しワールドは一応隔離しておきたいし、ということで。

のんびりナマライザのログ一覧表示を作りました。
LineConstructorを使いまわしています。
どうも少し重いようですが既存のコントロールを使ったときのような余計な制限やメモリ消費がないところが強みです。
コントロールを使うとコントロールにデータのコピーを置かなければならないのでメモリ消費とデータ反映にかかる時間が馬鹿にならないのですよ。
もっとも、スクロールにスクロールバーコントロールを使っているのでいまだに32767項目の制限があったりするのですがね。

日記を改良しました。
JavaScriptが有効になっている方は既にわかっていると思いますが、左側のリストがクリックで開いたり閉じたりできるようになっています。
Netscapeだとon～系のイベントが出ないようでクリックしても反応が無いのですがそのときはそのときで少なくとも前より悪いことはないと思うので勘弁してください。

爆ボンを改めて最初からプレイしてみました。
フルパワーなので楽勝楽勝！
と思いきやいきなりドラゴ戦で自爆！
あの過剰な爆発力に自分自身が餌食となってしまいました。
リッパーのときも同じく自爆しまくりだったのですがこちらはハートを何度でも回収できるので本当に楽勝でした。
しかし最大の難関！ブラックシティ！
正面突破は最短ルートでの突破に失敗し、かなりのタイムロス。
アルタイルタワーともなると、まさに難攻不落、フルパワーなんて全くの無力なのです。
あまりに全てが揃いすぎていて非現実的なパワーで侵攻しているというのにその結果があまりに現実的なタイム！
レインボーパレスがただのボムジャンプ練習場に見えてきます。
そしてクリアするとシアターでは見られないノーマルエンディング！
ものすごく久しぶりに見たのですがスタッフロールでのあの完璧なプレイと言ったら！
シリウス版のあの馬鹿なNGエンディングとは全く違う感動的なまでの完璧なスーパープレイ！
一瞬の無駄すらもありません！
最後のレインボーパレスへの布石はレインボーパレスとクリアしてから見るとまた違って感じるものがあります。
あの頃は単なる観光地だと思っていたなぁ。
クリアタイム16分です。
アルタイル１戦目の体力が分かったのでそこを更新です。

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

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

爆ボンレインボーパレス３面のフルパワー攻略完成させました。
ついでにマップ画像も差し替えてたりします。
一応攻略本とは違ういきかたをしているはずだと思います。
やり直しがきく分こっちのほうが上かと。

あとはダウンロードページ作成プログラムを場所移動したことですね。
見ているユーザーには関係ないことですけど。
ディレクトリ構造が変わったことでずいぶんと苦労しましたがとりあえずできることはできました。

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

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

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

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

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

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

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

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

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

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

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

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

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

1130074182.mid

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

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

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

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

1129473584.png

爆ボンのマップを作成するための素材を作っていました。
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++が勝手に書いてくれてるので自分で書く必要はないはずですが。