2006/06/12(月) [n年前の日記]
#2 [iappli] データの結合スクリプトを修正中
今までは画像データとサウンドデータだけをスクラッチパッドに置くようにしてたのだけど、resource に置いていた、敵発生テーブル、BGチップ並びデータ、ゲーム説明用文字列データもスクラッチパッドに置くことにした。ので、結合データのヘッダー内で、1ファイルにつき、データ種類 1byte 分を増やして対応。
resource にデータを置いておけば、.jar にする際に、それらデータも圧縮されるであろう予感も。…今のところ、スクラッチパッド上にはベタデータとして置いてるので、DLするバイト数は増えてしまうのがちと気になる。たしかそのへんも圧縮できる云々の話を見かけた記憶も。後で調べておかないと。
resource にデータを置いておけば、.jar にする際に、それらデータも圧縮されるであろう予感も。…今のところ、スクラッチパッド上にはベタデータとして置いてるので、DLするバイト数は増えてしまうのがちと気になる。たしかそのへんも圧縮できる云々の話を見かけた記憶も。後で調べておかないと。
◎ ヘッダーのバイト数。 :
今のところ、スクラッチパッド = 200Kbyteが上限、という前提で作っているので、
*1
アドレス値やサイズ等は、それぞれ 3byte あれば充分なはずで。
*2
データ種類で 1byte とったとしても、1+3 byte = 4byte というきりのいい byte数になる。
とは思うのだけど。後でもうちょっと容量の大きいスクラッチパッドを使えるようになったとき、スクリプトを変更するのも面倒だな。などと頓珍漢なことを思ってしまったもので、1(データ種類) + 4(アドレスオフセット値) + 4(ファイルサイズ) = 9 byte にしてしまった。
でも、ファイル数が 111ファイルあったりする状態なので、ヘッダー情報が1ファイルにつき 1byte 増えただけでも、全部で 111byte ほどサイズが増加してしまう。111byteといえば1パケット(128byte)に近いサイズ。1パケット分、ユーザさんに余計なDLを強いることに。うーむ。
3bit あればデータ種類も表現できるのだから…。やはり 4 byte に収めてしまおうかな。どうしたもんか。
そんな感じでアレコレ考えてしまって、キーを打つ速度は遅くなりがちだったり。…速い人は、たぶんごちゃごちゃ考えずに打っちゃうのかもしれん。
とは思うのだけど。後でもうちょっと容量の大きいスクラッチパッドを使えるようになったとき、スクリプトを変更するのも面倒だな。などと頓珍漢なことを思ってしまったもので、1(データ種類) + 4(アドレスオフセット値) + 4(ファイルサイズ) = 9 byte にしてしまった。
でも、ファイル数が 111ファイルあったりする状態なので、ヘッダー情報が1ファイルにつき 1byte 増えただけでも、全部で 111byte ほどサイズが増加してしまう。111byteといえば1パケット(128byte)に近いサイズ。1パケット分、ユーザさんに余計なDLを強いることに。うーむ。
3bit あればデータ種類も表現できるのだから…。やはり 4 byte に収めてしまおうかな。どうしたもんか。
そんな感じでアレコレ考えてしまって、キーを打つ速度は遅くなりがちだったり。…速い人は、たぶんごちゃごちゃ考えずに打っちゃうのかもしれん。
◎ 本番(?)アプリに説明画面表示部分を組み込もうとしたのだけど。 :
resource から InputStreamReader を使ってテキストデータを読み出していたのを、スクラッチパッドから読み出した byte 配列に対して行うようにしないといけない。エンコーディングがどうこうとか関係してくるのだろうか。どうしたもんか。
と、しばらく悩んでしまったけど。"resource:///" を "scratchpad:///0;pos=xxxx,length=yyyy" に置き換えればいいことに気がついて、一安心(?)。いや、byte 配列しか無い場合はどうするのか、そのへんやっぱり判らんのだけど。今後の宿題。
と、しばらく悩んでしまったけど。"resource:///" を "scratchpad:///0;pos=xxxx,length=yyyy" に置き換えればいいことに気がついて、一安心(?)。いや、byte 配列しか無い場合はどうするのか、そのへんやっぱり判らんのだけど。今後の宿題。
[ ツッコむ ]
以上です。