正直日記



2007/07/23

_ ALT+クリックでウインドウ移動とかしたい
Xでやってるのか更にその上位でやってるのか知らないけど(WMによらず出来るっぽい
からXなのかな)、ALT+右クリックでウインドウのサイズを変更できるのは便利だと思
うのでWindowsでも採用するべき。
_ 敵の無敵地帯を作る
画面上方8ドットの地帯を敵の無敵ゾーンにしよう(雷電II)と考えたが、いちいち敵
の無敵状態を調べるのが面倒くさい(敵自身が今ゾーンに入っているか調べるのと、弾
から見て敵が無敵かどうか調べる)と思ったが、逆に考えてみたらそのゾーンに入った
弾の当たり判定を消してやれば同じ結果が得られると思ったが、当たり判定を消さずに
弾の持つダメージ量だけ無くしてやれば打ち込み点だけ入ってウハウハだと思った。

次に、背景の下に隠れた地上オブジェクトを無敵にしたいときのことを考えてみたが、
これも同様に、隠れられる背景の上を通過している弾の属性をほにゃほにゃすることで
………ごめん、やっぱ今の無し。

sato_tiff > pitoってのでそれできますよ。もう5年ぐらい使ってます。  (2007/07/24 02:11:49)
>
マジェっすか?……マジェだ!便利!
どうもありがとうございますありがとうございます。
 (2007/07/24 03:52:51)

2007/07/22

_ 当たり判定の鬼
マッドボールに体当たりして思ったのだけど、あれは当たり判定のある部位が

 本体
 ├主砲台
 ├小砲台 x 8
 └本体と大砲台を結ぶ橋 2 x 8
  └大砲台 x 8
   └大砲台同士を結ぶ橋 2 x 8

の合計50パーツに分かれており、豪快にぶん回しつつ、ショットとの当たり判定まで取っ
て1INT以内に処理を終えてるのは割と熱いんじゃないかなあと思った。弾を撃ってくる
瞬間とか、体当たりして破片が飛んでる間とかは、さすがに処理落ちしてるけど……。


(しょーもない動画)

んで、ちょこっとだけ再現してみたところ、ARMは意外と強かった。空間分割しないと
きついだろうと思っていたら総当たりでもなんとかなっちゃった。いや、なんとかなっ
てないような気もするけど……。

2007/07/21

_ 地上物と背景のスクロール同期が合わない
速度を一緒にしているはずなのに、何故かタイミングがずれてガタガタしてしまう……
そんな悩みをお持ちの、そこの貴方!(誰だよ)

端数も揃えんとずれるよ。

というか端数そろえて解消するようなズレだったらあまり気にならないような気もする
けど……。気になるほどズレてる物は根本的に何かがおかしいように思う。描画タイミ
ングとか。

2007/07/19

_ Zバッファがどうの
チラつきは非常に見づらいということでサイズ可変スプライトをあきらめ、16x16固定
の代わりにバンバン出せるGBXSPを使う方向に転換し、前に作ったスプライトコンバー
タを改造して複合スプライトコンバータを作っているのだが、スプライト郡の下に完全
に隠れるスプライトを取り除く処理が面倒臭い。

そういえば、複合じゃないほうのスプライトコンバータはGBAソフトにアップしてあり
ます。誰も使わないとは思うけど、まあ一応。

2007/07/14

_ boostが全然加速できない
なんかもう面倒くさいのでパーサ書くときはboost::spiritを使っているのだがコンパ
イル重すぎメモリ使いすぎ。ちょろっと書いたYAMLパーサをコンパイルしたらcc1.exe
が150MBとか消費しててどうしようかと思った。一度コンパイルして.obj作っちゃえば
後はそうでも無いでしょ?とか思ったらいかんよ。ちょこっと修正するたびにいちいち
動作確認をしながら作りこんでいく人のことを忘れてはならんのだ(BASIC上がりの奴
はこれだから……)。
_ 気づき
co_resume(void) じゃなくて co_resume(int wait) にすれば、無駄なコンテキストス
イッチが減って具合が良かった。
_ 狭い我が家へようこそ
やっぱり160x160は狭いという結論に達しつつある。


(動画)

あとコルーチン重い気がする。動画の赤いバーが敵動作、ピンクがヒット判定(自機と
空中敵・敵弾)で、黄色がヒット判定(ショットと敵)それぞれの負荷なんですが、黄
色が長くなるのはいいとして赤いバー長すぎ。まあ敵はせいぜい十数体に控えればいい
話ではありますが。

どうでも良い話なんですが、俺は雷電のヘリが画面上方に帰る際たまに逆向きに回って
戻っていく奴がいて凄く萌えてるのですが動画ではそれを再現してあります(チラチラ
して分かりづらいとは思いますが)。要するにあれは「表示上の回転軸を移動方向の回
転軸に近づけるタイミング」をずらすことによって発生していたのだった。
_ マシン交換
ついにPCIスロットが全沈黙したのでPCを換えた。Xvidが2倍の速さでエンコード出来る
ようになって、SM3.0が使えるようになった。速いなー。

tekezo >
スゲェェェエ! 円熟の境ですねぇ。
しかし、やはりコルーチンは重いですか……。
 (2007/07/15 21:49:46)
> 敵を出しすぎたり、弾を曲げるために使おうと思ったりしなければ結構いけるんじゃないか、といったところですね。個人的にはソースに直接挙動を書けるのが嬉しいです。  (2007/07/15 23:26:56)

2007/07/11

_ マシンが壊れ気味でなぞ
なんかネットに繋がらないなーと思ったらハブが超高速に点滅していて、かと思ったら
突然マシンがリブートし、イーサネットカードのドライバ再インストールを要求された。

とりあえず再インストールしてみると「ドライバが無い」と言われ、今まで普通に使っ
てたのにそれはおかしいだろうと思うのだが、おそらく、PnPでイーサネットカードと
いうことまでは認識できたがメーカと型番が分からん、という状態っぽい。

別件でサウンドカードを挿したときもサウンドカードということは認識できても、それ
がクリエイティブのSB32ということまでは認識できずにドライバがインストール出来な
かった経緯があったりして、どうやら今使ってるパソコンピューターのPCIスロットが
不調なようだ。

最近トラブル続きだなー。飼い主に似るのかしら。
_ 左上のなぞ
誤ってATAN2に固定小数点数をそのまま突っ込んでしまい、計算精度の都合で左上に向
かって弾が撃てない事態が発生した。つまり左上が丸々、安全地帯と化してしまった。

それで唐突に『左上』で有名な某シューティングを思いだし、あれは何故あんなことに
なってしまったのかを考えてみたかった。

左上を原点とすると、距離を得る関数への引数が x, y 両方とも負になるというところ
がポイントなんだろうなー。

あーでも二乗するから負でも構わない気がする。

なんだろう。
_ 解像度のなぞ
へこんでてもしょうがないので、モチベーションは下がったけどまた解析をやり直し始
めたよ。

ところでX68000版の超連射68kは 384x256 だけど、Windows版超連射86系は 320x240 な
わけで、縦方向に足りない16ドットはどこへ消えたのかというと、最終的な出力段階で
16ライン毎に1ライン間引く方向で解決しているようだ。なんか画面がもにゃもにゃする
のはそのせい。でも画面が収まってるおかげで、ゲームする分にはそんなに違和感ない
よなー。

そこで、GBAの縦解像度にあわせて 160x160 にしてしまうのはどうかと思った。キャラ
クターの解像度を下げる──16x32の自機だったら10x20にする──か解像度を保持した
まま当たり判定だけ小さくするか、思案のしどころではある。多関節キャラを考えると
解像度そのままってのは無理か。内部は256x256でドライブして、画面出力だけ160x160
に縮小出来ればいいんだけどなー。(速度的に無理がある)



この間コルーチンを云々したときに試作したゲームを改造して、160x160にしてみた。
つーても、COLYで画面全体を暗くしてウインドウでその範囲を限定しただけですけど。
狭いは狭いけどやり方次第では割といけそうな感じがするね。

2007/07/06

_ きえたぷりんせす
トロイにファイルを消されておよそ一週間が経ったが、ファイナルデータ先生の懸命な
仕事と俺の仕分け作業によって、ようやく大体復活できた。

ような気がしていたのだが、ファイルの中を見てみたら……あー壊れてる。cronで動か
していたDB更新スクリプトが消えた領域を上書きしたらしい。svnリポジトリの中身も
大方変になってる。超連射の解析リストが消えたのはかなり痛いわ。へこみ中。

解析経過を書くのはプログラムを丸裸にするようなものなので避けてたんだけど、今か
ら思えば、ここに書いておけば良かったな。
_ パレットが足りない(4)
COLYで白っぽく、COLEVでBG透過して赤っぽくすることで、スプライト側のパレットを
一切変更することなくヒットダメージ表現が出来た。わーい。
_ 俺は社交辞令を真に受ける屑人間
(T/O)

> 「ゲーセンで待ち合わせしましょう」は社交辞令に入りますか  (2007/07/06 11:23:10)
> ジョイランドの絆前で待ってる。  (2007/07/06 18:17:31)

2007/07/03

_ パレットが足りない(3)
下の設定だとOBJの透過指定時に他のOBJが消えてしまうので

 REG_WINOUT = (WIN_OBJ_ON) | ((WIN_BG1_ON | WIN_OBJ_ON) << WIN_SHIFT);

のように設定したら

 (円の下に弾が隠れて欲しい)

スプライト同士のプライオリティが崩れたっつーか。まー透過指定してるんだから透け
るわなーと。しょーがないからアルファブレンドでやるか。確か出来たはず。
_ パレットが足りない(2)
パレットが足りないの続き。

スプライトを真っ白にしたいけどパレットが余ってないっつーか、整理すれば余ってる
けど色々あって整理がめんどいってゆーとき、そのスプライトをウインドウ属性にして、
真っ白なタイルを敷き詰めた BG1 辺りを透過させればいーんじゃないかと思ったのだ。

 REG_WINOUT = (WIN_OBJ_ON) | ((WIN_BG1_ON) << WIN_SHIFT);

最初、スプライト同士のウインドウ透過も出来ることを知らなくてバビった。半透明は
出来ないのに透過は出来るんかい。REG_WINOUTの範囲外側にOBJ を指定しておかないと、
REG_DISPCNT を設定したときに、OBJでWIN属性を指定していないスプライトまで表示さ
れなくなるのだった(透過してないので)。

……スプライト同士の透過で何かエフェクトが作れないかと一瞬考え込んでしまったよ。
あまり使いどころが無い気がする。

まーとにかく、真っ白と真っ赤の状態を作りたいときに、16色パレットを二本も潰さな
くて済むというのはちょっとおいしい気がしたよ。未使用BGがあるとき限定だけど。

2007/07/01

_ コルーチンみたいな(5)
コルーチンで回すタスクを書いたobjをobjdumpしたらdstレジスタをgrepしたらr0-r3を
除外したら保存すべきレジスタを節約出来る気がしたらやってみたら大抵はr4-r7しか
使ってなかったという。THUMBだからそうなのか。

と思いきや、バンバン使ってるのもあった。

00000068 <shitukoi_helico>:
  68:   b5f0            push    {r4, r5, r6, r7, lr}
  6a:   4647            mov     r7, r8
  6c:   b480            push    {r7}
あーそっか二度に分けてpushするんだ。なるへそ。なんか初めて真面目にarm-elf-gcc の吐くTHUMBコードを読んでる気がする。まあ自分で書く機会は無いんだろうけどなあ。 どうでもいいけどデバッグ用にsprintfを埋め込んだらスタック消費しすぎてて鼻血が 出たよ。
_ そうか、もう月末なんだな(・ω・)
ゲツマツーъ( ゚ω^)

> 今年が半分終わったとかそんなことは信じない。  (2007/07/01 05:51:43)
> 年度で考えるんだ。これから楽しいプール開きだヨ。  (2007/07/01 06:36:24)
1125 > 俺が誰か分かる  (2007/07/03 19:33:32)
> どなたですか。  (2007/07/03 20:15:28)

最新
2010 | 01 04
2009 | 01 02 03 04 05 06 07 09 10 11 12
2008 | 01 02 03 04 05 06 07 08 09 10 11 12
2007 | 02 03 04 05 06 07 08 10 11 12
2006 | 01 02 03 04 05 06 07 08 09 10 11 12
2005 | 01 02 03 04 05 06 07 08 09 10 11 12