DXライブラリ総合スレッドその16

**名前は開発中のものです。** · 2013/06/30(日) 23:57:05.06

Cを習得した程度のスキルでも、ゲームのグラフィックを比較的容易に描画する事のできる、
「DXライブラリ」に関するスレッドです。
DXライブラリに関するテクニックなどの情報交換などを行う事で、
多くのDXライブラリユーザのスキルの向上に役立てたら幸いです。

【公式】
http://homepage2.nifty.com/natupaji/DxLib/

【関連スレ】
C/C++ゲーム製作総合スレッド Part1
http://toro.2ch.net/test/read.cgi/gamedev/1337516528/
ゲームプログラムなら俺に聞け(プログラム技術板)
http://toro.2ch.net/test/read.cgi/tech/1366526476/

●DXライブラリではなくDirectXの質問ならこっちへ
【C++】DirectX初心者質問スレ【C】(プログラム技術板)
http://toro.2ch.net/test/read.cgi/tech/1370015791/

**名前は開発中のものです。** · 2013/10/08(火) 11:21:39.17

PS2も大差ないだろ
基本的に板ポリの量が増えるだけ

**名前は開発中のものです。** · 2013/10/08(火) 11:49:21.01

>>556
詳しく説明&サンプル感謝します
開ける環境に戻ったら勉強します。
しばらくビルボート式を用いて、他のことも含めて余裕がでてきたらシェーダを学ぼうと思います。
何年後のことやら…

**名前は開発中のものです。** · 2013/10/08(火) 11:50:03.23

>>566だミス失礼

**名前は開発中のものです。** · 2013/10/08(火) 12:19:08.14

>>568
腕を重点的に鍛えたいけどどうすればいい？って聞いたら筋トレしろって言われるのと同じだよね
ここ以外でもシェーダーは具体的なの見たことないな

**名前は開発中のものです。** · 2013/10/08(火) 12:53:20.88

>>572
OpenGL関係のスレとか、さもなきゃ書籍でも見たらいいのでは
一応補足しておくと、OpenGLのglslとDirectXのhlslは別物だけど、考え方は同じだよ

**名前は開発中のものです。** · 2013/10/08(火) 12:55:13.56

あ、スレじゃなくてサイト。素でtypo
何も知らない状態で待ってても見かけないと思う。
例えればプログラミングの基礎編にある物じゃなく、必要な人が利用する応用編の範疇の世界だから

**名前は開発中のものです。** · 2013/10/08(火) 13:01:23.14

俺なんて爆発表現は球体ポリゴンに、それっぽいテクスチャ拾ってきて材質設定して貼るだけだぞ
で、エフェクト中は球体を回転させながら透明度だけ弄る
頂点を操作するアニメーションなんてできないし

**名前は開発中のものです。** · 2013/10/10(木) 18:23:43.43

>>512-513
亀だけど、それ当たりで考えるとビリヤードのブレイクショットの配置みたいに
静止しててくっついてる状態でちょっとめんどくさくなると思う

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

接触してる相手の運動ベクトル見て振る舞いを決めればええんや

**名前は開発中のものです。** · 2013/10/11(金) 00:39:09.42

>>575
もう板ポリのテクスチャ変更して3Dドットみたいにしちゃうのか
試してみよう

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

3次元の音響ライブラリってないですか？
音を拾う座標指定して、音量とか減衰率とか反響とか設定できて簡単なやつ

**名前は開発中のものです。** · 2013/10/11(金) 09:13:37.91

なんでそれをDXライブラリスレで聞くんだ？

それはともかくとして、そんなライブラリがあるとしたらXAudio2のラッパということになるだろうけど、そんなのは現在ないっぽい

BASS Audio Libraryという3Dサウンドの使える比較的シンプルなライブラリがあるっぽいが、
日本語のドキュメントは殆どと言っていいほどないみたいなので自力で調べられない人には使えないだろう

**名前は開発中のものです。** · 2013/10/11(金) 09:26:57.30

>>579
この本に具体的に解説してあるから、実装しなさい。

DirectX9必携: 鎌田茂雄: 本

**名前は開発中のものです。** · 2013/10/16(水) 23:39:32.53

C#+DXライブラリでやってるんだけど
スクリーンに黒色で塗りつぶしたところがDrawGraphで透過Trueにしても透過しない
なぜじゃー

**名前は開発中のものです。** · 2013/10/16(水) 23:50:58.42

ブレンドモードは？

**名前は開発中のものです。** · 2013/10/16(水) 23:55:26.73

DxLibを利用した開発で、デバッグしようとすると
数度に一回マウス以外完全にフリーズしてしまいます。

VSの一番下部の青い所がF5を押してデバッグ開始するとそこがオレンジになって、
そこに AudioSes.dll シンボルがどうたら　
と表示されて読み込み中？のまま、マウスポインタは動かせるのですがそれ以外の動作ができなくなります。
タスクマネージャーの起動もできずになって直接電源切るしかなくなります。
このままではHDが死んでしまいそうです。
何が原因かわかる方いらっしゃいませんか？

ぐぐっても、似たような症状の方は見つかるのですが
解決策が出てないのしか見つからないです。
VS Express for Desktop利用です。
windows7 64bitが問題なのかともおもうのだけど。

**名前は開発中のものです。** · 2013/10/17(木) 00:03:15.56

俺が遭遇したことあるトラブルはエレコムのUSBパッドくらいだな

**名前は開発中のものです。** · 2013/10/17(木) 09:25:56.10

>>583
NoBlend

**名前は開発中のものです。** · 2013/10/17(木) 10:41:25.53

なめとんか

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

>>584
DxLib関係ないと思うが
システムごと死ぬのは十中八九デバイスドライバが悪い
64bitなら32bit用のドライバで動いてる奴が悪さしてるとかひょっとしたらあるかも

**名前は開発中のものです。** · 2013/10/17(木) 15:23:43.00

Noblendだと透過色って機能せんの？
ドウイウコトナノ・・・

**名前は開発中のものです。** · 2013/10/17(木) 16:06:04.12

透過ｼﾅｲ画像表示関数ｯﾃ存在価値ｱﾙﾉ？
画像全体に透過処理するんならモード変えろ

**名前は開発中のものです。** · 2013/10/17(木) 16:14:55.88

数レス前も読んでなかったすまん…
諦めて最初から透過しとけば？

**名前は開発中のものです。** · 2013/10/17(木) 16:57:54.53

いろいろ試してみたけど透過色はBMPとJpg読み込みのときだけ機能して
他のスクリーンやスクリーンをGetDrawScreenGraphでMakeGraphでつくったハンドルに移しても機能せず
アルファ付き画像でアルファ指定してやらんと透過せんのね
微妙すぎぃ

**名前は開発中のものです。** · 2013/10/17(木) 17:05:56.17

GDIのフォーマット(pixel辺りのビット数)についてちゃんと理解した上で扱ってれば特に問題無い気もする

**名前は開発中のものです。** · 2013/10/17(木) 17:27:20.11

面倒だけどマスク画像作って一回ブリーチングしてから描画することにしたわ
サンクス

**584** · 2013/10/18(金) 02:10:22.43

>>588
DxLib使わなければ固まらなかったんでそこばっかり調べてたのですが、
なるほどと、いろんなものアップデートかけたけど状況変わらずでした。

解決ってわけじゃないけどBCCに移行したら
一時間くらい作業してみてるけど再発せず。
VSが悪かったってことなんだろうか？

ただ、すげー使いにくい。

**名前は開発中のものです。** · 2013/10/18(金) 16:05:43.20

最小限のプログラムでも発生するなら、そうかもねー。
設定変えればいけるかもしれんけど

**名前は開発中のものです。** · 2013/10/18(金) 18:23:23.35

え、DXライブラリって、
64bitか32bitかで支障あるん？
64bit用なんてありましたっけ？

**名前は開発中のものです。** · 2013/10/18(金) 21:10:30.89

VSのExpress版使ってると64bitビルド出来ないから32bit版しか知らない

**584** · 2013/10/19(土) 00:04:03.03

>>595
自己レス。
おそらく本当に解決したので一応ご報告。

BCCでも固まりました。
というか、デバッガで固まったのでそこを重点的にぐぐったら、
同様の症状でDRM関連のCYMON.SYSを消したら直ったというページを発見出来たので、
削除したらおそらく今度こそ本当にたぶん解決。
同様の事案で悩んでる人たちに伝えたい。

＞64bit云々は同様の件で困ってる人がほとんど64bitのOSだったので怪しんだだけです。
結果的に関係なかった。
DxLibも関係なかった。

**名前は開発中のものです。** · 2013/10/19(土) 00:05:41.25

乙　結構有益な情報だわ

**名前は開発中のものです。** · 2013/10/19(土) 01:03:15.68

サイモンシスって読めばいいの？

**名前は開発中のものです。** · 2013/10/19(土) 01:16:15.10

Are you going to Scarborough Fair?

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

初心者です
よくリファレンスでFPS固定させるコードとかあるけどSetWaitVSyncFlag()で垂直同期するんじゃだめなんですか？
あとFPSによってゲームスピードが変わる云々という記述を見ますが、何故フレームで計算するんです？
私はGetNowCount()で計算しているんですが、何かまずい事でもあるのでしょうか

**名前は開発中のものです。** · 2013/10/21(月) 18:47:51.14

＞SetWaitVSyncFlag()で垂直同期するんじゃだめなんですか？
ダメ。垂直同期がない環境もある

＞何故フレームで計算するんです？
時間に応じて可変フレームに対応するゲームを作るのは大変だから

＞私はGetNowCount()で計算しているんですが、何かまずい事でもあるのでしょうか
パーフェクトに組めるなら問題ないけど、初心者には無理だと思う

あとです？で止めずにちゃんとですか？って書けよﾃﾞｺｽｹ

**名前は開発中のものです。** · 2013/10/21(月) 18:58:35.56

>>604
>時間に応じて可変フレームに対応するゲームを作るのは大変だから
何故ですか？可変フレームなら尚更フレームで計算より時間で計算した方が良いと思うのですが
あ、この場合の計算って言うのは例えば○秒で画像Aをy軸に+1するみたいな計算です

**名前は開発中のものです。** · 2013/10/21(月) 19:03:06.05

>>605
フレーム固定処理ってのは○秒の部分を16.6666...ミリ秒に固定してるだけだぞ
一定時間毎に処理するならフレーム処理と変わらない

**名前は開発中のものです。** · 2013/10/21(月) 19:06:38.76

回せるだけ回したらマシンパワーの無駄食いだから

**名前は開発中のものです。** · 2013/10/21(月) 19:07:14.69

たぶん質問の書き方がおかしくて話が伝わってない

FPS固定よりも可変フレームレートの方が良い
開発が少し面倒くさい程度で、デメリットがない

垂直同期はテアリングが起きないのが最大の利点
ただしフレーム数がモニターに依存するようになるから
結局可変フレームレートに対応するようなプログラムを書く必要があって面倒くさい

だから最も初心者向けサイトは基本的に
作りやすい60FPS固定にしてフレーム基準で計算するようにしてる
しかもデメリットは垂直同期しないために起こるテアリングくらいしかない

**名前は開発中のものです。** · 2013/10/21(月) 19:15:43.93

そもそもフレームってそんなに重要なもの何ですか？
DXライブラリ使っててフレームレートを意識した事が全くなくて、リファレンスなどを見て何故そこまでしなければいけないのかと困惑している次第で

**名前は開発中のものです。** · 2013/10/21(月) 19:17:01.12

フレーム数を時間代わりにすると環境によってはカクカクになります？

**名前は開発中のものです。** · 2013/10/21(月) 19:20:20.12

可変フレームレートって、ネトゲでもなきゃCPUが貧弱だった頃の名残じゃないのか？
処理落ちするとしたらほぼ確実に描画が原因な今の時代だと、固定フレーム＋フレームスキップがベターだと思う

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

フレームスキップじゃないな
固定フレーム＋描画スキップな

世の中のゲームの大半が60フレーム固定なのにはちゃんと理由があるわけで

・60フレーム以上のフレームレートにしても、人間が見るぶんには特に滑らかだと感じない
・CPUが成長したので処理で60フレームでないゲームなんてありえない

作るのが動的なゲームである限り、固定フレームを捨てるメリットはないというのが俺の持論

**名前は開発中のものです。** · 2013/10/21(月) 19:42:40.65

60フレーム出ないゲームなんてありえないって言い方はおかしいが、
とりあえず言いたい事はわかる

**名前は開発中のものです。** · 2013/10/21(月) 19:48:43.62

６０フレームを確保しているのは、ゲーム機の格闘ゲームくらいです。
ゲーム機で他のジャンルは　ほとんどが３０フレーム

パソコンの場合は、強力なＰＣもあれば、非力なＰＣもあるので
色々な手段を使って、最低限のフレームレートを確保しようとする。
また、負荷変動が多々にあるので、それに対処する必要も或る。

**名前は開発中のものです。** · 2013/10/21(月) 19:52:47.30

たいして難しくないんだからFPSと垂直同期くらい設定可能にしておけよｗ

**名前は開発中のものです。** · 2013/10/21(月) 19:53:04.57

>>609
何を質問したいのかがよくわからない
可変フレームレート（時間単位での処理）でできてるならそれで大丈夫だよ

>>612
60フレームと120フレームでは明らかに違うから見た瞬間にわかるよ
120と240は俺自身は比べたことがないけど恐らくそれも感じ取れるだろう
実際に今のテレビのほとんどが240フレーム表示を採用してるからね

2万のネットブックとかで動かすユーザーなんかが絶対にいるから
ゲーム用PCで1000fpsくらい出せるようなゲームでも、20fpsとかになることはざらにある

**名前は開発中のものです。** · 2013/10/21(月) 19:55:43.22

正直60でない化石の配慮なんて無駄
広大な3Dマップを切り替えなしのリアルタイムで読み込むタイプならあって損はないかもね
60より必要あるのはレート120やら144やら使う格ゲーFPSガチ勢くらい
それ以外のジャンルなら頭動かすだけ無駄
やりたければ勝手にどうぞの世界

**名前は開発中のものです。** · 2013/10/21(月) 20:04:47.68

これでも十分勉強になるのですが
私が言いたかったことは
例えばここの
http://dixq.net/g/03_02.html

while( ScreenFlip()==0 && ProcessMessage()==0 && ClearDrawScreen()==0 && gpUpdateKey()==0 ){

DrawGraph( 0, Count% 50, Handle, TRUE ); // 周期 50カウントでループ表示する
DrawGraph( 100, Count%100, Handle, TRUE ); // 周期 100カウントでループ表示する
DrawGraph( 200, Count%150, Handle, TRUE ); // 周期 150カウントでループ表示する

Count++; // カウンタ加算

}

こんな処理をしたとして「PCスペックによって時間が変わっちゃうからFPS固定しよう」とか言ってるなら最初から時間測れば良いのでは？
と思ったって事です

**名前は開発中のものです。** · 2013/10/21(月) 20:08:41.83

初心者はやっぱり明後日の方向で悩んでるから怖いな
そんな単純なもんじゃないから、フレーム固定で作っておけ

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

パソコンの負荷は一定では無く、不規則に変動するのですよ。
それが、個別に全部が違う挙動をする。

**名前は開発中のものです。** · 2013/10/21(月) 20:14:02.72

すいませんスペックじゃなくてリフレッシュレートです
↓
http://dixq.net/g/03_14.html

**名前は開発中のものです。** · 2013/10/21(月) 20:19:16.36

リフレッシュレートは60や120だけじゃなくて50や75や72や85もあるんだぞ
ズレるわ

**名前は開発中のものです。** · 2013/10/21(月) 20:23:20.98

>>618
そのサイトは初心者向けだから可変フレームレートは難しい
また、その章までに書いたプログラムすべてを変更する必要がでるから避けてるんだよ

>>608にも書いたけど時間を計って可変フレームレートにするのは良いことだよ
一応処理落ちについての話題が出たから例として触れておくと、
極端な処理落ちが発生したときに可変フレームレートだと衝突判定のすり抜けが起こることが
予期されるからそれを防止するためのメカニズムを考えないといけなかったりとか
とにかくプログラム書くのがFPS固定に比べて面倒くさい

**名前は開発中のものです。** · 2013/10/21(月) 20:27:42.27

ＦＦ３のエンカウント時エフェクトみたいな
1フレーム毎に画面が白黒⇔カラーを繰り返すみたいなエフェクトを実装するとき
可変フレームレートだと白黒のままになったりカラーのままになったりで
おかしな表示になるんじゃないんですか

**名前は開発中のものです。** · 2013/10/21(月) 20:27:43.27

面倒くさいどころか逆に負荷が増す場合もあるぞ
カーブとか重力を考慮した移動とか複雑な移動処理をするなら

完全な再現性を実現できない限りは可変フレームレートなんて採用すべきじゃないと思うな
ネトゲやFPSだって、発生した事実関係だけをサーバに送信して無理矢理辻褄合わせてるだけだし

**名前は開発中のものです。** · 2013/10/21(月) 20:30:11.95

FPS60に固定する
↓
予め1フレーム過ぎる毎にint countを+1しておく
↓
あるアクションから一秒たったら画像を表示させたいから
アクションおこした時にint a = countする
↓
count - a > 60の時に画像を表示

みたいな説明があって
countの代わりにGetNowCount()を使えばfps固定する必要なんてないと思ったと言おうとしました
説明下手でごめんなさい

>>623-625
なるほど
まだそんなレベルに達していなかったので面倒くさいとも思いませんでした
ありがとうございました

**名前は開発中のものです。** · 2013/10/22(火) 00:35:28.42

>>625-626
微分方程式を解ける秀才がこのスレに降臨したかと期待したが、ただの初心者だった

**名前は開発中のものです。** · 2013/10/22(火) 03:54:29.71

>>626
ああ、それは勘違いしそうになるな。説明が不適切とまでは言わないが。

1秒後（あるいは60フレーム後）に画像を表示する、くらいなら正直どっちでもいいと思うけど、
秒速120ドットで移動するとかだと少し面倒になるって感じかねぇ。分母が変わっちゃうから。

**名前は開発中のものです。** · 2013/10/22(火) 04:28:57.73

固定/可変フレームレートの問題というよりも、>626の場合は、
ゲーム内時間をフレーム基準で考えるか、実時間ベースにするかって問題だよね。

フレーム基準というのは、つまりゲーム内時間をプログラマが管理できる状態と言い換えられる。
それに対して、実時間を基準に処理を行うというのは、ゲーム内時間にプログラマがアクセス出来ない状態と言える。

この差は結構重要で、プログラミングをする際に1つの処理を細かく積み上げて考えたい時や、
あるいはテストプレイやデバッグの際に、ゲームスピードをゆっくりにして動作を見極めたいという時に、
実時間ベースだと不便そうだなあというのは、何となく分かってくれるんじゃないかと思う。

もちろん実時間ベースが優れてるところもあるので、決して間違いではないのだけれど。

**名前は開発中のものです。** · 2013/10/22(火) 06:42:35.27

dxライブラリのfps制御そのまま使ってるけどよくない？
1秒を60フレームって前提でゲーム内のタイマー作っちまってるわ

**名前は開発中のものです。** · 2013/10/22(火) 06:52:51.98

オンラインランキングとかしないなら、そんなに困らないと思う

**名前は開発中のものです。** · 2013/10/22(火) 07:32:13.52

可変フレームで気になってたんだけど
環境によってfps変わってたらリプレイの再現できなくない？

**名前は開発中のものです。** · 2013/10/22(火) 08:42:21.30

処理のループはfpsに制限されないでしょ
動きが荒くなるだけじゃない？

**名前は開発中のものです。** · 2013/10/22(火) 08:54:17.54

マリオカートのゴーストとかどう記録してるんだろ
と思ったけど処理したときついでに時間記録すれば普通にできるか

**名前は開発中のものです。** · 2013/10/22(火) 09:32:38.97

やってみそｗ

**名前は開発中のものです。** · 2013/10/22(火) 09:45:09.67

ゴーストとかリプレイを実装しようとして、「なぜずれるんだー」と頭を悩ますのはお約束だよな？　な？

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

処理時間≠入力時間に気をつけて処理させれば固定と同じようにやればいいだけ
ずれ誤差怖いから実体の位置を入力時間ごとに別で取っておいてそこから計算させた方がいいかも？
使う処理が1つで済む&信頼度高いけど情報量が膨れそう
とか妄想したけどジャンル的にリアルタイムリプレイなんて一生実装しないだろうな

**名前は開発中のものです。** · 2013/10/22(火) 12:36:20.41

低レベルな話ほど長く続くね

**名前は開発中のものです。** · 2013/10/22(火) 12:47:39.37

そりゃ母数が違うからな

**名前は開発中のものです。** · 2013/10/22(火) 15:20:36.48

確かにゲームプログラム全体の中では低レベル寄りな方だよな。vsyncとか。

**名前は開発中のものです。** · 2013/10/22(火) 15:31:37.39

自転車置き場の議論なら誰でも参加できるからな
俺のように高レベルな人間になると議論する相手を探すのも苦労する

**名前は開発中のものです。** · 2013/10/22(火) 15:55:43.08

バカばっか

**名前は開発中のものです。** · 2013/10/22(火) 16:25:11.43

>>641

多分ツッコミ待ちなんだろうけど、どこへツッコめばいいのかわからんｗ

**名前は開発中のものです。** · 2013/10/22(火) 16:30:05.22

冗談にマジレスはあかんでー

**名前は開発中のものです。** · 2013/10/22(火) 18:58:55.59

自作中のゲームがウィンドウモードと比べて全画面モードの処理速度がどうしても遅いのですが
他のdxlibを使ったゲームはウィンドウの方が不安定だったりするのになぜでしょうか…

2D表示機能のみで、主な設定関数は
SetGraphMode(800,600,16)
SetDrawScreen(裏画面)
SetDrawMode(バイリニア)//ゲーム中変更なし

処理としては、描画に加算・減算切り替えが多め、背景の計算がやや複雑といった感じです

全画面モード中はこの処理が重い、といったことはあるのでしょうか？

**名前は開発中のものです。** · 2013/10/22(火) 20:35:42.51

リリースで測った？

**名前は開発中のものです。** · 2013/10/22(火) 22:01:05.96

特定のビデオカード（や設定）と相性が悪いとか、
解像度を変えるのではなくウィンドウサイズを上げてるとか…… うーん、わからん

**名前は開発中のものです。** · 2013/10/22(火) 22:30:32.24

過去の記憶ではリリースビルドでも遅くなっていました(計測はしていなく今リリースビルドしたらデバックビルドでは出ないエラーが出て改善できず、計測できませんでした)
音楽に合わせた演出がゲーム最初にあるのですが確実にずれていました

デバックビルドで計測しましたが、ウィンドウだと13ms、全画面だと17msでした
screenflipで差が出るようです

**名前は開発中のものです。** · 2013/10/22(火) 22:31:54.83

17のほうが正常だそれ

**649** · 2013/10/22(火) 22:34:58.08

正常、って言うと語弊があるな。訂正。
たぶん、モニタ＆グラボのリフレッシュレートが75Hz（≒13ms）になってるんじゃないか？
で、フルスクリーンにするときに、プログラム側で60Hz（≒17ms）に設定しているんだと思う

**名前は開発中のものです。** · 2013/10/22(火) 23:04:05.07

おお、モニタの情報をみたら75Hzでした
では全画面モードが遅いのではなくウィンドウモードが若干早送りされてるということですか！
これを抑えて調整し直します。ありがとうございました！

**名前は開発中のものです。** · 2013/10/22(火) 23:07:27.52

まさにタイムリー

**名前は開発中のものです。** · 2013/10/22(火) 23:29:28.48

てか、普通ゲーム作るならFPSぐらい表示させないか
常にCPU負荷とFPSぐらいは見れるようにしとかないと・・・

**名前は開発中のものです。** · 2013/10/23(水) 01:24:23.81

FPS固定でウィンドウモードに対応させたい時、タイマーで制御すれば良いんだよね？
手元に60Hz以外に対応してるモニタが無いから、ホントにそれで合ってるのか分からん。

>>653
CPU負荷は表示させたこと無いなあ。Win32APIあたりから拾ってくるのん？

**名前は開発中のものです。** · 2013/10/23(水) 02:00:20.55

垂直同期するなら経過時間で処理する
垂直同期しないならWaitTimerが都合よく動くことを祈る

**名前は開発中のものです。** · 2013/10/23(水) 03:47:45.96

>>654
単純にwait処理以外の時間を1秒間ms単位で足して1000で割る
で良いんじゃね

垂直同期待ちしてる場合はScreenFlipもwait処理として考える

**名前は開発中のものです。** · 2013/10/23(水) 17:08:21.68

ああすまん、タイマーによるフレーム制御自体は既に実装済み（vsyncと切り替え可能）ではあるんだ。
ただ、手元に60Hz以外の環境で確認するすべがないのと、
もしかすると、もうちょっとスマートな方法があるのかな？と、ちょっと気になっただけなんだ。

まあ、タイマー制御もvsync待ちも切ると500FPSとかで動いたりするから、大丈夫だろうとは思うんだけどさ。
デフォルトはタイマー制御にしておいて、コンフィグ画面なり起動時のダイアログなりで変えれるようにするのがベストかな？

**名前は開発中のものです。** · 2013/10/23(水) 17:14:46.11

vsyncかタイマーか、設定できるようになってればどのみち問題はないだろう

**名前は開発中のものです。** · 2013/10/23(水) 20:42:08.44

描画処理は別スレッドにしてvsync固定

**名前は開発中のものです。** · 2013/10/25(金) 11:35:42.34

んー？よくわかんないんだけど
例えばモニタが60fpsだったら、描画スレッドを60fps(vsync?)にして、
処理スレッドと描画スレッドはどうやって同期するんだ？

処理スレッドが座標いじってる時に描画スレッドが座標見るのはダメなんだよな？
まぁ早々ブッキングはしないだろうけど何万回転とかしたら・・・

**名前は開発中のものです。** · 2013/10/25(金) 16:06:37.29

>>660
それは一旦fpsとかその他の言葉を忘れて、マルチスレッドでの同期処理を書いて理解した方がいい。

てか、ドライバ書いてる訳でも無いのに垂直帰線期間の話が出て来る事自体が、あんまりリアルじゃない。
30年前の8bitマシンならともかく、今のマシンでアプリレイヤの話ならばちょっと変だ。

垂直帰線期間の考慮が必要になるのは、例えばDirectXやOpenGLそのものがその中で行っている最後のラスタ情報のVRAMへの転送処理の中の話であって、
普通は(アプリケーションプログラマは)メインループの経過時間差を見てfpsをコントロールする。
具体的には一定経過時間未満の場合に処理をスキップさせる。

もしもこの周辺処理をマルチスレッドで実装したい場合に、意図的な同期処理が必要になるが、そういった場合にマルチスレッドでの流儀で実装する。

そうでないなら単にメインループの中で、普通に処理するだけ。
こういった話はより具体的にしないと、ただの曖昧な聞きかじりみたいな話で終わってしまい、全然役に立たない。
経験から引き出して実例として話さないとダメ。

**名前は開発中のものです。** · 2013/10/25(金) 16:51:42.23

>>660の質問に答えるのにその長文はいらんだろｗ

**名前は開発中のものです。** · 2013/10/25(金) 17:31:09.74

本人が必要性感じてない段階でわざわざマルチスレッドとか要らんよ

**名前は開発中のものです。** · 2013/10/25(金) 21:13:51.48

じゃあここにいる人たちはみんな組み込み系の専用モニタ使ってドライバからゲーム作ってる人たちなの？

**名前は開発中のものです。** · 2013/10/25(金) 21:16:54.66

ﾄﾞﾕｺﾄｰ

**名前は開発中のものです。** · 2013/10/25(金) 21:32:50.74

極端過ぎる

**名前は開発中のものです。** · 2013/10/25(金) 21:59:31.35

なんでいきなりそういう話になったの？
誤爆か？

**名前は開発中のものです。** · 2013/10/25(金) 22:47:27.21

そうだよ（適当）

DXライブラリ 総合スレッド その16

DXライブラリ総合スレッドその16