今日はこれだけ
爆ボンの敵キャラページを分離しました。
以上。
爆ボンの敵キャラページを分離しました。
以上。
ダウンロードページ一部改装しました。
横書きの文章は左上から右下へ読み進めていくものだということを踏まえ、読む必要の無い画像は右上と左下に配置、そうすると下側のメニューが使いにくくなるのでメニューは上で横に並べています。
あぁ~。バグのページも作らなきゃ。
爆ボンのページ更新しました。
昨日作ったツールでマップを描いて、レインボーパレス3面のページができました。
いや、できてなくて準備中だったりするんですが。
爆ボンのための3Dマップエディタできました~♪
爆ボンのマップの図を描くためのものなので見えない部分は特に考慮していません。
それなりに操作性は悪いのですが、自動ロード&セーブがあったり範囲選択があったりして多分それなりに操作性は良いと思われます(何
見た目さえ作れればそれでよいので同じ場所に二つ以上のチップを重ねるという暴挙もできてしまいます。
いえ、暴挙ではありません。これにも意味があるのです。
編集単位がブロックごとなので壁だけとか床だけとかのブロックを用意してそれらを組み合わせることができればよいかなと思っていたのです。
なかなかどうしてそんなこんなでどっちみちマップ作りは時間がかかってしまうのですがおそらくそれなりに比較上は量的問題として前が恐ろしくやる気をなくすほど時間がかかってしまっていたので多分結構はるかに劇的に感動的なほど時間短縮できてしまったりしているに違いないのでしょうがでも私は結局前どれだけ時間がかかったかすら忘れてしまっていると思われますので別に時間が短縮できても実感が今一湧かずやっぱりしんどいなと思っていたりするのでしょう。
頑張ってください(他人事?
爆ボンのマップを作成するための素材を作っていました。
EDGEでテクスチャを使って塗りつぶす方法を見つけて、というより、きっとあるはずだと信じて探したら本当にあって、その機能のおかげでずいぶんと作成速度が上がりました。
いろいろとマップチップ作成に便利な部品を作ったということも作成速度向上の一因には違いないでしょうが。
まだまだ調整が必要だけどここまでできてます。
ふにゃさんステージデータ改訂版。
ステージファイルに埋め込まれた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++が勝手に書いてくれてるので自分で書く必要はないはずですが。
ふにゃさんのミスターフレームのグラフィックが本家のふにゃについてきていなかったので修正しました。
爆ボンのマップ作成ツールのための画像を一日掛けて用意していました。
そして、これから3Dマップエディタを作る予定です。
ふにゃさん、MIDIも鳴らせるようになりました。
なんのことはない。自分でライブラリのMIDI再生機能を使わない設定にしたのを自分で忘れていただけでした。
それで、無事MIDIも鳴らせるようになったのですが、今度は一部のMP3に問題が出てしまいました。
サウンドのストリーム再生を使うと、一部のMP3の場合、延々と後半部分を中途半端に再生し続けるのです。
ストリーム再生をやめれば正しく再生されるのですが、そうするとBGMに使うほどの巨大な音声ファイルを丸々メモリに読み込んでしまうことになり、動作が果てしなく不安定になってしまいます。
爆ボンのマップを作るのが結構大変なので、マップ作成ツールを作ろうと考えて、マップの下地となる枠を作って。
今日は爆ボンのレインボーパレスのマップを引き続き。
レインボーパレス3面のフルパワー全ブロック破壊マップ切り替え無しでのクリアに成功しました。
後日攻略ページに掲載します。
LineConstructorに検索を実装しました。
結局ショートカットキーは思いつかなかったので1・2・3にしてしまいました。
明日にでもアップします。
メテオスやってます。
弱いメテオスも難しさ5になれば圧倒的、でも無いけど強いです。
何しろ難しさに関わらずカタマリの落下が遅いのです。
難しさ5でも上まで積みあがってからそこそこ耐えますし、時々大きく飛ぶのでそのときに点火の素材が沢山出てきます。
爆ボンの攻略で検索してくる人が多いなと思って自分でも検索してみてビックリ!
検索で出てきたのは500件以上、そのうち上位50サイトを見てみたのですが、まともな攻略サイトが一つも無い!!
ひどい!ひどい!!いくらなんでもひどすぎる!!!爆ボンに対する冒涜だ!!!!
そんなわけで、これから私は本格的な爆ボン攻略ページを作ります。
既に計画は始まっています。需要の最もありそうなレインボーパレスのマップを一つ作成しました。
ゲーム記のところから見てみましょう。
さて、ふにゃさんにもウナギカズラが登場して、そろそろ本格的に活動開始らしいのでちょっと覗いてみましょう。
・・・・・・・・
ああっ!なんということでしょう!激しく!激しく凶暴化しています!
共食い!共食いです!共食いをしています!!仲間だというのに罪の意識は無いのでしょうか!およそ人間のすることとは…あっ、そうでした人間じゃないんでした。
ご覧ください!他の生物も!…信じられない。およそ生物が食せるとは思えない硬い鋼鉄の機械を食らい、成長を続けています!
危ない!主人公のふにゃが近づいて…あれ、何も起こりません。何事も無かったようにふにゃはウナギカズラの上を走り、ウナギカズラは何もしません。…歯ごたえが無いからなのでしょうか。
とにかく、今はとてもお見せできるような状況ではありません。
LineConstructor完成しました。
VBの命令のInputBoxだとPaintイベントが呼び出されないからInputBoxと同じ機能を自前で作って(うちで配布しているInputBoxExね)、OCXのコモンダイアログコントロールだと同じく再描画されなくてAPIを使って直接呼び出して、指定したフラグがおかしなことになって瞬時に終了されたりして、いろいろあったようななかったようなで、必要な機能は全て揃いました。
行ごとの編集、並び替え、追加削除、あっ検索が無かった!
とにかく、明日検索を追加してドキュメントを付属してアイコンを作ってアップします。
うわー。紹介ページもまだだぁ。
爆ボンのMIDI、一応聞けるようにだけはして置きました。
でも、実際のところ、聞かれたくはないのだけれど…。
そして、エアライドのページも更新しました。
各種記録を!
チャット管理プログラム作り始めました。
現在はぼっとの辞書を見ることのみできます。
一応形だけ削除フォームと追加フォームが作ってあります。
こればかりは実物を見せるわけにもいかないので画面写真のみ公開しておきます。
調子に乗ってレッドマウンテンの曲まで作ってしまいました。
昨日は爆ボンのブルーリゾートの曲を作っていてあまりの難しさに放棄したのですが、今日は最後まで作りました。
で、やっぱり幸せ気分粉砕。
あまりにひどいデータなので公開していません。
今日は昨日のあの辞書整理システムを作る予定だったのですが、突然の衝動に駆られ、ブルーリゾートの曲の耳コピを始めてしまいました。
いあ、だって、爆ボンの音楽ってそれくらいいい曲ですもん。
今日爆ボンやってて終わった後にミョ~に幸せな気分になっていたのですよ。
で、耳コピに挑戦してみて幸せな気分粉砕。
ム・ズ・カ・シ・す・ぎ・で・す!
ふにゃさん、昨日の嘘画像に出ていたミスター・フレームを実際に出すにはほんもののふにゃのほうの画像が出揃っていないと後々面倒になるので、もしかしたら使うかもしれない画像をどんどん追加していきました。
攻撃アニメーションの正面パターンとか、ジャンプ溜め中のアニメーションを増やしたり。
氷の息正面撃ちは上方向に広がって、すぐに避けないと落ちてきた冷気で自滅します。
そしてなんとなんとなんとなんと!!!!
もう圧縮ステージファイルに対応しちゃったのでありますッ!!!
いや、もう、圧縮アルゴリズムは既にあるものを呼び出すだけなんだから簡単なんだけど、本当にあっさり実装できちゃって自分でも驚いています。
パネルγのスコアランキング、ゲームがフルスクリーンであり、せっかくVBランタイム不要にしたので、これを崩したくはないわけですよ。
他のソフトなら好きなだけブラウザを呼び出せたけど、フルスクリーンじゃそれもままならないし、直接接続するにしても、いろいろと面倒そうだし、第一日本語入力できないし、スコア報告だけVBで別プログラムを組むというのも嫌だし。
そこで、スコアランキング本体がCGIであり、Webブラウザで表示されるということを考慮して、スコア送信プログラムもWebブラウザで表示すればいいのではないか、もっと言えば、パネルγ本体でスコア報告用のHTMLを作り、あとでそれを開くことによってスコアランキングにいけると、そういうシステムはどうかと考えています。
今はHTMLファイルを書き出す処理だけ。
暗号化処理とかはまだしていません。
爆ボンデータ更新しました。
ブラックシティまでの敵キャラデータどきどき版を追加です。
掲示板のアイコンにあんこを増やしました。
まあ今回は楽な作業でした。
パネルγの裏話8「珍しいパターンたち」を公開しました。
これで予定している裏話は全部になります。一つはまだ完成していませんが。
今回は最後らしくネタバレを含んでいます。ご注意を。
爆ボンバーマンのページをニンテンドウ64のページから独立させました。
もともとゲーム記は自分が作りたくて作ったものであり別に見る人がいようといなかろうとどうでもいいコンテンツであり、あんまりアクセスが多くても困るのですが、大好きなゲームの爆ボンなら話は別。
ゲーム記の中でも特に検索で来る人が多かったので検索から一発で見つかるようにページを分けました。
今日はいつか作ったメロディを短調にしたもの。
案外短調にもなじんでいるように感じます。
爆ボンの敵キャラデータを更新しました。
今回は主にボス系統です。
アブソリュートとマスターは狙いが定まらないのでHPがよくわかりませんでした。
ふにゃさん、今日はアイテム全般の処理を作っていました。
このあたりはyaneSDKのCGameObjectBaseを参考に。
マップクラスに所有権を与えている時点であまりよい状態とはいえないのですがそれはそれで仕方が…って、もしかしたらもうちょっと依存性を低くする方法があったかも!?
そうだよ。せっかく少し細かくアイテム・敵・エフェクトと分けたんだからそれぞれが別次元のGameObjectとして働けばいいんだ。
というわけで明日から書き換え開始。
今日はBomer四角。
う~ん、純粋に下手というのは仕方ないとして、左右のバランスがうまく取れていないのが気になります。
ちなみにBomber丸Worldでの登場キャラです。
爆ボンバーマンの敵キャラデータを更新しました。
全部じゃないにしても結構それなりに揃ってるんじゃないかな~と思っていて自分としてはそれなりに満足だったりして、また暇のあるときにでも完成させようかなと思っていたりします。
VB小ネタを更新しました。
自分のウィンドウがアクティブかどうかを判定する方法を。
ゲームなどに使えるんじゃないかな。
ふにゃさんエディタでいろいろ安全対策をしてみました。
まずマップサイズの制限。
幅は10以上、高さは7以上が保障されるようになります。
そして主人公を一番下のラインに置かせない。
一番下から始まると先はもう場外しかないので。
爆ボンバーマンでちょっと敵の強さを調べていました。
いやはや、プニプニが防御力最強とはね。
ノーマルボムだと19回も当てないと倒せません。
一部をゲーム記にて公開しています。
気が向けば全部入れます。
メテオス、途中までだけど恐怖の館000をアップしました。
最初の数小節で早くも音程を外しているような気がしてならないけど、めんどくさいのでほっときます。
ふにゃさんエディタのステージ読み込みを作り始めました。
とりあえずデータをメモリに読み込むところまではできました。
後はこれを解釈するのですが、ポインタをいじれないVBではちょっと難航しそうな予感です。