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

1 ：11/08/18 〜 最終レス ：11/11/21

Cを習得した程度のスキルでも、
GUIのゲームを比較的容易に作成する事を可能にする、
「DXライブラリ」に関するスレッドです。
DXライブラリに関するテクニックなどの情報交換などを行う事で、
多くのDXライブラリユーザのスキルの向上に役立てたら幸いです。
【公式】
http://homepage2.nifty.com/natupaji/DxLib/
【過去スレ】
DXライブラリ 総合スレッド
http://pc11.2ch.net/test/read.cgi/gamedev/1197468399/
DXライブラリ 総合スレッド 2008
http://pc11.2ch.net/test/read.cgi/gamedev/1224923873/
DXライブラリ 総合スレッド その3
http://pc11.2ch.net/test/read.cgi/gamedev/1238429676/
DXライブラリ 総合スレッド その4
http://pc11.2ch.net/test/read.cgi/gamedev/1249822550/
DXライブラリ 総合スレッド その5
http://pc11.2ch.net/test/read.cgi/gamedev/1259912953/
DXライブラリ 総合スレッド その6
http://hibari.2ch.net/test/read.cgi/gamedev/1267108154/
DXライブラリ 総合スレッド その7
http://hibari.2ch.net/test/read.cgi/gamedev/1286180687/
DXライブラリ 総合スレッド その8
http://hibari.2ch.net/test/read.cgi/gamedev/1301818631/
DXライブラリ 総合スレッド その9
http://hibari.2ch.net/test/read.cgi/gamedev/1310904069/

2 ：

某所に盛大に誤爆してしまったのは内緒

3 ：

乙！

4 ：

>>1乙

5 ：

乙であります！

6 ：

ビット演算知ってるけど、取っつきにくくて、やったことなかった！
ビット演算楽しすぎｗｗｗｗｗ
つか、DXライブラリって知らない間に3D機能ついてたのね
2Dの頃、触ってたけど、まったく分からんかったわ！
今は、普通にわかる様になって少し感動

7 ：

公式掲示板荒らされてる・・・

8 ：

こわっ！

9 ：

うわ……

10 ：

うわー
ここで暴れてた基地害かな

11 ：

クラスが一つのファイルに１つ存在するものなら、ヘッダーファイルとソースファイルのセットと
同じような役割果たしてんじゃないか？
C++では構造体の中に関数も入れられるし、プログラミングの本質的なところは
Cと何も変わらないし、つまりCとC++の差はほとんどなかったということになる
クラスを使うか使わないか、ただそれだけだった

12 ：

ほんの入口に立っただけで何ドヤ顔してるんだ

13 ：

ヘッダーファイルとソースファイルのセットをモジュールとして考えられない人のためにクラスが作られた

14 ：

aaaa

15 ：

ようやく規制解除されたわ

16 ：

巧さんも大変だな

17 ：

管理人さんが動いたのか。ほんと大変だ

18 ：

現行ログ全滅か

19 ：

なにがあったんだ？

20 ：

過去ログってとこクリックしたら見れるみたいだけど、
そこにはないスレもあったのかな

21 ：

というか過去ログも減ってないか？
調整中なのかな

22 ：

つかわざわざあんな分かり辛い書き方するの意味あんの

23 ：

自分でも質問、回答保存しとかないとな、何が起こるかわからんね

24 ：

そもそもの存在を知らなかった

25 ：

存在も知らないってのは流石にもったいない
流し読みするだけでも有用な情報がかなり転がってるぞ。あの掲示板

26 ：

管理人が組んでくれた独自関数とか乗ってたりするしな

27 ：

DXライブラリは2Dゲームに使うのにかなり評判いいけど3Dはどうなんだろう。
DXライブラリで作られたフル3Dのゲームを見たことがないんだけども制作してる方いるかな？
それともやっぱり他ライブラリが優勢ですかね。

28 ：

ニコニコとかなら、いくつか

29 ：

その話題秋田

30 ：

3Dゲーム作るのにもかなり使いやすいよ
他のライブラリは余計な機能がゴタゴタついてたり、数値の指定がライブラリの独自仕様になってたりするけど、
DXライブラリは余計な機能がないし、座標がイメージしやすいから、2Dの機能を使いこなせてるレベルなら同じ感覚で3Dもいける

31 ：

糞機能しかないけど
制限の大きさがそれはそれで楽しめる
RPGツクールでアクションつくるようなもん

32 ：

荒らしが本家アク禁されて戻ってきたのか

33 ：

もう少し3Dに興味がわく関数追加してほしいと思う
今のままなら3D使わなくても2Dだけでいいやってなる

34 ：

メタセコイアーーーーーーーーー

35 ：

Seleneだっけ？あっちを使えばいいんじゃね
君には選ぶ自由がある

36 ：

>>33
CryEngineでも使っとけよ

37 ：

DrawBoxで描いた四角を透過したいんだけど、
SetDrawBlendModeを使うと描いた四角以外の部分も色が変わってしまう。
DrawBoxで描いた四角の部分だけを透過する方法はないですか？

38 ：

DrawBoxで描く前にSetDrawBlendModeで透過させて、描いたあとに同じくSetDrawBlendModeで透過解除させる。

39 ：

>>38
使い方の問題だけでしたか。
ありがとう。

40 ：

描画モード変更系は永続だからな

41 ：

仕様として標準値を決めておいて、もし変えたら終わったあとに戻すのがよいよ

42 ：

画像クラスに透明度も突っ込んじゃうと楽よね。

43 ：

透明度というか、描画関連情報を全部突っ込むと便利だな

44 ：

DrawBoxをラッピングしてalphaを引数で与えればいい
オーバーロードで引数無しの場合は0xffを与えればいい

45 ：

皆マスク関数とか使ってるの？
俺たまにマスク使いたくなるけど、リファレンツに出力がどうのこうの
って書いてあるから躊躇してしまう

46 ：

>>45
画面四分割する時に使ったことある

47 ：

便利なのかもしれないが使う機会はないな。
画面分割はやったことあるけど、矩形だったからSetDrawAreaで充分だったし。

48 ：

http://d.hatena.ne.jp/thk/20110530
あるんじゃないかとは思ってたけど
商業でDXライブラリ使ってるという話は始めて聞いた。
しかもこの人によると、割と使ってるところあるみたいね。
尤も、典型的な紙芝居ノベルっぽいから、それ専門のソフトとスクリプトで十分だとも思うが…

49 ：

RPGで敵をEnemyクラスとして扱おうとしています。
初期化処理において、
龍神録プログラミングのその11,エクセルを使って敵の出現データを作ってみよう、
を参考にして敵のIDに応じた各データメンバをcsvファイルから読み込ませようとしています。
他にもっと便利で修正しやすいよ、という方法ありましたらお教えください。

50 ：

それ以上を求めるなら自分で専用のツール作るしかないよ

51 ：

最近見つけてあんまり試してないけどSQLite+PupSQLiteとか面白そうだよ

52 ：

RapidXMLとか？

53 ：

敵にID振るのもいいけど敵PTのIDも作ったほうがいいんじゃ
敵が常に１体ならそれでいいだろうけど

54 ：

俺の場合は、敵編隊は、敵を発射する透明な敵オブジェクトでやってるなー
これなら敵として設置するだけで編隊を出してくれるから、同じようにステージに配置しやすい

55 ：

それってSTGの話？

56 ：

>>54はSTGの話だな。見た感じ
>>53
敵データと敵パーティーデータって普通は別扱いでやらね？

57 ：

>>52
「原理原則」や「机上の空論」を正論と思って賞賛してよいのは中学二年生まで

58 ：

普通がどうかは知らんが敵も敵編隊も弾も自機もエフェクトも全部同じ扱い、IDだけ変えてる
ファクトリメソッド使えるのならこのほうが楽

59 ：

RPGの話なのに何でSTGの話持ち出すのかイミフなんだが

60 ：

いつの間にかSTGの話にw

61 ：

おーすまない、けどRPGでも基本変わらん
エンカウントもイベント戦闘もその中での敵配置も同じ扱いでやったほうが楽

62 ：

>>56
敵が複数登場するようなゲームなら、
いくつかの敵IDの情報を持った敵パーティIDで抽選を行って、
その後、敵IDに応じたデータを読みこんでいけばいいんじゃないかなー
って思ったんだ

63 ：

ああ、RPGってのを見落としてたｗ

64 ：

>>62
ああ、俺が言いたかったのもそういうことｗ

65 ：

なんか俺素人すぎてif文が大量にあるから嫌になるな
多分完成した頃には重くて、容量でかいのができあがるんだろうな

66 ：

if文のコストは実は大したことない
乗算除算やループの方がずっと重い
実行ファイルの容量なんか気にする必要ないだろｗ

67 ：

スレどころか板違いだけど、if文を自動生成するプログラムを見たときは衝撃が走ったぜ…

68 ：

じゃあソースにあるループ文を全てアンロールするプログラムを

69 ：

前なんかこのスレの風潮でif文は糞みたいな流れがあったぞ
if文の条件を多くするってのは、条件一つにつきif文+1って感じなのか？

70 ：

当たり判定のやつ？
あれも実際は効果あるか怪しそうだけど

71 ：

>>69
このスレで糞糞言う奴の言葉とか全くあてにならんよ
if文の問題点はコードの見通しが悪くなることと仕様変更時に面倒くさいこと
利点は言うまでもないけど早く組めること
利点と問題点を理解して自分にあったスタイルで組めばいいと思う

72 ：

DrawGraphでの描画速度に限界を感じてきました。
そこでDrawPrimitive2D及びDrawPrimitiveIndexed2Dを使えば
速くなるのでは無いかと考えたのですが、使い方が探しても
見つからなくて困っています。
これらの関数でテクスチャを表示する方法をどなたかご教授
いただけないでしょうか。

73 ：

俺知ってるけどスレ違いだから教えない

74 ：

ライブラリ変えるかDirectX直接叩いた方がいいような気がしないでもない

75 ：

スレ違いでもないけど、教えるのは難しいな
昔は公式なリファレンスがあったんだっけ？
とりあえず↓をDXライブラリの関数に置き換えて読めば概要はわかるはず　これで理解できなかったら使う事自体おすすめしない
http://www.c3.club.kyutech.ac.jp/gamewiki/index.php?DrawPrimitive

76 ：

>>74
DXライブラリは概ね使いやすくて非常に気に入ってるので、あと描画速度を
もう少し何とかできればという感じなのですよね。
>>75
ありがとうございます。
構造体のメンバも同じですし、DirectXの情報を追えばなんとかなりそうですね。
頑張ってみます！

77 ：

てかDrawGraphで重いって一体どういう状況なんだろう
弾幕STGで、弾毎に頂点カラーで色を決めてるとかそういう感じ……？
ブレンドカラーの変更処理ってデフォだとエラーチェックが入るからフレーム毎に1000回くらいで重くなるし

78 ：

>>77
マップチップの描画処理です。
640*480に16*16のチップを3レイヤー分敷き詰めるとチップ無し
のマスもあるので平均して1500くらいの回数に。
で、内蔵グラフィックボードだと60fpsを割ったり割らなかったり。
一応透過pngをLoadDivGraphで読み込んだものを描画してるので
SetDrawBlendModeとかはしてないです。

79 ：

マップチップ画像のサイズは？

80 ：

>>79
4096*768でARGB32の2.52MBのpngファイルです。

81 ：

1500ねぇ。オンボだと確かに微妙な数字だな

82 ：

試しに256*256とかにしてみたら高速にならんかね

83 ：

マップチップだったのか
マップチップの最適な描画法ってある気がするんだけどなー

84 ：

全部16*16でやるんじゃなくて、形が決まってるものは大きいサイズで描画するとか
あとバッファをうまく利用するとか
何とか描画回数を減らすように工夫するのがまず必要だと思う
全部16*16ってのはかなり非効率的だし

85 ：

俺は全然描画に対して不便感じたことないけどな
重かったのは俺が、ミスって毎ゲームループごとにLoadGraphしてた時だった

86 ：

例えば、草原や床のようなフィルする機会の多いチップは2*2,4*4のような大きいサイズを作っておく
ソースから2*2のような形をそのまま持ってくる場合はその都度Derivationする
カリングする（上のレイヤによって完全に塗りつぶされる場合は描画しない）
など

87 ：

>>82
LoadDivGraphの速度は遅くなるけど、ハンドル取得後の描画には
影響しないんじゃないかと思ってましたがどうなんでしょう。
>>84
ですよね。大きな画像を作ってそれに最初にマップチップを全部
描画しておいて、その大きな画像を描画するというのも考えたの
ですが、なにぶんゲーム中に一部のチップだけ差し替えたりという
要素があるのでできれば全チップ舐めて描画したいなと。
でもよく考えるとチップ差し替え時に大きな画像の方にそのチップ
だけ上描ききすれば良いですね。

88 ：

俺も同じ事やった事あるな。
640*480で16*16のマップチップを３枚重ねるやつ。
透過pngじゃなかったけど結構負荷がかかった記憶がある。
んで、諦めて一番裏の背景は諦めて一枚絵にしてしまったり、
オプションで二枚目の背景も消せるようにしたりしたなぁ。
まだDXライブラリ使い始めの頃だったけど。
描画の前に重なり具合を調べて、見えなくなる部分は描画しないとかいう手もありかもしれない。

89 ：

>>87
画像サイズはVRAMとメインメモリでスワップが発生してるかどうかが問題かな
計算してみたら4096*768の32bitカラーで12MBの消費だから、それだけではスワップはしないと思うけど

90 ：

DXライブラリは内部的に同じテクスチャならある程度まとめ書きしてくれなかったっけ？
最大テクスチャサイズは2048x2048だっけな、オンボなら1024x1024ぐらいに抑えたほうがいいだろうけど
元画像を幾つかに分割してソート掛けときゃ気持ちぐらいは速くなるかもね

91 ：

>>90
そういえばそうだっけ
大きい画像は内部的に分割されるからまとめ描きがきかなくなる（と思う）ことを忘れてた

92 ：

なるほど、元画像の大きさが影響する可能性もあるんですね。
ちょっと1024*1024あたりに抑えたので試してみます。
あとやはり画像をまとめて1枚にしてしまおうかとも。
幸いにもアニメーションするマップチップは無いので。

93 ：

1024でもでかいと思うけどな

94 ：

でっかい描画可能テクスチャを用意して、シーン切替時にマップ全部描画して、
マップ移動時はその中から描画したいとこだけを描画するってどうだろう
アニメーションするチップがあるなら工夫必要だけど、これが最速な気がする

95 ：

低スペックＰＣなんか切り捨てればええんや

96 ：

>>94
フィールドみたいにサイズがでかすぎるとVRAMから溢れそう
描画可能テクスチャに1画面分描画して、スクロールが発生する時に
スクロール先の部分を描画可能テクスチャに1ライン描画するとかどうだろう
プライマリサーフェスに転送する場合はxオフセットとyオフセットを設定すれば、
描画可能テクスチャ1枚で足りるし、描画時に4転送で済む

97 ：

それスクロールするときに描画可能テクスチャ？を全描画しなおさないといけないんじゃないの？
オフセットだけだとはみ出すよね俺間違ってる？

98 ：

>>97
うーん、説明しづらいから分かりにくくてすまんｗ
スクロールするときにスクロールアウトする部分に1ライン描画するって言う意味
そうすると描画可能テクスチャは頂点がスクロールした方向に1ラインずれる
つまり、最初の状態で0〜100を1回描画だとすると、5ラインスクロールしたら5〜100＋0〜4の2回描画になるって具合
この場合オフセットは5ライン目
スクロールによるずれがx方向とy方向で生じるから、通常は都合4回の描画になる
実際にはスクロールする時のために上下左右に1ライン分のマージンが必要だけど

99 ：

つまり、描画可能テクスチャの初期状態が
00,01,02,03,04,05
10,11,12,13,14,15
20,21,22,23,24,25
30,31,32,33,34,35
40,41,42,43,44,45
50,51,52,53,54,55
で右にスクロールすると、描画可能テクスチャは左1ラインがスクロールアウトするから上書きして
06,01,02,03,04,05
16,11,12,13,14,15
26,21,22,23,24,25
36,31,32,33,34,35
46,41,42,43,44,45
56,51,52,53,54,55
って形になる。バックバッファに転送するときは最初に01~55を左詰めで転送し、次に06~56を転送

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲