今回の趣旨とお知らせ
今回は、トラックを走行中の描画について記載する。
なお執筆時点で、3月16日に”rF2 Example Plugin 2.7z”の改版がリリースされていることを確認した。
今回以降の更新は、本バージョンを使用する。
3月16日版の改版点-プラグインを使用する人向け-
プラグインを開発しない人達も重要な内容である。そういった方々向けのへの説明としては
「Build 68前向けのプラグインをBuild 68以降で使用した場合、rFactor2がクラッシュする場合がある。」
対策としては、Build 68以降向けに修正されたプラグインを入れなおす。
またシミュレータ本体が過渡期であるため、注意が必要である
ざっくりと区分けするなら、「プレーヤーのスコア(順位)・他の走者とのスプリットタイム等を扱うプラグイン」は
要注意である。
3月16日版の改版点-プラグインを開発する人・開発しないがC言語が分かる人向け-
rFactor2.exeとプラグインの間で情報を交換する構造体「VehicleScoringInfoV01」の要素が増えている。
(車体ではなく、アセンブラ的な意味で)アラインメントが当然狂うため、
アクセス違反や予期せぬデータが入ってきてしまう場合がある。
既に開発を開始している場合は、”InternalsPlugin.hpp”だけを差し替えて再コンパイルをする必要がある。
※アドレス決め打ち等、特殊な事をしていなければ、これだけで良いはずである。
ヘッダファイルの上部には、改版履歴が更新されていないが、ソースの中には、ここからここまで更新と書かれている。
3月1日時点で、内部的には更新されたようだ。
今後のプラグイン開発の注意事項
今後のプラグイン開発だが、今回のようにヘッダ・アラインメント等が変わってしまう場合も多々ある。
勉強目的や、簡易なテスト以外で中～長期の開発をする場合は、InternalsPluginを継承して、
子クラスでプログラムを作った方がよさそうである。頭の片隅に入れておいてほしい。
画面描画の準備
画面描画の際に呼び出される関数ExampleInternalsPlugin::UpdateGraphicsでは
”ExampleInternalsGraphicsOutput.txt”というファイルが書き出されている。
・・・はずなのだが、実際にrFactor2を起動すると、下記のメッセージしか記録されていないし、
何のコードを書いても実行されている形跡が無い。
-STARTUP- (version 1.042)
–STARTSESSION–
—ENTERREALTIME—
—EXITREALTIME—
–ENDSESSION–
-SHUTDOWN-
これは、単純に関数を呼び出す設定が「オフ」になっているからである。
Example.hpp内の中で定義されている関数(rFactor2.exeから呼び出される)で、
機能を”false”で返しているからである。これをtrueに変更することで呼び出されるようになる。
実際の画面描画
結論から言うと、「描画できない」と筆者は宣言させていただく。
「描画できているプラグインがいくつかフォーラムにあるようだが?」という意見もあると思うが、後述する。
さて、描画のための関数は、void ExampleInternalsPlugin::UpdateGraphics()になる。
引数として、GraphicsInfoV01の参照が与えられる。
サンプルプログラムをバッサリと消して、下記のようなコードに書きなおした。
前半分は描画そのもの。後ろ半分はデバッグ情報取得のためのものである。
さて、上記のコードは、GraphicsInfoV01からゲームウインドウのハンドルを得て、
デバイスコンテキストを取得して、そこに赤・緑・青の1ドットサイズの点を3つ。
”日本語描画テスト”という文字列を画面左上座標 100,100に描画するコードである。
実行結果は、下記の通りとなる。
※フォーラムで見つけた他プラグインの情報も表示されてしまっているが、無視してほしい。
描画できないって?
出来ているではないか? 実際は実行すると、頻繁なちらつきをおこす。
またfraps等でキャプチャするとキャプチャ画面には存在しない。
描画できないと宣言する理由は、下記の通りである。
・バックグラウンドサーフェイスのハンドルが得られないので、表のウインドウ画面にしか書き込めない。
DirectXのプログラムをやっている方なら分かるはずであるが、バックグラウンドのサーフェイスへのハンドルを
rFactor2.exeが与えてくれない限り、解決できないのである。
なぜ、他プラグインは描画できているの?
Ricahrd Burns Rallyやその他シミュレータでのハックと同じ方法で実施しているからである。
Windowsの仕様としてDLLをロードする際、検索順序がある。
まずは実行ファイルと同じ場所、その次は現在のフォルダ。その次は・・・・となっていく。
DirectX9を使用しているrFactor2の場合は、最終的にWindowsにインストールされたDirectXの
ランタイムにたどり着く。
一例だが、そのルールを逆手にとって、ゲームのインストールフォルダにDirectXのDLLと
同じファイル名のものを置くとどうなるか?
特定の関数(描画命令等)だけ奪い取って、必要なものを行った後、本来のDLLへ命令を投げれるのである。
なぜ、それを実装しないか?
この方法を使うと、複数の描画するプラグインを同居しにくくなってしまう。
「俺様のプラグインが描画機能占拠するから、他のプラグインには描画させねぇ～よ」という「俺様プラグイン」が出来てしまうからである。
他のシミュレータ等で、描画系プラグインを同居できなくて、泣く泣く1つのプラグインだけにしたことはないだろうか?
せっかくMODやプラグインを複数入れられる、また管理できる仕組みがrFactor2にはあるにも関わらず、
「俺様プラグイン」をユーザーに導入させれるのか? それは他プラグイン開発者へ失礼だと考える。
現状、サーフェイスへのハンドルがrFactor2.exeから渡されない以上、機能を実装してもらえるように
フォーラム等で意見を上げるしかない。
前向きに考えると、ウインドウのハンドルを得られる現状は、将来への布石(準備)とも見える。
プラグイン開発については今後も記載するが、”画面描画2″は暫くは進展が無い限り記載が無い予定である。
次回
予定のプラグイン開発情報は、独自ハードウェアとの連携について記載予定である。
参考リンク
Windows が使用する DLL 検索パス
http://msdn.microsoft.com/ja-jp/library/7d83bc18%28v=vs.80%29.aspx
DLLフックの”DetourXS v2″の関連情報
http://www.gamedeception.net/threads/21803-DetourXS-v2