仕事がたぶん落ち着いた。気がする。
気がするだけだった。仕事は無限にあっていくらでも働けるのがおそろしい。
週末はまたイベントだが、出す物がないな。PeerCastStation出しとけばいいんだろうか……。
前々から配信を止めてもYPから消えないことがあるって報告があって、しかし再現できないのでわからんでいたんだが、Issueに再現方法が上がってた。 HTML UIから配信開始すると配信止めたあともYPに残ってしまうとのこと。
最初勘違いしてHTML UIから配信を止めると残るだと思って調べたんだがそんなことはなさげ。だがGUIから止めてもHTML UIから止めても残ってしまう場合があったので直した。それで直したーとIssueを閉じようとしたが、HTMLから配信開始した時じゃないですかと間違いに気付いた。まあバグってたことは確かだったのでよかったけど。
再現はばっちりできたが原因がよくわからんのでブレークポイント張ったりして調べるとチャンネルが切断された時のイベントが発生してない模様。もっと調べると、チャンネル切断時のイベントはチャンネルを作った時点のSynchronizationContext上で発生するように投げてるんだけど、これが原因だ。
GUI版はWindows.Forms使ってるのでGUIからチャンネル作った場合はWindows.FormsのSynchronizationContextが使われてGUIのメッセージループスレッドでチャンネル切断イベントが発生するけど、HTML UIでは特にSynchronizationContextを作ってないので、新しいSynchronizationContextが作られてその上でチャンネル切断イベントが発生する。しかしただのSynchronizationContextは動作がとても怪しいのでなんかちゃんと動かないようだ。
使ってるところを見た感じべつにSynchronizationContextを使う必要もなかったので、チャンネル切断イベントは切断検知したスレッドで発生させるようにして完了。チャンネル関係のイベントはどのスレッドで発生するか不明なので気をつけろよということで。
あとはチャンネル情報が文字化けするとかいうのを調べないとだめかな。
今のPeerCastStationのアップデートは、新しいバージョンがあるのを検知したら通知を出して、通知をクリックしたらURLを開くだけという単純なものを実装してた。
でもしょぼいのでもうちょいちゃんとしたのを追加したい。OSXでよく使われるSparkleの.NET版でNetSparkleというのがあるのでこれを使いたい。
で、組み込もうとしたんだがいろいろと問題が。
NuGetで取れるのは.NET4以降専用らしく.NET3.5のプロジェクトには入らなかった。 公式からダウンロードしてきたら.NET3.5用のアセンブリも入ってたが、署名がついてなくて完全名がないので完全名がついてるPeerCastStationとリンクできなかった。
自分で変更してビルドしようとしたが、変更するとソースの同期とらないといけなくて面倒か。……というかNetSparkleはちょっと前に.NET3.5サポートが外れていたのだった。
NetSparkleをPeerCastStationに入れるのはちょっとめんどいのがわかったので一旦諦めてWinSparkle使おう。DLLを落としてきてP/Invokeで呼び出せばいいはずだ。……ん？なんかDLL読めない。ってネイティブDLLだからx86になってんのか。実行ファイルをAnyCPUでビルドしたら64bitで動いちゃうね。 x86でも特に問題ないのでそうしよう。
他には実行ファイルの情報をちゃんと設定したら動いたんだけど、新しいバージョンがありますという程度しか表示してくれなくて欲しかったリリースノート表示がない。なんか公式サイトのスクリーンショットと違うんだが。あとダウンロードボタン押したらブラウザ開いた。インスコはしてくれないの？
リポジトリを見るとリリースノート表示とかアプリ内ダウンロードはリリースされてる0.3より後の機能のようだ。自分でビルドするのめんどくせぇな。ドキュメント少ないのもちょっと不安だ。
ソースを詳しく見てみるがアプリ内ダウンロードしたあとはmsiかexeを起動してくれるだけのようだ。当然と言えば当然だがzip展開してくれるとかない。これはNetSparkleも同じか。
その程度だったら自分で書いても同じだなーということで既に作ってあった簡易的な新バージョン通知機能にリリースノートも表示できるようにしてあげた。 ダウンロードボタン押すとブラウザで開くだけだがWinSparkleの0.3はこれと同じだしなー。
オンラインアップデートは欲を言うといろいろと便利な機能が欲しいところだが作るのは大変なので保留である。 .NETで公式にそういった機能があるといいんだけどClick Onceはなぜか無かったことにされてて困る。Windows Storeは今のところ無理使えないし……。
動くの優先でC#で書きまくるって言ってた気がするが結局Rubyで衝突検出書いた。書く分にはRubyの方が早い。
難しい物はいまのところ必要無いということで、ワールドにつっこんだ物の相互の離散的な衝突検出とレイキャストだけ。 しかもAABBだけ。そりゃ簡単だよ。
ブロードフェイズ的にツリー状にAABBに構成して云々てやった方がいいんだろうけど、どの程度物つっこむかよくわかってないから今はまだいいかー。
とりあえず弾を撃ったら敵に当たって敵が死ぬようになった。弾は点として掃引しても線分なのでレイキャストで連続的に衝突判定が出来る。つまりある程度すっとんでも大丈夫なんだけど、いまAABBの掃引はできないんで壁なんかとの衝突はどうしたもんかね。離散的な衝突判定を極小時間で進めていくのが楽で無難なのかなぁ。
画面的には何も変わってないのでスクリーンショットは省略。
ところで衝突検出を書いたら何故か実行環境による速度比較を始めてしまった。 CRubyの32bit・64bitとJRubyとIronRubyでランダムで100個くらい箱を置いて1000回くらい適当な位置からレイキャストしてみた時間を計った。
やってみたところ、CRuby 32bitとJRubyでは同じくらい。JRubyはえぇ。IronRubyは倍くらい時間かかった。IronRubyおせぇ。 ついでにCRubyを頑張って64bitでビルドしてみたらさらに速くなった。やべぇ。超はえぇ。
と思ったんだけど、あとで確認してみたらレイキャストと変形がバグってて正常に動いてなかったようだ。 むむむ。ちゃんと直してもう一回試してデータ取らないとだめだな。
まあでもある程度のところまでは実行してるのは確かで、CRubyが64bitでだいぶ速くなったのはFlonumのおかげだと思われる。 浮動小数点数を沢山生成しちゃってるからね。
なんで比較始めたか思い出したけど、高速化するのにVector#xとかのアクセサメソッドを呼びまくるのをやめてローカル変数にキャッシュするのは効くんだろうかと調べたんだった。結局バグっててキャッシュするようにしたメソッドをあんまり通ってないのでよくわからないのが正しいんだけど、ふいんき的にはIronRubyでだけちょっぴり効きそうだけど、それでも手間を考えると報われないという結論になりそうだ。
IronRubyはちょっとメソッド呼び出し遅いみたいっすねー。
速度的にはCRubyの64bitでFlonumがとても魅力的ではあるんだが、特にWindowsでは64bit版のCRubyを使うのはとても難しい。 CRuby自体はVC++2010とかでさくっとビルドできるんだが関連するライブラリ用意するのが大変だわ。 今回動かしたプログラムは何も依存する物がなかったのでzlibすら無い状態でビルドした。 自分で拡張ライブラリ作るのもやっぱり関連ライブラリで面倒だろうな。mingw64がよくわからん。
次点は速度的には32bitのCRubyだけど、JRubyも速いよなぁ。CRubyにちょっぴり劣るとは言え同じような速度出てたし。 Javaのライブラリそのまま使えるのもCRubyで拡張ライブラリ書くより楽でいい。 InvokeDynamicとやらがまともに使えるとなるともっと速いかもしれないね。
IronRubyも遅いとはいっても普通にRuby的な使い方するには充分な速度出てるんだよね。 3D計算とかするにはしんどいけど、その辺はC#とかに振っちゃってゲームロジックだけRubyなら問題ないと思われる。 .NETのライブラリそのまま使えるのでC#と簡単に連携できるのは嬉しいし。 ただなんかgem installとかしようとするとめっちゃ遅いのは謎。rdocとかもすごく遅い。正規表現あたりだろうか。
便利さと速度のバランスを考えるとJRubyがとても魅力的だが、俺がJava書けないんだよなぁ。Mirahとかやってみる？泥沼にしか見えないが。