つかれたー。仕事が(おそらく)一段落ついたので土日休めたけど、調子に乗って土曜に遠出してしまったらけっこうしんどかった。 いろいろ買い物はできてよかったけど。
帰りに秋葉原寄ってCPUとマザボでも買おうかと思ったけどさすがに疲れてやめた。そんなに必要でもないんだよな……。
最近PeerCastStationで視聴してるとぶちぶち切れまくってよろしくない。Windows Media Playerなら大丈夫なんだけどVLCでは切れまくるなぁ。
ログを見たところSend Timeoutというのが多数記録されてた。これかー。 従来送信タイムアウトをちゃんとしてなかったのを修正したせいだな。
タイムアウトが一律3秒てのがよくなかろう。ちゃんとビットレートに合わせて可変させないと……ん？ いやいや、受信速度と再生速度がいっしょなんだからタイムアウトする方がおかしいでしょう。
理由を考えたところ、接続した瞬間はある程度貯まってるバッファを一気に送るので、そこでプレイヤー側のバッファがいっぱいになっちゃうとしばらく受け取ってくれない可能性はあるな。3秒以上のバッファを一気に送るって受け取ってもらえない状態になると次の送信がタイムアウトしちゃうなぁ。
さてどう対策したものか。といってもプレイヤー側のバッファサイズなんか知りようもないので対策しようもない。やるなら輻輳制御ということで、送り切れなかったらどんどんタイムアウト延ばしていく的な？ってそれタイムアウトしてないよ！
結局のところ視聴時はタイムアウトしないようにした。タイムアウトで切る必要もないしな……。ただ接続終了時はいつまでもブロックされるとまずいので10秒程でタイムアウトするようにしておいた。10秒は長いような気もするが大丈夫だろう。
PeerCastStationが落ちるとかいう話をよく聞くんだが、再現できなくてとてもこまる。
スリープして復帰すると落ちるとかそのあと起動できなくなるとか、複数のチャンネルを視聴しててそのうち一つが終了すると落ちるとかいう話だ。どっちもそういう使い方してないってのもあるんだが。
しかし落ちるときはGUIの問題で落ちてることが多そうに見える。Windows.Formsなんかきらいだ！単にマルチスレッドの扱いが上手くいってない可能性もあるけど、そのあたりは何度も見てるんだよなぁ。
追加の情報をもらって、どうもGUI非表示で立ち上げた場合に落ちるようだ。Formが非表示だと操作したときにウィンドウハンドルが作られてないので操作できません！とInvalidOperationExceptionを投げてくる問題だ。勝手にウィンドウの作成を遅延しておきながら例外投げるとかとんだクソ仕様だよ。 無駄にHandleプロパティをアクセスしてウィンドウハンドルを強制的に作らせるようにして解決。これで解決するとか意味わかんねーだろまじで……。
落ちるのとは別なんだけど、GUIをリモートで操作できないですかねという奇特な要望が来た。HTMLは使えるんだがGUIの方がいいという人もいるようだ。GUIもプロセス分離してHTML UIと同じようにRPCで操作するようにしようかな。それなら万が一GUIが落ちても痛くない。
GUI分離の欠点は、サーバと通信できないと操作が一切できなくて困るのと、サーバとクライアントの2つのプロセスを起動しないといけないあたりか。
利点はGUIが落ちてもサーバは無事、GUIを交換するのが簡単、リモートサーバの管理もGUIでできる、とまあけっこうあるな。
GUI側でサーバプロセスを見つけられなかったら勝手に起動するようにしたり、操作できるポートを勝手に探したりできるようにすれば欠点はごまかせるかな。サービス探索と言えばBonjour使えばいいな！いや良くないな！まあそんな物使わずになんとか頑張ってみたい。
以前からPeerCastStationをサービス化したいとも思ってた。そうなると必然的にGUI分離になる。
サービス化したいってのも、まあ単にサーバプロセスならサービス化するべきだよなぁと漠然と思ってたというだけだったが。 逆にサービス化しちゃうとインストール(というかサービス登録)必須になっちゃって、ファイルコピーだけで配置完了するのがいいという人も一定数居る中で反発もありそうだなと。
そんな話をしていたらサービス化して欲しいという人が二・三人程出てきた。 サーバマシンで起動してるのでログインせずに起動できるサービスになってると嬉しいとのこと。 いやー嬉しい場面だとすればそんなところかとは思ってたけど本当居るとは。 あとリモートで起動・停止・再起動できるのもいいとかなんとか。そう言われてみればそうだなー。
目立たないけど真面目にWindowsサーバ的なことやってる人もいるんだなぁ。 (今は亡き)Windows Home Serverとかもあるからおかしくはないか。俺もタイミングさえ合えばHomeServer買ってただろうし。
使う人居るならサービス化もしたいところだが、たいていの人にとってはサービス化なにそれ食えるの？な話でインストール必須になるというのはめんどくさいだけだ。そこをどうするか考えてみたが、今のPeerCastStation.exeとサービス化したPeerCastStationService.exe(仮)を両方入れておいて、必要な人はサービスを登録して使ってねということにすればよさげ。
サービス化はいずれやるにせよGUIの分離してからだなー。
内部的なソースの整理的なのをせっせとやっててよろしくない。
敵のAIなんかをステージ記述に書けるようにしたはいいが、モデルなんかが決め打ちだったのでそれをなんとかしようと四苦八苦した。
モデルは今のところ立方体一個とかなので、1プリミティブ+1マテリアルで1モデルを構成してる。モデルをインスタンス化する場合はプリミティブリソースとエフェクトリソースを指定するようになってるんだけど、2つリソース指定するのめんどくさいね。めんどくさいっていうか、後々には複数プリミティブに複数マテリアルでモデルを構成するので、いちいちそれらを指定するわけにはいかなかろう。
モデルリソースを作ればいいかーと思ってこねこねしてたがどうも上手くまとまらない。 モデルには衝突判定の形状も含まれるべきだ！ということでそれも入れようかと思ったんだけど、インスタンス化すると表示用のモデルと衝突用のモデルの2つに分かれるので1つのリソースにまとめる意味もあんまりないのか？
そもそも今のところは立方体一個で済んでるしな……。諦めて使う分だけ作るのが正しいだろうということで、1プリミティブと1エフェクトをまとめたメッシュリソースだけ作って満足した。 衝突判定の方は今まで直打ち前提だった衝突形状をリソースとして読み込み対応にしてやる程度。
ステージ記述ではリソースの定義をしてやって、敵の定義で表示モデルと衝突判定モデルのリソース名を指定すれば上手いことやってくれるようにした。
コードでリソース記述していくのも無理が出てきた気がする。モデルファイルとか作っちゃって、リソースは常にファイルから読むんですよ！とした方が楽になるのは分かってるんだけど、あんまり早い段階でそれ決めちゃうとあとで変えるの大変だから慎重にやりたいな。
そろそろゲームの中身をごりごり作る方に戻っていきたい。