くまりゅう日記

もっと過去の日記
[.NET | BeOS | Blender | COLLADA | fossil | mono | monotone | NPR | OpenGL | PeerCastStation | Riko | Ruby | Silverlight | TRPG | XNA | ゲーム | ゲーム作り | プログラム | | 模型]

2013-01-21

日記

コメントspamくらった……。spamフィルタをおすすめ設定にしてみたがこれで大丈夫だろうか。

[Ruby][OpenGL] ゲーム作り

メインマシンでゲームを作り進めててLOOX Uで動かしたら気がつかないうちにものすごく重くなっていた。 しかも更新処理だ。ぐわあ。

弾もアイテムも出てなくても更新処理が重いんだが、あとは衝突検出くらいしかないな。ここだろう。 と、思ってしらべてみたんだけど、平均20%台ということでそれ以外が恒常的に遅いようだ。

他に重いところなんて心当たりないなーと思いつつ調べてみると、更新処理の時間計測のうちに時間計測結果を表示するテキスト設定が入ってた。こいつか……。 ここでは文字単位で位置・色・グリフを保持するオブジェクトにつっこんでるだけなのでそれほど重くはないはず。 だけつっても結構な回数通るので時間もかかってるんだろうな。

そろそろ限界だろうか。描画はやっぱりRubyじゃ厳しい気がする。特にIronRubyだと。それ以上に厳しいのはAtom Z550なことのような気もするが、こればっかりは同等サイズの新しいマシンが出てくれるか外での開発を諦めるしかないんだが。 とかなんとか言いつつべつに重くてもいいやとそのまま進めることにした。

ステージ内のマップ間移動を実装するためにイベントを配置する。こいつに当たるとイベント発動ってだけのオブジェクトを置いただけなんだけど、なんか上手く動いてない。配置がちゃんといってるのか見るために線で表示してみると、なんか描画がおかしくて変に面が表示されちゃってる描画間違ってるか。 調べると描画頂点数指定が間違っていて頂点バッファの一部を描くつもりが常に全頂点数を指定していた。修正してちゃんと表示できた。

でもこれって今まで頂点バッファをオーバーランして描画してたんじゃないですかね。修正したのをLOOX Uで動かしてみたら今までドライバが落ちていたような表示も問題なく動くようになった。ああ、以前iMacで同じようなことしてOSごと落ちたことがあった気がする。てかその経験からわかりそうなもんなのになんでちゃんと調べなかったのかね。メインマシンで動いたからって大丈夫だと思っちゃだめか。あとANGLEならチェックしてるだろうと過信してました。 とりあえず遅いながらもまだLOOX Uでも動かせる状態なので進められそうだ。

横道にそれたがマップの切り替えは無事できた。あとはマップをある程度作りたいところだが、テキストで書いていくのはつらいのでマップエディタ的なのが欲しいなぁ。本気で作るのは大変だから適当に、しかしながらなんかしら視覚的に設定できるものが欲しいんだがどうしたものか……。

[PeerCastStation] PeerCastStationいじり再開

1.0を出してからあんまり本気でいじってなかったのでそろそろ再開した。

1.0になるとさすがに使ってる人も結構増えるようで、不具合報告とか要望がちょくちょく上がってくる。というより主に要望だけど、できるだけ対応したい。

配信が終了したあとにERRORになったチャンネルが溜まって一つずつ削除しないといけないのがうっとうしいのでERRORチャンネル一括削除ボタンが欲しいとのこと。だったら一括削除ボタンじゃなくて、ERRORになって一定時間経過したチャンネルを自動削除する方が筋だろうというと、ERRORになったチャンネルになったチャンネルは削除しないと再接続できないのでやっぱり一括削除ボタンが欲しいという意見もあり。手動で対応じゃなくて再接続できない方を直そうよそれは。

方針としては、ERRORになったチャンネルを削除しないと再接続できないのはバグなので直す、その上でチャンネルが一定時間ERRORのまま放置されてたら自動削除できるようにする、の二段階で進めたい。後者はもうちょっと仕様を考えた方がいいかもしれんけど。

先にバグ修正から始めようということでERRORになったチャンネルの再接続ができない件を。ややこしいことに同じようなバグが二種類あって、ERRORになったチャンネルに対してUIから再接続ボタンを押しても再接続してくれない(ことがある)というのと、ERRORになったチャンネルに対して視聴リクエストしても再接続せずにすぐに404を返してしまうという問題がある。外から見るとだいたい同じにしか見えんけど、とりあえず試すのが簡単な前者から直そう。

現象を見るとまあとても簡単で、接続しているノードがエラーを返すとこのノードはだめだと無視リストに入れるんだが、トラッカー(配信しているノード)が無視リストに入ってしまうと最初に接続しにいくノードが無くなってしまってすぐにERRORになってしまうようだ。無視リストには3分間入ってるので3分待ってから再接続すると上手くいくんだけど。

トラッカーを無視リストに入れる必要はあるのかとも思うんだが、延々トラッカーに接続しにいくのを回避するのが楽だったからこうしたんだっけかな。再接続する時には無視リストをクリアするのが良さそう。無視リストがあるクラスがいまいちおかしかったのでそれを移動しつつ再接続時にクリアするようにした。今気付いたけど再接続時はノードリストもクリアした方がいいのかなぁ?これはちょっと微妙なところか。

次はERRORになったチャンネルに対して視聴リクエストを送っても再接続してくれない件。これはそんなおかしな挙動ではないな。視聴リクエストが送られてきた時にチャンネルが無かったらリレー開始するけど、既にあったらそれを返そうとして、しかし既にエラーなのでそのままエラーにしちゃってるだけだ。既にあったチャンネルがエラーだったら再接続すべきだな。ちゃんと調べればすぐ対応できそう。


ページのトップへ | トップ «前の日記(2013-01-15) 最新 次の日記(2013-01-23)» | 編集 | kumaryu.net by kumaryu