DXライブラリ総合スレッド 2008

**名前は開発中のものです。** · 2008/10/25(土) 17:37:53

Cを習得した程度のスキルでも、
GUIのゲームを比較的容易に作成する事を可能にする、
「DXライブラリ」に関するスレッドです。

DXライブラリの詳細ついては
http://homepage2.nifty.com/natupaji/DxLib/
を参照して頂きたい。

DXライブラリに関するテクニックなどの情報交換などを行う事で、
多くのDXライブラリユーザのスキルの向上に役立てたら幸いです。

過去スレ：DXライブラリ総合スレッド
　　　　　　http://pc11.2ch.net/test/read.cgi/gamedev/1197468399/

**名前は開発中のものです。** · 2008/10/25(土) 18:16:32

やったー新スレだ

**名前は開発中のものです。** · 2008/10/25(土) 18:23:00

あれ？タイトル名普通は「DXライブラリ総合スレッド　その2」みたいにするんじゃないの？まあいいか。スレ立て乙

**名前は開発中のものです。** · 2008/10/25(土) 20:53:06

やっと規制解除された！
>1乙

**名前は開発中のものです。** · 2008/10/25(土) 21:50:29

もうすぐ３００９年になるのにこのスレそれまでに埋まるんだろうか・・

**名前は開発中のものです。** · 2008/10/25(土) 21:51:12

あ、ごめん２００９９ねんだｘちゅｔ

**名前は開発中のものです。** · 2008/10/25(土) 21:54:26

ちょ・・ごめんなさい。途中で送信してしまいました。昭和２００９年の間違いです。

**名前は開発中のものです。** · 2008/10/25(土) 22:16:04

　　　　　　　　　　　　　　　　　　　　　　　　 , ヘ　　　　　　　　　　／＼　
　　　　　　　　　　　　　　　　　　／´￣｀ヽ／: : : ＼＿＿＿＿＿／: : : : ヽ、
　　　　　　　　　　　　　　,.　-‐┴─‐- ＜＾ヽ、: : : : : : : : : : : : : : : : : : : : : : }
　　　　　　　　　　／: : : : : : : : : : : : : :｀.ヽl____: : : : : : : : : : : : : : : : : : ／
　　　　　,.　-──「｀: : : : : : : : :　:ヽ: : : : : : : : :＼｀ヽ￣￣￣フ: : : : :／
　　　／: :.,.-ｧ: : : |: : : : : : : : :　　　 :＼: : : : :: : : :ヽ　＼　／: : : :／
　　　￣￣／: : : : ヽ: : : . . . . . . . . . . .､＼=--: : : :.i　／　/: : : : :/
　　　　／: : 　　　 ∧: ＼: : : : : : : : : : ヽ: :＼: : : 〃}/　　/: : : : :/　　　　　　　　、
.　　　 /: : /　　. : : :! ヽ: : l＼_＼／: : : : :＼: ヽ彡: : |　　/: : : : :/　　　　　　　 |＼
　　　/: : ｨ: : : : :.i: : | 　＼!___／ヽ:: : : : : : :＼|:.:.:.:/:!　 ,': : : : /　　　　　　　 |: : ＼
　　 / ／ !: : : : :.ト‐|-　　ヽ　　　　＼: : : : : l::::__:' :/　 i: : : : :{　　　　　　　　 |: : : :.ヽ
　　 l/ 　 |: : :!: : .ｌ: :|　　　　　　　　　＼: : : l´r. Y　　 {: : : : :丶＿＿＿＿＿__.ノ: : : : : :}
　　　　　 l: : :ｌ: : :ﾄ､|　　　　　　､＿__,ィヽ: :| ゝﾉ　　 '.: : : : : : : : : : : : : : : : : : : : : : ／
　　　　　 |: : :ﾄ､: |: :ヽ ___,彡　　 ´￣´　　ヽl-‐'　　　　＼: : : : : : : : : : : : : : : : : : イ
　　　　 !: :从ヽ!ヽ.ﾊ=≠'　, /////　///u /　　　　　　　　￣￣￣￣￣￣￣￣
　　　　　　V　ヽ|　　 }///　 r‐'⌒ヽ　　イ〉、
　　　　　　　　　　　　ヽ､______ｰ‐‐' ィ´　/:/:7rt‐---､　　　　　　　こ、これは>>1乙じゃなくて
　　　　　　　　　　　　　　　　　　ィ幵ﾉ　./:/:./:.! !: : : : :!｀ヽ　　　　　ポニーテールなんだから
　　　　　　　　　　　　　　r‐'T¨「 |: | !:.∨:/:./: :| |: : : : .l: : : :＼　　　変な勘違いしないでよね！
　　　　　　　　　　　　 /: : .|: :|　!:.!ィ¨¨ヾ、:.:/　!: : : : l: : : : : :.＼

**名前は開発中のものです。** · 2008/10/25(土) 22:27:37

ああ、規制でおれも立てられなかったんだよ、>>1乙。
一応3D版も奴も張っちゃえ

http://fatalita.sakura.ne.jp/3DLib/

**名前は開発中のものです。** · 2008/10/25(土) 22:29:25

個人的な意見を言えば、次スレからは前スレで結構話題になった、
DXライブラリ3DのURLもテンプレに入れた方が良いと思う。
私は結構期待しているし、私以外にも注目している人は多いはず。

というわけで自分なりにテンプレ入れてみる。

また、DXライブラリと互換性を持ったライブラリ、
「DXライブラリ3D」が開発も非公式ながらも行われている。
DXライブラリ3Dを用いることにより、DXライブラリの機能に加え、
3Dの処理を容易に行えることが期待できる。
http://fatalita.sakura.ne.jp/3DLib/

10 · 2008/10/25(土) 22:30:40

>>9
かぶった。
スマソ。

**名前は開発中のものです。** · 2008/10/25(土) 23:34:54

>>9-10
FireFox3なんだけどそのリンク先、マウスにDxMainの透明ソースがくっついてはがれなくてクリックできない。

あ、実はDirectXについて調べててたまたま来ただけなんですが、ちょうど埋まってたので立ててみました。
DXライブラリの歴史は古いっぽいからスレタイの番号抜けちゃったのかなと年を入れて見たんですが、
次スレは2009年になりそうだしかまわないかなと。

僕がやりたかったのはDirectX使うゲームの画面をDirectXで静止画キャプチャなんですが、
DirectXでキャプチャするというHyperSnapでキャプチャしても画面が一瞬ロックしちゃうんであきらめました。
いろんなところにもBitBltより遅くなるって書いてあったし。
どんなゲームでもロックするとは限らないけど、ネトゲのセキュリティ機能が影響してるかもしれない。
廃スペックな人からは「そんなロックかからないよ」って言われたし、スペックでカバーできるっぽいし。

こういったライブラリは自前窓への描画や画面への出力前提だろうから、方向性もちょっと違いましたね。

**名前は開発中のものです。** · 2008/10/25(土) 23:54:35

たまたま来てスレ立てとな！

**名前は開発中のものです。** · 2008/10/25(土) 23:56:47

シルバーガンとかレイストームみたいな奴を手っ取り早く作りたい！
……って時には結構強いよね、3D版。

ポリゴンモデルを用意できるかどうかは別として。

**名前は開発中のものです。** · 2008/10/27(月) 14:23:21

>>12
クリックできないとは？
うちもFirefox3だけど問題ないが

**名前は開発中のものです。** · 2008/10/27(月) 15:24:06

DXライブラリの参考になるサイトも一通りテンプレにいれたらいいのに

**名前は開発中のものです。** · 2008/10/27(月) 22:20:31

ＤＸライブラリで、超単純な当たり判定ってどんなのがある？

画像が重なった瞬間消すだけでもいいんだけど、どうすればいいかよくわからん

**名前は開発中のものです。** · 2008/10/27(月) 22:24:13

DXライブラリで、ってのがよく分からんが、ごく普通の当たり判定じゃダメなのか。
最も単純って言うと、

　if ( x1 == x2 && y1 == y2 )

とか？

**名前は開発中のものです。** · 2008/10/27(月) 22:48:15

矩形の当たり判定が基本でしょ

**名前は開発中のものです。** · 2008/10/27(月) 23:21:07

円の当たり判定が一番簡単じゃない？
普通にピタゴラスの定理使えばいいだけ

18 · 2008/10/27(月) 23:28:42

ぶっちゃけどれも基本だよな。

**名前は開発中のものです。** · 2008/10/27(月) 23:42:59

円の当たり判定はベクトル使うと異常に綺麗に書けるよね

**名前は開発中のものです。** · 2008/10/27(月) 23:52:30

>>22
ピタゴラスの定理より簡単になるの？

**名前は開発中のものです。** · 2008/10/28(火) 09:43:23

通過しちゃったやつも当たったと判定しなきゃならんこともあるし

**名前は開発中のものです。** · 2008/10/28(火) 10:06:09

ベクトル使うと当たり判定が菱形にならないか？

**名前は開発中のものです。** · 2008/10/28(火) 11:15:02

>>24
あるあるｗ　処理時間の関係でどうしてもなるよな。あれが厄介

**名前は開発中のものです。** · 2008/10/28(火) 19:25:08

http://www.nicovideo.jp/watch/sm5018275
DXライブラリ３Dの動画発見した

**名前は開発中のものです。** · 2008/10/28(火) 21:25:44

ニコニコでDXライブラリで検索したら16件ほど出てくるのね

**名前は開発中のものです。** · 2008/10/29(水) 04:50:01

>>26
あれは線と線の交差を計算するだけ

**名前は開発中のものです。** · 2008/10/29(水) 04:51:17

>>29 kwsk

**名前は開発中のものです。** · 2008/10/29(水) 05:21:45

>>30
移動前と後の座標間を結ぶ線を引く。線を引くといっても直進なら２つの座標が直線を表す式になる。
直線１本を座標変換によってX軸と一致すると仮定する。
検査対象のオブジェクトのY座標が全てプラスまたは全てマイナスなら交差していない。

検査対象が１本の直線だとしよう。
直線は２つの座標で表されるので、その座標がプラスとマイナス座標の組み合わせなら交差していることになる。
数学では交点を求めるが、交差のみ検査するなら、Y座標だけ調べればいい。
二つの座標を(x1,y1)と(x2,y2)として、y１×y2がプラスなら交差なし、マイナスなら交差ありになる。
ポリゴンは線の集合なので、ポリゴンを構成する全ての直線についてこの計算をするもよし、
正の座標と負の座標それぞれの数を数えるもよし。

座標変換については高校数学で習うけど、ゆとり教育の今は大学まで進まないと習わないだろうね。
コンピューターグラフィックとかシミュレーションやるなら絶対必要な数学なんだけど、
大学生になってから学び始めても理解できるわけがない。
ようするに日本人は優秀なプログラマにはなれない。

**名前は開発中のものです。** · 2008/10/29(水) 08:48:56

論理飛躍しすぎだろｊｋ

**名前は開発中のものです。** · 2008/10/29(水) 15:25:49

>>31
>Y座標だけ調べればいい。

という意味がわからん・・。
ｘ軸と一致するように回転した線分の定義域x0の範囲を
x01< x0 <x02
としたら、この範囲の中でyの掛け算結果がマイナスになれば交差とわかるけど。
もし交点がこのx0の範囲じゃないところで交差していたらどうするの？
直線と直線の交差ならこれでいけるけど、
使いたいときってほとんど線分と線分じゃない？

**名前は開発中のものです。** · 2008/10/29(水) 15:36:57

>>33
横レスすみません。直線と線分って定義上違うんですか？
直線と長方形という意味でしょうか？

**名前は開発中のものです。** · 2008/10/29(水) 15:41:55

>>34
直線の長さは無限大。(線分には端が存在するが、直線には端が存在しない)
だから、二本の直線は必ず交差する

注１並行である場合を除く
注２ 2Dの場合に限定

**名前は開発中のものです。** · 2008/10/29(水) 15:45:07

>>35
詳しい説明ありがとうございました。なるほどそういう違いがあるんですね。

**名前は開発中のものです。** · 2008/10/31(金) 03:09:52

結局>>31の方法で線分の交差は判定できるの？

31 · 2008/10/31(金) 06:44:39

直線と言ってしまったのは悪かった。
まあ確かに>>33の言うとおり、x座標の範囲も見ないと実際は分からないけど、
直線とみなさないとy座標だけでは上にあるとも下にあるとも言えないから。

両方を直線とみなせば並行じゃない場合必ず交差する。
でも、平行じゃない直線が取るx座標、y座標は無限となるでしょ。
y座標のみ見るというのは、点として見ているから交差しない。
僕が言いたかったのは、基本的には数学の計算を利用するけど、交点まで求める必要はないということ。

計算手順としては、座標変換後、それぞれのx座標のみについて基準の線分の範囲内にあるかどうかを見て、
次に>>31で説明したようにy座標のみを見れば大体判断できる。
x座標が範囲の内と外をまたぐ線はあいまいだけど、
基準線の交差する側の端点を基準にしてx成分とy成分の比率を見れば交差するかどうかが分かる。

ちなみにこの計算方法はキャノンが特許申請してるが
常識なので却下するべき。
http://www.j-tokkyo.com/2003/G06T/JP2003-085568.shtml

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

こんなのが特許なら俺のソースは特許５００個くらいあるな。

**名前は開発中のものです。** · 2008/10/31(金) 07:37:16

>>31
あんた詳しいな。いろいろと。差し支えなければ職業とか聞きたい。

**名前は開発中のものです。** · 2008/10/31(金) 20:29:02

この休みはゲーム作るか……

**名前は開発中のものです。** · 2008/11/01(土) 15:44:46

ポリゴンもそうだが球の当たり判定でいくのが一番簡単
中心と半径だけで計算できる。

**名前は開発中のものです。** · 2008/11/02(日) 08:06:57

何気なく質問した当たり判定だけどピンキリだって事だな

**名前は開発中のものです。** · 2008/11/02(日) 11:25:09

で、DXライブラリに当たり判定してくれる関数はないの？

**名前は開発中のものです。** · 2008/11/02(日) 12:31:49

3D版にはあるね。
本家の隠し関数の中にあるかどうかまでは知らない。

**名前は開発中のものです。** · 2008/11/02(日) 15:48:59

>44
DXライブラリって、そういう系統の関数は用意しないという設計思想のよーな。

**名前は開発中のものです。** · 2008/11/02(日) 19:05:58

DXライブラリの２Ｄの方は２Ｄだし別に衝突判定とか用意しなくていいと思う。
初心者なら四角か球同士の判定を自分で実装することの勉強にもなるし２Ｄは
高校の数学程度で十分自力で実装可能。
３Ｄならそれだけで分厚い本があったり研究者がいたりするくらいだから面倒だけど。

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

3DでもAABBや球の辺り判定なら2Dと変わらないよ
2Dでも面倒なことするなら面倒

**名前は開発中のものです。** · 2008/11/07(金) 09:51:29

3DのＡＡＢＢは、スキンメッシュだと非常に面倒

**名前は開発中のものです。** · 2008/11/07(金) 17:21:25

あー、ブロッコリー食いたくなってきた。スレチガイかもしれませんがあれってどうやって食べるの？

**名前は開発中のものです。** · 2008/11/07(金) 17:24:04

すみません。板間違えてました。野菜板で聞いてみますﾉｼ

**名前は開発中のものです。** · 2008/11/07(金) 17:32:26

ちょｗｗｗ

**名前は開発中のものです。** · 2008/11/08(土) 04:58:31

ＤＸライブラリのスレは勘違いでいいから賑わって欲しい・・ｗ

**名前は開発中のものです。** · 2008/11/08(土) 14:28:00

WMPの視覚エフェクトをまねたいんだけど
リアルタイムの画像処理はDXライブラリじゃ難しい？

**名前は開発中のものです。** · 2008/11/08(土) 14:45:42

>>54
DXライブラリを詳しくわからないのだけど、
DXライブラリってテクスチャつかえますよね？
レンダリングターゲットをテクスチャに設定して
そこに視覚エフェクトを描画。
それを、通常レンダリングターゲットにもどして
そのテクスチャを描画してみては？
視覚エフェクトのアルゴリズムがわかれば可能だと思います。

**名前は開発中のものです。** · 2008/11/08(土) 15:49:01

特定のキー以外を取得したいのですが、
例えばエンターキー以外が押されている場合を取得するのはどうやればいいのでしょうか？

if (CheckHitKey(KEY_INPUT_0) == 1)
{
flgOn = true;
}
if (CheckHitKey(KEY_INPUT_1) == 1)
{
flgOn = true;
}
if (CheckHitKey(KEY_INPUT_2) == 1)
{
flgOn = true;
}
....
if (CheckHitKey(KEY_INPUT_RETURN ) == 1)
{
flgOn = false;
}
のようにして、一つずつどのキーが押されているかを判定して、
その押されたくないキーの時だけフラグをONにしないと言う方法を考えたのですが、
大量に判定（２５５個？）しないといけません。
それに書く量も多いです。
何か良い方法はないでしょうか？

**名前は開発中のものです。** · 2008/11/08(土) 16:18:22

>56
普通に考えればそうなるんじゃないかなあ。
タイピングを必要とするソフトなんだろうか。

**名前は開発中のものです。** · 2008/11/08(土) 16:22:15

>>56
KEY_INPUT_○○を全部一つの配列に入れとけばループで処理できる
KEY_INPUT_RETURNが来たときだけ別にすればいい

**名前は開発中のものです。** · 2008/11/08(土) 16:30:21

flgOn = false;
if (CheckHitKey(KEY_INPUT_RETURN) == 0)
{
flgOn = true;
}

じゃだめなの？

**名前は開発中のものです。** · 2008/11/08(土) 16:31:40

あーごめん、だめだ。　エンター押されてない　かつ　ほかのキーが押されてる　だったね

**名前は開発中のものです。** · 2008/11/08(土) 16:31:51

>>56
CheckHitKeyAll( void )を使って、キーボードの状態を監視しておいて、
何か押されたとき、CheckHitKey(KEY_INPUT_RETURN)で、
エンターが押されているかどうか判別する。
エンターが押されていなければ、エンター以外の何かが押されたことになる。

**名前は開発中のものです。** · 2008/11/08(土) 17:05:01

CheckHitKeyAll(void) だとマウスボタンとゲームパッドも反応するので
CheckHitKeyAll(DX_CHECKINPUT_KEY) で。

……これでもパッドが反応するんでコードチェックしたらバグだった。

DxInput.cpp:
　>// ジョイパッドのチェック
　>if( CheckType & DX_CHECKINPUT_KEY )　 // DX_CHECKINPUT_PAD のはず

気になるならバグ報告して修正を依頼してください。

**名前は開発中のものです。** · 2008/11/08(土) 17:08:47

みなさんありがとうございます。
一応タイピングのゲームです。

ループ処理をヒントに、
bool flgOn = false;
for (int i = 0; i < 256; i++ )
{
if (i != KEY_INPUT_RETURN)
{
if (CheckHitKey(i) == 1)
{
flgOn = true;
}
}
}
という風な処理にしたら、一応望み通りの動きができました。
でもバグ有りそうな予感がします。
CheckHitKeyAllを使えばもう少しスマートに書ける……のかな？

**名前は開発中のものです。** · 2008/11/08(土) 17:24:48

タイピングゲームって言っても、使わないキーはあるだろうから
そのあたりを省いた方がいいかも

**名前は開発中のものです。** · 2008/11/09(日) 13:19:18

KEYリテラルはビットフラグを利用してると思うから
&を使えばシンプルにすっきり書けるはずだよ。

**名前は開発中のものです。** · 2008/11/09(日) 15:04:32

だれかDXライブラリで作ったすごいゲーム等紹介してください

**名前は開発中のものです。** · 2008/11/09(日) 15:37:16

>>66がすごいと思うかは知らんが、
公式で紹介されてない所だと夜光蛾4とかDiadraEmptyとか。
同人系は「DXライブラリでここまで作れる」っていう良い例が多いな。

**名前は開発中のものです。** · 2008/11/09(日) 16:53:27

DiadraEmptyすげえな。
個人的にはモノリスフィア。

**名前は開発中のものです。** · 2008/11/09(日) 17:01:59

>>66
四聖龍神録は？半オープンソースだし。

**名前は開発中のものです。** · 2008/11/09(日) 18:19:57

DXライブラリってDirectXのラッパーなんだから2Dならなんでもいけるだろ

54 · 2008/11/10(月) 00:04:21

>>55
描画先変更できたのかーー！
こいつは便利だ

他にも見落としてる便利な関数あるかもと思って久しぶりに本家リファレンスページ見たら
”ドット単位で画像にアクセスしたい関係”ってのが追加されてて便利すぎﾌﾋﾋきゃっほう！！！１１

もうひとつ質問です。DrawPolygon3Dかなにかで3D平面を、空気遠近法で表示させたいのですが
似非でもいいのでいい方法ないでしょうか

**名前は開発中のものです。** · 2008/11/10(月) 17:51:27

DrawPolygon3DのＺ値を変えれば距離が変わるよ。
本家のリファレンスみたらわかるはず。

**名前は開発中のものです。** · 2008/11/11(火) 01:35:00

>>66
あとはゲームではないが
ウディタ(WOLFRPGエディタ)もそうだ。

**名前は開発中のものです。** · 2008/11/11(火) 16:04:15

８時から１１階から目薬の企画実行移します。場所は↑のとこで。
参加者は今のとこ私の他は３人です。その後焼き鳥でも食べに行きましょう。

**名前は開発中のものです。** · 2008/11/11(火) 19:37:44

最近のグラボは、古いDirectXにマトモに対応しておらず
DXライブラリもその煽りを食らってるって聞いたんだけど、どうなん？

**名前は開発中のものです。** · 2008/11/12(水) 06:22:06

そうなの？
9600GT,8800GTS,6600GTの３つ使ってるけどどれも不具合出たこと無いよ。

それよりVistaでたまにおかしなことになる・・。
同じコードで動かしてもXPとVistaじゃ違う挙動することが。

一つ一つのサンプル動かしても全然違わないんだけど、
スゲー大きなプログラムを動かしてみると違いが出てくることがある。
どうしてなんだろ・・。
ＤＸ管理人さんはそんなことないって言ってるから
自分のプログラムが悪いだけかもしれんが・・。
みんなそういうこと無い？

**名前は開発中のものです。** · 2008/11/12(水) 08:00:35

>>76
ＶＩＳＴＡに最初からはいってるのはDirectX10だからね。それも中途半端な。
ＭＳの中途半端な対応のせいでゲーム開発者はみんな迷惑してる。
DirectX9とか新しいDirectX10とかを入れてみると改善すると思う。

**名前は開発中のものです。** · 2008/11/12(水) 08:10:38

>>76
ビデオドライバ類が関係しているとかないかな

75 · 2008/11/12(水) 18:00:22

グラボじゃなくてVistaってことかもしれん。
自分は持ってないんで確認できないまま適当に書いた、すまん。

76 · 2008/11/12(水) 20:17:02

DirectX10の影響はいろいろ聞くね。
今度出るwindows7だっけ？あれはどうなるんだろう・・。

>>75

VistaとXPデュアルブートするといいよ。
作ったゲーム色んな環境で試してみれる

**名前は開発中のものです。** · 2008/11/12(水) 20:59:00

>80

2000 orz

**名前は開発中のものです。** · 2008/11/12(水) 22:09:52

Windows7でＭＳコケたらDirectX終わってLinux+OpenGLが盛んになる予感

**名前は開発中のものです。** · 2008/11/13(木) 01:05:13

ビスタって結局なんだったんだ・・。
なんかうちの周りだと、ＰＣに詳しくない奴が買ってるＯＳってイメージがある。
そのまま終わっていくのかビスタ。

**名前は開発中のものです。** · 2008/11/13(木) 07:38:57

諸刃の剣素人には(ｒｙ　ってやつじゃない？

**名前は開発中のものです。** · 2008/11/13(木) 19:45:16

>>83
ネットできりゃそれでいいってやつが買ってる印象だな
あとはofficeでも使えりゃ困らないしな

**名前は開発中のものです。** · 2008/11/13(木) 23:48:34

レンダリング処理やエンコードとかしても、ビスタは遅くてしかたないよ・・。

**名前は開発中のものです。** · 2008/11/14(金) 00:26:08

>>80
今時デュアルブートって流行らないんじゃない？
VPCとかさ。

**名前は開発中のものです。** · 2008/11/14(金) 01:06:10

今の最新技術は知らんけど、VirtualPC、VMWareは
グラフィックボード使ってなくて、CPU依存

**名前は開発中のものです。** · 2008/11/14(金) 01:26:37

デュアルブートって流行ってるからとかでやるもんじゃないだろ

**名前は開発中のものです。** · 2008/11/14(金) 01:28:06

どこから突っ込めばいいのか…

**名前は開発中のものです。** · 2008/11/14(金) 01:28:54

>>90
つ*

**名前は開発中のものです。** · 2008/11/14(金) 13:57:39

800*600のサイズでウインドウモードにしたいんだが、
SetGraphModeとChangeWindowModeを同時に使うと、
かなりの確率でOSごと落ちるorz

**名前は開発中のものです。** · 2008/11/14(金) 14:22:12

DxLib_Initの後にChangeWindowMode置いたらフリーズしなくなった
ｻｰｾﾝｗｗｗﾌﾋﾋｗｗｗｗｗ

**名前は開発中のものです。** · 2008/11/14(金) 14:48:29

>>93
初期化の前にウィンドウモードにした方が処理が早いよ

**名前は開発中のものです。** · 2008/11/14(金) 14:50:12

初期化(DxLib_Init)の前にSetGraphModeとChangeWindowMode書くと、
うちの環境ではなぜかフリーズするんです

**名前は開発中のものです。** · 2008/11/15(土) 19:53:04

質問させてください

ゲームの速度をどのＰＣでも一定になるようにするために、
ScreenFlipを使う前と後の時間差を利用してる方法が本にあったのですが、
そもそもScreenFlip一回の時間はどのように決まっているのでしょうか？

**名前は開発中のものです。** · 2008/11/15(土) 20:12:06

リフレッシュレート。

画面のプロパティ→設定→詳細→モニタ　で、リフレッシュレートが確認できる。
つってもこれは俺のPC（windows2000）だから他の環境だとちょっと違うかも。

**名前は開発中のものです。** · 2008/11/15(土) 20:17:30

補足。

ScreenFlipがリフレッシュレート通りになるのは
デフォルトで垂直同期信号待ちをしてるからであって、

「SetWaitVSyncFlag 　ScreenFlip関数実行時にＣＲＴの垂直同期信号待ちをするかのフラグセット」

で、垂直同期信号待ちを切った場合は関係ない。

また、条件は知らないが特定の環境（うちの場合はサブのノートPC）では
垂直同期信号待ち設定にしていても、ScreenFlipで垂直同期信号待ちしてくれない場合が
ある事を確認済み。

**名前は開発中のものです。** · 2008/11/15(土) 20:27:43

>>97-98
返事ありがとう。

リフレッシュレート自体はわかったんですが
後半よくわからなかったのでちょっと調べてみます・・・。

**名前は開発中のものです。** · 2008/11/15(土) 20:51:40

>ScreenFlipを使う前と後の時間差を利用してる方法

ってのがどんなのか判らないけど、
ScreenFlipの垂直同期信号待ちを利用した方法だとすると
前述したようにリフレッシュレートに依存するから
「どのPCでも一定の速度」にはならないよ。

リフレッシュレートを60にしてるPCと70にしてるPCではスピードが違う。

まぁそれを踏まえた上でいちばん簡単で代表的な速度を一定にする方法なんだけどね。
（つまり、リフレッシュレートが６０の場合を前提としてゲームを作り、
　６０以外にしてる人は６０にしてからプレイしてください、となるｗ）

**名前は開発中のものです。** · 2008/11/15(土) 21:13:47

垂直信号同期待ちについて、おおざっぱに説明してみようか。
俺も聞きかじりの知識だが。

最近はテレビにしろディスプレイにしろ、液晶が主流で「薄型」になってるが
もしブラウン管（分厚い）のテレビなりディスプレイがあるなら、画面の前で手を振ってみるといい。
残像がぶつ切りに、ストップモーションのように見えるはずだ。

これはどういう事かというと、画面が60分の1秒に一回、点滅してるからそう見えるんだ。
（厳密には60分の1秒に画面半分）
つまり、画面が光ってる時に「手の影が見えて」、画面が消えてる時には「見えない」から
手の動きがぶつ切りに見えるわけだ。

そうやって点滅してるのに、ずっと光ってるように見えるのは残像のせい。

もっとも「眼（瞳孔）」の方は反射で動いてるから、画面が光ってる時には瞳孔が小さくなり
画面が消えてる時は瞳孔が大きくなってたりするはず。
だから画面に近づいたり、暗い部屋で画面を見たりすると極端に眼が疲れる。

**名前は開発中のものです。** · 2008/11/15(土) 21:24:13

さて、画面が点滅してる、と言ったが、画面全体がぱっとついたり消えたりしてるわけじゃない。
ブラウン管ってのは、奥から電子ビームを画面に向けて照射して、その部分のみを光らせてるわけだから
実際に光ってるのは１点のみ。（もっとも一度照射されるとしばらくは持続するらしいが）
その電子ビームの照準が、画面の左上から始まって、右端まで動き、
一段さがってまた左端から始まって右まで動き、を繰り返し、画面の右下まで進む。
つまり
┏━━━┓
┃□ぬ□┃
┃□る□┃　みたいな画面が表示されてると、それは実際は
┃□ぽ□┃
┗━━━┛

┏━━━┓
┃□ぬ□┃
┃■■■┃
┃■■■┃
┗━━━┛
┏━━━┓
┃■■■┃
┃□る□┃
┃■■■┃
┗━━━┛
┏━━━┓
┃■■■┃
┃■■■┃
┃□ぽ□┃
┗━━━┛
という感じで高速に書き換えられてるという事。

**名前は開発中のものです。** · 2008/11/15(土) 21:30:19

ここでゲームの話になるわけだが、ゲームのキャラクターは画面上をあちこちに動く事になる。
もしこの「動く」のが前述した「画面を書き換えてるタイミング」だったらどうなる？
┏━━━┓
┃ぬ□□┃
┃る□□┃　この状態から
┃ぽ□□┃
┗━━━┛
┏━━━┓
┃□□ぬ┃
┃□□る┃　この状態からにまで移動しようとすると
┃□□ぽ┃
┗━━━┛
┏━━━┓
┃ぬ□□┃
┃■■■┃
┃■■■┃
┗━━━┛
┏━━━┓
┃■■■┃
┃□る□┃
┃■■■┃
┗━━━┛
┏━━━┓
┃■■■┃
┃■■■┃という感じになり、
┃□□ぽ┃
┗━━━┛
┏━━━┓
┃ぬ□□┃
┃□る□┃　人間の目にはこう映ってしまう。この現象をティアリングと呼ぶ。
┃□□ぽ┃
┗━━━┛

**名前は開発中のものです。** · 2008/11/15(土) 21:38:19

>>100
「ScreenFlipを使う前と後の時間差を利用してる方法」ってのを普通に解釈したらリフレッシュレートに依存せずに一定になるよ。
ScreenFlipの待ち時間に関係なく、1フレーム（1ループ）の差時間から移動距離を割り出せばok。
ただし、ゲーム画面がアクティブでなくても実際に時間は経過してるので、ゲームに戻るとその分進む（進んだ）ことになる。
これを回避するなら、ゲーム内で独自にインクリメントカウントを設置し、そこから移動距離を割り出せばok。
ゲームプログラミング独特の考え方だね。

**名前は開発中のものです。** · 2008/11/15(土) 21:40:57

>>101
ブラウン管テレビは29.97fpsだよ。

**名前は開発中のものです。** · 2008/11/15(土) 21:41:23

このティアリング（ちらつき）をさせないためにはどうすればいいか？

これが「垂直同期信号待ち」であって、つまりは
ディスプレイが画面全体の書き換えが終わるまで、
次の描画処理をしないで待ってるってわけだ。

これがScreenFlipではデフォルトで行われてる。
だからScreenFlipを使うと速度が一定に保たれる……のだが、

「画面の点滅は60分の1秒」と言ったが前述したが、これが要するにリフレッシュレートの事。
つまりこの速度をPC側で自由に変更できたりする。

リフレッシュレート60の場合はScreenFlipは60分の1秒経つまで待つわけだが、
リフレッシュレート70の場合は70分の1秒しか待ってくれない。
その分ゲーム速度は速くなってしまうわけだ。
（もしプログラム処理自体が重くて、70分の１秒で終わらなかったら
　70分の2秒、つまり35分の1秒かかるわけで、逆に遅くなる）

**名前は開発中のものです。** · 2008/11/15(土) 21:47:42

移動距離を割り出すという方法は知ってるし理屈も解るけど、
当たり判定もそれ相応の処理にしなくてはいけないし、
そうなるとリプレイ記録＆再生をどうやればいいのかわからなくなる。
そこらへんはどうやってるのかな。

ってこれはDXライブラリと関係ないか。

**名前は開発中のものです。** · 2008/11/15(土) 21:57:26

当たり判定もリプレイ記録も問題ないよ。
でもScreenFlipの待ち時間を基準にするなんて誰もしないと思うから
あたかもScreenFlipを使うとスピードがリフレッシュレート依存になるみたいな解説はやめたほうがいいと思うよ。

**名前は開発中のものです。** · 2008/11/15(土) 22:29:29

画面を書き換えたときに時間を取得し、前回取得した時間と比較して、
１ループが17ミリ秒（60FPS）になるまでウェイトをかけてやればいい
これが一番簡単で確実

**名前は開発中のものです。** · 2008/11/15(土) 22:34:05

リフレッシュレートが60のときはScreenFlip依存でいいんじゃね
それ以外はタイマで

**名前は開発中のものです。** · 2008/11/15(土) 23:12:07

>でもScreenFlipの待ち時間を基準にするなんて誰もしないと思うから

いや、俺してたし、してるしｗ

**名前は開発中のものです。** · 2008/11/15(土) 23:32:40

>>111
その話をしてるのは君だけど、実際にそれを採用してる人はいないって事だよ。

もしかして君は採用もしてるの？
だとしたら自分が長々と説明したデメリットが解消できてないよね。
それを解消したくて質問したいならそれなりの場所でそれなりの質問方法を取ればいいと思うよ。
もしそうじゃないなら誰も採用しない方法を解説されてもややこしくなるだけだから…。

**名前は開発中のものです。** · 2008/11/15(土) 23:41:52

ティアリングが嫌だから切り替え方式にしてるます。
最初はゲーム起動時に測って自動切換えにしてたけど
それもやめて結局手動切り替えに……。

**名前は開発中のものです。** · 2008/11/15(土) 23:43:35

切り替えってのはリフレッシュレート依存方法と、タイマでウェイトかける方法の二つね。
移動距離算出方法はやった事ないです。

**名前は開発中のものです。** · 2008/11/16(日) 00:40:12

ティアリングとスピードは関係ないでしょう。
とりあえずDXライブラリを使うならScreenFlip()で垂直同期を待てば良いと思うよ。
スピードの話はまた別の話。

>>113
ゲーム起動時に何を測るの？
それと、切り替える必要性が見えないんだけど・・・？

**名前は開発中のものです。** · 2008/11/16(日) 01:43:29

>>115
>ゲーム起動時に何を測るの？

ScreenFlipを一秒間繰り返して、その回数で判断。
>>98で書いたけど、垂直同期信号待ちをしてるはずなのに
ScreenFlipで待ってくれない場合があるから、
FPS値が異常に高かったらそうだと判断して
タイマー値によるウェイトかけるようにしてた。

>それと、切り替える必要性が見えないんだけど・・・？

それはどっちを基準にして？

ScreenFlipを基本として考えるなら、リフレッシュレートが変更された場合や
上で書いた垂直同期信号待ちしてくれない環境の時に異状スピードになってしまう。

タイマ値でウェイトかける場合は、やっぱりティアリングが気になるし、
１フレームごとに点滅するエフェクトとかがきちんと点滅しなくなる。

**名前は開発中のものです。** · 2008/11/16(日) 02:40:28

>>116
えっと、だからね、ScreenFlipとティアリングは関係あるけど、
それらとウェイトは関係ないって事だよ。

ゲーム起動時にScreenFlipの待ち時間からリフレッシュレートを判断してるようだけど、
それも結局ScreenFlip基準でタイマー取る方式だよね。
てことは例えば60Hzを基準にウェイトをかけるって事だよね。
だとしたらはじめからリフレッシュレートのウェイトなんかに頼らずに、
マルチメディアタイマーででも1/60sを基準にコードを書けばいいでしょ？
だから起動時に測る必要もないし、リフレッシュレートの変更やVsyncを待たない場合は考慮しなくていいの。
繰り返すけど、タイマーでウェイトかけてもScreenFlipを使うならティアリングはないよ。

**名前は開発中のものです。** · 2008/11/16(日) 03:40:07

何か齟齬がある気がする。

タイマでウェイトかける場合は、ScreenFlipのVsync待ちはOFFにしてあるんだけど、
それでもティアリングは発生しない？

んじゃ発生してる俺のプログラムは何か間違ってるのか。

理屈上、1/60sを基準にウェイトかけるようにすれば
ゲームスピードは一定になるが、タイミング次第で
ティアリングが発生しない状態か、
あるいはティアリングが発生し続ける状態が
維持されるものだと思っていたのだが。

**名前は開発中のものです。** · 2008/11/16(日) 04:22:31

Vsync待ち、かつ、タイマーで制御するんだよ。
これを前提に最初から読み返してみて。

**名前は開発中のものです。** · 2008/11/16(日) 14:59:43

ScreenFlipもやって、1/60secも待って、ってやらないと一定にならないし、ちらつきも解消されないよ。

**名前は開発中のものです。** · 2008/11/16(日) 17:43:53

タイマー待ちを使うんならVsync待ち無しのScreenFlipじゃないと
ティアリングは発生しないけど動きが凄いガクつくぞ
ＡＤＶみたいに動きの少ないゲームならそれでも良いと思うけど、
ＳＴＧやＡＣＴでは見るに耐えない

**名前は開発中のものです。** · 2008/11/16(日) 18:33:07

60Hzに合わせれば60Hzの環境なら結局タイマーでウェイトしないから問題ないよ。
75Hzの環境なら60fpsに制限されるから多少はガクつくけどこれはトレードだね。
ちなみに3Dモノとか海外のゲームはfpsを出来るだけあげて垂直同期しないっていうのが主流みたい。

>>121みたいにfps制限はするわ垂直同期しないわっていうのは愚の骨頂。
ティアリングするわfps制限されてるわでひどいもんですわ。

**名前は開発中のものです。** · 2008/11/16(日) 21:17:57

>>102-103
ｶﾞｯ

**名前は開発中のものです。** · 2008/11/16(日) 21:57:20

>>122
なんでそんなに相手を見下したような態度なの？

>60Hzに合わせれば60Hzの環境なら結局タイマーでウェイトしないから問題ないよ。
それはわかってるよ
だから最初にリフレッシュレート測って垂直同期主体にするかタイマー同期にするか判断するんでしょ？
121はあくまでfpsとリフレッシュレートが一致していない場合の話

>75Hzの環境なら60fpsに制限されるから多少はガクつくけどこれはトレードだね。
ここで122の言うとおり垂直同期とるかとらないかはプレイヤーの好みの問題
オプションで選択できるようにすべきだと思う

>ちなみに3Dモノとか海外のゲームはfpsを出来るだけあげて垂直同期しないっていうのが主流みたい。
そうだね。３Ｄモノは可変fpsと相性良いよね。

>>121みたいにfps制限はするわ垂直同期しないわっていうのは愚の骨頂。
垂直同期をとらないことで手軽に入力に対するレイテンシを下げることができるし、
リプレイを取る目的でfpsを固定しなければならない場合もあるんだから、
短絡的に愚の骨頂というのはどうだろう

122的には60fps固定＋垂直同期してない東方緋想天は愚の骨頂？
俺はそうは思わないけど・・・

**名前は開発中のものです。** · 2008/11/16(日) 22:50:57

２Ｄシューティングを過去いくつか作ってきましたが、
リプレイ周りの実装も含めて、やっぱりFPSは60に固定でロジックを組みますよ。
オプションで「Vsync待ちをするかタイマーか」を選択させてます。
１２４さんもリプレイの話をしているから、そういう前提で言ってるのだと思うのですが。

**名前は開発中のものです。** · 2008/11/16(日) 23:07:43

リプレイって別にFPS固定必要ないような
入力があったキーとその時の経過フレーム数があればいいんだし

**名前は開発中のものです。** · 2008/11/16(日) 23:30:59

おまいらもちつけよ.

**名前は開発中のものです。** · 2008/11/17(月) 01:36:47

>>124
何そのゲーム。＞東方なんたら
最悪だね～。

>>126
だよねぇ。

**名前は開発中のものです。** · 2008/11/17(月) 03:32:51

なんだ釣りか

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

なんだこんなすばらしいスレがあったのか>>1乙

**名前は開発中のものです。** · 2008/11/17(月) 21:49:06

DXライブラリで作った横スクロールアクションのソースってどこかに転がってない？

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

転がってるって・・・
作者の好意で公開してるソースをそんな言い方するなよ

**名前は開発中のものです。** · 2008/11/17(月) 22:04:49

ニコニコで一時話題になった、しかけが外道なスーパーマリオもどきはソース公開してたと思う

**125** · 2008/11/17(月) 22:57:25

＞126
たしかにそうですね。
ただ、自分の場合は、FPSを固定すればあとはキー入力さえきちんと記録できていれば
リフレッシュレートが違えどもリプレイがずれることがないのでそうしていました。

**名前は開発中のものです。** · 2008/11/17(月) 23:31:08

移動量固定方式か、経過時間による移動量計算方式かで
やり方も違ってくるんじゃないかな。

**名前は開発中のものです。** · 2008/11/18(火) 13:05:35

>>133
しょぼんのアクション　だっけ？
やっと1－1クリアだと思ったのに愕然とした記憶がある。

**名前は開発中のものです。** · 2008/11/19(水) 13:43:13

DirectXのバージョンを9に移行するらしいね

**名前は開発中のものです。** · 2008/11/19(水) 14:54:42

>>133
あれはやばいです
あれはほんとうに・・やばい・・。
この道１０年のベテランですらあれを見ると悶絶して悶え死ぬレベル。
あのソースを読んだあの日、私は自分の人生について考えさせられました。

**名前は開発中のものです。** · 2008/11/19(水) 15:08:39

そんなにすばらしいのか

**名前は開発中のものです。** · 2008/11/19(水) 15:11:10

思わず3回DLし直す位のレベル

**名前は開発中のものです。** · 2008/11/19(水) 18:41:54

あれは伝説のソースですよ

**名前は開発中のものです。** · 2008/11/20(木) 23:58:11

DLしてみたが・・・凄まじいソースだな

**名前は開発中のものです。** · 2008/11/21(金) 00:08:16

俺のソースも似たようなもんだなｗ

**名前は開発中のものです。** · 2008/11/21(金) 00:14:35

汚いコード書ける奴って尊敬するわ
むしろ逆に頭良いと思う

**名前は開発中のものです。** · 2008/11/21(金) 00:46:35

部屋が汚くても気にしないやつがいるのと同じ

**名前は開発中のものです。** · 2008/11/21(金) 05:06:26

http://fatalita.sakura.ne.jp/Software/cuirpgfordq3.lzh
これもマジキチ

**名前は開発中のものです。** · 2008/11/21(金) 05:58:28

>>146
これはアイテム4つで実装力尽きるｗ
配列すら使ってないとかやべぇ

でもスレチ

**名前は開発中のものです。** · 2008/11/21(金) 12:55:25

BASIC覚えたての頃、そんな風にGOTO文メインでテキストアドベンチャーゲームを作ったなあ…。
それにしてもその作者はDXライブラリ3Dの作者なの？
なんか色々考えさせられるな…。

**名前は開発中のものです。** · 2008/11/21(金) 15:36:28

でもスレチ

**名前は開発中のものです。** · 2008/11/21(金) 19:40:33

自分のスパゲティソースを晒す勇者はおらんのか・・

**名前は開発中のものです。** · 2008/11/21(金) 21:42:08

さらしてどうすんのよｗ

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

タイピングゲーム作ってるけど疲れてきたぜ。
ゲーム一本完成させるって難しいな。

**名前は開発中のものです。** · 2008/11/23(日) 02:26:12

完全体になる前にリリースすればいいじゃない（ﾏﾘｰ

**名前は開発中のものです。** · 2008/11/23(日) 02:27:42

プログラム歴３ヶ月おれもタイピングゲーム作ってます
プログラム練習としても面白いジャンルのような気がします
がんばりましょう

**名前は開発中のものです。** · 2008/11/23(日) 14:21:16

>>153
俺知ってるよ
そういうのをあじゃいるって言うんだよね

**名前は開発中のものです。** · 2008/11/23(日) 17:55:00

画面全体をぼかしたいのですが、どうすればいいのでしょうか？

SaveDrawScreen()で画面全体を保存した後に、
その画像を加工して表示するという方法を試しましたが、遅くてとても使えませんでした。
ちなみに手順は
保存→加工→保存→表示です。
加工と二回目の保存の処理の間がとても遅かったです。

直接DXライブラリで描画してる画像をぼかせばもっと早くなると思うのですが、
DXライブラリで直接ぼかす方法がさっぱりわからりません。
どういう方法でぼかせれるのでしょうか？

**名前は開発中のものです。** · 2008/11/23(日) 20:09:39

ブレンドモードを上手く使えばどうにかなるんじゃなかろうか。
昔、モーションブラーもどきを自分で作ったが細かいやり方は忘れた。

**名前は開発中のものです。** · 2008/11/25(火) 00:31:59

>156
そのまま画像を描画
↓
αブレンドを適当に128くらいに指定してxy数ドットずらして描画×数回…

こんなのでどう？

**157** · 2008/11/25(火) 20:03:29

>>158
ああ、そうそう。
そんな感じでできると思う。たぶん。
ずらし量やブレンド率でぼけ足上手いこと調整してどうにかする。
関数化できたら楽そうだ。

**名前は開発中のものです。** · 2008/11/25(火) 22:23:11

>>157-159
いろいろとありがとうございます。
アドバイスのおかげで、それらしいのはできました。
縦には動かしていないのですが、とりあえずそれっぽい動作はします。
ソースは以下の通りです。

private void GraphOff(int dot,int graphHandle)
{
for (int i = 0; i < 640 / dot; i++)
{
DrawGraph(i * dot - 640, 0, graphHandle, 0);
DrawGraph(640 - i * dot, 0, graphHandle, 0);
}
}

これでまた問題が出たのですが、この処理非常に重いです。
FPS30固定にしているのですがこれをするとFPS10～15になります。
軽くする良い方法は何かないでしょうか？

**名前は開発中のものです。** · 2008/11/25(火) 22:39:54

640 / dot ←この計算をfor文の前にやって適当な変数に代入しておく

**名前は開発中のものです。** · 2008/11/25(火) 23:02:53

>>160
i < 640/dot
を
i < 160/dot
くらいにまで下げてみる

ぼかすのがゲーム上そんなに大事じゃなかったら
このくらいで妥協するのが一番

**157** · 2008/11/26(水) 02:18:18

>>160
そんなに回数要る？
dotの値がいくら位で何回位描画しているのかとか、コードの意図とかちょっとわからんので
↓とどっちのコードの方が性能良いのかよくわからんけど…

int times = 4;//描画回数：4～16推奨
int gap = 2;//ギャップ：1～4推奨。残像拳のような効果を狙うなら大き目に。
SetDrawBlendMode( DX_BLENDMODE_ALPHA , 32 ) ;//描画回数×ブレンド率＝128～256推奨

for (int i = 0; i < times; i++){
DrawGraph( i*gap - times*gap, 0, GHandle, 0);
DrawGraph( times*gap - i*gap, 0, GHandle, 0);
}

**名前は開発中のものです。** · 2008/11/26(水) 04:53:23

>>160
本当に速度が必要で、それなりのクオリティーが欲しいなら
LoadSoftImage関数とLoadSoftImageToMem関数を使うといいかもしれない。

自分は近頃、DXライブラリまったく触ってなかったから、どんなもんか
わからんが、説明を読む限りではこっちの関数で処理して
GraphHandleをつけて、表画させる方が高速みたいだし・・・・・

**名前は開発中のものです。** · 2008/11/27(木) 05:33:03

ＤＸライブラリとは直接関係ないのですが、

ＤＸライブラリとかの関数を変な使い方すると、めっちゃ重くなったりして（コンパイルエラーが出るわけではない）、
上手く扱わないとたとえ数百行のプログラムでさえ上手く動かないのに
市販されてる３Ｄゲームとかだとそれこそ想像もつかない量のプログラム書いてると思うんですが
それを全く重くならないように作るというのはまさに神の所業としか思えないんですが・・・
やはり職人的なひとはそれほどすごいってことでしょうか？
それとも単にまだ自分が未熟なだけでしょうか？

なんか抽象的な質問ですみません。

**名前は開発中のものです。** · 2008/11/27(木) 07:22:55

>>165
普通に使っている分には問題ないと思うけど…
コード量も関係ないし。
メインのループ（秒間30～60回くらい回しているとこ）の外で1回やれば済む処理を
ループの中で毎回やってたりしてない？
例えばグラフィックハンドルへの画像の読み込みを毎回やっているとか。

**名前は開発中のものです。** · 2008/11/27(木) 12:05:54

DXライブラリもよっぽど変な使い方しない限りめっちゃ重くはならんでしょ。
そりゃまぁＰＣの性能にもよるけど。

市販されてる３Ｄゲームとかは、俺はヘボプログラマだからそれこそ神の領域にしか思えないけど
同じ市販ゲームでも、すごいグラフィックなのに軽快なのとか、やったらもっさりして重いのとかあるから
そこらへんはプログラマの腕次第でしょ。

凄腕のプログラマは極限まで無駄な処理を省いてるんだと思う。

**名前は開発中のものです。** · 2008/11/27(木) 17:02:45

メモリの１バイトは血の一滴ですね

**名前は開発中のものです。** · 2008/11/27(木) 18:56:41

>>166-167
なるほどサンクス・・・
確かに無駄に繰り返してるかもしれない・・・。

**名前は開発中のものです。** · 2008/11/27(木) 20:46:39

フォントのサイズ変更とかと勝手に予想

**名前は開発中のものです。** · 2008/11/27(木) 22:41:46

>>161-164
ありがとうございます。
回数がご指摘の通り多すぎました。
>>157のコードと併用して、思っていたぼかしができました。
コードは私の作成したコードと>>157のコードを関数化しただけなので省略させていただきます。

**名前は開発中のものです。** · 2008/11/27(木) 22:48:28

フォントのサイズ変更はしゃれにならんほど遅いからな……。
別フォント用意すりゃいいことだが。

**名前は開発中のものです。** · 2008/11/28(金) 05:15:28

SetWaitVSyncFlag(FALSE);

にしたらドラゴンボールの世界になってワロタ

**名前は開発中のものです。** · 2008/11/29(土) 16:25:44

PlayMusic関数で再生位置の指定ってできないの？

**名前は開発中のものです。** · 2008/11/29(土) 22:48:46

>>101

いますぐ昔の再放送の刑事ドラマやドラマの
事務所シーンを見るんだ！！！

パソコンのディスプレイあるだろアレみるとわかりやすい

**名前は開発中のものです。** · 2008/11/30(日) 02:55:10

>>175
あれ今見るとなんでそう見えるか理解出来るな
タイヤが逆回転して見えるのとかも

**名前は開発中のものです。** · 2008/12/01(月) 09:18:57

３Dでゼルダみたいなゲーム作りたいんだけど
DXライブラリ（３D）で完璧に作ったのと
DireｃｔXで完璧に作ったのだったら動きのサクサクさにどれくらい差が出るのかな？
PCの性能は結構良いのでそれは関係なく
個人的にはマリオ６４くらいのクオリティーは出したいと思ってるんだけど
始めての大型ゲームなんで全く想像付かない

**名前は開発中のものです。** · 2008/12/01(月) 09:51:01

3Dのゼルダってまんま64とGCのゼルダじゃね？

**名前は開発中のものです。** · 2008/12/01(月) 10:23:13

はい

**名前は開発中のものです。** · 2008/12/01(月) 16:53:55

DirectXで作るって言ったってどうせ自分でラッピングするんだから一緒だと思うぞ

**名前は開発中のものです。** · 2008/12/01(月) 16:57:45

>>177
そのプロセッサ専用のライブラリを熟知してれば
サクサク動くゲームになる

例えばPS2ならEEとかのベクトル計算のためのライブラリの仕様とか
windowsマシンにはそんな計算機能はデフォルトじゃついてないから
どうしてもグラボ依存になる

**名前は開発中のものです。** · 2008/12/02(火) 00:02:20

int WINAPI WinMain(HINSTANCE hI, HINSTANCE hP, LPSTR lpc, int nC){
　　ChangeWindowMode(TRUE);
　　　 SetDrawScreen(DX_SCREEN_BACK);

while(ProcessMessage() == 0 && CheckHitKey(KEY_INPUT_ESCAPE) == 0){
　　 ClsDrawScreen();
　　　　～～
　　 ScreenFlip();
}
}

↑こう書いたとき、～～　の部分の処理が毎回変わるモノだった場合でも、よほど～～の処理が長くならない限り、
ScreenFlip()があることによって、画面に出力される周期は～～の処理時間によらない、と考えていいんでしょうか？

なんか説明下手ですみません・・・。　　たとえば、指数関数的に動く物体を作りたいとして、
～～の部分を「毎回n=n+1して、x^nの位置に画像を出力」という内容にしたとした場合、
ループが来るたびにｎが増えるからx^nの計算の処理が多少だんだん増えていくと思うのですが、
もしその処理時間も画面出力に影響してしまったら、動きが時間の正確な指数関数にならないと思うのですが、
『ScreenFlip()によって、「処理が終わっても、規定時間δtが来るまでは画面出力しない」という仕組みが加わってるので、
処理時間に影響せず一定時間ごとに画面出力される。　ただし、もちろん　処理時間の方がδｔを超えてしまったら、重くなるという別の影響は出てくる。』
というものだと解釈していいのでしょうか？

（すみません。アク禁中の代レスなので、返事できないかもしれません。）

**名前は開発中のものです。** · 2008/12/02(火) 08:48:55

どうでもいいがProcessMessage()の場所が俺の好みじゃなかった。
本文は読んでいない。

**名前は開発中のものです。** · 2008/12/02(火) 08:53:50

SetWaitVSyncFlagがFALSEで無い限りは

**名前は開発中のものです。** · 2008/12/02(火) 09:50:01

リフレッシュレートに依存する。

**名前は開発中のものです。** · 2008/12/02(火) 21:13:42

x^nの計算なんか描画処理に比べたらほんの一瞬

**名前は開発中のものです。** · 2008/12/02(火) 22:13:19

そういやCを独学でやってて最初に詰まったのがべき乗計算だったなｗ

**名前は開発中のものです。** · 2008/12/03(水) 05:14:23

>>153
#include <stdio.h>
#include <windows.h>
void main (){
int cell=0,jinzo18=2,jinzo17=2,tensinhan=25,seimeiryoku=1;
int hikinobasi=0;
cell+=jinzo17;
for(hikinobasi=0;hikinobasi<30;hikinobasi++){printf("おお\n"); SleepEx(200,TRUE);}
printf("天津飯「まずい１７号を吸収しやがった・・・チャオズ俺は死ぬかも知れない\n");SleepEx(2000,TRUE);
printf("セル「天津飯！！雑魚が何をするつもりだ！」\n");SleepEx(4000,TRUE);
printf("天津飯「新気功砲！！ハー」\n");SleepEx(200,TRUE);
printf("セル「(ﾟДﾟ)ぬお！\n");SleepEx(200,TRUE);
while(tensinhan>0){
printf("セル「<｀Д´>おのれー」\n");SleepEx(200,TRUE);
printf("天津飯「(；　ﾟДﾟ)ハァー！」\n");SleepEx(500,TRUE);
tensinhan-=seimeiryoku;}
printf("天津飯「化け物め・・・・うう・・・・」\n");SleepEx(5000,TRUE);
printf("セル「むううう」\n");SleepEx(1000,TRUE);
printf("セル「こんな雑魚に足止め食らうとは」\n");SleepEx(4000,TRUE);
cell=jinzo17+jinzo18;
for(hikinobasi=0;hikinobasi<100;hikinobasi++){printf("おお\n"); SleepEx(50,TRUE);}
printf("完全体セル「すばらしい力だ　諸君！！」\n");
SleepEx(10000,TRUE);
}

**名前は開発中のものです。** · 2008/12/03(水) 05:38:32

同一内容の文字列を毎フレーム表示する処理があり、

空のサーフェスを作成 → 一旦バックバッファに文字列を描画 → バックバッファから空のサーフェスに文字列の画像を取得

こうして予め文字列を描画しておいたサーフェスから
毎回メイン処理でDrawGraphしているのですが、どうもスッキリしません。
しかもGetDrawScreenGraphの説明にもある通り透過色が使用出来ません。
DXライブラリでは作成したサーフェスに直接描画出来ないのでしょうか？
やりたい事は「同じ文字列を毎フレーム描画する処理を軽くしたい」だけなのですが、
文字グラフィックファイルを用意することは出来れば避けたいので、良い方法があったら教えて下さい１

**189** · 2008/12/03(水) 05:45:19

無駄に長くて分かり難くなってしまいました。
（例えば説明文等の）同一の文字列を毎フレーム描画する処理を軽くしたいが
文字グラフィックファイルを用意する以外で良い方法があったら誰か教えて下さいです。

**名前は開発中のものです。** · 2008/12/03(水) 09:09:23

DrawStringで十分軽いと思う
フォントハンドルを毎回読み込んだりしていない？

**189** · 2008/12/03(水) 17:18:45

>>191
お返事遅くなって申し訳ありません。
当方の環境ではDrawStringでやった場合のFPSが30くらいでDrawGraphにすると60になりました。
DirectX自体、文字描画にGDIを使っているのでビデオカードで処理できるBitBltの方が高速だと思っていました。数年前の知識ですが。。
低スペックでも快適に動くように作りたいので、DrawStringは極力使いたくないです。

**189** · 2008/12/03(水) 17:29:14

フォントの変更は行っていないので、フォントハンドルは使用していないです。

**名前は開発中のものです。** · 2008/12/03(水) 18:07:17

そんなにたくさんの文字を同時に表示してるのかな？
それともＰＣ環境が悪すぎる？

俺普通にDrawString使ってるけど別に遅くなった事ないよ？
普通に60FPS出てる。古いノートパソコンで。
最高でまぁ10行程度の表示しかしてないけど。

**名前は開発中のものです。** · 2008/12/03(水) 18:30:58

いやそれじゃ全くテストになってないから。
192の知識通り、今も文字列表示は遅いよ。
189の方法が適切だと思うし、他に方法を提示できないのは申し訳ないけど、
少なくとも文字列表示が遅いって前提でレスされると無駄だと思ったので口を出してみた。

**名前は開発中のものです。** · 2008/12/03(水) 18:37:18

×少なくとも文字列表示が遅いって前提でレスされると無駄だと
○少なくとも文字列表示が遅いって前提を否定するレスは無駄だと

**名前は開発中のものです。** · 2008/12/03(水) 19:17:52

俺の事？
別にテストしたわけじゃなくて、普通に使ってるだけなんだが。

文字列表示が遅いってのが前提なら、そもそもグラフィック表示だって遅いだろ。

グラフィック表示が遅いから他の方法はありますか？　って質問があったとしたら
まず現在どういう環境でどれだけのグラフィックをどういう方法で表示させてるのか教えろってのは普通の流れだろ？

そこをかっとばしてグラフィック表示処理そのものを早くする方法を考えるのは無駄な話だ。

**名前は開発中のものです。** · 2008/12/03(水) 19:27:15

確かに
今与えられた情報だけではなんともいえんな

**名前は開発中のものです。** · 2008/12/03(水) 19:41:02

文字列の長さ、量がまずわからない。

「フォントの変更は行っていない」というのが、フォントの大きさやアンチエイリアス有無の変更は行っているかもしれないとも読める。

**名前は開発中のものです。** · 2008/12/04(木) 00:31:01

>>197
文字列表示はグラフィック表示より遅いって常識知らないの？
そこは議論の余地なしだから言ったまで。
それと、テストじゃないなら>>194の報告は不適切。
まあ上記の前提を知らなかった故だからしかたないと言えばしかたないが、ややこしくなるのでなかったほうがよかったな。

情報は少ないが、前提を知っているば容易に共感できるし、解決方法を知っている人ならこの情報量でも回答できるかもしれない。

DXライブラリ 総合スレッド 2008

DXライブラリ総合スレッド 2008