おちゃめくらぶ掲示板 - 1659321896

648：御茶目菜子：2011/07/09(土) 16:18:35: レスにょ
みっぴゅさんへ
＞こんなに簡単なプログラムでありながらデータがあんなにも圧縮されるところを実際に体感出来るのって面白いですね！

データ圧縮というのは効果が目に見えるためやり甲斐もあるにょ。
私の目標はPACの所でも書いているように6ビット符号化と同レベル以上の圧縮率を確保する
ことにあったけどOGEはデータによってはそれを越えることが可能になり当初の予定は
概ね果たすことができたにょ。
あと6ビット符号化と比べてデータ圧縮部分は長くなってもいいけどテータ展開ルーチン
だけは短くする必要があるためアルゴリズムはできるだけシンプルにしなくてはならない
という課題も概ねクリアしたしね。
みっぴゅさんが指摘したような下記の問題点はあるもののアルゴリズム自体は悪くないと
自分でも思ってるにょ。

＞でも、よくああいったアルゴリズムを導き出すことができましたねぇ！

一般にファイル圧縮のアルゴリズムとしてよく使われるハフマン符号化は複雑すぎて
圧縮展開プログラムが長くなりポケコンには不適だからより単純なものを考える必要が
あったにょ。
GPRINT用データのような小さなデータの場合は相対的に辞書サイズも大きくなるから
ほとんど圧縮できないしね。
ハフマン符号化では頻度の高いものをより少ないビット数に置き換えることで圧縮を
しているのだけどOGEはそのアイデアを使いポケコン向けにシンプルにまとめただけであり
そこまで高いオリジナリティーのあるものではないにょ。

＞カタカナが混じってるのならば圧縮前の１６進数のみのデータでもボタンを押す回数とかトータル的な時間はあまり変わらない気がしました。。。

そこが私があまりOGEを強く推してない理由でもあるにょ。
カナの場合はアイウエオ以外は1文字につき2回キーを押す必要があるからね。（実際は
カナ入力の前にカナキーを押して終わったらもう一度推すため回数はそれよりも多くなる）
そうするとデータは小さくなっても実際に入力する際のタイプ数はあまり変わらないか
むしろ多くなることさえあり得るにょ。
したがって、いくら展開ルーチンが小さくても導入メリットは非常に薄いと言えるにょ。
というか展開ルーチンを込みだとメリットは全くないかも・・・。
だから自作ゲームでOGEを使ったことは一度もないにょ（笑）

その点、私が強く推しているOMPはBEEPと比べて非常にデータ節約ができるにょ。

ドの音を1秒間鳴らす場合
BEEP 1,222,262（13文字）　→　1A（2文字　※事前にテンポ指定$1を行った場合）

これだけ節約できればOMPの演奏ルーチン部分のリスト（200バイト少々）が別途必要に
なってもすぐにその分はペイできるにょ。
それにGPRINTとは異なりBEEPの場合は基本的にBEEP音階表とにらめっこしないと作れない
のに対してOMPは「Aがド」ということさえ覚えておけば誰でも簡単に使うことができる
というメリットがあるにょ。

OMPも公開時には「CDEFGAB」の普通の音階演奏演奏ルーチンの方がいいという人も中には
いたけど中途半端なものだと使用価値がなくなるため私はこのOMPに拘ったにょ。
音程だけではなくオクターブや＃などの処理の必要性が出てくるためデータサイズが
大きくなるだけではなく演奏ルーチン部分のサイズも大きくなってしまいサイズ面の
メリットが大きく失われてしまうにょ。
それにBASICでは処理が重いためOMPとは比べ物にならないほど音がブツ切れ状態になって
聴くに堪えられなくなるにょ。