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 では、次のような イメージ操作をサポートしています。
mgl では、screen 間の bitblt をサポートしています。
通常 op には、0 をいれますが、
void bitblt(struct screen *dst, int dx,int dy struct screen *src, int sx,int sy,int xsize,int ysize,int op);
BLT_TILING src のタイリング指定。 BLT_MASKING | color 透明色の指定もできます。 また、16bpp(STK_GENERIC_FULLCOLOR)タイプのスクリーンから、 その他のスクリーンタイプに、転送するときは、自動的にディザがかかります。
ピクセルの色を 配列に読みだし/書き出しができます。 色の定義は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 はなぜ早いか --- これはドローエンジン の仕組みによるところが大きいです。解説は別途。