がんばってPPMファイルのフォーマットを翻訳してみた
まだあきらめていませんでした(殴
Flipnote Files/PPM - DSiBrewのアニメーション部分を翻訳してみました。
っといっても、私は英語があまりわからないのです。
翻訳サイトを元に何とか間とかしてみました。
間違っている可能性は十二分です。
もし間違いがあったらぜひ指摘してください。
括弧内は訳注の場合が多いです。
でも、Google翻訳と他の翻訳ってずいぶん結果が違いますね・・・
ヘッダ情報
アニメーションセクションは0x06A0から始まります。
| アドレス | 長さ | 説明 |
|---|---|---|
| 06A0 | 4 | オフセットテーブルのサイズ |
| 06A4 | 4 | 不明。ペン表示などの設定が格納されている |
| 06A8 | 4 * フレーム数 | 再生される順番に並んだフレームのリストです。 |
以下の記述では、すべてのアドレスは最後のオフセットリストの終わりの相対的なアドレスになります。
また、フレームはファイル内に特定の形式で入っているわけではありません。
なのでこのテーブルを次のオフセットのフレームのリストポイントを見るために読み込む必要があります。00023572の次のフレームは00000000でした。
（ココは特に意味不明。原文 => 「so you have to read this table for the next offset as I've seen the list point to a frame at 00023572 and the next frame was at 00000000.」）
アニメーションフレーム
| 開始アドレス | 長さ | 説明 |
|---|---|---|
| 0000 | 1 | ペンと紙に関する情報 |
| 0001 | 48 | レイヤー1の行エンコード |
| 0031 | 48 | レイヤー２の行エンコード |
| 0061 | ? | レイヤー1、２を格納 |
0000のペンと紙の情報は、ビット単位で情報を詰め込んでいます。
(もしかすると、エンディアンてきな問題でビットを全部、または特定のブロックずつひっくり返す必要があるかもしれません。)
| 開始ビット | 長さ | 説明 |
|---|---|---|
| 00 | 1 | 新しいフレーム |
| 01 | 2 | 前のページをX、Yに動かす |
| 03 | 2 | レイヤー2 |
| 05 | 2 | レイヤー1 |
| 07 | 1 | 紙 |
「紙」は背景色を示します。黒は0、白は1です。
「新しいフレーム」は、前のページとこのページで変化がないなら0。違うなら1になる。と書いてあると思われる。
「レイヤー1、レイヤー2」ペンの色。
| 0 | 使われません |
| 1 | 白か黒。紙の色によって動作が変わる |
| 2 | 赤 |
| 3 | 青 |
ラインエンコード
ラインのエンコードは、1行48バイトで192ラインにわたって上から下の順に圧縮(最適化)してあります。
エンコードの仕組み(ラインコードとかいっているみたい？)は行ごとに2bitで格納していて、4行分まとめて1byteにしているっぽいです。
行はバイトの中のビットと同じ順番で入っています。
たとえば、0行目は、0,1ビットを、1行目は2,3ビット使っています。
ラインコードの値は、読み込む必要のあるバイト数を決定します。(determinsという単語は、determinesの間違いと判断しました)
以下がラインコードの意味です。
| 番号 | 意味 | |
|---|---|---|
| 0 | このラインをスキップします。このラインにはデータが含まれていません。すなわち、何も描画されないと思われます。 | |
| 1 | 符号化されたライン | |
| 2 | 符号化したラインを反転する | |
| 3 | そのままのデータ |
エンコード
ラインエンコードを行う前に、うごメモではレイヤーを使っていることを理解する必要がある。
レイヤーのビットマップは、1ならペンの色。0なら紙の色となる。
符号化ラインと、符号化反転ラインは、4バイトのヘッダーを持っています。
そのヘッダーはどのぐらいのバイトを読み込み、それが何を表しているかを示しています。と書いてあると思います。たぶん。
最初の4つの後のバイトは逆順に読み込まれれます(エンディアンに注意)。
たとえば、8の0は0bit目になります。
これを理解するには、まず行の256ピクセルを読み込みます。それを8で割り、32を与えます(たぶん、8で割って32を足す)。
これは、ラインエンコーディングが使用するバイト数の最大を示しています。(ココはよくわかりません。これまで確保された、かもしれません。もしかすると、たとえば、ライン変換に使うメモリ確保などの助けになるものかもしれません。)
そして、それは4バイトのビット数でもあります。(なにを言っているのかいまいち不明)
0x80000000がたっているときだけ(すなわち、ビット演算確認する)ときだけ、線の最初の8ピクセルが使われます。
たとえば、タイプ1としてエンコードされる場合、格納されるのは80 00 00 00 20です。
最初の4バイトは最初の1バイトはこの行に影響を及ぼし(この行で作用して)、それは行の最初の8ピクセルとなります。(結局よくわからん。effactedはeffectedの間違いと考えた)
次のバイトが読み込まれ、一度展開されたら、6番目のバイトがペンの色に設定されます。(結局意味不明)
もしもう一方のラインがタイプ2でエンコードされているなら、1ピクセルなら紙の色、他のピクセルならペンの色です。(このピクセルはbitをさしている可能性がある？)
下にあるコード部
(memsetとかあるから、C言語だろうか。)u32 => unsigned int
u16 => unsigned short
u8 => unsigned char
だろうか。
コメントも翻訳しておく。
// Set the full line to the current paper colour
行を全部ページ色にセットする。(行をページの色で塗りつぶす)
// Bytes in this line, read and deal with them
この行のラインのバイト。それの読み込みと処理を行う
「outB」と「inB」は事前に確保されたメモリブロックへのポインタです。
「inB」はファイルポインタです。
「outB」は出力データブロックです。
「useByte」はラインの最初の4バイトです。
もしあなたがタイプ3(そのままのデータ、生データ)だけなら0xFFFFFFFFが渡します。
「pen」「paper」の値は、ペンと紙の情報ブロックです。
[EOF]
最後のほうはかなりぐちゃぐちゃです。なにいってるかいまいちわからないんですよね。英語が大してわからんやつが技術的なことを含む文章を翻訳すべきじゃないですね。
ちなみに、colourは、色(color)のイギリススペルのようです。
結構疲れました。
いろいろと用事があるので、しばらく消滅するかもしれませんが、生きていますので。
