* すべてがOSECPUアプリになる？
-(by [[K]], 2013.08.02)
-ちなみにこのページ名は、森博嗣著『すべてがFになる』のタイトルのパクリです（笑）。
** (0) はじめに
-OSECPUアプリはセキュアです。そしてOSECPUアプリは機能密度が高いです。さらにOSECPUアプリはCPUに依存せずに実行できます。この三つが同時に成立したことで、予想外の相乗効果があると気が付きました。
** (1) きっかけ
-ええとOSECPUアプリでは、画面に絵を描く系のアプリが多いですよね。これは別に深い意味があるわけではなく、字を書いてもつまらないから絵を描いていただけなのですが、とにかくそれが出発点です。
-OSECPUではapp0006.oseで256x256ピクセルのきれいなグラデーションが表示されますが、これはたったの17バイトです。またapp0023.oseは71バイトでbballの模様を描くことができます。app0038の国旗は21バイトですし、app0043のメタリックなボールは30バイトです。これはとにかく驚異的な小ささだと思います。・・・何をいまさらと思うでしょう。
-でもこれを眺めていたら、ふと思ったのです。・・・「あれ、もしかして.oseって新しい画像形式の名前？」って。
-このアイデアに僕はわくわくしました（笑）。
-早速適当な画像ファイルを用意して（下記参照）これをOSECPUアプリにしてみました。それは.pngでは1410バイトでしたが、.oseにしたら587バイトになりました（app0080）。おお、これはいける！
--http://osecpu.osask.jp/download/night.png
~''night.png''
-調子に乗ってもう一個やってみました。.pngでは38233バイトですが、.oseにしたら3311バイトになりました（app0081）。
--http://osecpu.osask.jp/download/osask.png
~''osask.png''
-「.oseは新しい画像形式です。ものにもよりますが、単純な絵なら結構小さくなります。アニメーションもできるのでアニメーションGIFの代わりもできます。・・・あ、そういえばキー入力もできるのでゲームもできます。そういえばファイルの読み書きもできますね。・・・あれ？これは何でしたっけ？？」（笑）
** (2) こうさつ
-まあこれは半分は冗談です。だからそんなに真剣にならずに軽く読んでほしいのですが、仮に.png画像のほとんどが.oseにすることで容量を大幅に削減できるとしましょう。GIFアニメもそうだとしましょう。そうだとしたら、.pngや.gifなんて一部のハイエンドグラフィックツールだけが対応すればいいと思うんです。あとはみんな.oseでいいじゃないですか。
-.oseなら画像だけではなくて普通のOSECPUアプリの実行にも使えるわけで、エンジンは共通にできます。設定ファイルとかもこれからは.ose形式ですよ。データもアプリも.oseでいいのなら、簡単でいいじゃないですか。もちろん頻繁に編集するようなものについては、ベタで持っておけばいいと思います。でもリリース時には.oseにするのです。
-OSECPUは仮想マシンなので、特定のCPUに依存せずに実行できます。だからこそ汎用のデータ形式になりえるのです。そうでないと、x86でしかこの画像は見られません、とかになってしまいます。そんなのはもちろん論外です。.exeが画像形式になれない理由です。
-OSECPUはセキュアなので、データ形式の候補になりえます。もし「画像を見ようと思って開いたら、システムが破壊された」なんてことになったらどうですか？そんな可能性があるだけでももう怖くて開く気になれません。無限ループで帰ってこなくなった、そんなこともありません。これも.exeが画像形式になれない理由です。
-そしてもちろん、.oseが.pngや.gifよりも小さくなるからこんな話が成立するのです。そうじゃなかったら提案すらされないでしょう。
** (3) プログラムについて
-app0080.ask （瑣末な記述は省略しています）
VPtr p:P01;
PLIMM(p, L_PICTDATA);
DAT_SA(L_PICTDATA, T_UINT8, 16384); // 128*128=16384
D8B(4,4,4,4,4,4,4,4,4,4,4,...
（中略）
D8B(6,6,6,6,6,6,6,0,0,0,0,...
SInt32 x:R00, y:R01, c:R02;
junkApi_openWin(128, 128);
for (y = 0; y != 128; y++) {
for (x = 0; x != 128; x++) {
LMEM0PP(c, T_UINT8, p);
junkApi_drawPoint(4, x, y, c);
}
}
--このプログラムでopenWinから最後までのバイトコードは無圧縮状態で16バイトです。だからベタ形式データに対するオーバヘッドはかなり小さいです。ということで単純な圧縮勝負になります。
--このプログラムで、基本8色しか使わない画像は全て対応できます。
-パレットコードを使うとしたら：
-インデックスカラーを使うとしたら：
VPtr p:P01, t:P02;
PLIMM(p, L_PICTDATA);
PLIMM(t, L_COLORTBL);
DAT_SA(L_PICTDATA, T_UINT?, ?);
DAT_SA(L_PICTDATA, T_UINT?, XSIZ * YSIZ);
D?B(?,?,?,?,?,?,...
DAT_SA(L_COLORTBL, T_UINT24, ?);
D24B(0x??????, 0x??????, 0x??????,...
SInt32 x:R00, y:R01, c:R02;
junkApi_openWin(?, ?);
for (y = 0; y != ?; y++) {
for (x = 0; x != ?; x++) {
junkApi_openWin(XSIZ, YSIZ);
for (y = 0; y != YSIZ; y++) {
for (x = 0; x != XSIZ; x++) {
LMEM0PP(c, T_UINT?, p); // c = *p++;
PALMEM0(c, T_UINT24, t, c); // c = t[c];
junkApi_drawPoint(0, x, y, c);
}
}
--多分これがパレットを使う場合の基本形です。
--多分これがインデックスカラーを使う場合の基本形です。
* こめんと欄
-jpgで保存された写真はどうですか？バイトコードを圧縮している圧縮形式がpngより優れているという事でしょうか？ -- ''noname'' SIZE(10){2013-08-08 (木) 14:42:14}
-jpgだと多分勝てないです・・・。いや、うーん、勝てるかもしれない要素は少しあるのですが、でも些細な差だと思います。 -- ''K'' SIZE(10){2013-08-08 (木) 14:58:27}
-pngより圧縮率がいい理由の一つは、OSECPUがtek5圧縮を採用しているからです。もう一つには、画像の特徴を生かして色数を削減していることもあります。たとえばapp0081は全部で5色使われていますが、内部データは2ビットカラーになっていて、つまり4色用のデータ形式になっています。それで前後の関係から5色を正しく再現させています。こういうことができるのは、app0081が単なる「データを圧縮したもの」ではなく、プログラムだからです。 -- ''K'' SIZE(10){2013-08-08 (木) 15:03:54}
#comment
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
