確かな情報筋によるとドラゴンボールが揃ったらしい。
一部で熱望されていた願いがついに実現されたとのこと。いやあめでたい。
せっかくだからTricksterに特訓DXの公開許可を取る。ちょっと細工したら今のバージョンを公開するかも。とりあえず動くだけ、というものだけど。
一応、射撃の腕は上達しているらしい。とりあえずCZ75をもう少し調整しておく事にする。
日本製先行者をぷるうぇいするとWindowsがふっ飛ぶ。JVMの都合だろうか。
やっと眠れる〜という勢いで寝る。
で、朝9時起床。
10時頃、でか過ぎて郵便受けに入らなかった郵便物が届けられる。開封するとDFが掲載されたDOS/V magazineが。ってこれ既に頂いているのですが…。
後は窓の様子を確認するための業者待ち。一応午前中と指定してあるのだが。早く来い、寝かせてくれ〜。
13時、やっと到着。窓が閉まらない点を家の中から、外から力説する。
ドライバーでサッシのネジをぐりぐりして調節。そんな所に調整ネジがあったとは。
「あ、コレで限界だよ」
なんか不安になるような事言わないでください(^^;)。おおむね窓は閉まるようになったので吉。
かなり天気がいいのでそのままどこかに出かけたくなったが業者が帰った後で部屋に戻ったらまた眠くなったので寝る。
21時起床。
まだ眠いような。頭が痛いがこれは肩こりのせいだろうか。
ふみゃー。眠いぃ。
果汁グミを久しぶりに見かけたので購入。なんか、昔よりおいしくない感じが。以前の果汁グミってもう少し柔らかいというか、もちもちした感じがしたと思うのだけど。
カップラーメンが大安売りされていた。100円。大したことないって? ポップには100円と書かれた下に<5kg>と書かれているのだ。つまり、5kgで100円という表示。えーと、カップラーメン5kgって何個分?
ああっ。昨日だよ。
ってをひ。
DFについての動作報告を頂く。
なんでも、ディレクトリを圧縮しようとするとルートディレクトリからがんがん圧縮するとか。
んがっ、なんでだー。
色指定はRRGGBBの方がいいのではないか。確かに。何度かそのような話が。
今使っているユーザのことを考えるとなかなか踏み切れなくてビクビク病にかかっています。
早いほうがいい、とも言われてしまいそれはそれで納得。さて、いつやるか。
そういえばINIファイルの解析ルーチンってサイズ、速度ともにあまりいいもんじゃないな。もう少しなんとかならないものか。
個人的には、ファイルの新規作成で貼付を行った時、既存のファイルの後ろに追加するような機能が欲しいと思うことがあったり無かったり。
コピーした文章をテキストファイルの後ろに追加する、という芸ができると楽かなあと。
ビットマップだったらどうするんだよ、というあたりが悩みどころ。
あふやWZ Filerのような1ウィンドウ2画面ファイラーとDFとでは使い勝手が違うらしいのだけど、どういうところが違うのだろう。
同じようにTabキーで別ウィンドウに切り替えられたりするのだけど。Alt+Tabで切り替えようとすると面倒かも。いや、まさか。
ファイラーはFEP、というとアレかもしれないけど、コンソールというか。何か処理する時の基点として使えると楽だなあと。
DOS(っていうか、CUI)だと作業を開始すると自動的に待たされるので困らないのですが、Windowsだと待たされないので順番に処理をする、というのがちょっと難しい。
CUIでもunixならバックグラウンドで走らせてfgで切り替え、という芸ができるのでバックグラウンドでコンパイルとかファイルの転送なんかをしてたりしますが。
終了待ちするというのも手だけど、終了待ちの間は応答無し状態になりかねない。頑張れば応答無し状態は回避できるけどそこまでする価値があるかどうか。まあ、応答無しでもよければ追加は簡単。
問題は終了するとは限らない所だったり、終了したからといって処理が終わったというものでもなかったり。二重起動防止系のアプリだと、二重起動時にはすぐに終了してしまったりするので、終了を待っても仕方がない。
処理が終わってもウィンドウは開きっぱなしというアプリとかもあるし。
で、DFはそういう他のプログラムを使うことを前提としてコンソールとして使えれば…というノリ。
お好みのエディタ、グラフィックツール、メーラ、アーカイバとあわせてどうぞ、という感じ。
そこでアーカイバ機能を付けてくれ、と言われるのはなんかこう、
「ハンバーガーお一つですね? ご一緒にドリンクはいかがですか?」
「ハンバーカーに混ぜてくれ」
というような感じが。
営業も重要だし、そういう技能は特殊な技能で誰しも持っているものではない、というのは解っています。
ただ、個人的には広めた人よりは物を作った人の方を評価します。
私としては、本を売った販売店よりも本を書いた著者のほうが評価が高いわけです。
広めたのはあなたかもしれないけど、作ったのはあなたじゃなくてあの人とかあの人とかあの人なんだよ。
紹介したものの人気にあやかって注目されたっていうだけのことが解らないのかな。
紹介したものがおもしろかったというだけで、紹介したあなたがおもしろいというものでは無い、ということが解れば、実は落ち込んだりする必要がまったくないということが判るハズです。
え、なんの話だって? 別にシャー専用機の話ではないのですが。他人のネタでウケを取ったもののあとが続かない所ってのがたくさん出てきて見苦しいもので特定のアレ、というつもりはありません。
ああっ、このがむしゃらに迫りくる現実から目をそらしたい…。
月末から連休明けに納期が延びたっぽいんですけど、月末から連休なので全然変わらないんですけど。
休むなって? いや、客先が休むもんだから結局作業できないとか。
ああっ。今日だよ。
なんだかこの3日間で1ヶ月分の仕事をした気分。
自分のことながらやればできるじゃんとか思ってみたりみなかったり。
なんかこう、ここ一年ほど真面目に仕事する気力が沸かないとか言う。
そのあまった気力はどこへ行くかというとDFとか特訓とか。ゲームゲームゲーム…という方向にはあまり流れなかったなあ。最近おもしろいゲームってドリラーくらい?
ファイラーはFEPだと思います。というか、そう使える方が便利。
FDを使っていた時はFDでファイルを選択してAlt+?でコマンド起動、という感じで使ってましたし。単にファイルのコピーとか削除ができればいい、というものではなくて。
今のところ、ファイルを操作することということはコンピュータを使うことだと思うので。ファイルという概念が無くなる日も来るかもしれませんが、もうしばらくは残るでしょう。
で、DFで$Fを使うと一気に起動させているのはせっかくマルチタスクなOS使っているんだから一気に起動した方がおもしろいんじゃないかとか思ったというのがオチ。便利かどうかはともかく。
DOSなら待たされてもしかたないけど、せっかくWindows使ってるんだし。
ソースファイルを選択してコンパイルさせるとプロンプトが複数開いて同時にコンパイルしてくれるのは割とおもしろいです。
ってこんなこと書いてる場合じゃないんだってば〜。
なんて客先に移動しながら思いつつ。
ああっ、こういう時に限って特訓のネタが…。
手をつけている暇が無いのでとりあえず、ウェイトして約60fpsにしているルーチンをフリッピングに変更。
あまりティアリングとかが気になるというものでもないのだけど。
DirectXだとリフレッシュレートを設定するパラメータが無いようだ。リフレッシュレートはDirectX3からだっけ? 5? DirectX7.0aSDKだと、どのフラグがどのバージョンから使用可能になったのかは記述されていないので調べるのが厄介。
しかも IDirectDrawSurface7::BltFastはWindows 98が必要、なんて記述されていたりするし。デスクトップのほうはWindows 95だからWindows 95を切り捨てるわけにはいかない。DirectX6.1を使えということか?
そういえば、先週の仕様変更の影響が思ったより大きくて設計への反映が間に合ってない。次から次へと穴が見つかる。
後から見つかるよりはマシだが、開発中止にするくらいなら仕様変えないでくれ〜。
作業が間に合いそうに無いので今のうちからコーディングしてもらっている箇所もあるのだが、何度も修正してもらうハメになっている。
開発中止ってのが決まっているだけにやる気も上がらない。
明日だよ。間に合わないよ。
DF、見た目がダサイですか(/_;)。
本人、割と気に入っているのですけど。まあ、デザイン系のセンスは乏しいので仕方がないといえば仕方がない…(/_;)。
というか、仕事がてんやわんやになってそれ(何?)どころではない。
来月中旬に設計書とソースコードを納品、という予定があさってまでに設計書だけでも納品という形になってしまったのだ。
製品が開発延期(中止?)になったので、現状の資料を引き渡す必要が出てきたため。
この仕事、アセンブラで開発するということになっていたのだけど、ちょっと他に無いMPUを使うもののため、コンパイラが提供されてから吐き出されたコードを使ってコーディングしようと考えていた。
しかし、開発中止が決まってしまったためにコンパイラも提供されなくなったため、もくろみが崩れさる。
設計とCによるコーディングを同時進行させて設計の漏れを早期に発見しつつ、設計書とソースコードを同時に納品、という予定で同時進行させていたため先に設計書だけよこせと言われても困るというか。
しかも、私の担当分はいつの間にか脹れ上がってて他人の二倍あったりする。予定としては期間がそれなりにあったので問題ないと思っていたのだが、あと一ヶ月の予定が2日に縮んじゃあなあ。
なんだか判らないあいまいな部分を担当していたせいで、なんだか判らないものは全部私の担当になってしまった。
DirectX7.0aSDKを入れる。と、HDDの空き容量が無くなる。
デジカメで取りためていた画像とか@niftyの会議室ログ(去年分)をPDにコピーしてHDDから削除。
とりあえず当座はしのげる。
FIVAのバッテリーも死んできたし、HDDも足りないし、なんとかしたほうが効率が悪くてしょうがない。
今出ているFIVA20xも少し気に入らないというか、Crusoeの次版に期待しているので今のは手を出したくない感じ。
となるとバッテリーとHDDということになるのだけど、本体を買い替えたら意味がなくなる物に投資するのもなあ…。
という案も。画像とか資料とか、古いソースのバックアップなんかをどんどんデスクトップにコピーしてFIVAには作業するためのファイルしか残さないとか。
でもバッテリーが…。
今日のGM。未参戦。めちゃくちゃ混んでて。
今日のDDR。DIVEで回りそこねる。CEREBLATE NINEで回る。B4U long version(MANIAC)。撃沈。
体脂肪は10.5%。運動し過ぎたか。
特訓DXをデスクトップで動かしてみる。
デスクトップはPentium 100MHz、ビデオはTrio64というスペック。
がーん。320x240x8という解像度をサポートしていない。
一時凌ぎにディスプレイモードを640x480x8にしてStretch掛けてみる。
22fps。
…遅過ぎる、いくらなんでもコレは変だ。
というわけでDirectX6のSDKをインストールして調査。
んがー。ハードウェアBltにStretch機能が無い。つまり、今のはVRAMから1ピクセル読み込んで拡大しながらVRAMに転送していたのか。33MHzのPCIバスからちまちま読みこむんじゃ考えただけでも遅そうだ。
まあ、実際に遅いんだけど。
仕方がないので640x480x8にして、そのまま拡大せずにBlt。左上だけに表示されるがまあ、こだわらない。
は、速い。速過ぎる。これが本当にPentium100MHzか?
で速度は450fps。うそー。
200MHzで動作しているFIVAが480fpsなのに。
640x480x8だと、FIVAで160fpsしか出なかったから解像度落としたのに。特訓99がFIVAで180fps程度、デスクトップで80fpsとなんとかぎりぎりという感じだったのでこれだとデスクトップで速度が出ないだろうと判断したわけ。
実はまったく問題なかったらしい。というかむしろデスクトップの方が速いとか。
調子に乗ってLibretto SSでテスト。
こいつも320x240x8の解像度はサポートしていない。
そういえばTricksterのLibretto 50では問題なく動いているわけだから、実はスペックダウン? NeoMagic使えねー。
同じく640x480x8の解像度でテスト。
…背景が消去されない。
どうやら背景消去要求が受け付けられていないようだ。
これは背景の消去を非同期で行って欲しかったためにDDBLT_ASYNCを付けていたのが原因。非同期、というからにはビデオカードの処理が終わるまでCPUが待たされないという効果があると期待した。というか、付けないと同期転送するのでは、ビデオカードの処理が終わるまで待たされてしまうのではないかと思ったのだ。非同期だし。
それが実は、非同期転送ができる時には常に非同期で転送するらしい。それでは何のためのDDBLT_ASYNCなのだ?
このフラグの意味は、転送する準備ができるまで待たない、ということらしい。準備ができない時にはエラーを返すとのこと。まあ、エラー処理を省略していた私も悪いのだが。もし省略していなかったらASYNCがAsynchronousを意味していないということには一生気付かなかったかも。
で、このフラグ、どういう時に使うのだろう。
転送して待たされるくらいなら並列度を上げるために別の処理をしよう、ということだろうか。だったら最初から別の処理しておけば転送を試みる必要が無くなるので意味がない。そもそも、サーフェスがBUSYかどうかは簡単に取得できるので困らない。
うーん。
何にしろ、非同期とは関係ないものに非同期と名前を付けるのは勘弁していただきたい。付けるのなら待たない、ということでDDBLT_NOWAITという感じがふさわしいと思う。
今日のGM。3連敗。
アッガイのスーパー頭突き、どう対処するのがいいのだろう。近寄られたらアウトっぽい。
久々にDFの修正。
ファイルのリネームとワイルドカード選択のダイアログで使用している入力用テキストボックスに入力文字数の制限があったため、長いファイル名に変更できないなどの不具合を修正。
ついでにワイルドカード選択のキーをCtrl+Uから*(FD準拠)に変更。
遅い遅いと文句を付けているFIVAだけど、よく考えると内部構成的にはPentiumではなくて486と同等なんだよな。
1クロックで実行できる命令数が1個しか無いのだからPentiumに比べれば遅いのは当然か。
やっぱりクロックを性能の指標とするカタログはキライだ〜。
OSもセットでプリインストールして販売するのだから、カタログにはOSが起動するまでの時間も記載して欲しいな。
カタログ上有利、ということでWindows 98がプリインストールされたりして。Meよりマシだと思うのだけど。
特訓DX。誘導弾を追加。まだ発射する敵はいないというか、作っただけ。
転回方向を決めるためのアルゴリズムを特訓99とはがらりと変える。
特訓99の時には、再度目標物への角度を求め、現在の進行角度と比較して右か左かを選択した。
今回作ったのはもっと単純に進行方向に直線を引いて、それより上か下かで左右のどちらに曲がるかを選択する。
仕組み的には速そうな感じだ。
と言うわけでベンチマーク。
例によって16384回ループ。
| 特訓99式 | 今回版 | 2ms | 7ms |
がーん。
特訓99の角度算定方法()と特訓DXの角度算定方法ではかなり効率がよくなったのだけけど(ベンチマーク取らなくても判ったので未計測)ここまでよくなっていたとは。
もう少し弾を増やしても問題無さそう。ネックは演算ルーチンじゃなくて描画だし。
マッピングによる当たり判定のベンチマーク結果が残念な思いをさせてしまったらしい。
アレはアレで効果的というか、オブジェクトが多くて複数の物体の当たり判定を行わなければならない時には非常に有用だと思いました。
たとえばパチンコ台のエミュレートとか、ピンボールとかだと使えるかも。
ちなみにテスト用として書いたのはこんなコード。
#define STRICT
#define WIN32_LEAN_AND_MEAN
#include<windows.h>
#include<mmsystem.h>
#include<stdio.h>
#include<stdlib.h>
typedef struct tagEN EN;
struct tagEN{
EN *next;
int x;
int y;
};
#define TEST_NUM 32
#define EN_NUM 16384
EN en[EN_NUM];
EN *map[15][20];
int xpos;
int ypos;
void init(void){
int i;
for(i=0; i<EN_NUM; i++){
en[i].x=(rand() % 5120) <<4;
en[i].y=(rand() % 3840) <<4;
}
}
void test1(void){
int st;
int ed;
int hit;
int i;
int loop;
st=timeGetTime();
loop=TEST_NUM;
do{
hit=0;
for(i=0; i<EN_NUM; i++){
if(xpos < en[i].x && en[i].x < xpos+4096 &&
ypos < en[i].y && en[i].y< ypos+4096){
hit++;
}
}
}while(--loop);
ed=timeGetTime();
printf("all test %dms. hit %d\n", ed-st, hit);
}
void test2(void){
int st;
int ed;
int hit;
int i, j, k;
int l, m;
int loop;
EN *p;
loop=TEST_NUM;
st=timeGetTime();
memset(map, 0, sizeof(map));
for(i=0; i<EN_NUM; i++){
i--;
j=en[i].x / (256*16);
k=en[i].y / (256*16);
en[i].next=map[k][j];
map[k][j]=&en[i];
}
i=xpos/(256*16);
j=ypos/(256*16);
do{
hit=0;
for(l=0; l<3; i++){
for(m=0; m<3; m++){
p=map[j+l][i+m];
while(p){
if(xpos < p->x && p->x < xpos+4096 &&
ypos < p->y && p->y < ypos+4096){
hit++;
}
p=p->next;
}
}
}
}while(--loop);
ed=timeGetTime();
printf("mapped test %dms. hit %d\n", ed-st, hit);
}
int main(void){
int loop;
/* initialize */
xpos=(160-8)*256;
ypos=(120-8)*256;
for(loop=10; loop; loop--){
init();
test1();
test2();
}
return 0;
}
init()で敵を配置して、test1()が総当たりで当たり判定を行ってみるテスト。test2()がマップを作って当たり判定を行ってみるテスト。
TEST_NUMは当たり判定を行う回数。EN_NUMは敵の数。
でどこが遅いかというと test2()の最初に出てくるforループ。除算とリンクリストの構築が遅い。
そこから先の当たり判定自体は総当たりの時に680ms程度の場合には30ms程度にまで減らせるのでいい感じ。
マップを650ms以内で作れるようにれば効果がでてくるのだが、現状だと1800msくらいかかっている。3倍速くしないと。シャア専用。
TricksterのK6-2+(500MHz)マシンでは3600fps出た模様。
FIVAは200MHzだから3600×200÷500=1440ってことで1440fpsでてもおかしくないということになるのだが400fps出るのが精一杯。理論値とは3倍以上の開きがある。
ここまで差があるようではPCの性能にCPUのクロックを用いるのは根本的に誤っているのではないだろうか。
コレからはカタログにCPUのスペックだけじゃなくてベンチマークのスコアを載せて欲しいなあ。
用途によって向き不向きなPCがあるわけだけど、買うまで判らないというのは何とかならないモノか。
なんとなくfor(i=0; i<N; i++)ではなくてfor(i=N; i; i--)と書いてしまう。この方がdecしたあとのZFで条件分岐してくれそうな気がして。inc i; cmp i, N; jc XXX; ではなくて dec i; jnz XXX; を期待するというか。これだとcmpしなくていいし、レジスタストールも無くなる。
WATCOM C/C++がそこまで最適化してくれるかどうかは不明。
なんにしろcmpよりもtestの方が速いし。
なんとか敵が少ない時なら400fps以上でるようになった。
敵とか弾とか見えません。液晶の応答速度の問題かもしれないのでCRTで見てみたい。
結構動いてきたのでタイトル画面とか作ろうとしたらめちゃくちゃハードルが高くて悩む悩む。
ふつーのゲームだと大雑把にこんな感じの流れになっていて、タイトル画面が終わるまでは次に進まないし、ゲーム中にどっかにふっ飛ばされることも無いので順番通りに処理を並べるだけでいい。
という感じのものを作って順番に呼び出してやればOk。
しかしWindowsだとOSからのメッセージを処理したりウィンドウ関連の処理があったりするので黙々と順番通りに処理していられない。
画面の移り変わりにはキー操作をともなうことがあるので、それぞれの処理の中でキーボード操作の処理を書いてやりたいところだけど、キーボードが押されたという通知はウィンドウに対して届くので、ゲームの処理とは別にウィンドウを管理するための処理が必要。
しかもDirectXを使うと、ディスプレイを制御できるウィンドウは一つに限られてしまうのでそれぞれの処理に応じてウィンドウを用意してやる、と言うことができない。一つのウィンドウを使いまわさないといけないのでまた手間が増える。
ウィンドウに対する通知ではなくてGetAsyncKeyState()とかDirectInputなどを使えばキーボードの状態を取得できるのでこのやり方で処理すると少なくとも入力周りに関しては素直に書ける。
だからといってOSからの通知メッセージを無視していたりするとWindowsを終了させようとした時に時間がかかったり「応答無し」とか言われてしまったりするのであまり楽にはならない。結局ある程度の処理をする必要があるので面倒。
また、GetAsyncKeyState()やDirectInputでキーボードの状態を取得すると、キーの同時押しが判定できなくなる。同時押しを使うようなアクションゲーム系にはちょっと使えない。また、状態取得にかかる時間的なオーバーヘッドも高いので高速で動かしたいアクションゲームでは厳しいものがある。
となると、結局OSからウィンドウに対する通知でキーの情報を処理するしかない。
そうすると、タイトル画面から次の画面に進むためのきっかけが、タイトル画面処理の中だけで完結しなくなるのであっちとこっちとで連携させる必要が出てきて厄介ごとが増える。
また、同じキーでも画面によっては役割が違うので、キー入力通知を受け取った時にどの状態でキーが押されたのか判断して処理を分岐しなきゃいけない。
こういう時にはウィンドウのサブクラス化によって、根本的に処理を切り替えてしまうというテクニックがある。特訓とかBKEY、DFでは多用している。
サブクラス化することで状態を限定できるので余計な処理がまぎれ込んでくる可能性も無くせるし状態判定をしなくてもすむのでコードも減らせる。想定していない処理が起こらないということと、コードが少ないということで、バグも減らせる。またあったとしても見つけることが容易になる。
でもDirectX(というかDirectDraw)にはDDERR_HWNDSUBCLASSEDというエラーコードがある。
どうやらウィンドウをサブクラス化するとDirectDrawがうまく動作しないことがあるらしい。
と言うわけで残念ながらサブクラス化も断念。
タイトル画面とかでちょっとアニメーションさせようとか思うと、めちゃくちゃ面倒。
ウィンドウを切り替えられてしまうと現在の表示内容はすぽぉんと消されてしまうのでどこかに保持しておかないといけない。
ウィンドウが切り替えられたタイミングでバックアップを作ろうとしても、当然切り替えられたあとなので既に表示内容は消されている。
なにか定石みたいなものは無いのだろうか。結局、車輪の再発明を行うことになりそうな気がする。
メモリデバイスコンテキストに描いておく、というのが手かも。ってそれではDirectXの立場が…。
しかし、どんな時でも総当たりで調べるよりマップする方が速いというのは不可解だ。
ifによる条件判定は減るとしても、マップするという処理はすべてのキャラクタに対して行っているので、条件判定よりマップするほうが速いというものでなければちょっと成り立たない。
というわけで1024キャラクタのテストを16,384回繰り返してみるテスト。30回テストしてその平均を求めた。。
| 総当たり | マッピング | マップしたものの判定 |
|---|---|---|
| 約719ms | 約1860ms | 約30ms |
この結果を見る限り、昨日のテストでは繰返し回数が少な過ぎたために時間が判りにくかったようだ。
計算しやすくするため、大雑把に考えて600、1800、30にして考える。
総当たりで判定する時間を1、当たり判定をもつキャラクタ数をxとすると総当たりだとx時間かかるところがマップ判定だと3+0.05x。
マップは16x16で切ってあるので、実際に当たり判定を行う分は32×32 ÷ 320×240で1.33%程度に収まるハズなのだけど、リストを手繰ったりする必要があるので5%程度になるのは妥当かもしれない。
仮にこの部分を高速化してもそもそも全体の5%以下という処理量なのであまり効果はない。むしろマップを作る処理を高速化しないと。
総当たり判定をもつキャラクタが3つになった時点で総当たりだと600×3で1800ms、マップだと1800+30×3で1890とほぼ同値。
とりあえず総当たりで処理するか。
ちなみに、現状だと処理自体は遅くても2ms以内で終わっているのでマップで処理したところでコマ落ちをおこすことは無いような気もする。うまくいっている時には1msかかっていない。
どこで時間がかかっているか調べてみると、サーフェスのロックとBitBltでの転送。特にロックできるようになるまでの時間待ちが長い。
FIVAのような統合型ビデオチップでもCPUとは並行して動作しているので、ビデオ側にBitBltを要求してから、敵キャラの移動処理などを行ってもまだビデオチップが処理を終えていないので待たされてしまうという。
もっと並行度をあげるような構造にしないとダメかもしれない。
てなわけで(掲示板参照)、一時的にシェルをExplorerに戻してinternat.exeを起動させる。
どうやら、ツールバーの表示/非表示はHKEY_USERS\.Default\control panel\input mestdのshow statusという所に記録されているらしい。
…HKEY_USERS? HKEY_CURRENT_USERじゃなくて? もしかしたらユーザー共通の設定? それはちょっとひどいんじゃないかい?
っていうか、regeditで書き出したレジストリの中にはHKEY_CURRENT_USERが見当たらない。書き出す時にはHKEY_CURRENT_USERの項目をHKEY_USERSとして書き出して、取り込む時にはHKEY_CURRENT_USERのものとして取り込むのだろうか。なんか不思議。
ソリテール(単四電池使用のマグライト)がへたってきたので買い替えを検討。
どうも電極の接触が悪いらしく、振ると何事も無かったかのように点灯するのだけど、運が悪いと何度振っても点灯しない。点灯してもみょーに暗かったりして使い物にならない。
中をのぞいてもスイッチらしいものが見当たらないので、どういう仕組みでスイッチが入るのか考える。
電球のハウジングをゆるめると点灯、締めると消灯、という仕組み。逆なら簡単そうな気もする。
どうやら、電球ソケット部分が可動するようになっていて、押し込むと接触が断たれる、というものらしい。
電球ハウジングを締めつけることでソケットを押しこみ、接触が断たれて消灯。
逆に緩めるとばねか何かの力でソケットが復座して点灯、という感じかな。
で、どうやらこのソケットを復座させるためのばねがへたっているらしい。どうやったら分解できるのか皆目見当も付かないのでやはり買い替えるしかないか。
ハンズで1,400円、長崎屋で1,200円程度のもの。
ソリテールもマグライトの仲間で、一応「永久保証」をうたっていたような気がするけど…。まあ10ドルちょっとの物を永久保証っていうのは無理があるか。
というわけでソリテールはまた使えなくなるのが目に見えているので別のものにする。電球のだとバッテリーの持ちが悪いのでLEDのものにしようと思う。悪いというわけでもないのだけど、LEDのほうがはるかによい。
で、ハンズで目をつけたのが松下のキーライト(1,480円)とINIFINITY TASK LIGHT(2,500円)。
キーライトのほうは陳列品に電池が入っていて、操作可能だったので試してみる。かなり明るい。電球寿命は1万時間。本当か? バッテリーはボタン型電池(型番は忘れた)4つ。かなりの大食らいというか、かなり電圧高め。
INIFINITYのほうは操作不可能なのでちょっと判らない。高いし。でも防水なのとバッテリーが単三電池1つというのが気に入った。電球寿命は10万時間。本当か? もし本当に10万時間持つのならキーライト10本分と思えば安いことになる。
ソリテールみたいに使えなくならなきゃいいけど。
ぴかぴかのメッキ仕上げのキーライトとフラットな黒塗り仕上げのINFINITYだとなんとなくINFINITYのほうがかっこいいのもあってこちらに決定。
で、電池も購入して点灯。
んー、キーライトの方が明るいか? でもコレで充分。というか昼間でコレだけ明るければ玄関先とかを照らすぶんにはまったく困らない。単にあっちはボタン型電池4つを直列にするという豪快な電圧をかけるので、その分明るいのだろう。ということはこちらもLR44あたりを8つ直列にして(やめろ)。
色も真っ白で電球独特の赤っぽい光ではないのが気に入ったりする。
LEDがむき出しでなくてレンズを付けて反射板が付いていればキーライト並に明るくできるのではないだろうか。アルミホイルでも張ってみるか(チープ)。
2,3個並べて撮影の補助用光源として使うというのはどうだろう。
とおもったら、近距離しか照らせない。うーん。やはりレンズと反射板は必要か。もう少し遠くまで照らせると便利なんだけど。
P90。ネットの通販サイトとかガンショップのサイトを見ていると、予約だけで入荷分が埋まっているところが多いなあ。やっぱダットサイト付きはおいしいか?
でもオープンサイト付いてないんだよな。
当たり判定のベンチマーク。
総当たり戦とマップ併用。
最初、マップがものすごく遅くてビビったけど最適化を掛けたら速くなった。
| キャラクタ数 | 判定数 | 総当たり | マップ |
|---|---|---|---|
| 1024 | 1 | 0から6ms | 0から1ms |
| 2048 | 1 | 0から16ms | 0から1ms |
| 8192 | 1 | 0から6ms | 1から3ms |
| 16384 | 1 | 1から7ms | 2から6ms |
| 1024 | 16 | 0から6ms | 0から1ms |
| 2048 | 16 | 2から9ms | 0から1ms |
| 8192 | 16 | 11から26ms | 1から2ms |
| 16384 | 16 | 22から84ms | 3から6ms |
| 1024 | 32 | 1から7ms | 0から1ms |
| 2048 | 32 | 4から19ms | 0から1ms |
| 8192 | 32 | 21から40ms | 1から2ms |
| 16384 | 32 | 51から100ms | 4から5ms |
マップする価値ありか?
判定数は自機にしか当たり判定を設けないとすると1固定になるけど、処理速度が安定しているというのは捨てがたい。
でも、実際に使うのは1024個の弾と128個の敵オブジェクトだけなんだよな。総当たりでも対して処理時間に差が無いとか言う。
ネタが無いので特訓作りかけのスナップショットでお茶を濁してみるテスト。
GMの練習。ガンダムの前でディスプレイに見入っている兄ちゃんがいた。やるのかなあ、と思って対戦はしたくないのでとりあえずDDR5thでDIVE、DIVE、DIVE。
まだ見てる。見てるだけか。だったらゆっくりと練習させてもらおう。
席に座ってコイン投入…ってあれ、あの兄ちゃん、2P側に座りやがった。ま、対戦とは限らないし…ということで連邦軍を選んでGM選択。げ、ジオン軍を選んできた。やる気だ。あの人はねぇ、本気なんだよっ! ってことか。
こっちはやる気が無いというか、腹が立ったのでプレイせずに席を立ってDDRでDIVE、DIVE、PARANOiA MAX。
プレイするならするで席に座ってプレイしてろって言うか。私はお金払ってまであんたとやりたくも無い対戦プレイなんかしないぞ。
あ、ガンダム空いた。と言うわけで席に行く。あ、先に入られたっ。でも連邦だ。共同プレイで乱入。ありがたくGMの練習をさせていただく。
あはははー、へっぽこだー。どうも間合いがつかめない。
ビームスプレーガンは出るまでが長いというか。相手の硬直時間に撃たないとかわされてしまう。
バルカン。射撃+格闘なんだけど、なぜかロックオン+射撃を押してしまう。P+Gのつもりなのか? ダメじゃん。
ゲルググのナギナタ強過ぎ。重ねられたら逃げ場が無い。見つけられないだけ? 一発入るとそのまま破壊確定って感じでいやぁん。
カメラ位置が状況に応じてくるくる変わるのはおもしろい。おもしろいんだけど、距離がつかめなくなる。敵に近づいた、と思ったら単にカメラが寄っただけだったりしてビームサーベル空振り。その隙にナギナタ確定。んがー。
もうちょっと硬直時間が短いと助かる…。
ってな感じでプレイしていて私がやられてゲームオーバー(笑)。
でもココ、1コイン2クレジットだし。懲りずに連邦で再入。
げ、向こうは対戦にしてきやがった。がーん。
でも勝った。私以上にへっぽこだったらしい。
あ、援軍だ。ありがとー。げ、ガンダム。コスト高いじゃないのー。やられないでよ〜。
あ、そこそこ戦ってくれる人みたい。助かる〜。っていうか、見てるとGMよりはるかに反応速度がいい。プレイヤーの反応速度なのか、機体の反応速度なのか。プレイヤーの反応速度だと思いたい。GMでも充分戦えるハズだと信じたい。
安心して敵はガンダムに任せて(をひ)、間合いの確認とタイミングの調整。なんかレバー操作との組み合わせで技が変わるようだ。でも何がなんだかさっぱり。
起き上がりの攻防はどうしたらいいのだろう。
って適当にやっているうちに勝ってしまった。うわ、ガンダムかなり敵をなぎ倒したらしい。どんなプレイヤーなんだろう…って、子供?
どう見ても7歳行ってないくらい。おいおい。でも座っている位置が変だな。隣に誰かいるのだろうか。
ちょっと遊び過ぎたから次は攻め込むことにしよう。
うおー、あのガンダム、つえー。
敵を見るや突っ込んでいって撃破してやがる。っていうか、ビームライフル強くない? 気のせい? 出るまでの時間がスプレーガンとずいぶんと差があるような。
しかしあのツッコミっぷりはかなりの熟練者のようだ。どんなプレイヤーなんだろう…ってやっばり子供しか見えない。お前か? 本当にお前なのか? うそー。
結局ガンダムの方が戦果がおおいでやんの。GMじゃだめなのか?
っていうか、お子様恐るべし。
結局、次のステージも、その次もガンダムの方が戦果を多くあげてました。私の負けです。
ビグザムに負けて終了。
っていうか、ガンダム突っ込み過ぎだって。ビグザムに真正面から突っ込んで撃破されてんじゃないよー。コスト高いんだから。
さすがお子様。しかし、真正面からビグザムを斬り付けているガンダムはカッコ良かった。もう度胸ありまくり。一緒になって斬り付けて遊んでしまった。
東京マルイのP90、10周年記念価格でダットサイト付き29,800円とのこと。この10周年記念価格というのがミソで、5月の二次出荷では値上がりするかダットサイトが付かなくなる公算が高いとか。
ホビーサーチでは、次期入荷分からはダットサイトが付かない、という話。
ポストホビーでは、次期入荷分からは値上がりするか、ダットサイトがなくなるのではないか、とのこと。
うーん、買うなら今か? ポストホビーでは残り2+展示品1。ヨドバシではたくさん積んであったけど…。
ポストホビー価格で23,840円。どうだろうか。
internat.exeが例外出して死亡。
LiteStepのsystray系との相性問題だと思うのだけど、なぜ今ごろ?
何かのモジュールを差し替えればOk、という話だったのだけどどれだったか忘れた。というか、こちらでは問題が起きなかったので無視したというのが正確かも。
うーん、何をどう入れ換えるんだっけ。
ものすごく頭が痛くなってきたので日記を更新せずに寝る。
同じDirect Xのバージョンで、DirectDrawのBlt、BltFast、Lock、Unlockの速度って、DirectDrawのバージョン間で変化は無いのだろうか。
特にハードウェアのナニを使っているわけではないのでDirectDrawを使っているけど、速くなるならDirectDraw7にしてもいいかなとか。
いつもならとにかく実験してしまうのだけど、Direct X7のSDKが見つからない。
8はFIVAで良くないことが起こるらしいのでいやー。
今日のウィークリーまぐまぐで所ジョージvs山本譲二の勝負の結果が判るかもっと思っていたら載ってなかった。がっくし。
所ジョージという話もあるようです。
しばらくなぜか解りませんでしたが、日記のネタとして引用しようとしてペースト。ペーストした途端に理解しました。
ネタバレなので一応削除。
やはり私はこちらの方面の知識というか発想力というか頭脳回路が発達していないようです。つまらない人間ですね、はい。
みんなが笑っている中で私だけ何がおもしろいのかさっぱり解らなかったあの時も、あの時も、また別のあの時も、もしかしたらちょっとしたネタがあったのかもしれない。結構笑えるポイントを逃してますか。もったいない。
突然「オレって撫で肩だからよー」と弁解する某様を思い出してしまった。
アレは撫で肩っていうか、単に首が太くて肩が埋まっているというか。
10日に敵の描画を高速化するために画像データを連続させたところ、一キャラクタの描画にかかる時間が半分以下になった。
それまでは画像データはBMPファイルそのままの状態で保持していた。たとえば256x256のビットマップを使用している場合に16x16のキャラクタを描画する時には、横の1ラインは連続しているものの、下のラインに移る時に転送元を240バイトずらしてやらないといけない。
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | … | 254 | 255 | 256 |
| 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | … | 510 | 511 | 512 |
上の表で言うところの16番のピクセルを転送したら、次は17ではなくて257番のピクセルを転送しなければならないわけ。
最後のピクセルは、はるか先の3856番ということになる。
この +240 という足し算を省略できれば一キャラクタ当たり16回、秒間60回呼び出しているわけだから秒間960回、同時に50キャラクタ表示していれば48,000回の足し算が省略できる。
たったコレだけのことで、速度が倍になってしまう。多分、画像データが1次キャッシュに収まりやすくなったというのも理由の一つかもしれない。
と言うわけで、現在はビットマップから16x16、256バイトごと領域ごとに切り取ってメモリ保持している。これが16x16ドット以外のキャラクタを表示させにくい理由の一つ。
で、今回は弾にも同じことをしようというわけ。
弾の画像は8x8の大きさなんだけど、基本的なキャラクタサイズは16x16なので
| 弾A 1ライン | 弾B 1ライン |
| 弾A 2ライン | 弾B 2ライン |
| 弾A 3ライン | 弾B 3ライン |
| 弾A 4ライン | 弾B 4ライン |
| 弾A 5ライン | 弾B 5ライン |
| 弾A 6ライン | 弾B 6ライン |
| 弾A 7ライン | 弾B 7ライン |
| 弾A 8ライン | 弾B 8ライン |
こんな感じに格納されている。メモリイメージ的には平面ではないので
| 弾A 1ライン |
| 弾B 1ライン |
| 弾A 2ライン |
| 弾B 2ライン |
| 弾A 3ライン |
| 弾B 3ライン |
| 弾A 4ライン |
| 弾B 4ライン |
| 弾A 5ライン |
| 弾B 5ライン |
| 弾A 6ライン |
| 弾B 6ライン |
| 弾A 7ライン |
| 弾B 7ライン |
| 弾A 8ライン |
| 弾B 8ライン |
こんな感じ。
コレをなんとかして
| 弾A 1ライン | 弾A 2ライン |
| 弾A 3ライン | 弾A 4ライン |
| 弾A 5ライン | 弾A 6ライン |
| 弾A 7ライン | 弾A 8ライン |
| 弾B 1ライン | 弾B 2ライン |
| 弾B 3ライン | 弾B 4ライン |
| 弾B 5ライン | 弾B 6ライン |
| 弾B 7ライン | 弾B 8ライン |
と並び替えたい。
なんとなくこういうパズルは好きなので思わず考えてしまった。
結論としては次の手順で実現してみた。
領域を4分割し、右上と左下を入れ換える。
| 弾A 1ライン | 弾A 5ライン |
| 弾A 2ライン | 弾A 6ライン |
| 弾A 3ライン | 弾A 7ライン |
| 弾A 4ライン | 弾A 8ライン |
| 弾B 1ライン | 弾B 5ライン |
| 弾B 2ライン | 弾B 6ライン |
| 弾B 3ライン | 弾B 7ライン |
| 弾B 4ライン | 弾B 8ライン |
上下二つの領域についても同じように領域を4分割し、右上と左下を入れ換える。
| 弾A 1ライン | 弾A 3ライン |
| 弾A 2ライン | 弾A 4ライン |
| 弾A 5ライン | 弾A 7ライン |
| 弾A 6ライン | 弾A 8ライン |
| 弾B 1ライン | 弾B 3ライン |
| 弾B 2ライン | 弾B 4ライン |
| 弾B 5ライン | 弾B 7ライン |
| 弾B 6ライン | 弾B 8ライン |
さらに上下二つの領域について領域を4分割し、右上と左下を入れ換える。
| 弾A 1ライン | 弾A 2ライン |
| 弾A 3ライン | 弾A 4ライン |
| 弾A 5ライン | 弾A 6ライン |
| 弾A 7ライン | 弾A 8ライン |
| 弾B 1ライン | 弾B 2ライン |
| 弾B 3ライン | 弾B 4ライン |
| 弾B 5ライン | 弾B 6ライン |
| 弾B 7ライン | 弾B 8ライン |
完成。
弾画像入れ換え(領域, 高さ){
左下と右上を入れ換える;
if(高さが1なら){
終了;
}
弾画像入れ換え(上半分の領域, 高さ /2);
弾画像入れ換え(下半分の領域, 高さ /2);
終了;
}
こんな感じ。
もっと考えるといろいろおもしろいやり方がありそう。
とりあえずこのやり方なら32x32といった大きなキャラクタも連続領域に再配置できるのでOk。
とりあえず、現在活動中の敵の数を画面に表示させながらプレイ。
おおむね30体、運が悪くても60体表示されると画面が結構埋まる。
| 320 x 240 | 32体 | 64体 | 128体 |
|---|---|---|---|
| 76,800画素 | 8,192画素 | 16,384画素 | 32,768画素 |
| 100% | 10% | 20% | 40% |
現在の最大128体、という設定はちょっとオーバースペックかもしれない。その分スペック的には余裕が残せるかもしれない。
128体も出すと画面の4割が埋まるわけで。実際には重なるハズなので2割くらいが埋まるのか? 数値にすると少なく感じるなあ。
弾は最大1024発。コレだけ飛ばすと画面が埋まるのでいい感じ。
弾は8x8の大きさなので64画素。敷き詰めると8割を埋めつくすことになる。
…足りないか?
あー。
確かに、誰か先行者を描いてくれと書いたよ。私が書いたヤツだとヘッポコだし。
だから誰か描いてくれと日記に書いたさ。
だからといって大きくすることはないじゃないかッ!
16x16ドットでどうやって表現しよう、と考えたところでヒゲがナイスなマリオ様を思い出したので二頭身でいこうと思いつき、とりあえず描いて、バランスが悪いから頭を小さくして…って感じで出来上がったのがアレだよ。おかげさまでこいつだけオモチャっぽいというか他のキャラクタから浮きまくってるけど。
単に技量の差という話もある。
だからといって大きくすることはないじゃないかッ!
このままでは笑い殺されてしまう。勘弁して。
.gbaというのはゲームボーイアドバンスエミュレータのROM形式らしい。だれか特訓をGBAに移植したのか?(絶対違う)
隠しコマンドは一体…(だから無い)。
そういえばWonderSwanを買ったら特訓を移植しようと思っていたけど、そのままほったらかしだ。直前にColorが出るという話を聞いたのでColorにしようと思っていたら思いのほか高かったので値下がりするのを待っていたら全然値が下がらない。
おにょれNeoMagic。このビデオチップ、VESA 320x240x8の解像度をサポートしてやがらねえ。
Mode Xでならサポートしているようだけど、Mode Xだとサーフェスロックができないし。DirextXのリファレンスを読むと、ModeXなサーフェスにはロックどころかBitBltもできないらしい。どうやって描画しろって言うんだ。BltFast()? つかえねー。
640x480x8でサーフェス作ってBitBlt()で拡大するのが吉か? ハードウェアで拡大転送が使えればそれなりに速いだろうし。
しかし、ここ数年のチップならVESA 2.0くらいはサポートしているのだと思っていたけど油断できない。
Weekly Mag Magから。
小学生の時から、答えがわからなかったクイズがあります。
「山本譲二と所ジョージが喧嘩した、勝つのはどっち？」。
小学生向けのクイズなので多分二人の名前を洒落にして解くのだと思いますが未だに解けません。ティ―チャ―先生、答えを教えて下さい!
（ジョン）
すごく簡単なオチなんだろうけどさっぱりわからない。
問題にたどり着くまでに小学生の時から、答えがわからなかった
とあるのでこの時点でものすごく難しい問題だというような暗示にかかってしまうのかもしれない。
もしかすると時期的な問題かもしれない。当時、どちらかが「勝つ」と言いまくるCMに出演なさっていたとか。
TricksterのLibretto 50、速過ぎ。
ヤツのLibretto 50はクロックをあげてあって90MHz程度で動作しているらしい。
FIVAで動かすと60fpsくらいの速度で動くプログラムで平気で50fpsくらい出てる。クロック倍違うんですが。FIVAが描画に20msくらいかかるところが、気になるアイツのLibrettoは23ms程度で処理をしているようだ。
私のFIVAは200MHz。やるな東芝。独自チップセットの勝利か?
負荷は表示の部分にかかっているので、Chips &Tech.のビデオチップが高速なのかもしれない。
ってtkkn.gbaだと思っていたらtkkn.gcaだった。ホッ(なにが)。
特訓99がアップローダ系の掲示板に載っているのを発見。しかもなぜかtkkn.gbaというファイル名。さっそくダウンロードしてダンプしてみた限りではtkkn.exeとかtkkn.hlpなんかが入っているので私のアレっぽい。
しかしまあ、そんなにヤバそうなものにみえますか。
ところで.gbaってどういう形式?
角度計算ルーチン作成。
まあなんとか動いているようだ。ちょっと誤差があるハズだけど、見た感じでは判らない。というか、単に四捨五入するのを忘れただけだったり。
Tricksterから新キャラ用のグラフィックがどかどか届く。こりゃ助かる。という困る。こっちの作業の方が追いついてない。
なんとか2キャラ追加するものの、まだキャラクタがあまってる。
ネタはあるものの、それをコードに落とすのが大変。
楕円起動を描かせるにはどうしたらいいのだ。まっとうな楕円の方程式とか使うと計算量が多くなるので避けたいところ。厳密な楕円でなくてソレっぽく見えるだけでもいいのだけど。
すげー。ノーヒットノーランなんてなかなかできるもんじゃないし。
テレビで見てても、フォークはスゴイ落ち方をしている。バッターボックスとかキャッチャーから見たら見失うんじゃないだろうか。
弾の加減速ルーチン作成。結構気持ちよく動く。初期値にどういう値を入れるとどういう動きになるか実験しながら調整。
ファミコン版のスターフォースってハドソンが作っていたのか。テクモ(当時テーカン)だとばかり思っていた。
道理でスターソルジャーとスターフォースがよく似ているハズだ。
ゲームボーイアドバンスかワンダースワンあたりでスターフォースとスターソルジャーのデラックスパックでも出ないかな。
特訓DXは弾を4x4から8x8に大きくする。弾は微妙にアニメーションさせているのだけどあまり効果が見られないのでやめようか思案中。
サーフェスの描画はビデオメモリではなくてシステムメモリで行うと速いという説があるのを読んで実験。
というか、FIVAのビデオメモリってシステムメモリ(SDRAM)との共有なのであまり効果が無いような気もするが、もしはっきりとした効果が無いなら誰かに頼んで計測してもらうことにする。
結果、システムメモリの方が2割遅い。一応、FIVAでもビデオメモリの方が速いらしい。
まあ、こっちはサーフェスメモリからの読み込みが無いのでその分楽なのだろう。
ClaftLauncher、快適。
MoonLightもなかなかいいんだけど、カレントディレクトリを指定できない、というのが致命的。一部のプログラムはカレントディレクトリにあるファイルを使用する作りになっているのでカレントディレクトリを指定できないとうまく動かない。KTXのマクロなんかがそんな感じ。
DFも起動時にはカレントディレクトリの一覧を表示するので、できればカレントディレクトリを指定したい。
起動するファイルにショートカット(*.LNK)を指定することで解決しようとしたものの(ショートカットなら作業フォルダという形でカレントディレクトリを指定できる)、しっかりとショートカットのリンク先を解決してしまうのでアウト。
いやあ、惜しい。
これ以外は入力時のレスポンス、フィードバックともに好みで使ってておもしろかったのでかなり気に入ったのだけど。。
もう一つの、キーワードランチャー。
C++ Builderの強力なGUIデザイン機能が災いしているのか、Windows標準の色使いからかけ離れた画面デザインがアウト。
私の場合、ウインドウがかなり黒っぽくて文字を白くしている。このためちゃんとシステムカラーを取得して描画する作りにしないと文字が読めない。
一部のダイアログで、システムかラーではなくて黒で描画しているものがあったため文字がまったく読めなくて残念な思いをした。
あと、強調のために暗い青で文字を書いているところもあったのだけど、これも読めない。文字の色を指定するなら背景の色も指定してくれ〜、とHTMLのBODYと同じ不満を感じた。
背景消去に思ったより時間がかかっていたので調査。
プロファイラによると
| 57705300 | 2122回呼び出し | Draw |
| 326659597 | 2122回呼び出し | Erase |
と、ただの矩形転送を行っているDraw()と矩形を塗りつぶしているErase()で5倍以上の差が出ている。転送する方が時間がかかりそうなものだけど。
ためしにLockしたついでにmemset()でクリアしてみる。
| 73479742 | 2217回呼び出し | Draw |
| 355687072 | 2217回呼び出し | Erase |
若干遅くなったくらいで目立った変化は見られない。
| 75375444 | 2872回呼び出し | Draw |
| 435354252 | 2872回呼び出し | Erase |
ダブルバッファじゃなくてシングルバッファで描画と消去を行うとわずかに速くなった。でも誤差といえば誤差かも。
| 62857068 | 2652回呼び出し | Draw |
| 394422570 | 2652回呼び出し | Erase |
バッファリングの効果を確認するため、4面バッファ。
ココまでやって若干効果が。ロックしようとしたところでサーフェスが使用中だったりして待たされる、と言うことを回避するためにはもう2面くらい足さないとダメかも。っていうかFIVAのビデオ処理が遅過ぎる。
もしかして、最近のちょー高速なビデオカードだと充分に速いんだろうか。
ミレニアムくらいでいいので誰か2D描画が速いヤツをくれー。Pentium 100MHzにTrio64じゃ時代に取り残されっぱなしだ。
そんなことよりも、敵の描画が遅いのが頂けない。なんでこんなに遅いのだ、というくらい遅い。
| 57705300 | 2122回呼び出し | Draw |
| 326659597 | 2122回呼び出し | Erase |
| 2428604975 | 242201回呼び出し | E_draw |
画面消去と比べると、正に桁が違う。呼び出される回数にいたっては二桁違うのでココをチューンするのは効果がありそうだ。
しかし、チューンする場所が無い。高々85行のコードで、そのうち18行は中華キャノンの処理だからほとんど実行されない。実質67行のコードの処理速度を10倍にできるだろうか。
ランチャーとして以下の3つをセレクト。
とりあえずしばらくはこの3つを使って比較するつもり。
静止して弾を掃射する、という動作をコーディング。
80発ばらまいてみるとすき間が無くなってつまらないので間引いて20発にする。これでもまだ狭いか。
で、弾が1024発以上出るこの状況では、キャラクタの描画をBitBltで一つ一つ転送するやり方はどんどん遅くなる。Lockして自前で描画、というほうが速い。うぬう、しくじった。
DOSみたいにフレームバッファを直にいじくれると楽なんだろうけど、そのためだけにDOSエクステンダ突っ込むってのもなあ。
とりあえずLockして描画するように修正。やたら時間がかかる。
何かが公開されていたのを記念してwith SSTPバージョンをコンパイルする。あれ、SSTPで使うポートって変更されていなかったっけ? 公開されている文書を見るとまだ11000のままのようだけど。とりあえずDF.INIの[SSTP]のPORTでポート番号を指定できるようにする。
日本文芸家協会と日本図書教材協会との間で著作権に関する協定が結ばれたとのこと。要は教材に著作物を使用する際には使用料を支払う、というもの。
文化庁長官の支払と二重取りになったりしないのだろうか。
参考のためスターフォースをプレイ。
あ、弾ってこんなに速くてもいいんだ。敵もこんなに少なくていいんだ。
ものすごく気が楽になった気がする。
先日、Kok.wishさんに当たり判定には座標を区切ってマッピングするという手がありますよという感じのアドバイスを受けた。区切ってしまうとピクセル単位の判定ができなくなると思ったのだけど、これだけで当たり判定を行おうとするからダメなのだと。
処理の手順を増やすと時間がかかる、ということから一手で当たり判定を行うことしか考えていなかったのでちょっち目からウロコ。
カップヌードルを食べる。
風邪薬飲む。いつもなら3錠でも5錠でも流し込めたのだがどうにもうまくいかず1錠ずつ飲み込む。
ZDNetのファイル管理ツール関係ソフトウェアレビューにrOMANCE fILER21が。
負けた。
DIVEで回る。TRICK。
もう少し研究すれば回りまくれるような気がする。のでDDRVのデータが落ちていないか検索。
DDR系のサイトのほとんどが消滅していたり別物になっていたりしてビビる。中でも笑えたのがMETAのrefreshで飛ばした先が404だったりするところ。ドコに飛ばしてんだっていう感じ。