Visual Studio 2016 Communityを使う †

そこそこ軽い、速い、いつものビジュアルスタジオっていうことで、かなりいい！
パフォーマンスアナライザーがついたプロ仕様、無料、素直、安定している、しかもついにリソースエディタが標準で使える。いままでありがとうresEditまた会う日まで！

↑

SDK群全部入り †

インストールするとDirectXのSDKから、Windows SDKのバージョン違いまで、きっちり整理されてインストールされ、環境変数の設定はもちろんライブラリのパスまで通されている。すげえ、今からガッツリ取り組もうと思ってたのに、普通になにもしなくてもプログラミングできる状態になってるよ！すげえ、俺、これからもWindowsでGame作るね。頑張るよ！

↑

キーバインドが異なる †

Ctrl+Shift+Bでビルドできる。しかし、VC6ライクにF7でコンパイルしたい。

ツール > オプション > 環境 > キーボード

vc2015keyboard.PNG
次の追加キーボードマップスキームを適用で「Visual C++ 6」を選ぶ

↑

ビルドとコンパイルの違いってなんなの？ †

簡単に言うと「ビルド＝コンパイル＋リンク」
厳密にはプリプロセス（前処理）と、コンパイル後のポストプロセス（後処理）なんかも含まれて総合的に実行ファイルを創りだすのがビルド。
コンパイルはビルドの中の作業の１つ。

↑

ソリューション(sln)とプロジェクト(vcproj,vcxproj) †

プロジェクトの設定ファイルがvcproj、プロジェクトは１つのソリューションに複数作れるので複数のvcprojを管理しているのがsln（ソリューション）ファイル。プロジェクトが１つしかないなら、どっちを開いても同じ。

-ソリューション.sln（グラディウスII）
--プロジェクト1.vcproj(アーケード版)
--プロジェクト2.vcproj(ファミコン版)
--プロジェクト3.vcproj(PCエンジン版)

※どちらもテキストデータなので開いて編集可能
※vcprojはvisual studio 2010からvcxprojになる

↑

実行したいプロジェクトがアクティブにならない †

vc2015change.PNG
プロジェクトを右クリックして「スタートアッププロジェクトに設定」するとデフォルトのプロジェクトが変更できる

ちなみに・・・、

ツール＞オプション＞アクティブな項目をソリューショネクスプローラーで選択された状態にする。

これすごく便利でなんでデフォルトでチェックが外れているか謎だったけど、プロジェクトが複数ある場合に編集中のソースコードを触っただけでコンパイル対象のプロジェクトが変わってしまうのね。注意、注意。

↑

filtersとか*.suoとか？ †

  • suo・・・・・visual studioのタブ状況とか各種ウインドウの状態を管理。なくてもいい。
  • filters・・・プロジェクトのファイルのフォルダツリーを管理。なくてもいけるがないと苦しい
↑

新規プロジェクトの作成でウイザードが先にすすまない？？ †

アプリケーション設定の画面から先に進めない。
vc2015blank.PNG
なんかバグってるようです、TABキーをおして「完了」ボタンにたどりつくか、マウスで画面を上から下にドラッグすると、なんか強制的にスクロールして「完了」ボタンが見えます

↑

なんかWinMainが読めない、なんだこれは？ †

int APIENTRY wWinMain( _In_ HINSTANCE hInstance, _In_opt_ HINSTANCE hPrevInstance, _In_ LPWSTR    lpCmdLine, _In_ int nCmdShow)

あれ？こんなんだったっけ・・・？なんだ「wWinMain」って。なんで草生やしてんのよ。

３つ目の引数 LPWSTR lpCmdLineをユニコードで受け取るという意味のｗです。
つまりワイド文字に由来します。

なるほど、そうか、じゃあしょうがないね。

あと、なんで引数の前にinとかoutとかついてんのよ。

これはSALと呼ばれるもので、引数の使用方法に関して使用出来る一種のコメントであり、
C++のコード障害対策として用いられています。

ふむう、どうもこれをつけておくと宣言と動作が異なるときに検出してくれるらしい。それはいいけど他所のプログラムで動かない独自仕様をいっぱい入れてくんのやめてほしい。まあwinMainに関してはWindowsしか使わないんだけど。そうやって拡張されたObjective-Cよりはマシかもしれないが、もう普通のCではコードがワイルドすぎてダメなのか・・・。

↑

DirectInputが使えない †

↑

リンカ ツール エラー LNK2001がでる(dinput8.lib) †

↑

GUIDが見えない †

C++ の場合、目的の入力デバイスのインスタンス GUID に対する参照値。C の場合、この GUID のアドレス (「注意」を参照すること)。この GUID は、 
IDirectInput8::EnumDevices メソッドを介して取得するか、または、次の事前定義された GUID の 1 つを使う。 この GUID 値を有効にするには、アプリケーション
は、ソース ファイルの先頭で、他のすべてのプリプロセッサ ディレクティブより前にINITGUID を定義するか、または DXGUID.LIB にリンクしなければならない。

https://msdn.microsoft.com/ja-jp/library/cc351914.aspx
なんだってー！
ソースの先頭でコレを書くか・・・

#define INITGUID

これをリンクする

#pragma comment(lib, "DXGUID.LIB")

今まで必要なかったのに・・・なあ。

↑

fatal error LNK1112: モジュールのコンピューターの種類 'X86' は～　が出る †

 fatal error LNK1112: モジュールのコンピューターの種類 'X86' は
対象コンピューターの種類 'x64' と競合しています

ありがたや↓
http://blog.livedoor.jp/nanoris/archives/51745346.html

「 プロパティ」 - 「リンカー」 - 「詳細設定」 - 「対象コンピュータ」 に
 MachineX64 (/MACHINE:X64) にした時にツールバーにある「ソリューションプラット
フォーム」が Win32 のままである。または、 x32 のプロジェクトを x64 のプロジェクトに変更した。
↑

作業ディレクトリと実行ファイル出力フォルダなど †

ルートディレクトリにrunフォルダを作って実行ファイルを出力する

Output Directory ・・・$(SolutionDir)run\

デバッグ時の作業フォルダを設定

Working Directory ・・・$(ProjectDir)
　↓
Working Directory ・・・$(SolutionDir)run\