「ミディビ」に関する日記(4)

6票 編集画面すら出てこない
2票 ピアノ部分クリックで音がなり、演奏によっても音が出た
2票 ピアノ部分クリックでは音がならず、演奏では音が出た
0票 ピアノ部分クリックで音がなったが、演奏では音が出なかった
0票 どちらでも音は出なかった

「編集画面すら出てこない」ってのは問題外で考慮しないけど一応確認のため、と思って項目に入れてたんですが６割もいちゃ無視できませんね。
どうも最近のパソコンにはJREは標準では入っていないようです。
JREのダウンロードページへのリンクが必須ですね。
そして2位の「ピアノ部分クリックで音がなり、演奏によっても音が出た」というのは理想的ですが、「ピアノ部分クリックでは音がならず、演奏では音が出た」がいる以上無視するわけにはいきません(何より自分もその一人ですし)。
「ピアノ部分クリックでは音がならず、演奏では音が出た」は簡単な方法でピアノからも音が出せるようになります。
「ピアノ部分クリックで音がなったが、演奏では音が出なかった」でも音が出るようにはできますが難しいので正直いなくてよかったと思います。
「どちらでも音は出なかった」は残念ながらどうしようもないです。
いなかったのが幸い。

結論。
編集画面すら出ない人のためにJREダウンロードページ(http://java.com/ja/download/)へのリンクをつける。
そしてピアノロールから音が出ない人でもちゃんと音が鳴るように改善する。

Bomber丸WorldのグラフィックエンジンはほぼyaneDIBだけなのでさらりと実装。
しかしマップの実装に苦戦中！
なんせアニメーションして高低差もあってデータ的に前後関係を作らなくても(例えばRPGツクールやSFCのRPGなどでは「手前」にあるマップチップを「上」に置くことで見た目に正しくしている)自然な形のマップデータを与えればただしい前後関係で表示されるマップを作らなきゃならないんですから！
アニメは余裕ですが高低差と前後関係は結構悩みどころです。
高低差があれば当然高いほうを後から描くのですが、じゃあ前後関係との兼ね合いはどうなる？ってこと。
自然な形のマップデータにより、一つのマップチップの大きさが任意に変えられるようになるため、スクリーン座標でZソートして描画するとデータ的には前にあるのに後ろに描画されてしまったりすることがあるのですよ(ビルボーディングと同じ問題)。
だからマップ座標でZ(奥行き)ソートしたものを更にY(高さ)ソートすれば理想的にはうまいこと表示されるはずなのですが、それにキャラを乗せると、キャラの奥行き方向の幅によりあるZ座標の範囲でまた前後関係の誤認が起こるのですよ(ビルボーディングと似た問題)。
そのため、奥行き方向の幅を補正するために画像データに近い段階でZ方向にオフセットをかけてやり、誤認される範囲を少なくし、更にゲーム的に移動範囲に制限を設け、残った誤認が起こる範囲に入れないようにするのです。
これでおそらく見た目に問題となる範囲では前後関係の誤認は起こりえないでしょう。

それと、ぜひ付けたい映像表現が、ちびロボ！にあった、主人公が物陰に隠れるとそのシルエットが最前面に浮き出て見えるという表現。
これ、ちびロボほどじゃないにしても小さくてすぐ物陰に入って見えなくなってしまう主人公たちには必須なのだと思うのですよ。
実装はどうやればいいかな…。後で考えておこう。

というわけで。はい。以前のプロジェクトは完全に破棄しました。
Bomber丸Worldはまた最初から作り直しですが今度こそは最後まで行きますよ。
何とか今までのゲーム作りなどで、ずぼらで面倒くさがり屋の私にでも完成させることができるプログラミング手法はある程度修得したつもりです。
だけどDirectXの講座サイト見ながらやってたら早くも挫折気味だぜい！
とりあえず紹介ページも更新してます。描画手順など。
そういえばマップチップの大きさなんかも決めたりしたです。
今回決めた描画手順に適合してなおかつグラフィックが破綻しない大きさを考えると幅25x奥行き15x高さ20というマップチップのサイズが計算されたデス。
見下ろし角度およそ37度でございます。

そうそう、ミディビに関するアンケート作りました。
ミディビの「実際に使ってみる(テスト中)」から動作確認アンケートに答えてください。
ほんとこれ切実です。実態を把握できないと進めるに進められません。

ミディビさっぱりうまくいきませんよ。
どうして全てが正常の値を示しているのに音だけが鳴らないんでしょう。
同じことを別の方法で実現するコードで書いてみても結局はやっていることは同じなので結果も同じだし、よもやと思ってこれを作り始めた頃に参考にしたアプレットを開いてみたら今はならないんですよ。
ということはブラウザ側の問題、Javaのアップデートがいけなかったのでしょうか。
しかしだからといってJavaをダウングレードしろとユーザーに求めるわけにもいかないし、ここまで来て開発を中止する気もさらさらないし、どうすればよいのでしょうか。
一応、演奏機能を使えば音は鳴る、つまり、Sequencerは正常に音を出してくれるので、最悪一音出すだけのSequenceを作ってSequencerに渡せばよいのですがこれはあくまで最後の手段として取っておきたいのです。
もっとも、過去の経験からするとあっけなく最後の手段に打って出ることになりそうですが。

どうにもふにゃさんのエディタが使いにくいようだったのでまずちらつきをなくす方面で改良を加えてみました。
それとやっぱり、ゲーム内のキャラの中には、ギヤバネのようにあたれば吹っ飛ぶというわかりやすいものだけでなく温度変化ゾーンなどの特殊なものもあったり、キャラ同士の相性などもあったりと、必ずしも感覚的にわかりやすいものばかりではないので、ヘルプがある程度必要そうな気がしてきました。

Bomber丸Worldのグラフィック、要するに３Ｄに見えなきゃいいんだ、ってことで、ドットを潰さない３Ｄのレンダリング方法を考えています。

1136473028.png

ドラクエ8、今回はヘチマ売りの何でもありパワーで船を海まで引きずり出しました。
そしてついにザ・モンスター・バトルロード…じゃなかった。モンスター・バトルロードが出ました。
とりあえず竜商人でんすけを引っ張り出してきてＧクラスを余裕で突破。
更に錬金釜がパワーアップして道具が3つまで入れられるようになりました。
これをいいことに牛の糞を入れた釜に美味しいミルクと鉄の鎌を入れて合成を試みるという暴挙に出てみたのですが案の定何もよいことは起こりませんでした。

ふにゃさんのページに今までアップしてきたゲーム画面のギャラリーを作りました。
そしてゲーム本体のほうでは炎に氷を息を当てると一時的に火が消えて通れるようになったり、クリアしたときとミスしたときの音楽ができたり、ゲームを開始した瞬間に空中でジャンプできるバグを直したりしました。
今後の予定としては他の音楽を補充したり残りの必要なエフェクトを入れたり正式なステージを作ったりすることにしています。
シークレット機能はおまけなので最悪後回しでもよいのだ。

パネルγ、ハイパーモードなるものを当初作ろうと予定していたのですがもはや新しいモードを作るには時期があまりにも遅くなりすぎたので中止にしました。

残念ながら、ふにゃふにゃの追加ステージやら使いやすいエディタなどもおそらくなかったことになりそうです。

残念な話はこれだけにしておいて、次はミディビに使うアプレットの名称変更について。
最初の名前のMIDIAはいろんな名前と重複するために没となったのですが代わりのMIDIAPも音の響きが決してよいとは言えなかったので思い切って新しい名前を考えることにしました。
MIDI AppLetからつけたMIDIALは既に以前に使わないことに決めました。
他に考え付いたのがMIDIAPL、MIAPL、など。
これはこれで響きがよくないので没です。
原点に返ってMIDIApplet。
PaintBBSの実例もあることだし最悪の場合はこれにするつもりでした。
immediateとかけてimMIDIate。
すぐに直感的にMIDIが作れる、という意味でしたがちょっと内容から離れています。
他の人に考えてもらったMALET。
響きはよかったのですがマレットという人もマレット通りという場所も実在するらしいのでこれも没案。
美文が作ったんだからMIDIA323。
でも略してMIDIAだからいっしょだし。
ということでみふみを前に持ってきてMIFUMIDIA。
ミフミディアという響きも悪くないし、長すぎず短すぎず、作者の名前もMIDIもアプレットもきれいに収まっていて、何より一緒に考えてくれた人のカッコいいとのお墨付きまで頂いた！
というわけでMIDIAPのこれからの名前はMIFUMIDIAでほぼ決定です。

そして、今日はメテオスのレイヤーゼロ♪ユーロピアンの000～002までのMIDIを作ってみました。
そうそう、日記にアップしているほうのMIDIはふにゃさんのクリアしたときの音楽ですよ。

1135521728.mid

ミディビ更新しました～♪
ついにアプレット上で演奏されるようになって格段にMIDIが作りやすくなったと思います。
しかし実は前からだったのですがクリックしたときに音が鳴らなくなっていたのです。
原因は全く不明。
演奏があるから一応何とかなるんだけど例外も何もなくただ音が鳴らないだけというのはなんとも気持ち悪いです。
アプレットビューアではなるのにどうしたことでしょう。

ドラクエ8ではついにトロデーン城に帰還。
お城の方々は揃いも揃ってイバラ人間化していました。
そういえば主人公も心なしか緑っぽい雰囲気が…。(ないない
しかし毎度毎度だけどザコ敵の強いこと！
いばらドラゴンとか地獄の騎士とか、城内最強っぽいです。
目的の部屋まであと少しだったのですがククールが死んだため仕方なく引き返すことになりました。
でも正直、ククールのこまめな回復がないと一気に全滅してた可能性が高いです。

NeoMupl、どうもVBとC++のDLLを組み合わせたのはよくなかったようです。
デザインの簡便さからVBを使っていたのですがマルチスレッドで同期を取るとなると面倒なことは避けられそうになくてむしろ全面的にC++で最初から書き直したほうが楽だと感じ始めたのです。

ふにゃさん、色々細かいところを変更しました。
1.ふにゃの絵のハイライト部分を消した。
　　何度見てもふにゃには合わなかったので。
2.ギヤバネが氷の息を受けて凍るようになった。
　　そして凍った状態だとバネが働きません。
3.ギヤバネの空中の動きを改善。
　　前にギヤバネの動きを変更したとき変になっていたので。
4.ふにゃの他キャラクターとの当たり判定の最適化。
　　若干処理が軽くなります。
それでは。ごきげんよう

1135349032.png

今日は朝から雪が降っていて、学校に着く頃にはすっかり一面雪景色になっていました。
こうも見事に降り積もっていると寒さも吹き飛んじゃいますね。
とか思っていたら首筋から雪が舞い込んできてあまりに冷たかったので屋内に退避。
所詮子どもが喜ぶ程度の雪と思っていたらしっかり交通網にダメージを与えていて学校へ来るためのバスが不通になり午前が休みに。
しかしそのうちにバスがチェーンを装備し午後からは平常通り授業となってしまいました。
もっとも、これで来られなくなった人がいるということで今日予定されていた中間テストは中止されたのですが。

ミディビは実に順調ですよ。
明日にでも更新できそうです。

今日はミディビの開発を進めていました。
本当はスレッドを使ってMIDI演奏、なんてことをやってみたかったのですが、そのためには今どこを演奏しているかも表示しなくちゃならなくて、そのためには画面のちらつきをおさえなくちゃならなくて、それに意外と手間取ってしまったので次の更新ではそのあたりを重点的に扱うためアプレット上での演奏は来年に持ち越しということになりそうです。
とりあえず今回の要点はrepaintはupdateを呼び出してupdateはいったん画面をクリアするから嫌でもちらつくということです。
BufferStrategyとかで必死で頑張ってたんですけど問題はもっと単純でした。

レポートを出しに行ったら先生は出張。
朝まで頑張ってたのはなんだったのよ！

それはそうとミディビ、なぜかブラウザ上で音が鳴らなくなったんですがどうしたんでしょうかね。
閲覧者のほうからは私の事情なんてわからないのでどうしたんでしょうかねといわれても困るだけだと思いますが。
しかしもう、最後のvalidate、あれがわからないうちは絶対に正しいはずの「変更」の悪い部分を探してかなり迷走してました。
なんでやねーん！とか思いながら最大化して初めて実は変更は間違っていなかったことに気づいたのですよ。
でもおかげでまた更新時刻がこんなに遅く…。

今日もふにゃさん。
氷の息のためのクラス作成。実装はまだだけど。
そしてそれですよあれですよこれですよ。
セーブデータにプレイ時間という項目を追加。
プレイ時間に関するシークレット機能も付くかも！？
そして、シークレットもまたセーブデータだったりするわけで、いつか言っていた統一的な処理を実現しつつONになるまでは非公開にしておくために、初期値を持つセーブデータは省略して記録するという方法を使いました。
あと、テストプレイ用に好きなステージだけをプレイするモードも作りたいところ。

ミディビの開発もしていたのですが全くはかどらずほぼ何もしていない状態です…。

ミディビ更新しました。
デザイン改良とか言っておきながら現状ではデザイン改悪機能退化なのですが。

アキタラヤメル[舞台設定など]を更新しました。
クリアス研究所に8人追加です。

ロクヨンのマリオゴルフ64の記録を更新しました。
このゲームはあまりやりこんでいないので頑張ればこのくらいの記録は誰にでも出せると思います。

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

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

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

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

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

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

ふにゃさんステージデータ改訂版。
ステージファイルに埋め込まれた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に書き込むのがよさそうです。
これを日曜日あたりにプログラムとして書くつもり。

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

ミディビで保存ができなかった原因がほぼ特定できました。
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

チャット、時間切れ強制退室の処理を改良しました。
以前のものだと二人以上が同時に時間切れになると一人ずつしか退室できませんでしたが、今回はその不具合も解消されています。

今日はミディビの開発でもしようと思ったのですが、Luna3はJavaアプレットを使っていると結構頻繁にフリーズするのでその対処で開発が全く進みませんでした。