プログラミング関係の話題。プログラミングコーナーを更新したとか、プログラミングの内容に踏み込んだ話とか。
以前の日記に書いたドットを潰さないレンダリング方法、あれ別に3Dでなくとも2Dでも高さ成分を真正面から見た高さの８割になるように、奥行きを真上から見た奥行きの6割になるようにドット絵で描けば縦・横・高さの比率が正しいドット絵として立派に成立するじゃないですか！
というわけでそういう描き方をしたマップチップでマップを描くプログラムを作ろうとしていたのですが何をどう間違えたのかマップチップを作っているうちにマップ上に配置する人物キャラを描きだしてしまいました。
元々人物のデッサンなんて小学校以来やってはいないしましてや37度から直立姿勢の人を描くなんてことは一度もなかったので、とりあえず理論的に正しい人物を描こうと身長別－男女のボディサイズ平均を見て数値を見ながら描いていったのですがどうにも日本人の体は細長すぎるようだったので、今度はメタセコイアに入っていた人物の３Ｄモデルを３７度の角度から見下ろした画像から輪郭抽出してそれを参考にしながら描いてみたら結構自然な感じになりました。
しかし謎の男のつもりで描いていたのですが、暗いね。
まずいよーまずいよー。
おさかなさんとけてるよー。
やきざかなにがいよー。
今日はブルーリゾートの1・3面のスピード攻略を作っていました。
3面のクリアタイムを更新、1面は3通りの方法を検討しています。
詳しいことはまだ後日書きます。
チャット配布用一応できましたがオリジナル版との違いが予想より大きくなってしまったためちょっと内容を再検討中です。
あと、やはり不足している機能が多すぎること。
ナマライザの解析部分でリクエスト先を更に分解してディレクトリ・ファイル名・?以下の文字列に分けるようにしました。
しかしそのときクラス内で使っているユーザー定義型はまともな方法では外部に公開できないということがわかってVBへの不信がいっそう募ったり。
外部標準モジュールに一時保存用の変数を作ってそれ経由で渡さねばならないようです。
本当にVB6のオブジェクト指向は形だけで役に立ちません。
さりげなく昨日のStringArrayを公開しました。
プログラミングコーナーの一番下からいけますよ。
先日のBomber丸Worldの敵DLLの問題、敵キャラクラスは根性で共通インターフェイスを作って、逆にDLLから本体へのアクセスは文字列としてコマンドを渡して動かすということにしようと考えています。
これなら本体に後から機能追加してもDLLのほうはコンパイルしなおさなくて済みますからそれなりに開発しやすくなると思います。
ナマライザの解析処理部を改良しました。
以前のだと複数のファイルを読み込むと一つ読み込むたびに解析を行っていたのですが、今回で全てのファイルを読み終わった後に解析を行いようにしたのでたぶん回数分だけ軽くなっています。
ついでに、ステータス表示に現在の読み込み状況を表示していたのですが、その表示そのものを受け持つ部分と表示される文字列を作る部分とを分け、ステータス作成部分では現在の状態のリスト(通常は0～1項目)をStringArrayクラスにつんで一番新しいものだけを表示させるようにしました。
それに伴ってStringArrayクラスも改良しました。
戻り値の一部がVariant型になっていたりしたのを修正して、新しいメソッドDeleteValueを追加しています。
DeleteValueでは指定した値を持つ要素を全部消去してその分を詰めます。
ふにゃさんのBGMをループできるようにしました。
設定項目を増やしてそれを認識してループフラグを操作するだけだったのですが、設定プログラムのほうでyaneLineParserと同じはずのクラスで読み取りポインタが増加しないバグがあったので正しく読み取れない事態が発生していました。
もちろん即行で原因を見つけて直しておきましたが。
標準BGMのほうはどうしようかなぁ。
敵が周りにいて変化、というのは難しいかもしれないし重いかもしれないし。
ふにゃ本人の状態だけで変化させるんなら簡単で軽いはずなんですよ。
例えば眠ったときに静かな曲調にするとか…。
メテオスのスタッフロールにあった楽譜、あれオープニングの一部なんですね。
MIDIに打ち込んで気付きました。
プログラミングコーナー更新ですよ！
はっきり言って思いつきでふと更新しました。
しかし変数に符号付きデータを使っているということを忘れていてソート結果をバイナリエディタで開いて0付近から始まっていなくてかなりあせてしまいました。
しかも、ActiveBasicはファイルの読み書きが弱く、バイナリファイルをまともに読むにはAPIに頼らねばならなくて、面倒だったのでVBで読み込んで「data[0]=… data[1]=… …」というようなプログラムで直接変数にデータを代入するファイルを作って、ABだけファイル読み込みはせずに済ませてしまいました。
純粋にアルゴリズムだけの速度を比較したいということのほかにこういうこともあったんですよね、ファイル読み込みの時間を考慮しなかったこと。
Bomber丸Worldの敵のシステム、基底クラスにキャラクラス、そこから派生して敵キャラクラス、更に派生して個別の敵のクラス、という構造にしたいのですが、それを全部いちいちプログラムに埋め込んでいたら実行ファイルのサイズが、使用メモリが、起動時間が、えらいことになってしまいます。
そこで考えたのが、敵キャラクラス一つにつき一つのDLLに埋め込んで、敵キャラをDLLで提供するという方法。
こうすれば本体をコンパイルしなおさなくても敵を追加できますし、動作が独立になることで保守もしやすそうに思えます。
しかしこれには問題があって、例えばDLLを見れば一気にネタバレしてしまったり、ファイルを削除すれば敵が出なくなったり、そのあたりは適当に考えて隠したり存在チェックをすれば済む話なのですが、もっと問題なのは、DLLの実装方法です。
基本的に同じ基底クラスを本体とDLLで共有して、DLL側で派生クラスとして実体を提供するという形になるのですが、途中で基底クラスの実装を変更してしまうとDLL全部をコンパイルしなおさなくてはならなくなり、かえって保守が難しくなってしまうのです。
だから先にインターフェイスを決めてしまい、後はずっと同じものを使うのですが、この問題があるということは、もっと別の問題も考慮しなくてはならなくなります。
それはDLLの敵からゲーム本体にアクセスする方法です。
このゲームでは他のキャラクターを使って行動したり、ゲーム内の変数を利用したり、高度なグラフィック処理をする可能性があるので、ゲーム本体のクラスなどに比較的自由にアクセスできることが必要なのです。
う～ん…難しそうだ。
ふにゃさん、ステージ内に埋め込まれた画像を読み込む処理の改良に成功しました。
やはりこの前考えたとおり、GlobalAllocで確保したメモリアドレスと違う位置を渡していたのが原因だったようです。
mapを使って識別子とデータを関連付け、データクリア時にはそれぞれを別々にメモリ解放します。
要するに今回はこの関連付けるデータを一つ一つGlobalAllocで確保したというわけです。
また、確認はしていませんしその必要もないと思うのですが、以前のものだとデータの長さ(というよりデータの要素数)にほぼ比例した検索時間が必要でしたが、新しいほうだとその対数オーダーでの増加になるので大きなステージでは読み込みが速くなるはずなのです。
もしかしたらメモリの解放忘れがあるかも。でも多分無いかと。うん。自分を信じよう。スペル間違い以外に不具合は無かったんだし。
ミディビのMIDI受信プログラムを少し改良しました。
データを簡単に検査することでMIDIかどうかを判別し、MIDIデータでなければ保存しないのです。
MIDIには必ず存在するデータというものがあるのです。
それが存在するかどうかさえ調べればおかしなデータが送られてきたときにエラーを出すことができるというものです。
ミディビは一応完成したら配布するつもりなので悪意のあるデータを排除するというのも必要になってくるわけです。
そういえばPerlの正規表現ってバイナリデータに対してはどう動くんだろう？
PHPについてはどうやら一行のデータを前提にしているらしいのですが。
ん？でも掲示板とかで複数行のデータを渡したときもちゃんと動いてる？どーなってんだろー。
しかしもしバイナリデータでも正規表現が使えるなら強いですよ。
なにせ正規表現だけで曲名も作者もコメントも抜き出せるのです。
JavaのおかげでMIDIのバイナリデータを直接扱うことはありませんでしたがやはりいずれにせよMIDIファイルの知識は必要だったようです。
それでも一応MIDIメッセージの段階まではMIDIに踏み込むことができたのでできる自信はあります。
正規表現の挙動しだいですが…。
ミディビ作ってました。
もうほんとに色々あって。
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。
出だしの部分だけ。
後半で発展させてゆきます。
ふにゃさんステージデータ改訂版。
ステージファイルに埋め込まれた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に書き込むのがよさそうです。
これを日曜日あたりにプログラムとして書くつもり。
爆ボンやってました。
今度はどきどきモードでドラゴとリバイアを倒しました。
攻略ページのほうの更新はありません。
やっぱりどきどきモードだと強くなっています。
慣れないことをしたため早速失敗しました。
爆ボンマップ作成プログラム、マップチップの演算子をオーバーロードして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++が勝手に書いてくれてるので自分で書く必要はないはずですが。
オブジェクト指向といったら何をオブジェクトにするかが大事なんです。
例えば、名簿クラスのメンバの各個人の名前はstring型を使うかCNameを作るかという問題など。
どの程度までクラスとしてまとめるか、分けるか、というので結構痛い目にあってるから使う必然性がない限りはあまりオブジェクト指向でやりたくないんですよね。
ええ、痛い目にあいました。ふにゃさんで。
分け方を誤った…。もっと細かく分けるべきでした。
派生クラスを作るときに余計なクラスをはさむべきじゃなかったんです。
実は、他のゲームでならこれでもよかったのですが、今回は違いました。
主人公にとって敵とアイテムの間に本質的な違いはないし、敵にとって他の敵と主人公の区別は無いんです。
仕事を語るのに白人も黒人も無いようなものですね。
今の仕様では主人公・敵・アイテム、という３人種がいて、それぞれで主人公は主人公で一まとめ、敵は敵で一まとめ、アイテムはアイテムで一まとめにしていたのですけれども、例えばですね。ウナギカズラというキャラ、主人公のふにゃと敵のミスターフレームは乗せるけど、敵のとげとげとギヤバネは食べてしまいます。
ギヤバネは他のギヤバネとぶつかって吹っ飛にますし、アイテムのバナナは主人公グループと、敵グループのミスターフレームに食われます。
だけど、ミスターフレームはめったに登場しません。つまり、敵の中からミスターフレームを探す作業は果てしなく無駄が多いのです。
これを、とげとげならとげとげだけのグループ、ウナギカズラならウナギカズラだけのグループを作れば、効率はかなり上がるはずです。
例えば、とげとげはウナギカズラを無視するからとげとげがウナギカズラを見る時間をそっくりカットできるというわけです。これで沢山敵が出たときの処理落ちが軽減されます。
バナナとかは主人公とミスターフレームしか見てないからバナナが多くて関係ない敵が多いとめちゃくちゃ無駄な時間が使われていたわけです。
しかし、こうして分けても、場合によっては全部を統一的に扱わねばならないときもあるので、結局は混在することになりそうですが、今の問題は、マップキャラと、例えばギヤバネの間に、敵キャラという分類を設けたことによる中途半端さによるものなので、いっそのこと全部か各個かのどちらかにしてしまえば問題はなくなるのです。
そもそも、敵キャラと味方キャラとアイテムの区別すら曖昧だったんですよね…。そもそも似たもの同士でグループ分けできるものじゃなかったんです。
しかし…変更は地道な作業になりそうです…。
ふにゃさん、各自でBGMを用意するタイプはCBGMLoaderでさらっと書いちゃおうかな～などと思っていたのですが、強制的にループしたり存在しないファイルに対する動作がよくわからなかったりするので使用は控えることにして、その基底クラスであるCLoadCacheとファイル解析のCLineParser、CSound、あと存在するBGMとかいろいろデータのためSTLのmapなどを使って実装してみようと目論んでいます。
そひて、色々仕掛けを入れようと考えている標準BGMのほうは、曲の進行に合わせて効果音とかの音程を変更するようにしてみようかと思ったのですが、それをDirectMusicProducerのデータで実現しようとしてソフトを起動して色々調べていたら、どうもどうにも私の考えていたのとは違っていたような違っていないような、とどのつまりは余計に分からなくなって、少々挫折気味なんですが、やろうと思えばプログラムで無理矢理、ということもできなくはないだろうし、そもそもやらなくたってゲーム進行には別に関係ないわけだし、とりあえずDirectMusicProducerのセグメントのパターン切り替えはマスターしているつもりだし、何とかなるだろうしならなくてもよいわけで、結局BGMそのものができていなければBGMに特殊効果をつけるなんてできるわけがありませんので、やっぱり原点回帰で普通にMIDI作るのが無難かと思っていたりするわけです。
う～む、localtimeとかで得たデータをまた秒数に直すにはmktimeか…。
となればもう試行錯誤しながら目的の時間を探す必要はないわけで…。
うん、よさそうだ。
これを使うと以前のデータは壊れてしまうみたいだけど、コピーを持っておけば何の問題も無いというわけで。
ナマライザ読み込みできるようになりました。
エクスプローラからドラッグ＆ドロップで読み込めます。
一括して沢山のファイルを読めます。
重いです。激しく重いです。さすがナマライザです。他のソフトも巻き添えで重くなります。メモリ食いすぎです。
あんまり重いので、強制終了できるようにしておきました。
ログ読み込みは基本的に中断できないんですよ。ログ解析は中断可能ですが。
プログラミングを更新しました。
「activebasic vb c 速度比較」のアレです。
今日は面倒くさいので空ループしかしませんでしたが、結構意外な結果でした。
VBのほうが速いなんて…！
ふにゃさんエディタ、上層マップや下層マップは存在しない場合は保存しないようにしました。
これを保存してしまうとゲーム本体のほうで誤解釈して見た目に汚くなるので。
そろそろ画像読み込みを手軽にできるようにしたいです。
本体のほうでは、ギヤバネとふにゃとの相互作用を改良。天井や地面でギヤバネと重なってしまうと動けなくなってしまっていたのですが、天井ではギヤバネを、地面ではふにゃを強制的に動ける位置まで移動することにより動かなくなる現象を解消しました。
そして、ななななんと！！！！
新キャラ3体追加だそうですよッ！
調査チームが極秘に活動写真を入手したそうなのでお披露目しましょう！！
ふにゃさん、ギヤバネの動きもとげとげの動きも一通りできて一段落したところです。
ふにゃがギヤバネにはさまれるといろんなことになっちゃったりとげとげの反応が遅くて存在意義がアレだったりと微調整がまだまだといった印象ですが、それはステージを作りながら調整していくことにします。
チャット、最新版をアップしました。
アルニックは呼べば出てきます。
また、チャットに誰もいなくなって1時間経つと勝手に出てゆきます。
…しかし、ログ表示の遅さが問題だな…。
今度の更新は各言語ごとの速度比較にすることにしました。
検索でハズレを当てた人がいたので。
今日の絵はカエルの呪いのあの子。
しかもなぜか右側だけ。
プログラミング「Perl→PHP書き換えメモ」に配列処理を追加しました。
なぜこれを更新したのかというと、チャットの在室者管理を作るため。
IDと名前の両方の一致で同一人物とみなします。
今日の絵はPiece of Facesのキャラクターたち。
アキヤメキャラに「悪魔の潜む幼帝とその師」を掲載しました。
まだ作り始めるめどさえ立っていない「Bomber丸World2」からです。
1には名前すら登場しません。
同じく100題に29番を追加。耳です。
昨日のDirectMusicはどうにかなりました。
あんまり演奏結果自体はよくないんですけど動作自体は正しいようです。
やっぱりSMFを使って無理やり切り替えるパネルγ方式のほうがしっくりくるなぁ。
今日の絵は女の子と頭蓋骨。
頭蓋骨のほうは一応資料を見ています。
さてと、チャットの在室者管理でも作りますかね。
入室時：member.dat読み込み→入室者チェック→member.datにデータがなければmember.datに入室者を追加して入室メッセージを表示→member.datを更新
ログ表示時：m読み込み→長期ROMの人がいた場合自動退室させてm保存→在室者を表示
発言時：m読み→発言者がmになければエラー→最終発言時間を更新してm保存→ログ表示
退室時：m読→退室者いなければ何もせず→いたら削除＆m保＆退室メッセージ
てな具合でどうでしょ。
DirectMusicProducerで作ったデータを再生しようとして見事に挫折。
どう頑張っても全く音が鳴らないしエラーが出るんですよぉ。
今日は「Bomber丸World」の海音楽裏。
短調です。
日記カテゴリに「掲示板」と「チャット」追加しましたよ。
パネルγ、久々に更新しましたよ！
かねてからやろうと思っていたキーボード入力です。
(GetKeyState(VK_CAPITAL)&1) ^ (GetAsyncKeyState(VK_SHIFT)!=0)がTRUEなら大文字、FALSEなら小文字というのを利用させていただきました。
ゲーム記のちびロボ！と地球防衛軍2を更新しました。
まあ、例によって公式サイトだけですが。
私は、検索でここに来る人が使った単語のうち、ここにないことを期待したようなものは、このサイトへのリクエストだと考えています。
例えば、「activebasic vb c 速度比較」「midiを作る」「カービィとドンキー」などなど…。
趣旨の分かりかねるものや私では力不足のものもちらほら。
今日の絵は、Bomber丸Worldより、コワレ精神逃避状態。
限りなくテキトーですが、それでいいんです。
それでこそコワレなのです。
ちびロボ！ではついにアーミー隊が解散。
隊員の一部が訓練に厳しさに耐えかねて脱走したのです。
軍曹は二度と大切な仲間を失わないためにより厳しい訓練をしていたのですがそれが裏目に出たのです。
しかし、優秀で勇敢な隊員ちびロボが、猛獣タオのアジトに単身乗り込み、大切な仲間グワム二等兵の形見のドッグタグを取ってきたことで、グワム生存の希望がわき、アーミー隊は再び、以前より強く、結束したのです！(脱走した腑抜け除く)
んで、アーミー隊はプランを練るということで活動停止状態になり、仕方なく残りの腑抜けの相手をすることになりました。
そして、腑抜けの一人メンヒスのチキンレースに挑戦してみると、よくわかんなくてデタラメにブレーキを踏んだら偶然にもがけすれすれ車体の半分が飛び出す形で停止し、おそらく最高評価であろうＳをいただきました。
プログラミングのVB小ネタをちょっと更新しました。
偶然間違えて全角入力モードでコードを打ち込んでしまって気付きました。
もはやトリビアですな。
３Ｄのあれは形としては完成。
羽が動かないのを気にしなければそのまま３Ｄゲームに組み込めるようになっています。
ふにゃさん、タイトルから始められるようになりました。今のところ１面しか遊べないので、沢山のステージを作ろうと思ったらそれだけステージファイルそのものが増えてしまいます。今後はステージクリア・ネクストステージあたりを作る予定。とりあえずギヤバネを数千匹ほど出してメモリ使用量を大きく増やしてガーベジコレクタが正しく働いているかどうか確認。出てきてくれたギヤバネ君には全員犠牲になってもらいました。
エディタ方面では、下層マップと上層マップをうまくいれる方法を考案中。上のほうのマップが下のマップを隠してしまうのでそれをうまく下も見せるように。今のところは、上層・中層・下層の全てのマップに対して、１００％・５０％・０％表示というオプションをつけて、半透明にして上下両方とも確認したり、要らないマップを非表示にしたりできるようにする予定です。その半透明合成を実現するためにAlphaBlendなるAPIを見てみたのですが、ウィンドウを半透明化するのが主な用途らしくて、実際に使えるかどうかは今のところ不明。昔拾ってきたRakkyoGLなんかはその点いい感じにハーフブレンドができるようなので使ってみようかなと思っていたりします。
今日は子どもの絵。どういうふうに「子どもの」なのかは聞かないでください。人体の描き方がさっぱりわかっとらんので数をこなして身につけていかにゃ。
