http://d.hatena.ne.jp/shuji_w6e/20090611/1244730385
おお、懐かしい。
と思ってる人は多いはず。
Java2SE 1.3が登場したとき画面のスクリーンショットやマウスやキー入力のイベント発生させるRobotクラスが追加されたときみんなやったものだ。
おいらも画面のスクリーンショットを転送、クライアント側のキーやマウスイベントをサーバー側に反映してリモートデスクトップを作った記憶がある。
動画でもない限り画面が更新されるとは限らないので、まずは更新されない場合は転送自体をしないというのが最初に気がつくところだったり。その後画面を分割していって更新されたブロックのみ転送をするようになる。また、一定のフレームを出し続けないといけない動画と違って画面全体が一気に更新される必要も少ないので、たとえば分割数を4つだとすると、一気に画面全体が更新されたとしても4フレームに分けて更新するといったことでも割と問題はない。その分フレームレートはあがるわけだし、びっくりするくらいうまくいくものだ。
厄介なのが圧縮。当時はImageIOがなかったので画像圧縮はsunパッケージのjpegくらいしかなかった。jpegにしろpngが使えたにしろ当時の貧弱なマシンスペックでは画像加工関係がネックになるのはご存知のとおり。
白背景に黒文字といった文字の場合JPEGも圧縮率を上げても意外と結構ちゃんと見える。pngは可逆なので画像の種類によってメモリ量が大幅に変わるのに対してJPEGは安定しているのが強い。減色してディザがはいるとpngの圧縮率はどんどん低下していくのもつらい。
クライアントが独自ならばフォーマットも独自にしたほうがいいだろう。実際おいらはYUV変換後UVをまびきまくって転送していた。白地に黒とかはっきりしたものはきれいに見えるからUVはまびきしまくっても問題は少ない。人間の目にはYが最重要と真っ先に気がついた人をほめてあげたい。あと覇256色にするにしてもフィルタかまして圧縮しやすいようにしてからpngへの変換をとうした方がよいかな。
と、ソースのパッケージ構造見てみたらこれサーバーへ送信とサーバーからダウンロード、サーバープログラムの2つなのね。サーバーとクライアントの2つだけかと思ってた。
ちなみに去年のフェスタでえふおうさんとmkeiさんにお見せしたのはpngの画像をAJAXで更新させるようにしていた。もちろん、ブラウザでのキー入力をサーバーに飛ばす処理もしてある。
http://d.hatena.ne.jp/shin/20080504/p1
この時点ではFirefox3は安定版はなく、非常に不安定、Firefox2は低速、safariもGC時間が非常にとろいということで一番安定していたのがIEだけだった。
ローカルでテストをするとフレームレートが15fpsとかは一応出ていたかな。ブラウザによってすごい速度に差がでてたけど、ブラウザの高速化競争をしている今ならもっとフレームレートが高いかもしれない。GC時間と思われる定期的に出る停止時間が一番少ないのが当時がIE6だっただけ。
ただ、いろいろとやればやるほどあらが見える。まず、ブラウザだけだと音が出せない。そしてジョイスティックが使えない。もうこのあたりでアクション系を作るのを断念する。無音でも問題なさそうなものは何か･･･ということでRPGっぽいものにしたのだ。覇邪の封印とかウィザードリィとかハイドライドとか無音も別に普通だしね＞RPG
