MGL API の紹介その2

screen

mgl では 3 種類の画面(screen) をサポートしています。

	  物理画面
          オフスクリーン
          部分スクリーン

生成方法が異なるだけでできることは同じです。

物理画面


struct screen *physigal_screen;

int SCREEN_WIDTH;
int SCREEN_HEIGHT;

初期化時に生成されています。これにだけ、大きさを表すシンボルが定義されています。
スクリーンのタイプは、STK_NATIVE (後述)

オフスクリーン


struct screen *screate_memscreen(int xsize,int ysize, char *bitmap
					,int kind,int op)

これでオフスクリーンを生成します。kind には、

		STK_NATIVE			物理画面と同じフォーマット
		STK_GENERIC_4COLOR		2bpp
		STK_GENERIC_192COLOR		8bpp
		STK_GENERIC_FULLCOLOR		16bpp

のいずれかを指定します。違う種類の間でも bitblt できますが、同種間が最も早いです。

たとえば、STK_NATIVE で生成すると、物理画面間の bitblt が高速化されます。

また、STK_GENERIC_FULLCOLOR だと、MGL で最大の色情報を保存できます。これらを選ぶ基準は、必要とされる表現力と使用メモリのトレードオフにすべきです。

なお、bitmap は通常 NULLにしてください。 op も通常 0 で OKです。

部分スクリーン


struct screen *create_subscreen(struct screen *parent,int x,int y,
		int xsize,int ysize);

これで、部分スクリーンを生成します。座標のローカライズや、クリッピング(まだ実装されていませんが) を行うためのものです。

イメージ操作

mgl2 では、次のようなイメージ操作をサポートしています。

bitblt

mgl では、screen 間の bitblt をサポートしています。


void bitblt(struct screen *dst, int dx,int dy
	    struct screen *src, int sx,int sy,int xsize,int ysize,int op);

通常 op には、0 をいれますが、

		BLT_TILING		src のタイリング指定。
		BLT_MASKING | color	透明色の指定

もできます。また、16bpp(STK_GENERIC_FULLCOLOR)タイプのスクリーンから、その他のスクリーンタイプに、転送するときは、自動的にディザがかかります。

pixstream

ピクセルの色を配列に読みだし/書き出しができます。色の定義は1つなので、これを使えば、他のフォーマットへの変換ができます。


void get_pixstream(int x,int y,int *buf,int length,int dir,int op);

void put_pixstream(int x,int y,int *buf,int lenght,int dir);

dir は方向を示します。

		DIR_NORTH               右から左
		DIR_WEST                下から上
		DIR_SOUTH               左から右
		DIR_EAST                上から下

get_pixstream の op には、bitblt での透明にする色の指定ができます。この指定をすると、該当ピクセルの色値は、COLOR_TRANSPARENT になります。

また、FULLCOLOR タイプのスクリーンでは、色値に COLOR_DITHER フラグが付きます。

put_pixstream では、COLOR_TRANSPARENT の色はなにもしない指定になります。また、COLOR_DITHER フラグが付くとディザをかけてて描画します。 COLOR_REVERSE を指定すると、ピクセルの明るさを反転します。 ( 2回 COLOR_REVERSE を行うと元に戻ります。)

解説

MGL では色体系を1つしか持っていません。アプリケーションで色の情報量が必要なときは、FULLCOLOR な screen を生成するわけです。

普通の Window API は複数のスクリーンフォーマット/bitblt をもっていますが、色体系に、HSB を採用しているものはないと思います。

違うタイプの screen 間の bitblt は、内部的に get_pixstream/put_pixstream を使います。 1つの色体系にしか対応しなくて良いので、コンパクトにまとめることができています。色体系に RGB を採用したとすると、2bpp/8bpp のタイプの性能が落ちることになります。

2bpp は明るさの 2bit しか必要としないので、RGB それぞれを見るのは遅くなる要因です。
8bpp では、ハードウェアが色変換テーブルを用意していますが、 RGB を単純に減色すると、6bit しか利用できなく美しくありません。 MGL では、H 4bit S 2bit B 2bit というように 8bit すべて利用できます。また、実際に使う色が 76色だと分かっているので、変換テーブルを 1 つ作れば、8bpp の X 上でも問題なく使えます。

MGL では、2bpp/8bpp に有利になるような設計になっているわけです。 16bpp では RGB 値と相互変換するのにテーブルを使うことを前提にしています。そのため、色空間を小さくしてでも、メモリ量を減らせることを優先しています。

ちなみに、同じタイプ間の bitblt はなぜ早いか --- これはドローエンジンの仕組みによるところが大きいです。解説は別途。