XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

[KEYONN]

[1] 質問文
　[1.1] 自分が今行いたい事は何か
＞初の本格的な３Ｄレーシングゲームを作っていますが、地面との当たり判定や、道路ではない
緑の部分（草地）との当たり判定、レーダーの処理、坂道の上り下りがしたいです。

　[1.2] どのように取り組んだか(プログラムコードがある場合記載)
まず、地面との当たり判定は、坂道がないため、ZX平面を平行移動する形となるため、
２次元画像（orp.png:4360,4360)のZX平面と対応する（３次元座標のZが２次元画像のY座標で、
３次元座標のXが２次元座標のX座標にして、色を取得し、緑色RGB(0,200,0)なら
スピードをだんだん遅くするようにしました。他にも似たような処理でレーダーというか
コースの地図(orp2.png:64,64)と、16ドットの大きさの「敵」と書かれたスプライトや
「自」と書かれた自分の車の位置をマッピングする処理も書きました。

それから、坂道の当たり判定は、どうやればコースデータ(course.x)の全ての頂点を
把握するのか分からず困りました。また、２Ｄゲームで何かスプライトが
落下するときみたいに、Y座標を足せばいいのか、ちょっと微妙です。
まだ、処理がよく分かっていないので、坂道は組んでないのですが、ＤＸライブラリの
３Ｄのサンプルが役立ちそうです。ただし、坂道の処理を組んでしまうと、
先ほどの３次元座標を２次元画像とマッピングする処理と一緒に存在すると、
破綻してしまうのではと考えました。（他にも交差する道路や、トンネルなど）

両方とも、３次元空間の把握の仕方が分からない事で自分は困っているんだと
思います。OpenGLの右手座標系なら分かるのですが、DirectXの左手座標系は、
Ｚが奥に行くほど足されていくという考えであってますでしょうか？

　[1.3] どのようなエラーやトラブルで困っているか(エラーメッセージが解る場合は記載)
エラーメッセージは無いです。
トラブルは、３次元座標のZが奥に行くほど足されていくと思うので、２次元座標にY座標として
使うと、Y座標の方向が逆になってしまいます。
あと、３次元座標Xは、そのまま２次元座標に使えるのか分からないです。


レーダーは本当に本当の位置を示しているのか分からないです。

坂道はＤＸライブラリのサンプルを参考にしてみます。

　[1.4] 今何がわからないのか、知りたいのか
３次元座標を２次元座標にマッピングする処理で当たり判定を行う処理は、メリットとデメリット
がどのくらいあるのか知りたいです。

[2] 環境 　
　[2.1] OS ： Windows, Linux等々
WindowsXP SP3です。

　[2.2] コンパイラ名 ： VC++ 2008EE, Borand C++, gcc等々
VisualC++ 2008 Express Editionです。
[3] その他
　・どの程度Ｃ言語を理解しているか
ポインタが変数のアドレスを示す変数なのは分からないでもないですが、ちょっと高度な
プログラム、例えばリストやツール作り
（グラフィックエディターででアンドゥとリドゥをメモリの許す限りできるようにする事）
などができません。

他にもアルゴリズムとデータ構造の知識に乏しいです。

あと、ビット演算は不得意分野です。

　・ライブラリを使っている場合は何を使っているか
ＤＸライブラリです。

[softya（ソフト屋)]

３次元空間として地形を組んでしまった方が早いと思います。
ただ、人間に見える地形と当たり判定で使う地形は分けたほうが楽だと思います。
→　ここで地形ツールを作る必要が出てきます。

>OpenGLの右手座標系なら分かるのですが、DirectXの左手座標系は、
>Ｚが奥に行くほど足されていくという考えであってますでしょうか？

カメラにおける光軸方向の事でしょうか？
OpenGLだと奥がマイナスでDirectXは奥がプラスですね。

>先ほどの３次元座標を２次元画像とマッピングする処理と一緒に存在すると、
>破綻してしまうのではと考えました。（他にも交差する道路や、トンネルなど）

マップは真上から見た図なので、ZXだけ処理して構わないと思います。

[KEYONN]

＞３次元空間として地形を組んでしまった方が早いと思います。
＞ただ、人間に見える地形と当たり判定で使う地形は分けたほうが楽だと思います。
＞→　ここで地形ツールを作る必要が出てきます。
地形ツールは、既存のモデリングソフト（メタセコイア）を使いました。
３Ｄなのに、平面な地形です

＞>OpenGLの右手座標系なら分かるのですが、DirectXの左手座標系は、
＞>Ｚが奥に行くほど足されていくという考えであってますでしょうか？

＞カメラにおける光軸方向の事でしょうか？
＞OpenGLだと奥がマイナスでDirectXは奥がプラスですね。
おお、そうでしたか、やはり合っていたようです。

>先ほどの３次元座標を２次元画像とマッピングする処理と一緒に存在すると、
>破綻してしまうのではと考えました。（他にも交差する道路や、トンネルなど）

＞マップは真上から見た図なので、ZXだけ処理して構わないと思います。
ここで質問です。マップの座標を
MV1SetPosition( int MHandle, VECTOR Position ) ;で指定したのですが、
指定される座標がどの地形の部分なのかよく分からないのです。とここで、
勝手に、マップの中心点だと決めてしまい、失敗したのですが、どの部分が指定されるのか
分からず、計算式を打ったり、関数電卓で計算したり、スケッチブックに図形を描いて
調べたりを繰り返しているのですが、分かりません。

添付した画像の計算式が間違ってるみたいなのですが、どこが間違っているのか分かりません。
Xは右に伸び、Ｚは奥に伸びるので、これでおかしいのはどうしてなのか分からないのです。

[KEYONN]

どこがおかしいかというと、DrawFormatString関数で、GetXとGetYの値を調べたのですが、
GetYの値が途中からマイナスになっているのです。

[KEYONN]

分かった事があります！！
この計算をするには、メタセコイア側で左下を（０，０、０）に合わせないと駄目だということです。
でも、まだ、GetXがマイナスになったりするので、よく分からない事が多いですが、頑張ります。

[KEYONN]

＞初の本格的な３Ｄレーシングゲームを作っていますが
ちなみに、分かるとは思いますが、”初”のというのは僕にとって、初めて本格的な３Ｄゲームを作っているという
意味です。

あと、旋回速度は、

コード:

YRotate=((float)(YRotate))+(3.5f/(Sp+0.1f));

という計算式を使っています。
スピードが高くなればなるほど、旋回速度は低くなるので、ブレーキを踏み、スピードを落とすと
曲がりやすくなります。Spに0.1を足しているのは、０除算エラーを防ぐためです。

[KEYONN]

あまり関係無いですが、今日はもう寝ます。疲れました。
頭を使うと眠りにくくなるみたいですし

あと、スクリーンショットだけ画像を添付します。

[softya（ソフト屋)]

Ｚ軸の方向もそうですが、簡単に確認できることを質問してしまうのは、KEYONNさんにとって良くないことだと思うのでＺ軸と「MV1SetPosition( int MHandle, VECTOR Position ) ;で指定したのですが、指定される座標がどの地形の部分なのかよく分からないのです。」を確認する方法を考えてみてください。
これは、テスト方法とか考えるにも必要なプログラマーにとって大事な思考プロセスをしていない事になるからです。
難しくはありません。ちょっとした工夫をするだけですので、ウヤムヤにせず必ず確認してください。

それとマップ表示でCameraPosが何のために出てくるのかよく分からないのですが、やっていることの解説かコードをお願いします。私にとっては非常に不可解です。

>地形ツールは、既存のモデリングソフト（メタセコイア）を使いました。
>３Ｄなのに、平面な地形です

それだとトンネルは作れません。
本格的に作るのは、マップをブロックに分割してメタセコイアでモデルを作成し、それを結合するためのツールが必要だと思います。
結合と言っても、それぞれのモデルを移動して座標を記録するデータを作成するだけのツールです。
まぁ，ある種のマップエディタと言えるでしょう。

[KEYONN]

ＫＥＹＯＮＮです。
ちょっと外出していました。なので返信が遅くなってしまってすみません。

＞Ｚ軸の方向もそうですが、簡単に確認できることを質問してしまうのは、
＞KEYONNさんにとって良くないことだと思うので
＞Ｚ軸と「MV1SetPosition( int MHandle, VECTOR Position ) ;で指定したのですが、
＞指定される座標がどの地形の部分なのかよく分からないのです。」を確認する方法を考えてみてください。
＞これは、テスト方法とか考えるにも必要なプログラマーにとって
＞大事な思考プロセスをしていない事になるからです。
＞難しくはありません。ちょっとした工夫をするだけですので、ウヤムヤにせず必ず確認してください。
これは、確認する方法をちょっと考えてみたのですが、１プレイヤーの車のモデルを
MV1SetPosition()で座標を指定してカメラも移動させて目視で確認するか、
自力で移動してDrawFormatStringで、X,Y,Z座標を確認するという事でしょうか？
ちょっとやってみます。
．．．
やってみました。
モデリングツールで四方の隅にそれぞれ違う形の単純な図形を置いて
０，０，０に頂点を合わせて、自力で１プレイヤーの車を
移動してDrawFormatStringで座標を見たのですが、
多少のずれはあるものの、それを補正して、計算できました。

指定される座標は、中心ではなく（モデリングツールで中心が０，０，０）なら中心にきますが）
Ｘ、Ｙ、Ｚの方向へ向かって小さい方から始まると思われます。

＞それとマップ表示でCameraPosが何のために出てくるのかよく分からないのですが、
＞やっていることの解説かコードをお願いします。私にとっては非常に不可解です。
もともと敵が動かないＦＰＳを作っていて、放っておいたソースを使っているので、
行列とかベクトルとかが出てこないソースです。
そちらの数学（高校数学の）ほうが便利で高速なのは分かってはいるんですが、
個人的に、取っ付きにくいなあ・・・と考えてしまうため、楽をしています。
あと、一応ゲーム数学本で行列とベクトルは勉強したので、手計算でも
できます。

カメラが自プレイヤーとほぼ同じ座標にいるのでそうなります。
というか、自プレイヤーの座標をはじめに指定するのではなく、
逆にカメラから座標を計算して、自プレイヤーの座標を計算しているので、
カメラの座標で移動座標を調べました。ここらへんは、ＦＰＳのソースを流用した結果
そうなりました。

ただし、Ｘファイルに出力する際に、左右を反転するで、反転させているため、
計算が混乱しています。たぶん、左右に反転しなければいいのでしょう。
そこらへんは、なんとかします。

>>地形ツールは、既存のモデリングソフト（メタセコイア）を使いました。
>>３Ｄなのに、平面な地形です

>それだとトンネルは作れません。
確かに・・・、ですが、少しずつ高度な事をやろうとしている為、今はＺＸ平面で精一杯です。

>本格的に作るのは、マップをブロックに分割してメタセコイアでモデルを作成し、
>それを結合するためのツールが必要だと思います。
>結合と言っても、それぞれのモデルを移動して座標を記録するデータを作成するだけのツールです。
>まぁ，ある種のマップエディタと言えるでしょう。
よく分かりませんが、敵の動き方を編集するのでしょうか？
それなら、リプレイデータを使っていますが、確かにそちらの方がやりやすいですね。

[softya（ソフト屋)]

．．．
やってみました。
モデリングツールで四方の隅にそれぞれ違う形の単純な図形を置いて
０，０，０に頂点を合わせて、自力で１プレイヤーの車を
移動してDrawFormatStringで座標を見たのですが、
多少のずれはあるものの、それを補正して、計算できました。

指定される座標は、中心ではなく（モデリングツールで中心が０，０，０）なら中心にきますが）
Ｘ、Ｙ、Ｚの方向へ向かって小さい方から始まると思われます。

テストプログラムを書くほうが簡単だと思いますが。
わざわざ、開発中のコードを直したのでしょうか？

＞それとマップ表示でCameraPosが何のために出てくるのかよく分からないのですが、
＞やっていることの解説かコードをお願いします。私にとっては非常に不可解です。
もともと敵が動かないＦＰＳを作っていて、放っておいたソースを使っているので、
行列とかベクトルとかが出てこないソースです。
そちらの数学（高校数学の）ほうが便利で高速なのは分かってはいるんですが、
個人的に、取っ付きにくいなあ・・・と考えてしまうため、楽をしています。
あと、一応ゲーム数学本で行列とベクトルは勉強したので、手計算でも
できます。

カメラが自プレイヤーとほぼ同じ座標にいるのでそうなります。
というか、自プレイヤーの座標をはじめに指定するのではなく、
逆にカメラから座標を計算して、自プレイヤーの座標を計算しているので、
カメラの座標で移動座標を調べました。ここらへんは、ＦＰＳのソースを流用した結果
そうなりました。

カメラはプレーヤー車の位置を表すのですね？
しかしカメラから車の挙動を計算するには面倒だと思うのですが。　→　ドライバー視点固定でしょうか？　それでも車の回転中心とはズレているはずです。

【追記】
車はＧが働くのでベクトルの計算が不可欠です。
質量の慣性ベクトルと車のタイヤ駆動の動力ベクトルを合成しないと車らしい動きになりません。
あと摩擦係数とか考えないとドリフト走行までもっていけないと思います。

ただし、Ｘファイルに出力する際に、左右を反転するで、反転させているため、
計算が混乱しています。たぶん、左右に反転しなければいいのでしょう。
そこらへんは、なんとかします。

mqoファイルではダメなのでしょうか？
そのままＤＸライブラリは読み込めるはずです。

>>地形ツールは、既存のモデリングソフト（メタセコイア）を使いました。
>>３Ｄなのに、平面な地形です

>それだとトンネルは作れません。
確かに・・・、ですが、少しずつ高度な事をやろうとしている為、今はＺＸ平面で精一杯です。

先のことを考えて開発するかどうかの問題ですが、このコードを流用しないなら問題ないでしょう。

>本格的に作るのは、マップをブロックに分割してメタセコイアでモデルを作成し、
>それを結合するためのツールが必要だと思います。
>結合と言っても、それぞれのモデルを移動して座標を記録するデータを作成するだけのツールです。
>まぁ，ある種のマップエディタと言えるでしょう。
よく分かりませんが、敵の動き方を編集するのでしょうか？
それなら、リプレイデータを使っていますが、確かにそちらの方がやりやすいですね。

車の動きを編集するなんて普通はしません。カーレースゲームでは一般的にＡＩで敵車は走るんです。
そうしないと接触事故等で挙動が変わった時に対処出来ない事になります。

それとマップツールと書いていますが、マップをブロックに分けてメタセコイアで作成して組み合わせて１つのステージを作るという意味です。
プラレールの感じと言えば分かるでしょうか？
メタセコイアでトンネルや道路を作って、それをツールで組み合わせてステージとするんです。

[KEYONN]

＞テストプログラムを書くほうが簡単だと思いますが。
＞わざわざ、開発中のコードを直したのでしょうか？
はい。

＞カメラはプレーヤー車の位置を表すのですね？
＞しかしカメラから車の挙動を計算するには面倒だと思うのですが
カメラとは別にCarPosという変数とEPosという変数があります。
それを参照すれば良いと思います。

＞mqoファイルではダメなのでしょうか？
＞そのままＤＸライブラリは読み込めるはずです。
mqoファイルで読み込んで見ます。

＞先のことを考えて開発するかどうかの問題ですが、このコードを流用しないなら問題ないでしょう。
全て行列とベクトルに計算し直した方がいいでしょうか？

＞車の動きを編集するなんて普通はしません。カーレースゲームでは一般的にＡＩで敵車は走るんです。
＞そうしないと接触事故等で挙動が変わった時に対処出来ない事になります。
ＡＩですか、ついファミコンのF1レースを思い出してしまいました。（笑）
あれはぶつかっても良い代わりに自分の車が事故に遭うんですね。

＞それとマップツールと書いていますが、
＞マップをブロックに分けてメタセコイアで作成して組み合わせて１つのステージを作るという意味です。
＞プラレールの感じと言えば分かるでしょうか？
＞メタセコイアでトンネルや道路を作って、それをツールで組み合わせてステージとするんです。
なるほど、そうですか、普通はそうやって作ってるんですね。知りませんでした。
しかし、真似をしたいのですが、ＣＰＵが遅いため、できるかどうか分かりません。

[softya（ソフト屋)]

結局、マッピングは出来たのでしょうか？

>カメラとは別にCarPosという変数とEPosという変数があります。
>それを参照すれば良いと思います。

それだとCameraPosは出てこないですよね？
つまり「XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい」としては不要ということでしょうか？

カーレースゲームは、ここのＸＮＡの講座が参考になると思います。
私の提案と違いますが、ちゃんと基本的なことは解説しています。
「ゲームクリエーター特訓　2012年度」　
2012/12/15 GP24 PDF, 配付資料 (12/12 up) カーレースゲームと自動走行 (XNA)
http://kait.ogatakaoru.jp/

>全て行列とベクトルに計算し直した方がいいでしょうか？

上記の事をやるなら、そうしないと出来ないです。

[KEYONN]

>>カメラとは別にCarPosという変数とEPosという変数があります。
>>それを参照すれば良いと思います。

>それだとCameraPosは出てこないですよね？
>つまり「XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい」としては
>不要ということでしょうか？
いえ、どちらにせよ、マッピングする必要があります。
あとは、現在、LoadSoftImageで、読み込んだマッピングしたい２次元画像
をDrawSoftImageで半透明描画して、自プレイヤーと敵プレイヤーも位置で描画しています。
しかし、微妙にずれているんですよね。何が原因かは分かりませんが、いろいろやってみます。

>カーレースゲームは、ここのＸＮＡの講座が参考になると思います。
>私の提案と違いますが、ちゃんと基本的なことは解説しています。
>「ゲームクリエーター特訓　2012年度」　
>2012/12/15 GP24 PDF, 配付資料 (12/12 up) カーレースゲームと自動走行 (XNA)
>http://kait.ogatakaoru.jp/
うわぁ、これは・・・僕が元居た大学の資料じゃないですか？
あの頃は、いろいろあって、辞めてしまいましたが、
数学や物理の公式を見るのさえ難しく感じられ、つまらないなあ・・・と思っていました。

今は、なんとか、数学の知識が少しずつ入ってきていて、
物理も頑張ってみようかな・・・と思っています。

ただ、「ゲーム開発のための数学・物理学」という本を元にやっているのですが、
前に￥７０００で購入した「ゲームプログラミングのための３Ｄグラフィックス数学」は
難しく感じます。

>>全て行列とベクトルに計算し直した方がいいでしょうか？
>上記の事をやるなら、そうしないと出来ないです。

やってみます。

[softya（ソフト屋)]

あとは、現在、LoadSoftImageで、読み込んだマッピングしたい２次元画像
をDrawSoftImageで半透明描画して、自プレイヤーと敵プレイヤーも位置で描画しています。

自プレイヤーと敵プレイヤーの座標が確かに必要だと思いますがCameraPosが必要な理由がイマイチわかりません。
あとDrawSoftImageって遅くありません？
マップは別に描画用にLoadGraphで読んでDrawGraphしたほうが良いと思います。

DrawSoftImageから引用「主に編集した画像が正しいかどうかを確認するためにしようするものです。
グラフィックハンドルの描画に比べて負荷が非常に高いので、確認以外の用途で使用することは避けた方が賢明です。」

しかし、微妙にずれているんですよね。何が原因かは分かりませんが、いろいろやってみます。

それこそ、方眼の３Ｄマップデータと方眼イメージマップで座標ズレの原因を探るべきです。

[KEYONN]

>自プレイヤーと敵プレイヤーの座標が確かに必要だと思いますがCameraPosが必要な理由が
>イマイチわかりません。
う～ん、ソースを載せるしかないようですね。


>あとDrawSoftImageって遅くありません？
>マップは別に描画用にLoadGraphで読んでDrawGraphしたほうが良いと思います。
遅いというか、ちょっと凝った３Ｄモデルを描画する方がむしろ遅いです。
まあ、それぞれ環境の違いがあるので、LoadGraphでDrawGraphにしました。

>それこそ、方眼の３Ｄマップデータと方眼イメージマップで座標ズレの原因を探るべきです。
どうやら、座標更新後にマップのレーダーというか、そういうものを描画していて、
DrawGraphで半透明描画していた方は、座標更新前に描画していたのが、ズレの原因だったようです。

それにしても、mayaという高価なソフトウェアを使える環境がうらやましいです。
それとは別に、自分の敵の動きとか、逆走しているかの確認のために、メタセコイアで座標を
１つ１つ、確認し、int [11][2]個の配列にまとめました。

まだ、内積を行えないですが、２つの３次元ベクトルのＸ成分とＹ成分、Ｚ成分をそれぞれ掛け合わして
全て足すという簡単な処理なので、解が正なら、時計回りで半時計周りでも、順走しているのが分かるので、
どうすれば、内積というか、座標の配列と内積を行えるか、考え中です。

[softya（ソフト屋)]

>自プレイヤーと敵プレイヤーの座標が確かに必要だと思いますがCameraPosが必要な理由が
>イマイチわかりません。
う～ん、ソースを載せるしかないようですね。

私もそう思いますが、ちゃんと動いているなら無理して掲載の必要はないです。
いやな予感がするのは、プレーヤーの車を動かさずに地形を動かしているのでCameraPos必要という理由じゃないかという点です。

それにしても、mayaという高価なソフトウェアを使える環境がうらやましいです。
それとは別に、自分の敵の動きとか、逆走しているかの確認のために、メタセコイアで座標を
１つ１つ、確認し、int [11][2]個の配列にまとめました。

mayaじゃなくてもBlender(無料)で出来ると思いますが。

[KEYONN]

＞私もそう思いますが、ちゃんと動いているなら無理して掲載の必要はないです。
＞いやな予感がするのは、プレーヤーの車を動かさずに地形を動かしているので
＞CameraPosが必要という理由じゃないかという点です。
地形は動かしてませんよ。カメラと車をそれぞれ動かしています。
地形を動かしているなら、どうやってレーダーとか、マッピングの
処理を行うのか良く分かりませんし。。。
あと、ちゃんと動いていますよ。おかげさまでズレは直りましたし

＞mayaじゃなくてもBlender(無料)で出来ると思いますが。
Blenderは良いソフトですね。無料ですし、GIMPとの相性も良さそうです。
それに、パーティクルで、煙や水、炎といったものまで計算するとは驚きです。
ただ、Blenderの使い方が一番知りたいところです。
英語を知らないと難しそうです。

[softya（ソフト屋)]

Blenderなら書籍も出てます。

「Blender日本語化関連 - blugjpまとめサイト」　いちおう日本語化プロジェクトもあります。
https://sites.google.com/site/blugjp/bl ... ranslators

「WBS+(Web/Blender Studio+)」　こちらで日本語チュートリアルも公開されています。
http://wbs.nsf.tc/

[KEYONN]

あと、このパソコンは随分古くて処理落ちしてしまいます。
このゲームが遅くてイライラしてしまいます。
そこで、いろいろ調べたら、フレームスキップという方法があるのに気づきました。
http://www.c3.club.kyutech.ac.jp/gamewi ... (2D%CA%D4)
ＦＰＳを１５くらいにすればなんとか収まるんじゃないかと考えています。
カクカクしてしまうのは仕方ないです。

[KEYONN]

コード:

static int FPS=0;
			static int NowTime=GetTickCount();
			static int NowFPS=0;
			if(GetTickCount()-NowTime>1000)
			{
				NowFPS=FPS;
				FPS=0;
				NowTime=GetTickCount();

			}
			DrawFormatString(0,0,GetColor(255,0,0),"FPS=%d",NowFPS);
			FPS++;

と思ったら
このコードで調べたら、ＦＰＳが１０以下でした。敵の車を全て描画対象から外してもＦＰＳが５０以下でした。

[softya（ソフト屋)]

本当に描画の動作だけが遅いのか、処理も含めて遅いのかによって対処が変わります。

ＣＰＵ側が遅い場合はコードはここのが参考になると思います。
「フレームスキップについて • C言語交流フォーラム　～ mixC++ ～」
http://dixq.net/forum/viewtopic.php?f=3&t=11722

ただし、レースゲームですので画面表示をスキップしても車の体感速度は維持しないといけません。
fps_getSkipFrameNum()で経過時間を移動距離に反映するようにしてください。

描画側が遅い場合は、ゲームプログラミングWikiの方式のほうが良いと思います。
まぁ、試してみないと分からないんですけどね。

> このコードで調べたら、ＦＰＳが１０以下でした。敵の車を全て描画対象から外してもＦＰＳが５０以下でした。

１０ＦＰＳならモデルやら地形のポリゴン数などを減らしたほうが良いと思います。
せめて２０ＦＰＳは欲しいです。
どういうスペックのＰＣか分かりませんが、３Ｄ描画が全てＣＰＵ側のソフトウェアで行われているのでは？
DirectX診断ツールでDirect3Dのアクセラレータが利用可能になっているか確認してください。
あるいは、DＸライブラリのLog.txtにソフトウェアレンダリングと書かれているかもしれません(見たこと無いので、どう表示されているか不明です)

[ISLe]

どういうスペックのＰＣか分かりませんが、３Ｄ描画が全てＣＰＵ側のソフトウェアで行われているのでは？

PC版セガラリー・チャンピオンシップはソフトウェアレンダリングで30FPS出てましたけどね。
それも初代Pentium時代に。

[KEYONN]

＞本当に描画の動作だけが遅いのか、処理も含めて遅いのかによって対処が変わります。
はい。

＞ＣＰＵ側が遅い場合はコードはここのが参考になると思います。
＞「フレームスキップについて • C言語交流フォーラム　～ mixC++ ～」
＞viewtopic.php?f=3&t=11722
ちょっと見てみました。
管理人さんのプログラムすごいですね。

＞ただし、レースゲームですので画面表示をスキップしても車の体感速度は維持しないといけません。
＞fps_getSkipFrameNum()で経過時間を移動距離に反映するようにしてください。
画面表示をスキップって具体的にどういうことをやればいいのか分かりません。
ScreenFlip();だけではなさそうです


＞描画側が遅い場合は、ゲームプログラミングWikiの方式のほうが良いと思います。
＞まぁ、試してみないと分からないんですけどね。
描画側が遅かったようです。代わりにメタセコイアで車の色だけを変えた軽いサイズの.xファイルに
変えてみた所、１プレイヤーの車が表示されているだけの状態とほぼ同じ速度
（ＦＰＳ：５０以下）になりました。

＞> このコードで調べたら、ＦＰＳが１０以下でした。
＞敵の車を全て描画対象から外してもＦＰＳが５０以下でした。

＞１０ＦＰＳならモデルやら地形のポリゴン数などを減らしたほうが良いと思います。
＞せめて２０ＦＰＳは欲しいです。
なんとかなりました。一応、これでもこのパソコンでもゲームプログラミングしてきたので、
これでとりあえず、しのぎたいです。

＞どういうスペックのＰＣか分かりませんが、３Ｄ描画が全てＣＰＵ側のソフトウェアで行われているのでは？
＞DirectX診断ツールでDirect3Dのアクセラレータが利用可能になっているか確認してください。
DirectX診断ツールでDirect3Dのアクセラレータは利用可能になっていました。

＞あるいは、DＸライブラリのLog.txtにソフトウェアレンダリングと
＞書かれているかもしれません(見たこと無いので、どう表示されているか不明です)
Log.txtを見ました。ためしに、Ctrl+Fで”ソフトウェア”と検索しましたが、１つもヒットしませんでした。

[softya（ソフト屋)]

もしかして５０ＦＰＳなのは、モニタ画面の更新周期が本当に５０ＦＰＳなのでは無いでしょうか？
モニタ画面の詳細設定で画面のリフレッシュレートが５０Ｈｚなのでは？

>DirectX診断ツールでDirect3Dのアクセラレータは利用可能になっていました。

それなら３Ｄモデルが原因だと思われます。

とりあえず５０ＦＰＳ出て安定してるなら、そのまま進めて良いと思います。

[KEYONN]

＞PC版セガラリー・チャンピオンシップはソフトウェアレンダリングで30FPS出てましたけどね。
＞それも初代Pentium時代に。
ソフトウェアレンダリングは面白そうですね。ただ、あの環境で30FPSは驚異的です。
全てi386のアセンブリ言語なのでは？

[softya（ソフト屋)]

＞PC版セガラリー・チャンピオンシップはソフトウェアレンダリングで30FPS出てましたけどね。
＞それも初代Pentium時代に。
ソフトウェアレンダリングは面白そうですね。ただ、あの環境で30FPSは驚異的です。
全てi386のアセンブリ言語なのでは？

ＰＣ版はDirectX5対応ですよ。DirectXのソフトウェアレンダリングでは？

そういえばモニタは50HZでしたか？

[KEYONN]

モニターは詳細設定を見る限りでは６０Ｈｚでした。
何が原因かは分かりませんが、とりあえず、作業進めたいと思います。
Blenderのモデリングを勉強中です