Win用に趣味で2Dゲームを作っている（というか ライブラリ的な下回りを作って満足って状態だったり。 でも、ちょっと前お仕事絡みでwin用の軽いgameを作るときに流用したり）。
そのとき調べたり/知ったりしたことで気になったことを、 ネットや本で見ただけのことや自分でやったヘマなど、 信憑性は無いだろうけれど、とりあえずメモ （WinでGame作ってるような人にはごくあたり前だろうことでも 忘れっぽい自分のために）。
MS の DirectX のマニュアルは、VC付属のDX5のヘルプや
ダウンロードできるDx7のヘルプ、あるいはMSのサイト内のDX6のページ、
などのオンラインものや、MSオフィシャルとして書籍で出てる黒い本
など、ある。
けれどそれらだけでは、実際に普及しているハードのサポート具合/制限が
わかりにくい。結局、自分でGカードをテスト/調べる必要があるのだけど、
結構ネットでそれらを調べられた方のページがあったり、
ゲーム作られてる方の経験談などに有用な情報があったりなので
それらを思いっきり参考にさせてもらったりする。
オフィシャルでない書籍では、工学社のI/O別冊の
DirectX7実績プログラミング
(DircxtX実績プログラミング)
はDirectXの取っ掛かりには結構よかった
（他にも工学社はWinでGame作成関係のムックがあった。
他社もあるけれど……全体にDirectXベタなモノは少ないのかも）。
で。
Gカード自体はハードでいろいろ機能を持っていたとしても
DirectDrawのみではそれらの機能は提供されず、
使いたければDirect3D(IM)を用いることになる。
D3IM とかだと、結局ある程度メジャーなGカードの性能
の最大公約数的に機能を選ぶんだろう（もちろんルーチンの
場合分けもするだろうけれど）。最低ラインをどこに
するかは作るゲームにもよるんだろうけれど。
個人的には自力描画なルーチンで2Dやってて速度思うと
D3IMは魅力に思えてきてて、そのせんでちょっとサンプル的な
ことをしただけなんでホント何もやってないのだけど。
音楽はからっきし苦手なんで、凝ったことはしない（出来ない）。
SEの再生とBGM 用にWAVストリーム再生が取合えずできればよしな
奴なんで……。
WAVの(同時)再生とかがきちっとマルチメディアAPIのほうで 出来たら、軽めのゲームならば、わざわざDirectX使わんでもすむのに （画面は自力描画することにして、パッドはマルチメディアAPIで用意されてるし (フォースフィードバックが不要ならば むしろDirectInputよりも扱いやすいし)）、 と思うも今は Win98もWin2Kも最初からDirectXが入っているので かえって DirectX無い環境用意するほうが手間だったりする （起動時チェックのテスト用に素のWin95マシンを用意したり）。
で、凝ったことはせず、ごくオーソドックスなDX5(?3?)なルーチン
だったのだけれど、
テストプレイをしていたとき音のでないマシンがいくつかあった。
他のゲームとかではちゃんと音が出ているのに。
己のは DirectSoundの Createに失敗したりプライマリ・バッファの
確保に失敗したりする。
色々試しているうち、実はDirectX7 付属のサンプルでも同様な症状が
起こるのだった（がってむう）。
右往左往したが結局、ゲーム全体でDX5の機能しか使っていないので
リンクするライブラリをDX7 でなく DX5 にしたところ、きっちり音が
なるようになったのだった。
ならなかったマシンはDX7がインストールされているのだけれど（8/2と思ってたが
どうもみな素のWin98(すべてが初代かSEかどうかは未確認)のようだった）。
ライブラリ……お馬鹿な状況には脱力。
実はMIDI再生もとりあえず対応はしてみた。DirectMusicで鳴らしたり、
ネットで配布されているGPL というゲームライブラリ中の MIDI ルーチンを
流用してみてりはしたけれど、結局データどうすんねんとかいう問題もあるが、
自分のマシン環境(YMF744なカード)で
MIDIでBGM を鳴らすと（DM,GPL関わらず）異様に処理落ちしてしまって
使いものにならなかったのだった（人のマシンだと全然大丈夫
だったりしたけれど）。
しかし後日 OSの再インストールしたとき、YAMAHAの
ソフトシンセサイザーS-YXG50をインストールしない状態だと
そこそこまともに動くのが発覚、これが重たかった模様。
単に何か設定が悪いだけのような気もするけれど、よくわからないし
別にインストールしなくても鳴ることはなるのでアンインストール。
素直にクリエイティブのカードにするがよいと痛感かも。
まあGMだのXGだのMIDIの都合が分かってないものにとっては
まともにプログラムあつかえんというのもあるが。
己の作ってたゲームプログラムは一応、フルスクリーンとウィンドウモードに
対応させていたりした。
実行中に窓＜＝＞フルスクリーンを切り替えられるようにしてると
いろいろ面倒があって実質、起動時のオプション選択にしちまってるけれど。
完成品の目標はフルスクリーンとしても
窓モードのほうがデバッグしやすいので、ちょっとめんどくさくても用意
したほうがいいかなあと思う（リモートデバッグしたらいいやん、と言われたら
辛いけれど、基本的に１台しかマシンないしね）。
安全をとって基本的にクライアント領域640x480の画面(窓)で
ゲーム作ってるのだけれど、窓モードの場合、画面全体が640x480だったりすると
結構困ってしまう。窓枠もあるしタスクバーもあるしで、窓を最大化しても
クライアント領域が狭くなる。
800x600以上推奨とかするのもカッコ悪いし。
一応、タスクバーなく最大化したときにどうしても隠れる範囲には
メッセージ等の情報をおかないなどの対策をしたりするけれど（まあ
コンシューマーでのテレビ対策と変わらんわけやし）。
ところで窓の表示位置を CW_USERDEFAULT,CW_USERDEFAULT にしていたのだけれど
（普通考えなければこうしちゃうような気がする）、
あるとき些細な思惑でこれを画面の中央に窓が表示されるようにしてみたら、
意図せずこれが640x480画面でも結構有用な感じ。
画面位置の算出方法の問題だけれど画面が 640x480だと窓のほうが大きすぎて始点は
負の座標になる。窓は画面外にはみ出せるようになっているので別に問題なく表示
される。このとき見える横サイズは640で調度クライアント領域、見えなくなるのは
縁のみ。上下に関してはタイトルバーとファイルメニューの分上に方よりがあるので
すべては消えないけれど、残っているのはうまくファイルメニューのみ。
枠がなく、それなりな画面に見える……。
さらに終了方法をESCキーなり別メニューで用意するなら、ファイルメニューも
いらないので、640x480以下の画面のときは
調度クライアント領域が画面いっぱいになるよう始点位置に調整すれば、
フルスクリーンのゲームに見えるようになる。
（気がついてみれば結構拍子抜けだけど、結構悩んでました）
とりあえず、ルーチンは以下のような感じ。
int cw = 640 + GetSystemMetrics(SM_CXSIZEFRAME)*2;
int ch = 480 + GetSystemMetrics(SM_CYSIZEFRAME)*2
+GetSystemMetrics(SM_CYMENU)+GetSystemMetrics(SM_CYCAPTION);
int cx = (GetSystemMetrics(SM_CXSCREEN) - cw) / 2;
int cy = (GetSystemMetrics(SM_CYSCREEN) - ch) / 2;
if (GetSystemMetrics(SM_CYSCREEN) < ch) {
cy = -(GetSystemMetrics(SM_CYSIZEFRAME)
+GetSystemMetrics(SM_CYMENU)
+GetSystemMetrics(SM_CYCAPTION) );
}
hWnd = CreateWindowEx(0, appName, appName, WS_OVERLAPPEDWINDOW,
cx, cy, cw, ch, NULL, NULL, hInst, NULL);
もっとも起動時のみなんで、ゲーム起動中に画面モード切り替えで640x480に されると困ってしまうけれど。切り替え時にも調整入れるのも手なんだろうけれど、 ここまでくると、もうユーザー責任ってことで無視してもいいかな、って気も する。商品ならば、フルスクリーン固定にしちゃって窓モード無しにするのが 安全だろうし。
以前に自分のやら仕事場のやら知り合いのやら
のマシンでDirectX7 sdk に入っていた DxCapsViewer.exe を
実行した結果のファイルがあるんですが、ちと見ずらいので
、それのうちの
DxCapsViewer.exe は計測したマシンの性能を調べるものみたいで、
画面モードに関してはつながっているモニタの制限を受けてしまい、
Ｇカードのサポートする最大数まで出力されているわけでは無い模様。
でもって、DDの Memory については、計測したときの画面モードや
M/B(ドライバ)のAGPメモリの設定の影響受けているみたいで、
値はかなり見ずらい（値みてそのときの状況を類推できるかもしれないけれど）。
サンプル数が少ないんで焼け石に水には違いないんだけれど、世代がまちまち とはいえ nVIDIA,Matrox,3dfx,s3,ati,intel があるので多少はマシかな？
と。 こちら のページに DX6 のDirectX Info Viewer での結果をちゃんとまとめた表があるので参考になるでそう (テクスチャフォーマットは無し。DX5,DX6のDxView.exeは、画面上では確認できの だけどファイルには吐き出しさないのでそのためかな）。
古い世代と Voodoo を捨てれば 主要どころではテクスチャの 1024x1024 は期待できそうなのかなあ (voodoo5ってどうなったんだろ)。 少し前に知り合いと話たとき、Voodoo にあらせて 256x256に分割して 管理すりゃよいかなあと話したら Gカードによっては PS での右辺下辺の 1ライン問題が発生するかもと脅されてしまう（テクセル座標floatで指定 するんだから何がしかの誤差に悪さされるのかもか） ...悩んでるまに何か試せばいいんだろうが... Voodoo3 のテクスチャフォーマットが 256x256 なのはいいとして 32ビット色がないのわかってから急速に興味が薄れてしまっていたりする。 ノートパソコンを気にしだすとD3D必須はツライく思えてくるし。 やっぱバストアップの表示くらいならば自力αでよいか、って 気も大きくなってきてるのね （境界に半透明置いたバストアップをαでクロスフェードしたりしたい、 とか程度なんだし）。