Kyo-N's Weblog

Dragonball

物語の後半部分はリアルタイムで見ていなかったので、こういう結末だったのか〜と、いまさらながら納得。

まぁ、名作ですな。元祖と呼ぶにふさわしい。

最終巻は4ページ分 加筆してあるらしいのだが、どこがそうなのか元を見てないのでわからんので、その筋のかた教えてください。確かに微妙に絵柄が違うような部分はあるけども。

しかし、ランチさんは どこにいったんだろうなぁ。

RGB と YUV

引き続き 画面関連のお話。

画像をディスプレイに表示する場合、なんらかのテクスチャ（サーフェス）を使用するわけだが、そのフォーマットは様々である。一般的には RGBの色情報を持つビットマップが使われるが、キャプチャデバイスによっては画像データをYUV形式で返すものがあるので、これに対応しなければならない。

YUV とは、輝度信号(Y)と、輝度信号と赤色成分の差(U)、輝度信号と青色成分の差(V)の3つの情報で色を表す形式（IT用語辞典） とある。基点となる情報の差分でデータが構成されているのでRGBよりも圧縮がしやすい。かつての白黒テレビと互換性をもつために考案されたものらしい。 ^*1

YUVと似たようなものに、ＹＩＱというのもあるが、基本的な考え方は同じでよい。前者はPAL方式、後者はNTSCで使用されている。

さて、YUVとRGBを相互に変換するのはそんなに難しくない。RGBの各要素にある係数を掛けて足せばYUVの要素が得られる。とあるページでは以下のように記されていた。

Y = 0.299R + 0.587G + 0.114B
U = -0.169R - 0.331G + 0.500B
V = 0.500R - 0.419G - 0.081B

また、別のページでは以下のような式もあった。

Y = 0.299R + 0.587G + 0.114B
U = -0.147R - 0.289G + 0.436B
V = 0.615R - 0.515G - 0.100B

似てるけど、なんか係数が違っている。なぜだろう？
これは 各要素の上限と下限を考慮するかしないかの差である。
具体的に言うと、RGBを0~255と扱うか、16~235と扱うかで係数が変わるのだ。

前者はYCC形式と呼ばれ、UとVがそれぞれCb,Crと呼びかえて使われる。

この差は意外と重要で、後者は色の範囲がせまいので、真っ黒に近い黒、真っ白にちかい白など、極に近い色がつぶれてしまう恐れがあるので注意しなければならない。

また、一口にYUVといっても、またこれがさらに細かく枝分かれして存在する。泣ける。
UYVY、YUY2、YVYU、IYU1、IYU2 など。これらの違いはビット長である。
各要素を何ビットで取り扱うかが異なるので、当然データ量と画質に違いがでる。
DirectXで主に使用されるのは D3DFMT_UYVY と D3DFMT_YUY2 である。 ^*2

この２つのフォーマットは、Yを8Bit、UとVを2ピクセルでそれぞれ8bitで構成するという特殊な形をしている。つまり1ピクセルあたりY:8+U:4+V:4=16bitとなる。（UとVが2ピクセルで共有されてるってこと）

DirectShowのヘルプを追っていくと、このあたりはレンダラがいろいろとやってくれるらしいが、自前で色空間の変換を行う場合、様々な注意点があることを認識しておこう。

なんだか、まとまりのない文章になってしまった。１エントリにまとめるには情報が多すぎる。

映像方式

アナログなテレビ放送には 大きく分けて2種類ある。

日本で使用されているのはNTSCという方式。アメリカやアジア諸国もNTSCである。正確には日本はNTSC-JとアメリカではNTSC-Mという差があり、何が違うのかというと輝度の幅（0IRE＝黒）が違う。
ハード的な仕様としては、走査線本数が 525本、秒間 30フレーム、 60フィールドのインタレース描画を行う、となっている。

これに対し、欧州で普及しているのがPALという方式。ヨーロッパで動作するコンシューマゲームを作る際にはこいつを念頭におかなければならない。さて、何が問題になるのか。それはハード仕様を見るとすぐわかる。PAL・・・走査線本数625本、秒間 25フレーム、50フィールドのインタレース描画。

そう。要するに秒間６０フレームで描画することを前提にゲームを作った場合、PALのテレビだと50フレームでしか描画できないのである。このことから、フレーム単位でモーションやアニメーションを計算しているものは スロー再生 ^*1 になってしまう。

また、最近のPAL方式テレビでも60フレーム描画可能な方式のものが出てきており、実質ヨーロッパでゲームを作成する場合は50フレームでも60フレームでも動作するものを作らなければならないのである。

一番よい方法は、両方のテレビで再生できるようにデータを２つ持っておくことだが、実際には難しい。基本となるモーションデータなどを60フレーム用につくっておき、環境によって間引いて表示させる処理などが必要となる。ポリゴンのモデルを表示する分にはこれで問題ないが、ムービーデータなどは手間だろう。50フレームのテレビで60フレームのデータを再生した場合にはティアリングは避けられない。

全世界で規格が完全に統一されるには、当分かかりそうだし、気をつけよう。

フォントクラス

Windowsのフォントから ゲーム中に表示するBitmapフォントを作成するツールを作った。

これに伴い、今までのKyoXでは固定ピッチのフォントしかサポートしていなかったのが、プロポーショナルフォントにも対応。当たり前だが日本語対応、ビットマップ数に制限もなし。

フォント画像自体は、通常のBITMAPで出力するので、後から装飾もできる。（他力本願ともいう）

暇ができたらこれに文字ピッチの操作、あとツールでなくてプログラム実行中にフォントデータを動的に作成するようにしようかな。（実際にはフォントの著作権があるので、勝手にビットマップ作って配布するとまずいからね）