日記(945)

<前 次>

微妙な拒絶感

浮き沈みリンク集を改良してみました。
タグがリンクの入れ替わりに応じてくるくる入れ替わってしまってタグをつけても探すのが面倒ということになってしまっていたので、リンクは従来通りスコア順の表示にして、タグはそれとは関係なく五十音順で表示するようにしました。
ただ、前のバージョンのほうがいいという場合もあるかもしれないので、一応これはオプションにしていて、何も設定していない場合は従来の方法で表示するようにしています。

バナーを追加しました。
コネコベーダーを使った白黒の極小バナーで、うちの画像にしては珍しくGIF形式です。
ついでにバナーのアドレスを変更しました。
まずリンク集にある各サイトのバナーの置き場を/links/banners/から/banner/に、それに伴ってうちのバナーもその中に入れて/banner/tgws01.pngと/banner/tgws02.gifです。
この名前の変更は管理上の理由もありますが、うちにリンクしてくれるという人がバナーをダウンロードしたときファイル名に困らないようにするという意味も持っていたりします。

で、そして、ふにゃさんのステージセレクトの改良なんかもしたりしていました。
難しそうな気がしたもんでずっと先送り先送りにしていたのですが、改めてよく見てみると、ステージセレクトでのマップの表示処理はたった3行のコードで書かれていただけであり、結局ちょこっと手直ししただけで開始面を表示できるようになってしまいました(以前は何面まで進んでいても表示されるのは常に1面だった)。

そんでもって、今日は辛口イモ天カレーなんぞを食べてました。
何のことはない、レトルトの辛口カレーに昨夜の残りの芋の天ぷらを乗せただけのものです。
スパイシーな辛口カレーに芋の天ぷら油が微妙な拒絶感を醸し出していました。

ライブラリ

Bomber丸World開発Wikiに旧開発室のライブラリのページを移行しました。
どうにも手抜きして旧ページからコピーしただけのCBWWindowクラスのページは不正確なようです。
他は細かい修正などもあって位置から書いたりしたのでわりと正確なはずですが。

地味な処理

はいはい。
それで、いきなり流れをぶった切ってTGscriptの開発を進めたりしていたのです。
今回やったのはプロフィール読み書きの一番中核部分です。
本当に、IDがいくつだったら開くファイルは何とか、ファイルを開いたらデータをキャッシュに一時入れるとか、プロフィールを閉じるときはデータが更新されているなら自動で保存も行うとか、ほんとそんなところばかり作ってました。
キャッシュに入れる、というのは、例えば掲示板などにおいては、何人かが話しているわけで、何人かのデータをメモリ上においておけばいちいち何度も同じ人のデータを開く必要がなくなるわけです。
だからといって全員ずっと保存しっぱなしだったらメモリが足りなくなってしまうのである程度数が増えたら見切りをつけて適当にデータを閉じます。

可変ウィンドウ

yaneSDKのバージョンや内容も変わったし、最初にCBWDrawを作ったときからゲーム画面の処理も変わってきたのでCBWDrawを手直し中です。
まず、DirectDrawによるフルスクリーンを使わなくなったこと。
これによりディスプレイ解像度の変更が完全になくなるのでゲーム画面の大きさ変更からフルスクリーンとフルスクリーンのときのビット深度のオプションがはずされました。
そして、ウィンドウサイズが自由になったこと。
これはyaneSDKの前提の一つを覆すものなので結構修正が多いかと思ったのですが、CWindowのことあるごとにウィンドウを画面中央に持ってくる部分を修正すれば、他はCBWDraw内部の処理だけでなんとかなりそうです。

そうそう、TGWSにある全てのWikiの更新状況を管理者が一箇所で監視できるようにしてみました。
ユーザー側から見れば別に何もありませんが、こっちから見れば、他の掲示板などへの書き込み通知と同じように見ることができるので非常に便利になるのです。
本当はそういうのに対しては予めメール通知機能がついていたりするのですが、元々私はあまりメールチェックをしませんし、メール送信は案外重い処理らしいので、できるだけ一つのサーバー内で起こったことは一つのサーバー内だけで完結させたかったのです。

DirectDrawは遅かった

で、yaneDirectDrawとyaneDIBDrawの性能を比較してみました。
結果はWikiに書いてあります。
圧倒的というか、話になりませんね。
yaneDirectDraw、単純な等倍転送以外、使い物になりません。
で、全てを拡大する可能性のあるこのゲームでは使えないというわけです。
何しろ一つ転送するのに10ms以上かかるということは、よくあるキャラを二人描いたら60FPSは達成できなくて、五人描いたら20FPSすら出なくなります。

DirectDrawの拡大処理

う~ん、今日yaneSDK1stでDirectDrawによる2倍拡大を試してみたらyaneDIB32にあったような整数倍拡大時のドット潰れが起きていなくて、Bomber丸Worldの描画エンジンも半透明とかエフェクトなどをあまり豪勢に使わないならDirectDrawでもいいかなと思っていたりします。
Bomber丸Worldではドット絵と解像度の関係上拡大処理が多くなって、そうするとyaneDIB32の本領発揮となるエフェクトや各画素ごとの処理などがうまく働かなくなる可能性もあったり、その上単純に処理すべきドット数が増えることによる速度低下なども考えられたりして、その意味でもDirectDrawのほうが良いのかなと思ったりしてます。
だけどそうするとまた描画関連のプログラムがごっそり入れ替わる可能性もあるわけで…。
とりあえずブレンド処理の速度を測ってみてから考えたいと思います。

曲率

ふにゃさんのプレイムービー5~10面をアップしました。
11面以降も録画しようと思ったのですが、あいにく11面でゲームオーバーになってしまったので録画は先延ばしです。
そうそう、現在ふにゃさんのシークレット機能の空を飛ぶふわふわふにゃの動きを考えています。
別にふわふわふにゃそのものの動きでもかまわないのですが、やっぱりふにゃさんなんだから、空気の抵抗を受けたり、くるくる回してみたり、色々やりたいわけですよ。
くるくる回すというのがよくわからないかもしれませんが、やってみればわかるかもしれません。
曲率を利用することも考えてます。

Bomber丸World開発室のWikiへの移行は順調です。
本当はプログラムの深いところをどんどん追記していきたいのですが、やっぱりキャラとかストーリーを書くほうが楽しいので、そっちのほうばかりが充実していきます。

<前 次>