なにかOotakeに貢献できる事がないかと、別プラットホームの時に、ソフトウェアでバイリニアフィルタ(は3D処理の用語な気がするので、アンチエイリアス？)を実現してて移植もしてあるので、Ootakeに使えないかとソースを見てました。

　別プラットホームは16bitカラーだったので、32bitカラーであるOotakeには、そのままでは使えないだろうと思っていたら、内部はギリギリまで9bitカラーだったので、似た方法で高速化の方法として利用できる気がします。


Ootakeのソースに合わせて記述すると、
[VDC.cpp]
void
VDC_Reset()
{
〜
for (i = 0x000; i < 0x100; i++)
_PaletteBG[i] = _PaletteSP[i] = 0x000001FF;

static inline void
set_Palette()
{
〜
c = ((_ColorLatch & 0x0038)<<3)|((_ColorLatch & 0x01C0)>>3)|(_ColorLatch & 0x0007);

[Screen.cpp]
〜
Uint32 _GammaRGB[512]; // ガンマを計算した数値を入れておく
Uint32 _GammaS80RGB[512]; // スキャンライン80%用
Uint32 _GammaS90RGB[512]; // スキャンライン90%用
〜
void
SCREEN_SetGamma(
Sint32 scanLineType,
Sint32 scanLineDensity) //スキャンラインの濃度(%)
{
〜
Uint32 rc, gc, bc;
〜

for (i=0; i<=512 ; i++)
{
rc = (i>>6) & 7;
gc = (i>>3) & 7;
bc = i & 7;

_GammaRGB[i] = (_Gamma[rc] << 16)|(_Gamma[gc] << 8)| _Gamma[bc];
_GammaS80RGB[i] = (_GammaS80[rc] << 16)|(_GammaS80[gc] << 8)| _GammaS80[bc];
_GammaS90RGB[i] = (_GammaS90[rc] << 16)|(_GammaS90[gc] << 8)| _GammaS90[bc];
}

モノクロテーブルには使えませんが、後は、
*pDst++ = _GammaRGB[d & 0x01FF];

　みたいな感じで、マスクで範囲外アクセスのリスクが低減されていた事も考慮し、0x1FFでマスクしていますが･･･
私は別プラットホームの時は、やっていませんでしたけどｗ


　ただ、元々32bit化してたので退化する感じになる、せっかくメモリを覗いた時にどんな色か判かりやすかったのにダメになる、なので定数を代入する時も判り難くなる、過去のステートセーブに対応しなければいけなくなる、というデメリットもありますし、
今時のPCで、Ootakeが重いっていう事もあんまりないでしょうから･･･ご判断はお任せします。

ありがとうございます。

_PaletteBGと_PaletteSPの32bit化は、VDC.cppで_pScreenBufに値を書き込む時
の高速化と明瞭化の為に実施したので、今後の開発のためにもbit数を減らすこ
とはできないです。

スクリーン転送時にテーブルを使って高速化する場合、今のデータ構造のまま
でも、例えば_GammaRGB[16777216]のように24bitぶん(約16MB)のテーブルを用
意すると出来そうなので試してみますね。

あまり速くないPCでもできるだけ快適に動いてくれればいいなと思っています。