WindowModePatchの改良予定は?

対応しているADVシステムもだいぶ増やせたことですし、そろそろ機能改良に目を向けてみたいと思っています。

今現在、私がblogやWebページで公開している中では主力になっていますからね。

一応予定について

個人的には以下のようなことを考えています。今現在の優先順位で並べてあります。

  1. 完全可変ウィンドウ状態への対応(ウィンドウの大きさを変更可能にする)
  2. フルスクリーン状態の対応強化
  3. DirectX10やDirectX11への対応
  4. DirectDraw時の描画をDirectX9で内部エミュレーションすることで解像度変換時の補間を強化
  5. 強制フルスクリーン状態の作成

機能追加としては完全可変ウィンドウが可能性が大きそう

うまくいかない理由を優先度が低い方から説明すると

  • 強制フルスクリーン状態の作成

=> それ自体はそこまで不思議ではないが、メニューが含まれたときの処理が非常にややっこしい

  • DirectDrawをDirectX9でエミュレーション

=> 特に抜き色転送(透明色転送)を拡大縮小付きでエミュレーションしたときの品質保証をどうするかが難しい

抜き色転送は3D描画系では不必要となるため、内部実装する必要があり、その状態の時がかなり面倒

  • DirectX10以上への対応

=> DirectX10以上系を扱ったことがないため一度使い方を勉強する必要があり

今のグラフィックカードが上位のDirectXに対応していない+検証用ゲームを持っていないため正常に動くか検証できない

  • フルスクリーン状態への対応強化

=> フルスクリーン化するとデバッグがまともに出来なくなるため動かなかった場合のコードの検証が難しい

  • 完全可変ウィンドウ

=> ウィンドウサイズ変更時に描画がかかる場合など特にプログラム本体からの描画処理を正しく処理しないと動かなくなったりエラー落ちが起こる

と言うことで、今現在は内部的に対応コードを追加して言っているところです。

よほどなことがない限り次のバーションでは動作が遅くなったり動作が異なったりすることがあると思います。

やっぱりこの頃のシステムはちゃんと解像度変換処理を積むようになってきたな

特に3D系の描画処理を積んでいる場合では対応が早いようですね。元々3D描画の場合補間処理は必須なので実装しやすいと思います。

それでも見ている限り問題点がいくつかあり、

  • 画像を拡大したときに補間処理がうまくいっていないのか、ブロックが見える状態になっていることがある
  • ウィンドウモード時縮小側の処理は存在するが拡大側の処理が存在しないため、数年後に解像度が上がったときに小さく見えるという問題が起こる予感

いつまでこの手のゲームが持つかどうかという疑問もありますが、まあそのときはそのときなのでしょうね。


コメントを残す

メールアドレスが公開されることはありません。

*

この記事のトラックバック用URL