メインマシンのSSDが128GBだとさすがに心許ないというか、残り10GBしかなくて今時のソフトを入れる余地があんまりなかったので256GBの奴を買ってきた。 悩みつつM5Pの256GBとか買ってきたんだけど、やっぱりM5Sで充分だったんじゃないですかね……。 今も安いSSDで充分速いと思ってるのでそんなに高いのいらなかったのでは。もう買っちゃったのでべつにいいんだけど。
移行はめんどい。とりあえず今の状態をバックアップ取ったところまではやった。SSDつけかえて移行しないとなぁ。
土曜日に全ゲ連第13回交流会というのに行ってきたので感想。
DOGA-Lシリーズの紹介。DOGA-Lシリーズってまだあったんだ……。
30分中15分(質問入れて20分)でおわってしまった。 実際に作ったムービーとか作ってみるデモとかあった方がよかったんじゃないかなぁ。
DOGA臭さを消すようにモデリングを頑張りましょうと言ってたけどそれ頑張ったら本末転倒にならんかな。
動画サイトにPV上げるためのキャプチャ/エンコード方法解説。
初心者向けの話かと思ったら専門用語飛ばしまくりでワロタ。 コーデックの中身とかちゃんと解説すると難しいので、とにかくこれをやっておけ的なのだけの方が混乱しなくていいんじゃないかな。
ゲーム画面取り込みは可逆圧縮がいいと言ってたが、べつに可逆じゃなくても編集用のコーデックでいいんじゃないかと思うんだよなぁ。 まあ画面キャプチャに使える安価な編集用コーデックはみんな可逆圧縮なだけかもしれない。
ニコニコ動画のエコノミー回避って言葉が出てきたけど、質問でエコノミーって回避できる物なんですかと聞かれていて伝わってないようだった。 つまりサーバでの再エンコード回避ってことなんだから変な言い方せずにそう言えばいいと思うんだけど……。
YoutubeとかVimeoでのサーバ再エンコ状況はどうなんだろうか。 30fpsまでとしか言ってなかったがきっとそれだけではあるまい。 ニコニコ動画とか全く興味無いのでこっちの方が気になった。
ゲーム中に使う動画はDirectShowとか使うとデコーダが環境によって何入ってるかわからんのでゲーム内で持ちましょうとか言ってたけど、べつにWMVなら変なデコーダに差しかわってることもないんじゃないかなぁ。WMVのデコーダを置き換えちゃってるような人は環境さすがに……。もし別なWMVデコーダ入っててもGUID直接指定すれば標準の使えるだろう。
デコーダを独自に持とうにも結局使える物ってTheoraかVP8くらいしかないもんね。
東方幻想麻雀というゲームのサーバの作りについて解説。東方幻想麻雀は全くやったことがないがまあオンライン対戦できる麻雀だろう。
特にログとか残していない対戦サーバなのでDBは使っておらず、対戦中のデータはRAMディスク上のファイルシステムにファイルで作ってやりとりしてるらしい。
データアクセスがとても頻繁に行われてHDDだと間に合わないのでRAMディスク上に作りましたという話だが、HDDでは本当に間に合わないんだろうか。 最大でも1GBほどのデータでそれがほぼ全てっぽいしメモリ8GBもあるマシンなのでRAMディスクでも余裕！という話だったので、実はそれ全部ディスクキャッシュに入らないか？という気はする。まあ永続化いらなくて大きくもない物なのでむしろHDDに置く必要もないしRAMディスクで妥当だと思うけどさ。
あとでApacheは最近アクセスされたファイルをキャッシュする機能でディスクアクセス無しにRAMから返してくれて高速化できるよ！と言ってたのはちょっと違和感が。もともとRAMディスクじゃん……。まあ一般的な話なんじゃないかと思いますが。
スケールしない形だけど同時接続が体験版時で800、製品版時で500くらいとそんなに多くないし、サーバプロセスも重いことやってなさそうだからスケールする必要もないようだ。 スケールするようにするならファイルシステムを簡単なDBみたいに使ってる感じなので同じように使えるMongoDBとかCouchbaseあたりがよさそうなのかなぁと思った。ファイルシステムにしてるから余計な処理なくApacheから返せるってのが無くなっちゃうのでそこはなんとかする必要があるけどそのくらいのオーバーヘッドは仕方あるまい。
クライアントからは秒間3リクエストをHTTPで投げてるということで接続処理がクソ重くなるんじゃないかと思ったが、あんまり詳しく説明してなかったんだがKeep-Aliveでコネクションを張りっぱなしの模様。なるほどなー。HTTPのKeep-Aliveってよくわかってないからこんどちゃんと調べてみよう。
HDDじゃなくてSSDだったらRAMディスクじゃなくてもいけたんだろうかという質問があって、頻繁なアクセスは寿命が縮むのではと答えていたけど、秒間3回も書き込んでるわけじゃないと思うし読み込みもかなり局所性あるだろうから、たぶんディスクキャッシュから出ていくばっかりで実際のディスクアクセスはあんまりないんじゃないかなぁ。もし秒間3回書き込んでもやっぱりほとんどディスクキャッシュに書かれるだけなので想像よりは長く持ちそう。でもやっぱり永続化するようなデータじゃないし容量も充分足りてるのでRAMディスクが最適というのは比較対象がHDDでもSSDでも変わらんだろう。
プログラマだが、曲を頼むのが大変なので自分でなんとなく作れるようになったよという話。
すごくよかった。すげー、これでいいんだ！的な感じでとてもためになった。 プログラム以外の話で特に簡単なのは聞く機会がないのですごく新鮮だ。
LTということになってたが一切LTな要素がなかったような……。けっこう長かった。
真面目な話ばっかりだったのでこういうセッションがあってもいいでしょうとかいいつつ始めたんだけど、これが一番真面目な話じゃなかったかと。 ディレクターはこういうことを心掛けようという話で納得できる点ばかり。
『さくら荘のペットな彼女』を知らなくてもわかる話と書いてあってたしかに知らない俺でもわかったんだけど、むしろ『さくら荘のペットな彼女』との関わりが全くなかったような。神田空太くんはちゃんと気をつかってる、すごい！というなんとも抽象的なことをたまに挟んでくるだけなので、べつにそいつを持ち出してくる必要はなかったんじゃないですかね……。いや話の中身はよかったんですけどね。
TokyoDemoFestの紹介。
もう登録してあるんで、特にどうということもなく。
ハズレ的なものはなく想像以上にいい感じだった。
あんまり分野も偏ってないのもいいな。IGDAのSIG-Indieはノベルゲー専門っぽい感じだし。 次もなんか面白そうなのがあれば行ってみたい。
最初に内輪ネタ的な質問はやめてくださいと釘を刺されていたんだが、釘刺さないといけないってのはちょっとこわい状況だわな。 丁度俺の後ろのあたりに自称老害とか痛々しいことを言っている仲良い人達的なのが集まっていてああこいつらが内輪ネタ振るような人達かと不安だったが、休憩時間に常識的なレベルで騒がしい程度であとは至って普通だった。まあセッション中に俺のすぐ後ろでくっちゃくっちゃ音立ててガムか何かを噛んでいたのはさすがに頭おかしいと思ったが、幸いすぐ終わってくれたので殴らずに済んだ。
Windows8で起動時に落ちるようになったので設定ファイルを消したら直った、という話があった。
エラーログから見るに、.NET4.5で動いてたのが何かの拍子に.NET3.5が入ってそっちで動くようになったんだけど、.NET4.5で作られた設定ファイルが読み込めないということなんじゃないかと予想した。
手元でWindows8が無いものの.NET4で作った設定ファイルを.NET3.5で読めるか試してみると、やはり無理なようだ。設定ファイルに書かれているバージョンのアセンブリが読めないとな。これはそう簡単に回避できなくないか？困ったね。
まあやるなら.NET4優先で動くようにして、あとから.NET3.5が入っても.NET4で動くままにするとかかねぇ。.NET3.5で作った設定ファイルは.NET4で問題なく読めるし。 ただ.NET4を優先にするとデバッグがめんどうなので1、いっそ.NET4以降専用にしてしまった方がすっきりするかもしれん。
もう一個、視聴を始めようとすると落ちるけど設定ファイルを消したら直ったという報告も貰った。これも同じかなぁと思ったんだけど、チャンネルを開こうとするところまで行ってるので設定ファイルはちゃんと読み込めてるじゃん。そういえば起動時にウィンドウ非表示設定にしておくとチャンネル開いた時に落ちるというバグ報告があった。こっちだな。
とりあえず起動時にウィンドウ非表示設定にするとチャンネル開いた時に落ちるのは直した。ウィンドウのコンストラクタでチャンネル追加削除監視のイベントハンドラを設定してたが、コンストラクタで非表示になってる場合はウィンドウの実体が作られるのが遅延されて、イベントハンドラ内でウィンドウがまだ作られてないのにリストとかにアクセスした！とか言って落ちてた。コンストラクタじゃなくてLoadイベントでやらないといけなかったか。つかそんなところ遅延すんな/遅延するならしても動くようにしろよクソWindows.Formsが。
視聴してるのに今接続してるのがトラッカーかどうか判別したいという話で、今表示してなかったから入れようかと思ったら実は入ってた。接続先一覧のPCP Relay項目でIPアドレス:ポートの後ろにTが付いてたらトラッカー直下なようだ。そういえばそんなの入れた気もするわ……。
ただトラッカーかどうか判別する方法が怪しい。最初に接続できた先をトラッカー扱いしてるんだけど、YPに問い合わせ行ったらYPをトラッカー扱いするのでは……と思ったが、あれ、今YPへの問い合わせしてなくないか……？してなさげ。じゃあいいけど、問い合わせは実装したいなぁ。すっかり実装したつもりでいたわ。無くても大抵動くんだもの……。
YPへの問い合わせとかトラッカーかどうかの判別が怪しいのはともかく、表示はもうちょっとちゃんとしたいな。接続情報は今ToStringで文字列で取得しちゃってるけどもっとちゃんと取得したいのでそのインターフェースを追加したい。追加したいが、けっこう大変なので一旦置いておくことにした。もっと先にやることあるよねー。
ERRORになったチャンネルはある程度放っておくと勝手に切断できるようにしたい。そんなに難しい機能でもなんでもないんだけど、これはいったいどこに入れたらいいんだ。
定期的に何かしたいという意味で丁度いいのはGUIなんだけど、動作的にはUIに依存するものじゃないのでGUIには入れたくない。GUI無くても動く機能だ。同じくHTML UIに入れるわけにもいかない。 じゃあコアの機能か？というとちょっと違うかな。あとから増やしたりしたいのでプラグイン的な何かっぽい。
となるとPeerCastStation.Core.dllじゃなくてPeerCastStation.exeの機能かなぁ。こいつには今UIも入ってないし。しかし、こいつの立ち位置は微妙で、GUIに統合した方がいいだろうかと思ってるのでここに新機能足すのははばかられる。 じゃあとりあえずコアに入れてしまうか。
コアにIChannelMonitorというチャンネル監視・管理するインターフェースを作ってOnTimerメソッドを定期的に呼んでやるようにした。あとはこれを実装したChannelCleanerクラスを作って30分程接続されてないチャンネルはぶち切るようにして完成！ だが困ったことにChannelCleanerはどこに入れればいいんだろう。Coreに入れるのはなんか変だしPeerCastStation.exeに新機能追加するのもなぁ。かといって新しいアセンブリ増やす程でもない機能だし？やっぱりとりあえずはPeerCastStation.exeに入れておけばいいか。切り離すのは簡単なクラスだしな。
もう一個問題はChannelCleanerの設定をどうするかだな。こいつの有効・無効およびチャンネル消すまでの時間とかは設定できるようにしたい。チャンネル消すまでの時間とか誰もいじらないから固定でもいいんだけど、有効・無効の設定は必要でしょう。今は特に設定の統一的なインターフェースとか無くて標準の設定クラスを使っちゃってるんだけど、あれの動作がよくわからんところがあるのでちゃんと調べるか自前で作った方がいいんだよなぁ。まあできれば自前で作るべきだと思う。でも大変。
そろそろドキュメントちゃんとしたいんだけど、静的HTML吐くCMSをまた調べるか……。
.NET3.5で作ってるはずなのにデバッグする時も.NET4で起動してしまうのでVisualStudioが上手くアタッチできない模様 ↩