12/11/10 20:38:55.50 MaNESqv5
自分の知ってる洋ゲーだと、
起動ランチャーからPlayとOptionが選べて
Optionからウィンドウ・フルスクリーンまたは解像度の選択をすることで
Play時の画面が変わるタイプと、
とりあえずフルorウィンドウモードで起動させておいてゲーム内オプションから
画面モード、解像度が切り替わるタイプがあるね。
スプラッシュロゴを先に表示させてーって言うのはなくもない気がする。
確かあれは…ｱﾘｽｿﾌﾄ
33:名前は開発中のものです。
12/11/11 00:01:50.31 ftt+7YV1
アリスソフトはスプラッシュスクリーンじゃなくねと思ったら古いのは一見そうだったな
でもあれはオプションでスキップできるからやっぱりスプラッシュスクリーンじゃないんじゃね
34:名前は開発中のものです。
12/11/11 00:07:54.36 FJ/BuQzh
そんな面倒なことするなら、さっさと起動してサークルロゴでも表示して、その隙に読み込むほうがマシ
35:名前は開発中のものです。
12/11/11 00:25:39.48 briCeBRn
つーか、あんなくだらない質問する人がスプラッシュスクリーンが必要になるほどのゲーム作ってるとは思えんｗ
36:名前は開発中のものです。
12/11/11 00:44:26.75 FJ/BuQzh
初心者だからこそ大量のデータを非効率的に読み込んで時間がかかるんだろ
データ量が多いゲーム＝いいゲームってどこの小学生だよ
37:名前は開発中のものです。
12/11/11 05:43:02.75 Hm1wlo6/
>>32
ランチャーでオプションの設定、MODの切替とかできるゲームは腐るほどあるね
開発ブログのフィード表示したりとか
でも>>28が言ってるような、設定読むためにスプラッシュスクリーン表示するゲームってのは聞いたことないな
38:名前は開発中のものです。
12/11/11 06:55:56.42 Fz8S8jkx
初心者が初心者なりに試行錯誤しながら
ゲーム作っちゃいかんのか？
39:名前は開発中のものです。
12/11/11 07:03:25.92 WRJMXXw0
前に自分がやったときは、
別途にGUIアプリを作っておき、そこからゲーム本体を起動する形にしてた。
GUIアプリはルートディレクトリに、ゲーム本体の方は下位ディレクトリに置くようにして、
ユーザには基本的に前者を起動させるようにする。
解像度とかの設定は、起動時に引数で渡すなり、iniファイルを経由するなり。
40:名前は開発中のものです。
12/11/11 08:39:59.76 FJ/BuQzh
わざわざ別アプリにしなくても、Windowsアプリケーションならゲームのexeに組み込めるけどね
ゲームのメインループに行く前にそのダイアログのプロシージャだけwhileで回しておけばいい
41:名前は開発中のものです。
12/11/11 08:42:20.83 L5JKQqt7
俺もDLLの数がかさんだ時やってるなあ
42:名前は開発中のものです。
12/11/11 10:44:08.51 uoIXRWNI
DXライブラリなら、ini読んで最初の描画するまで1秒とかからないよね
前者も後者も時間は変わらないと思うんだけど
最初の描画の前に、巨大なファイル読み込みをしてしまって時間かかってるなら、
それをやめて、最初の描画のあとで巨大なファイル読み込みすればいいと思う
43:名前は開発中のものです。
12/11/12 21:21:49.93 YFdCFH9b
3Dゲーム作ってるんだけど、キャラモデルの影が強すぎる…
みんな調整とかしてるの？マップの方はなんともないのに
44:名前は開発中のものです。
12/11/13 14:04:57.88 NSnEvyoH
アクティビジョンのトニーホークシリーズで、画面解像度とか、Fogのオンオフとか選べるランチャー経由で起動してたな。
exe直だと前回と同じオプションのままで起動だったと思う
45:名前は開発中のものです。
12/11/13 17:18:55.36 54EeWz/8
>>24
均等に負荷かかってるならマルチスレッド処理してるってことだよね？
処理の粒度が細かすぎるとかじゃないかな。粒度が細かすぎると、同期APIでカーネルスケジュラーが
頻繁に起されて、CPUの負荷が上がらなくなるように見えたはず。
46:43
12/11/13 22:35:47.91 kWBnqj8x
俺だけみたいだな、モデルの問題か
XファイルなのがDXライブラリと相性が悪いとかじゃないならいいや
47:名前は開発中のものです。
12/11/15 20:46:12.19 fgdtbuMx
CSSスプライト見たいな手法って画像のロード時間だけで
描画とかゲームの速度自体に影響するのかな？
48:名前は開発中のものです。
12/11/15 22:18:24.14 n5nkf/Ds
一応テクスチャ切り替えの手間が省けるからちゃんと軽くなる
そこが結構重いとか重くないとかいう噂は聞いたことあるけどそういえば調べたことはないな・・
49:名前は開発中のものです。
12/11/15 22:31:02.33 V2Q8QmNk
速度よりは、全く同じように使えるようにする工夫が気になる
50:名前は開発中のものです。
12/11/15 22:48:07.83 JeS5pTB2
めっちゃ影響するぞ
最悪の状態と最高の状態を比べると数倍から数十倍もの速度差がでる
最悪の場合をテストするには、画像Aと画像Bそれぞれの画像からグラフィックハンドルを作って交互に描画
最高の状態をテストするには、画像Aと画像Bを結合した一枚の画像を作って、LoadDivGraphで読み込むか、
もしくは画像Aと画像Bを結合した一枚の画像を読み込んでグラフィックハンドルを作り、DerivationGraphでそれぞれのハンドルを作って、
交互に描画
最悪のパターンなんて、実際には弾幕シューティングでわざわざ別画像の弾を交互にばら撒きまくとか、
別テクスチャのマップチップを交互に敷き詰めるとか、奇妙な状況でしか起こり得ないけど
51:名前は開発中のものです。
12/11/15 22:54:50.95 fgdtbuMx
へぇ、メモリに入ったら同じかと思ってた
52:名前は開発中のものです。
12/11/15 22:58:50.04 JeS5pTB2
書いてて思ったけど、テクスチャ切り替えの発生回数をカウントする関数が欲しいな
最適化プログラム作る際の参考になりそう
53:名前は開発中のものです。
12/11/15 23:22:09.30 j9gB1nc1
実際どのぐらい違うんだろうね
3Dだとモデルを描画する度にテクスチャが切り替わってると思うんだけど
54:名前は開発中のものです。
12/11/16 00:18:40.62 oomGOn6x
>>45
まさか今更相手してくれるとは思わんかったありがとう
えっとID変わってるけど>>26の通り、改めて計測してみると
大体計測の単位時間あたり2～3単位時間に1回ぐらい100%になるコアがある
でも他のコアは20～30%ぐらいだし2～3単位時間に1～2回は60～80%ぐらいしか稼働してない
fpsは常時3～5程度
ソースコードは公式の3Dサンプルプログラムをひたすら改変したものだけどマルチスレッド処理は書き加えてない
描画関数をコメントアウトしても同じぐらいの負荷とfps
でもパーティクルの運動とかの記述はそのままに描画関係の行列計算とかを大量に含む部分を切ったら1万パーティクルでもfps59.6～59.9で安定
今のところテストでグラフィックハンドルは1つしか使ってないので>>50で言う最悪の状態にはなってないはず
将来的にはもっと大量のエフェクトを描きたいので出来れば10万～100万ぐらい扱いたい
最適化は一切してないので描画関係の行列計算がかなり多いように感じる
でもCPUの計算能力や描画関数の呼び出しとかとの相対的な負荷が想像がつかないのでどの程度影響与えてるかわからない
1万～10万ともなると普通の四則計算や行列計算の負荷もバカにならないのかな
55:名前は開発中のものです。
12/11/16 00:22:29.41 oomGOn6x
連投スマン
仮にマルチスレッド処理をさせるようになって>>45の状況になったしたら
CPUの負荷が上がらなくなるように「見える」だけで実際は限界まで負荷かかってるの？
56:名前は開発中のものです。
12/11/16 01:43:36.27 O/FEtKHj
>>54
あれーじゃあなんで均等に負荷がかかってるんだっていう疑問がわいてくる・・・
前段の部分は、行列計算が重いのかなぁ・・・。でもその場合はそのスレッドが全力で走るはずだよね。
後段の方は、実際にも限界まではかかってないよ。
粒度が細かすぎの場合カーネルオブジェクトで同期すると（最悪時には同じ
オブジェクトをそれぞれのスレッドでロックをとりにいくから）1/スレッド数 ぐらいしか
はたらかなくなっちゃう、で、ただただカーネルスケジュラーが走る分だけ重くなる。
（スピンロックの時は全力でスピンし続けるからすべてのスレッドが上限に張り付くのが見える。）
57:名前は開発中のものです。
12/11/16 02:52:18.52 oomGOn6x
>>56
紛らわしいことしてごめん
>>24の均等に負荷ってのは間違いで>>26や>>54の通りどれか1つのコアは高負荷状態になってる
他の3つは確かに割と均等だけど……
でも確かに自分でも処理落ちしてるんだからどれかのコアは常時100%負荷じゃないとおかしいとは思ってる
一応CPUはi5 2500Kでそこまで古いわけじゃないからちゃんとしてやれば別に毎フレーム数万回の運動計算ぐらいなら大丈夫だと思うんだけど
さすがに100万エフェクトに上限設定したらアイドル時？の毎フレームのループ処理だけでfps40ぐらいまで落ちるけど
もう少しして描画関係の関数が落ち着いたらマルチスレッド処理するようにしてみようかな
そのときにもうちょっと勉強して参考にさせてもらうよ
でもまあなんとなくのイメージは分かったありがとう
あとつい勢いでグラボも積んでみたんだけど、ソフトウェアレンダリングじゃなくてハードウェアレンダリングにするのは
SetUseSoftwareRenderModeFlag でFALSE返せばいいんだろうか
これを入れる前後でGPUの負荷も変わったように見えない……
0～40%ぐらいまでしか上がったこと無いんだけど
58:名前は開発中のものです。
12/11/16 03:14:19.95 N1OcN+jA
行列計算は用意された関数を使ってるわけじゃなく自前？
だとしたら普通にその計算が重いだけだと思う
昔自前で座標変換してたコードを発掘してみたら三角関数たっぷりの糞重そうなコードだった
１万パーティクルというと頂点数はその数倍あるだろうし、その上ソートとかもあるとしたらかなりの重さになると思う
弾幕STGの弾の計算処理との比較での想像だけど
59:名前は開発中のものです。
12/11/16 14:41:04.47 nI21i1kq
>>58
行列計算は主にDXlibのMGetRotAxisがほとんどかな
自前で用意したのは使ってない
1パーティクルあたり6頂点(4インデックス)の長方形の板ポリを
時間経過に合わせて自由に変形できるようにしたりしてる
あともう一つ心配な要素としてパーティクル構造体のメンバがかなり多いことがある
個人的な話だけど今まですごく不自由な環境で真似事みたいなことを長いことしてたから
パーティクル一つ一つの運動や展開にとにかく自由度をもたせた結果、
数えてみると一つのパーティクルごとに(unsigned)charが42、intが26、floatが23 程あった
計算がここからの引用の演算が9割なんだけどこれって影響あるかな
60:名前は開発中のものです。
12/11/16 14:55:28.38 N1OcN+jA
MGetRotAxisでも頂点を個別に処理してると重そうだな
何をやろうとしてるのはかよくわからないが、頂点数が多い場合はカメラの側を動かすとかの工夫が要ると思う
頂点一つの変換だけで三角関数が数十回使われるからね
構造体の重さだけど、それが問題になるのはメモリコピーや再配置が行われる場合
つまり、構造体の配列をソートしたり、構造体を関数などに直接渡すときだけ
ソートが含まれる場合は、その配列は構造体のポインタにしておくと早くなる
関数の場合は参照渡しかポインタで
61:名前は開発中のものです。
12/11/17 03:20:24.81 lLy9v9bv
3D空間に文字を表示する方法ってある？
リファレンスみたけどそれっぽい関数が見当たらなくて
内容変化するからテクチャーに貼って表示する方法は使えない
62:名前は開発中のものです。
12/11/17 03:45:07.67 qyuu2tNE
内容変化するなら毎フレーム描画し直せばいいじゃん？
まぁヘッダ読むと多分見つかると思うよ
未確認だけど
63:名前は開発中のものです。
12/11/26 06:43:45.17 UmrBg6OG
更新来てるね
毎度お疲れ様です
64:名前は開発中のものです。
12/11/26 11:34:46.37 3FNv2Sko
自分で制作中のプログラムを 3.09 に載せ替えただけで、60 FPS に届くようになった。
65:名前は開発中のものです。
12/11/26 17:41:20.96 ABDeEVSH
更新しようと思ったらＶｉｓｕａｌＳｔｕｄｉｏも２０１２とかなってるのかよ知らなかったわ
66:名前は開発中のものです。
12/11/26 18:00:36.41 fShAradv
VC++11はconstexpr以下もろもろサポート無しで萎えたんだけど使ってる人いるの
URLﾘﾝｸ(blogs.msdn.com)
だいたいXP対応するっつってもツールで対応するみたいだしもうなんか覚えるの面倒くさいしいいや（ﾊﾞｶ
URLﾘﾝｸ(blogs.msdn.com)
67:名前は開発中のものです。
12/11/26 18:38:13.09 1/gWMvah
ライブラリの更新ってまだ軽量化の可能性とか残ってるもんなの？
68:名前は開発中のものです。
12/11/27 02:04:26.00 JayK2jV6
少なくともDXライブラリはソース見る限りエラーチェックが一番の重くなる原因だと思うから、まだまだ軽量化はできると思うよ
数年前にはライブラリ作者自身がDirectX生で使うより10倍以上遅いって言ってたし
69:名前は開発中のものです。
12/11/27 11:28:23.82 f5qtpDPQ
＞①１万枚が１つのテクスチャを使用していて、且つ全く動かず、１画像辺り16x16サイズであり、それを１万枚毎フレーム描画する、
という条件でしたらDirectXを直接扱う場合はビデオカードの性能が良ければＤＸライブラリの１０倍以上高速に描画できると思います
＞②動かない、という条件のみ変えて１万枚の画像がランダムに画面上を等速直線運動している(画面端にぶつかったら跳ね返る)という場合ですと
差はいきなり縮まってＤＸライブラリのDrawGraphを使う場合より１．５倍ほど高速に描画できると思います、ただ、ＤＸライブラリの
DrawPrimitive2Dを上手く使用した場合は恐らく速度差は殆ど無いと思います
これだべ？
10倍遅いは誤解を招くべ
70:名前は開発中のものです。
12/11/27 11:38:25.25 JayK2jV6
それだ
うろ覚えだったわ
でも関数によってはまだまだ数倍高速化できるのは事実
描画関係じゃなくね
71:名前は開発中のものです。
12/11/27 11:49:37.42 f5qtpDPQ
描画関係以外で速度求めるって一体どんな関数使ってんだよ…
72:名前は開発中のものです。
12/11/27 11:58:08.94 JayK2jV6
1フレームに数千回呼び出す関数なんかはエラーチェックでかなり処理食われたりするよ
多数のオブジェクトに別々の動作をさせるようなプログラムだとたまに起こる
73:名前は開発中のものです。
12/11/27 12:06:38.69 f5qtpDPQ
いや…自分で定義した関数ならともかく、DXライブラリの関数で数千回とか何やっとるん…？
74:名前は開発中のものです。
12/11/27 12:25:04.10 JayK2jV6
想像できないなら想像できないでいいと思うよ
75:名前は開発中のものです。
12/11/27 12:56:42.07 ByhNS8r3
性格悪っ！
76:名前は開発中のものです。
12/11/27 13:02:12.23 JayK2jV6
だってめんどくさそうな人だから相手したくないんだもん
77:名前は開発中のものです。
12/11/27 13:16:49.74 ByhNS8r3
だったら無視すればいいだけ！
78:名前は開発中のものです。
12/11/27 13:17:22.16 6Mv2IZhC
アホす
79:名前は開発中のものです。
12/11/27 13:32:11.78 LIfIJ6xQ
自演まるわかり
80:名前は開発中のものです。
12/11/27 18:06:28.14 SSSMeP/t
プログラマブルシェーダー２．０を使用できる環境では通常の描画処理にも
ピクセルシェーダーを使用するように処理を変更。
81:名前は開発中のものです。
12/11/27 18:27:43.01 n5lQqkP/
DXlibがソースそのままでWindowsStore用のアプリ生成出来ればええな
昔作った奴いつくかそんなに日本語部分多くないから英語でリリースして
外人さんの感想聞きたい
82:名前は開発中のものです。
12/11/27 18:59:23.43 Y6tGCz/D
まず海外のフリゲ公開サイトにでも登録してみたら
83:名前は開発中のものです。
12/11/27 22:32:16.92 TGtbuLIb
>>81
すぐには無理でしょ。
.ＤｘｌｉｂがNETベースのC++/CLIかC#あたりに移植されれば別だが。
当然、自分のゲームソースも同じようにC++/CLIかC#に移植になるけど。
84:名前は開発中のものです。
12/11/28 00:14:38.58 9BuN3YHL
更新されてたんで久々に更新したら
SetCreateDrawValidGraphChannelNumでチャンネル数2で良かったものが3必要になってた
85:名前は開発中のものです。
12/11/28 14:16:31.64 YnS7DAU9
DXライブラリのソース追っていくのすげーきついな
86:名前は開発中のものです。
12/11/29 20:45:23.29 cXkL+nrF
ちょっとお前らの経験則から助言いただきたいんだけど、筋力から物理攻撃力を求める時みたいに
元の数値さえあれば格納しておかなくても計算で導き出せるような項目をわざわざ格納しようかなと
思ってしまう 計算の複雑さ×使用頻度 の目安ってどんなもん？
そういう数値は格納したら格納したで整合性を保つための更新タイミングも考えなくちゃいけないけど
そういう手間も加味して評価するよね、こっちは管理者が更新するようにして解決しようと思うけど
87:名前は開発中のものです。
12/11/29 21:03:47.74 GNB73dnr
何を言ってるかよく良く解らんが、
全てを最新状態に更新する処理を作っておいて、
装備を変えるときとかにそれを呼び出せばいいんちゃう？
（デバフ喰らったりしたときとかはまた別になるのかもしれんけど）
新しい項目を追加したりした時その方が変更楽じゃない？
でもDXライブラリと関係ないよね。
88:名前は開発中のものです。
12/11/29 22:52:50.84 fLuPtmdH
>>86
外部ファイルやらDBやらを使ったり、算出にランダム要素などが加わるならキャッシュする。
そうでなければ気にしないかなあ。
89:名前は開発中のものです。
12/11/29 23:29:10.33 JG9/8B69
俺はそういう場合、キャラクラスですべて管理するようにしておいて、
実数値もメンバとして用意しつつ、変化と再計算もメンバ関数にする
アイテムを装備する場合とか能力変化技を受ける場合、そのキャラの装備関数能力変化関数を呼ばせる
その中で毎回再計算関数を呼べば数値は常に最新になるし
そもそも実数値をほとんど使わないとしても、格納しておかないと、規模が大きいゲームになってくるとデバッグが面倒になったりする
90:名前は開発中のものです。
12/11/30 21:55:18.56 d5cNZMEM
環境によって作成できる最小テクスチャサイズってあるのかな
MakeScreen(8, 8, TRUE)
と小さい画像作ったんだけど、テクスチャ幅が8以下の画像だと
初期化もされないうえにClearDrawScreenをやってもクリアされないっぽくゴミが残る
これより一回り大きい幅16になるとゴミも消えてくれる
91:名前は開発中のものです。
12/11/30 22:41:41.07 oui3MhFc
>>87-89
ｻﾝｸｽ。とりあえずインターフェイスを計算結果側の項目に絞っておけば
後からどっちにも対応できて良さそうだね
92:名前は開発中のものです。
12/12/01 13:33:46.23 IBe3OiN8
初心者です。画像表示のためのラッパクラスを作っていて
画像ハンドルと、DxLibのDrawRotaGraph3の引数と同じ項目（描画位置以外）をメンバ変数として持ち
各メンバに値をSetした後にDraw(int x, int y)で描画できるようにする予定なのですが、
拡大率が1.0倍で回転角度も0度のような、DrawRotaGraph3を使わずともDrawGraphで描画可能な場合、
やはりDrawGraphを使って描画した方が処理が速いのでしょうか？
93:名前は開発中のものです。
12/12/01 14:35:16.76 b+EQ3+6O
速度のことは必要になるまで考えるな
以上
94:90
12/12/01 15:57:16.54 xUkutrV6
自己解決した
ListUpTexSize関数内で、２のｎ乗ではなくて良い場合の条件に合致するとき
最小サイズ未満の場合が抜けていたのがうまくいかない理由だった
MIN_TEXTURE_SIZEで最小サイズを変更できるけど上記の部分も変更しないと
最小サイズが適用されないことがある
95:名前は開発中のものです。
12/12/01 23:49:15.26 IBe3OiN8
>>93
確かに。とにかく突き進んでみます
96:名前は開発中のものです。
12/12/05 07:28:58.56 dxKlQPoH
MV1SetMaterialTypeってトゥーン表示に出来るみたいだけど
リファレンスに乗ってない？使い方が分からない…
97:名前は開発中のものです。
12/12/05 10:07:53.76 cfYtyBWt
プロローグによくあるような、画面上部にイラストがあって、下部に「むかしむかし、、、」みたいなかんじで文字をだしたりしようとおもってるんですけど、ああいうのってムービー作って再生させてるんですか？
実装しようとするとフェードインアウトとか結構手間がかかりそうで。
98:名前は開発中のものです。
12/12/05 10:12:25.17 5bbxrjLT
全然手間じゃない
フェードはフラグを用意しておいて、TRUEなら透明度が255になるまで毎フレーム増やす、FALSEなら透明度が0になるまで毎フレーム減らす、
みたいな感じに組めばすぐできる
そんなのでムービーにするのはバグや相性問題の元だからやめとけ
99:名前は開発中のものです。
12/12/05 11:06:07.54 ze777H3I
>>98
なるほどー。相性とかあるのか、、、。
わかりました。今日の夜やってみます。
100:名前は開発中のものです。
12/12/05 12:46:04.92 r3FoL9zZ
「画面上部にイラストがあって」の部分がよくわからないけど、ゲームのプロローグなんかは普通動画だよ。
背景に動画を流して、下に字幕被せてるだけ。
101:名前は開発中のものです。
12/12/05 12:50:44.41 5bbxrjLT
ヨッシーアイランドみたいなのだろ
アニメを流すなら動画だけど、単に静止画やドットアニメレベルならプログラムの方がいいと思う
プログラムで簡単に出来ることをわざわざ動画にして要領増やすのも馬鹿らしい
102:名前は開発中のものです。
12/12/05 14:12:16.87 JhztC1FO
上から黒い四角を重ねるだけでも、フェードイン/アウトにはなるしな。
103:名前は開発中のものです。
12/12/05 14:43:15.90 kPhWb69t
まずは完成させること優先で考えたら？
動画作りが得意なら動画で済ませておいて、後でやり直したくなったらやり直せばいいだけ。
プロじゃないんだから極力難しいことは避けても問題ない。
例えば作り直すタイミングで、もっとかっこいい3D動画にしよう！という新たな方向性に目覚める可能性も残せたりね。
でも完成させることよりプログラムの勉強が優先なら、ちょっと悩んでもやりたいと思った今プログラム組んでみたほうがいいと思う。
104:名前は開発中のものです。
12/12/05 15:49:01.40 lks+z0Wj
言われている通りでまさにヨッシーアイランドと同じような感じで作りたいと考えてました。
動画作成も興味はありますが、とりあえずプログラムでやってみます。
105:名前は開発中のものです。
12/12/05 16:11:07.03 8b/D9r5+
便乗してすごく初歩的な質問なんだけど>>98が普通に「透明度」って言葉使ってるけど
画像を表示するためのDrawGraph系の関数には透明度の指定がないから、
毎回SetDrawBlendModeでアルファ値を設定してから描画するって意味？
フェードの話だとマスク画像かもしれないけど、単純に画像に透明度を指定して
表示させたい場合はやっぱり↑の方法しかないんですか？
106:名前は開発中のものです。
12/12/05 17:05:02.24 d0fjoMgW
少なくとも俺はそうやってる。
107:名前は開発中のものです。
12/12/05 17:26:51.05 5bbxrjLT
>>105
そう
自前でSetDrawBlendModeしてからDrawGraphする関数を作ってもいい
108:名前は開発中のものです。
12/12/05 18:27:00.14 J7+ZDMKL
ライブラリを更にまとめた自前関数いいよね
109:名前は開発中のものです。
12/12/05 22:27:44.51 8b/D9r5+
>>106>>107
そうだよね、ふと不安になってしまった
>>108
Mintの人ってまだ生きてるのかな
110:名前は開発中のものです。
12/12/06 04:06:11.37 e4ZfE9+5
ついでだから俺も便乗させてもらうけど
パーティクルの描画をそれぞれに描画に必要なステータスをクラスのメンバで管理してて
いろんな種類のパーティクルを全部DrawPolygonIndexed3Dにステータスを当てはめて一括で描画してるんだけど
黒煙の表現とかに減算合成使いたいんだがSetDrawBlendMode使うと
管理の方法上パーティクル一つ一つの描画のたびにSetDrawBlendModeを呼び出すことになって
たかだか1000程度のパーティクル数で30fpsぐらいまで落ちる
管理人が昔、一括描画の最適化処理がSetDrawBlendModeの変更とかで途切れるから重たくなるって話を聞いたんだが
ここまで酷いもんなの？それとも他に原因がありそうだろうか
っていうか直接DrawPolygonIndexed3Dで減算みたいなこと出来ないかな
何かいい方法ない？
111:名前は開発中のものです。
12/12/06 07:31:49.70 lmRU6WCg
ブレンドタイプごとにまとめて描画すればいいんじゃね
112:名前は開発中のものです。
12/12/06 08:27:40.98 M80gGcCN
普通に考えると何度もブレンドモードを切り替えるような設計が間違ってる
SetDrawBlendModeは現在のブレンドモードと同じなら変更しないようになってるので、できるだけ同じタイプのパーティクルの描画が続くようにするべき
クラスで管理してるのならソートは簡単なはず
組み合わせてる描画が通常描画なら、煙のエフェクトには減算なんて使うもんじゃないし、黒いパーティクルを用意して通常描画にするのもいい
もしくは、複数のパーティクルを一つにまとめて数を減らす
┌───┐
│ │
│ │
│ ● │
│ │
│ │
└───┘
↑みたいな画像を大量に描画するんじゃなく、
┌───┐
│● ● │
│ │
│ ● │
│ ● │
│ ● │
└───┘
↑みたいな画像にすれば見た目はあまり変わらず、パーティクルの数と描画負荷は1/5にできる
113:名前は開発中のものです。
12/12/06 20:04:35.05 hHiG3Evm
横槍っぽくてすまんがクラスのメンバにFlagを持たせる場合intとboolどっち使ってる？
個人的にはbool使いたいんだがDXライブラリのFlagがintだからどっちにしろムズ痒い
114:名前は開発中のものです。
12/12/06 20:52:41.59 LDGG4ruw
boolで、自動伸長にまかせる
115:名前は開発中のものです。
12/12/06 22:38:38.16 Kx+9UwDD
両方使えばいいやん
RPGツクールだってスイッチと変数あるで
116:名前は開発中のものです。
12/12/06 23:07:52.71 wwcN/NFR
>>115
今はそういう話じゃないと思うが・・・
117:名前は開発中のものです。
12/12/06 23:16:43.27 M80gGcCN
俺は大は小を兼ねるでintかな
特定の数値をエラー番号にできるし
118:名前は開発中のものです。
12/12/06 23:49:56.18 hHiG3Evm
どの道intでやってきてるから変更はしたくなかったんだけどね・・・
即レスで「boolしかねぇだろバカ」って言われたら踏み切ろうと思ってた、ありがとう
119:114
12/12/07 00:20:29.50 y/XfV8vE
なんか俺がマヌケだ
120:名前は開発中のものです。
12/12/07 07:25:26.94 ynWkr9Hy
自分はboolかなー。
三値以上、あるいはエラーコード等を考えてintにするなら、
どっちかっていうとenumとかにするべきのような気もするし。
121:名前は開発中のものです。
12/12/07 15:34:07.50 p7dlEACG
＞プログラマブルシェーダー２．０を使用できる環境では通常の描画処理にもピクセルシェーダーを使用するように処理を変更。
とあるけど、速度に対する影響ってどんなもんなんだろ
122:名前は開発中のものです。
12/12/08 21:10:34.48 O5Dwta97
t-potやなんかの簡単なhlslをdxlib用に移植することすらできねー
俺アホすぎオワタ
123:名前は開発中のものです。
12/12/08 21:24:01.42 3G4JIdgx
2Dでいいじゃないか
124:名前は開発中のものです。
12/12/08 21:27:11.89 S+fVZNT1
その2Dでもシェーダ使うけど？
125:名前は開発中のものです。
12/12/08 21:27:41.71 ON91ZUBN
DXライブラリのシェーダは仕様の制限がわかりにくい
126:名前は開発中のものです。
12/12/08 21:33:38.88 O5Dwta97
ライト方向の定数がワールドじゃなくビューなのがわからん
コンパイラも列オーダー強制で転置必要だし、他サイトのサンプルも俺の頭じゃ満足に動かせない
127:名前は開発中のものです。
12/12/08 21:48:07.56 3G4JIdgx
シェーダ使わなきゃいいじゃない
128:名前は開発中のものです。
12/12/09 14:53:19.13 /H4jWPeA
Paint文はちゃんと動く？
宣言だけで中身のない命令なのか
129:名前は開発中のものです。
12/12/09 18:13:29.91 ETEjY4yj
ライブラリにライト設定ってあるけどこれマテリアルの設定なんだよね
ゲームの影みたいには出来ない…射影法だっけ
130:名前は開発中のものです。
12/12/11 12:50:17.45 NIH2nzCF
2Dなんだけど、回転付きDrawBoxってあったっけ？
131:名前は開発中のものです。
12/12/11 13:10:27.88 TGP7768d
ない
DrawQuadrangleで代用するか、DrawQuadrangleを使って自分で用意べし
132:名前は開発中のものです。
12/12/11 13:34:33.28 NIH2nzCF
おお、ありがとう。
危うくDrawLineでせこせこ書くところだったぜ
133:名前は開発中のものです。
12/12/12 21:10:06.59 DG3DeyXN
Ver3.09にしたらフルスクリーン→ウィンドウの切り替えで
フルの画面が残る？んだけど同じ症状出てる人います？
134:名前は開発中のものです。
12/12/12 22:35:27.16 AZMXsYNg
DXライブラリはもう保守が限界に近づいてるんじゃないか
135:名前は開発中のものです。
12/12/12 23:11:17.68 QTcOfxsy
「フルの画面が残る」の意味がわからない。
136:名前は開発中のものです。
12/12/12 23:44:11.14 A3akQxx/
デスクトップ左上からフルスクリーン解像度分が黒く塗りつぶされた状態で残ってるってことだろ？
そういうのってビデオドライバのバグな気もするが
137:名前は開発中のものです。
12/12/13 00:00:51.12 7iuoyONB
3.09にしたら、って事はそれ以前のバージョンじゃなってなかったって事だよな。
バージョン戻して、ちゃんとなってるかどうか確認してみる必要があるんじゃないか。
138:名前は開発中のものです。
12/12/13 00:37:01.54 dHHXSXFg
>>135 >>136
直前まで表示されてた画面がそのまま表示されっぱなしになってます
裏でウィンドウに触れたりは出来るんですが
>>137
3.08eに戻すと大丈夫です
もうちょっと調べてみます
139:名前は開発中のものです。
12/12/13 09:33:31.24 eCbS15Yt
俺もテストプレイしてもらった人から、ウィンドウモードで表示されない（他にも異状はある）という報告をもらった。
（133とは現象違うし、旧バージョンでも起こるようだが）
Win7で発生してXPでは発生しないという事らしいが、133のOSは何使ってるの？
このままじゃWin7は対象外って事になってしまう……。
140:名前は開発中のものです。
12/12/13 09:34:21.64 eCbS15Yt
あ、「ウィンドウモードで表示されない」じゃなくて「フルスクリーンモードで～」でした。
141:133
12/12/13 14:20:52.98 dHHXSXFg
>>139
開発は8ですね
症状自体は7とVISTAでも再現するのを確認してます
XPは手元に無いのでまだですが
142:名前は開発中のものです。
12/12/13 16:11:18.90 RivcO0oI
反転のブレンドモードで描画すると設定した透過色が
透過されないんだけど仕様かな？
143:テルマの代行
12/12/13 16:41:44.29 Ib1R9I8O
139のはグラフィック復帰書いたりしてるの？
出来ないなら「フルスクリーンには対応してません」でいいじゃん。
133のはビデオドライバっぽいな。
8にアップした後に8用のドライバにアップして、
カスタマイズせず「工場出荷時の設定」などでテストしてるだろうか？
俺の環境ではウィンドウフルスクリーンの切り替えでまったく正常だ。
144:139
12/12/13 17:44:23.56 eCbS15Yt
>>143
もちろんグラフィック復帰は書いてるよ。
今ではDXライブラリで自動復帰とかできるみたいだけど
そうなる以前に書いた自力でグラフィック復帰させてるソースだからその点は間違いない。
前述したように「他にも異状がある」ので「フルスクリーンに対応してません」ではちょっと済ませられないかも。
プログラム自体とは関係なさげな異状だから、俺のバグではないと思うんだが……。
なんにしてももっと調査が必要だわ。
145:133
12/12/13 18:02:50.39 dHHXSXFg
>>143
正常との報告ありがとうございます
8とVISTAが別環境なので疑ってなかったのですがドライバ周りも探ってみようと思います
146:名前は開発中のものです。
12/12/13 18:37:57.92 g4qmaU43
ドライバ問題かどうかはSDKのsimplesampleあたり試せばすぐ分かりそうだけどね
前バージョンで動いていたのなら可能性としてすごく低いと思うけど。
今更だけど本体の更新でコアな部分に手を加える前に
最新版と安定版に分けてくれていたらなあ
147:名前は開発中のものです。
12/12/13 19:37:53.29 Jp8gIPXB
とりあえず、バージョンの違いでおかしいなと思ったら、
まず↓で3.09とか3.08eとか自分の使ってるバージョン番号で検索してみたらいい
そうでなくてもとりあえずどういう問題が報告されてるか知っておくのはいいと思う
URLﾘﾝｸ(hpcgi2.nifty.com)
148:133
12/12/15 14:48:25.74 4z8W5i5N
いろいろ調べた結果、どうやらVC#用3.09だけで起こる問題っぽいです
とりあえずVC++用3.09だと大丈夫でした
C#用は変換ソフト使ってるとのことなのでおかしくなる事もあるんですかね…
あとで公式に投げておこうと思います
アドバイス等々ありがとうございました
149:名前は開発中のものです。
12/12/17 19:07:19.03 9yI3pxiI
DerivationGraphって非同期読み込みの対象外なんだな
これも対象にしてくれても良かったと思うんだけど
150:名前は開発中のものです。
12/12/17 19:10:24.52 9yI3pxiI
実際には読み込み用じゃないから仕方がないか
ああ、作り直さなきゃ
151:名前は開発中のものです。
12/12/23 19:39:35.16 UDpOJxNp
質問。
DXlibでゲーム作る傍ら、同じくDXlibでそれ用のツールも作り始めたのですが、
1画面に収めるにはレイアウト的に無駄が多いので複数ウインドウで1アプリに
したいのだけれど、DXlibはその機能を提供せず。
Windowsの機能を直接利用するしかなさそうなのでその線で考えているのですが、
良い手本や資料ってありますか？
152:名前は開発中のものです。
12/12/23 20:04:54.75 DyE9bJRU
WIN32APIで検索すれば講座サイトたくさんヒットすると思う
ついでにDxLibに頼らなくてもそこそこやれるくらいの知識を身に付けるつもりでやると良いかもね
153:名前は開発中のものです。
12/12/23 20:06:21.24 DyE9bJRU
あーあとそれとはまた別の話になるけど
エディタを作るならC++じゃなくてC#やVBがラクだと思うしその知識は無駄にならないと思う
WIN32とか基礎からやろうと思うと勉強意欲がガシガシ削られかねない
154:151
12/12/23 22:16:09.12 UDpOJxNp
助言ありがとうございます。
確かにAPI叩きが身に付けば天下無敵なのですが。
身に付けるのにどれだけ時間掛かるかなあ（＾＾；
私はCがおぼつかない程度の実力で2010EXPRESS使っています。
VBはともかくC＃ですか。
今まで考慮に入れた事なかったので少し資料あたってみます。
そちらから突破口考えてみます。
ありがとうございました。
155:名前は開発中のものです。
12/12/23 22:31:08.73 cXg0KV/e
Ｃ＃なんかマウス操作で部品はっつけて、
ボタン押されたときの処理とかを書くだけで出来上がり
156:名前は開発中のものです。
12/12/23 22:42:08.45 fCnMZAgY
うん、だから簡単なツール作るのに使う人が多いね