ホイール欲しい ハンドル欲しい

28日に発売された Nike + iPod 買いました。
http://www.apple.com/jp/ipod/nike/

靴にセンサーをつけておくだけで、走行距離や速度、消費カロリーが iPod nano
に表示されます。

一見音楽プレイヤーとはあんまり関連性が無いように見えるけど、音声で現在の
状況などを報告してくれるのです。いちいち画面を見なくても大丈夫。

まだ試しに少し歩いた程度ですが、何も設定していないのに距離や速度の表示が
結構正確に出ます。キャリブレーションもできるけど、他の万歩計等と違って
わざわざ歩幅を はかって入れなくてもいい。
ずっとこの点だけが面倒だと思っていたのですよ＞万歩計の歩幅設定


で、これ走行状況が逐一 iPod に記録されておりロガーとしても機能します。
iTunes 経由で Nike+ のサイトに情報が送られて、時間軸とともにグラフ表示
できたり、他のランナーの状況と比較できたりするから結構楽しい。
これを見るためにもう少し走ってみよう、という気になります。

まだ登録数も少ないので、数キロ程度の距離でも日本ランク 700位程度。
走らなくても大丈夫。まだまだウォーキングでもいいポジション狙えます。


足につける無線のセンサーといえばポラールを思い出すわけですが、Nike + iPod
はここまで本格的ではありません。
http://www.polar.jp/html/segments/Running.html

もっと気楽にはじめられて、ネットに登録するのが楽しみで、はまりそうな予感。

だけどやりこんだら心拍計もほしくなるだろうなあ・・というわけで
ハートレートモニタつきの上位機種が出てほしいです。


または、ポラールやガーミンあたりも対抗してオンラインサービスはじめてくれると
面白いんだけど。ネットワーク対応のサイクルコンピュータなんてのも出てほしい
ですね。

コンシューマ系の組み込みハードと PC の Direct3D では、気をつけなければいけ
ない点が異なっています。思わぬボトルネックが発生します。

とあるメーカーが開発した PC 向けのタイトルのサンプルで、非常に動作が重い
ものがありました。しかもモデルデータのせいで処理が重いので、データを軽く
して欲しいとの話でした。またデータのせいで使えるビデオカードにも制約が
出てしまうとの指摘でした。

画面は 3D のフィールドを表示するシンプルな画面で、背景もキャラクタもごく
普通のモデルデータです。

ところが非常に要求スペックが高く、ためしに起動した PC では 1fps も出てい
ない状況でした。

大体予想がつきましたが、おそらく GPU ではなく CPU の方で処理が落ちている
のでしょう。見たところデータフォルダ内には細切れになったテクスチャが大量
に入っていました。


PC の場合、Direct3D の描画 API の呼び出し回数によって速度が大幅に変わります。
そのためエンジン設計の第一歩は Draw の回数を減らすことからです。

描画はできるだけまとめてばらばらのオブジェクトも一回で描画できるようにします。
Draw 呼び出しの内部ではマテリアルやレンダーステートを切り替えられないので、
マテリアルの数がそのまま描画回数の増加につながります。

テクスチャはできるだけシートにまとめ、マテリアルパラメータは可能ならば頂点
に埋め込みます。

マテリアルやシェーダーの切り替えも負荷になるので、切り替えを最小限にするため
には描画の前にソートしておく必要があります。

また ShaderModel3.0 や、ATI RADEON の ShaderModel2.0 では、ジオメトリ
インスタンシングを使うことができます。頂点ストリームにジオメトリやマテリアル
を書き込んでおくことで、一度の描画呼び出しで大量のオブジェクトを描画可能です。

つまり、描画時には必ずこのような描画を減らす工夫が必要だということです。
そうでないと描画呼び出し API の実行だけで CPU サイクルを消費してしまいます。


コンシューマ系の組み込みハードウエアでは、描画 API の Call はそれほど負荷に
ならず、テクスチャの変更もほとんどサイクル数を消費しないものがあります。
そのためつい同じような考えで描画パイプラインを設計してしまうと思わぬ
ボトルネックに苦しむことになります。

WindowsVista + Direct3D10 では、ステート等のバッファを VRAM 上に確保できる
など、より負荷を軽くするためのさまざまな工夫が施されているようです。


Draw 呼び出し回数の次に考えられる CPU のボトルネックはバッファの lock です。
例えばキャラクタのスキニング等で頂点バッファを lock して書き換えると、GPU
との同期待ちで CPU が無駄に待っている可能性があります。

シェーダーで演算すれば解決なのですが、どうしても CPU で書き込みを行う場合は
フレームバッファと同じように頂点バッファを複数持つ必要があります。頂点バッ
ファを POOL 化して、書き換えた頂点を発行するたびに使用するバッファを切り
替えていきます。

このあたりのボトルネックは、今では PIX 等の解析ツールを見れば一目瞭然で
しょう。

新たに複数の文書(TAB)間移動を割り当ててみました。

外付け USB キーボード向けの定義なので、内蔵の QWERTY キーボードでは入力
できないコマンドがあります。エディタのみ考慮しているので、メール等他の機能
では操作しづらくなる可能性があります。

・「ESC + 文字」系の操作は IME を off にしておかないと使えないので注意です。
・「C-X + 文字」系の操作は「Ctrl-X F」「Ctrl-X Ctrl-F」どちらでも構いません。
・「ESC + 記号」は残念ながら定義できないようです。


C-A 　LTOP 行頭
C-B 　LEFT カーソル左移動
C-D 　DELEET 1文字削除
C-E 　LEND 行末
C-F 　RIGHT カーソル右移動
C-G 　UPPG ページアップ
C-H 　BS BackSpace
C-I 　TAB TAB
C-J 　ENTER ENTER
C-K 　DEREAR 行末まで削除
C-M 　ENTER ENTER
C-N 　DOWN カーソル下移動
C-P 　UP カーソル上移動
C-Q 　CTRL 制御コード挿入
C-R 　REDO Undoの取り消し
C-S 　SEARCH 検索
C-U 　UNDO Undo
C-V 　DOWNPG ページダウン
C-W 　CUT 選択範囲切り取り
C-Y 　PASTE 貼り付け
C-\ 　IMESW 漢字変換ON/OFF
C-SPACE 　SEL 範囲選択開始

C-X C 　MDICLS 現在の文書を閉じる
C-X F 　OPEN 新規ファイル読み込み
C-X N 　WINNXT 次のタブに切り替え
C-X P 　WINPRE 前のタブに切り替え
C-X S 　SAVE 保存
C-X U 　UNDO Undo
C-X W 　COPY 選択範囲コピー

ESC N 　END ファイルの終端へ移動
ESC P 　TOP ファイルの先頭へ移動
ESC V 　UPPG ページアップ

以下の内容を win.key ファイルに上書きすると有効になります。

» Read More

ダイアログやメニューなど、前回かなり遅かった部分が早くなりました。
メニュー操作も [←] でキャンセルできるなど自然な感じで操作できる
ようになっています。

ダイアログを閉じるときも、右下に「×」が表示されていてソフトキー2で
閉じるんだとはっきりわかるようになっています。

修正のペースからもいかにも最後の追い込みといった感じです。

USBの外付けキーボードで、メモや議事録のテキスト入力用として使っている
自分にはもう十分な感じです。こんな特殊な用途ですが PWZ3 + patch から
改善されるのは以下の点でしょうか。

・改行、TAB、全角空白などのマーク表示が VGA 画面に合わせたハイレゾになる
・メニューやメニューバーのフォントも VGA サイズで小さく細くできる
・メニューなどの操作が片手だけでできるようになる

これ以外は PWZ3 で満足していたので・・全然使いこなしてないですね

DirectX は当初ものすごい勢いでバージョン番号が更新されていきました。
途中 X4 が抜けているものの、DirectX2～7 までがわずか 4年。
ところが Shader が登場した DirectX8 以降はそのペースが落ちます。

特に DirectX9 は 2002年に登場してから 4年間も使われていることになります。

以前はリアルタイム3Dのテクノロジの更新が API に直結しており、ハードウエアの
進化や新機能の追加は Direct3D API の刷新が必要でした。

ところが今では D3D API ではなく、シェーダー機能の拡張そのものにハードのパワー
が注がれるようになっています。

「シェーダーが必要なわけ」
でも書いたように、もはや 3D アルゴリズムの進化とハードウエアの拡張は別物です。

ソフトウエア技術者はシェーダーという自由の中で、アクセラレータの恩恵を受け
つつさまざまなアルゴリズムを開拓することができます。

そしてハードウエアメーカーは GPU の汎用的なシェーダーパワーの拡充に専念する
ことができるわけです。

もうすぐ Direct3D10 とともに ShaderModel4.0 が登場します。

ハードウエアの都合に強く依存していたシェーダーの仕様は、徐々にその影響力を
弱めています。ますます汎用的になっています。

レンダリングのアルゴリズムは、ハードウエアロジックではなくプログラマに委ねら
れているわけです。さらに近い将来、プログラマではなくグラフィックデザイナー
範疇に含まれるようになるかもしれません。


一般的に画像データは RGB の各色を 0～255 の 256段階で持ちます。RGBがそれぞれ
256段階なので、256×256×256 = 16777216 のおよそ 1677万色の表現が可能です。
これを 24bit カラーといったりフルカラー画像と呼ぶことがありました。

フレームバッファも最終的には 24bit カラーなので、リアルタイムレンダリングの
ピクセルカラー演算も 0～255 の 8bit 整数が使われていました。

ShaderModel2.0 以降、PixelShader 内部は 24～32bit の浮動少数点演算に拡張され
ています。モニタへの出力は 1677万色なので、色数を見たらフルカラーを超えて
おりオーバースペックです。

PixelShader の演算はベクトルや座標値など、もはやカラーの値だけでは済まない
からです。

またカラー値そのものも HDR で持つことが多くなりました。演算中は自然界の数値
を模した高いダイナミックレンジを保っておき、最終的にモニタに出力する直前に
人間の可視範囲で切り取るわけです。

3D のワールドマップ上でキャラクタやオブジェクトを動かしておき、任意のカメラ
で見える範囲をレンダリングするのに似ています。

自然界の微弱なものから強烈な光まで、幅広い光の中から任意のカメラで好きな
部分を「可視可能な領域」としてレンダリングできるようになります。

ブルーとかオレンジとかゴールドとか
料金プランの種類があまりに多くて複雑で混沌としているので、
その中からどれが自分の使い方で一番安くなるか
シミュレートしながらいろいろ計算してみるのが結構楽しいです。
アセンブラの最適化をしているような感じです。

自分で作ったコマンドについ install～ の名前をつけてしまってあせりました。

Windows Vista ではどうやら名前に instal がついたプログラムはインストーラと
判断して UAC の監視対象になるようです。そのため起動すると毎回確認のための
ダイアログがでてしまいます。
エラー終了時にもインストール失敗なのかどうかきかれます。

よく見るとアイコンにも４色の盾のマークがついてるし。

ゲームなどリアルタイム 3D のレンダリングでは、フィルレートがますます厳しく
なります。これはもう当たり前の状態だといえます。

Xbox360 であれ PS3 であれハードウエアの性能は向上したものの、より高い
解像度が求められるようになっているからです。

しかも開発者側も、フィルを無尽蔵に消費できた特殊な PS2 の開発に長いこと浸り
きってしまっていました。

Xbox360 や PS3 の開発がかなり進行している今となっては、実作業を経験すれば
もうこの問題は十分理解できているでしょう。4～5年前の Xbox の開発では
PS2 系デザイナーとプログラマとの間で何度も衝突することがありました。

コンシューマでは、PC 向けビデオカードよりもさらにバス帯域が限られてくるので
さらに描画ピクセル数をきちんと管理する必要が生じます。


なお、Wii に関しては次の記事を見る限り、シェーダーが無く描画機能も非常に
限られている可能性があります。フィルや描画のバランスがどのように設計されて
いるのかはわかりません。
http://pc.watch.impress.co.jp/docs/2006/0920/kaigai301.htm


古くはリアルタイムレンダリングの場合、データ仕様をポリゴン数で切りました。
トランスフォームやクリッピング、ライティング、スキニングなど、ジオメトリ
演算の方が負荷が高かったからです。
もっと厳密に言えばデータ負荷の目安はポリゴン数よりも頂点数です。

今のハードの場合、呼び出し方を間違えなければ頂点数はそれなりに出るし、
一度ストリームに乗せてしまえば GPU だけで全部やってくれます。

むしろシェーダーによって重いピクセルが多いので、如何に描画ピクセルを減らす
かが負荷の目安となります。なので、データ仕様はどちらかといえばシェーダー
毎のピクセル負荷と面積で切ることになります。

もちろん面積はオクルージョンカリングが有効な条件を満たしているかどうかが
鍵です。あらかじめ Z バッファを作っておくか、常にカメラの手前から描画する
ことでレンダリングするピクセル数はほぼ一定量になり、ピーク負荷も求まります。

例えばフルにノーマルマップを使うなど重い背景データがあったとします。
この背景のマップオブジェクトのシェーダーが一番重いとわかっているなら、背景が
画面いっぱいに描画されいてるケースで最も負荷が高くなります。

キャラがカメラの手前ぎりぎりまで近寄って、どんなにアップで表示されようとも
負荷は上がりません。むしろ描画すべき背景の面積が減って相殺され、かえって
負荷が軽くなるわけです。


ただしこの負荷の計算はあくまで「alpha 値を含まない不透明ポリゴン」にのみ
当てはまります。カメラアングルや状況によってめまぐるしくピクセル負荷を上げる
要因となるのは「影」と「エフェクト」です。

影は今のハードウエアと描画アルゴリズムではとにかく(ひたすら)重い処理です。
機会があったら解説します。

またエフェクトでは煙や光物など、半透明のオブジェクトが画面いっぱいに重なって
描画されるともう終わりです。処理落ちどころではありません。

この2つのピクセル負荷は一定のピーク値として計算できないので、非常に苦しい
ところです。


またエフェクトのようにあとから乗せるパーティクル系のオブジェクトでなくても、
マップとして配置する半透明のガラス等でも別の原因で負荷が高くなります。
さらに木々の葉っぱなど、Alpha や texkill でピクセルを捨てるケースがあると
オクルージョンカリングが無効になることがあります。

それどころか、オクルージョンカリングのために先に Z バッファだけレンダリング
する場合も、半透明や抜きのあるポリゴンは完全に先行レンダリングできません。


GPUの負荷
・エフェクトなど半透明ものは完全に追加のピクセル描画となる
・パーティクルは重なることが多く、カメラ位置によって面積が極端に変化する
・マップ配置物でも透過や抜きはオクルージョンカリングを阻害する

CPUの負荷
・加算以外の半透明オブジェクトは描画時にZソートが必要となる


だから alpha 成分を含む半透明オブジェクトは、エフェクトにしろマップ配置に
しろ大量かつアップで描画されると重いのです。

それまでコンシューマをやっていたチームが、新たに PC系ビデオカードでゲームを
作ろうと評価を始めると、エフェクトなど半透明の描画が遅いので引っかかって
しまうことがあるようです。

でもよくよく話を聞いているとポリゴンを重ねすぎているだけのように見えます。

半透明の描画が通常のポリゴン描画よりも遅いのは当たり前です。
唯一当たり前じゃなかった特殊なハードが PS2 です。

PS2 には PixelShader どころかマルチテクスチャ等の pixel 演算系機能が無いので
表現力を上げるにはマルチパスを用いる必要がありました。

なのでエフェクトもひたすらポリゴンを重ねて半透明を大量に使う傾向があります。
PS2 は GPU (GS) にオンチップで VRAM を搭載していて、その転送バスは 2560bit
(147MHz で 47GB/sec) もあります。16 pixel/sec と並列度も高く、稀に見る
フィルレートの高さを持っていました。

これなら半透明など Pixel の Read/Write を頻繁に繰り返してもさほど速度が
落ちません。


オンチップでバスの太さを選んだ代わりに容量が犠牲になっており、VRAM はわずか
4M byte しかありませんでした。

4M byte だとフレームバッファだけでも一杯になるので、さらにインターレースを
用いて半分(640x240)で済ませたり、横の解像度を若干削ったり(512)します。

例えば 640x480 で color 32bit, depth 32bit だと 2.4M と半分以上も消費します。
512x240 まで削ると 1Mbyte くらいで収まります。

フレームバッファが小さくなるとさらにフィルの負担が減ることになります。

もちろん半透明といっても、等視点が変わるケースではソートが必要になるため
完全なコストフリーではありません。だけど他のプラットフォームに比べたら
圧倒的に(異常に)速かったわけです。

そんな作り方に慣れてしまっていると他のハードを使ったときに困ってしまいます。

半透明は極力減らすようにとデザイナーに伝えても「前はこうやって作ってたから」
となかなか理解してもらえないのです。


例えば同世代(?)の Xbox は、CPU と共有のバスで 6.4GB/sec の帯域を持っています。
その代わり 64MByte 全部に GPU が直接アクセスできます。

pixel 並列度で 1/4、バスの転送能力で 1/7.5、だけど VRAM は 16倍。そして
マルチテクスチャやプログラマブルなシェーダーを搭載しています。

この場合半透明をひたすら重ねる作り方は自分の首を絞めるようなもので、できる
限り重ね描きを減らさなければなりません。

リッチな表現はマルチテクスチャやシェーダーを使えばいいので、むしろマルチパス
など重ねて描画する必然性が少ないともいえます。


同じようにいまどきの PC のビデオカードも、メモリアクセスが無尽蔵にできる
わけではありません。GPU 自体の膨大な演算能力に比べるとバス帯域はそれなりに
限界があります。

例えば GeForce79000GTX のメモリが 256bit バスの 1600MHz だとすると
51.2GB/sec です。これでもべらぼうに速いんだけど数値上は PS2 の 47GB/sec と
それほど差がありません。

そして PC はよりハイレゾが求められるので、例えば 1920x1200 だと 32bit color,
32bit depth のフレームバッファだけで 18Mbyte です。
たったこれだけでも必要な転送量は 7～18倍 にもなってしまいます。
HDR をまじめにやると color は 64bit です。


この描画面積を考えると PS2 比の転送能力はずっと落ちていくことになります。

それだけ PS2 が特殊だったといえます。

できる限りピクセルを重ねずに、ピクセル1つにかける演算を重視します。
GC, Xbox1, Xbox360, PS3, PC (D3D9) と、その傾向は徐々に強くなっています。

半透明が重いのは当たり前という前提でまず描画の設計を見直しましょう。

もうすぐ PS3 が登場して、ようやくメジャーハードでハードウエアシェーダーが
当たり前になります。1年前に登場した Xbox360 を筆頭に、ShaderModel3.0 が
リアルタイムレンダリングで必須になるわけです。

本当は 2002年に発売された Xbox1 に ShaderModel1.x が搭載されており
シェーダーの時代はとっくに始まっていました。

あまり注目されなかったのは販売台数のせいもありますが、ShaderModel1.x では
機能的制約が大きかったのも一因でしょう。

特に PixelShader で使用可能なステップ数は 演算8+テクスチャ4 の 12個で、
演算制度も 9～12bit 程度の固定少数でした。

もちろん海外での事情は異なっており、Xbox も PC ゲームも人気があるので
シェーダーのノウハウの蓄積はずいぶん先行しているといえます。


シェーダーの登場によって、開発するプログラマの手間は結構増大します。
固定機能の時代はハードに設定すれば勝手にやってくれたジオメトリやライトの
演算も、まるで時代が逆行したかのように自分でやらなければいけなくなりました。

特に初期のシェーダーはアセンブリ言語で記述していたため、拒否反応を示す
人も多かったようです。

ではなぜそこまでしてシェーダーが必要なのでしょうか。


ハードウエアロジックでの実装はたいへん時間がかかると考えられます。
設計から試作、量産まで、実際に動いて使えるようになるまでどれだけの手間と
時間がかかるか想像もできません。

それでも GPU はテクノロジの進化によってさまざまな機能を実装できるように
なりました。もちろんひたすら高速化のために並列度を上げていけばいいんですが、
それだとトランジスタ数よりも先に、メモリ速度やバス帯域が限界に到達して
しまいます。

そのため、ただただ速度を上げるよりも、より美しい描画を行うために機能を割く
必要が生じます。

ただしこの分野はアルゴリズムの問題であり、どんなアルゴリズムを、どんな仕様
でハードで実装すればいいのか取捨選択するのが難しいのです。
アルゴリズムの研究の進化も早いですから。

だったらプログラマが自由に命令を選択できる方がいいのではないか、そう考える
のも自然でしょう。


ハードウエアシェーダーの登場によって、プログラマが自由にハードウエアの演算
ロジックを変更できるようになりました。

プログラマがハードの機能を選択するのに必要な時間はごくわずかです。いくらでも
設計と試行、フィードバックを繰り返すことができるのです。
ハードロジックを設計してチップを製造する時間とは比較になりません。


ハードウエアアクセラレーションの恩恵を受けつつ新しいアルゴリズムの開発が
短期間でできるようになり、一気にリアルタイムグラフィックスの分野が華やかに
なりました。

アルゴリズムを開拓する人にとってはたいへん魅力的なものです。

そしてシェーダーはハードウエアでしかできなかったさまざまなアルゴリズムを
アプリケーション化してくれます。他の人が作ったシェーダーをもらってきて
使うこともできるわけです。


もう１点、シェーダーがどうしても必要だった理由があります。

GPU の開発会社や Direct3D 等の API を設計する Microsoft 等と、実際にゲーム
等を開発する現場とはどうしてもそれなりの距離や隔たりがあります。

実際に現場が欲しい、リアルタイムレンダリングで欲しい機能と、ハードに実装
される機能は必ずしも一致していませんでした。

頂点カラーの演算方法、値の持ち方、ジオメトリブレンディングの仕様、ライティ
ングの仕様など。

固定機能の時代は、使わない機能やオーバースペックな機能であってもハードに
実装されているため使わざるを得ませんでした。また API の設計によっても
制限を受けます。


むしろ DirectX3～6 等、CPU だけでジオメトリ演算を行っていた時代の方が
ゲームにあわせて自由に頂点や演算を設計し、不要な演算は徹底的に省いて必要
最小限にすることができました。


DirectX7 世代のハードで Hardware Transform and Lighting が搭載され、
演算が極めて高速になったのは望んでいたことでした。
が、速度は速くなったのだけど、逆に使いづらい制約も増えたなと感じたものです。


DirectX8 でシェーダーが登場し、不満だった部分も全部再設計できるようになり
ました。CPU 演算時代の自由度と、GPU の速度の両方を手に入れたのだから
シェーダーは最高です！

きちんと
公式ページを見たら、詳しい使い方や設定などが丁寧に解説してありました。

・導入ガイド
http://www.villagecenter.co.jp/soft/wzmobile/guide/

・WZモバイルでブログを作ろう
http://www.villagecenter.co.jp/soft/wzmobile/blog/

先にこれを読んでおけばよかった。


全体的にですが、機能はそれなりに豊富で良く実装してあるのではないでしょうか。

使いにくい印象を与える原因はおそらくこんなところでしょう。

・操作や反応が遅い(テキスト編集部分ではなく、ダイアログやメニュー等の UIが遅い)
・独自の UI 設計なので、WindowsCE/PocketPC の暗黙のルールが通用しない
・基本的にテキストベースなので、全体的に見た目の印象が良くない
・ベータなのでまだ不具合が残ってる

描画などのレスポンスが速くなるだけでも、操作のストレスはだいぶ減って
くるのではないでしょうか。バグや不具合は当然直るものとして。

テキストエディタで文章を入力する分には問題なくて快適です。
個人的には、普段持ち歩く携帯電話(PDA)でこれだけしっかりとテキスト編集が
できるのだからこれだけで満足です。

実は ZERO3 でメール使うのははじめてです。
あらためて試してみると W-ZERO3メール も Outlook もその使い勝手に結構苦戦中。

てこずりながらも WZメール も試しました。
pdx メールの自動受信は無いものの、一般的な pop3/smtp アクセスが可能です。

すっかり携帯メールや webメールの気楽さがしみついてしまってるので、久しぶり
にやるメール設定がかなり面倒です。全部ゼロから打ち込むのだと覚悟を決めたら
何とかなりました。

画面構成 メール一覧＋プレビュー で前回のエントリの「ウェブ」と同じ。

送受信はバックグラウンドで行われており、待たされることも無くキー操作を妨げる
ダイアログも出たりしません。

動作はかなり重たいです。メニューや操作は試行錯誤と慣れが必要でしょう。

ただ設定は細かくできるので、一旦セッティングが決まってしまえばそれなりに
使えるかもしれません。デフォルトだと返信時に signature が付いてしまいます。
この辺のテンプレートも自由に書き換えることが出来ました。



まだ機能的に不安定な部分があるものの、そこはベータなので今後直っていくで
しょう。標準の電話帳との連動とかその辺は不明です。

メール等のベースフォルダを SDカード に設定すると、サスペンドからの復帰に
時間がかかるようになってしまいました。メインメモリに移動したら大丈夫でした。

メニューの「ツール」＞「ベースフォルダ設定」で存在しないフォルダを割り当
てると、WZモバイル が一旦終了してもう一度フォルダ設定画面になるようです。


こんな感じで WZ Mobile に含まれる機能は、メール、ノート(メモ)、ブラウザ、
タスクマネージャ、ファイラーと多岐にわたります。

メールにはアドレス帳が付いているし、データをタイムスタンプ順にカレンダー
表示する機能もあります。ノート機能を使うと一見スケジューラのような使い方が
できます。



なんとなく携帯電話の基本的な機能をカバーしてるようですね。
テキストエディタを中心に据えつつ、独自の携帯電話 UI/アプリ を構築しよう
としてるのかなと、そんな気がします。

WZモバイル 画面で選択できる「ウェブ」は、テキスト形式のブラウザ機能でした。
html の表示が可能でテキストエディタ内で可能な分だけタグが処理されます。
フォームも使えるので「これを使って blog に投稿しよう！」という趣旨のようです。

インターネットが普及し始めたころに使っていた Lynx を思い出しました。

通常のブラウザと何が違うのかといえば、フォーム内のテキスト編集が使い慣れた
テキストエディタでできるということ。
上手く活用できれば今後　長文　のエントリが増えるかもしれません・・。

さて実際の投稿ですが image ボタンが多いとたどり着くのに少々苦労
うーん、script のせいかタイトル入力ができずにうまく投稿できませんでした。


左から管理画面(プレビュー付き)と、全画面のブラウザ表示、右はRSSの画面

WZモバイル には、本当はテキストエディタだけではなくいろんな機能が含まれています。
いまさらだけど他のアプリも立ち上げてみました。

・WZモバイル (メイン画面)
　　・メール
　　・ノート
　　・ウェブ
・WZエディタ
・WZタスク
・WZファイラー

さすが WM5 対応とあって、メニューも設定も画面切り替えも片手だけでできました。

片手で操作できるのは結構便利なので、個人的には慣れればそれなりに使えるかなと思います。
もちろん独自 UI の もたつく描画 と ちょっと違う操作感にさえ　慣れれば　の話です。


WZモバイル アイコン (メイン画面) から起動すると「メニュー」＞「画面」＞「基本設定」
を選べます。ここでメニューやダイアログに使うフォントの設定ができるようです。

6ポイントかつ太字を解除するとこんな感じ(右側)。
カーソルの描画もちょっと速くなった気がします。

→

元の設定(左)に比べると、メニューやステータス行も細く小さくなって本来の VGA らしい
画面になりました。
この辺が独自にウィンドウのウィジットを描画してるメリットなのでしょうか。

メールはまだ使ってなくて、ファイラーも慣れるのに結構時間がかかりそうです。
せめてもうちょっとエディタ以外の部分の描画や操作が速ければよいのですが、、

文章書きと WZ Mobile Editor

W-ZERO3[es] で外付けキーボード経由で使用しています。

[es] は USB の外付けキーボードが使用できるため、シグマリオンや
モバイルギア等、かつてのキーボードつき WindowsCE 端末同様に本格的な
文章入力用として利用することができます。

唯一の問題は・・それに耐えうるだけのテキストエディタが無かったことでした。


なので、PocketWZ3 用の WindowsMobile5.0 パッチには非常に感謝しています。
http://www.digiyama.com/zero3es/pwz.html

このパッチのおかげで文字入力用端末としてノートPCを持ち歩かなくても
済むようになりました。

PocketPC 用テキストエディタは他にもありますが、
それでも PocketWZ が必要な理由は純粋に機能面にあります。

・ファイルサイズ等、特に制約が無いこと
・書式など細かい設定ができること
・操作の UNDO ができること
・キー操作を自由に再割り当てできること

PocketPC はもともとキーボードが無くてペン操作のみだったことから
キー操作についてはあんまり考えられていないものばかりでした。


ようやく登場した WZ Mobile Editor にも大変期待しています。

WZ Mobile Editor (WZM) で一番気になっていた

「キー配列を自分好みに書き換えられるか」

はほぼ大丈夫なことがわかりました。
フォルダに入っている win.key を書き換えるだけで自分のキー配列が作れます。
(Emacsもどき)


同じように *.mnu や *.btn を書き換えることで
メニューも自由にカスタマイズできるようです。
割り当てる機能名が若干わかりにくいのが難点ですが。


WZM は検索やファイルオープンなど、Dialog を用いる操作で
結構待たされます。この点は PocketWZ3 (PWZ3) の方が高速です。
メニュー周りも PWZ3 の方が軽快に感じます。
描画の問題のようです。

一般的な編集操作は、PWZ3 同様に必要十分な速度で使えています。


あとはやっぱり正式対応なのが嬉しいところです。
特に PWZ3 + パッチではフォント周りに制限があり、
サイズによってはカーソル位置が見かけとずれる等の問題がありました。
WZM はもちろん大丈夫。


マクロ系も見当たらないので
現段階では PocketWZ3 より機能ダウンしているように見えます。


Editor のみですがまとめるとこんな感じ

・WM5 への正式対応がまずは嬉しい点
・最初から作り直し(?)で機能的に PWZ3 に及ばない部分もある
・Dialog 等の UI は描画が重くて操作も結構待たされる

個人的には PWZ3 でも使わない機能が多かったので
シンプルながら必要な機能はほぼ満たしていました。
まだベータ版なので、製品版に向けてのこれからに期待です。

その１ W-ZERO3[es] のファームを 1.01a から 1.02a に更新しました。
http://wssupport.sharp.co.jp/download/ws007sh/update_sp2/

一回目
　最初のリセットで再起動の直後白い画面で停止・・
　→ハードリセット

二回目
　今度は前半のアップデート完了！
　また再起動がかかって後半が始まる前に白い画面で停止・・
　→ハードリセット

三回目
　だめもとで実行したらアップデートまで進んで完了
　今度はいきなり後半だった模様

３回目にて何とか 1.02a に更新できたみたいです。
けどいまいち自信が無い。


その２ iTunes につないだら iPod nano の更新が来てました

　ダウンロード後更新開始→ずっと更新中のまま進まず

　最初の iPod 本体の再起動の後、
　Eject でドライブは Unmount されたのに
　USB デバイスとして中途半端に認識されたままなので
　再認識されずに止まっているらしい。

　無理やりケーブル抜いてさし直したら進みました。


すんなり行かないのは心臓に悪いですね。

Windows Vista RC1 は ActiveSync を入れなくても
ZERO3 など WindowsMobile5.0 の PocketPC が
そのままつながります。

Outlook の同期はできませんが、
いちいちパートナー設定しなくても良いので
外部ストレージのように気楽に使えて便利です。

ためしに VisualStudio2005 に WindowsMobile5.0 SDK
を入れてみました。

既存のプロジェクトを読み込んでみたところ
XP + ActiveSync と同じように Device でのデバッグも今のところ OK。
使えています。

いつも人に「なんでそんなに小さい音で聞いてるのか」と言われます。
(小音量派？地獄耳?)
最近のデジタル系プレイヤーはあまり音量を絞ることができなくて
苦労しています。


●そのままでぴったりに設定できる
・iPAQ h1920/37 (ボリューム以外に設定画面で調整できる)
・NW-MS9


●ぴったりに設定できるが音量を毎回設定する必要がある
・iPod Shuffle (旧) 最小位置(無音状態から+1)
・ぷれいやん(旧)


●GSPlayerのプリアンプでぎりぎりまで絞るとOK
・iPAQ h3630/2210 最小位置でも大きい
・GENIO e550 最小位置でも大きい
・W-ZERO3[es] 最小位置でも大きい


●設定できない、最小位置でも大きい
・V702NK
・V905SH
・iPod nano
・iPod (HDD系)


最近 iPod shuffle から nano に買い換えたら、
最小でも音量が大きくて困りました。
いろいろ探してやっとみつけたのがこの2つ

・SHURE レベルコンバータ
・ELECOM TV用ボリュームつきヘッドホン延長コード(3m/5m)

ELECOM のは長いので、切って短く改造しています。
今はこの2つを使い分けてます。
好きなヘッドホンが使えて快適になりました。

WZ Mobile 来ましたね
WZ Mobile

MobileGearII の頃からずっと PocketWZ を使っていたので
うれしい限りです。

とりあえず MultiLevel UNDO ができてキーバインドを自分で
好きなように設定できれば満足です。

外付けキーボード用にカスタマイズします。

早速Emacs風の定義を作ってみました。
まだまだ「もどき」だけど

win.key に上書きすると使えます。
(元のファイルは保存しておくようにしてください)

» Read More