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 のタイプの性能が落ちることに なります。

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

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


オリジナル コピー リンク ダウンロード