単純なバグフィックスではなく対応ゲームをちょっと増やしてみました。

20:45 追記 とある都合でVer 0.48 AlphaおよびVer 0.49 Alphaはスキップします。

パレットエミュレーションが難しい

というわけで、今回の修正は主にDirectDrawでパレット描画を使用しているときにおこる色化け現象を直しました。そのあたりの資料はネット上にもほとんど残っていないのでだいたいは対象のゲームの動きを見ながら推察でやっています。しかもこの時期のゲームはフルスクリーンのみのゲームもそれなりにあるためやっかいです。こんな時にこそ強制ウィンドウ化なのですが・・・。まあ試しているゲームでは色化けがだいぶ無くなったのでよしとします。

RADEONは気むずかしい？

私のPCですが、グラフィックにはGeForce系を使っています。が、掲示板を見るとどうもRADEON系で妙な描画のされ方をされることが多々あるようで。前回はとあるテクスチャの描画処理、今回はSMAAの描画処理でGeForceでは描画されるのにRADEONでは描画されない、という現象にあいました。

まあ、バグの原因については想像がついていますが、おそらく頂点座標の処理が厳密なのでしょうね。本来なら描画時に全く使われないパラメータのはずなのですが、RADEONの場合はその部分まで確認して描画をしているようで、そのために描画がおかしくなるようです。テスト機(GeForce系)が描画できるのにRADEON系で描画に問題が起こったときは頂点座標のパラメータを確認してみましょう。Direct3Dで正しいとされている状態なのか、ということですね。

一応前者の例(テクスチャを直接ディスプレイに描画するパターン)のバグの原因を紹介しておくと、「変換済み座標の設定でrhwに通常は1.0を設定すべきところ、その描画の時だけ設定を忘れていたため、ゼロクリアされた0.0が適応されていて誤った描画となった」と言った具合です。どちらのグラフィックカードがいいか、とかそういう問題ではないのですが。

ついでにMovieLayerPlayerとWindowResizerも修正

WindowModePatchで初期ウィンドウ位置入力をつけたときに「整数値および-(マイナス)の記号のみを受け付ける」という状態を維持するルーチンをこの二つから持ってきたのですが、こちら側のデバッグ中にゼロクリア時に微妙な動作をしていたので直しています。

で、今回その部分をのルーチンをフィードバックしておきたくなったのでバージョンアップを行った次第です。そのため、他の部分には影響はないです。なお、このルーチンですが動作としては想定したとおりなのですが、他のプログラムでこのような制限をしているときにどうしているのか微妙だったりします。気になる人は気になるのではないでしょうか。