POINT BLANK な日々の記録

2001年6月（前半）

早いもので、

　もう６月か。
　いい加減、ダラダラするのにも飽きた。　早く働きたいっス。

　

　

開発状況（通信管理）

　おーおーおー、ナルホド。
　なんとなく解った＞ＤｉｒｅｃｔＰｌａｙ８

　いままで自前でスレッド切って処理していた受信部分の処理がコールバック
　化されて、非常にお手軽になっているねぇ。
　最初からそうしろよな。
　思えば２年前。　ＷａｉｔＦｏｒＳｉｎｇｌｅＯｂｊｅｃｔ の意味が解らず（何故だ？）に、
　スレッドをガンガン回して受信ポーリングしてたっけ。（かなり間抜け）
　３度目の正直で、今度こそ「使える」ライブラリを作るぞ、と。

　ピアツーピア、クライアント、サーバ・・・各々が異なるインタフェイスに分割
　されたので、ちょっと「厚め」のラッパーにしようかにゃあ。
　ついでなので、ヴォイスも統合っと。　・・・マイクを買わねば。
　ていうか、まずはネットワークカードを挿さねば。（ぉ

　てことで、ＤｉｒｅｃｔＰｌａｙラッパーと通信管理クラスの骨組みを作ったところで
　時間切れ。
　　↓

　や、やきにく・・・（涙）

　食った。　もちろん奢りで。
　えむっちとＤＡＩちゃんが大阪に一時帰還していたので、せっかくだからと３人で。
　自宅近所の焼肉屋（行くのは初めてだが）で、嬉しい「食べ放題」。
　意外・・・と言うと失礼だが、大変美味しかった。
　ごちそうさま、えむっち！

　いきなり沢山食べて胃がビックリしたのか、ひつこいしゃっくりに悩まされるも、
　カラオケ屋で「侍ジャイアンツ」を唄ったら何時の間にか止まっていたぜ。

おいおい

　相変わらず暇なので、
　熊本市内小学校校区図
　を見ながら会社周辺の様子をいろいろと復習。
　次は恐らく鉄道を利用する事になるような気がするし。

　・・・いや、地図がコレしかなかったんだってば。
　まぁ、コレを選んでくれたのはいとうくりえさんなのだか、彼なりに気を
　遣ってくれたんだろうなぁ・・・。

　こゆこと書くから誤解されるんだな、きっと。（苦笑）

　

ＯＮＥ ＨＡＮＤＲＥＤ ＹＥＮ ＭＡＮ

　食糧の買い置きが底をついたので、例によって１００円ショップへ。
　５００ｇスパゲティＸ３、レトルトのパスタソース各種Ｘ５、１㍑入りの紙パック
　コーヒーとかＸ３、クリームパンＸ１、チキンラーメンＸ２。
　しめて１４７０円（税込）ナリ。

　

　

開発状況（通信管理）

　ＳＤＫサンプルの”ＡｄｒｒｅｓｓＯｖｅｒｒｉｄｅ”からダイアログ関係の処理を
　ひっこ抜いてイタダキ。
　とりあえず起動時に接続用のダイアログが出るようにしてみた。
　「出る」だけで、接続はできない（笑）

　　−−−−−−−−

　うむー。
　このダイアログの定義（？）なんだけど、ライブラリ側で完全に隠蔽しよう
　と思ったら、ＤＬＬにするしか無いのだろうか・・・？

　コード上で全てを記述してやれば良さそうなものだが・・・
　ウィンドウクラス？・・・よくわかんない。（ぉ

　まぁ、ダイアログ自体がターゲットアプリによって変ってくるだろうから、
　プロジェクトのリソースとして持たせるのが正解なんだろな。
　しかし・・・そーすると接続設定関係のベタなコードが露出してしまって
　イヤなんだよなぁ。

　　−−−−−−−−

　昨日もちょっと書いたように、ＤｉｒｅｃｔＰｌａｙ８では、受信したメッセージの処理
　はコールバック関数で行なうようになっている。
　従って、Ｒｅｃｅｉｖｅ というメソッドは廃止されて消えてしまった。

　ＤｉｒｅｃｔＰｌａｙ がメッセージを受信すると、予め登録しておいたコールバック
　関数（もちろんこれは自分で作成する）が呼び出される。
　この中でメッセージのタイプごとに振り分けをして、適切な処理をするのだ。
　ま、ウィンドウのメッセージハンドラみたいなものだ。

　前バージョン（ＤｉｒｅｃｔＰｌａｙ４だっけ？）では自前でスレッドを用意してたっけ。

　受信コールバック関数はＤｉｒｅｃｔＰｌａｙラッパーの中に隠蔽。
　アプリ作成者の方では、個々のメッセージ毎にハンドラを作成して登録する
　ようにしてみた。　ＭＦＣのアレみたいな感じ。

　　−−−−−−−−

　次にやる事は・・・
　　・ ダイアログの処理を真面目に作り込む。
　　・ プレイヤーの管理クラスを作成。
　　・ ＰＣにネットワークカードを挿す。　（ケース開けるのが面倒なんだよね。）
　　・ セッション生成／接続。
　　・ 相互の通信確立まで確認。
　　　（最低限必要なシステムメッセージ用ハンドラを作成）

　と、ここまでで一区切りかな。
　アダプタとサービスプロバイダの列挙も必要だなぁ・・・コピペで行けるか？

開発状況（サウンド管理）

　まだ影も形も無いっス。
　ひとまず落ち着いて、ＤｉｒｅｃｔＸ Ａｕｄｉｏ のマニュアルを熟読する。

　そーかー、ＤｉｒｅｃｔＳｏｕｎｄ と ＤｉｒｅｃｔＭｕｓｉｃ は統合されたのかー。
　旧バージョン（６しか知らない）からかなり変ってるみたい。
　と言っても、ＤｉｒｅｃｔＭｕｓｉｃ は一度も使った事ないので関係無し（笑）。
　ＤｉｒｅｃｔＳｏｕｎｄ の方は薄いラッパーを作ってあったが、廃棄となる模様。

　音楽も効果音も ＤｉｒｅｃｔＭｕｓｉｃ だけで面倒を見てくれるようで宜しい。
　ＤｉｒｅｃｔＳｏｕｎｄ のインタフェースは使う事は無さそうだ。

　さぁ、爽やかな（？）気分で最初から作ろう。

　　−−−−−−−−

　仕組みは大体解った。　やはり、最初からそう作っとけ！って感じ。
　（ＤｉｒｅｃｔＰｌａｙに比べ）シンプルな上に手続きも少ないので、けっこう楽かも。

　ところで、
　ＤｉｒｅｃｔＰｌａｙＶｏｉｃｅ と ＤｉｒｅｃｔＳｏｕｎｄ の関係がよく分からんのだが。

　

我主食

　さ、さすがに昼夜２食とも続けてパスタというのはちょっと・・・。
　まぁ１日１食しか食えないのに比べたらマシと言えるのではあるが。
　せめてもの抵抗で、昼はホワイトソースで、夜はミートソースにした。

　

"ＭＯＯＮＬＩＧＨＴ　ＬＡＭＢＬＥＲ"

　えーと、最初の「バブルガム・クライシス」のシリーズ５作目っス。
　前作”ＲＥＶＥＮＧＥ　ＲＯＡＤ”と同様一話完結になっていて、またもや
　ナイトセイバーズは脇役扱い。

　最初に言っとくケド、これはかなりハズレだったし。
　監督は当時ロボットアニメ等で人気のあった大張なんとかってアニメータの人。
　（これが敗因？）

　衛星軌道上の工場（？）から逃亡した慰安用ブーマ（人造人間。セクサロイド？）
　が地球に降り立ち、自分達の生命（？）を維持する為に夜な夜な人間を襲う。
　血液を抜き取るのだ。吸血鬼？
　で、秘密裏な処分を目論むゲノム社とナイトセイバーズの面々とが追いかけると。

　・プロローグでブーマ達が脱出するシーンだが、園田風キャラのオンパレードで
　　さながら「ガルフォース」と見紛おうかといった所だ。
　　２人（？）を逃がす為に他の全員が犠牲になるあたりの演出とかも。
　　なんだかすごくバブルガムっぽく無い。
　　それから「ドーベルマン」とかいう戦闘用ブーマのデザインも世界観が違う。

　・ブーマ達が逃亡の際に奪った（？）秘密兵器「バトルムーバーＤＤ」だが、
　　これもデザインの世界観が違い過ぎる・・・。
　　スケール感というか・・・ゼータガンダムのデザインディテールでボトムズの
　　メカを作っても違和感ありあり・・・ってのと似た感じ。　わかって（笑）。

　　存在の必然性が薄い。　戦闘シーンを描く為だけに登場している事を観客に
　　見透かされてしまっては（ホントにそうだとしても）負けだとおもう。

　・個々の見せ場を描く事「だけ」に注力されてるみたいで、登場人物の目的や
　　行動の必然性が非常に希薄だった。
　　ていうか、ストーリーもあまり印象に残っていない。
　　あの女の子達は、いったい何がしたかったのだろう。

　”ＲＥＶＥＮＧＥ　ＲＯＡＤ”のおまけに収録されていた予告編を見る限りでは
　すっごく面白そうで期待していたのだけどなぁ・・・。

　

　

開発状況（タスク管理）

　プレイヤーの管理下にあるタスク・・・すなわち「マイキャラ」を管理する
　ようにした。　基本的には前バージョンから変らず。
　マイキャラはタスクの登録時にフラグで指定する。
　当然ゲーム中にマイキャラは唯一つしか存在できない・・・はずなのだが、
　今は手抜きでチェックしていない。
　マイキャラの交代も未サポート。

　　−−−−−−−−

　マイキャラを作成した関係で、タスクの「入力処理ハンドラ」を作成。

　入力デバイスの状態は、入力処理用スレッドの中でポーリングされる。
　その後に同スレッド中から、マイキャラの「入力処理ハンドラ」が呼ばれる。

　「入力処理ハンドラ」の中では、直前に読み取られた入力デバイスの情報
　に従って内部コマンドを生成し、コマンドバッファ・オブジェクトにストアする。
　内部コマンドについては自タスクの中だけの約束事なので、好きに決めて
　やればいい。

　んで、タスク側の更新処理では、この「コマンドバッファ」を参照して状態の
　更新を行なうのだ。　ここで入力デバイスの状態を参照するのは禁止。

　非常に面倒なのだが、これには一応の理由がある。
　　・ 通信データの量を減らす。
　　・ 抽象化レイヤを挟む事で、思考ルーチン作成の便を図る。
　ちょっと弱いか・・・。
　「思考ルーチン」と「入力処理ハンドラ」を動的に差し替える事で、簡単に
　どのキャラもマイキャラに出来たりする・・・予定。

　直感的で「行き当たりバッタリ」な作成感覚には適さない。
　小さなデモやテストプログラム程度ならそれでも何とかなるけどね。
　タスク・オブジェクトを作成する時は、キチンと「設計」をした上でコードを
　書くようにしてくれ。（俺モナー）

　

開発状況（グラフィック管理）

　メッシュクラスに”ＣｒｅａｔｅＢｏｘ”メソッドを追加。
　Ｄ３ＤＸのヘルパー関数を呼んでるだけなんでらくちん。
　別にティーポットでも良かったんだけど。
　一応、「豆腐人間」を作る為の布石。

　　−−−−−−−−

　うむむー。
　リサイズ後（デバイスの再作成後）に上記のメッシュが描画されなくなって
　しまう・・・。　なんでだろう？
　従来通りに Ｘファイルからロードした奴は問題無いのに。

　コードを見る限り、間違いなくローカルメモリ（ＶＲＡＭ）上に作成されている
　はずなのにぃ・・・。　そもそもコードの殆どが共通なんだから、メッシュ
　そのものに何らかの原因（理由）があるという事なのかのかのか。

　　−−−−−−−−

　はいはいはい、原因はレンダリングステートでした。
　デバイス再作成後にはレンダリングステート管理を初期化し直す必要が
　あったのだが、面倒で直してなかった。（ぉ

　あ、デバイスの再作成ってのは、正確には「デバイスのリセット」ね。

　

開発状況（通信管理）

　はふ。
　前バージョンの通信管理では、自前メッセージキューの状態を監視しながら
　送信やメインループの処理間隔を調整していたのだが、そういうことは
　ＤｉｒｅｃｔＰｌａｙがやってくれるらしい。
　とはいえ、やはり相手の受信処理速度を追い越さないように、送信間隔は
　調整してやる必要があるみたいだなぁ。

　　−−−−−−−−

　結局、今日は何もせず。

よしよし

　お昼頃風呂に（優雅なもんだ）入っていたら、熊本の社長から電話が。
　こないだ決めてきたマンションの審査が通ったとの事。やった。
　入居予定日を先に決めなければならないそうで、とりあえず２１日に決定。
　さぁ、引越し屋にコンタクトだ。
　具体的な見積もりを依頼しよう。

　ぼちぼち片付け始めてはいるのだが・・・箱が足りんなぁ。
　また近所でもらってこようか。

　

変化に乏しい食生活

　今日もお昼はパスタ。
　ソースはナポリタンにしてみました。　ていうか、もうなんでもいいよ・・・。

　さて、東京都にお住まいのＥ田さん（仮名、２９歳独身）他お二方より、
　「お米を買って炊いた方が経済的なのでは？」
　というご意見を頂いているのだが・・・。
　炊飯器が無いので鍋で炊かねばならず、非常に面倒臭いのだ。（ぉ
　というワケで、引っ越してから炊飯器を買います。

　　−−−−−−−−

　１００円ショップに飲み物を買いにいく。
　紙パックの１リッターで１００円。　種類が少ないのはヤムナシ。
　う〜ん、相変わらず賞味期限がクリティカルだなぁ。

　ついでに「そうめん」を二束買った。
　暑い日を狙って風流に食うぞ。

　

　

開発状況（通信管理）

　いい加減埒が開かないので、面倒を我慢してネットワークカードを挿した。
　ドライバのインストール等をはしょったが、ＰｎＰでうまく動いてるみたい。

　　−−−−−−−−

　「コマンドキュー」クラスを作成。

　「コマンド」クラスの配列によるリングバッファ。
　格納と取出しは異なるスレッド間で非同期に処理されるので、クリティカル
　セクションで排他制御してるです。

　格納／取出しの際は、モロにデータをコピーしているので効率悪し。
　が、コピーしないでキューを長時間占有するよりはマシなのか。

　　−−−−−−−−

　「プレイヤー管理リスト」クラスを作成。

　リストと言いつつも、実装は配列なのであった。　がはははは。

アンデルセン萌え

　暇なので「ヘルシング」を最初から読み直してみた。
　おぉー、そーか。
　アンデルセン神父は「ただの」人間ではなかったのか。なるへそ。
　しかも、あの銃剣は四次元ポッケにしまっていたのか。なーる。
　これで得心がいったぜ。

　それはともかく、眼鏡をかけたキャラが多いね。
　婦警以外の主要キャラはみんな眼鏡？
　えむっちにオススメという事で。（ぉ

　　−−−−−−−−

　そーいえば、「狼男を近代兵器で武装させる」というネタを考えた事が
　あったなぁ・・・。　１０年くらい前に、ＴＲＰＧのシナリオで。
　唯でさえタフなのに、有り余る体力にモノを言わせて強力なボディアーマー
　を着てんの。
　ちなみに「シルバー・チップ」の弾頭は銀じゃなくてアルミなので、全然
　効果無いよ。念の為。
　どうやって闘うのかって？
　そりゃあ勿論、対戦車ライフルを担いで立ち向かうのさ。

　　−−−−−−−−

　吸血鬼を見分ける特徴として、「日光、十字架、にんにくを嫌う」とか、
　「鏡に姿が映らない」といったモノがあるよね。

　さて、Ｂ級映画「キャプテン・クロノス　バンパイア・ハンター」にて描かれた
　判別法は中々ユニークだ。
　　・ 吸血鬼が近づくと、花が萎れる。
　　・ 吸血鬼が近づくと、死んだカエルが生き返る。
　うーーむ。
　これって一般的に認知されたものなのだろうか？
　この映画だけの創作？

　

印象に残る台詞

　ああッ
　俺も人狼じゃなくて
　人娘だったなら！

引越し準備

　熊本の会社から連絡有り。
　マンションの契約書を送るので、必要事項記入・捺印の上返送せよとの事。
　印鑑証明及び住民票も必要なのだそうだ。　これは今から取ってこよう。

　さて、身分証明として運転免許のコピーが要るそうなのだが・・・持ってない。
　で、不動産屋に問い合わせてもらった所、証明写真でＯＫだそうでひと安心。
　ちょうどハーワークに提出する為に撮った写真が余ってるし。しめしめ。
　・・・！
　この写真は！　頭を剃る前のものではないか！
　これで本人と認めてもらえるだろうか？（笑）

　　−−−−−−−−

　生憎の雨模様だが、早速区役所に印鑑証明と住民票を取りに行ってきた。
　こういう日の方がすいてるんだな。

　帰りに銀行に寄る。　失業保険の給付金が振り込まれてるハズだ。
　・・・が、
　何だか微妙に多い。
　ダレかボクの口座にお金を振り込みましたか？（ぉ

　

ヤングチャンピオン．エア

　とかいうのが有ったので買ってきた。
　ヤングチャンピオンの増刊らしい。　生意気にも平綴じだ。
　もちろん目当ては「エイリアン９」の書き下ろしで、他はどーでもいい。

　が！

　この「花右京メイド隊」とかいう漫画を描いている「もりしげ」って人は、
　あの、ペドフィリア御用達（ぉぃぉぃ）超絶鬼畜系ロリロリエロリ漫画家の
　「もりしげ」なのだろうか？
　そういえば、確かに「眼」の描き方に面影が・・・。

　うーん、最近見かけないと思ったら、健全路線に宗旨変えしてたのか。
　しかもコミックスが既に３巻まで出ているらしい。　これは迂闊。
　しかもしかも、あまつさえＴＶアニメ化されているというではないか。
　世も末じゃのう（？）

　あんまりメジャーになると、過去の作品が「無かった事」になって抹殺
　されてしまう恐れがある。　注意めされよ御同輩。（ぉ

　

　

開発状況（通信管理）

　いろいろとゴニョゴニョやって、あっさりとホスト・セッションが立ち上がった。
　あ〜らくちん。

　ＳＤＫサンプルから接続（ＧＵＩＤを同じにしといた）を試みたら、うまい事接続
　できたみたい。
　後は、自分の方から既存セッションに接続するケースの処理だ。

　　−−−−−−−−

　ところで、ＳＤＫサンプルの”ＡｄｄｒｅｓｓＯｖｅｒｒｉｄｅ”って、
　「同一ゲームのセッションが複数存在する場合、接続先を選択する」
　という処理がゴッソリ抜けてるんだね。
　最初に列挙されたホスト・セッションに無条件に接続に行ってるし。

　まぁ自分で処理しろという事なのか。
　確かにその為の「オーバーライド」ではある。

　　−−−−−−−−

　うきゅ〜
　ゴリゴリ直して、なんとか「一般プレイヤーとして、ホストプレイヤーに接続」
　が出来るようになった。
　各メッセージハンドラも正常に呼び出されているようだ。

　通信管理クラスの実装は、吐き気をもよおす位にグチャっている・・・。
　接続ダイアログの処理をライブラリ内部に隠蔽したいんだけどなぁ。
　（まだ言ってる）

　　−−−−−−−−

　よっしゃよっしゃ。
　接続に伴うプレイヤー管理情報の登録／削除の動作を確認。

　　−−−−−−−−

　データ受信
　　↓
　該当するプレイヤー情報のコマンドキューに格納
　　↓
　キューよりコマンドを取り出して更新処理

　・・・までの動作確認完了。

　昨日「雰囲気で」作った「プレイヤー管理」と「コマンドキュー」は所期の
　動作をしているようだ。　やるじゃん。（ぉ

　　−−−−−−−−

　次はコマンドの送信処理を真面目に作ろう。
　「２フレームに１回送信」てのを試してみようか。

　それからいよいよ本題の「同期機構」の整備だ。
　まぁ単なるカウンタなんですけど。

　今日は（ダラダラしてる割には）随分と進んだので、続きは明日。

メシ

　いちいち書くまでも無く、デフォルトでパスタ。
　今日のソースは「あさりコンソメ」。　あっさりではなく、貝のアサリだ。
　わりとお気に入りなのだが、インターバルを長めに取らないとすぐに
　飽きてしまいそうではある。　肉入ってないし。

　

家賃払う（断腸）

　はぁ、１ヶ月遅れで５月分の家賃を払ったぜ。

　残る６月分は退出までの日数割りになる。
　これは次（今月末）の失業保険給付金で賄えるであろう。

　今のペースを維持すれば、食事とタバコに事欠くこともあるまい。
　やれやれ、何とかなりそうだ。

　　−−−−−−−−

　組事務所に顔を出し、図々しくも勝手にパソコンを触る。
　が、のんびりとあちこち見て回れるような雰囲気では無かったので、
　自分の掲示板だけＦＤに保存した。

　ついでに今週のサンデーとマガジンを貰って帰る。

　　−−−−−−−−

　宅配便にて、転居先マンションの契約書を受領。

　はふぅ。　敷金が・・・。
　せっかくだから、もちっと安い物件にすれば良かったかなぁ。
　会社で立て替えてもらえる事になっているのだが、当然返済する必要が
　ある訳で、これは結構痛い出費かも。
　まぁ、頑張って稼ごう。　倒れるなら前のめりだ（？）

　

　

おおぅ！？

　うちの掲示板に、知らない人の書き込みが！　わーい。
　１年半ぶり位ではないだろうか。　これは快挙だ。

　最近は意識してＵＲＬを晒さないようにしていたのだが・・・いったい
　どういうルートで辿り付いたのだろうか？　気になる。
　カウンタを見る限り、「煮ちゃんねる」で晒されてるという事はないだろう。
　・・・ないよね？　ね？

　”ＤｉｒｅｃｔＸ”とかをキーワードに検索して見つけた（可能性高し）のなら、
　ゴメンナサイ。　約に立つような事は書いてありません。
　でも仲良くしてください。

　　−−−−−−−−

　うーむ。　もっとマメに掲示板をチェックしないといかんなぁ。

　ところでnightmare君、

　＞ってことで、今日もデスクでレイのアレと戯れておりまする。

　「レイのアレ」というのは例の「綾波育成ゲー」の事でしょうか？　　
　「レイのアレ」はどーでしたか？
　「レイのアレ」の具合は良かったかね？（ぉ

　

　

開発状況（タスク管理）

　タイトル画面、デモ、メインメニウ、ゲーム本編・・・などなど、画面遷移の
　処理を作らねばならん。
　勿論ターゲット毎にその構成は変ってくるのだが、アウトラインというか
　基本形というか、作り方の見本を示さねばならない。
　末端のコーダーの自由度を徹底的に奪うのだ。（ぉ

　　−−−−−−−−

　やっぱり個々のモードをタスク・オブジェクトとして作る事になる。かな？

　入力に対する応答が必要なので、便宜上「マイキャラ」という事になる。
　ちなみにこれまで「マイキャラ」と呼んでいたものは、ゲーム本編中で
　プレイヤーが操作するオブジェクトの事だ。

　全てのモードのタスクは最初に生成してしまおう。
　画面モードが遷移する時は、自分をインアクティブにしてから、遷移先に
　アクティブ化のシグナルを送る・・・と。
　で、ここで問題になるのは、「マイキャラ権の委譲」だ。判ってたけど。

　「マイキャラ権」を所有する唯ひとつのタスクのみが、入力デバイスから
　の情報にアクセスできる。
　んで、「現在は誰がマイキャラなのか？」という情報はタスク管理が保持
　する。

　　−−−−−−−−

　マイキャラかどうかによって、「コマンド」オブジェクトに対するアクセスの
　仕方が変ってくるので、この辺を先に整理する必要があるか・・・。
　（更に言うなら、通信プレイかどうかによっても変る）

　それから画面遷移に関しては、トップレベルのタスクが一元管理した方が
　ややこしく無くていいかな。やっぱ。

　　−−−−−−−−

　ところで、この↑区切りなんだけど、間で結構な時間が経過してる事を
　表すのだ。

　　−−−−−−−−

　まだ何にもしてないケド、眠いので寝る。　オヤスミ。

　　−−−−−−−−
　　−−−−−−−−

　おはようフェルプス君。（ぉ
　面倒だったので、上で書いてた事を全く無視してやってみた。（ぉ

　とりあえず「タイトル画面」と「メインメニウ」のタスク・オブジェクトを作成。
　まだ中身はカラッポで、確認用の文字列を表示するだけだ。

　んで、
　画面が遷移する時は、遷移先のタスクを生成しておいてから自殺っと。

　「マイキャラ権」の委譲に関する処理の方針を決めるのが億劫だったのだ。
　まぁこれは追々考えよう。

　　−−−−−−−−

　タスクの削除要求に対する処理がバグっていたので修正。
　条件式の意味が逆だった。

　　−−−−−−−−

　ホントは最初に書いたように、全てのタスクを生成しておく必要がある。
　でないと、一旦遷移して戻ってきた時に、前回の状態を覚えてられない。

　タスクに「インアクティブ」という概念を導入するのだ大変なんだ。
　別のタスクから「起こす」為の手段とかも用意せにゃならんし。

　今回のはあくまでも暫定処置という事で。

印象に残るキーワード

　「レイのアレ」

　・・・具合はどうですか？（ぉ

　

むぐぐ

　まいったなぁ・・・、一昨日に取ってきた住民票なんだが、本籍地の
　記載が省略されてるではないか。

　仕方ないので、もっかい区役所にいって取り直し。
　本籍地の記載が必要な場合は、その旨記入しないといけないのね。

　しかし簡単に貰えるのはいいのだが、住所氏名と生年月日さえ知って
　れば、他人でも簡単に取れそうだねコレ。大丈夫なん？
　その足で郵便局に行き、速達にて発送。

　帰りに１００円ショップにてパスタを購入。
　いいかげん、パスタソースの種類を増やしてくれ。

　

　

開発状況（グラフィック管理）

　むむむ。
　マルチサンプルのブラーを実装しようと思ったら、
　プリミティブ数 Ｘ サンプル数 の分だけディスプレイリストのエントリを食う。

　それってば、あまりにもイヤーンな感じではないか。

　レンダターゲットだけ変えて同じディスプレイリストをレンダリング・・・。
　結局はもう一層上に簡易スクリプトみたいなのを実装する必要がある？

　　−−−−−−−−

　「まずレンダターゲットありき」・・・で考えていたけど、
　ディスプレイリストにレンダターゲットをアタッチするような感じになるのか。

　「レンダターゲット＋カメラ」のペアを複数用意して任意のディスプレイリスト
　にアタッチすれば、後は内部でマルチサンプル・ブラー・・・とか？

　ディスプレイリストのレイヤはやっぱ１通りではダメかな。
　半透明用レイヤは内部に完全に隠蔽してしまおう。

　

　

開発状況（通信管理）

　受信メッセージのハンドラは全て「通信管理」ライブラリの中に隠蔽されてる。
　・・・のだが、
　「プレイヤー生成」のシステムメッセージのみ外部のコールバックを使える
　ように修正。　通信管理のプレイヤー情報とタスク管理のタスクオブジェクト
　との関連付けをするのがココなわけだ。

　　−−−−−−−−

　さて、途中でプレイヤーのタスクオブジェクトが変った時が問題だ。
　通信管理のプレイヤー情報に含まれる「タスクオブジェクトへのポインタ」が
　デッドポインタになって辻褄が合わなくなってしまう。

　タスクオブジェクト側でもプレイヤー登録エントリへのポインタを保持して、
　「逆引き」できるようにするべか。　ベタだけど。

　　−−−−−−−−

　タスクオブジェクトの「通信プレイヤー」を作成。
　内部コマンドの送受信部分を正しく実装。

　試しに４つ程プログラムを起動してみた所、正しく相互に送受信されてる
　ようだ。

　た・だ・し、
　通信データの同期処理をまだ行なっていないので、あっというまにコマンド
　キューが溢れてしまい、コマンドの取りこぼしが発生している。
　まぁいい。　段階的に鍛えてゆくのじゃ。

　　−−−−−−−−

　同期処理の作戦。

　・ コマンドキューからコマンドを取り出す際、全員の分のコマンドが同一
　　シーケンス（送信時に付加する連番）になるようにする。
　　（とりあえずは、全員の分が揃うまで待つ。）

　・ コマンドキューの溜まり具合を監視して、「入力（送信）」と「メイン（受信）」
　　の各スレッドのサイクル時間を調整する。
　　　・ 自分のコマンドが沢山溜まってたら、「入力（送信）」スレッドの処理
　　　　間隔を長くする。
　　　・ 相手のコマンドが沢山溜まってたら、「メイン（受信）」スレッドの処理
　　　　間隔を短くする。
　　　基本はこんな感じ？　よくわからんけど。（ぉ

　　−−−−−−−−

　シーケンス番号を揃えて取り出すのはＯＫ。　・・・少し怪しいけど。

　キューの監視は明日実装しよう。

　

　

はぁ・・・

　基本的に俺は片付けが苦手な人なのだ。
　悪い癖は、
　「本棚から取り出した本（多くの場合マンガ）を元に戻さない」というもの。

　読んだ後にそのまま「手の届く範囲内」に平積みしてしまう。
　かくして、俺の定位はすぐに「コクピット状態」になってしまうのだ。
　これでは部屋が広かろうが狭かろうが関係無い。

　困ったものだね。

　

　

印象に残るアルバイト

　アダルトビデオの男優。
　１本あたり１５万円。
　ただし相手は男。

　・・・遠慮しときました（苦笑）
　「攻め」の方がマシと言えなくもないが、素人はたいてい「受け」なのだ。
　それに、ちょっと安いかな。

しまった！

　今日はゴミの日だったのに！　寝坊して出すの忘れた・・・。

　引越し荷物とゴミで・・・寝る所が無い。

　

引越し準備

　ようやく引越しの段取りが決まったぜ。
　結局どこも似たり寄ったりの金額だった。

　金額も確定。　うぅ、高い・・・。
　大阪→東京とかだと何件分かの荷物をまとめて輸送できるのだが、
　大阪→熊本だと２㌧㌦車（＋要員２名）をチャーターする事になるのだ。
　２㌧車に詰める量の範囲内なら、料金は変らなそうだ。
　うーむ。　本は捨てずに全部持って行けそうだなぁ。（ほとんどが漫画）

　結局の所、マンション契約と引越しの費用で５０万近くの借金を抱える
　事になってしまった・・・。　とほほ。
　まぁ、立て替えてもらえるだけでも有難い話ではある。
　返済は１年以内目標という事で。

　予定では２０日１２：００〜１４：００搬出、２１日現地搬入。
　搬出後に解約の手続きをし、直ちに熊本へ移動。
　２０日の晩はどこかで一泊。
　いとうくりえさんとこに泊めてもらおうかにゃあ。（と探りを入れ）

　１３日に見積書とサービスの（というか料金に含まれてる）ダンボール箱
　を届けてもらう事に。

　　−−−−−−−−

　おっと、早めに粗大ゴミ回収の依頼をしなければ。
　・・・これってドコに頼むんだろ？（ぉ

　

　

開発状況（グラフィック管理）

　（メモ）
　テキスト描画に「ウィンドウ」の概念を導入する必要あり。
　ビューポートと同義と言えなくもないか。

　　−−−−−−−−

　時々、クライアント領域が白くフラッシュするのだが・・・・・・？
　ＰＡＩＮＴメッセージを無視してるのが悪いのかしらん？（ぉ

　

懐かしひ

　人恋しくて ｎｉｇｈｔｍａｒｅ君とこに電話してみた。
　おー、今回は繋がった。　（仕事場は電波が届かない所に有るらしい。）

　ちょうど新居への引越しが完了した所だったそうだ。
　忙しかったろうに、ついつい長電話してしまった。スマソ。
　仕事の方は大変なりに楽しそうで良かったねぇ。
　まぁ、元気そうでなにより。

　　−−−−−−−−

　有ったら嫌な携帯電話
　スタンガン付携帯電話
　・・・意外と有りそうで無いよね。
　やっぱし危険だし（笑）　ショックでメモリが消えちゃいそうだし。
　ていうか、「携帯電話型スタンガン」の方が需要がありそう。

　

　

　

開発状況（通信管理）

　ひとまずは様子を見る為にテキトー実装。

　自分用のコマンドキューしか監視しない。（ぉ

　・ キューの溜まり具合が上限基準値を越えたら、スレッドの処理間隔を
　　短くする。
　　で、ある程度まで減ったら通常速度に戻す。
　・ キューの溜まり具合が下限基準値を下回ったら、スレッドの処理間隔
　　を長くする。
　　で、ある程度まで溜まったら通常速度に戻す。
　
　これだけ。　手抜き。　いやんばかん。
　「通常速度」ってヤツ自身は固定値なので、これだと速度がフラフラする
　事になるよな、きっと。　フレームレートのダッチロール現象！？

　　−−−−−−−−

　おーおー、これだけでもケッコウいけるじゃん。
　とりあえずコレで、キューのオーバーフローは無くなったぜ。

　「一応」でも動いてしまうと、急に情熱を失ってしまう。（ぉ
　これ以上の細かい制御は「調整」扱いとして次のステージへ持ち越し！

　　−−−−−−−−

　んー？
　４コ立ち上げて、表示させてるキューの状態を１０分くらい眺めてたら、
　・・・ひとつがコケた。

　解放後のヒープブロックに書き込みに行ったんだと。ひぃ。

　問題は多分、昨日書いたコードの中だろ。
　心当たりが無いでもない。（ぉ
　やっぱり排他制御への考慮が足りなかったか・・・。

　それもそうだが、最適化オプションを付けたら絶対に動かんなコリャ　（ぉ

　それはともかく、残された３コが固まってしまうというのも深刻な問題だ。
　通信相手が消滅しているのに、メッセージを待ちつづけているのだ。
　・・・ダサダサ。

　　−−−−−−−−
　　−−−−−−−−

　そうそう、「プレイヤー消滅」のハンドラを外部に公開するのを忘れてた。
　「追加」だけ有ってもダメじゃん。　て事でサクっと修正。
　やる事と言えば、プレイヤーが保持するタスク・オブジェクトを削除する
　だけだ。（それ以外は全て通信管理の内部で秘密裏に処理される。）

　　−−−−−−−−

　そういうワケで、スレッドが永久ループに陥る爆笑問題を対策。
　とりあえずタイムアウトするようにした。（ぉ
　それから問題部分をクリティカル・セクションで排他制御するように。
　参照している最中に追加／削除が発生して辻褄が合わなくなるから。
　しかし、比較的ロック期間が長くなるので、能率面でやや心配だ。
　メッセージハンドラの処理を待たせる事になるからねぇ。

　プログラム終了時、各管理クラスが終了した後に"DESTROY_PLAYER"
　のハンドラが呼ばれてぐちゃぐちゃになる問題を対策。
　実は、通信管理とタスク管理のどっちを先に終了しても具合が悪いのだ。
　結局は対症療法的にグローバルポインタで振り分け。ダサダサ。
　ＤｉｒｅｃｔＰｌａｙのインタフェースを解放するタイミングが悪いのかな？


　これでホストに対して各プレイヤーが自由に接続／終了できるようになった。
　が、「ホストの移行」は未サポート。　難しい訳ではないのだが、なんとなく。

　　−−−−−−−−

　むー。
　４コ起動すると、そのうちの１コがメモリの不正アクセスでコケる・・・。
　３コまでなら問題無し。　なんだろなもー。

　それはともかく、接続相手がコケた時は"DESTROY_PLAYER"メッセージ
　は来ないのか。　居もしない相手からのメッセージを待ってるよ・・・。
　ひょっとして"CONNECTION_LOST"が届いてるのか？
　こいつは判定してなかったなコリャコリャ。

　　−−−−−−−−

　いや、"CONNECTION_LOST"なんてメッセージは存在しないぞ。

　再現させてみたけど、やはり"DESTROY_PLAYER"は届いていない・・・。
　コケるまでの時間にばらつきがあるのがイヤンな感じ。

　一定時間応答が無かったら切断とみなして削除しちゃえばいいのかな？
　そのへんはＤｉｒｅｃｔＰｌａｙが判定してくれても良さそうだけど。


　マニュアルに記述が有ったような気がするが、探してみると見つからない。
　よくわからんのでペンディング。

　　−−−−−−−−

　入力に従って、マイキャラから新しいマイキャラ（のタスク）を生成する
　動作のテスト。　イメージは「キャラ選択 → キャラクタ」みたいな。

　”ＥＮＴＥＲ”キーをトリガにしたのだが、どーもおかしい。

　２回”ＥＮＴＥＲ”キーを押さないと新しいマイキャラが動き始めない。
　ていうか、”ＥＮＴＥＲ”キーを押した時点でメインループ自体が止まって
　しまっているみたい。　・・・？？

　ぐは。
　そーだった！　ＳＤＫサンプルをドダイにしてるから・・・。
　”ＥＮＴＥＲ”キーは「ポーズ」だったっけ。（激ぉ

　別のキーに割り振ったら、当然キチンと動いた。
　うーむ。　けっこう時間を浪費してしまったな。
　「ポーズ」と「ステップ実行」は殺しておこう。

　ネットゲーに「ポーズ」は要らん。
　　・・・ていうか、有ったら困る（笑）

　　−−−−−−−−
　　−−−−−−−−

　各プレイヤー用タスクに「ステータス」を増設。
　とりあえず、キー押下で「プレイの準備ＯＫ」という状態を表す値を設定。

　全プレイヤーが「準備ＯＫ」となったら、ゲーム本編に突入・・・という手筈だ。

　が、ここで問題が。
　・ プレイヤー全員の状態を、いったい「誰が」チェックするのか？
　　仮に「（その）画面モード」用タスクの中でやってる。
　　だが・・・プレイヤー管理リストを直接舐めてるので、非常にベタだ。
　　通信プレイでしか機能しないし。
　　プレイヤータスクへのフィードバックにも問題が残る。
　　「タスク間通信」をまだ実装していないからだ。

　・ 後から参加したプレイヤーに、既存プレイヤーの「ステータス」が反映
　　されない。
　　むむむ。　徹頭徹尾「入力データ交換」型でやってる弊害か。
　　新参者には、既存プレイヤーの状態を通知してやる必要がある。
　　これはホストの仕事だな。
　　さて、
　　　・ 状態通知用ユーザメッセージ・タイプを新設。
　　　・ 同データフォーマットを策定。
　　　・ 送信手順を策定。
　　　・ 受信ハンドラから対象タスクまでのデータ受渡し経路を作成。
　　状態の整合性が取れるまでブロックするように、同期開始の手順をいじる
　　必要があるかも。
　　ところで書き忘れていたのだが、
　　ゲーム本編が開始したら、
　　新規プレイヤーの途中参加は受け付けない。

　それとは別に、
　・ ホストが先に終了すると、一般プレイヤー側のプログラムがコケる。
　　・・・まぁ、何も考慮してなかったから。

　　−−−−−−−−

　ワンショットの作り捨てプログラムならば、別に悩むような事ではない。
　ライブラリとゲーム部分を綺麗に分離させようと目論んでるから悩むのだ。
　すでに「綺麗に」という部分は崩壊しつつあるけど。

　相変わらずダラダラやってる割には進んだ方か。
　今日はここまで。

　

　

印象に残るアルバイト

　女の子を説得して某国に売り飛ばす。
　成功報酬２００〜３００万円。

　・・・やっぱり遠慮しときました（汗）
　俺には向かないし。（←そういう問題でもないのだが・・・）
　これはかなり特殊な才能が必要だ。

　

開発状況（通信管理）

　通信確立後にコケる「ことがある」という問題を対策した。
　入力スレッドでのコマンドオブジェクトの排他制御に問題があった。
　異なるスレッド間で同時アクセスしているのに気付いていなかった。
　原因の想定に３分、対策自体は１５秒で完了。

　確認の為、１台（しかないもので）のマシン上で６個起動して接続。
　２時間ほど放置してみたが、問題は発生しなかった。
　よしよし、実験は成功じゃ。

　ただ・・・
　４個以上起動すると、ＣＰＵパワーの不足からスレッドに充分なＣＰＵ
　時間が行き渡らなってくなる。
　フレームレートを制御しようとしても、意図通りの速度にならないのだ。
　で、コマンドキューが溢れて、入力の取りこぼしが起きてしまうんだなぁ。
　これは追って検討の上、対策を考えよう。

　　−−−−−−−−

　むがー！！　わけわからん！

　いや、コマンドキューの状態を監視して、送受信用各スレッドの処理時間
　を調整しているのだが・・・。
　見るべき情報と操作すべき処理の組み合わせががが。　タスケテ。

　とりあえず自分のキューだけ監視しているのだが、やはり無理あるみたい。
　通信相手のキューを見るっつっても、複数居るのにどーしたらいいんだ。
　１人はキューがカラになってるし、もう１人はパンパンに溜まってる。
　むぅ。
　落ち着いて冷静に考えれば解りそうな気もするけど・・・。

　　−−−−−−−−

　とりあえずキューには０．５秒分のコマンドが常に溜まるようにしている。
　０．５秒以内のラグはこれで吸収するって寸法さ。
　見方を変えれば、常に０．５秒のラグがあって操作感（反応）が悪いと
　いう事だ。
　０．５秒以上のラグの時は・・・・・・・・・・・・知らん。（ぉ
　（現状では処理落ちする）

　　−−−−−−−−

　個々のプレイヤー名を表示しようと思ったら、プレイヤー管理情報に値が
　入っていなかった。　ありゃりゃんこりゃりゃん、と。
　”ＣＲＥＡＴＥ＿ＰＬＡＹＥＲ”メッセージのハンドラで取り出し損ねてるのかと
　思ったら、同メッセージのフィールドにもプレイヤー名が入っていない。

　て事は・・・と確認すると、案の定セッション開始時に設定する構造体の中
　にプレイヤー名（とセッション名）をセットしていない。（ぉ
　ダイアログのテキストエディットから名前を取り出すタイミングが悪かった。

　しかし、そんなんでよくセッションが生成できるな。
　名前は要らんのかい。


　てぇことは・・・だ。
　「同一プレイヤー名」に対するチェックと蹴り出しは、自分でやらなあかん
　という事かい。　そりゃ考えてなかったぜ。

　　−−−−−−−−

　プレイヤー管理情報に、「ホストプレイヤーかどうか」のフラグを追加。

　　−−−−−−−−

　ついでに”ＣＲＥＡＴＥ＿ＰＬＡＹＥＲ”メッセージのハンドラ内にて、コンテキスト
　ポインタを登録するように修正。
　登録するポインタは勿論プレイヤー管理情報のエントリを指す。

　このコンテキストは通信管理が内部的に使用するもの。
　同様の意図を持った機能として、プレイヤー管理情報の方にコンテキストの
　ポインタを保持する変数とそのアクセサを用意。
　こちらはターゲットアプリの作成者（ライブラリの使用者）が自由に使用する
　事が出来る。　使い道が有るのかどうかは・・・？

　　−−−−−−−−

　ユーザコンテキストの内容を送受信する仕組みを作ろうかな〜。
　（キャラセレ画面では「入力データ交換型」を放棄しようかという含み）

　　−−−−−−−−

　そーか。
　「入力データ交換」と「状態交換」との両方をサポートしようと思ったら、
　汎用のメッセージキューが必要になるのか・・・。

　現状ではメッセージのデータをコマンド・オブジェクトにデコード（？）してから
　キューイングしている。　これでは汎用性もへちまも無いし。

　その他は特に問題無し。
　あ、ユーザコンテキスト自身にロック機構が必要になるか。

　　−−−−−−−−

　そゆことで、「状態交換」モードをサポートした。　やや手間取ったかな。

　

　

憶え書き

　これから必要になるモノ

　　・ 自転車　−　必須。　こっちで買って持ってこかな。　折り畳み式。
　　・ 作業机　−　必須。　長いのが２つ。
　　・ 肘掛付き座椅子　−　必須。　今有るのは壊れてるので捨ててく。
　　・ 出窓用のカーテン　−　寸法を測らねば。
　　　　・・・以上で２万〜２．５万くらい？

　　・ 全自動洗濯機　−　コインライドリーが近所に無ければ。
　　・ ベッド　−　安い折畳式でいいか。　せめてマットレスだけでも。
　　　　・・・以上で４万〜５万くらい？

　　・ ＰＣ用ディスプレイ　−　１９インチ以上必須。暫くは１５インチで我慢。
　　・ 炊飯器　−　鍋で充分だけど、有ると楽だから。
　　・ 大きめのテレヴィジョン受像機　−　ＣＡＴＶが有るらしいし。
　　・ ＶＨＳ方式のビデオデッキ　−　えっちなビデオが見たいから。（ぉ
　　・ ドリームキャスト　−　「サクラ大戦３」をプレイする為。（ぉ

　　・ お嫁さん　−　必須。　俺の為に毎日みそ汁を作ってくれ。なんちて。

そーいえば

　ＥＢＡ君にエロゲーを借りっぱなしで忘れてた。（って、いつの話だ）
　引っ越す前に返さなきゃ。
　・・・と思ったら、なんと電話が通じないではないか。
　実家だからそう簡単に変ったりしないハズなのに・・・。
　携帯電話からだからダメなのかしらん。　どーしよう。

　

　

印象に残るアルバイト

　ヤクの売人。（ぉぃぉぃ

　・・・だから遠慮しときましたってば（激汗）
　ソフトな方ね。　バイニンではなくディーラーと呼ばれてた。

　も少しマトモなバイトを紹介して欲しかったデス。
　昔の話ね。　念の為。

　

そーいえば

　改めてＥＢＡ君に電話したら、今度は繋がった。
　とりあえず明日の１０時にこっちの近所でおち合う事に。

　

　

開発状況（通信管理）

　「状態交換」モードなのだが・・・。

　プレイヤのタスクが初期化処理をする中で、任意の構造体領域を用意
　する。　で、そいつのポインタをプレイヤー管理リストの自エントリに登録
　するのだ。　これがユーザコンテキスト。

　構造体のフォーマットは、先頭４バイトに構造体自身のサイズを保持する
　意外は自由。　ただし、丸ごと送受信するので小さいほど良い。
　この構造体の中でタスクの現在の「状態」を保持しておくのだ。

　後はライブラリ側で勝手に送受信して、構造体の内容を随時更新する。
　ちゃんと排他制御してるし、「通信」に関わる部分は一切意識しなくていい。

　逆の見方をすると、タスクオブジェクト側で意図的に任意のデータを送信
　する手段は無いという事だ。　これでいいのだ。

　　−−−−−−−−

　「入力データ交換」型だと、受信データの取りこぼしが絶対に許されない。
　例えばミサイル発射のコマンドを取りこぼしてしまうと、送信側では発射
　されているのに受信側では発射されていないという不整合が起きる。
　それ以降、その不整合を修復するのは絶望的に困難だ。

　その点、「状態交換」型ではゆとりがある。
　とにかく最新のメッセージさえ受信すれば、少々取りこぼしが起きても
　問題にならない。　メッセージ中の状態データが、その瞬間のタスクの
　状態の全てを保持しているからだ。　例えばキャラの「現在位置」とか。
　ただし、シーン中のオブジェクトが増えるほど送受信データが比例して
　増えていく為、「量的問題」に直面する恐れがある。

　　−−−−−−−−

　メッセージの送信は「全員に送信」モードを使っているのだが、これだと
　自分のメッセージも自分宛に送られてくるんだよね。

　コンテキストのデータを受信したら、即座に該当プレイヤーのコンテキスト
　を書き換えてるのだが、「自分自身」のは具合が悪い。
　ので、送信者が自分だったら、そのメッセージは無視する事にした。
　だって自分のコンテキストに限っては、入力に従って処理をしてタスクの中
　で更新するものだから・・・。
　（処理後のコンテキストを送信前に旧いコンテキストで上書きしてしまう。）

　「入力データ交換」モードの時は、自分のメッセージも他と同様に扱う。

　　−−−−−−−−

　で、現状の（軽微な）問題。

　「状態交換」モードの時の入力データの扱いだ。
　具体的には、入力スレッドで生成した「コマンド」をメインスレッドに渡す
　部分ね。

　従来（「入力データ交換」モード）はコマンドをメッセージとして送信。
　受信したメッセージからコマンドに戻してキューに登録。
　メインスレッドではキューからコマンドを取得。
　・・・となっていた。

　今度（「状態交換」モード）は入力データは送信せず、ただマイキャラの
　タスクに引き渡すだけでいい。
　なワケで、受渡し用に１コのコマンドオブジェクトを用意したのだが・・・。
　それじゃゼンゼン駄目だったのだ。

　「入力」と「メイン」のスレッドが非同期に回っている事を忘れていた。
　両者のフレームレート（？）は、通信同期の為に常に変化している。
　「メイン」が１ループする間に「入力」が２ループしたりして、トリガ情報の
　取りこぼしが発生しているのだ。

　要するに、スレッド間でのコマンドの受渡しにも、キューを挟まないと
　いかんという事なのだ。
　まぁ「コマンドキュー」クラス自体は既に有るので、それを使えばいいか。
　・・・じゃぁさっさとやれよ。
　と言われそうだが、なんだか気分が乗らなくてねぇ。（ぉ

　　−−−−−−−−

　ところでこの「状態交換」なんだが、送受信して同期を取るのはあくまでも
　「マイキャラ」のコンテキストのみである。

　その他のＣＯＭキャラとかミサイルとか爆発とかのタスクは全くの考慮外だ。
　だから、ゲーム本編はやっぱり「入力交換」型で行く事になる。
　全タスクのコンテキストを送受信するのは現実的ではない。と感じる。
　ま、「処理」自体はホストだけでやれば済むし、タスク数の少ない小規模な
　ゲームならそれも有りなのかな。
　ていうか、それは「クライアント／サーバ」だよね。

　更に言うなら、「ゲーム全体のコンテキスト」の送受信も対応していない。
　これは有ったら便利な事もあるのかな？
　結局は必要になってくるような気がしないでもないケド・・・？
　その時は「特殊なプレイヤー」として組み込んでしまえばいいか。

　　−−−−−−−−

　仕方がないので、「状態交換モードの時に自身の入力を取りこぼす」
　という問題を対策。　上で書いた通り、コマンドキューを使うようにした。

　自分宛のメッセージキューがパンクする問題を対策。
　読み捨てるべきなのに、単に無視していたのが悪かった。そりゃそーだ。

　これにて、
　「プレイヤー受付」＆「キャラセレ」の部分を構築する材料は揃った。
　・・・のかな？

　　−−−−−−−−
　　−−−−−−−−

　ふぅ。

　前にも書いたけど、通信ゲーのフレームワークを書くのは３回目。
　最初のは・・・なーんにも知らなかったので問題外の出来。
　前のは一応動いたが、行き当たりばったりの改造で九龍城状態に。

　基本的に知識と経験が不足してるからなぁ・・・。
　最初の設計に充分な時間をかけても、開発途中で不測の事態（単に知ら
　なかっただけ）に直面する事が多い。

　半ば常識となっている事でも、自分で経験して発見して行かねばならん。
　ま、そんなもんだろーね。

　とりあえず今回のはそれなりのモンが出来そう。（だといいなぁ）
　少なくとも、前のバージョンよりも１０倍は出来がいい。（性能ではなく）
　基本的な機能の構築を目的としているので、例えば予測実行などという
　遅延対策のテクニック的な部分は考慮していない。
　それからパフォーマンスについてもあまり深く考えていない。
　（俺にとっては）まだ早いのだ。

　今回の経験を元にして、次のバージョンでは「実用的」なのを作りたいね。
　そっちは多分、仕事で使う事になるのかも。

　　−−−−−−−−

　うむー、プレイヤー管理に対する追加／削除処理でクリティカル・セクション
　の取得に失敗して固まってしまう・・・。
　と思ったら、某関数のエラー処理でロック状態のままリターンしてた。（ぉ

　ここはやっばり goto なのか？（笑）

　　−−−−−−−−

　むう。
　４個起動してから順番に終了させていくと、２or３個目を終了した時点で
　残りの内の１個がコケる。　んー？　なんだろね。

　その他の問題点。
　　・ プレイヤー名の重複チェックをしていない。

　っと、他には？（笑

　

　

ところで

　ちかごろ開発状況ネタ以外が無いのは、開発作業が順調だから。
　「開発状況」だけでけっこう長いし。
　それに、引越しに向けての片付け（ぜんぜん進んでない）もあるし。
　期待されてる一部の方、ゴメンナサイ。

　

　

開発状況（タスク管理＆グラフィック管理）

　サンプルの仕様を引きずってサポートした、以下のメソッドだが・・・。
　　RestoreDeviceObjects();
　　InvalidateDeviceObjects();
　　DeleteDeviceObjects();

　やる事は決まっている（対象のみ異なる）のに、いちいち全てのタスクに
　記述するのは何だか間抜けっぽい。
　という事で基底クラス側で隠蔽するようにしよう。

　タスク内で使用するメッシュ（とフォント）オブジェクトを登録処理しとけば、
　後は全部自動でやってくれるように・・・。

　　−−−−−−−−

　というように直した。
　これでタスク・オブジェクトに上記の３メソッドを記述する必要はなくなった。
　その代わり、初期化処理でメッシュ（又はフォント）をテーブルに登録する
　コードを追加する必要がある。

　簡単な処理なので、一発で動いた。

　　−−−−−−−−

　タスクが終了して所有するメッシュが削除される時・・・。
　実はそのメッシュはまだディスプレイリストに登録されてて、レンダリング
　している最中・・・という事が起こり得る。ていうか、起こった。
　メインループとレンダリングとを別のスレッドで非同期に回している故に
　発生する問題だ。

　だから以前、メッシュに参照カウンタが必要だと書いたのだが、面倒で
　やっていなかった。
　これも早急に対処しよう。（上のヤツとやや関連）

　とりあえず「プログラム終了時」に関してだけは、レンダリング用スレッド
　を最初に終了するという方法で問題を回避したっス。（ぉ

　　−−−−−−−−

　対策した。
　「リファレンス・カウンタ」クラスを作成。
　好き勝手なタイミングで解放処理をされるとイヤなので、Ｒｅｌｅａｓｅ（）に
　該当するメソッドは無し。　あくまでもカウントの増減の管理のみだ。

　ディスプレイリストに登録する時点で＋。　レンダリングが完了したら−。
　タスクの削除処理の中で、リファレンス・カウンタを調べる。
　でもってもしも２以上のヤツが居たら、次回の削除処理に回す、と。

　それはさておき、生まれて初めて使ったよ。
　多重継承ってやつを。
　わけわからんこっちゃになるのを嫌って使わないようにしてたのだが、
　今回のケースはシンプルなのでまぁいいかな・・・と。

　

　

料金が・・・

　また人恋しくなって、いとうくりえさんに電話。
　簡単に近況報告をば。
　っと、先月末以来更新が止まっている事を指摘されてしまったぁ！
　あう。　明日、ネットカフェに行ってアップロードしてこよう。

　それはともかく、月末の通話料引き落としが怖いなぁ。

　

マンガ

　だからあれほど金が無いと言ってるのに。
　懐かしさに引かれてついつい買ってしまった。

　「市立戦隊ダイテンジン」（六道神士）

　あー、そういえばそもそもエロマンガだったのね、コレ。
　「落とし穴に落ちるエクセル」以外ぜんぜん印象に残ってなかったし。
　でもって渡辺（違うけど）にヤられちゃってるし（苦笑

　

　

印象に残る台詞

　君の一存で
　何とかしてくれたまえ!!

　

久しぶり

　うー、寝坊した。　ＥＢＡ君からの電話で起こされた。
　素早くシャワーだけ浴びて待ち合わせ場所へ。

　いやぁ、ぜんぜん変ってないね。　ていうか変ってても恐いけど。（ぉ
　積もる話と近況とこれからの予定を報告。
　借りてたエロゲーを返したら、俺が貸してたエロゲーが返ってきた。
　しかも４本も。　あれぇ？

　ユニバーサルスタジオの「ブルース・ブラザーズ」ショウが大層面白い
　そうで、話を聞いててウズウズしてしまった。　せっかくだから大阪に
　居る間に行っとくか？
　アトラクションによってはかなり濡れる（水でだ）らしいので、靴は
　ビーチサンダルとかの方がいいんだと。

　丁度田植え時期で忙しいとの事で、２時間ほどダベってから別れた。

　　−−−−−−−−

　その足でネットカフェへ行く。
　もちろん溜まった日記をアップロードする為。

　初めて行く店だったのだが、けっこう遠い・・・。
　なんでも会員制だそうで、身分証明を忘れたと言ったら携帯電話を
　人質に取られた（笑）。　一時間４５０円でフリードリンク。

　んが！　だめじゃん！
　ＦＤＤが付いてない（爆）

　仕方が無いので、知り合いの掲示板に書き込みだけして帰ってきた。
　くすん。　クリちゃん、更新できなくてごめんね。

　　−−−−−−−−

　ＸＦＣ２００１の参加申し込みをした。

　発表するような技術的ネタは持ってないので、一般参加という事で。

　　−−−−−−−−

　ああっ！　俺の馬鹿。
　また本を買ってしまった・・・。　引越し荷物を増やしてどうする。

　「世界のミサイル」　定価３８００円

　古本屋で１５００円だったから。　いや、理由になってないね。
　弾道ミサイルと巡航ミサイルの解説本。　資料としてはマアマア。
　この辺の分野はあまり詳しくないんだ。

　

　

開発状況（通信管理）

　さて問題だ。

　プレイヤー全体を監視する為の「キャラセレ画面処理」タスクだが、
　個々のプレイヤータスクに対して情報をフィードバックする手段が
　用意されていない。

　例えば、各プレイヤーキャラの初期配置の座標を割り振って決定
　したとして、それを当のタスクに伝える手段が無いという事だ。

　更に、
　プレイヤーを識別する手段がＤＰＮＩＤしかないので、初期位置など
　はホスト側で決定して他の一般プレイヤーに伝えるようにする必要
　が有るのではないか。
　複雑な決定方法にした時、辻褄が合わなくなる事が考えられる。

　　−−−−−−−−

　やはり、初期状態に関する情報はホストの「キャラセレ画面処理」
　タスクで決定しよう。
　でもって、「タスク間通信」でプレイヤータスクに伝える。
　プレイヤータスク内では、「タスク間通信」で受け取った初期状態に
　関する情報をコンテキストに格納する。
　そうすれば、コンテキストの内容が自動的に送信され同期が取れる。

　という事で、「タスク間通信」をサポートするのが鮮血だな。

　

開発状況（タスク管理）

　はいはいはい、「タスク間通信」ね。
　これは前回の時に既に実装しているので、簡単に持って来れるだろ。

　タスクの基底クラスに「送信」と「受信」のメソッドを追加する。
　データのフォーマットは相互のタスク間でローカルに決めればいい。

　メッセージは受信側のタスクが保持するキューに格納される。
　データ量が少ないであろうと予想されるので、リスト構造で行こう。

　　−−−−−−−−

　前回から抱えている問題なのだが、今回のフレームで送信した
　メッセージが同じフレーム内で受信されるとは限らない。
　受信側タスクの今フレームでの更新処理は既に終わっているかも
　知れないからだ。　その場合、受信処理は次のフレームまで持ち
　越される事になる。
　これは受信ポーリングをやめてコールバック形式にしても変らない。

　前回は「実用上問題無し」と判断してそのままにしていたのだが、
　ホントに問題無いのだろうか・・・？
　実は、各通信プレイヤー内のプレイヤータスクの登録順序は、接続
　した順番によってそれぞれ異なるのだ。
　（必ず自分のタスクが最初に生成される為。）

　うーん。
　ここはひとつ、「メッセージは必ず次のフレームで受信される」という
　逆発想で逃げを打とうか。
　今フレームで送信したメッセージは同じフレーム内では受信できない
　という事ね。　だめ？

　勿論、最初から「タスクに対する情報問い合わせ」などの用途に使う
　つもりは無いっス。

　　−−−−−−−−

　３０分ででけた。
　上で書いた「待たせる」って処理は未実装。

　毎回ヘッダとバッファをｎｅｗ／ｄｅｌｅｔｅするという悲しい実装だが、
　とりあえずはこれでいいのだ。

　

開発状況（通信管理）

　さっそくテストテスト。

　プレイヤー全員が「準備ＯＫ」となりホストが「スタート」を指示すると、
　「キャラセレ画面処理」タスクから全プレイヤータスクに対してタスク間

　通信メッセージを送信する。

　ＯＫＯＫ！　送受信ともバッチリと動作してるぜ。

　メッセージの内容はとりあえずダミーデータだが、本来ならばここに
　各タスクの初期位置などの情報が格納される。

　念の為に再度書くが、
　各プレイヤータスクの初期状態決定の処理を行なうのは、ホストプ
　レイヤーのピアだけだ。　他のピアへはプレイヤータスクのコンテキスト
　を通じて情報が（自動的に）送信される。

　「ピア内の管理情報としてのプレイヤー」と「ピアとしてのプレイヤー」が
　曖昧で紛らわしい事に、今気が付いた。（ぉ

　　−−−−−−−−

　プレイヤー管理から「ホストプレイヤーの登録エントリ」を取得する
　メソッドを作成。

　　−−−−−−−−

　現在の問題点。
　　・ プレイヤー名の重複チェックをしていない。
　　　　・ 最初に弾いて受け付けない。
　　　　・ 連番とか「偽」とか付けて受け付ける。
　　・ ホストが先に終了すると、残りのプレイヤーが固まる。
　　・ ホストの移行をサポートしていない。
　　・ ブレイヤーの１人がコケると、残りのプレイヤーが固まる。
　　　　（通信相手の消失を検知出来ていない）
　　・ ４個以上接続すると、終了時にコケる事がある。

　　−−−−−−−−

　タスクオブジェクトの状態遷移（アクティブ／インアクティブ）をサポート。

　インアクティブ状態のタスクは、ハンドラが一切呼び出されなくなる。
　外部からアクティブにするには、その対象タスクのポインタを知っている
　必要がある。　・・・ので、使いにくい。

　タスク呼び出しのオーバヘッドになるので、消せるのなら消そう。

　　−−−−−−−−

　覚え書き。
　　・ マイキャラが交代した時は、新しいマイキャラのコマンドキューを
　　　クリアする事。
　　・ タスクの「アクティベート」は即時に処理される。
　　　従って復帰後はまず「レンダリング」ハンドラから実行される。

　　−−−−−−−−

　プレイヤー管理から「ローカルプレイヤーの登録エントリ」を取得する
　メソッドを作成。

　ローカルプレイヤーってのは、自分の事ね。

　　−−−−−−−−

　ありゃ？
　プログラムの終了時、既にＤ３Ｄデバイスが解放されているタイミングで
　レンダリングしようとしてコケるし。
　リファレンスカウンタ周りが正しく機能していないのかな？

　

　

しゃっくり

　心配しないでも、ちゃんと毎日パスタ食ってるよ。（ややすさみ気味）
　今日はミートソース。　何にしても「肉」は重要だ。

　最後に思いっきり頬張って飲み込んだら、横隔膜がびっくりしたらしい。
　また、しゃっくりが止まらなくなっちまったぜ。

　「侍ジャイアンツ」を熱唱すると、しゃっくりが止まる

　という驚異の発見の再確認をとも思ったが、独りでカラオケ屋に行くのは
　いやだなぁ。　お金かかるし。

　　−−−−−−−−

　鬱陶しいので、気合で止めた。

　メシ食ったばかりだったので苦戦したぜ。　腹筋も衰えてるし。
　血管キレそうになった。　馬鹿。

　

　

印象に残る台詞

　恋する女は
　何やったって
　ええんやでーっ

  　（ 小池田マヤ「零子が行く！」 ）

　・・・おいおいおい。

開発状況（通信管理）

　覚え書き。

　　・ 「状態交換」から「コマンド交換」への移行のタイミングで、一旦
　　　シーケンスの同期を取り直す必要があるのではないか？

　　−−−−−−−−

　リファレンスカウンタ関係の不備を対策した。
　レンダリングが完了しないうちに解放してしまうという問題ね。

　リファレンスカウンタをデクリメントするタイミングが早かったみたい。
　ＥｎｄＳｃｅｎｅの完了まで待ってからデクリメントするようにしたら解決した。

　　−−−−−−−−

　画面遷移の動作に深刻な問題が起きたので、かかりっきりで対策した。
　問題の根本的原因は、各ピア毎にタスクの実行順序が異なるという事。
　（必ず自分のタスクが最初に生成される為）

　タスクから新たなタスクを生成して、自分はインアクティブ化する。
　その際、再びアクティベートされた時の為にコンテキストを初期化してた。
　これがいけなかった。
　通信相手の方はタスクの実行順序が丁度逆になるので、初期化された
　コンテキストの内容に影響を受けて予定外の動作をしてたのだ。

　むー。　けっこう根が深いかも。
　とりあえず初期化はやめとく事で問題を回避した。

　　−−−−−−−−

　こういう事だ。

　下の例ではＡがホストプレイヤーである。
　基本的に重要な決定はホストプレイヤーのタスクが一元的に行なう。

　　　　　　　　　　　１　　　２　　　３　　
　　ピア１（Ａ）：　Ａ　Ｂ｜Ａ　Ｂ｜Ａ　Ｂ｜・・・
　　ピア２（Ｂ）：　Ｂ　Ａ｜Ｂ　Ａ｜Ｂ　Ａ｜・・・

　縦棒がフレームの区切りだ。
　コンテキストはこのタイミングで更新される。

　１フレーム目のピア１で設定されたＡのコンテキスト（上段Ａ）は、ピア２に
　送信されて（下段Ａ）で有効になる。　どちらもＢがＡの影響を受ける。

　でもって、（上段Ａ）の処理直後にコンテキストを書き換えてしまうと、（下段Ａ）
　との不一致が発生して困ったちゃん・・・というワケだ。

　うーん、実はよく解っていないのか俺？

　　−−−−−−−−

　上記の問題の対策案。

　・ タスクの実行順序を各ピア間で同じにする。
　　無理・・・とは言わないが、けっこう面倒で気が進まない。
　　あ、プレイヤーのＤＰＮＩＤでソートしちまうか？（勿論挿入ソートね）

　・ コンテキストの書き換えタイミングを固定する。
　　コンテキストは受信ハンドラの中で即座にタスクに反映させているが、
　　これを一旦キューイングして更新処理の開始前等の固定タイミングとする。
　　・・・ていうか、既にそうなっていた。　勘違い。（ぉ
　　そういう問題ではなかった。

　やっぱり単純に再初期化のタイミングをずらそうかな・・・。

　　　−−−−−−−−

　ま、こういった意味でもタスクの実行順序に依存した処理にならないように
　注意しなければならない・・・という事か。
　難しい注文だね。

　あるタスクの処理結果は必ず次のフレームで参照する・・・て事なのか。

　　　−−−−−−−−

　これまでの修正で、
　「４個以上接続すると、終了時にコケる事がある。」
　という問題はいつのまにか解決した。

　やはりプリミティブの解放タイミングが悪かったのね。

　　　−−−−−−−−

　ていうか、解決してないじゃん。（実行順序問題）

　　　−−−−−−−−

　受信コンテキストのサイズをチェックすべし。

　　　−−−−−−−−

　もう寝る。　くすん。

　　　−−−−−−−−

　ようするに、プレイヤーのうちの１人（ホスト）が主導権を握ってるのが
　いけないんでないかい？
　状態変更の制御は第三者のタスクに任せよう。　それがいい。

　　　−−−−−−−−

　タスク間通信メッセージ。

　今回のフレームにて送信されたメッセージは、同じフレーム内では受信
　出来ないように「待たせる」細工を実装。

　　　−−−−−−−−
　　　−−−−−−−−

　ぎゃぁ！　動いたぜ！

　苦労した。　あまり多くは語りたくない気分だ。
　「状態交換」から「コマンド交換」へ移行する際の、ピア間の辻褄を
　合わせるのが大変だった。
　ていうか、まず「何が起きているのか」を把握するのが大変だ。

　便利なデバッグ方法ってないのかなぁ・・・・・・。

　　　−−−−−−−−

　あひぃ。
　４個目を起動した直後にそいつがコケた。　再現しない。
　４個接続した状態だと、画面表示が壊れる事がある。

　ウチの環境だと、３個まではＣＰＵに余裕があるのだ。
　で、４個目を起動を起動するとＣＰＵパワーが足りなくなってくる。
　そのせいか？　タイミング関係かな。やだなぁ。
　今度はＤ３Ｄが絡んでるみたいだしだし。

　この調子だと、引越し前のリリースは無理っぽい・・・。

前の日記を見る