色々調べて、2010.2 でのメモリリークは解決できるっぽいけれど。2011.3のメモリリークは無理くさい。
ってか、APIいっさい呼んでないのに、メモリリークって・・・w

結局、メモリリークがない、2011.2 を使う事に。
APIが若干変わってるみたいだから、あとで新しいバージョンでたら、結構大変だわw

2010.2 のメモリリークはこちらを参照に。
FBX SDK 2010.2 のメモリリークがなくならない [FBX]

とりあえず、Debugビルドの時は、
d3dx9d.lib
d3dx10d.lib
をリンクする。

次に、DirectX関数のエラー時のデバッグ情報取得。
dxerr.lib
をリンクして
dxerr.h
をincludeする。

//
// Helper macros
//
#if defined(DEBUG) | defined(_DEBUG)
#define DXTRACE_MSG(str)              DXTrace( __FILE__, (DWORD)__LINE__, 0, str, FALSE )
#define DXTRACE_ERR(str,hr)           DXTrace( __FILE__, (DWORD)__LINE__, hr, str, FALSE )
#define DXTRACE_ERR_MSGBOX(str,hr)    DXTrace( __FILE__, (DWORD)__LINE__, hr, str, TRUE )
#else
#define DXTRACE_MSG(str)              (0L)
#define DXTRACE_ERR(str,hr)           (hr)
#define DXTRACE_ERR_MSGBOX(str,hr)    (hr)
#endif

内部で上のマクロが定義されているので、これを使って取得する。

HRESULT hr = D3D10CreateDeviceAndSwapChain(); // 引数は省略
if (FAILED(hr)) {
  DXTRACE_ERR_MSGBOX(L"Failed.", hr);
}

お好みに合わせてどのマクロを使うかを選択すればいいかな。

#ifdef _WIN32
#include 
#endif // _WIN32

#include 
#include 

class LFGLContext
{
 public:
  LFGLContext();
  ~LFGLContext();

#ifdef _WIN32
  /** Create object resource. */
  bool Create(HWND hWnd);
#endif // _WIN32

  /** Release object resource. */
  void Release();

  /** Resize backbuffers */
  bool Resize(GLsizei width, GLsizei height);

  /** Swap back buffer */
  bool SwapBuffers();

 private:
#ifdef _WIN32
  /** OpenGL Rendering context. */
  HGLRC hGLRC_;

  HWND hWnd_;

  /** Windows device context. */
  HDC hDC_;
#endif

  GLfloat ratio_;
};

LFGLContext::LFGLContext()
{
  this->hWnd_ = NULL;
  this->hDC_ = NULL;
  this->hGLRC_ = NULL;
}

LFGLContext::~LFGLContext()
{
  this->Release();
}

#ifdef _WIN32
bool LFGLContext::Create(HWND hWnd)
{
  if (!hWnd) {
    return false;
  }

  this->hWnd_ = hWnd;
  // Get device context from window handle.
  this->hDC_ = GetDC(this->hWnd_);

  // Set the pixel format for the device context.
  PIXELFORMATDESCRIPTOR pfd;

  memset(&pfd, NULL, sizeof(pfd));

  pfd.nSize = sizeof(pfd);
  pfd.nVersion = 1;
  pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER;
  pfd.dwLayerMask = PFD_MAIN_PLANE;
  pfd.iPixelType = PFD_TYPE_RGBA;
  pfd.cColorBits = 24;
  pfd.cDepthBits = 16;
  pfd.cAccumBits = 0;
  pfd.cStencilBits = 0;

  int pixel_format = ChoosePixelFormat(this->hDC_, &pfd);
  if (0 == pixel_format) {
    return false;
  }
  if (FALSE == SetPixelFormat(this->hDC_, pixel_format, &pfd)) {
    return false;
  }

  this->hGLRC_ = wglCreateContext(this->hDC_);
  if (!this->hGLRC_) {
    return false;
  }

  // Create render device context.
  if (FALSE == wglMakeCurrent(this->hDC_, this->hGLRC_)) {
    return false;
  }

  glClearIndex((GLfloat)1.0f);
  glClearDepth(1.0f);

  // Enable depth test.
  glEnable(GL_DEPTH_TEST);

  return true;
}
#endif // _WIN32

void LFGLContext::Release()
{
  if (this->hGLRC_) {
    wglMakeCurrent(NULL, NULL);
    wglDeleteContext(this->hGLRC_);
    this->hGLRC_ = NULL;
  }

  if (this->hWnd_ && this->hDC_) {
    ReleaseDC(this->hWnd_, this->hDC_);
    this->hWnd_ = NULL;
    this->hDC_ = NULL;
  }
}

bool LFGLContext::Resize(GLsizei width, GLsizei height)
{
  glViewport(0, 0, width, height);

  this->ratio_ = (GLfloat)width / height;

  glMatrixMode(GL_PROJECTION);
  glLoadIdentity();
  gluPerspective(45.0f, this->ratio_, 3.0f, 7.0f);
  glMatrixMode(GL_MODELVIEW);

  return true;
}

bool LFGLContext::SwapBuffers()
{
  if (FALSE == ::SwapBuffers(this->hDC_)) {
    return false;
  }

  return true;
}

Windows API叩いた事ある人ならなんとなく分かるかも？
2D描画の時に使っていた、DC（デバイスコンテキスト）から、OpenGLに対応した、GLRC（GLレンダリングコンテキスト）を作成する流れになる。

wglCreateContext

後はもう普通に OpenGL の描画処理などをやって、最後に、 SwapBuffers を呼び出すのを忘れなければ大丈夫。

Mac環境もあれば、Macにも対応させておきたんだけれど、Mac持ってないんだよねーw
システムエンジニアやっていた人間としてはかなり珍しいかもね・・・Mac持ってないの。

_CrtSetDbgFlag

を使って、メモリリークをチェックできるらしい。

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

大抵は、起動時にこんな感じで呼び出す。

指定するフラグの詳細はこちらなどを参考にどうぞ。
http://msdn.microsoft.com/ja-jp/library/5at7yxcs(VS.90).aspx

_DEBUG が define されている時だけ有効になるらしいので、呼び出し側で明示的に、_DEBUGを意識する必要性はないみたい。まあ、こんなのが動いていたら、遅くなるだろうしねー

Visual Studio 2008 Service Pack 1 および .NET Framework 3.5 SP1

とりあえず、SP1を使うと、C++的に何が違うかというと、単純なC++のバージョンアップか。
boostのライブラリの一部が、標準ライブラリに採用されている。

将来的には、C++0x から、std:: で使えるようになるらしいけれど、今は、 std::tr1:: で使える。
shared_ptr なら、std::tr1::shared_ptr なわけだ。
長いな・・・ｗ

typedef で、短くするというのは、自分のコーディング規約的にはやらない方向性なので、とりあえずは、長いまま書いておくか。

ちなみに、tr1 は Technical Report 1 の略らしい。

Linuxだと、gcc44が既に使えるから、試してみるのもいいかもね。

#include <mmsystem.h>

timeBeginPeriod(1);
DWORD currentTime = timeGetTime();
timeEndPeriod(1);

この時 winmm.lib にリンクを張る必要性がある。

UNIX系なら

#include <sys/time.h>

gettimeofday()

で取れるらしい。
こっちはまだ試してない。

デバイスではなくて、ドライバ（API) だけれど、DirectX と openGL のそれぞれに依存している部分を
どの程度依存を強くするか。というのが、両方に対応させるポイントかなと。

たとえば、C++ で InterfaceClass を定義して、それを継承したクラスが
DirectX用の Vector, openGL用の Vector クラスを内包していて
Interfaceは統一されている状態であっても、そのポインタを更に DirectX 用の API に渡すには更にキャストが必要。
しかも、そこに必ず DirectX 用の Vector オブジェクトがこないといけない。
ポインタとしては、抽象クラスに一度キャストされているし、受け口もそうすれば受け取れるけれど
中身が違ったら結局実行時エラーが出る。
それじゃ、抽象化に成功しているとはいえない。
組む時の苦労は何も減らない。むしろ、キャストしてただ単にパフォーマンスが落ちるだけじゃないのか？

どんなに Vector や Matrix, Light を抽象化しようが、最終的にはそれぞれの API が指定しているオブジェクトを渡さないといけないんだもん。

って言うことで、余り依存関係を弱くしても、それがシステム的にいい設計とは限らないと思うわけです。
じゃあ、どこまでを依存にして、どこからを非依存にすれば
ゲームエンジンとして、性能がいいのだろうか？

おそらく、デバイス依存する部分はがっつり依存する。つまり描画周り。
そこを、きちんと切り出しておいて、DIコンテナみたいに、動的に入れ替えが出来れば問題がないはず。
アスペクト指向ってやつかな。

で、ゲーム側ロジック側では抽象クラスとしてしか扱わない。
つまり、InterfaceClass のポインタを受け取って、その関数を扱うけれど、オブジェクトには直にアクセスしない。
描画部分だけは、InterfaceClassのポインタではなく、完全にデバイス依存のオブジェクトポインタを受け取る。
これで、ある程度は分離できるはず。

Javaのフレームワークで、散々アスペクト指向というものに触れてきたけれど
それが役に立っている感じ？

まあ、オブジェクト指向、アスペクト指向、エージェント指向って色々あるけれど
プログラムを本格的に組んでいると必ずぶち当たる壁に対する、解決手段思想だよね。

たまに、そういう思想を一切勉強しないでプログラムを組んでいる人を見かけるけれど
そういう人って、性格にもよるけれど、ちょっと困る場合が多い。

大抵の場合そういう人のプログラムは読めないし、後から変更が出来ない、どこかをいじると次々と動かなくなる。
という場合が多いからだ。

個人差はあるけれど、自分が見かけた人たちは、得てして頑固な性格をしていて
根拠がない理由で頑固なんだよね。

これはどうしてこういう方法を使っているの？
このカラムは何でこのテーブルにあるの？
って聞いても、なんとなく。って答えるんだよね。

まあ、話はそれたけれど、その思想への好き嫌いはそれぞれあるだろうし
勉強しなくても、別にいいんだけれど

他人が読めるプログラムを組んで欲しい。
それに付きます。
動けばいい。っていうプログラムの組み方する人のプログラムはもう二度と見たくないなぁ・・・

リファレンス見てみたら、メッセージがなくても待機しないからループ処理ががんがん走るっぽいね。

今回作りたいプログラムにこれを使うのは危険なので、GetMessage使っておこう。

DirectXサンプルの中では、PeekMessageをやって、メッセージ処理がなかったら、Render関数を呼び出すという
処理をしているんだけれど、これは簡単なサンプルだからやっている事で
実際のプログラムだと、Threadの方でRender処理をすれば良いから
時に問題はないかなぁ・・・

むしろ、Message処理をしている間に、Renderがまったく止まるのは実際のプログラムとしては
厳しいかなと。
まあ、要件次第だけれど、俺は止めたくないなー

VisualStudio 2008 で容量をけちって、VC++だけをインストールしたら

プロジェクト : error PRJ0003 : ‘cl.exe’ の起動中にエラーが発生しました。

というエラーが発生。

ぐぐったら、まず、PATHが通っていないんだろう。って事なので

ツール -> オプション -> プロジェクトおよびソリューション -> VC++ディレクトリ
C$(VCInstallDir)bin
以外に
C:\Program Files\Microsoft Visual Studio 9.0\VC\bin
を追加。

それでも解決しなかったので、VC#をインストールしたら解決した。

自分の環境では
C:\Program Files\Microsoft Visual Studio 9.0\VC\bin
の設定をはずしたらまた同じエラーが出たので両方必要な場合もあるっぽい。

（mayaは、2008, 2009 両方で動作確認。 VisualStudioは2008で確認）
maya + VisualStudio をインストールする。

C:\Program Files\Autodesk\Maya2009\devkit\pluginwizard
内にある、「MayaPluginWizard2.0.zip」を解凍する。
「_MayaPluginWizard」フォルダが作成される。

解凍したフォルダ内の
MayaPlugInWizard.vsz
を編集

Wizard=VsWizard.VsWizardEngine.7.1
↓
Wizard=VsWizard.VsWizardEngine.9.0

「MayaPlugInWizard.ico」、「MayaPlugInWizard.vsz」「MayaPluginWizard.vsdir」 を
C:\Program Files\Microsoft Visual Studio 9.0\VC\vcprojects
へと移動。

「MayaPluginWizard」を
C:\Program Files\Microsoft Visual Studio 9.0\VC\VCWizards
へと移動

C:\Program Files\Microsoft Visual Studio 9.0\VC\VCProjectDefaults
内にある、「CoreWin.vsprops」を開き、編集。

AdditionalDependencies=”kernel32.lib”
↓
AdditionalDependencies=”kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib”

ODBCとか使ってる時は、odbc用のlibも読み込まれている場合がある。

File -> New -> Project -> Visual C++ -> MayaPluginWizard を選択する。
（この時点で表示されいない場合、今までの設定に間違いがある）

次にプロジェクト毎に、インクルードファイル、libファイルの設定を行う。

Project -> [Project Name] properties… [Alt + F7]
Configuration Properties
  C/C++
    General
Additional Include Directories
に
C:\Program Files\Autodesk\Maya2008\include
を追加する。

Configuration Properties
  Linker
Additional Library Directories
に
C:\Program Files\Autodesk\Maya2008\lib
を追加する。

MayaPluginWizardを使わなくくても、エントリークラスと設定がきちんと書かれていれば
maya plugin として、きちんと認識する。