3万2千色専用高速ブラフィックライブラリ , コンコルド

これは,FMＴｏｗｎｓの3万2千色用の高速グラフィックライブラリです.
高速なだけではなく,ビューポートによるクリッピング機能や,
仮想Vラム機能もありますので,ある程度の汎用性もあります.

さらに,コンコルドライブラリは,座標値をすべて32ビット整数で扱います.
三次元座標演算の結果出てくる座標値は,時として,巨大な値になることがありますが,
そのような場合でも,コンコルドライブラリは,対応することができます.

なお,FMＴｏｗｎｓツーＦのメインラムのウェイト1で測定して,ＴｏｗｎｓＯＳ
バージョン2・1レベル20のEGBに対する速度比を,
一部の機能について紹介しますと,

ポリゴンペイント………………………………約3・5倍
直線………………………………………………約5・2倍
円（塗り潰し）…………………………………約6・3倍
パターンプット（カラー）……………………約1・5倍
パターンプット（カラー／拡大縮小付き）…約1・6倍
パターンプット（モノクロ）…………………約2・6倍

と,非常に高速になっております.ウェイトをノーマルにすると,
倍率はさらに高くなります.なお,この他の描画オペレーションでも,
EGBより高速になっております.

もちろん,速度と高機能はトレードオフの関係にありますから,
このライブラリは,機能的に見ると,EGBには遠く及びません.
しかし,ポリゴンの３次元処理のように,速度を要求される物には適しています.



コンコルドライブラリの特徴

在来型のＴＯＷＮＳ(FMＴＯＷＮＳ CX以前)は,サンハチロクの16メガヘルツと,
世間の基準では一見低速ではありました.
しかし,普通のMS-DOSは,サンハチロクをリアルモードと呼ばれる16ビットモード
で利用しているのに対して,ＴＯＷＮＳでは,ドスエクステンダーの標準装備によって,
サンハチロクをネイティブモードと呼ばれる32ビットモードで利用しているため,
64KB単位でセグメントを切り分ける必要がなく,演算能力も高く,
世間一般で言うところのサンハチロクの16メガヘルツとは思えない速いスピードで
動作していました.現在の最新型機では,
ヨンハチロクの33メガヘルツや66メガヘルツで,
かつネイティブモードを利用しているため,さらに高速に動作します.

そのＴＯＷＮＳは,標準で,EGBというグラフィックバイオスを搭載しています.
このバイオスは,高機能で,かつ,通常の使用では,十分なスピードを発揮します.
しかし,時として,
機能を削ってCPUパワーをすべて描画スピードに振り向けたい場合があります.
ポリゴンによる三次元グラフィックのようなケースは,その典型例です.


ここで,少し話は逸れますが,ビットマップパターンの描画は,横16ドット,
縦16ドットのようにまとまったピクセル単位での書き換えが多いのに対して,
三次元グラフィックの描画では,
1ドットあるいは2ドットだけ書き換えたいというケースが多くあります.
そのような場合,色の情報を従来の複数プレーンに分割して持つVラム構造では,
たった1ドットの書き換えでも,プレーンの枚数回書き換え処理が必要でした.

その点,ＴＯＷＮＳは,パックドピクセル方式というVラム構造になっていて,
1ピクセルの色の情報は,複数プレーンに分かれず,Vラム上に連続して存在します.
そのため,1ドットだけ書き換えるためには,
その連続した数ビットを書き換えればよい仕様になっています.
とくに,8ビットピクセルでは,1バイトの書き換え,
16ビットピクセルでは,連続した2バイトの書き換えなので,
一度の書き換え命令で済みます.
  
では,パックドピクセルでポリゴンの内部の塗り潰しのように,
連続した数ピクセルの書き換えを行う場合はどうかというと,これは,
所要ビット数は等しいため,書き換えバイト数も同じことになり,
スピード的に複数プレーンに分割したVラム構造よりも劣るということはありません.
そこで,この16ビットピクセルに目を付けました.


コンコルドは,
リアルタイム三次元グラフィック描画に使用すること目的とて開発したライブラリです.
ソフトウェア開発では,メモリ使用量とスピードはトレードオフの関係にあります.
このライブラリは,スピードのためならメモリ使用量は考えない,
という方針で開発しました.とはいえ,標準で2メガのラムを搭載していて,
ハチマルサンハチロクのネイティブモードで動作するＴＯＷＮＳでは,
2メガバイトの空間をリニアに利用することができるので,
多少メモリ使用量を度外視して作っても問題はありません.

さらに,機能とスピードもトレードオフの関係にあります.しかし,
機能面であまり削ってしまうと,これも問題があります.そこで,
実用上必要な機能は残して,速度を追求する方針で開発しました.
そのような理由で,ビューポートクリップなどの必要な機能は持たせていますが,
XORやANDなどの論理演算機能は持たせませんでした.

このような方針で開発したため,描画機能では,はるかにEGBには及ばない代わりに,
速度では,大きくEGBを上回ることに成功しました.


三次元グラフィックスの描画で,もう一つ問題になるのは,
座標などで出てくる値の大きさです.
頂点座標を投影面に投影したら,16ビット整数の範囲を越えてしまう,
ということも起こります.
リアルモードでは,普通に扱うことのできる整数値が16ビットなため,
多くのグラフィックシステムでは,座標値は16ビット整数として扱っていました.
このため,画面座標の値が16ビット整数の範囲に収まらない場合は,
画面枠のクリッピングをアプリケーション側で行う必要がありました.

しかし,ネイティブモードでは,特別な処理をすることなく,
32ビット整数を扱うことが可能です.コンコルドライブラリでも,
この強力な演算能力を活用して,座標値は,すべて,
32ビット整数で扱うことになっています.コンコルドライブラリを使えば,
アプリケーション側で,画面枠クリッピングを行う必要はありません.
その他の整数値も,ほとんど32ビット整数として扱うようにできています.


また,コンコルドライブラリは,FMＴＯＷＮＳ上で開発したもので,一応,
FMＴＯＷＮＳ用となっていますが,ライブラリ自体は,マシンを問わず,
ハチマルサンハチロク以上のCPUを搭載した機で,ネイティブモードの
開発実行環境であれば利用できます.
CPU以外のハードウェア  に依存している箇所はありません.

コンコルドライブラリは,画面を,ページという構造体で管理します.
ページ構造体には,ピクセルデータ格納領域のセグメントセレクタと,
アドレスオフセットを記録してあります.
ページ構造体のセレクタに,Vラムのセレクタを代入すれば,
コンコルドライブラリの描画関数で,直接Vラムを書き換えることができます.
ページ構造体のセレクタの値に,データセグメントの値
(ゲットディーエス関数で得る値)をセットすれば,
コンコルドライブラリは,データセグメント上の仮想Vラムに対して描画します.

データセグメントとは,Ｃで扱う普通の変数や配列を格納しているセグメントですから,
データセグメントをピクセルデータとして扱うことができるということは,
普通にＣで使う配列をピクセルマップとして扱うことが可能であるということです.

そのとき,ライブラリには,それが,Vラムであるのか,それとも,
Ｃの配列であるのかは見えないわけです.
単に指示された領域をひとつのピクセルデータの空間として扱うだけです.

この機能は重要で,必要に応じて,仮想Vラムを使ったり,また,Vラムを,
上下に複数枚のピクセル空間に分割して,
あたかも何枚も画面があるように扱うことをも可能にします.
ＴＯＷＮＳは,画面モードによっては,
上下に表示画面2枚分のVラムを持つことが可能で,この機能と,
コンコルドの仮想Vラム処理機能を利用すると,
ダブルバッファ法による書換えが可能になります.

