110gc -- DataScope Graphics Component
ユーザーズガイド
この110gcで提供する、機能らしい機能は、実は1つしかありません。
short gcBitCopy( gcBit* d, gcBit* s, gcRgn* rgn , short dx, short dy, short sx, short sy);それがgcBitCopy関数です。この関数では、転送元ビットマップから、転送先ビットマップへ、ビットマップをコピーします。 コピー元領域は、描画領域rgnをsx,syだけ移動したものであり、 コピー先領域は、描画領域rgnをdx,dyだけ移動したところです。
ここで出てくる、gcBitがビットマップを示し、gcRgnが描画領域を示していますが、 これらは両方とも次のgcObj構造体と同じ構造をしています。
つまり、gcBitCopy関数へ渡すのは、実際のデータへのポインタではなく、 実際のデータへのポインタへのポインタ、 つまり、ダブルポインタであるハンドルなのです。typedef struct { gcObj_v* v; //予約、未使用 void* d; //実際のデータへのポインタ } gcObj;
なぜこんなに面倒なことになっているのかというと、 すべての根源は描画領域にあります。 描画領域を示す型 … (gcRgn*)->dで指し示される実際のデータは、 画面上の任意の領域を指し示すことができますが、これが可変長のデータだからです。
可変長のデータのため、領域同士の演算ルーチンは、 110gcで管理されるヒープ領域からメモリを確保して、結果を返します。 しかし、ヒープ領域といえどもDS110のこと、 あまり多くのメモリを割り付けることはできません。 そのため、メモリが不足すると、ヒープ領域のコンパクト化を実行します。 コンパクト化というのは、ヒープ領域で使用しているメモリ群をエイャ、と、 連続するヒープ領域にまとめてしまい、ヒープの空き領域を作成することを言います。 このコンパクト化が起こると、 実際の領域データが格納されているアドレスが移動してしまいます。 その位置の追跡が行なえるように、ダブルポインタになっています。
つまり、(gcRgn*)->dの値は、ヒープのコンパクト化に伴い変化しますが、 gcRgn* の値そのものは、コンパクト化されても変化しません。 これにより、gcBitCopy関数は、 いつでも正しい領域データを見つけることができるようになっています。
このようなヒープ領域のサポートを含め、110gcグラフィックスライブラリには現在、 次の5つの関数群(クラス)が提供されています。