マイクロソフトのorigami、発表になったね。もちっとかっこよかった。UMPCのHPも！

ここのニュースにあるように

Microsoft、超小型PC“Origami”プロジェクト公開
http://pc.watch.impress.co.jp/docs/2006/0309/ms.htm

マイクロソフトのorigamiが発表になった。

　やっぱ、昨日の、Intelの「Ultra Mobile PC」よっかは、かっちょいい！

　で、もう、origami projectのホームページ(http://www.origamiproject.com)も更新されていて、最後に、

マイクロソフトのUMPC
http://www.microsoft.com/windowsxp/umpc/default.mspx

と

コミュニティサイト
http://origamiproject.com/default.aspx

にいけるようになっている！！

ほー、もう、UMPCのページができているのですね。
全部英語だけど（＞＿＜！）

中国のケータイアプリ開発事情を、BREWの圧縮解凍関数で考える

　スラッシュドットによると、中国では、ケータイ部品が買えるそうな。。

　携帯電話の部品が買える、中国の電脳街・深セン
http://slashdot.jp/article.pl?sid=06/03/03/0042246

ほー、ナンに使うの？？っていう気もするけど。。
まあ、ケータイ人気、進んでるのかもしんない？？

---

　じゃあ、アプリは？？っていうと、BREW関係の調べモノをすると、結構中国のサイトにヒットしてしまったりする。

　たとえば、BREWの場合、ZIPで圧縮する関数は、なかった気がする（気のせい？）が、
　Unzipは、ある。
　といっても、gzip用なのだが、IUnzipAStreamというインターフェースがある。

　しかし、この関数を利用するためには、非同期ストリームからデータを読み込むIAStreamの方法をしらないとできない。

　そこで、じゃあ、あらかじめ、データを作っておき、それを解凍して表示する（前に書いたブログのような、ゲームっぽいケースでありえる）という場合、どーするのか？？

　っていうことを調べるには、「IUnzipAStream IAStream」と検索エンジンにいれたほうが、参考文献が多く出そうだ。

---

　ということで YAHOOでやると、このとおり
２０個中、半分以上が中国語なのだ（＠＿＠！）

　これ以外でも、ちょっとこみいったもの、IBITMAP_Bltinとかひくと、中国語が出てくる。

　まさに、クアルコム、ソフィアクレイドル、２ちゃんねるのもののあとは、
　ウィリアムのいたずらのページか、中国語なのだ（＾＾；）
　→おおげさですけど。。

　すっげー！！

　って中を見ると。。。

　たとえば、さっきのIUnzipAStream IAStreamで出てくるサイト、プログラムが、あれあれ、おなじ？？とかというケースがある。

　っていうことで、みんな、のりのりで開発してて、いろいろ書いているというよりかは、なにかをはっつけているのかもしんない。

---

　というわけで、中国のサイト、たしかにプログラムは参考になることは、あるんだけど、
　本当に中国でアプリ開発が盛んなのかは、いまいち疑問だったりする。。。

　でも、盛んなのかもしんないね？？

室内アンテナでテレビがきれいに見れるとしたら、ワンセグもいいなあ

　あなたはワンセグを受信可能な携帯電話などを持っているというアンケートをYAHOOでやっていて、13:00現在、

　　　持っている ３％、
　　　４月１日まで購入予定１％
　　　今のところ持つ予定はない 42%
　　　ワンセグ自体を知らなかった 49%

という状況のようだ。つまり、ワンセグにあんまり興味ないということだね。

あ、そうそう、ワンセグで、この前間違えてたこと書いてたので、ここで訂正。
　ワンセグ放送は、地上デジタルの１周波数で放送されるっていうことで、基本的に、放送局がやるんだよね。
　そのなかの、データ通信部分は、たしかにBMLで記述ということになるんかもしんないけど。。

---

　でも、ということは、ワンセグで、デジタルでみれる。。。

　っていうことは、家の中でも、きれいにうつるのかなあ。！？

　ウィリアムのいたずら、引っ越してから室内アンテナなので、ぜんぜんきれいに写らないのだ。。
　昨日も、小笠原亜里沙が２重に見えた（＾＾；）

　ワンセグで、家の中でも(室内アンテナでも）きれいに見れるのなら、
　ワンセグもいいなあ。。

キャラクタを１クラスとして、複数キャラ・背景を動かす一般的な話とBREWの話

この前書いた話のつづきで、３次元のキャラクタを１クラスとして考えたとき、そいつを動かすにはどうするかという話。

（書いた直後に訂正がはいってます。ダブルバッファリングの場合も考慮しました）

　このとき、動きはちょっとづつ、流れるようにうごき、背景も変わるし、キャラクタがいくつも出てきて重なったりするという場合。

　なので、背景をもう一度書いて、キャラを動かしてリドローすると、ずれるような場合

　で、ウィリアムのいたずらは、ゲーム系ではないので、こーいうのを直接やる必要はない（カメラでちょっと似たようなことが必要であったときに、妄想したわけ）

　ここからさきは、ちょっと試しているわけでないので、妄想をメモしたという段階です。
　今忙しくて、試してる暇ないので。。うまくできるかは（＾＾）？？

---

＜＜妄想した方法＞＞

（１）まず、画面のビットマップを取得し、
次画面用のコンパチのビットマップを複製する
　　　→ただし、Updateしないと、再描画されないようなシステムの場合、
　　　　（ダブルバッファリング）コンパチのを用意しなくて、
　　　　直接書いてよい

（２）そのビットマップに次画面の背景と、キャラを配置し

（３）その次画面用ビットマップを、画面に転送して
　　　→（１）でコンパチのビットマップを作った場合

（４）画面のアップデートをする

---

　で、いまのは、一般的な話。ここからＢＲＥＷの話

＜＜妄想をＢＲＥＷで現実するために必要な事項＞＞

（１）まず、画面のビットマップを取得し、次画面用のコンパチの
　　　ビットマップを複製するのは、
　　　・IDISPLAY_GetDeviceBitmapで画面用ビットマップ取得
　　　・IBITMAP_CreateCompatibleBitmapで、
　　　で、コンパチのビットマップが複製できるけど、

　　　IDISPLAY_Updateするまで、画像だったら、再描画されないと
　　　思ったので、この場合は、直接画面に書いてよいかも
　　　・なおIBITMAP_GetInfoでビットマップ情報を取得可能

（２）上記（１）のビットマップに次画面の背景と、キャラを配置し
　　　・ビットマップに対して、書き込めばいいが、
　　　　その際、IBITMAP_SetPixelで、ピクセルで書き込める。
　　　　ここで、ネイティブカラーで設定しないといけないが、それは
　　　　IBITMAP_RGBToNative()で、RGBから変換する。
　　　　→思ったほど、時間がかかんなかった気がした。
　　　　→たしかIGRAPHICSだと、ディスプレイに書いちゃうと思った。
　　　　　このとき、ダブルバッファリングならＯＫだけど、そうでない
　　　　　場合は、コンパチのビットマップにSetPixelで書くカタチ
　　　　　になると思う。　　　　

（３）（１）でコンパチの次画面用ビットマップを作った場合、画面に転送
　　　　・IBITMAP_BltInで、作ったコンパチから画面へ

（４）画面のアップデートをする
　　　　・IDISPLAY_Update

　って、けっきょく、コンパチの場合、ダブルバッファリングを自分でやっているってこと？
　っていわれると、そう。

　IGRAPHICS_EnableDoubleBufferをみると、ダブルバッファリングはすべてサポートされてるわけではない？
　とすると、自分でやるケースもあるのか？ということになるよね。

　で、１６Ｘ１６のキャラなら、ファイルにそのＲＧＢをもっておいて（または埋め込み）で、それを、あらかじめIBITMAP_RGBToNativeすればいいかも。

　クロマキー（色（クロマ）を鍵（キー）として、そのキーの色だったら、下絵を透過させる方法）の場合は、キーになっている色だったら、SetPixelしない。そーすると、下の色になるので、透過したことになる。

　ちなみに、ふつうのWindowsだとBltInでなくBitBltだったと思う。

　まだ、試してないので、一応メモ。