C/C++ゲーム製作総合スレッド Part4

**名前は開発中のものです。** · 2013/08/12(月) NY:AN:NY.AN

ゲーム製作におけるC/C++全般に関するスレです。

元スレ
DXライブラリ総合スレッドその12
http://toro.2ch.net/test/read.cgi/gamedev/1330000532/

前スレ
C/C++ゲーム製作総合スレッド Part1
http://toro.2ch.net/test/read.cgi/gamedev/1337516528/
C/C++ゲーム製作総合スレッド Part2
http://toro.2ch.net/test/read.cgi/gamedev/1351015269/
C/C++ゲーム製作総合スレッド Part3
http://toro.2ch.net/test/read.cgi/gamedev/1357899040/

**名前は開発中のものです。** · 2013/11/08(金) 14:24:03.36

>>612
シーンの変更というよりは、ミニゲーム２つ3つ作るようなもんじゃん？
もちろん使い回すコードはあるにしてもさ。

**名前は開発中のものです。** · 2013/11/08(金) 15:08:13.78

それぞれのシーンが難しくないならば、ふたつ作るのもたいして変わらない
一桁の足し算を100回やるのは面倒ではあるけど難しくはならないだろう？

**名前は開発中のものです。** · 2013/11/08(金) 15:08:15.81

ソースに文章書き込むなら簡単だけどスクリプトとか文字列操作熟知してないと難しそう
えんいー

**名前は開発中のものです。** · 2013/11/08(金) 20:11:46.11

スクリプトの作成ってインジェクション対策がめんどくさそう
ある程度適当な文法でもエラー出力作ってなかったら通っちゃうだろうし
外部に置くってなると他人に触らせること前提ってイメージがある

**名前は開発中のものです。** · 2013/11/09(土) 02:42:05.48

他人の作った組み込みスクリプトを使うという方法もある
けれども基本的には、自作する事で得られる様々な知識や知恵の方が大事かと
まあ簡単なノベルゲームやアドベンチャーゲームの一つ二つ作るつもりで挑むべし
つーか、これらのゲームも基本的にはスクリプトを使ってると思った方が良いかと

**名前は開発中のものです。** · 2013/11/09(土) 10:47:13.41

そもそもシーンの変更を扱う方法はスクリプトに限らない。
マルチスレッドを使う方法もあれば、タスクシステムを使う
方法もある。フラグや分岐や関数ポインタでえっちらおっちら
やったっていいし。どの方法にも一長一短がある。どうせ内部で
どんな挙動をしているかは作ったプログラマにしか分からない
んだし、自分の好きなやり方でやるべし。

**名前は開発中のものです。** · 2013/11/09(土) 11:16:02.17

>>613
そういう人たちにはむしろ組み込みスクリプトを教えた方が良いのかもしれんな
組み込みスクリプトを使っている人達には迷惑かもしれんが

**名前は開発中のものです。** · 2013/11/09(土) 11:31:05.04

シーンの変更はオブジェクト指向で実現しようとすると難しいなぁ
主に共有したいデータのやり取りとか

あと、コンソールゲームと違ってループを意識して状態を保存できないといけない
Boostにコルーチンあるけど、自分のに組み込むほどの理解には至れないなー

描画を別スレッドにするのでも良いけど、マウスゲーのように画面と操作（MV）が密接に
関わっているような作りだと、フレムワーク自分で作るのは骨だろうね

**名前は開発中のものです。** · 2013/11/09(土) 11:53:07.42

自前主義からの脱却を

**名前は開発中のものです。** · 2013/11/09(土) 12:59:59.47

シーンごとに別のループを用意するんじゃダメなの？
俺の場合、メインスレッドを用意して、シーンごとに別のループを作ってるが。
この方法の問題点は同期処理関連をおろそかにするとフリーズする事かな？
Windows7以降だとそうでも無いんだが、昔のOSだとOSごとフリーズするので、
デバッグでは苦労した覚えがある。

**名前は開発中のものです。** · 2013/11/09(土) 14:51:11.85

>>621
ごめん、なんか引っ掛かった。

＞シーンの変更はオブジェクト指向で実現しようとすると難しいなぁ
＞主に共有したいデータのやり取りとか

それ、全体としての実装手法の話と、アプリケーション固有の(自分自身の)設計の話が切り別れて無い印象を受けた。
もしかして固定的な何か一つの実装をイメージしてないか？

複数スレッド使う事や全体としてOOの考え方で実装する事と、シーンの変更がしんどいか否かはレイヤの違う話かと。

**名前は開発中のものです。** · 2013/11/09(土) 18:30:15.80

ループは一つにしておけよ・・・

**名前は開発中のものです。** · 2013/11/09(土) 18:34:25.44

ソースが分かりにくくなるから却下

**名前は開発中のものです。** · 2013/11/09(土) 19:32:06.23

一つのメインループの中で、現在設定されてるシーンに対応したイベントと描画処理を呼び出すのではいかんのか

**名前は開発中のものです。** · 2013/11/09(土) 19:34:22.11

例えば、シーンが変わるごとに同じループでフラグ管理とかポインタ関数管理とかやってると、
一度に二重三重のシーン変更処理が入った場合にバグを発生させる可能性が高くなるからな。
シーンごとに別ループで管理しておけば、少なくともそういったバグが出る可能性は無い。

**名前は開発中のものです。** · 2013/11/09(土) 19:41:29.60

昔のOSでフリーズしてる時点でバグが有るんだろｗ

**名前は開発中のものです。** · 2013/11/09(土) 20:03:13.90

スレッドの同期関連のバグとシーン変更関連のバグを同列で扱う馬鹿よりはマシかと

**名前は開発中のものです。** · 2013/11/09(土) 20:22:26.69

昔のOSはちょっと間違えるだけでフリーズしたりブルースクリーンが出たりして大変だったよな

**名前は開発中のものです。** · 2013/11/09(土) 20:53:32.08

MS-DOS時代はフリーズしてもあんまし文句言われなかったのにな

**名前は開発中のものです。** · 2013/11/09(土) 21:08:02.88

DOS時代だって数百万円するのに使えないCADとか不満多かったけど
バックアップするにもドライブ遅いから時間かかるし
一太郎だって安定してた4.3を使い続けたりだとか

**名前は開発中のものです。** · 2013/11/09(土) 21:13:23.84

うーん、そんなに複雑になるものかな？
自分の場合、ゲームのメインループ自体の仕事はFPSの計測と負荷調整だけで、いつシーンが変更されたかなんて気にしなくていいような設計にしてたもんで……

**名前は開発中のものです。** · 2013/11/09(土) 21:27:56.92

でも昔はリセットボタンを手軽に押せたけど今は手軽に押せないじゃん
っていうか、最近リセットボタン使ってないなぁ･･････

**名前は開発中のものです。** · 2013/11/09(土) 22:00:01.21

>>634
RPGで？それは凄いな。バグの解析で頭こんがらがらない？

**名前は開発中のものです。** · 2013/11/09(土) 22:18:31.84

メインループ設けるだけでバグの解析が難しくなる設計ってどうやるんだ

**名前は開発中のものです。** · 2013/11/09(土) 22:34:39.14

岩押したり船やドラゴンに乗ったりNPCを特定動作させたりランダム動作させたり
あと何やったかな？そんな所ですが

**名前は開発中のものです。** · 2013/11/09(土) 22:39:32.94

>>636
俺の場合、最初と次に作ったゲームはシーン毎にループ処理やってたけど、
それ以降はメインループ一本にしたら、管理とか変更とかすげー楽になった。

**名前は開発中のものです。** · 2013/11/09(土) 22:51:18.18

設計の意味知らないんじゃん・・・

**名前は開発中のものです。** · 2013/11/09(土) 22:56:46.28

>>639
ID凄ぇ
なんか、自分とは逆だな。昔はメインループ一本だったのに、今はループを分けて作ってる。
バグを出さない方向に工夫した結果なんだがな。

**名前は開発中のものです。** · 2013/11/09(土) 23:17:49.74

>>640
DQ2とFFを足して割ったようなゲームを作る以上の事は特に考えずに、
その場の思いつきでRPG作ってるからなぁ・・・

**名前は開発中のものです。** · 2013/11/10(日) 00:26:02.25

久々にひどいワナビバカを見たわｗ
アマチュア時代は自分で思いついたことを素晴らしいことだと思わず、
すでに実績のあることを自分のものにすることに力を入れたほうがいいぞ。

**名前は開発中のものです。** · 2013/11/10(日) 00:56:13.82

>>638
メインループとゲームのロジックは、明確に分けるべき。構造化プログラミングすら出来てないんじゃないか？

**名前は開発中のものです。** · 2013/11/10(日) 01:01:54.40

横レスだけど
ヤバイ
何を言ってるのか理解できない
ボクはプログラミング力が低いらしい

メインループ内でシーンマネージャー呼ぶ
シーンマネージャーの中で各シーンの処理を呼ぶ
各シーンの処理の中でそのシーンでやりたいことの処理を呼ぶ

こんな感じじゃダメなの？

**名前は開発中のものです。** · 2013/11/10(日) 01:12:04.49

いいよそれで

**名前は開発中のものです。** · 2013/11/10(日) 04:24:39.77

>>645
普通に考えるとそういう設計になると思う。てか、ドシンプルに最初に書く屋台骨ってそうなると思う。
合ってる。そういう設計プロセスのイメージが出来ない人ってのが、つまり >>613 に書かれてるような、考えと整理の経験が足らない人って事になると思う。

**名前は開発中のものです。** · 2013/11/10(日) 11:41:35.08

メインループを分けるってことはメッセージ処理をあちこちから呼び出すってことが

**名前は開発中のものです。** · 2013/11/10(日) 12:17:49.63

それのどこがわるいんだ？龍神録の講座でもメインループは一つのみ、
複数あったら設計がおかしいとか書いてあるけど、
メッセージ処理とかするのに、わざわざ深いネストから抜けないといけないじゃん。

**名前は開発中のものです。** · 2013/11/10(日) 12:19:33.98

メッセージ処理とやらをシーンがやんの？

**名前は開発中のものです。** · 2013/11/10(日) 12:30:53.34

メッセージ処理をまとめた関数をシーンが自由に呼び出す

**名前は開発中のものです。** · 2013/11/10(日) 12:37:54.22

ゲームのメインループはメインスレッド上に用意し、
メッセージループはDirect3Dのオブジェクト管理をしているが？

**名前は開発中のものです。** · 2013/11/10(日) 12:41:34.36

なんかマルチスレッドとか使ったらすごい複雑になりそう

**名前は開発中のものです。** · 2013/11/10(日) 12:49:18.45

同期処理関連を理解してれば問題無い

**名前は開発中のものです。** · 2013/11/10(日) 13:08:34.27

メッセージループでPeekMessage使うとCPU使用率が100%にならない？
それが嫌だからマルチスレッド使ってる。

**名前は開発中のものです。** · 2013/11/10(日) 13:12:44.88

100％になるのはSleep入れてないからでは？

**名前は開発中のものです。** · 2013/11/10(日) 13:17:53.86

>>651
メッセージ処理とやらをシーンから呼び出す必要があんの？
メッセージ処理って何？

**名前は開発中のものです。** · 2013/11/10(日) 13:20:58.54

メッセージループにSleep入れるとOSの動作が不安定になってただろ？

**名前は開発中のものです。** · 2013/11/10(日) 13:22:25.04

>>657
普通にPeekMessageとかのウィンドウ一連の処理。

**名前は開発中のものです。** · 2013/11/10(日) 13:24:07.25

>>658
いや？不安定になるのは長く入れすぎじゃないか？
むしろSleep(0)として、ほかのスレッドに処理渡さないと逆に不安定になると思うが・・・・

**名前は開発中のものです。** · 2013/11/10(日) 13:27:24.32

>>658
普通ならない。
>>660も言ってるけど、OSと自分の書いてるアプリケーションの関係、つまりメッセージの循環(OSのメッセージポンプ、メッセージディスパッチ)の
立場とか意味わかって書いてたらならないと思う。

**名前は開発中のものです。** · 2013/11/10(日) 13:35:43.16

>>660
昔、PeekMessageにSleep(16)とかやってたなぁ、そういや。
今はGetMessageにタイマースレッドとメインスレッドを組み合わせているから関係ないが。

**名前は開発中のものです。** · 2013/11/10(日) 13:46:45.40

http://codepad.org/Vx38Y7XI

**名前は開発中のものです。** · 2013/11/10(日) 13:55:30.97

↑まずこの土台の中で、抜けてる考えが無い前提の上で、話してるんだよな？

＞今はGetMessageにタイマースレッドとメインスレッドを組み合わせているから

ちょっと引っかかったけど、GetMessageってただ単にOSのメッセージキューからメッセージ引っこ抜いて構造体に詰めてくれるだけ、かつ
取得するまで処理が返らない訳だから、書かれてる内容から察すると、要は別スレッドから OSのメッセージキューにお構いなしにブチ込んで
自分のやりたい処理はウィンドプロシージャへのディスパッチ経由で動かしてるって言う、なんか変に遠回しな方法になってるけど
そこら辺の動作はちゃんと見えてる上で、設計してるか？

**名前は開発中のものです。** · 2013/11/10(日) 14:04:21.67

そこら辺は俺もちょっと気になった。ループがタイマーに依存するから、
常にアイドルイベント発生させて、そっちでやったほうが良いような・・・

**名前は開発中のものです。** · 2013/11/10(日) 14:09:57.12

昔のコードを見るのは久しぶりだな。土台の部分は
while (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
ままだよ？WinProcは最近は全然いじってない。
主にいじるのはメインスレッドだけ。

**名前は開発中のものです。** · 2013/11/10(日) 14:10:22.48

いや、そういえばマルチスレッドか。
メインスレッドはどういう処理を司ってるの？

**名前は開発中のものです。** · 2013/11/10(日) 14:18:19.26

我はメインスレッド
世界を司るものなり

**名前は開発中のものです。** · 2013/11/10(日) 14:19:11.46

>>668
ﾜﾛﾀｗ

**名前は開発中のものです。** · 2013/11/10(日) 14:19:41.06

>>666
自分の設計による実装都合の範疇だから良い悪いを言う話じゃないが、そこに書かれてる動作って基本的に、

「OSと言うプログラム側が行っている、一番大きな、こちらからは見えないレイヤのループの中で、
OS管轄のメッセージキューにメッセージが放り込まれるまで　『待機する』　形式」　なので、

それで要件が間に合うならそれでいいし（例えばOSベンダ提供のAPIを単に利用したユーティリティとか）、そうでないなら違う。
そこの意味と切り分けをした上での選択であれば、普通の処理だよ。

そしてメインスレッドってのは、そのメッセージループを「OSと言うプログラムが、自分のアプリケーションコードを、エントリ関数から実行している最初のスレッド」の事なので

＞主にいじるのはメインスレッドだけ。
↑この言い様と書かれたコードの間に差異があるように見える。

**名前は開発中のものです。** · 2013/11/10(日) 14:28:22.95

メインスレッドでゲームの主な処理全般をやってて、WinProcがレストア対策とかを、
タイマースレッドはこんだけ。
DWORD _DrawTim(LPVOID pParam)
{
while(g_boolTimeLoop)
{
Sleep(DRAW_TIME_WAIT);
SetEvent(m_hMainEvent);
}
PostMessage(g_hWnd,WM_SYSCOMMAND,SC_CLOSE,NULL);
return 0;
}

**名前は開発中のものです。** · 2013/11/10(日) 14:29:39.91

あぁ、もしかして >>666 が言っている　「メインスレッド」　って、いわゆるメインスレッドじゃなくて、
「自分で別に起こした、ゲーム処理用のスレッドの事」　の事か。

で、OS側とのポンプを行うディスパッチは、「本当のメインスレッド側に任せている」　みたいな。
もしもそういう意図で言ってるならいいんじゃねと思うが。多分にエスパーだけど。
用語に齟齬がある感じか？

**名前は開発中のものです。** · 2013/11/10(日) 14:33:41.51

>>672
ああ、そういう事を聞きたかったのか。理解力が無くてすまん。
それで当たってる。

**名前は開発中のものです。** · 2013/11/10(日) 14:35:33.82

把握

**名前は開発中のものです。** · 2013/11/10(日) 14:35:58.59

>>671
＞メインスレッドでゲームの主な処理全般をやってて、WinProcがレストア対策とかを、

入れ違ったけど、>>672 で合ってたようだ。
そしてその様子だと、なんかOS側都合の処理と自分のアプリケーションコードと、切り分けないで行ったり来たり混ぜ込んでるみたいだけど
…　いやそれで問題無いなら別にいいが、エラく遠回りな実行パスになってるなぁとは思うけど。

あと "タイマー" スレッドって言うか、それもしかしてハートビート処理してるんじゃね的な印象受けるが。
いや、いいならいいんだけど。

**名前は開発中のものです。** · 2013/11/10(日) 14:44:09.28

一応念の為、今ここで話してる内容は、単に「その人の都合でそう実装してる」の範疇を今の所出ていないので、
一絡げに良い悪いでぶった切れる訳じゃないって事を一応書いておく。

**名前は開発中のものです。** · 2013/11/10(日) 14:50:50.53

えっと、ハートビート処理っていうのか、これ。
始めはマイクロ秒単位に直すべきかな？とは思ってたんだけど、
なんだか最近はどうでも良くなってね。
多分、苦情も出ないだろうと。

**名前は開発中のものです。** · 2013/11/10(日) 15:18:12.54

いや、本当にハートビートなのか単なるタイマーなのかは、その処理がどういう文脈やアイデンティティを持たされて単位化されたかによるので、
違う使われ方なら違うと思うけど、>>671 のコードだけ見ると、一定速で足並みそろえる為だけに別スレッド起こして
定期的に処理全体の速度決めてるみたいだから、それっぽく見えただけ。　ループ１回のテンポ管理って言うか。

**名前は開発中のものです。** · 2013/11/10(日) 15:40:15.07

>>675
レストア関連の処理を登録型にして、オブジェクトの生成時に自動登録してるから変に思うのかな？

**名前は開発中のものです。** · 2013/11/10(日) 15:46:33.19

>>679
？いや全然そういう事じゃなくて、書いてる通り。
あと、「変」と思ってる訳じゃなくて、これも書いてる通り、エラく遠回りな実行パスになってるなぁって話。

＞ OS側都合の処理と自分のアプリケーションコードと、切り分けないで行ったり来たり混ぜ込んでるみたいだけど

こういう事。OS側都合の処理と、自分側都合のアプリケーション設計のレイヤをキレイに整理して分けないで、あえて混ぜ込んでるのかなと思ったって事。
そう思った理由が、要は別スレッドに分けようがどうしようがいいんだけど、いちいちOS側のメッセージポンプ経由してやりとりしてるように見えたから。

**名前は開発中のものです。** · 2013/11/10(日) 16:03:46.14

あああと、こう言ったらいいか。

OSに対してメッセージを送信したり受信したりって動作は、メッセージキューに対してデータをストアしたり自分で取得したりって言葉に置き換えられて、
で、取得したメッセージデータをディスパッチするなりなんなりしてポンプとやりとりするその繰り返しを、つまりメッセージループと呼ぶ訳だけど、

その動作の正体って、要はこちらのアプリケーションコードがOSと協調して動く為に、
OS側の都合で用意された仕組みな訳で、いわば「ここで動く物ならば、書かねばならない事」な訳だけど、

それはそれ、これはこれって話で、逆にこちらのアプリケーションコード側には当然こちらの処理都合や設計がある訳で、
その両者、つまりOS側都合のコードと、アプリケーションの設計に基づく自分都合のコードと、それらの仲立ちをする部分ってのを
明確に分けないで、常にOS側に寄ってるような書き様に見えた、って事。

でも細かい事を言えば、例えば描画処理やキーやマウスなんかの入力状態の取得は
結局OS側API経由で行う訳だから、その意味では完全に切り分かりはしないんだけど、メッセージポンプそのものを直接操作する部分まで
自分のレイヤに置いてるから、実行パスがなんか長く無いか？　と思うって事。　真面目に書くと長い。

**名前は開発中のものです。** · 2013/11/10(日) 16:49:07.90

この手の話で描画を別スレッドでやるとかの話がよく出るんだけど
具体的にどんなふんにやってるのか、それがよくわからんのよね

メインスレッドはメッセージポンプだけ担当させて
メッセージは別の状態更新スレッドに送って、さらに描画を別スレッドでやる？
1/60秒で処理をやるにしても、正確に処理をまわせるのか？って悩んでるんだけど。

**名前は開発中のものです。** · 2013/11/10(日) 17:00:52.03

ゲームスレッドの中に色々とループ処理を入れて
それぞれのシーンを表現しているけれども、
それに違和感を感じたって事かな？

**名前は開発中のものです。** · 2013/11/10(日) 17:02:48.64

描画を別スレッドでやる意味あるのか？
ゲームの処理を終わらせた後じゃないと描画する意味が無いから
メインループ {
1F経過まで待つ
シーンマネージャー処理（ゲーム処理）
シーンマネージャー処理（描画処理）
}

もちろんゲームの処理は中でできるとこだけマルチスレッドにしてもいいけど
こんな感じじゃダメなの？

**名前は開発中のものです。** · 2013/11/10(日) 17:11:59.41

＞描画を別スレッド
自分の場合は描画もゲームスレッドでやってるからそれは何とも言えない。
ただ単純に、
for(int i = 0;i<30;i++){1F経過まで待つ;ゲーム処理;描画処理;}
ってやれると楽そうだな、という発想でゲームスレッドでやってるから。

**名前は開発中のものです。** · 2013/11/10(日) 17:24:20.86

こんな感じ。
//初めのシーン
for(int i = 0;i<30;i++){1F経過まで待つ;ゲーム処理;描画処理;}
//ゲームシーン(breakで抜けるまで続く)
for(;;){1F経過まで待つ;ゲーム処理;描画処理;}
//終了シーン
for(int i = 0;i<30;i++){1F経過まで待つ;ゲーム処理;描画処理;}

**名前は開発中のものです。** · 2013/11/10(日) 17:32:39.17

>>686
sugeee

**名前は開発中のものです。** · 2013/11/10(日) 18:51:24.54

>>686
やっぱり言葉よりコードだな、ようやく言いたいことが分かった。
確かに分かりやすいし書きやすい。
もう少し粒度を小さくしないと、後々大変そうだけどね…

**名前は開発中のものです。** · 2013/11/10(日) 19:02:16.28

どの当たりが楽になったの？

**名前は開発中のものです。** · 2013/11/10(日) 19:19:59.24

簡易的なコルーチンのように使えるはず

**名前は開発中のものです。** · 2013/11/10(日) 19:48:01.12

じゃあコルーチン使えばいいじゃんｗ

**名前は開発中のものです。** · 2013/11/10(日) 19:50:19.66

>>691
？
好きにつかえば？

**名前は開発中のものです。** · 2013/11/10(日) 19:55:37.45

だね

**名前は開発中のものです。** · 2013/11/10(日) 20:22:31.51

データの複製を２つ用意して、計３つ（A、B、C）のデータを
２つのスレッドで構造体のポインタをスワップする方式とか構想したことあるなぁ

Aを描画スレッドが使って、Cをルーチンスレッドが更新、
AとCのスレッド同期待ちを防ぐためにBがあるんだけどメモリ消費３倍の割りに
得るものがほとんどないんだよねｗ

A　←→　B　←→　C

**名前は開発中のものです。** · 2013/11/10(日) 20:43:45.76

描画コマンドをリストに貯めてそいつをダブルバッファとしておけばいいんじゃないの?
DirectX11のマルチスレッド対応も実際には描画してないし

**名前は開発中のものです。** · 2013/11/10(日) 22:37:11.50

垂直同期って具体的にどうやるの？
データから頂点の座標取得したりする描画スレッドとそれ以外のメッセージ処理や更新判定処理スレッドの
二つがあるとして

メインループの中で

更新
判定
描画

ってやってるんだけどちょちょいのちょいで出来るようにならない？
一応オブジェクト指向に則って疎結合を意識してるつもりな設計

**名前は開発中のものです。** · 2013/11/10(日) 22:37:57.03

あ、ごめん、5行目からは現状の話ね

**名前は開発中のものです。** · 2013/11/10(日) 23:25:00.60

OpenGLやDirectX使わないと垂直同期ってとれないんじゃないかな？

**名前は開発中のものです。** · 2013/11/11(月) 00:58:53.66

ちゃんとした垂直同期はDXGIじゃなかったか？
なんちゃって垂直同期は16ms待てばいい

**名前は開発中のものです。** · 2013/11/11(月) 01:43:24.19

DXGIってDirectX10以降か。
それ以前と以降では仕組みが違うんかな。

**名前は開発中のものです。** · 2013/11/11(月) 12:48:03.31

普通にD3D9以前でもできたっぺ
基本フルスクリーンモードでなきゃなんちゃってだけど

**名前は開発中のものです。** · 2013/11/11(月) 16:02:02.14

DirectX9 シェーダプログラミングブックを手にいれたんだけど、ネット見てるとアプリケーションウィザードってのが使えないらしい

これのかわりになるものってありますか？
ちなみにPCはWindows7でDirectX11です。

**名前は開発中のものです。** · 2013/11/11(月) 16:51:39.02

Windows8.1でDirectXが11.2に進化
CPUやメモリへの負荷がさらに軽減され、
超高解像度の大画面などの表示もこれまで以上に快適になりました

**名前は開発中のものです。** · 2013/11/11(月) 16:52:56.35

ほんとかよ(´・ω・`)

**名前は開発中のものです。** · 2013/11/11(月) 18:51:40.86

Windowsが8にしんかした

**名前は開発中のものです。** · 2013/11/11(月) 20:46:10.17

>>702
もしかして VisualStudioのAppWizardの事言ってる？

**名前は開発中のものです。** · 2013/11/11(月) 21:05:44.05

Directx9の時だったかあったかも
最後の方のDirectX9のサンプルを持ってればその中にEmptyProjectってのが代わりにあった
これをそのまま毎回コピペして読み込めばたぶん一緒
最近のVisualStudioなら最初にテンプレートのエクスポートすればコピペしなくて済みそうだ

**名前は開発中のものです。** · 2013/11/11(月) 21:29:01.28

>>707
確かにEmptyProjectってのはありました

テンプレートのエクスポートってのをちょっと詳しく教えてください

**名前は開発中のものです。** · 2013/11/11(月) 21:34:01.50

そもそも必要性がないから無くなったのに、それで何がしたいんだ？

**名前は開発中のものです。** · 2013/11/11(月) 21:36:39.52

VisualStudioのAppWizardの事なら無償のExpress版と有償版で扱い違うから、
テンプレート書き換えの際に注意な。
あと基本的に自己責任

**名前は開発中のものです。** · 2013/11/11(月) 21:37:03.59

>>709
DirectX9 シェーダープログラミングブックではその機能を使って進めてるから、ない場合はどうすればいいのかなと疑問に思っただけ

**名前は開発中のものです。** · 2013/11/11(月) 21:38:00.99

>>709
大体シェーダプログラミングってお題でなんでAppWizard必要なのかってのは
俺もずっと引っ掛かってた

**名前は開発中のものです。** · 2013/11/11(月) 21:40:36.26

>>711
そのお題で言うなら、要点はhlsl書く部分なので、
いつも通りのDirectXコード書いた上で、追加するイメージだよ