Playstation3 に折りたたみ携帯型 Bluetooth キーボードを
登録してみました。こないだ届いたこれです。
・リュウド RBK-2000BTII

PS3 は Bluetooth を内蔵しているので、Bluetooth 周辺機器を
登録することが出来ます。そもそも標準のコントローラや
専用リモコンが Bluetooth らしいです。

登録メニューには、今のところ
　・BDリモートコントローラ
　・ヘッドセット
　・キーボード/マウス
の３つの登録メニューがあります。(今後のファームアップデートで
増えるかもしれません。)

試したことは無いですが、ボイスチャット用のヘッドセットも無線で
できるなら結構便利かもしれません。

PS3 Linux 上でもきちんと Bluetooth は見えているので、Linux 上
ならもっといろいろなデバイスがつながるかもしれません。
実際 debian の yaegashi さんが Wii コントローラをつないでいます。
・ほげめも Wii Remote on PS3 Linux

●機器登録

Bluetooth キーボード RBK-2000BT2 の登録手順は下記の通りです。
PS3 のクロスメディアバーでの操作です。

(1) 周辺機器設定 → Bluetooth機器登録 → キーボード/マウスの登録

(2) [検索開始] を選択する機器検索を始めるので、
　　RBK-2000BT2 側も [Fn] + [~`] を長押しして認識モードにする。
　　(キーボード右上の Bluetooth LED が点灯)

(3) 検索してみつかった機器がリストアップされます。
　　RBK-2000BT2 は PS3 上で「 Bluetooth Keyboard 」と
　　表示されました。これを選択。

(4) 画面にパスキーが数字で表示されるので、RBK-2000BT2 側でも
　　この数字を入力します。
　　数字キーで入力し、最後に [Enter] を押します。
　　この [Enter] を忘れがちなので注意。

(5) 「登録が完了しました」と表示されておしまいです。

以後、クロスメディアバー上の操作がキーボードだけでできるよう
になります。カーソルキーが使えます。

●キーボード言語選択

そのままでも使えますが、WindowsMobile への登録時と同じように
デフォルトでは日本語キーボードとして認識しています。PS3 では
これを簡単に切り替えることが出来ます。

(1) 周辺機器設定 → キーボードのタイプ

(2) 「英語キーボード」を選ぶ (US側)

これで ASCII(英語)キーボードでも、キーボードの刻印通りに
文字入力できるようになります。

●キーボードによるクロスメディアバーの操作

カーソルキー、Enterキー、ESCキーでほとんどの操作が出来るようです。
オプション表示の(△) キーは [F1] でいけます。
残念ながら (PS) ボタンは見つかりませんでした。
キーボードをつなぐことによって、文字入力は各段に使いやすくなります。
ただしこれらの操作は、必ずしもゲームで使えるわけではないようです。

・カーソルキー
・(○)　[Enter]
・(×)　[ESC]
・(△)　[F1]

●再認識

PS3 本体の電源を入れた後、キーボード側の何らかのキーを押すと
再認識されてすぐ使えるようになります。いちいち PS ボタンを
押さなくてもよく、なかなか便利です。

ついこの間 Folding@Home で 1PETA 超えた
と思ったら、もう 1264TFLOPS です。
Playstation3 だけでも 1000TFLOPS いってます。
かなり増えていますね。

・Fonding@Home Client statistics by OS

OS Type           Current TFLOPS   Active CPUs  Total CPUs 
Windows           164              172703       1798091 
Mac OS X/PowerPC  8                9391         105647 
Mac OS X/Intel    13               4188         23712 
Linux             36               21449        245348 
GPU               43               732          4246 
PLAYSTATIONR3     1000             40305        255338 
Total             1264             248768       2432382 

Last updated at Sun, 23 Sep 2007 09:49:22  

また 何か届きました。

折りたためる Bluetooth キーボードです。
・リュウド RBK-2000BTII

折りたたんだ時はちょうど EM・ONE (標準バッテリー)と同じくらいの
厚みです。電池込みで実測 209g

開いたところ。

大きさ比べ。

↓上が FILCO パピヨン

パピヨンよりもキーが大きく、間に隙間も無いので一般的なキーボードに
近い感覚です。パピヨンと違い数字段にもずれがありません。
キータッチもパンタグラフ式のおかげかストロークがスムーズです。

正式対応しているだけあって EM・ONE とのペアリングも問題なくすぐ
使えました。マニュアル通りです。復帰時も認識に数秒かかりますが、
それ以外は何もせずに使えるようになるのでこれは便利ですね。
WM 端末は外付けキーボード端末として利用しているので、これから
じっくり使い込んでみるつもりです。

キートップの刻印は ASCII(英語)配列ですが日本語キーボードとして
認識されます。もしキーの刻印と入力文字を合わせたい場合、または
ASCII 配列派の方は em1key + asciipatchwm で対応できるかと思います。

・em1key
・asciipatchwm

自分は普段 JIS 配列で使っているのでこのままで十分そうです。
ただ日本語キーボードとしてみた場合キーが足りないので、
[￥｜] と [＿] が打てませんでした。
この辺は em1key のカスタマイズで何とかしようと思います。

よくみると左上に小さい [Esc] キーがありますね。
もし無理やり親指シフトで使うとしたら、パピヨン改 と同じように
alt を割り当てる形になるでしょうか。この場合親指がちょっと窮屈な
感じです。

WM6版の EM・ONE S01SH2 きましたね。
・イー・モバイル、Windows Mobile 6搭載の「EM・ONE α」
・NEWS | eMobile
しかも従来機種もアップグレード可能！
予想していなかったのでこれはうれしい。
最近稼働率が低かったのでちょうど良いです。

WindowsCE(PocketPC) の OS アップグレードといえば、以前
Toshiba GENIO e550 初代 と iPAQ h3630 で経験したことがあります。
両方とも PocketPC(PPC2000) から PocketPC2002 への変更でした。

CPU が ARM に一本化されたり、ボタンレイアウトが iPAQ 準拠に
なったりと、いろいろ変化があったあのときです。
特に GENIO はすぐアップグレードがあることを前提に発売したような
感じで、ARM 採用など最初から 2002 向けのデザインでした。
PPC2000 のまま使ったのはたぶん半年に満たないです。

そのわりに RAM 増設のために本体も送ったりと GENIO のアップ
グレードは結構大掛かりでした。(増設無しも可能)
EM・ONE はもともと本体性能がいいので余裕でしょう。

iPAQ は CD-ROM が送られてきて自分で更新できました。
英語版では ROM が少なかったので、ROM に入りきらなかった一部の
ソフトがダウンロードインストールになっていたようです。
その後しばらく MS のサイトから TerminalServicesClient だけ個別
ダウンロードできたのは、、iPAQ の ROM が少なかったおかげです。

前回迷路を作成するシェーダーを作りました。
・Direct3D ShaderModel4.0 Shaderで迷路作成

でも作成した迷路が本当に端から端までつながっているのか、
壁がどっかでつながっていたりしないか確認するのが大変なので、
今度は自分で探索させてみました。

まず迷路を作り、その後色のついたピクセルが勝手に歩き回ります。

キャプチャだけだと良くわからないので、これも実際に走らせて
ぜひ動いているところをご覧ください。
動いているところだったら、何をやっているのか一目瞭然だと思います。

今回は動きがわかりやすいように 128×128 の初期データが入ってます。
ss03(前回)の initdata.png を使うと 512×512 の迷路になります。
拡大しないとわからないですが暇な時にじっくり見るのにお勧めです。

基本的にすべての探索点は同じアルゴリズムで動いています。
どれも右側の壁伝いに歩いてすべての通路を歩きつくそうとします。
ただしお互いにも衝突するので、狭い路地から出られなくなったり
ショートカットして違う分岐に進んだりと結構ランダムに散ら
ばってくれるようです。

壁伝いに動くため、壁を見失うとその場でくるくる回ってしまい
ます。誰かが助けに来てくれるまでそのままです。

探索点はランダムに左上 (1,1) の点から生み出されます。

シェーダーは下記の 2つです。
　・maze.fx (迷路生成、前回のものと互換性あり)
　・walk.fx (迷路探索)

cpp 側のソースを見るとわかりますが、シェーダーを適用して
Draw( 4, 0 ) で四角形を1つ描いているだけになっています。

処理は全部 PixelShader です。迷路のデータを元画像として
レンダリングすると次のシーンが出来上がるわけです。
使っている画像フォーマットも通常の 32bit (R8G8B8A8_UNORM) です。

walk.fx での内部的なピクセルの意味は次の通り。

R= 0.00 路地
   0.25 衝突判定用予約点
   0.50 探索点
   1.00 壁
G= 向き (探索点と予約点のみ) 0.25単位で 上下左右
B= 向き確定フラグ (探索点のみ)
A= 探索点の色

フレームバッファに転送する際に内部ワーク状態を消すようにした
ので、ちらつきも無く見やすくなっています。その代わり判定
している様子など内部状態は見えなくなりました。

walk.fx で使っている乱数は1つだけ。探索点の生成と探索点自身
の色決定です。移動時の判定順は次の通り。

(1) 未確定で右側が空白なら優先して向きを変える(確定)
(2) 前が空白ならそのまま確定
(3) 右も前も埋まっているなら左に向きを変える(未確定)

単なる画像処理なので探索点はいくつでも構わないし、何千個
あっても、数万個あっても処理速度はほぼ一定です。
動的分岐とリソースアクセス遅延によるばらつきが出る可能性が
ありますが、ほぼ完全に面積だけで速度が決定します。

複数同時に動く可能性があるので、衝突判定はかなり厳密です。
Shader が入力可能なのは 1つ前のシーンだけなので、同じ空白を
複数のピクセルが同時に移動可能と判断してしまう可能性が
あるからです。

この同期サイクルのせいで、1pixel 歩くまでに 3フレームも
費やしています。迷路生成よりも判定が長いのは、確定判定が
追加されたからです。まず maze と違い足跡を正確に消す必要が
あります。さらに右を向いた瞬間もと来た場所が空きになるので、
さらに右手に回れると判断してしまう(戻ってしまう)ことも防いでいます。

これらの判定のおかげでピクセルが同時にいっぺんに移動しても
問題なく処理可能となりました。すり抜けも起こらないでしょう。

迷路の生成 maze.fx は ss03 と同じものですが、乱数計算に
偏りのバグがあったので一部修正しました。これはそのまま
ss03 で使うことも出来ます。

ダウンロードはこちらです。
・wheelhandle_ss04t.zip
ソースだけでなく実行ファイルも入っています。