ページへ戻る

− Links

 印刷 

OT​/0003 のバックアップ差分(No.4) :: OSASK計画

osaskwiki:OT/0003 のバックアップ差分(No.4)

« Prev[4]  Next »[5]
3: 2009-07-13 (月) 22:09:46 ソース[6] 4: 2009-11-17 (火) 12:06:25 ソース[7]
Line 26: Line 26:
*** (5)圧縮の予期せぬ効用 *** (5)圧縮の予期せぬ効用
-我々はある程度の規模のプログラムを書くとき、内部にそれなりの構造を持ったテーブルなどを用意する。たとえばジャンプテーブルなどである。こういうものは時に結構な容量になることがある。それが気になると、テーブルを可変長などにして容量を節約するが、これはアルゴリズムを複雑にする傾向がある。 -我々はある程度の規模のプログラムを書くとき、内部にそれなりの構造を持ったテーブルなどを用意する。たとえばジャンプテーブルなどである。こういうものは時に結構な容量になることがある。それが気になると、テーブルを可変長などにして容量を節約するが、これはアルゴリズムを複雑にする傾向がある。
--OSASKアプリの場合、シンプルで何の工夫もないテーブルのままでも、問題にはならない。なぜなら圧縮して小さくなってしまうからである。だから複雑なアルゴリズムを導入することもない。・・・値のほとんどが6bit程度だからこのテーブルはcharにしよう、そして時々出てくる16bitや32bitの値についてはプリフィクスをつけて・・・なんてことはしないのだ。面倒だから全部32bitの単純な配列でいいのだ。上位の00ついてはtekが十分に小さくしてくれる。おかげでプリフィクス機能は不要、というわけだ。 +-OSASKアプリの場合、シンプルで何の工夫もないテーブルのままでも、問題にはならない。なぜなら圧縮して小さくなってしまうからである。だから複雑なアルゴリズムを導入することもない。・・・値のほとんどが6bit程度だからこのテーブルはcharにしよう、そして時々出てくる16bitや32bitの値についてはプリフィクスをつけて・・・なんてことはしないのだ。面倒だから全部32bitの単純な配列でいいのだ。上位の00についてはtekが十分に小さくしてくれる。おかげでプリフィクス機能は不要、というわけだ。 
--ゲームを作るときにキャラクターデータなどがあるだろうが、それも全部BMPのようなベタデータで十分である。心配しなくてもちゃんと小さくなる。そしてベタデータはもっとも扱いやすく、アプリの構造は単純化され、さらに小さくなる(単純な構造のプログラムはもちろんそれだけでもコンパクトになる傾向があるが、さらに単純な構造のものは圧縮も効きやすい)。+-ゲームを作るときにキャラクターデータなどがあるだろうが、tekを前提にするのならそれも全部BMPのようなベタデータのままで十分である。心配しなくてもちゃんと小さくなる。そしてベタデータはもっとも扱いやすく、アプリの構造は単純化され、その分だけさらに小さくなる(単純な構造のプログラムはもちろんそれだけでもコンパクトになる傾向があるが、さらに単純な構造のものは圧縮も効きやすい)。
-高速化のためにアプリの一部にループアンローリングを施しても問題はない。だってそんな繰り返しは圧縮されてしまうのだから。だからアプリの肥大化を気にせずに、必要なアンローリングは積極的に行う。 -高速化のためにアプリの一部にループアンローリングを施しても問題はない。だってそんな繰り返しは圧縮されてしまうのだから。だからアプリの肥大化を気にせずに、必要なアンローリングは積極的に行う。
-ファイルも圧縮できるので、設定ファイルなどの構造を容量を気にして考える必要がない。単純でせこくないのがいいのだ。そうすることで、拡張性のある設定ファイルとなり、アプリのバージョンアップがあっても、設定ファイルフォーマットを変える必要がなく、複数のバージョンをサポートすることもない。 -ファイルも圧縮できるので、設定ファイルなどの構造を容量を気にして考える必要がない。単純でせこくないのがいいのだ。そうすることで、拡張性のある設定ファイルとなり、アプリのバージョンアップがあっても、設定ファイルフォーマットを変える必要がなく、複数のバージョンをサポートすることもない。
« Prev[4]  Next »[5]