FreeBASIC GfxInternalFormats
目次→FreeBASIC のハッキング→FreeBASIC でのハッキングのための情報→Internal graphics formats←オリジナル・サイト
FreeBASIC が画像を表すために使う内部形式に関する情報。
画素形式
描画モードが、
Screen (Graphics) か
ScreenRes 関数で設定されると、
GfxLib は、標準のシステム・メモリでフレーム・バッファを作成して、モードのために適切な内部の画素形式を用意します。
基本的に、3つの内部の画素形式が存在して、選択された画面の色深度に従って、下の表に示したようになります:
画面の色深度 | 1画素あたりの内部のバイト | 範囲ビットマスク | 画素形式 |
1bpp | 1 | &h1 | パレット色索引 |
2bpp | 1 | &h3 | パレット色索引 |
4bpp | 1 | &hF | パレット色索引 |
8bpp | 1 | &hFF | パレット色索引 |
15/16bpp | 2 | &hFFFF | RRRRRGGGGGGBBBBB |
24/32bpp | 4 | &hFFFFFFFF | AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB |
全ての描画操作は、この RAM フレームバッファで、働きます。
実際のディスプレーで、表示が更新されるとき、GfxLib は、実際のディスプレイ・メモリに、フレームバッファの内容をコピーします。その過程で、現在の内部の画素形式から、実際の表示が使っている画素形式に、自動的に変換します。
内部の画素形式を、3つに制限することによって、ライブラリは、あり余る程の実際の表示形式に対処しなければならないことを、防ぎます。
色の値
色を受け入れる描画の基本命令(原始関数)を呼ぶとき、色の値は、2段階の方法を使って指定されます。
8bpp 以下のモードで、色の値は、現在のパレットの、ダイレクト 8ビット色索引でなければなりません。そして、色の値は、8bpp 以下のモードのための、内部の画素形式に合致しています。
より高い色深度では、色の値は、常に
&hAARRGGBB 形式になります。
これは、
RGB と
RGBA マクロが返すものであり、24/32bpp の内部の画素形式表現と同じものです。
現在の色の深度が、24 か 32bpp であれば、色の値が、常に
&hAARRGGBB 形式なので、色の値が、変更なしで渡されることを意味します。
15/16bpp モードが使われていると、内部的に、それぞれの基本命令(原始関数)は、自動的に、色を、
&hAARRGGBB 形式から、
RRRRRGGGGGGBBBBB の、内部の画素形式に変換します。
(この過程で、アルファ・チャンネルが失われることに注意して下さい。15/16bpp モードは、アルファ・チャンネルをサポートしないからです。)
色の値が、3つの画素形式の、いずれか1つに決まった時点で、基本命令(原始関数)は、現在の色の濃さでサポートされている範囲に、色の濃さを制限します。このとき、範囲ビットマスクとともに、ビット
And 操作を使います。
それで、例えば、8bpp では、渡される色の値は、
&hFF によって
And 操作されます。
透明性に関する注意
8bpp 以下のモードで、色索引 0 は、常に透明色として扱われます。透明性をサポートする
Put モードのためです。
より高い色深度では、
RGB (255, 0, 255) は、常に透明色を表します。
15/16bpp モードで、これは内部の値の
&hF81F に変換されます。
24/32bpp モードでは、
&hFFFF00FF になります。
24/32bpp モードで、
Put は、色の値の、赤、緑、青の成分だけを見て、透明色を特定することに注意してください。アルファ値は、任意の値をとることができます。
つまり、24/32bpp モードで、例えば、
&h00FF00FF、
&h10FF00FF、
&hABFF00FF、
&hFFFF00FF は、いずれも透明色になります。下位の24ビットが、
&hFF00FF だからです。
バッファ形式
FreeBASIC では、画像を、配列(QBのように)として、または、ポインタとして、使用できます。
いずれにせよ、画像データは、1つの連続した塊に、含まれています。
塊は、ヘッダーと、それに続く、画像データで、構成されます。
ヘッダーは、2つの型(古い形式と新しい形式)のいずれかで、続く画像データの形式を決定します。
古い形式 の塊ヘッダーは、4バイト(32ビット、または、4バイト)で構成されます。
最初の 3ビットは、1画素あたりのバイトで表現される、画像の色深度を含んでいます。
(8ビットの色深度 -> 1; 16ビットの色深度 -> 2; 32ビットの色深度 -> 4)
次の 13ビットは、画像の幅を、
最後の 16ビットは、画像の高さを含んでいます。
ヘッダの本質的な性質から、最大
8191 * 65535 画素までの大きさだけを考慮している点に、注意してください。
' inside FB namespace (extracted from fbgfx.bi)
Type _OLD_HEADER Field = 1
bpp : 3 As UShort
Width : 13 As UShort
height As UShort
End Type
実際の画素データは、ヘッダーの後ろに続きます。画素データは、画素を並べて、一列に圧縮されています。
データ整列は、全く想定されていません。
塊の最終的なサイズは、従って、下の公式を使って、計算できます:
size = 4 +
( width * height * bytes_per_pixel )
新しい形式 の塊ヘッダーは、32バイトで構成されます。
最初の dword(32ビット) は、値 7 に決まっています。
GfxLib が、新しい型の塊を特定するためです。
2番目の dword は、1画素あたりのバイトで表現される、画像の色深度を含んでいます。
3番目と4番目の dword は、それぞれ、画像の幅と高さを含んでいます。古い形式の画像の塊で強制される、画像サイズの制限を、効果的に取り除かれます。
5番目の dword は、バイトで表現される、画素列のピッチを含んでいます。
これは、画像の画素の列が、何バイトを占めるかを示します。
新しい形式の塊のピッチは、常に16の倍数になるように、水増しされます。画素の列のデータが、パラグラフ境界で揃えられるようにするためです。
ヘッダーの残り 3 dword(総12バイト)は、現在、未使用で、今後の使用のために予約されます:
' inside FB namespace (extracted from fbgfx.bi)
Type IMAGE Field = 1 '' in FB namespace
Union
old As _OLD_HEADER
Type As ulong
End Union
bpp As Long
Width As ulong
height As ulong
pitch As ulong
_reserved(1 To 12) As UByte
End Type
画像の最終的なサイズは、以下の通りです。
size = 32 +
( ( ( ( width * bytes_per_pixel ) + &hF ) and not &hF ) * height )
すべての描画の基本命令(原始関数)は、古い形式と新しい形式の画像の塊の、両方で働くことができます。
画像情報に簡単にアクセスするために、
ImageInfo を使って、どの形式が使われた場合でも、画像バッファの役に立つ特性を取得できます。特性とは、画像の寸法や、色の濃さや、ピッチや、画素データへのポインタなどです。
また、この特性情報にアクセスするために、直接画像ヘッダーにアクセスすることもできます。
ヘッダー構造を参照するための、詳しい情報については、
GET/PUT 画像ヘッダーの例を参照してください。
参照:
ページ歴史:2023-07-09 00:19:40
日本語翻訳:WATANABE Makoto、原文著作者:LilloWiki