2003/12

2003/12/24

　あまり進展が無いまま帰省する日が目前に。
というかゲームばっかりやってたし。
実家では効率化のアルゴリズムを考えながら過ごそう…。


　実家は宮崎県の延岡市というところにある。
目前に海、背後には山々が連なる地形にある、寂れた工業都市…というより田舎町である。
ここから車で数十分奥地へ行ったところには母方の実家があり、
そこは今でも狸や猪や猿などの野生動物が出没する、必要以上に緑豊かな場所である。
　その母方の実家のある地域、5年程前までは
畑の野菜を猿に盗まれた、川で魚を獲っていたら猪が襲ってきて命からがら逃げてきた、など、
のどかな事件が後を絶たなかったんだけど、ここ数年は高速道路の敷設などで一気に山が削られ、
野生動物も数が少なくなっているらしい。嘆かわしいことだ。

　幼い頃はしょっちゅう母方の実家を訪れていた。
小学生になって首都圏に引っ越した後も大きな連休になると大抵泊りがけで母方の実家に帰っていたので、
宮崎で暮らした日々の記憶はほとんどこの母方の実家で過ごした日の記憶だ。
　田んぼでイモリやオタマジャクシを捕まえたり、蛍の群れの光に時間を忘れて魅入ったり、
朝早起きして森にカブトムシを捕まえに行ったり（カブトムシやクワガタは早朝地上に出てくる）、
夜遅くに川に海老を獲りに行ったり（川海老は夜になると動きが比較的緩慢になる）、
台風で家の周辺まで水が来たら日がな一日水位の変化を観察したり、
山に筍掘りに行ったり、川で投げ網で鮎を獲ったり、海にゴムボートでキス釣りに行ったり、
典型的な田舎生活を満喫していた。
今思うと貴重な体験だったような気がする。

　そんな俺が今は引き篭もりへたれプログラマになってるし、
当時の友人が今は金髪で暴走族やってたりするし（大人しいやつだったのに…）、
世の中変わるもんだとしみじみ。

2003/12/16

　前回の辺-面総当りな方法でポリゴン同士の衝突検出を実装してみた。
結果は予想を大幅に上回るノロさに。
効率を考えてないとはいえ、50ポリゴン程度のオブジェクトと12ポリゴンのキューブ40個程で60FPSを割ってしまうんじゃ、
グループ化で効率上げても焼け石に水のような気もする。
根本的なところから変えないといかん予感。
速度優先で行くならグループ化してグループからAABBを作成して、AABB同士で判定した方がまだマシか？
あと衝突後に自然なリアクションをさせるのがまた難しい。
まだまだ前途多難…。

　グラディウスV発売延期？来年4月以降？
勘弁してくれー…。

2003/12/13

　よく考えてみれば、ポリゴン同士の衝突検出も効率を考えないなら難しい話ではない。
衝突側のポリゴンの辺全てと、被衝突側のポリゴンの面全てを交差判定すれば交差を検出できる。
ただしこれだけだと一方のオブジェクトが完全にもう一方のオブジェクトの内側にある場合に判定が漏れるので、
これも考慮する場合、辺の交差に加えて衝突側のポリゴンの頂点全てと、被衝突側のポリゴンの面全てを内外判定する。

　当然ながらこれだけじゃ死ぬほど無駄な計算コストがかかるので実用にはならないだろう。
事前に（モデルデータロード時）8分木なりで面をグループ化して検索効率を上げる必要がある。
それに加えて、描画用のモデルとは別に衝突用の簡略化したモデルを用意すれば実用レベルになってくれるだろう。多分。
　てわけで、なんとなく解決の糸口が見えてきたような気がしなくもない。
とりあえず明日効率を考えないばーじょんで組んでみよう。


　なんとなくオフラインゲームがやりたくなってヨドバシへ。
WildArms AlterCode:Fを買おうかと思ったけど、PS2持ってない上に当分借りられそうにもなくて断念。
正月明けあたりに本体ごと買おうかしら。
　PS版のWAは、ザックとレディーハーケン絡みの話がかなり好きで今でも強く記憶に残っている。
全てを忘れたレディーハーケン（本名忘れた）に、ザックが約束のリボンを渡すシーンはあまりにやるせない。
てかこのシーンをもう一度見たいが故にAlterCodeをやりたいのだったりする。

　今回は代わりにCloverHeart'sを買ってきた。
まだ始めたばかりだけど、久遠さんカコイイ。

2003/12/12

　レイヤー化でより柔軟な衝突を実現してみる。
レイヤー化はその名の通りオブジェクトを層を分けて分類しておくテクニック。
例えば、自機を1、敵を2、地形を4、弾を8のレイヤーに書き込むとする。
（これはデフォルトの挙動で、Luaなどの外部スクリプトから変更可能にしておく）
この場合自機は(2|4|8)のレイヤーを見に行けば敵、地形、弾と衝突してくれる。
一部の弾を例外的に地形と衝突させたい場合、その弾に(1|4)のレイヤーを見に行かせればいいし、
上の図のキューブの挙動を実現するには(1|2|4)のレイヤーを見に行かせればいい。

　現状検索自体は総当りでやってるんで大変効率が悪い。
レイヤーごとに8分木を構築して検索効率を上げるのが次の課題か。
　あとポリゴンオブジェクト同士の衝突も今後の課題。
ポリゴン-点の衝突ができればゲーム用途ではなんとかなりそうだけど、
学校の進級発表の研究テーマをポリゴンオブジェクト同士の衝突と決めているのだ。
学校の先生の「進級発表で成果を出せれば出席日数は大目に見る」的なお達しをアテにして
ろくに学校の授業出てなかったりするんで、意地でも仕上げにゃイカン。

　50000アクセス感謝。
いい機会なので（？）賞味期限切れ過ぎなトップ絵抹消。

2003/12/8

　現在位置を前後のポイントの位置で平均化したしなり。
曲がる時速度が落ちてしまうけど、これはこれで面白いかも。
んでも、まだ今ひとつ物足りない気がする。
大げさすぎるくらいグネグネしてくれるのが理想なんだが…。

　そういえば、グラディウスVのデモムービーのレーザーをコマ送りで観察してみると、
部分的に直線になってたり直角に近い角度になってたりする。
動いてる時はとても綺麗に見えるのに。
どういうアルゴリズムなんだろう。

2003/12/7

　Linuxで、というかgccでコンパイルできなかったの修正。
あとグネグネの尾をより美しく。他色々。
予想以上に綺麗な絵が出て浮かれてたせいか、あちこちでアホなミスをやらかしてるらしく…。

　グラスレでちらっと話題に上がってるのを見て失笑。励みになります。

2003/12/6

　グネグネレーザー(仮称)と、散々後回しにしていたLuaからのテクスチャアニメ制御を実装。
割と派手で面白げな雰囲気になってくれたような気がしなくも無い。
今の状態でもLuaから弄り倒せばゲームらしいものができそうではある。
残る課題はリソースの用意…、って、これがプログラム自体より大変かもしれないんだけど…。

　成果物。
3ボタンでグネグネレーザー(仮称)
4ボタンと十字キーで方向変化
2ボタンは試験的実装のワープ

2003/12/5

　調子に乗ってグラディウスVのグネグネレーザー(仮称)を真似てみる。
・ラインを構成するポイントに速度を持たせて個々のオブジェクトとして動かす。
・攻撃判定はポイントと同位置に持たせる。
・生きている攻撃判定をなぞるように描く。
考えてる手順はこんな感じ。

　とりあえずポイントに速度を持たせて動かし、描いてみる。
それだけじゃあまりに見た目がしょぼいので、ポイントの位置の履歴を20フレーム分(値は適当)取り、
現在位置と履歴の最後の位置からQuadStripを生成して残像っぽいエフェクトをつける。
その結果がこんな感じ。

いまいちグネグネ感が足りないのと、見た目があまり美しくない現状。

　ちなみにグラディウスVのデモムービーはこちら。
2chで発売は来年2月という噂が流れてるけど、真実であることを祈る…。

2003/12/4

　昨日の続き。

　ポリラインの幅をwidth(実数)、カメラ位置をcamera_pos(ベクトル)、
頂点配列をvertex[n](ベクトル。nは配列の大きさ)、現在の頂点のインデックスをi(整数)として、
まず頂点からカメラ方向への単位ベクトルと、線の接線の単位ベクトルを求める。

vector4 aim_camera=(camera_pos-vertex[i]).normalize();
vector4 tangent;
if(i==0)       tangent=vertex[1]-vertex[0];    // 始点の場合
else if(i==n-1)tangent=vertex[i]-vertex[i-1];  // 終点の場合
else           tangent=vertex[i+1]-vertex[i-1];
tangent.normalize();

この二つの単位ベクトルの外積がカメラに対して垂直、かつ接線に対して垂直な方向になるので、
それに幅を掛ければポリラインの左右の頂点が得られる。

vector4 vertical = vector4().cross(tangent, aim_camera);
vector4 distance_from_center = vertical*(width/2); // 左右2方向に向かうので/2しておく

vector4 right= vertex[i]+distance_from_center;
vector4 left = vertex[i]-distance_from_center;
// right/leftがほんとに右側/左側に来るかは状況次第だけど、便宜的に

　後はright,leftを使ってQuadStripとして描くだけ…、と行きたいけど、
このままだと急カーブの時とかカメラに対する角度が浅い時、ポリゴンが重なったり捩れたりして汚くなる。
より完璧にしたい場合、角度を考慮した頂点の配置にしないといけないけど…、めんどくさー…。
というか、幅がそれほどでもない場合なら意外と気にならないなぁ。

　GLで描画するアルゴリズムにしてみた。
あんま汎用性無いけど、ランダムアクセスイテレータが使えるコンテナなら一応適用できるはず。
（ベクトルの型に合わせて使うメンバ関数を変えないといかんけど。ベクトル/行列計算ライブラリ標準化されないんだろか）

　曲がるレーザー、電撃、尾を引くオブジェクトなどなど、使える場面は多そうだ。
こんな単純な手順でこんな面白い効果が出せるって素晴らしい。
単純つっても俺には思いつかなかったんだけど。

2003/12/3

　「 ゲームプログラミングのための3Dグラフィックス数学」という本を読んでいたら、
ポリラインを生成するための非常に分かりやすいテクニックが載っていた。
それを基にコード書いていったら、あら不思議、
散々悩みまくった挙句後回しにしたポリラインがほんの1時間程度で完成…。
イカスぜこの本。

　手始めに乱射してみる。

さながら常時渾身の力の解放、あるいは常時バーサーク状態。
…なんか上のトップ絵のレーザーより綺麗な気が。

　明日にはポリライン生成の解説でも。（これ書いてる現在4日だけど）

　＊追記：たまにレーザーが明後日の方向に飛んでいくのを修正（原因は0除算。迂闊）

2003/12/2

　昨日は11月31日じゃなかったのか…。

　かなり初歩の気がするけどはまってしまった出来事

struct Base
{
	Base() { shout(); }
	virtual ~Base() {}
	virtual void shout() { std::cout << "貴様らの存在を消してやる！" << std::endl; }
};

struct Deriv : public Base
{ void shout() { std::cout << "お父様ァァァ！！！" << std::endl; } };

int main()
{
	Deriv test;
}

　Baseのコンストラクタの中でshout()を呼んでいる。
そのshout()はvirtual関数であり、Derivでオーバーライドされている。
故に「お父様ァァァ！！！」と叫んでくれることを期待したんだけど、
Baseのコンストラクタの中ではDerivはまだ構築されていないので、shout()はオーバーライドされない。
（C++では基底クラスから順に構築されていく）
てわけでこの場合、「貴様らの（略」と叫ぶことになってしまう。

2003/11

2003/11/30

　久しぶりに怒首領蜂（Ⅱでも大往生でもない、ノーマル怒首領蜂）をやってみたら、これが楽しい。
サイヴァリアⅡや、エスプガルーダまでもが霞んで見えかねないくらい楽しい。
このゲームは俺がゲーセンに通うきっかけとなったゲームであり、
やり尽くしたってくらいプレイしまくったゲームなんだけど、今やっても全然色褪せない。
　思えば怒首領蜂以降、弾幕STGの中で「これは怒首領蜂より面白い！」と一時的にでも思えたゲームって、
ぐわんげくらいしか思い当たらない。
どうも俺の中では「避け」が主体の弾幕STGは怒首領蜂で完結してしまってるような気がしてきた。

　怒首領蜂の楽しさとは何かといえば、避ける楽しさであり、敵を破壊し、なぎ倒していく楽しさだ。
これはほとんどの弾幕STGに共通するはず。
　しかしぐわんげの場合事情が異なる。
敵を破壊する楽しさは共通として、（俺はこれが無いSTGをSTGとは認めない）
その独特の式神システムのために「避ける楽しさ」は少し希薄なものとなり、
代わりに、押し寄せてくる弾を式神で止めて一気に消し去る楽しさとか、
ボス戦でどう動いても避けられないような弾が来た場合に、式神で部分的に弾を止めて切り抜けていく楽しさとか、
式神システムならではの楽しさがある。
　そして、敵の配置や攻撃パターンなどはこのシステムに合わせて調整されている。
そのため、ユーザーは式神システムに慣れることが強要されるが、
慣れてしまえば式神システムならではの楽しさが存分に味わえ、ゲーム自体が楽しく思えてくる。

　こういう「慣れれば楽しい」STGの例は、ぐわんげの他に斑鳩が挙げられる。
「極小当たり判定の自機」「やたら多い敵弾」をシステムとして見るなら、怒首領蜂も該当するかもしれない。
（実際、弾幕STGの存在を知らなかった当時の俺には斬新なゲームに見えた）

　新しいシステムでゲームを作る場合、システムそれ自体が画期的かどうかは重要ではなく、
ゲーム全体をそのシステムに合わせて徹底的に調整することが何よりも重要なのだろう。
そうすることでそのシステムならではの楽しさを生み出せるようになり、それはそのゲーム独自の楽しさとなるはず。

　逆に既に同じシステムのゲームがある場合、他のゲームと差をつけられる部分はより限られるので、
どこか似通ったものになってしまうのは避けられない。
差をつけられる部分はグラフィック、サウンド、敵の配置や攻撃パターンくらいだ。
いや、グラフィックとサウンドはゲームを盛り上げるための効果に過ぎないので、
実質ゲームの内容自体は敵キャラの挙動でしか差をつけられないかもしれない。
こんな制限の中でそのゲーム独自の楽しさを生み出すのは相当難しいんじゃないかと思う。
　数ある弾幕STGの中でも多様な攻撃パターンを用意し、
避けさせることに特化した東方紅魔郷/妖夢は、この系統の数少ない成功例のように思う。

　別に他のゲームと競争するわけでも勝負するわけでもないんだけど、
作ってる俺自身がプレイしてて明らかに他のゲームよりつまらんと感じるようなゲームは作りたくない。
そして弾幕STGでは怒首領蜂みたいな名作が既にあるし、俺自身弾幕だけのSTGは少々食傷気味。
そんなわけで、自分でSTG作る場合は独自システムを積んだ「慣れれば楽しい」系で行きたいなぁと、
往年の名作をプレイすることで再確認した今日この頃。
希望だけで終わらないようにしないと。

2003/11/28

　もえたん届いたー！
単なるネタ本と思ってたんだけど、割とまともな内容なのが意外。例文と挿絵はヲタクテイストたっぷりだけど。
英単語覚える目的でもそれなりに使えるかもしれない。
…でも実際にこれを教材にしてる受験生いるんだろーか。

★あなたが感じている感情は精神的疾患の一種です、治す方法は私が知っています。
☆The emotion that you feel is a kind of mental desease. I know the cure.
爆笑。
そういえばこの名(?)文句を作った人、つい最近事故死したんだっけ…。


　D言語をスクリプトとして使うってアイデアが面白そうだ。
でも俺の場合まずdll関連のWinAPIから調べないと…。

2003/11/26

　以前と違って書くネタがなかなか見つからないのは、最近新しい発見が少ないからだろうか。
もっとアンテナを高くしないと…。それともっと手を動かさないと…。


　VCのRTTIは何故こんなに遅いんだろ？
実験台
VC: 0m1.369s
gcc: 0m0.519s
オプションはVCは-GR -Ox、gccは-O3。PenIII1G環境下。

自力で型にIDつけてRTTIもどきを実現してみる。
改造後
VC: 0m0.105s
gcc: 0m0.288s

VCではえらい差が出ている。
可能な限り自力で型にIDつけたほうがいいんだろーか…。

2003/11/25

　雨の中もえたんを求めて新宿中を彷徨いまくるが結局見つからず終い。
amazonで注文しよう…。

2003/11/24

　もえたんってこんな内容だったのかー！
明日買いに行こう。

2003/11/22

　未練がましくAoM/AoTネタ。

　アンチユニットの効果が具体的にどのくらいなのか今まで知らなかったんだけど、AoM Heavenに一覧が載っていた。
ギリシャ、エジプト、北欧、 アトランティス
見ていて意外に思う部分が多い。

・槍系ユニットの騎兵に対するボーナスって実はほとんど無い。
スピアマンでx1.1だし、ポプリタイに至ってはx1.0。まじっすか。「槍は馬に強い」のセオリーはAoMでは通用しないのか。
しかしカタペルテスはx3.0…。ポセイドン使いがアトランティス相手だと絶望的になる理由が今よーやく分かった。
現実でも槍よりメイスの方が騎兵に効果的なんだろーか。なんか納得いかないものが…。

・対歩兵用歩兵ユニットはヤバイ。
アックスマンでx4.0、ヒュパスピストでx4.5、フランカでx2.25。うへぇ。
ラーでスピアマンを主力に戦ってる時、こいつらに一瞬で壊滅させられる理由が今よーやく分かった…。
つうかこいつら何でこんなに極端なんだ。

・タルタロスの門の悪魔は意外に強い
人間ユニットにx2.0。つまり攻撃力30…。
恐らく人間兵士最強であるフルチューン済みコンタリウスの18でさえ脅威なのに30って。
キャンペーンの8.ケルベロスとかで歩兵がこいつらに虐殺される理由が（ry

・ファナティックは歩兵と騎兵にx2.0
どーりで表記の割に強いわけだ。いや仮に表記通りだったとしても強い方なんだけど。
弓に対するアンチはないけど、防御力は極端に低いわけでもないし、ファナティックは間違いなく最強の歩兵ユニット。
うーん、ますます神話まで行かないと使えないのが惜しい…。

　今までこんなことも知らずにやってきたのか。不覚だ。
今すぐ再インストールしたくなる衝動を必死に抑えつつ…。

2003/11/21

　今更ながらAoTの適当な雑感とか。

　アトランティスは町の人の作成が遅い上に移動速度もトロいのが嫌で実戦では使わず。
てか、アトランティスって町の人がこれだから内政荒らしに弱い＞荒らされる前に仕掛ける必要がある
で古典初期からトゥルマRやプロメシアンRって戦法に限られてくるんだろうか。
　歩兵ユニットのファナティックがカコイイ上に強いんで、
AoCでアステカでひたすら近衛兵作りまくって攻めるのが好きだった俺としては惹かれるものがあったんだけど、
神話まで行かないと作れないのでやはり断念。せめて英雄の時点で作れれば…。
しかしあの格好（上半身半裸、両手に長剣）でなんであんなに防御力あるのか謎だ。

　で、AoMではエジプトでラーだったけど、AoTになってもラー。
聖職者の内政加速が心強い。流行のイシスの英霊/日食の対策にもなるんでなおさら心強い。
しかしAoTになって何故こんなにイシス増えたのか。以前はセト全盛だったのに。
どちらにしても、AoTでもエジプトが大人気らしき。

　ティタンは何度か相手に出されて負けたけど、こっちが出して勝ったことはなし。
出すまでに時間はかかるけど、神話まで行ったら積極的に狙っていくべき要素のようだ…。
　…で、結局AoTでのレートは最初から最後まで1600～1650付近をうろうろ。弱ー…。

　それとAoTのオープニングムービー、
いくらなんでもありゃ手ェ抜きすぎじゃありませんか。
AoMのムービーをちょろっと編集しただけで、新しいカットは一つもなし。
AoCも確かAoKのOPにテロップを入れただけだったような気がするけど、それを上回る手の抜きっぷり。
5800円もするんだし、もちっと気合入れるべきじゃありませんか。

　そういえばAoMのOPムービーも突込みどころありまくりだ。
まずモデルは写実的なのにモーションがディズニーのアニメのようなデフォルメされた動きなのが違和感ありまくり。
それと色が白っぽい。コントラストが弱い。もっと調整するべきじゃなかんべか。
そして効果音がしょぼくて萎える。雰囲気台無し。というかゲーム中に使われてる効果音をそのまま使っている。
AoKの時もそうだったような気がするんだけど、何か信念でもあるのか。
　何故これでリテイクが出なかったのか疑問に思ってしまう。
まあそれでもプレイし始めの頃は起動するたびに見てたんだけど。


　似ない…。
しかも最終的には陰もテクスチャに描かないといけないのを忘れていて
ミラーリングした状態に合わせてUV展開してしまった。
廃棄処分にするか気合入れて修正するか悩むところ…。

2003/11/20

　AoTに時間を吸い取られまくっていい加減危機感を感じてきたのでアンインストール。
すっかり放置癖がついてしまった…。

2003/11/15

　エスプガルーダノーコンクリア達成。
しかも残ライフ1でバリアは使いきり、覚聖カウンタも無くなる寸前とゆーアツい状況下でのクリア。
ラスボス最終形態の網弾幕を潜る時の緊張感がたまらない。
次の目標はクリアの安定か。
しかしアーケードSTGでこんなに早くクリアできたのは初めてだ。
　ラスボス最終形態にガードバリアぶちかましてみたところ、ものすごい勢いで回復した。
その勢いといったら、最終形態は大体ゲージが3分の1になったあたりからだけど、
4分の1消費ガードバリアを全部当てたらそれだけで最終形態開始時まで回復しそうなくらい。
最終形態のときは死んでもガードバリア当てないようにしないと…。（幸い左右端に寄れば当たらない）

2003/11/14

　新宿のゲーセン（コマ劇場付近）にエスプガルーダが入っていたのでプレイ。
1プレイ目はタテハで5面中ボス（1ボス再来）まで、
2プレイ目でアゲハで5面ボス（多分ラスボス）の3ゲージ目まで行けた。
大往生やケツイとは比べ物にならんほど簡単な難度になってる模様。
　ロケテバージョンと比べても簡単になっている。
ロケテバージョンの覚聖はあまりにすぐ切れるから怖くて使いたくなかったけど、
覚聖カウンタの減りがいい具合に遅くなって積極的に使っていけるようになっている。
敵の攻撃も全体的に緩くなってるような気がする。
ただ、タテハは覚聖時ショット強化になって使いにくくなっている。
ロケテバージョンの難しさで引いた人（含俺）は一回製品版をやってみれば印象が変わるかと。
というか、ロケテバージョンは大往生やケツイの時より難しかったような気がするんだけど…。
　2ch情報によるとラスボスはガードバリア当てると回復したり、覚聖攻撃が効かなかったりするらしい？
3面後半には覚聖状態でしか破壊できない敵がいて、そいつが1upを持ってるらしい？
　クリアはそう遠くはなさそうなんで短期集中プレイでクリアを目指す所存。

　AoM拡張パック（以後AoT）発売で微妙にAoM再燃中。
だけど、対戦で最近流行ってるらしいクロノス古典ラッシュと当たりまくって負けまくり。
クロノス古典ラッシュというのは、主神クロノスで原始の段階で神殿を敵陣へ転送、
従神プロメテウスで早めに（4分くらい）古典入りして全力でプロメシアン生産＆
賢者をGP武勇で英雄化して戦闘要員に＆反撃兵士小屋転送してトゥルマ生産で古典初期でキメるとゆー戦法。
出遅れたらまず助からない。
これの迎撃対策を考えとかないと狩られまくるハメに…、なんだかなぁ。
　AoTの目玉であるティタン様はよほど均衡しているか、
戦闘そっちのけで進化しまくらない限り出番はなさそーな。

2003/10

2003/10/28

template<class T> class HogeClass<T> { ... };
template HogeClass<int>;

　これでHogeClass<int>を実体化できると初めて知った…。
この機能を使えばtemplate classも実装を全部ヘッダファイルに書かなくて済む。
今までこれを知らないせいでリコンパイルに無駄に時間を費やしたり、
ヘッダファイル間の依存関係が無駄に増えたり、散々不便な思いをしてたんで感動…。
　ちなみにVCでは実体化の部分（上で言うとこのtemplate HogeClass<int>）
は実装ファイルの方に書かないとエラーになる模様。

　あと、スゲー今更ながらcygwinのviにもちゃんと設定ファイル入ってることに気づいた。
cp /usr/share/vim/vim62/vimrc_example.vim ~/.vimrc　なり
ln -s /usr/share/vim/vim62/vimrc_example.vim ~/.vimrc　なりで適用。
これからはWindowsでもエディタはviでいいかもしれない…。
しかしviで書いてVCでコンパイルって結構ひねくれた使い方のような気がしなくもない。

2003/10/26

　SDLはマルチスレッドを扱うので、
VC7.1でSDLを使ったソースをコンパイルする場合、マルチスレッドDLLとリンクしないといけない。
そうなるとmsvcr71.dllと依存関係になる。
C++の場合はさらにmsvcp71.dllとも依存関係になる。
これらのdllはWindowsには標準では入ってないので、配布の際は一緒に配布しないといけなくなるわけだけど、
この二つだけで容量は1MBを超える。あまりにもアホらしい。
　つうわけで、VCの時だけ代わりにシングルスレッド+WinAPIで処理するラッパーを書き書き…。
入力、ウィンドウ作成、OpenGLの初期化くらいしか使わないのでそれほど手間でもない。
　てか、cygwinだとmsvcrt.dll(windowsに標準で入ってるdll)とリンクするように取り計らってくれるんだけど、
VC7.1でそうするようにはできないんだろーか。
マルチスレッドは今後避けて通れないものになりそうなんだけど…。

　そういえば、SDLのフルスクリーンモードは他のウィンドウのサイズを変えてしまう。
たまにある、フルスクリーンでゲームをやって終了してデスクトップに戻ってきた時、
他のウィンドウが小さくなって画面左上に集まってるあの現象だ。
正直あれは結構いらつくものがあるので改善しておきたい。
　ChangeDisplaySettingsの第二引数にCDS_FULLSCREENを渡せば
後でChangeDisplaySettings(NULL, 0)した時復元してくれる、みたいな記述を見たような気がするんだけど、
どうもそうなってないようだ。
少なくとも俺と、実験台になってくれた何人かの知り合いは復元されなかった。
　どうやらフルスクリーン化する前に全部のウィンドウの位置と大きさを調べ上げて、
フルスクリーンから戻ってきた時一つ一つ元通りにしていかないといけないらしい…。
…と書くと大変そうな気がするけど、調べた結果簡単にできることが分かった。
具体的にはこんなコードで実現できる。（実行ファイル）
面倒なので説明は省略するけど、WINDOWPLACEMENT,EnumWindowsあたりのキーワードで情報を得られるはず。

2003/10/24

　相次ぐマシントラブルで鬱になったり、
血尿が出て自分が不気味に思えたりする日々…だったけど、
だんだん調子が戻ってきて以前のペースを取り戻しつつある今現在。

　なんとなくC++でサーバーサイドで動くバイナリを作れないかと思い立ち、
このサイトを置かせてもらってるサーバーをあれこれ調べてみた。
　…わざわざC++でやる意味なんてほとんど無いし、
全部staticリンク(-static)すれば自分のマシンでもここのサーバーでも動くバイナリはできたけど、まあ何事も実験。
　ここのサーバーはtelnetもsshも公開されてないので、こんなスクリプトを書いてみる。
（安全のためcgiとしては公開しない）
フォームから受け取った文字列をコマンドとして実行して、
結果をhtmlとして出力する、要するにブラウザを端末代わりにするもの。
C++のソースをアップロードし、これを介してサーバー側でコンパイルすることができた。
というわけで、C++でcgiを作ることも可能となった。
頑張ればmqoをアップロードしたらレンダリング画像が返ってくるcgiなんかも可能なわけで…。
気が向いたら何か作ってみよう。

2003/10/6

　仕事の都合でものすごく久しぶりにモデリングとWeb3Dのオーサリング作業をやっている。
というか、今年に入って以来まともなモデリングは一度もやってなかったような気が。
　今でも、主に知り合いの繋がりでムービー製作の手伝いやWeb3Dのオーサリングの依頼を受けるんだけど、
今はプログラム方面に力を入れている…というかほとんどそれしかやってないので複雑な気分。
しかも依頼が来るようになったのはプログラム方面に力を入れだしてからなので尚更。
依頼が来るってことはそれなりにできると評価されてるってことだと思うんで、それ自体は嬉しいんだけど…。
　これを機会にゲーム製作用のモデルも作り溜めておくべきか。
G-わんげの方のためにも…（あのさあさん、ごめんなさい…）

　水月コンプリート。
開始時からなんとなく感じてたけど、設定がYU-NOと似通ってるところが多いように思うのは気のせいか。
　御社の洞窟で扉を見かけたら、円盤をはめないと連れが落とし穴に落ちて死ぬ、とか、
和泉家が強引に工事を始めても、付近の遺跡からの落雷の連発で作業にならない、とか、
全キャラ終わったらいきなり見知らぬ森で目がさめて異世界（マヨイガ）編が始まる…とか、
雪さんは高ノ天原族（≒山の民）で、常に超念石（≒涙石）を身に付けていないと死んでしまうとか、
現在の牧野父は次元を漂う思念体で、本物の牧野父は白骨死体状態で防空壕に埋められてるとか、
那波は牧野父にナイアーブ状態にされているためにたまに言動がおかしくなるとか、
主人公の父は昏睡状態に陥りながら別の並列世界で事象ツリーの観察に勤しんでいるとか、
そーゆー妄想ストーリーを考えずにはいられない。
残念ながらゲーム本編は多くの謎が未消化のまま終わってしまったが。
　YU-NO並の完成された世界とストーリーで酔わせてくれるゲームは無いもんだろうか…。

2003/9

2003/9/30

　どうも調子が出ないのでゲームで気晴らし。

　Ys6が面白い。
なんてったって戦闘がとても爽快。
ボス戦は巨大な3DボスやアツいBGM（デモムービーで流れてた曲）が相まってかなり燃える。
すぐ終わるとか、移動がダルいとか、タイトル画面でデフォルトでNewGameになってて間違えて押してしまうとか、
細かい不満も色々あるけど、俺的には買って満足な内容でした。
現在アイテムコンプとオーブボス撃破目指して2週目をプレイ中。

　それと今更ながらに水月をプレイ。
…誰か俺に雪さんをください。
むしろ俺はマヨイガへ旅立つべきですか。


　Ys6で一部前後関係がおかしくなってる描画部分があるのを見てふと思い出した。
半透明オブジェクトやアルファチャンネル付きテクスチャを張ったオブジェクトの描画について。
　デプステストを有効にしたまま透過オブジェクトを描画する場合、透過部分にも深度情報が書き込まれてしまう。
そうなると透過部分の後ろ側に他のオブジェクトを描画しても、
その部分は透過オブジェクトの深度情報に阻まれて表示されなくなってしまう。
（東方妖々夢の1面＆2面の背景の木が不自然なのが多分これと同様の理由）
　かと言ってデプステストを切ったら問答無用で最後に描画したものが最前面に来てしまう。
アルファテストで一定値以上/以下の透明度の部分を切り捨てることができる（深度情報も書き込まない）けど、
完全に透明な部分だけ切り捨てる場合、ちょっとでも不透明な部分は残ってしまうし、
不透明な部分まで切り捨てたらかなりみすぼらしい外見になってしまう。
　んじゃどうすりゃいいのかと言えば、
自前でZソートして奥のオブジェクトから描画していくくらいしか思いつかないんだけど、
果たしてこれは一般的な方法なんだろーかと…。

　いい機会なのでテキトーに実装してみた。
カメラの位置と、カメラが向いてる方向の単位ベクトルから成る平面と各オブジェクトの距離を比較＆ソートして、
奥のオブジェクトから順に描画してるだけ。所要時間約10分。
ビルボードに関してはこれだけでも十分だろう。
ポリゴンオブジェクトに関しては凝りだすと終わりそうに無いので当分これで十分だろう。…十分なのだろうか。

　あとlua用ベクトル＆行列、assert撒き散らして簡易エラーチェック。
それとマクロは全部取っ払ってtemplate inline関数に。
ホント手間がかからない改良ばっかり…。

2003/9/25

　空白の1週間。

　ユーザーデータ化ベクトル＆行列、いくつか改善を経てゲームに組み込んでみたところ、
弾700発あたりまで60FPSを維持。
なんとも中途半端な結果。
弾は700出せりゃ十分なんだけど、敵、背景、その他諸々のことも考えると不安が残る。
Lua関数の代わりにCの関数も渡せるようにする、とかの予備の手段も考えておいた方が良さそうだ。
やっぱ全てのオブジェクトをスクリプトで制御って無茶かなぁ…。

　とりあえずこれでなんかやってみようと、ケツイ5面中ボスの攻撃を真似てみた。
真似っつーか、うろ覚えなんで別の敵になってる気がするけど。

　記述があまりに煩雑なのと、デバッグしにくい（ポインタのキャストが主な原因）
せいで無駄に時間がかかるけど、これでもなんとかやりたいことはできそうだ。
これ以上他の方法を模索しだすと永遠に終わらない気もするし、もっと使いやすいように改善していかないと…。

2003/9/18

　std::vectorはメモリ再割り当てが発生するとポインタもイテレータも無効になるってことを忘れていた。
こんな初歩的なことを忘れてたなんて…。
というわけで、昨日の雑記のメモリ割り当ての仕組みはあのままじゃヤバい。ヤバすぎ。
んでもこれまで使ってた領域を無効にせずに領域を伸長する方法ってあったっけ…？
とりあえず、何かいい方法が思いつくまで最初に100KB分くらいどかっとreserveしとくことでその場しのぎ…。

2003/9/17

　Lua組み込み奮闘記2。

んで、ユーザーデータ化したベクトル＆行列。
ユーザーデータってのはCのポインタなわけで、ポインタってことはどっかにある有効なデータを指してないといけないわけで、
どこにどうやってデータを保存しておくかが問題になってくるわけだ。
必要に迫られるたびにnew/deleteするんじゃテーブル使うのと変わらんので、
確保した領域は徹底的に使い回すような効率のいい仕組みにしないといけない。

　というわけで、ベクトルも行列もまとめて一つのstd::vector<char>型のコンテナで一括管理してみる。
連続したメモリにデータが置かれていることが保証されている上に、
capacityを超えない限り再割り当ては発生しないstd::vectorはこの用途にうってつけ。

　コンストラクタが呼ばれたり各種計算が行われると結果をこのコンテナに突っ込み、
その領域へのポインタをLuaのスタックに積む。
例えばLuaからvector3のコンストラクタが呼ばれた場合こんな感じに処理する。
なんかもっといい記述がありそうな気もするけど…。

int s=math3d_stack.size();
math3d_stack.resize( s+sizeof(vector3) );
vector3 *p=reinterpret_cast<vector3*>( &math3d_stack[0]+s );
*p=vector3();
lua_pushlightuserdata( L, static_cast<void*>(p) );

　積みっぱなしじゃ無限にメモリを消費していくんで調整も。
Luaの関数を呼ぶ前に現在のコンテナの大きさを記憶しておき、Luaから戻ってきたら元の大きさに戻す。
こうすればコンテナの大きさを一定に保ちつつ、
Luaの関数の外側で定義されてる変数はlua_dofile()の時静的に確保されるはず。

　これらを踏まえた上でコード書き。
つってもほとんどがC++側の関数を呼び出すためのインターフェースを書くだけの単調作業なのでかなりめんどくさい。
可能な限りマクロとエディタの置換に任せながらガリガリと書いていく。

　書き終えたところで早速比較。
行列*ベクトルの計算を5,000,000回ループさせて所要時間を比較してみる。
より正確には、matrix44*vector4の計算を行うLuaの関数の呼び出しを5,000,000回繰り返してみる（PIII1G環境下）
テーブル化した場合：35.999s
ユーザデータ化した場合：6.708s
それなりに速くなってる。GJ、俺。
というかテーブル遅い…。
リアルタイム用途なら動的にテーブルを作成するのは一切止めた方がよさそうだ。
　ちなみに、直接C++で書いてやった場合の結果は0.965s。
やっぱ要素へのアクセスに常にキーのコピーと比較が行われる以上しょうがないんかなぁ…。
　関数呼び出しのオーバーヘッドのこと考えてなかったので、ついでに関数を呼ぶ回数を減らして比較してみる。
matrix44*vector4の計算を1,000回繰り返し行うLuaの関数の呼び出しを5,000回繰り返してみた。
テーブル化した場合：32.850s
ユーザデータ化した場合：4.204s
速くなった。
あとは実際にゲームに組み込んでどうなるか…。

　欠点はただでさえ危険なポインタのキャストがそこら中にあるんで、
一歩間違えただけで暴走してしまうことか。うーん…。
まだ怪しい部分もあるんで、もちっと念入りに調べてから公開する予定。

2003/9/16

　Lua組み込み奮闘記。

　最初に問題になったのが、オブジェクトごとに独立したLuaのグローバル変数領域を持たせたいんだけど、
オブジェクトを生成する度にlua_open()してライブラリと敵データを読むのは時間がかかりすぎる、ということ。

　lua_newthread()で分岐してからlua_newtable() lua_replace()で新たにグローバル環境テーブルを作る手がある。
これが上手くいくんならこれでやりたいんだけど、
100前後（ライブラリを読んだりすると減っていくようだ）分岐したところでseg. faultになってしまう。
これを解決するために存在するのであろうlua_closethread()は何故かマニュアル上にしか存在しない。
というかlua_closethread()があったとしても分岐してるうちに落ちる可能性があるんじゃ怖くて使えない。

　次に考えてみたのが、暇な時にせっせとスレッド作ってプールしておく方法。
まあまあ実用的な速度は出たけど、個別にスレッドを作るっつう大きな手間を省けないのはかなり痛い。
それにプールが尽きた時ガクンと速度が落ちてしまうのでやはり不安。

　んで今回採った方法が、オブジェクト側にstd::map<std::string, boost::any>型コンテナの変数保存領域をこさえる方法。
変数保存領域にアクセスするのにいちいちインターフェース関数を介さないといけないのが面倒だけど、
C++側からも簡単にアクセスできるし、敵用とか弾用とかステージ用とか、１系統に1スレッドあれば事足りる。
Luaもキーと値を関連付けて保存、というstd::mapと同じようなデータの管理をやっているので、
速度にもあまり変化はない…と思う。憶測だけど。


　スレッド回りが何とかなったところで、インターフェース関数をごねごねとこさえて、弾をばら撒く敵を配置してみる。
直進するだけの板ポリゴンの弾を500個くらいに出しただけで60FPSを割ってしまった。（PenIII1G+GeForce2GTS環境下）
何もしない弾だと1500個くらいまで60FPSを保つ。
早い話が遅すぎる。

　一番時間を食われてるのは計算部分じゃなくて、メモリ確保の処理のようだ。
Luaはテーブルコンストラクタを呼んだりテーブルに要素が追加されるとメモリ再割り当てを行うらしい。
ベクトルと行列はテーブルにして扱ってたんで、
馬鹿みたいな頻度でメモリ再割り当てが行われ、無駄に遅くなっていたわけだ。
　というわけで、テーブルを使わず、記述があまり煩雑にならず、
それなりに高速なベクトル＆行列計算を実現する方法を考えないといけない。

まずは戻り値を複数持たせられるのを生かして、結果を個別の数値で返すようにしてみた…んだけど、重大な問題が。

vector3={}
function vector3.new(x,y,z)
	return x,y,z
end
print( vector3.new(1,2,3), vector3.new(4,5,6) )

これを実行すると
1 4 5 6
と表示される。
なんか2つめ以降の戻り値は上書きされてしまうらしい。なんでやねん。
このせいでvector3.add( vector3.new(1,2,3), vector3.new(4,5,6) )みたいな使い方ができない。
一度戻り値を変数に保存してから呼び出せばいけることはいけるけど、記述があまりに面倒で現実的ではない。

　他に思いつく方法は…、かなり面倒なんで避けたかったんだけど、
ベクトルと行列はユーザーデータにして、インターフェースをホストプログラムから提供する方法。
もう形振り構ってる余裕は微塵も無いので次はこれを試してみるしか…。
つうわけで現在これを実現すべくコードを書いてるところ。


　こんな具合でここ10日程は試行錯誤して検証して悩んで悩んで書き直してを延々繰り返し。
その割にはあまり進展無いけど…。
　合間に妖々夢とアキ学をやってたり。どっちもなかなか楽しい。

2003/9/4

　そろそろまともなエフェクトを実装しよう、つうことで、
ビルボード（常にカメラを向いてる板ポリゴン）を実装しておこうと思い立った。
これ何気に結構面倒でずっと後回しにしてた要素だったりする…。

　某3Dグラフィックス数学にビルボードの頂点を求める式が載っているけど、
ここはもうちょっと汎用性のある方法として、
あるベクトルを与えたらそのベクトルの方向を向かせる行列を得る手段を考えてみる。

　与えられたベクトルをxz平面、yz平面、xy平面に分解してそれぞれの軸の角度を求めてEular回転…、
これでできれば楽なんだけど、これは2軸以上が絡み合うと相互に影響し合ってうまくいかない。
モデリングツールで3軸が絡み合う回転をx,y,z軸回転だけで制御するのが難しいのと同様だ。

　ここは少々強引な方法だけど、
普通にY軸回転させた後、与えられたベクトルをxz平面に投影し、90°Y軸回転させ、正規化、
それを軸にして、与えられたベクトルと基準となるベクトル（ここでは0.0, 1.0, 0.0）との角度分任意軸回転、
という手順でやってみた。（ちなみにマウスドラッグした時のカメラの回転も同様の方法でやっている）
…一応問題なく動いてるように見える。
とりあえずこれでやってみよう。

　んで、やはり結果は目に見える形じゃないとありがたみも薄いんでホーミングレーザーで実験。
キーボードのaでビルボードのon/off切り替え。
カメラのターゲット（原点）からカメラの現在位置を向く行列を適用してるんで
視界の端に行くほど不正確な結果になってしまうけど、速度重視ということでこれはそのまま。
そのうち爆発やら弾幕やらで毎フレーム数百のオブジェクトを処理することになるんで、無視できない計算量になる。
　上記の行列を計算してる部分は、src/istl/matrix.hの一番下のaimVectorの部分。
週末はこのビルボードを使ってエフェクトらしいエフェクトを描いてみようかと。



　地道に外堀を埋める作業をやってるわけだけど、
適当なところでXMLとLuaの制御を組み込んで歌鶫の後継に仕立てようと考えている。
そろそろCしか知らなかった頃（というかプログラムに関する理解自体浅すぎた頃）
の設計が色濃く残った遺物から脱却せねばと。

2003/8

2003/8/31

　今まで書き溜めたライブラリっぽいものの中から汎用性がありそうなものを取り出して、
namespaceで囲って、おかしなところは書き直して…。
というか今までnamespace全く使ってなかったのはかなり恥ずべきなような気がしなくもない。

　試しに作成したライブラリを使ってポリゴン単位の衝突判定をやってみたホーミングレーザー。
model.mqoを差し替えれば任意のモデルが使用可能。
　衝突判定ライブラリは今後もっと充実させていきたいところ。
目指せTruckDismount。



　そういえば、今更ながらARB_vertex_buffer_object拡張を使ってみた…んだけど、描画速度は全く変化無し。
GL_ARB_STATIC_DRAWを初めとして9種類のデータの持ち方があるんだけど、どれを使っても速度には何も変化がないような…。
どっか使い方間違ってるんだろうか？と思ってあれこれ調べてみると、やはり変化がないと嘆いてる方を何人か発見。
どういうこっちゃ…。

2003/8/24

　ps_2_0==HLSLと思い違いをしてたんだけど、
(HLSL:High Level Shading Language。nVIDIAのCgとよく似た記述方式のD3D用シェーディング言語。)
HLSLはあくまで言語であって、ps_2_0やps_1_xはHLSLのソースをコンパイルして出力する時の形式、ってな感じのようだ。
ps_1_xはアセンブラっぽい記述、って認識があり、そのせいでps_1_xは使いたくなかったんだけど、
HLSLからもps_1_xで出力できると分かってちょっと安心。
　んでグロー。色を普通に出力した後適当にぼかして何回か重ねて描画、って手順で表現しようと考えてるんだけど、
この目的にはVertexShaderの方が近いようだ。t-potでいいサンプルを発見…。
でも実用レベルの速度が出るかは怪しげ。というかだんだん面倒になってきた…。

　f1bフォントの2D用ライブラリが。多謝。
圧縮部分で0x7fとすべきところを0x79とやってる恥ずかしいミスその他諸々は早めに何とかしておこう…。

2003/8/20

　レーザー実装迷走中…。
なんとなくDirect3Dのピクセルシェーダ(ps_2_0)を使ってグローがかかったレーザーを描いてみようと思い立った。
パンツァードラグーンオルタのノーマル形態ドラゴンのレーザーみたいなのを描いてみたいわけだ。
まだps_2_0はおろかDirectXもあまり深くは知らないんだけど、
以前歌鶫のD3D版を作ったノウハウがあるし、今回は目標がこの上なく明確なので何とかなるだろう、多分。

　未だにDXSDK8しか入ってなかったのでまずはDXSDK9を拾ってくる。
SDKインストール後、DirectX9の初期化用classを適当に書く。（ほとんど他のソースからのコピペだけど）
そしてspinのチュートリアルを参考にメッシュの作成し、エフェクトファイルを読み込み、いざ描画。
…が、シェーダーを有効にして描画しても、無効にして描画したときと変化がない。
念入りにソースを追っても、経過をファイルに出力してもおかしなところは見つからず、
もしやと思ってデバイスをリファレンスラスタライザに変えてみたら表示された。
どうやらビデオカード（GeForce4）がps_2_0に対応してないらしい…。
ドライバを最新のにしてみたけど、それでもリファレンスラスタライザじゃないと動かない。

　ps_2_0ってGeForceFXクラス以上じゃないとサポートされてないのかー…、知らなかった…。
仮に動作する環境を整えたとしても、ここまで環境を選ぶんじゃ一般配布するゲームには当分ps_2_0は使えそうにない。
（まあスイッチでps_2_0の使用のon/offを切り替えられるようにしとけばいいんだけど）
　ps_1_xではどうなんだろう。
明日もやる気が続いていたらそちらを調べてみよう。
というかps_2_0がだめと分かった現在既にやる気は半減してるんだけど…。
　それにしてもps_2_0の書式ってCgの書式そのまんまやね。

2003/8/18

　誰かさんに呼び出しを食らい、行く予定の無かった夏コミ（3日目）に行ってきた。
会場着いた後、眠い、暑い、人多いの三拍子で動き回るのが面倒になり、
結局樹さんとこの本だけ買って適当にだべって帰りに友人と焼肉食って帰還。
そして妖々夢とDuoPrincessは買っとくべきだったと後悔している現在。アホだ…。

　久しぶりに会った友人に、
雑記に延々とプログラム関係のことばっかり書いてるから根詰めすぎてるんじゃないかと心配された。
実際は結構遊び呆けてるんだけど…。
とりあえずプログラム以外の話も交えつつ、もうちょいこまめに雑記を書くようにしようと思う。
それにしても、現在でも身内（というか過去にネットで出会って直にも会ったことがある方々）
にこのサイトを見ている人がいるらしいというのがちょっと驚き。
突然外部との連絡を断った上、プログラマーに急転向したもんだからもう誰も相手にしてないもんかと。

2003/8/14

　突発的＆発作的にOpenGLで日本語を表示する手段が欲しくなった。
日本語を表示できれば何かと都合がいいし、ゲーム作る上でいずれ必要に迫られるに違いない。
それに場合によってはprintfデバッグの代わりも勤まるかもしれない。
よし、やってみよう。

　OS依存の機能を使ったり、SDLなんかのほかのライブラリと組み合わせて日本語表示を実現する方法なら
たまに紹介されてるのを見るけど、環境非依存の方法はほとんど見かけない。
せっかくOpenGL使ってるんだから環境依存にはしたくない。
Unicodeフォントを使って環境非依存にしている例もあったけど、
これはVCでは問題なく動いたけどgccでは何故か L"日本語" ってやってもUnicode文字に変換されず（？）化けてしまった。
しょうがないので、外部ライブラリを使用せず、少なくともWindowsとLinux両方で使えて、
あまり容量を食わない文字表示ライブラリを作ってみることにする。
このくらいは一度自力でやっておきたいというのもある。

　外部ライブラリ無使用＆OS非依存って時点で採るべき方法はほぼ限定されている。
フォントを自前で用意しておく方法だ。
できればフォントデータを一枚の画像として持っておくとやりやすい。
SDL_kanji でbdfフォントを読めば簡単に画像化できそうだったんで、これでやってみる。
bdfフォントは東雲フォントというよさげなものがあったんでこれを使用。

　SDL_kanjiを通して一字ずつビットマップに変換＆連結し、一枚の巨大な画像ファイルに変換。
サイズ16の東雲フォントを32bitRLE圧縮tgaにしてみたところ、1.9MB超。
扱いやすくはあるんだけど、このサイズはちょっといただけない。
フォントなんて1bitで十分なんでとりあえず1bit画像化する。
加えて、同じ数値が並んでる部分が多数あるんで適当にRLE圧縮してみる。
…221KBまで縮んだ。
これならイケル。

　次にこの1bitフォントの読み込みと描画。
東雲フォントのエンコードはJISなので、入力した文字列も内部でJISに変換し、
さらに変換した文字を文字配列へのインデックスへと変換する。
（というかこの部分はSDL_kanjiそのまんま）
現在の行列を退避させ、座標系をウィンドウに合わせてglBitmapで描き、行列を復元する…。

　…できた。
まだ最小限の機能しかないけど、これだけでも結構使えるかもしれない。

2003/8/7

　最近学んだことを取り入れつつ、美しいホーミングレーザーを実装してみようと実験中。
段階を踏んで
1.ただのラインのレーザー（現在一応達成済み）、
2.軌道を元にポリゴンを配置＆テクスチャを張って見栄えを良く（斑鳩の力の解放なんかも多分これと同じタイプ）、
3.できれば頂点バッファを使って高速化を図る（この場合逆に遅くなるかも…）
てな具合にステップアップしていく予定。

　1.の実装も兼ねた暇つぶしゲーム。
ちなみにこれのレーザーの移動の式は
vel=vel*0.93+(target-pos).normalize()*1.2;
pos+=vel;
こう。
もちろん根拠は何も無い。

2003/7

2003/7/30

　早速boostを実戦投入中。
filesystemとかlexical_castとかformatとかshared_ptrとか、
ありそうでなかった、痒いところに手が届く地味にありがたい機能が嬉しい…。
　boostに関する情報はここと ここ が非常に役立つ。

　VCのコンパイラ(cl.exe)の標準準拠率も上がったことだし、clの方がgccより実行ファイルのサイズが小さくなるし、
大抵はコンパイルも早いんで、コンソールからもclを使ってみようとふと思い立った。
あんま意味無いような気もするけど。

　そんなわけで、以下cygwin+clに関するメモ。
　コンソールでclを使えるようにするためにはvcvars32.batを実行する。
これを実行することでclやlink(VCのリンカ)の実行に必要な環境変数を設定してくれるらしい。
というわけでまずcygwin起動バッチファイルの最初の方にvcvars32.batを呼び出すコマンドを書く。
call "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat"
とか。
これでbash上でclを呼べる。

･boost
　boost_1_30_0のパッケージそのままではコンパイルエラーになるのが多数あるんで、cvsから最新版を拾ってくる。
最新版ではほとんどが問題なくコンパイル通る。素晴らしい。
手順は公式にある通り

cvs -d:pserver:anonymous@cvs.boost.sourceforge.net:/cvsroot/boost login
(ここでpasswordを聞いてくるけど、何も入力せずにEnter)
cvs -d:pserver:anonymous@cvs.boost.sourceforge.net:/cvsroot/boost co boost

cvsが入っていない場合はcygwinのセットアッププログラムから入手してくる。
　clは何故かデフォルトでは例外処理が無効になってるんで、
そのままではコンパイルは通るけどリンクエラーになってしまう。
例外処理を有効にするためには-GXオプションをつける。
cl hoge.cc -GX
これはデフォルトで有効でもいいと思うんで、
bash起動時の設定(.bash_login)で環境変数を指定してデフォルトオプションにしておくといいかも。
export CL='-GX -nologo'
(-nologoはcl実行時に出てくるコピーライト表記を出さないようにするもの)

･SDL
　最近GLUTの代わりにSDLを使い始めてるんだけど、これがかなり手間取る。
まずSDLはマルチスレッドを扱うんで、マルチスレッドDLLとリンクしないといけないらしい。-MDオプションを使用。
(-MDだとmsvcr71.dll依存になってしまうんで-MTでやりたいんだけど、何故かこれだと競合でリンクエラー…)

　それとSDLはマルチプラットフォーム対応のため内部的にmainを別の名前に置き換えたりするらしいんで、
これだけだとリンカが「エントリポイントが見つかんねーよ」と文句垂れてくる。
これはリンカのオプションでサブシステムを指定すれば解決できるようだ。
(何故これで解決できるのかよくわかっとらんのだけど…)
-SUBSYSTEM:CONSOLE
起動時にコンソール画面を出ないようにしたい場合は
-SUBSYSTEM:WINDOWS
(当然ながらこのオプションをつける場合WinMainが無いとリンクエラーになる。
　SDLはSDLmain.libでWinMainを定義してるらしき）

　リンカ(link.exe)にオプションを渡すには、-linkオプションに続けてリンカ用のオプションを指定する。
SDL+OpenGLなプログラムなら
cl hoge.cc glu32.lib opengl32.lib SDL.lib SDLmain.lib -MD -link -SUBSYSTEM:WINDOWS
こんな具合。
長すぎるんで頻繁に使う場合は適当にalias張っとくとか。
alias cl_sdloption='echo glu32.lib opengl32.lib SDL.lib SDLmain.lib -MD -link -SUBSYSTEM:WINDOWS'
cl hoge.cc `cl_sdloption`
これでコンパイルもリンクも通る。
実行にはmsvcr71.dllが必要になるわけだけど、これって勝手に再配布していいんだっけ…？

　clやlinkの実行に影響のある環境変数は
CL : clのデフォルトオプション
LINK : linkのデフォルトオプション
INCLUDE : インクルードディレクトリ
LIB : ライブラリのディレクトリ

　オプションの一覧表示は
cl -help
link -Link

2003/7/19

　標準準拠率がかなり高くなったと聞いてVC7.1(Version2003)を購入。
早速インストールし、boostのlambdaやspiritのテストを試してみたたところ、
クソ長いwarningメッセージを吐きまくるがコンパイルも動作も問題なし。ちょっと感動。
これからはboostも積極的に取り入れていこう。
しかしlambdaとかのテンプレート酷使型ライブラリはコンパイルにかかる時間がとんでもなく長い…。

　ターミネーター3を見てきた。
…なんか、非常にイマイチ感が…。
延々とアクションシーンの連続でストーリー性はあまり無く、なんだか見てて飽きてくるし、
最後ジョンは核シェルターに逃げ込み、外は核ミサイルの雨が降るとゆーバッドエンドな展開だし、
すぐ終わるし…。（1時間半くらいしかなかったような）
キャッチフレーズの「恐れるな、未来は変えられる」は嘘ですかと。
比較の問題じゃないんだけど、見た後の満足感はマトリックスリローデッドの方が遥かに大きかった。
ちなみに、ターミネーター2は俺が今まで見た映画の中で一番好きな映画です。

2003/7/8

　AoMとArcturusやってるうちに長大な空白が…。

　Gravity社製作のROの前作的オフラインRPG、Arcturusをヨドバシのポイントで購入、そして昨日ようやくクリア。
クリア時のプレイ時間が約60時間…。
　適当に紹介するとこのゲーム、前述の通り韓国のGravity社がRO（Ragnarok Online）の前に作ったゲームで、
先月末にファルコムから日本語版が発売された。
システムは戦闘がグランディアになった一人用ROって感じで、
　あくまでイントロダクションな序章。
　本筋は宝石探しの旅だけど、サブイベント盛りだくさんで自由度高くてまったり進行な1章。
　1章から2年後、戦争に次ぐ戦争で一気に退廃し、人が死にまくる殺伐とした雰囲気の2章。
　人類シミュレータやらミトラやらアーリマンやら、話が変な方向に進みだす3章。
　ノアの箱舟やら失われた楽園EDENやら有名なものが脈絡なく現れて、
結局最後まで不明瞭なことだらけのまま終わってしまう終章。
と、いくつかの章で構成されている。

　1章の街の人の話を隅々まで聞いて回ってサブイベントこなして…って流れは、
これぞRPGって感じでやっててかなり楽しい。
というか1章想像以上にボリュームがあるようで、
1章だけで30時間くらいかけた俺も相当見逃してるイベントがあるらしい…。
　2章は1章とは打って変わって一本道で陰惨な話の連続。精神的にキツい。敵が異様に強くなって戦闘もキツい。
誰かが「ゼノギアスの後半っぽい」と言ってたけど、言われてみれば確かに似てる気がする。展開も、陰惨な雰囲気も。
ヒロインのアイが満を持して登場するのが救いか。
　そして3章以降、話の展開も戦闘バランスも滅茶苦茶。
黙示緑になぞらえてるらしいけど、無理になぞらえようとして意味不明になってるし。
2章を作ったあたりで作り手が飽きたんじゃないか邪推してしまう。
1～2章は面白いだけに、もったいない。
終盤まで1章のノリでやってほしかったなぁ。製作の手間は倍増するだろうけど…。
なんだかんだ言って1日15時間ペースで進めてしまうくらいにははまってたわけだけど…。

　パッケージ、説明書、OPムービー、ゲーム中全てにおいてキャラの絵柄が違うのはなんとも詐欺くさい。
ゲーム中も説明書の絵柄でやって欲しかったなぁ。
というかファルコムは今回翻訳とパッケージ＆説明書くらいしか関わってないらしいんで、
（西風の時原形留めないくらい手を加えて本土で叩かれたからだとかなんとか）
バグフィックスなんかのサポートも期待できそうにないのがなんとも…。

　それとこのゲーム、BGMもROと同じチーム（TeMP）がやってるらしいけど、
…というか半分曲目当てで買ったんだけど、なんかROと比べるとイマイチな感じがする。
けど、方々で曲がいいと言われてるのを見ると、たまたま俺の好みに会わなかっただけのような気もする。
それなりに気に入ったのが終盤のN.O.A.H.の曲とEDENの曲あたり。
ちなみにROではゲッフェンの町の曲が一番のお気に入り。
（Beta2以降の曲はほとんどゲーム中には聞いてないんで選考から除外）
　ROと言えば、ROのまともなサントラが出たら是非買いたいところだけど、
ガンホー社にそれを望むのは無理なんだろうなぁ…。

　シズとアイのコンビがサイコー、とか、
2章のドーム変わりすぎ、辛すぎ、とか、
使徒のデザインだめすぎ、ギャグですかあれは、とか
黄金寺院の暗号を解けた神はいるのでしょーか、とか
セリーヌの着替えのドット絵アニメ無駄に手が込みすぎ、とか
強制終了しすぎ、さすが重力、とか
語りたいことはまだまだあるんだけど…。
周囲にこのゲームやってる人がいなくてもどかしい。

2003/6

2003/6/19

　奇妙な巡り合わせにより、会社巡り中。（と言ってもまだ2社だけど）
就職活動ってわけではないんでそんなに気構える必要もないんだけど、
プレゼンやら何やら今までほとんど経験してなかったことの連続で結構精神的疲労が…。
　昨日の大阪での会社訪問では、
ゲーム会社のヤバい話、黒い話、その他色んな経験談が聞けて暗い現実が垣間見えて、
10年後のくたびれた自分がなんとなく想像できてちょっと鬱になったり…。
学生の間に、まだ社会のしがらみがあまりないない間に何か一つ、
悔いを残さない大きな事をやっておきたいね…。

　蒼トリ、占領ENDもドラゴン襲来ENDも見てCGもコンプ。
ゲーム自体は割とあっさり終わってしまったけど、
ここまで物語に引き込まれたのは久々かもしれない。
というか引き込まれた要因はスツーカの語りに拠るところが大きい気がする。
彼は俺的このゲームの中で最も魅力的なキャラである。
俺は彼のような渋い男になりたい。
そしてナノカたんのような女の子を娶りたい。
…両方とも激しく無理くせぇ。

　やっっっと大往生/ケツイサントラ到着。
ケツイ5面の曲が素晴らしい。
延々リピート中。

2003/6/17

　今更ながら蒼トリ（青い海のトリスティア）を購入し、はまる。
なんかこのゲーム、錬金術で造った金やダイヤを闇商人に売りさばいたり、
非合法の重火器を売買したり、その他色々ダークな駆け引きがあって意外。
パッケージの絵柄からはこの内容はちょっと想像できない。
　駒都えーじ氏の絵はやはりイイ…、んだけど、肝心のCGの枚数少ない。
一応音声入りだけど、極一部のイベントにしか入ってないし、
それなりに楽しめるけど、この内容で8000円はちと高いなぁというのが正直な感想。

　今日から一泊で大阪に行くことに。

2003/6/13

　先日のLuaの問題、 ライブラリをリンクする方のプロジェクトのコンパイルオプションで、
全般＞プログラム全体の最適化
を切ったらとりあえず正常に動くようになった。
お前が原因かぁぁぁ！
　でも、小さなテストプログラムを用意してこのオプションを適用してみたところ、問題は起きなかった。
となると問題がある部分はゲームのコード自体だろうか。
なんせ俺のやることだからどんな問題が起きても不思議はない。が、
Luaライブラリをリンクした時だけしかこの問題は発生しなかったという事実もある。
ついでに言うと、gccではこの問題は起きなかったという事実もある。
（学校で使えるようにgcc+GLX用のコードも用意している）
あーもう、わけわからん。
一応解決できたから今は気にしないようにしよう…。

　久しぶりに衝突の処理の部分のコードを見ていたら
うっかりミスっぽい部分を発見したので適当に修正を入れる。
するとあっさり思い描いていた理想の衝突になった。ラッキー。
2ヶ月以上前の自分って当てにならんね…。

　思わぬ臨時収入が入ったのでマシンのアップグレードを計画中。
PenIV3Gを購入する予定だ。
DualCeleronなんて構成も考えたけど、プログラム系に転向して以来マルチプロセッサ環境を活かすような作業
（クソ重いレンダリングとか）をほとんどやってないし、これからもやらなさそうなんで却下。
しかしCPUの数が変わるとOSごと再インストールしないといけなくなるのがまためんどくさい…。

2003/6/11

　ようやくLuaから敵の行動や弾発射の制御ができるように。
タイムラインと組み合わせた時ちょっと挙動がおかしくなったりするんでそこらへんの改善、
あと背景やカメラの制御のスクリプト化が終わればシステム部分の開発は一段落つけそうだ。
システム部分以外は全部プログラム本体から切り離すのは初期の頃からの目標だったんで、
これが達成できれば思い残すことなくゲーム内容の製作に取り組める。
…とか言いつつ、システム部分がなんとかなったらCgシェーダの組み込みまでやってみようかと考えてたり…。
しかし最近注意力が散漫になって進みが遅い…。

　Lua5.0の日本語マニュアル。ありがたい。
凄情報源。なにやら紹介されてて感謝しつつ…。

　そして大往生/ケツイサントラ予約完了。

2003/6/9

　EnemyMLを読み込み時に木構造のバイナリデータ化しようとコードを書いていた時の出来事。
データ保持は
struct hoge {
　　map<string, hoge> branch;
　　･･･
};
こんな感じの入れ子のコンテナでやるという設計で、
gccで問題なく動作するところまで漕ぎ着けた…んだけど、
これはVCではコンパイルできないことが発覚。
VCでは先にhogeを完全に定義しておかないとだめらしく、つまり入れ子にすることはできない。
思いつく解決策はコンテナをmap<string, hoge*>として自前でメモリの割り当て&解放をやっていく方法くらい。
というわけで、現在萎えまくりながらVC用コードを作成中。
つうか何とか上のコードをVCで通す方法は無いだろーか…。
Luaがデバッグモードでおかしくなるのも直らんし…。

2003/6/8

　遠出したり読書したりしてるうちに週末が終了。
パソコンと延々と向かい合う日が続いてたんでいいリフレッシュになった気がする。

　…リフレッシュも束の間、
VCでLuaのライブラリを作ってスタティックリンクしてデバッグモードで起動すると速攻落ちるという問題が発生。
Luaライブラリのコンパイルオプションやらなんやらをちょびっと変えて再度リンクしなおしてテスト…、
を、延々と5時間以上繰り返すも一向る気配無し。
モチベーションだけがどんどん低下していく…。
普通に起動した場合は問題なく動作している（少なくともそう見える）んで、
解決しないと先に進めないってわけでもないんだけど…このままほっとくのは気持ち悪すぎる。
何とかならんもんか…。

　ちなみに俺はgccでモジュールを書いてVCで統合という感じで作業している。
gccはWindows以外の環境でもよく使われてるし、VCよりコンパイル時のチェックが厳しいんで
こっちで作っておいたほうが可搬性があるコードになる。
そして最終的にはWindows特化なVCに強力に最適化してもらう、という寸法。
つうかできれば全工程gccでやりたいんだけど、Windows依存な部分があるんでそうもいかんという実態…。



Luaシェーダ弄り。
左は普通にPhongシェーディングしたもの。（式間違ってる気がする…）
中央はそれに加えて色を法線のXYZ要素にしたもの。
右はさらに法線を適当な行列で捻じ曲げたもの。

2003/6/6

　クソ暑い一日だった。
これからもっと暑くなっていくことを考えると気が滅入る…。

　面倒だったけど必要に迫られて作成したLua用ベクトル&行列計算ライブラリ。使用例。
これを作ってる途中、行列の掛け算の部分で'+'を間違って','と書いてしまい、
それでもエラーも警告も出ないし部分的には正常に動いてるもんだから無駄に長時間悩む羽目に。
引数&戻り値無制限って怖いかもしんない…、ってか俺がマヌケなだけか。

2003/6/5

　特別授業とやらで忙しかった今週もようやく終わりが近づいてきた。

　↓シェーダをLuaで書いてレンダリングしてみた球。
しかし肝心のレンダラ本体がまだ球しかレンダリングできなくて面白くない。
途中で飽きることなくポリゴンオブジェクトのレンダリングまで漕ぎ着けたらソースごと公開する予定。
レンダラ書きもなかなか楽しいかもしれん。
…なんだかまた盛大に脇道に逸れつつあるような…。

　レンダリング所要時間は、プログラム内に書いたシェーダを使うと2.4秒、Luaシェーダを使うと3.7秒。
3倍くらい遅くなるのを覚悟してたけど、意外に早い。
プログラムの外側にシェーダを置ける利点を考えれば十分許容できる範囲だと思われる。

2003/6/2

　昼休みに西口付近のとらのあなへ立ち寄っておとぎ奉り2巻Get。
満を持していろりたん登場。
4人目はJBだったりするんだろうか。

　Luaで敵の行動を制御できるようにする基本的な関数群と、
EnemyMLからLuaを呼ぶ機構をぼちぼち作成中。
　最近学校の授業でレンダラやらシェーダやら作ってて、
XMLやLuaに関するノウハウをそれらに活かせないかと考えている。
シーンの記述はXMLでやって、シェーダはLuaで書くとか。
そんなに難しくもなさそうな気がする。気が向いたら試してみよう…。

　面白いものを見つけてしばらくはまり込む。
上手くやれば全部LvMAX行くらしいけど、どうしても水道管（？）がLvMAXにならん…。
　6/3追記：達成
雨が上がる条件はオレンジの球のレベルが一定値に達したら、というのが肝。

2003/6/1

　Luaを組み込み中。
includeする時にExtern "C"{}が必要だと知らずにリンクエラーで悩みまくったり、
テーブルをスタックに積む方法が分からなくて悩みまくったり、
LuaからCの関数をうまく呼び出せなくて悩みまくったりと詰まりっぱなしだったけど、
結局白い弾幕くんのソース（command_lua.cc）を見てほとんど解決。ありがたや…。

　問題なくCプログラムと連動できるようになってから急に楽しくなってきた。
Cプログラムでゲーム内のデータとやり取りする関数さえ用意して登録しておけば、
Cプログラム自体には手を加えなくてもLuaからゲーム内の情報を自由自在に変更できる。
これは素晴らしく役に立ちそうだ…。

2003/5

2003/5/31

　Cygwin/XFree86上でGtkなプログラムをコンパイルしたり、
GLXなプログラムをコンパイルしたりして遊んでるうちに1日経過。
今までまともにCygwinのXWindow使ってなかったけど、
Linuxと完全互換の開発環境を得られるという利点にようやく気付き、使い出した。
クソ重いっつー欠点もあるし素直にLinuxでやってもよさそうなもんだけど、Windowsと共存できるのはありがたい。
KDE-Cygwinが実用レベルなくらいに軽かったらなぁ…。
というかそろそろ新しいマザーとPen4なCPUが欲しい…。

　ひょっとしたらこの情報を求めてる人もいるかもしれないのでメモ。
　デフォルトの状態ではpkg-configのpathは/usr/X11R6/lib/pkgconfigには通っていないので、.bash_loginに
export PKG_CONFIG_PATH=/lib/pkgconfig:/usr/lib/pkgconfig:/usr/X11R6/lib/pkgconfig
とでも書き加えておく。
XWindow用のgtk使ったプログラムをコンパイルする場合は、
上記の設定後、コンパイルオプションに $(pkg-config gtk+-x11-2.0 --cflags --libs) を追加。
　GLXを使ったプログラムをコンパイルする時のpathとライブラリの指定は
-I/usr/XFree86/include/ -L/usr/XFree86/lib/ -lX11 -lGL -lGLU
必要に応じて適当に追加する。

2003/5/30

　LuaがいいらしいのでLuaについてあれこれ調べたり、
EnemyMLの機能強化やデータの取り扱いについてあれこれ思案したり…。
どうも最近プログラム絡みのことについて考え出すと他のことに全然頭が回らなくなってる気がする。


　そのうち書こうと思っていた、サボってるうちに溜まっていたネタ。
Cygwin/XFree86上でKDEという面白そうなものを発見したので動かしてみた。

　まずは適当にダウンロードして適当にウィザードに従って適当にインストール。
インストーラの容量は45MB程度だけど、ファイル数が異様に多いのでインストールには結構時間がかかる。
インストールが終わったら、
KDEをインストールしたディレクトリにあるkde起動用バッチファイル（/opt/kde3/startkde.bat）を実行。
しかし起動開始直後にXWin.exeが見つからないと言われて中断してしまう。
XWin.exe自体は/opt/kde3/binに存在しているのを見ると、どうやら環境変数pathが適切に設定されていないらしい。
startkde.batの中身を見てみたところ、cygwinのルートディレクトリとしてCYGWIN_ROOTという環境変数を参照してるけど、
そのCYGWIN_ROOTが定義されている場所がどこにも無いことが発覚。
つうわけで、cygwin.batかstartkde.batの最初の方にでも
SET CYGWIN_ROOT=C:\cygwin
と追加し、再度startkde。

　今度は開始後XWindowは起動するものの、
コンソールにDCOPClientがどうのというエラーメッセージらしきものを垂れ流した後やっぱり中断してしまう。
これは公式サイトのFAQに対処方法が載っていた。
説明に従ってレジストリを書き換え、再度startkde。今度こそ問題なく起動。
WindowsなのかLinuxなのかよくわからぬ面白いデスクトップに。

　しかし、重い。
ウィンドウ一個開くのに10秒くらい待たされるし、操作のレスポンスもトロい。
メモリ使用量を見てみると…390MB！絶句。これはちょっと使い物にならん…。
試みは面白いと思うんだけどなぁ…。

2003/5/28

　意外な人物に捕捉されてて驚きつつ、既存の機能は引き継いでXMLスタイルへ移行完了。
と言っても特に機能の追加は無し。内容にも変化無し。
今のところ単に記述量と実行ファイルの容量が多くなっただけのような…。
　action要素の中にBulletMLを仕込めないかなぁとか、
Luaで行動を制御できるようにして、EnemyMLからそれを呼び出せるようにできないかなぁとか、
想像だけは色々広がるけど実装は未定。

　5月は俺も俺の周囲の人も病んでる人が多かった気がするけど…、
というか現在進行形で病んでる人が多いような気もするが…、そろそろ復活の兆し。
適当なところでプログラムに一段落入れてモデリングもせねば。

2003/5/22

　事の発端は友人とRagnarok Onlineのβ1初期の頃を懐古していたときのことだ。
「ツデローヘデームベトーン」や「ヂッハベ」に代表される、俗に「重力語」と呼ばれるブッ壊れた日本語が
ROの大きな魅力であったことは当時のプレイヤーには疑いようのない事実だ。
そんなわけで、今は亡き重力語変換システムを俺らの手で復活させられないだろうか？という話になった。
去年の今頃も同じような話が上がったけど、
当時はprintfやscanfで一喜一憂していた時代なのでそんなの夢物語だった。
だが、今なら…。

　変換の仕方は確か英大文字を小文字に変えればいいだけで非常に簡単だったはず。
ということで、ファイルをドラッグしたら重力語に変換したコピーを作成するプログラムを作ってみた。
あっさり成功。でもちょっと感動。
若干変な部分もあるが（ドッペルゲンガー＞ドッペルヒンヌーとか。ドッペル貧乳？？）
とりあえず今は細かいことは置いておくことにする。
　しかしこれだけでは物足りない。
以前あった重力語変換システムみたいに、指定したURLを丸ごと重力語に翻訳して表示する機能が欲しいのだ。

　そんなわけで、こういう用途に向いているような気がするPHPというサーバーサイドスクリプトに手をつけてみる。
めんどくさそうなHTTPで通信する部分は、とりあえず今はサンプルを借用。
変数名に$がつくのと文字列演算子の"."と".="の存在以外は大体Cと同じなので、割と適当にやってもなんとかなる。
一番重要な部分のフォームからの入力は
$HTTP_POST_VARS['（inputタグで指定した名前）']
という変数で受け取る…。
　…てな具合であれこれ弄り回してるうちに、それなりに動く変換システムが良く出来上がりました。
イェロージェームストーン＞ツデローへデームベトーン、アックス＞ヂッハベあたりはばっちり。
色々妙な部分もあるが、とりあえず今はこんなとこだろう…。

　PHPは手軽な割に色んなことができて楽しい。
他に何か面白そうな用途はないかなぁ…。

2003/5/17

　TinyXMLを導入してXMLスタイルに移行中。
TinyXMLは、パースの速度が若干遅いけどその名の通りコードサイズが小さい軽量型XMLパーサ…らしい。
もっとも選んだ理由はいくつか適当にライブラリを拾ってきてヘッダファイルとサンプルプログラムを見て
一番分かりやすそうだったからっつう不純なもんなんだけど。
　実際使ってみたところ、かなり分かりやすく、使いやすく、非常に好感触。
このまますんなり移行できそう。

2003/5/15

　気が付けば1週間も間が。
なんか最近調子出ないなぁ…。

　歌鶫をあれこれ改良。
mqoとobjを読めるように。画像はtgaに加えてbmpも読めるように。
かなりいい加減なfor文、自機の速度変更、テクスチャアニメ、その他色々。
今後しばらく大きな変更が続きそうなので、スクリプトの説明書きは後回し。

　だんだん複雑で面倒になっていく構文解析部分のコードを見てふと考えついたけど、
XMLパーサを導入して記述をXMLスタイルにしてみるといいかもしれない。
構文解析は楽になりそうだし、記述も多少長ったらしくなるけどより一般的で分かりやすくなりそうな気がする。
週末はこのあたりを調べてみよう。

2003/5/7

　今更ながら、式神の城2をちらっとやってみる。
方々で「斑鳩のパクリだ」と言われてるのは耳にしていたけど、
実際やってみると…やっぱりかなり斑鳩の影響受けてそうな雰囲気。
敵機のデザインと行動パターンあたりが特に…。
　最初はEasyでやってみたらあっさりノーミスで3面クリアできてしまったので、
2回目はNormalでやったら緊張が途切れたのか3面道中でげーむおーばー。みっともねー。

　背景がかなり綺麗だし、前作よりはいい感じの第一印象だった気がするが、
ぱっと見でものすごく気になり、斑鳩と決定的に違うと思われたのが敵機の照光処理。
3面までの印象だけど、明らかに陰が暗すぎる。
まるで真っ暗闇の中でスポットライトで照らされたような状態。
しかもハイライトがほとんど無いため、なんだかメリハリが無い。
　斑鳩は照光をテクスチャに焼き込んで、ゲーム中はあまり照光処理の結果が強く出ないようにしている感じがする。
それでも全体的に室内っぽい感じの照光になってしまってる印象だった。特に1面降下前。
式神2はさらに室内っぽい雰囲気になってしまっている。
別に焼き込まないのが悪いというわけではなく（俺も可能なら焼き込まずにやりたい）、
焼き込まないなら焼き込まないで、せめてライトをもう1,2灯配置するとかすれば大分良くなりそうな気がするんだが…。

2003/5/5

　GW中に目標達成する予定だったのが今一歩力及ばす。
しかしアニメーション関連はそれなりの成果。
少々不正確ではあるが線形以外のキーフレームの補間ができるし、1軸単位でキーを設定できる。
ゲームの基本部分はスクリプトで記述して、スクリプトじゃ荷が重い複雑な分岐なんかは
プログラムの中に書いてスクリプトからそれを呼び出す、って形式でやっていく予定。
パーツ単位のアニメーション、for文で弾の記述の簡略化、背景制御、mqoとobjを取り込めるようにするのが今後の目標か。
あと未だに不正確な衝突もなんとかしておきたい…。
このあたりが落ち着いたらそろそろオリジナルSTG製作へ向けて機体デザインとかモデリングとかしたいなぁ…。

　今日が免許を取って2回目の誕生日だけど、まだ20回くらいしか運転してない気がする。
というか東京に越して以来運転する機会が皆無で、もう1年以上運転していない。
次に運転する時無事でいられる自信もない。
もはや完全にペーパードライバー…。

2003/5/2

　現在ゲーム用の簡単なスクリプトエンジンを製作中。
ゲーム内容記述をスクリプト化し、プログラム本体に手を加えなくてもゲーム内容を書き換えられるようしようという計画。
こうすれば製作効率も上がるし、誰でも改造できるようになる。
　とりあえず構文を解釈し、指示通りに敵を配置し、動かし、弾を撃たせるところまでは既に完了。
もちっと細かいところを突き詰めて、独自形式以外のモデルを取り込めるようにしたら公開と行きたいところ。

　スクリプトエンジン製作にはSTLのmapとlistが大活躍。
mapのオブジェクトに名前を付け、その名前からオブジェクトにアクセスできる機能は俺が長い間捜し求めていたものだった。
（自分で作りゃ済む話ではあるんだけど）
アルゴリズムと関数オブジェクトで複雑なソートなんかも楽々だし、素晴らしい。爽快ですらある。
凄ぇぜSTL。

2003/4

2003/4/7

　それなりにまともになってきた面との衝突。
しかし、頂点単位の判定の時とは逆に、粗いポリゴンだとまともな判定になっているように見えるけど、
密なポリゴンだとまだめり込んだりする。
めり込んでる時も衝突自体は検出できてるから、問題があるのは突き飛ばす処理だろうか…。

　衝突検出の手順としては、まず自機に一番近い三角形を割り出して、
その三角形との内外判定に合格し、自機が法線の逆方向にあるとき衝突、とみなすようにやってみた。
三角形との距離の比較は法線と頂点の内積と法線と自機の内積の比較で行い、
衝突後は突っ込んでる距離分法線方向に突き飛ばしている。
　閉じたポリゴンならばこうすればオブジェクトの内側にあるときだけ衝突を検出できるだろう、
と目論んでいたんだけど…、まだ調整が足りんようだ。
つうかそれ以前にこのアルゴリズム自体に問題がある可能性も考えられる…。
　あーもう、いい加減次のことやりたい。けど中途半端なところで投げたくもない…。

　最近になってようやく本格的にSTLを使い始めた。
まだvectorくらいしか使ってないけど、何故今までこんな便利なもん使わなかったんだろうか、と思うくらい便利。
　便利なんだけど一つはまり込んだ罠があって、
コンテナをpush_backやinsertで領域を伸長していくと、たまにデータの位置（アドレス）が変わってしまう。
コンテナの特定の位置をポインタやイテレータとして保存しておいて後から参照する場合、
途中で伸長が行われると、いつの間にかデータが移動してポインタの指す先に何も無くなっていた、
なんてことがたまに起こる。
これ、ポインタじゃなく添字で位置を保存するしか解決法はないんだろうか。ちょっと痛い問題…。

2003/4/6

　そういえば来月で俺も20歳。
中学高校時代がほとんど空白だったんで全然実感ないんだけど、しっかり歳だけは食ってるという冷酷な事実。
　俺はもう若くはないし性根入れて勉強しないといかんなぁというか、
俺は年上キャラ萌えなんだがもうほとんどが年下の年上キャラで寂しいなぁというか、
もう宮崎県の延岡市とかいう街には二度と住みたくないなぁというか、
20というと順当に生きられたとしても既に人生の3分の1くらいは使い果たしているわけで、
そう考えるとちょっと怖いなぁというか…、
　…やめよう。考え出すとどんどん深みに嵌っていきそうだ…。
常に前進を止めない生き方でありたい。

2003/4/5

　三角形の三つの頂点を含む面と原点との最短距離って、
単に頂点と法線の内積を取ればいいだけじゃねえかー！
つうことで遂に面との衝突実装。なんともマヌケな最後じゃった…。

　ここで一旦衝突は終わらせたいところだけど…まためり込む問題が付きまとう。
まだしばらく衝突関連をやらねばならんようだ…。

2003/4/4

　衝突進まず。
明日は本屋で数学の参考書を立ち読みしてくるか…。
ついでに蒼トリでも買ってくるか…。

　今後主に学校で使う機会が多そうなので、objファイルのローダーを書いてみる
objは主にMAYAで使われる形状ファイルだけど、最も一般的に使われている形状ファイルでもある。
　objファイルはテキストで非常にわかりやすく記述されていて、
vで始まる文字列には頂点の位置、
vtで始まる文字列にはUV座標、
vnで始まる文字列には法線、
gで始まる文字列はポリゴンのグループ情報を示し、
fで始まる文字列には、ポリゴンの各頂点の情報が　頂点/UV/法線　の順のインデックスで記述してある。
位置以外は必須じゃないので、インデックスは　頂点/法線　だったり頂点だけのこともある。
　…などと説明らしきものを書いてみたけど、
わざわざここで説明しなくても実際にobjをテキストエディタで開いてみれば一目瞭然。
なのでローダーも簡単に書けるだろう、と踏んでいたんだけど…、一つ重大な罠があって頭を悩ませることになった。

　ポリゴンを記述している部分（fで始まる文字列）のインデックスは、配列の添字に使われるものより1進んでいる。
例えば頂点数が10なら頂点のインデックスは0～9になるべきだけど、実際には1～10になっている。
読み込むときは1下げてやらないといけない。
この罠のせいで3時間くらい悩んだ…。アホらしー。

2003/4/3

　法線の逆方向に頂点を引っ込める方法、
よく考えれば（よく考えなくても）辺との判定でも使えるじゃないか、
ということでざっとやってみたら、これまでのに比べてかなり美しい結果になった。
必要最小限しか押し返さないし、オブジェクトにめり込むこともあまりない。（ないわけではないが…）
あと一歩ッ！
美しい衝突まであと一歩だッ！

　面と判定をやるのに必要な情報は、面の法線と、原点からの距離。
三角形の場合、これに加えて3つの頂点の位置情報があればいい。
三角形との内外判定を行い、距離を測る。
内外判定に合格し、距離が衝突の半径より短ければ衝突だ。
内外判定は三つの頂点と自機が成す角度を内積から求め、その合計から判別できる。
内側なら360度、外側なら360度未満になる。

　手順は上記通り割と単純ですぐできそうな気がするんだけど、
三角形の原点からの距離を割り出すところで詰まっている…。
三つの頂点を含む面と原点との最短距離を測ればいいんだけど…、方法が思いつかない。
この部分以外はもうコード書きあがってるのにー…。


　友人がパソコンの不調で助けを求めてきて、色々調べてみた結果ウィルスに侵されていることが発覚。
みなさんもプロセス一覧にWinHelp.exeというのがあったら要注意。

2003/4/1

　健康診断で癌と診断された。
…という縁起でもない四月馬鹿ネタはさておき。

　実際今日は健康診断があったんだけど、尿検査で引っかかって再検査ということになった。
何でもウロビリノーゲンとかいう物質が通常より多く検出されたらしい。
糖ほど怖いもんでもないらしいけど、やっぱ心配になってくる。
気になってざっと調べてみた。

　尿にウロビリノーゲンが出てくるのは、主に疲労と肝臓回りの病気が原因らしい。
肝臓回りの病気を具体的に挙げると、肝炎、肝硬変、肝臓癌など。
うげぇ、ますます心配になってきた…。
　今度はその肝臓の病気についてざっと調べてみる。
肝臓の病気と言えば真っ先にアルコールとの関係を思い出すけど、
俺は酒は全く飲まない…というか缶ビール一本で顔が真っ赤になって頭痛がしてくるくらい弱くて飲めないんで、
アルコール絡みの病因は考えにくい。
というかそれ以前に、日本人の肝炎の80%はウィルスによるものらしい。ちょっと意外。
　肝臓癌などのヤバい症状へ進展する可能性が高いのはB型肝炎、C型肝炎らしいけど、
これは血液を介して感染するものらしい。これも心当たりは全くなし。
肝硬変は肝炎が進行して移行する症状らしいので、これも考えにくい。
　少し安心。
残るそれらしい要因として考えられそうなのは…疲労？
…これも心当たりないつうかまるっきり無縁だしなぁ…。

　そんなこんなで、四月早々鬱にさせてくれる1日だった。
まあ多分今日の心配は杞憂に終わるだろうけど。
まだやりたいことは山積みだし、興味は尽きないし、当分くたばる気はないぞ俺は。

2003/3

2003/3/31

　久々に新宿まで足を出し、西スポに行ってみたらBorderDownのロケテをやってるのを発見。
早速やってみたが…、ばりばりの覚えゲー＆パターンゲーな雰囲気がぷんぷん。
最近の傾向に漏れず難度はかなり高めだし、こりゃちと微妙っつうか、俺の肌には合わないかもなぁ…。
2ボスがやたらしつこいホーミングや大量の加速弾をばら撒いてきて萎え。
初見じゃあんなの無理じゃー。
　レーザーのせめぎ合いがメタルブラックやGダラあたりを思い起こさせる。
横スクロールだし地形ばりばりだし、ゲーム全体の雰囲気もこれらに近い感じ。
しかし、自機のデフォルト武器がホーミングレーザーなためか、
後ろから敵が来たり、地形に邪魔されて直接は狙えないところに敵がいたり（グラディウス系によくあるアレ）色々と嫌らしい。
敵は至近距離からでも弾を撃ってくるけど、
遅めの初速で発射されてゆっくり加速していく弾がほとんどなんで理不尽な死に方をすることはあまりなさそう。
今日は2ボスまでしか行けなかったんで、ほとんど2面から受けた印象だが。
ちなみにロケテは3/29～4/6までだそうな。
気が向いたらまたやってみるか…。

　とらのあなに立ち寄ってANUBISの設定資料集（Visualworks of ANUBIS）を購入。
酔う酔うばっかり言ってるけど、実はかなり気に入ったこのゲーム。
資料集もかなりのボリュームで満足。
　ついでに蒼トリの設定資料集も購入。
（こっちはゲーム自体は持ってなかったりするんだが）
駒都えーじ氏の絵はやはりイイですな。げへへ。

　…平日の真っ昼間から何をやっとるんだろう俺…。

2003/3/30

　amazonで頼んでたオルタのサントラが到着。
CITY IN THE STORMがお気に入りです。燃え。
　ついでに頼んでたnVIDIAのCgチュートリアル本を読んでぼちぼちシェーダーの勉強中。
リアルタイムシェーダープログラムは前々から興味はあったけど資料が少なすぎて困っていた分野だったりする。
近いうちにCgシェーダーをゲームに組み込んでみよう。

　辺との衝突判定、実装までは割と簡単にできたけど、オブジェクトにめり込む問題がなかなか解決できない。
当たったら即死にするなら今のままでも結構いけそうだけど、俺は当たっても死なない式で行きたいし…。
衝突の半径を大きくすればめり込む可能性は減るけど、根本的な解決にはならんし…。
うううううう、どーしよー…。
　と、あれこれ悩んでるうちに、面（三角形）との判定ならこれを解決できるような気がしてきた。
最寄の三角形を割り出し、その三角形を衝突の半径分法線の反対方向に引っ込ませ、判定を行う。
これなら自機が面の内側（=オブジェクトの内側）にあるときしか衝突したことにならないし、
衝突の半径が大きくても大丈夫だろう…と思う。
手間取りそうだけど、やはり面との判定をやらんことには美しい衝突判定は完成せぬようだ…。
スクリーンショット

3つのブロックが隣接してる部分に自機を押し付けてると高い確率でめり込みます。
良い子は真似しないように。

2003/3/28

　ここの27日のquick reportによれば、近いうちにOpenGLにARB_vertex_buffer_objectという拡張が実装されるらしい。
DirectXのVertexBufferに相当する機能らしく、リアルタイム系の人には嬉しい実装なんじゃないかと思う。
少なくとも俺はかなり嬉しい。
　先日歌鶫にnVIDIAの拡張命令でこの機能を組み込んだけど、当然これはnVIDIA系ビデオカードじゃないと使えない。
ARB_vertex_buffer_objectはハードウェアベンダ共通の命令なんで、
ドライバがサポートすればnVIDIA系でもATI系でもそれ以外のメーカーのでも使えるようになるわけだ。ありがたい。
ATIとnVIDIAのドライバがサポートしたらこっちに切り替えることにしよう。
つうかATI系はATI_vertex_array_objectって拡張命令でできたのか…。

　今更な情報だけど、まほろまてぃっくＴＶスペシャル。
また俺を萌えさせてくれるか！？
　ゲーム版も製作中らしいけど、俺の経験ではマンガがゲームになって面白かったケースは皆無なのでパスだろうなぁ。
せっかくコナミが作るんだから、マグナムと輝ける闇（手から尾を引く金色の光を出すやつ）で、
セイントや管理者のメカをぶっ壊していくANUBIS風アクションゲームにしてくれたらなかなか楽しそうな気がするんだけど…。
　…つうかいろいろ考えてみたけど、オプションとか地形とか余計なもん無しでただ撃つ＆斬るだけなら、
ANUBIS風ゲームの実現はそう難しくないような気がする。
今の技術力じゃ無理な部分もあるけど、手順はかなり具体的なものが思いつく。
今年度中にサンプル作るくらいの目処でぼちぼちやってみよう…。
…モデリング＆アニメーション上手い人と組めないかなァ。

2003/3/27

　昨日は3D酔いに苦しみながらもなんとかANUBISをクリア。
戦艦5機をベクターキャノンで叩き落していく面がめちゃくちゃ爽快で楽しかったり、
荒野の乱戦で仲間が一機一機撃破されていく様子が結構生々しくて嫌な気分にさせてくれたり…、
最後似たような見た目＆似たような攻撃パターンの敵と3連戦になるんだけど、これはちょっとダルい。
これ以外はテンポよく進んで気持ち良かっただけに勿体無い気がする。
ラスボスはザカート並かそれ以上にドでかい敵を期待してたんだけどなぁ…。

　衝突をもう一歩発展させ、ぐわんげみたいに当たっても押し返されるようにしてみる。
手順としては、まず衝突時の頂点と自機の位置から方向を求める。
自機の位置-頂点の位置の座標を出し、その座標のY軸要素を0にし、正規化。
（任意平面に投影する必要が出たら行列を使うべきだろうけど、
当面はXZ平面上でやる予定なんで単純にYを0にするだけ。）
そしてその方向に向けて適当な距離…とりあえず自機の速度*2の距離を引き離す。

　いざ実行してみると、しっかり押し返してくれた。
これで押し返し実装…といいたいところだけど、同時に頂点単位の衝突判定じゃちと苦しいことが発覚。
ちょっとでも隙間が開いてるとすり抜けてしまってみっともない。
やはり面との衝突じゃないと実用にならんかなぁ…。
明日はさらに一歩進めて辺との衝突にしてみよう…。

　拙作石のような物体をゲームで使えるようにポリゴン削減＆1枚のテクスチャに収まるようにマッピングのやりなおし。
やはり自分で作ったモデルがゲームの中で動いてくれるのはちょっと感動するもんがある。

2003/3/25

　謎の企画への参加に伴い、ほったらかしになってたゲームシステムの作成を再開。
手始めにかなりインチキな方法だけど衝突を実装。
AAバウンディングボックスとの判定に合格したら、オブジェクトの頂点と総当りで判定を行うというアルゴリズム。
要するに敵オブジェクトを弾の塊とみなす手法。
でもこれだとある程度密なオブジェクトじゃないとすり抜ける可能性があるんで、いまいちスマートとは言えない。
速度面では有利なんだろうけど…。
線との判定まではわかるけど、面との判定が未だ理解できてない現状。
　しかしゲームの進行に必要な最小限の機能はこれで一通り揃ったと言ってもいいような気がする。
しばらくはこれで進めてみよう。

＊23:30頃間違ってデバッグ中のバグ混入バージョンをアップしてました。
　もしそれを落としてた人がいたら…、すみませぬ。

2003/3/24

　ちょっと息抜きちう。
せっかく買ったのに、しかもつまらんわけでもないのに投げ出すのは悔しすぎるんで、
酔い止め飲んで限界まで画面から離れてANUBISプレイ中。
これでも2時間以上続けてやってると吐き気がしてくる…、情けねェ。
現在ヴァイオラA.I.消去で挫折しそうになったのを何とか乗り越え、ゼロシフトとやらを入手するところまで到達。
なんとかクリアまで持ちこたえてくれ、俺。

2003/3/22

　ビデオメモリ直アクセス（この方法Vartex Array Range、略してVARと呼ぶそうな。長ったらしいのでここでもVARと呼ぶ）
での描画の時の挙動をあれこれ調査。主に実行速度。
（調査環境はPenIII1G&GeForce4Ti4600）
　昨日は適当にしか調べてなかったからよくわからなかっけど、予想してたより大きな効果があったようだ。
通常時だと表示ポリゴン数が30,000を超えたあたりから60FPSを維持できなくなってくるのが、
VAR有効時だと60,000ポリゴンくらいまで60FPSを維持している。

　俺の環境ではOpenGLは何故か処理が追いつかなくなってくると一旦大きくFPSを落として（60FPS>40FPS）
しばらくそのFPSを維持しようと勤めるみたいで詳細なFPSの変化は分からないけど、
VAR無効時　～30,000Polygon:60FPS　～60,000Polygon:40FPS
VAR有効時　～60,000Polygon:60FPS　～130,000Polygon:40FPS
と言った感じで変化した。
DirectX版で同じテストをしたところ、FPSの下がり方が違う（少しずつ減っていく）ものの、
描画速度自体はVAR有効時のOpenGL版とほぼ同じ結果になった。
　大満足。
DirectXとほぼ同じ速度が出せたとは。しかも10万ポリゴン超えてもこの速度。素晴らしすぎる。
いやまあ、実際ゲームにするときは多くても2万ポリゴンくらいを限度にすべきだろうけど…。

　よくわからないのが、アルファブレンドの処理。
具体的には大爆発のエフェクトをかけたときの挙動だけど、
これはDirectXでもVAR有効OpenGLでもVAR無効OpenGLでも殆ど同じように速度が低下した。
しかもこれはポリゴン描画とは違って、高い解像度で実行したとき速度の低下が著しい。
（ポリゴン描画速度は解像度を上げても殆ど結果は変わらなかった）
アルファブレンドはビデオカードのアクセラレーションをあまり受けないんだろーか…。

　そしてやばい問題が、ATIの拡張機能にはVARに相当するのが見当たらないこと。
つうかこれはもうどうしようもない。
何か方法が見つかるまでこの問題は無視ということで…。
ゲームが起動すらしなくなるってわけではないし、そこまで致命的な問題にもならないだろう、多分。

2003/3/21

　英語ドキュメントと格闘すること二日、 やっとOpenGLでビデオメモリに直アクセスすることができた。
nVidiaの拡張機能で実現してるんで、今のとこGeForce系、Quadro系ビデオカードじゃないとこの機能は使えないけど、
描画速度は2,30%程向上。
すばらすぃ。

　DirectXがOpenGLより描画が早い大きな理由の一つが、標準で実装されてるVertex Buffer、
つまりビデオメモリに頂点データを溜め込んでおき、描画を高速化する機能の存在だと知り、
（標準ではD3DのVertex Bufferに相当する機能が無いOpenGLでは、
描画の際には常にシステムメモリ＞ビデオメモリのデータのコピー処理が行われる。
データのコピーは最も時間がかかる処理の一つであり、描画は遅くなる。）
OpenGLでこれを実現する方法は無いかと探し回っていたわけでした。

　つうかこの辺の情報の日本語のWeb資料が皆無ってのは寂しすぎる。
今回得た情報は書き残しておこう。
今日は疲れたのでとりあえず実行ファイルだけ…。
　…なんか相変わらず脇道に逸れてばっかりで大きな進歩はないような気がするけど、
まあ勉強になってるからいいとしよう…。

　…ANUBIS、俺には向いてないっぽいデス。
酔いまくりでまともにプレイできマセン。
激しくリタイアの予感。

2003/3/19

　昨日はANUBISを買ってきてプレイしてた…んだけど、
マズイことにこのゲーム、動きが激しすぎて酔う。
ダーククロニクルでさえちょっとやばかった俺にはとても耐えられず、
2時間ほどやったら完全にグロッキーに陥り、吐き気を堪えながら寝込むハメに。
慣れるのが先かリタイアするのが先かビミョーなところ…。
ゲーム自体はかなり爽快なんだけどなぁ…。
　オプションやバリアまで見事に再現されているビッグバイパーには失笑。

　歌鶫、細かいところをいくつか修正。
あと32bitカラー以外では何故か超絶重くなるという事実を忘れていたんで注意書きとして添えておくことに。
そしてUpDate項目には常に最新のを置いておくように。
つうか、バグ修正以外では大きな変更を加えるまで公開は控えるようにしよう…。

2003/3/16

　微復活。

　昨日今日とやっていたことは歌鶫をDirectX用に書き直す作業。
基本的にゲームの進行部分とそれ以外の部分は切り離してあるし、
座標変換は自前ライブラリでやってるんで、実行可能にするところまではすんなり移植はできた…が、
いくつか違う環境で動作させてみたところ、テクスチャと照光の処理が違うのか、全然違う描画結果になってしまった。
プログラム自体に色々問題があるんだろうけど、これにはかなり萎えた…。
もう当分DirectXのことは考えずにゲーム自体を作ることに専念しよう。
　…でもDirectX版の描画速度はOpenGL版のそれより二回りほど速かった
やっぱ最終的にはDirectXにするべきなんだろーか…。なんか悔しいなぁ…。

　DirectX版製作の副産物、wgl版歌鶫。
wgl版と言っても、今までウィンドウを開く処理やキーボードなどからの入力の処理を
glutというライブラリでやっていたのを自前でやるようにしただけ。
でもこれでかなりWindowsゲームらしくなった気がしなくもない。
　…というかglutのタイマーがあまりにアホだったからwglへの書き直しを思い立って、
wglへの書き直しが意外なほどあっさりできたからDirectXへの書き直しを思い立ったわけだったりする。
よーやくクソ忌々しいコンソールウィンドウと目障りなglut.dllから解放されたよ…。
そして衝突。未だ実装ならず…。

2003/3/14

　何気に捕捉されていたんで再掲、 ぞんでリプ。
余空使用でノーミスクリアなリプがいくつか。7面ノーミスで行けたんで以前のと差し替え。
　お気遣い感謝ですじゃ。

2003/3/13

　本格的に風邪引いてダウン中。
自分で心配になってくるくらい頭が痛くてちとやばげ。
進級確定した安心感から来た油断のせいだろーか…。

　昨日の明け方食い物を買いにコンビニに出かけたら、
途中でお巡りさんに呼び止められ、尋問を受けた。
何でも近くで強盗があり、その犯人の身体的特徴が俺のそれに似ていたとかなんとか。
…いい迷惑じゃ。

2003/3/11

　今日は進級発表があった。
どうやら俺は無事ニ年次に上がれるようだ。
課題のリテイクも無くて一安心…。


衝突関連の調べ物をしてるときに見つけた行列（これ自体は衝突とあんまり関係ないけど）

cos(θ)+(1-cos(θ))*x*x	z*sin(θ)+(1-cos(θ))*x*y	-y*sin(θ)+(1-cos(θ))*x*z	0
-z*sin(θ)+(1-cos(θ))*x*y	cos(θ)+(1-cos(θ))*y*y	x*sin(θ)-(1-cos(θ))*y*z	0
y*sin(θ)-(1-cos(θ))*x*z	-x*sin(θ)+(1-cos(θ))*y*z	cos(θ)+(1-cos(θ))*z*z	0
0	0	0	1

　x,y,zは任意の軸を示す単位ベクトルの要素で、
この行列を使うと任意軸回りにθ(単位はRadian)回転した座標系を得られる。
前々から欲しかったんだよ任意軸回りの回転が！！！めっちゃ感動。
　ちなみに単位ベクトルじゃないベクトルを設定してこの行列で座標変換すると、
変に歪んで笑えることになってしまった。注意。
自力でこの行列を導き出せるくらいになりたいね…。

2003/3/10

　ゲーム製作関連はここ最近地味な改良ばっかりだったんで、一念発起して衝突判定の実装に取り組む。
既に実装済みの弾と自機みたいな点と点との距離の比較ではなく、ポリゴンオブジェクトの衝突。
3Dゲームには欠かせない要素であり、多くのゲームプログラマーさんが頭を悩ませているであろう難問の一つ。

　今回は自機と地形や敵機との衝突を考える。
当たり判定の小さい自機は点としての取り扱いで十分なんで、実際は点とポリゴンとの衝突判定ということになる。
対象が点だから幾分楽そうだけど、それでもクソ真面目に全オブジェクト全ポリゴンとの衝突判定をやってたら
実行速度に深刻な影響が出ると思われるので、
やはりいかに不要な計算を省くか、言うなればいかにサボるかが重要になってくる。
　とりあえず実装にはオーソドックスで比較的簡単だと思われるAABB法(Axis Aligned Bounding Box)を使用。
バウンディングボックスでオブジェクトを区切って何段階かに分けて判別して計算する必要がある部分を洗い出し、
その部だけポリゴン同士の衝突判定の計算をする方法だ。

　今日でバウンディングボックスで区切る部分まで意外とあっさり実装できたんで、
あとは判別とポリゴン同士の衝突判定の計算。
判別は一番簡単だろうけど、問題は肝心の計算部分。まだいまいち理解できていない…。
しかしここを乗り越えられればその後はかなり楽しくなるはず。なんとか乗り切りたい。
　しかしこの分野、微分やら積分やらベクトルやら行列のオンパレードで完全に数学の分野。
高校の時にプログラムでこういうのやる機会が無かったのがホント惜しい…。

　なんとなく昨日に引き続きらじおぞんで。
余空でU_T_Nノーミスノーペインクリアなリプレイ。

2003/3/9

　昨日から頭が痛いわ異様なほど気だるいわ…、また風邪でも引いたんだろうか俺…。
つうか連休に入ってから必要最小限しか出歩いてなくて不健康なことこの上なし。
なんかいい気晴らしはないもんか。
SO3とANUBISでも買ってこようかなァ…。

　なんとなく久々にらじおぞんでをバージョンアップしてやってみる。
背景が派手になってたり7面が簡単になってたり…、当たり判定小さくなってる？
熱中してるうちにそこそこ満足な戦果があがったんで、
余空で7面1ミス、8面ノーミス、X_PSYノーミスなリプレイなんぞを。喰らってる回数結構多いけど…。
　このらじおぞんでというゲーム、グラフィックのクオリティや弾幕の美しさも勿論だけど、
その独特のバックグラウンドストーリーが特に気に入っている。
無個性な作品が溢れる中、ここまで個性的で独自の世界を築いている作品も珍しい。
俺も今後オリジナルのゲームを作る時は、面白さと個性が感じられる作品にしたいところ。

2003/3/7

　マイクロソフト、OpenGLARBを脱会。
今後WindowsではますますOpenGLは衰退していきそうだ…。
「パクるもんパクり尽くしたから脱会したんだろうな」と囁かれてるのを耳にしたけど、
DirectXはバージョンが進むにつれてどんどんOpenGLに似てきて、
9ではOpenGLの機能の殆どを内包してるらしいからあながち言い過ぎでも無いような気がしなくも無い。
とは言え、Windows上ではDirectXが機能面でも速度面でも圧倒的に有利なのも事実。
DirectXの勉強もしないとなぁ…。

　加算で合成するパーティクル用のテクスチャを作ってて不透明度の調整をしている時、
PhotoshopでPixel単位で不透明度を上げる方法を知らない自分に気付く。
レイヤー重ねまくれば完全に透明でない部分は復元できるけど、
これだと完全に透明な部分の復元は無理だし、レイヤー重ねまくるという方法自体なんか納得いかない。
　気になってグラフィッカーの知り合いに聞いてみると、標準機能ではPixel単位で不透明度を上げる機能は無いとのこと。
つまり完全に透明になってしまってる部分は復元できないということになる。
つうわけで、あんまり使うこともなさそうだけど、TGAファイルを完全に不透明にするソフトを作ってみた。
ソース付き（汚いが）、改変再配布自由。
TGAファイルのヘッダの構造を掲載していたサイト（アドレス紛失…）に感謝。

2003/3/6

　寮の洗濯機が新しいものに入れ替わった。
…のはいいんだけど、使用料金が100円から200円に格上げされた。ムカー。

　そういえば歌鶫のネットワーク機能、Windows同士、Linux同士なら問題なく動くけど、
片方がWindows、もう片方がLinuxだと同期が取れなくなるという問題があって現在原因を究明中。
　Windows用SocketAPIもLinuxのそれも元は同じBerkeleySocketAPIを元に設計されているらしいけど、
互換性は完全ではなく、同じソースがどちらのOSでも動くわけではない、
しかも同じ関数名なのに微妙に使い方が違うのがあったりするし、なんか色々挙動が違うし…。うー、だるい…。

　ネットワーク関連のプログラムの書き方は明らかにLinux系のSocketAPIの方が簡潔でわかりやすい。
これはLinux系はOSのkernelレベルでネットワーク機能をサポートしてるのに対し、
WindowsではOSとは独立したライブラリとしてネットワーク機能を実現しているかららしい。
だからLinux系では初期化処理は不要でネットワークの情報もファイルの読み書きと同じように手軽に扱えるし、
WindowsではAPIを使うときにいちいち初期化や終了処理なんかの面倒な手順が必要なのだとか。

昨日も書いたstructとunionを併用する方法で、ビット単位の操作ができると知った。
union {
　struct {
　　bool b1:1;
　　bool b2:1;
　　bool b3:1;
　　bool b4:1;
　　bool b5:1;
　　bool b6:1;
　　bool b7:1;
　　bool b8:1;
　};
　unsigned char b;
};
構造体変数定義のところの":1"がミソで、これはその変数に1ビットを割り当てることを意味する。
この例では1バイト（=8ビット）のunsigned charの1ビットずつをb1～b8に割り当ててるんで、
b8を1にするとbは128になるし、bを255にするとb1～b8は全部1になるという寸法。
もちろん:2とか:32とかもできるけど、どんなに大きなビット数を割り当てても
その変数の型が扱える数値以上の数値は扱えないようだ。
　早速入力データ&リプレイデータを取り扱う部分にこれを使っておいた。
これも使用頻度は高くなさそうだけど、知っておくと色々と便利そうだ。

2003/3/5

　今年になって殆ど日記書いてなかったせいか、サボり癖がついてしまったようだ。
以前は惰性でもなんか書かないと気が済まなかったのに、今は全身のやる気を奮い立たせないと書けない。
これも連休の間に矯正していこう…。

　そういえばもうすっかり花粉の季節ですネ。
目が痒いわくしゃみは出まくるわ、ダルいことこの上ないデス。
つうか俺の場合、春は花粉、5月は5月病、夏は夏バテ、秋から冬にかけては風邪引きまくりで
年がら年中ダルイダルイ言ってるような気がしなくもないけど…。
言うなれば後天性ダルイダルイ症候群と言ったところでしょーか。…情けねェ…。

　バッファ間コピー使わないブラーがどうしても上手くいかんので見切りをつけて他の部分へ。
いい加減背景と敵＆攻撃パターンのバリエーション追加しよう…。
　最近union（共用体）の便利な使い方を知ってたまに使うようになった。
学校で習ったときは「こんなもん何の役に立つんだよ」な気分だったけど、例えば
class Vector
{
public:
　union {
　　struct {
　　　float x,y,z,w;
　　};
　　float v[4];
　};
・・・
};
こうするとxがv[0]、yがv[1]、zがv[2]、wがv[3]に対応するようになる。
配列として一括処理する場合と、個別に処理する場合（名前がついてると分かりやすい場合）
で使い分けができるようになって便利。（ポインタでも同じことはできるが、いちいち"*"つけるのがめんどい）
最もこれ、かなり初歩らしいけど…。

2003/3/3

　alphaへの書き込みができるようになったんで、alphaの書き換えを使ってブラーを実現してみる。
大まかな手順は、スワップする直前のバックバッファを
glColorMask(0,0,0,1);
glClearColor(r,g,b,alpha);
glClear(GL_COLOR_BUFFER_BIT);
てな具合でalphaだけ任意の数値で塗り替えて、
その後glCopyPixels()でフロントバッファからバックバッファに直接合成する、というもの。
結果は…、GeForce4なメインマシンではブラーなしの時と殆ど同じ速度で動くようになった。
が、MilleniumG400なサブマシンでは一旦自前バッファにコピーする方法の時と殆ど変わらないノロさだった。
この極端すぎる速度差、ハードウェアのOpenGLの実装の差なんだろうかなぁ…。
　バッファ間でのデータのやり取りをせず、
ポリゴンを重ねて描画していくことでブラーを実現できないかと思案中。
できるなら多分それが最速のブラーと思われる…。
相変わらず脇道に逸れてばっかりでゲーム自体はなかなか進行してないけど、まあ勉強になるからいいだろう…。

　あとFPS表示を実装。
やってることはtime()で時間を拾得し、前フレームの時間と同じならFPSをカウント、
違っていたらFPS表示を現在のFPSカウントに切り替えて0に戻す、というシンプルなもの。
つうかtime()っつう関数の存在を今まで知らなかった俺…。

　とりあえずここまでのまとめ。
　bキーでブラーの切り替え（ブラーなし＞早いブラー＞遅いブラー＞もっと遅いブラー）
そしてブラーがなし以外の時に1キーを押すとブラー激化、2キーで緩和。
　早いブラーは今日の解説にある方法。多分大抵の環境では他のブラーより早い。…と思う。
遅いブラーは先日の自前バッファを使った方法。判別がつくように移動も加えている。
もっと遅いブラーは自前バッファに拡大処理を加えたもの。フィードバックブラーっぽく。


　そういえばスターオーシャン3。
買うつもりだったんだけど、例のバグ騒動のせいで躊躇っている。
俺のPS2（借り物だけど）はSCPH-10000だし、
致命的なバグが話にあった序盤のやつだけならいいんだけど、他にもある可能性も否定できないしなぁ…。

2003/3/2

　glutInitDisplayMode(GLUT_RGBA)
ではバッファのalphaへの書き込みが有効にならないことに気付いた。
#define GLUT_RGBA GLUT_RGB
ってなってるから以前から疑問に思ってたけど…、これは罠としか思えん。
alphaへの書き込みも有効にするには
glutInitDisplayMode(GLUT_RGB | GLUT_ALPHA)
としないといけない。（GLUT_RGBAもGLUT_RGBも同じなんでどっち使ってもいい）
　どーりで今までGL_DST_ALPHAが常に1になってたわけだよ……。
しかしこれで色んな疑念が晴れたんでまた進展できそうだ。

2003/3/1

　連休になったことだし、ゲーム製作の続きに本腰を入れることに。
とりあえず今日はもっとゲームらしい派手なエフェクトを入れてみようと、OpenGLでの混合処理についていろいろ調査。
あと学校で習った行列変換をクラス化してOpenGLの行列変換関数と入れ替えたり。

　今更ながら
glBlendFunc(GL_SRC_ALPHA, GL_ONE)
でピクセルの加算合成ができることに気づいた。早速爆発エフェクトに使ってみる。
これはDirectXを使ったゲームでよく炎の表現なんかに使われてる合成方法。
ただこれだと合成後の色は明るくなる一方なんで、軽い感じになってしまう。
手っ取り早い改善方法は、炎と煙で別に画像を用意して炎を加算で合成、煙を普通に合成…ってなところだろうか。
後ほどやってみよう。
　ちなみに
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
が普通の合成。
　つうかglLogicOp()とも絡めて色んな組み合わせを試してみたけど、
上記の二つくらいしかまともな結果が出る組み合わせは無かった。
このあたりはDirectXが得意とするところなんだろうなぁ…。

　数珠繋ぎの弾をレーザーらしく見せる手っ取り早そうな方法として思いき、モーションブラーを実装してみる。
OpenGLでブラーと言えばアキュムレーションバッファを使う方法がよく本に載っているけど、
実際に使ってみるとあまりにも重過ぎて使い物にならなかった。
アキュムレーションバッファは元々リアルタイム向けではないようだ。
　つうわけで…glReadPixels()でフロントバッファを自前で用意したバッファに読み込み、alphaを適当に減らして
glDrawPixels()でスワップする直前のバックバッファに合成
（合成は前述のglBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)で）するっつー、
物凄く力技な方法で実装してみた。あっさり成功。
しかし当然のことながらこれも激重。
それでもアキュムレーションバッファ使ったときよりは幾分マシではあるが…、
何かいい方法がありそうではあるんだけど…。

リプレイ保存機能が死んでた不具合の修正も兼ねて、最新版。
そのうちソースの整理してオープンソースにしようか…。

rキー:変更した視点をデフォルトの位置に戻す
dキー:敵弾爆破
bキー:ブラーのオン･オフ

↓スクリーンショット

2003/2

2003/2/28

　課題終わったぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁ！！！！！！
これで晴れて自由の身…。
これから約1ヶ月半の自由時間、やりたい放題できるゼ！！
年明けから色々慌しかったけど、ようやく一息つける…。
しかし…課題のリテイクが出たりしたらやだなぁ…、可能性が無きにしも非ずなところがなんとも…。

2003/2/22

　課題と調べ物の合間にちびっとずつ書き進めていたネットワークモードが一応一通り動いてくれたんで公開。
ネットワーク対応版。
しかしこれ、LANじゃないとまともに遊べる状態にはならんくさいです。
詳細は付属の説明書き参照。

2003/2/15

　課題ラッシュにつき修羅場モード。
しばらく実のある更新は無くなると思われます…。
　ネットワーク経由で2人Playが可能なゲームを作る具体的な方法を学んだんで、
早速歌鶫に組み込もう…、とした矢先に課題ラッシュ。
頼むから勢いを削ぐようなことはせんといてくれ…。

　友人から貰ってまほろまてぃっく（美しい方）全話を一気に見ました。
最後の方の3話を見て鬱になりました。

2003/2/13

　以前の雑記で「shortよりint、floatよりdoubleの方が早い」と書いたけど、
floatとdoubleに関しては一概にそうとも言えないようだ。
最近のコンパイラ+CPUではfloatはfloatのまま扱われることも多いらしい。
　でも資料によってかなり情報がまちまちで、
floatは全て一旦doubleに拡張される、とか
floatは関数の引数になった時だけdoubleに拡張される、とか
floatは全てfloatのまま扱われる、とか
ばらばら過ぎて混乱しまくり。

　百聞は一見にしかず、ということで試しに速度を測ってみることにした。
こんなプログラムを書いてgccで最適化無しでコンパイルし、timeコマンドで時間を測ってみたら…、
両者の違いは0～2%くらいで、場合によっては逆転したりという結果に。
ほぼ同じと見ていいだろう。

次にこんなプログラムを試してみる。
関数を呼ぶ時に型変換が行われるらしい？という情報の確認のためのプログラム。
結果は…、double型がfloat型のほぼ2倍の所要時間になった。
これはメモリアクセス速度の差か…？（float:4Byte, double:8Byteなのでdoubleが所要時間2倍？）

　これ以外にsin関数とsinf関数を繰り返し実行してみたけど、
これは引数のdouble、floatに関係なくsinfを使った方が圧倒的に遅くなった…。

　なんかますます混乱してきた…。floatの方が速い…？
速度が大して変わらないならメモリ消費が少ないfloat一本で通したいんだが…。
もうしばらく調べたり実験したりしてみることにしよう…。

この辺のことに詳しい方いましたらご一報願います…。

2003/2/11

　追尾のアルゴリズムをちょっと改良。
と言ってもそんなに大きな変化は無し。
次回改良時にはショットの数珠繋ぎじゃなくてちゃんとした一筋のレーザーにしたいところ…。

2003/2/10

　エセ力の解放実装。
Cキーか、パッドの1+2または3で撃ち放題。
　相変わらずシステム周りの改良ばっかりで、目立った変更点は解放と形状データを完全に独自のものにしたくらい。
やはりmqoは編集用なんでそのままでは扱いにくい。
↓スクリーンショット


　せっかくの（束の間の）テスト後休み期間なんで、時間があるときにやっときたかったSimCity4を本格的にプレイ中。
今回から警察署や学校に割り当てる費用を個別に設定できるようになったのは嬉しい。
あと3000では殆どの施設に短めな寿命があり、建て替えるのが面倒だった（俺が3000が嫌いな大きな原因の一つ）のが、
4では寿命が無くなってたり、あまり気にしなくてもいいくらい長くなってたりするのもありがたい。
そして今回は近隣都市に接続することで受けられる恩恵があるのが面白い。
例えば普通はある程度街が発展してからでないと出てこないハイテク産業が、
近隣都市に接続することで最初から出てきたりする。

　しかし…、3000の時もそうだったけど、自由度の低さを感じる。
例えば住宅地区は学校＆病院の完備、低い公害、職場への交通の確保等等、
かなりの条件を整えてやらないと全然成長しないし。
地区はRCIバーに沿ったバランスで設置しないと廃墟だらけになってしまう。（これはシリーズ通してそうなんだけど…）
地区の設置の時に街路が自動的に敷かれるのも余計なお世話な気がしなくも無い。
あと街の変化が目まぐるしいので、あまり画面から目を離せない。
　非常に現実的ではあるけど、ちょっと自由度が低すぎるんじゃないかというか、
これじゃ誰がやっても同じような街にしかならないんじゃないかというか…。

　俺がこのシリーズで2000が一番好きなのは、
結構テキトーにやってもそれなりに発展してくれる難度の低さというか自由度の高さがあったからで、
色々実験したり極端な街を作ったりして楽しんでいた。
あとクリア後のご褒美的存在のアルコロジーがなかなか楽しかった気がする。
マップを全部ラウンチアルコロジーで埋めた2000万人都市は壮観だった。
　4はせっかくマップ単位の開発ができて、近隣都市からの影響なんて概念があるんだから、
こっちのマップは住宅街、あっちのマップはハイテク工業地帯、そっちのマップは農村…、
というような自由なやり方が許されるようにしたら格段に楽しくなりそうな気がするんだけど…。
4も結構遊べそうだけど、俺は2000の方が好きかなぁ…。

　今のところ中型マップで92000人が最高記録。
100000人に届きそうで届かない…。
大型マップなら余裕で行けるだろうけど、
中型マップでも町が大きくなってくるとゲームの進行がノロくなったりたまに止まったりするんで怖くてやる気が…。

2003/2/7

　最近知った俺には結構意外だったCの事実。
char、shortよりもintで計算した方が速い。

　整数の計算は内部では全部intでやっているらしく、
charやshortは内部で一度intに拡張する処理を行ってから計算する。
そして大抵の場合、計算よりもその変換作業の方が時間がかかる。
状況によっては実行速度に5倍くらいの差が出ることもあるそうな。

　同様の理由により、floatよりもdoubleの方が速い。
（floatは一旦doubleに拡張される）
よって計算に使う変数はintとdoubleの2つだけにするのが理想的なようだ。
shortやfloatは最近のパソコンではどうやらメモリ節約のため以外の存在意義は無いらしい。

　…つうわけでそそくさとshortやfloatだらけのコードをintとdoubleを使ったものに書き換え。
メモリはできるだけ節約しておくに越したことはないだろうっつー、
なんとも貧乏くさいというか日本人的な考え方で今までshortやfloatを頻繁に使ってたけど、
これはどっちかと言うと悪い方向に働いていたようだ。

　つうかOpenGLの命令の一部にはfloatじゃないといけないのもいくつかあって、
そのせいでdoubleとfloatが混在するはめになってすっきりしない。
特にglInterleavedArraysにはdoubleの配列を指定できないってなんでやねん。

2003/2/6

　しばらくほったらかしになってましたが、ようやく試験が（色んな意味で）終わったのでぼちぼち再開したいところです。
しかし落とした教科の数によっては大量の追加課題に喘ぎ苦しむ羽目になって本格的な休止状態になる可能性も…。
俺は無事に2年次に上がれるのであろうか…。

　遅くなりましたが、長月さん先日はお忙しい中どうもでした。
今回はあまり話せませんでしたが…、つうかお互いゲームばっかやってましたが（笑、また機会があれば。
女詫斑、やはりRisingForceが一番気に入ってます。


　ケツィ。
適度に稼いで5面突入時くらいまでには2回目エクステンドできるようになり、
調子がいいときは5ボスまでは行けるようになったけど、5面道中後半をなんとかしないとクリアには届きそうに無し。
つうか5面後半は別次元の難度。なんだか2周目に迷い込んだような気分になります。
特に逆スクロール地帯の大型機ラッシュ、ノーミスノーボムで切り抜けられる気が微塵もしねーのですが…。
　5面中ボス、未だにたまに殺されるけど、あのトリッキーな弾幕は見てても避けてても楽しい…っつーか笑えます。
あのでかくてごつい威圧的な姿といい、弾幕のひねくれた変則っぷりといい…、
ケツイというゲームを象徴する敵と言っても過言では無いでしょう。
「踊る弾幕くん」と俺命名。

　RedHatを8.0にアップグレード。
…したらXが起動しなくなった。
Xの起動ログ（/var/log/XFree86.0.log）を見てみるとNVIDIA_kernelのモジュールの初期化でエラーが起きているらしい。
とりあえず最新のRedHat8用NVIDIA_kernelとNVIDIA_GLXを落としてきてインストール。
何故かエラーでnvidia.oを組み込めなかったんでこれは手動で組み込み。
それでもXは起動せず、エラー内容も全く同じ。つうかインストールに失敗するって時点でなんか怪しいが…。
　しょうがないのでNVIDIA関連ドライバをアンインストール（rpm -e NVIDIA_kernel NVIDIA_GLX）して、
/etc/X11/XF86Configの内容も元に戻し、デフォルトnvドライバで起動。
そしたらなんとかX復活。
しかしこれだとビデオカードの力を殆ど得られないんで、OpenGLを使ったプログラムなんかは激重。
歌鶫なんて秒間5フレームも出てない気がする。
無くなって初めてわかるビデオカードの力の偉大さ…。
　とりあえず解決方法がわかるまでこのまま使うことに。
元々ゲーム用途は考えてないし、自作プログラムの動作確認は一応この状態でもできるし。
7.3に戻せば解決するけど、8.0になって色々改良されてる部分も多いんで（特に日本語表示）できれば戻したくない現状…。

2003/1

2003/1/28

　東方妖々夢の体験版がこれまためっちゃ楽しい…。
ケツイ＋妖々夢＋PS2大往生で今年上旬はSTGに餓える心配はなさそう。
そういえば去年の今ごろは斑鳩に熱中してたなぁ…。

　ザコ敵の管理もできるようになったんで適当に道中を作ってみる。
ついでにケツイに備えて動体視力の鍛錬用にボスの弾幕を前回より二周りほど難しいものに。
…ちと難しくしすぎたかも。
↓スクリーンショット



　そういえば、このゲームをいくつかの環境で試してみたところ、
俺のメインマシン（PenIII1G+GeForce4）では快適、
サブマシン（PenIII600M+MilleniumG400）では激重、
実家のマシン（PenIV1.7G＋GeForce2）では重、
学校のマシン（Athlon2G＋GeForce3）では快適、
という結果になっている。
　どうやらCPUよりグラフィックボードの影響が大きいようだ。
快適に動く最低動作環境はPenIII以上のGeForce3以上ってところだろうか。
これは遊べる人を結構選びそう…、DirectXにしたら幾分マシになるかもしれないけど…。

2003/1/26

　ケツイむっちゃ面白いです。
正直大往生がいまいち肌に合わなかったんであんま期待してなかったけど、
いい意味で思いっっきり裏切られた気分。
久々に燃えられそうですヨ。
　今日は3回目のプレイで5面行けたけど、それ以後は4面止まりになってしまった…。
とりあえずボスが全然安定しないのをなんとかしていくのが当面の目標か。
　つうか結構上手い人が1周目ラスボスっぽい敵まで行ってるのを見れたけど、5面は他の面とは比べ物にならん難度。
5面に関しては大往生よりケツイの方がキツイっぽい。
5面中ボスの弾幕は最初見たとき「弾が踊ってる！？」と思ってしまったほどトリッキーで印象的ですた。
5面の背景なんかエスプっぽかったなぁ…。

防備録も兼ねた攻略メモ：
･2ボス
　赤ワインダーの後に自機を狙ってくる青針弾、
　画面最下部からちょっと上のあたりで構え、青弾が動き始めたら下の隙間から横に抜けるとラクチン。
･3面道中
　自機が移動速度高＆直進弾の方の場合、大型機と中ボス以外ではロックショットは使わない。
　（ロックに時間がかかって破壊が遅れ、逆に辛くなる。これはこの面に限った話じゃないかもしれない。
　　つうか一瞬でロックが終わる時とやたら時間がかかる時があるけど、法則性がわからず…）
･3面中ボスの巨大戦艦
　ノーボム＋パーツ全破壊で1UPが出る。
　開幕直後の周りのザコヘリに気を取られてると前部の砲台を逃してしまうので、意識的に砲台を狙っていく。
･3面ボス
　左右どっちかのパーツを真っ先にぶっ壊しておくと回避が楽になる。
　発狂パターンの青弾＋曲がる赤弾は、
　自機を青弾すれすれに寄せて移動していれば当たらない。赤弾は見ないでOK。
･4面道中前半
　できるだけ画面上部で左右に切り返すように動く。
　黒いブーメランみたいな敵の編隊は最優先で破壊。
･4ボス
　上にビットを飛ばして下からせり上がってくるところは、
　画面上部に移動して一旦ロックを外してビットにロックしなおし、破壊する。そうしないと詰むっぽ。
　ボス本体には衝突判定ナシ。

　新大久保駅付近のαステーションと、西武新宿駅付近のSIGMAで50円で稼動ちう。
SIGMAは音がでかくていい感じ。ここを根城にしよう…。

2003/1/23

　予定通りケツイが稼動開始したけど、
2chのケツイスレで「難しすぎ、敵硬すぎ」と言われまくってるのを見て心配になってきた…。
12月頭のロケテのときはすんなり4面まで行けて大往生よりは幾分簡単そうな印象だったけど、
製品版になる時にまた難しくなったんだろーか…。
つうか今回も2周目あるのか…。
とりあえず今週末はゲーセンへ行ってみよう。
　ストーリーにある「EVAC Industry」がCAVEを逆にしただけと知って爆笑。

　ゲーム作る合間にランレングス圧縮（RLE）をかけたTGAファイルの読み込み＆書き込みをやってみました。
ランレングス圧縮なんて固有名詞を使うと難しそうに思えるけど、
これは連続した同じデータの並びを一つのデータと繰り返す回数に置き換えるという最も簡単な圧縮アルゴリズム。
例えば「AAAAABBBCCCC」という文字列なら「5A3B4C」という具合に置き換える。
　TGAファイルの場合、色情報データ（BGRAの順）の前に繰り返す回数を示す1Byteの数値が入っていて、
これが0x80未満ならn+1個の不揃いなデータが並び（nBGRABGRABGRA...）、
0x80以上なら同じデータがn-0x79個続くようになっているようだ。
実際に圧縮TGAを読み込む場合、こんな感じのループを書く。
　意外と単純なんだけど、この仕組みを解析するためにバイナリエディタで延々とデータと睨めっこするのはしんどかった…。
画像データや3D形状データのファイルフォーマットの資料って公開されてないんだろうか…？

2003/1/19

　昨日は久々に秋葉原へ行き、CimSity4とAgeOfMythologyと、
以前から気になっていたLinux搭載Zaurus（SL-C700）を思い切って購入。
　帰ってきて早速LinuxZaurusをLANに繋いで、TelnetやFTPでWindowsマシンやLinuxマシンと連動させたり、
ipkgで配布されてるgccでLinuxZaurus上でCプログラムをコンパイルしてみたり、
ついでだから今まで放置していたsambaなどのLinuxのネットワークの設定をやってみたり…、
…とやってるうちにあっという間に終末が過ぎ去ってしまった。
なんか時間の割にあんま進んでないような気もするけど、勉強になったからよしとしておこう…。
　LinuxZaurus、かなり遊べそう。

　SimCity4、チュートリアルだけ一通りやってみたけど、3000より面白そうな印象。
しかし財政を黒字に持っていくのが厳しくて難しい。
推奨スペックPen4 1.4G以上ってのは驚いたけどPenIII1Gな俺の環境でも現在スイスイ動いてるし、
これは時間が空いたときに猿のようにヤりまくりたいところ。
ちなみに俺内部でのこのシリーズのハマリ指数：（SimEarth>）2000>初代>3000
　そしてAgeOfMythology、衝動的に買ってしまったはいいが周囲に対戦相手になってくれそうな人がいないのが…。

2003/1/17

　いつまでも冬休みの脱力感を引きずってないでそろそろ渇を入れねば…。
後期は殆ど学校の授業出てなかったんで、出席日数が足りてるかどうか危うかったり、
未提出課題がある教科があったり、そもそも課題が出ていたのか出ていなかったのかすら分からない教科なんかもあって、
新年早々WARNINGでNO REFUGEなわけで…。
CとOpenGLは自信あるんだけどナァ…。

　いつの間にやら30000ヒットオーバー。ありがとうございます。
これまでも、恐らくこれからもどうしようもなくマイペースなのはあまり変わらないと思いますが、
気に入っていただければご贔屓に。
やっぱり反響があるとやる気も沸くってもんですヨ。

2003/1/12

　歌鶫大改良。
細かい変更点は数え切れないほどあるけど、大きなものは
ショットを撃てるようにした、ゲージ表示、フルスクリーン対応、描画速度がかなり高速に、緋蜂っぽい弾幕追加、
と言ったところ。
　…とは言え、攻撃パターンなどは相変わらずあまり変化無し。
しかしようやくゲームシステムの方向性が固まってきたんで、
もうすぐグラフィックや行動パターンの設定に集中できるようになりそう。
↓スクリーンショット

2003/1/8

　早めに帰ってくる予定だったのが帰省ラッシュで飛行機もバスも満席で動けず、今日になってようやく帰還。
もう学校始まっとるがな…。

　しかし去年は色々と変化が大きかった年だった。
去年の4月まで無職透明ダメ人間だったのが学生に舞い戻り、現在住んでいる寮に移住。
夏まではかなりダラダラした学校生活を送っていたのが秋頃急変、
C言語でポインタを習い始めたあたりから急にプログラムが楽しくなりだし、
学校サボって家でプログラムを書きまくる日が続く。
そしてゲームを作りたいという以前からの目標を達成すべく日々精進、現在に至る。

　…実はプログラムは中学の頃N88BASICを少し学び、
それからC言語に移行しようとしたけど挫折した、という経験がある。
その当時C言語を学ぶいい方法を知らなかったんで、
とりあえずVisualC++とそれに関する本を買って学ぼうとしていたけど、
今思えばそれが大きな間違いだったように思う。
VisualC++の本が最初に扱うのは大抵WinAPIとMFCを絡めた内容で、
これにはかなり複雑なクラスや必要以上に多種なデータ型がわんさか出てきて、
入門者にはあまりに敷居が高すぎる。
　今の学校のLinuxという珍しい環境に触れて、C言語の基礎の基礎から地道に学んで、OpenGLで図形を描画して…、
というのはかなり刺激的な、いい授業環境なんじゃないかと思う。
ともあれ、きっかけを与えてくれた日本電子とOpenGLというイカスAPIに感謝。
今年もプログラムの勉強が主な日々になりそうです。

　つうわけで、明けましておめでとうございました。