Q＆A更新！
なんと！カテゴリ分けされて分かりやすくなったのだ！
しかもカテゴリ分けしたのをCGIで管理しておきながら表示はHTMLなので管理が楽でなおかつ軽いのだ！
例のWebスペース増加のおかげでいくらファイルを作りまくっても強気でいられるのだ！！
ふははははっ！
文字列配列管理クラス
さりげなく昨日の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の敵からゲーム本体にアクセスする方法です。
このゲームでは他のキャラクターを使って行動したり、ゲーム内の変数を利用したり、高度なグラフィック処理をする可能性があるので、ゲーム本体のクラスなどに比較的自由にアクセスできることが必要なのです。
う～ん…難しそうだ。
ブーストに大失敗！！
どうもここのところサーバーで用意してもらっているアクセス解析が不調で、何度も見に行っていたら、いつの間にやら空き容量が3桁になっていました。
本来利用できる容量は100MBなので3桁もあるはずはなかったのですが、確認してみるとさりげなく250MBに増えていました。
最近色んなのに手を出して使用領域が増えてきていたため少しファイルサイズをケチろうかと考えていたのですが、この容量増加はつまり、ケチらずガンガン使えという意味だったのでしょうか。
そうと分かれば気兼ねなくどんどん使うぞ！！
といいたいところなのですが、無駄にファイルサイズを大きくしてしまうと閲覧者側の負担に繋がるのでファイルサイズ増加は目指さないことにして、逆にファイルサイズ削減のためにクオリティを落とすことはしないようにしたいと思います。
やっぱりファイルサイズ制限がなくなったことで充実させられるといえばダウンロードコーナーのソフト紹介ページとか、プログラミングコーナーのサンプルとかでしょうね～。
久しぶりにナマライザの開発をやっていて、ログの分解に正規表現を使えないかと思って探していたら、Boost Regex++なんてC++用のライブラリを見つけて、インストールしようとしたのですが、ライブラリをソースからビルドしていたらあまりに時間がかかっておかしいと思いビルド状況を見てみると、いくつものファイルをビルドしていて、その全てで100以上のエラーが出ていたので、仕方なくビルドを中断して、それにかわるライブラリといえば、有料のVB用DLLがあるぐらいで他はよく確認はしていないのですがVBでは直接的にも間接的にも使えそうになかったので、正規表現はいったん諦めて簡易アクセス解析と同様にVBのSplit関数で分解して後でそれを加工する方式をとることにしました。
それ以外では、一応各種情報のための情報を用意したりしたのですが、どうもそれらは一気に全部取得したほうが速そうなので、まとめて取得する方式にしたら変数の数を半分近くにまで減らせそうです。
バイポーラトランジスタ
今日はSPICEを使って電子回路シミュレーションの実験をしていたのですが、出てきた結果がどう考えてもおかしいんですよ。
わずかなベース電流を引き金としてコレクタに大電流が流れるはずのバイポーラトランジスタの回路だったのですが、コレクタ電流がほぼベース電流で一定だったんですよ。
これで一日中わけがわからなくて試行錯誤していたのですが、試行じゃなくて思考してみるとだんだん分かってきました。
ベース電流がそのまま流れてコレクタ電流が遮断されるというのは、つまり、バイポーラトランジスタが一つのトランジスタとしてではなく二つのダイオードとして働いたということなのです。多分。
で、ベース電流を逆にして考えてみると増幅効果が出るはずなのです。
考えてもみればSPICEで入力するのは＋側→－側の順であり、電圧源であれば＋から出て－へ電流が流れるのですが、電流源だと＋から－へ電流が流れるので電流の向きが逆になるんですよ。恐らく。
おかげで電流を逆にすることにより正しい結果を得ることができました。
ペナルティ！
ふにゃさんステージエディタにゲームオーバー時のペナルティの設定項目をつけました。
ペナルティというのは１でもあったように、ゲームオーバーのときコンティニューしてやり直すために消費されるバナナの数で、今回はステージファイルごとに決められたりします。
今回は１のような１ステージバナナ５個の制限がないので、標準ペナルティは100です。
１のときの10はやさしすぎました。
コンティニューしたくない、だけどどうしてもコンティニューしなくてはクリアできない、そんなときの最後の手段にしたかったのです。
ただ、任意に変えられるようにすると０にしたり何万にもしたりする人が現れそうなので、一応制限をつけて、10～999の間にしています。
そうそう、設定項目の値に制限をつける機能もちゃんと今回つけてます。
しかし、実は困ったことに、ゲーム本体のほうではペナルティはおろか、ペナルティに使うバナナの数の保存すらできていないのです。
急がねば。
レゴで6835のUFOをLDrawに入れてから、本体をばらして箱の裏にあった組み換えバージョンを一個だけ作ってみました。
本当は３つあったのですが１つしか再現できませんでした。
あと、昔作っていたオリジナルの海洋警備隊本部兼自宅も再現してみました。
なんだかところどころ微妙に違ってたり一番大切な浮き輪マークの部品が見つからなかったりしているのですが、近いうちには完成しそうです。