ZERO3[es]のバッテリーメーターの減りが早くなってきたのでリフレッシュして
みました。いったんバッテリーを完全に空にしてからフル充電して、これを2回
くらいやっとけば元に戻るはずです。

バッテリーを空にするために試したのがネットのストリームラジオの連続再生です。
iPAQ のときは CF アダプタに LAN ケーブルつないで、よくデスクサイドの
プレイヤーとして使ってました。

[es] の場合は PHS 接続なので、最初は 24Kbps あたりからおそるおそる実験
開始です。使ったソフトはGSPlayer、回線はデータ定額 (4x 最大128Kbps)。

24Kbps は結構余裕で、48Kbps も OK。予想以上に結構いい感じです。

64Kbps も窓際など回線状態が安定している場所でじっとしていれば大丈夫でした。
64Kbps は MP3 のモノラルなので、音質的にはステレオだと 128Kbps 相当だから
もう十分です。

96Kbps のステレオもサーバーや回線状態によってはたまに途切れたりするものの、
条件さえ安定していればなんとかいけそうな感触です。

ブラウザ使ってるとあんまり速い印象は無いのですが、レイテンシを無視できる
ストリーム再生だとそれなりにスループットが出てるみたいです。少々意外でした。

年末には W-OAM 対応の W-SIM が出るそうなので、これだと速度は 204Kbps まで
出ます。非常に楽しみになってきました。

これ
http://www.willcom-inc.com/ja/lineup/rx/420al/index.html

http://ch09144.kitaguni.tv/e310974.html の続き
CPU 依存の無い共通のバイトコードといえば昔 WindowsCE にもありました。
WindowsCE は小規模な組み込み向けに使われる OS でプラットフォームを選びません。
HandheldPC や PocketPC など、PDA でも当初は SH3, SH4, MIPS などさまざまな
CPU が使われていました。プログラムを作る側も使う側も、同じ OS だけど CPU の
違いを意識しなければならずたいへんです。

そのため一時期 CEF と呼ばれる共通のバイナリ形式が登場しました。やはり仮想の
バイトコードの形にコンパイルされて、実行前にネイティブなコードに変換されます。
一度変換すると以後はネイティブコードのアプリケーションとして振舞います。

しかしながらあんまり使われることは無く、その後のバージョンで PocketPC は
ARM アーキテクチャに統一されてしまったので、CEF の意味もなくなってしまい
ました。ZERO3 も HTC の WindowsMobile 機も全部 ARM です。

WindowsCE 向けにも .NET Compact Framework が登場しています。やはり PC 版と
同じように共通のバイトコード MSIL を使うので、今だったら CPU の種類が多くて
もそんなに困らなかったのかも、、しれません。
(続く)

http://ch09144.kitaguni.tv/e310960.html の続き
CLI の仕様に沿っていれば、.NET Framework 用アプリケーション開発は特に言語を
選びません。C# だろうが VB だろうが。この辺が Java とは少々趣が違うところで
しょうか。

そしてもちろん C++ での開発もできます。C++ といえど CLI に従うので MSIL に
コンパイルされます。C++ なのにネイティブコードにならないのは何となく不思議
な感じがします。

CLI にさえ従っていれば他の言語でもかまわないし、さらにアセンブラを使って直接
MSIL のコードを書くこともできます。

C++/CLI で非常にユニークなのはネイティブコードとの共存ができることです。

言語仕様も拡張されており、C++ のルールにのっとりつつも C# のような言語拡張が
使えて管理された安全なコードを書くことができます。これはマネージドコードと
呼ばれるものです。MSIL です。

同時に従来の C系統のコードがそのままコンパイルできて、従来のライブラリも
リンクできます。こちらはネイティブな x86 等のバイトコードになります。

この両者が1つのバイナリに共存していることになります。

ネイティブコードの部分は .NET Framework 管理下に無いのでアンマネージドコード
と呼ばれます。

ちなみに C# でも、DLL など Win32 API 呼び出しができたりポインタを使った
メモリアクセスができるので、C++/CLI と同じように意図してアンマネージドな
プログラムを呼び出したり書いたりできるようになっています。ネイティブコード
に変換されるわけではないのですが。
(続く)

C# は C言語系の新しい言語の一種です。C# を使ってアプリを作るのは簡単だし
便利だよとよく話を聞くのですが、この場合 .NET Framework まで含まれるので
少々混乱します。

まず .NET Framework というのは Windows の新しい API セット＆ライブラリの
ことです。ツールキットであってクラスライブラリです。OS のさまざまなサービス
を提供しつつ、ユーザーインターフェースやらなにやら便利な機能をたくさん
取り揃えています。

.NET Framework を利用できるのは、MSIL と呼ばれる仮想コンピュータ用の
プログラムだけです。直接ネイティブな x86 等のバイトコードではありません。
これは .NET Framework に含まれる CLR と呼ばれるランタイムが、プログラムの
実行直前にネイティブなコードに変換します。

つまり、JIT コンパイラによって MSIL から x86 へのコンパイルが行われてから
プログラムが走るので、実行時はネイティブコードとしてのパフォーマンスが期待
できます。

このように面倒なのですが

・プログラムは仮想マシンのバイトコードなので完全に管理下に置くことができる。
　不正なコードやバグを除外できる。セキュリティ強化。

・仮想コードなのでプラットフォーム依存を無くすことができる。

等のメリットが考えられます。

仮想マシンや JIT コンパイラなど、動作の流れも特徴もほとんど Java と同じです。

ただし Java は完全に言語仕様と動作環境やクラスライブラリが一体化しているの
に対して、.NET Framework はオープンです。仮想マシンのバイトコード MSIL レベル
で仕様が統一されているので、そこから上のプログラミング言語は特に限定されて
いません。この仕様が CLI になります。

プログラミング言語としての「Java 言語」に相当するのが C# です。C/C++ 言語
における、バグの原因となりやすい部分を言語仕様として改良＆拡張しています。

そのため C# による開発を語る場合は、言語としての便利さと、.NET Framework
における管理された安全性やライブラリの使いやすさとしての便利さと、開発環境
として整っているツールの便利さが含まれているようです。

今後 Vista にあわせて .NET Framework 3.0 としてさらに幅広いサービスが提供
されるらしく、ワークフローにまで及んでくるそうです。今後はネイティブコードが
消滅して Windows 自体、アプリケーションも全部 MSIL で動くようになるので
しょうか。
(続く)

mipmap は pixel 毎に異なるテクスチャを参照するため、その境界がはっきりと見
えてしまうことがあります。

この境界をぼかすために 2つの level の mip テクスチャ間で線形補間を行うこと
ができます。u-v 方向にかかるバイリニアフィルタに対して mip level 方向が
加わるためトライリニアフィルタと呼ばれます。

u方向とv方向の解像度が異なる場合など、向きによって適切な mip level に大きな
差が生じる場合は少々厄介です。

例えばカメラに対して大きく傾いている地面や天井は、元のテクスチャ画像よりも
細長い形状となります。縦方向(画面の奥に向かって)は小さいテクスチャを参照
したいのですが、横方向にはもっと大きな解像度の画像が必要です。

そのため高い解像度のテクスチャを参照しつつ、縦方向(画面の奥)に向かって
縮小をかけます。これが異方性フィルタリング(Anisotropic filtering)です。

ぼけぼけだった mipmap の効果も引き締まって見えるので見栄えのいい画面に
なります。が、きれいに縮小するためには部分的に mipmap のデータを作ってるよう
なもの。重い処理となってしまいます。

傾きの大きいポリゴン以外は効果が小さいので、場所によってどの程度まで
フィルタリングするのか使い分けがいります。極端な例だとビルボードには全く
必要ないわけです。

(前の記事)
http://ch09144.kitaguni.tv/e309230.html