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

**名前は開発中のものです。** · 2010/02/25(木) 23:29:14

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/

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

アイデアが入ってないとかマヌケ過ぎるぞ
基本、アイデアがすべてだと思っている

**名前は開発中のものです。** · 2010/04/10(土) 16:12:38

>>383
いろんな名作を研究するのは確かに良ゲー制作の助けにはなるかもしれんが、別に必須というわけではない
マリオやカービィ等、黎明期の名作は手本なんてなかった

**名前は開発中のものです。** · 2010/04/10(土) 17:21:15

>>384
アイデアは列挙するまでもない大前提だろう。
そのアイデアを生むための下敷として、いろんなものが必要。
ああ、ゲームの知識と経験と努力だけじゃ足りなかった。
世の中のいろんな事、いろんな物の知識と経験と努力も要るな。
ヒキコモリの世間知らずは何も産めないし、何も作れない。

>>385
その手本が無いと言う根拠は？
似たゲームが無いと言う浅慮からだとしたら、
おいおいとしか言いようが無いけれど。

まぁ最早スレ違いだし、めんどくさくなってきたのでもうやめる。

**名前は開発中のものです。** · 2010/04/10(土) 17:25:18

>>386
根拠も何もあの時代に手本となるゲームなんてなかっただろ…
ゆとりか？

**名前は開発中のものです。** · 2010/04/10(土) 17:34:11

ゲームの手本はなくてもゲーム以外の手本はありそうな気も

割りきってシンプルな素材作るかー

**名前は開発中のものです。** · 2010/04/10(土) 18:56:46

ゼルダは宮本茂が
少年時代に野山を探検してまわった経験が
アイデアの元だって、なんかで読んだな

てか、一般化しようとしたって難しい話題だなこれ

**名前は開発中のものです。** · 2010/04/10(土) 20:42:05

カービィの桜井は今でも他の作品やりまくってるわけだが

**名前は開発中のものです。** · 2010/04/11(日) 10:35:58

君たち青春だねェ！

**名前は開発中のものです。** · 2010/04/12(月) 14:30:38

画面からはみ出た部分(マップや敵など)は、描画処理もされているんでしょうか？
もしされているなら条件分岐させて非描画にさせようと思うのですが、
聞いたことも無いので自動でやってくれているんでしょうか

**名前は開発中のものです。** · 2010/04/12(月) 16:18:16

>>392
描画範囲外への描画処理について
ttp://hpcgi2.nifty.com/natupaji/bbs/patio.cgi?mode=view&no=923

**名前は開発中のものです。** · 2010/04/12(月) 20:05:54

>>393
わ、すんませんありがとうございます

**名前は開発中のものです。** · 2010/04/13(火) 17:15:19

DXlibに限った話じゃないんで恐縮ですが質問です
屋内のMAPで3Dアクションを作る場合、例えば平屋の一戸建てを

１．建物全部のモデルを作成しておいて一度に読み込ませる
２．パーツごと（壁、床など）にモデルを作成して描画位置を指定しておく

全体の作業量に差は無いんだけど作業工程が大幅に変わるので悩んでます
SouceSDKなんかではbsp形式で一括、バイオシリーズなんかでは後者の様ですが

**名前は開発中のものです。** · 2010/04/13(火) 17:29:53

>>395
一度に読み込ませる方がシンプルで良いんじゃない？

>バイオシリーズなんかでは後者の様ですが
これどこ情報？

**395** · 2010/04/13(火) 18:49:13

>396
早速のご意見ありがとう！

かなり前ですが、海外のバイオMODフォーラムで拾った話です
PC版初代と2のモデルを抜くツールを作っている人がいまして
その使い方解説でその様な記述があったと記憶しています

デジタルロケのサンプルでも片面ポリの部品で舞台が構成されていたので
当時はインドア3Dゲームって全部そうやって作るもんなんだとおもってました

**名前は開発中のものです。** · 2010/04/13(火) 18:55:23

3Dは扱ったことないからわからんが
壁とか床のモデル使いまわしたほうがゲームが軽くなるんじゃないの？

**395** · 2010/04/13(火) 19:17:26

>398
リソースはある程度軽くなると思います。単純に描画処理だけなら差は微々たるものかと

ただ一括と部品を配列配置ではグラフィックメモリ使用量がかなり違うんじゃないか？とか
見た目が単調になるのを避けるのに結局リソースが増えるんじゃないか？とかでウジウジ

**名前は開発中のものです。** · 2010/04/13(火) 20:04:37

質問が漠然としていて答えづらい。
リソースって言ってるものを何処に持たすかで話しが変わってくるよ。
単純にメモリなのかそれともグラフィックボード上なのかとかね。

ＢＳＰマップの描画の話しならクリッピングから調べれば？

って話しだし

**名前は開発中のものです。** · 2010/04/13(火) 21:43:19

ツール作成がめんどくさそ

**名前は開発中のものです。** · 2010/04/16(金) 21:21:42

ふと疑問に思ったんだけど、LoadGraphとかがスレッドセーフじゃないのは知ってるけど、
boostとか使ってラップすれば割と簡単にスレッドセーフにできたりしない？
みんなそういう事やってるん？

**名前は開発中のものです。** · 2010/04/21(水) 20:48:58

RPGのタイトル画面などで、ウェイトをかけるにはどのような方法が良いでしょうか
newgame、loadgameなどを上下キーで選ぶとします
そのままだと上下を押すと一秒間に60回移動してしまいます
空のメインループを呼び出し、描画だけをするのでしょうか？

**名前は開発中のものです。** · 2010/04/21(水) 20:53:21

>>403
コントロールパネルのキーボードの設定項目をみて思いつかないか？

**名前は開発中のものです。** · 2010/04/21(水) 21:08:21

>>403
空のメインループだと、特定のタイミングでキーを押しても反応しないことがある。
実際に作ってみれば分かるが、これはかなりストレスが貯まる。

というわけで、一般的には

(1)矢印キーを押した瞬間にのみカーソルを動かす。
　あらかじめ直前のフレームにおける入力状態を保存しておけば、押した瞬間を検出できる。
　この検出処理自体はゲームの至る所で使用するので、タイトル画面に関わらず必ず作っておいた方が良い。

(2)ウェイト用のカウンタ変数を用意しておき、毎フレーム減らす。
　カウンタが0以下の時のみ、カーソルを動かす。その後、待機するフレーム数（1秒ウェイトなら60）をカウンタに代入する。
　キーを押しっぱなしで、かつカウンタが1以上なら、0になるまで毎フレーム1ずつ減らす。　
　キーが押されてなかったら、カウンタを0にする。

という、どちらかのパターンになると思う。
(1)はキーを連打することでカーソルを動かす、(2)は押しっぱなしでカーソルが動く。
(1)と(2)を組み合わせた方法とかもあるけど、それに関しては割愛。

>>404
キーボードじゃなくてゲームコントローラじゃね？ OSによって違うかもしれないけど

**名前は開発中のものです。** · 2010/04/21(水) 21:13:04

>>403
何も思いつかないです。。。
>>405
なるほどー、ありがとうございます

**名前は開発中のものです。** · 2010/04/21(水) 21:15:43

直前のキーの状態の保存の処理をキーの状態に変化がなくても毎フレームやってもいいの？使うキーが多いと無駄にＣＰＵ資源を使うような

**名前は開発中のものです。** · 2010/04/21(水) 21:21:09

パフォーマンスチューニングで一番大切なのは細かいことを気にしないこと

**名前は開発中のものです。** · 2010/04/21(水) 21:26:58

>>408
それにしても細かすぎるだろｗ

**名前は開発中のものです。** · 2010/04/21(水) 21:30:42

キーの状態の取得なんかカスみたいなもんだからどうでもいいよ
実際にゲームとして動く段階になってそんなところがボトルネックになるなんてありえない

**名前は開発中のものです。** · 2010/04/21(水) 22:17:42

そんなこと気にするならキーが押されてる間、
カーソルの移動する処理と一緒にウェイトいれとけば

**名前は開発中のものです。** · 2010/04/21(水) 22:35:41

>>407
人間だって直前の状態から変化がなければ何もせず、
エロいことが発生すれば勃起するという判定を無意識に毎フレーム行っているが大した負荷ではない

**名前は開発中のものです。** · 2010/04/21(水) 23:22:40

直前のキーの状態の保存の処理程度でＣＰＵ資源気にするようじゃあゲーム自体作れないｗ

**名前は開発中のものです。** · 2010/04/21(水) 23:52:50

なんでC#用の奴は
ｄｌｌファイルやcsファイルでも元の関数名のままなのに
C#で使う場合にDX.を頭に付けなきゃ使えないんだろう？
どこでこういうことが決められてるんだろう？
弄って直せないレベル？

**名前は開発中のものです。** · 2010/04/22(木) 03:54:35

若いころはアイデアがわくが　技術がたらない
年取ると　技術があるが　作りたいゲームのねたがわかない
（トシ　トッターナ　フランス画家）

**名前は開発中のものです。** · 2010/04/22(木) 07:40:35

>>414
public static class DX ← DxDLL.csのコレじゃない？

**名前は開発中のものです。** · 2010/04/22(木) 08:53:49

どこでってC#の言語仕様としか言いようがない。

**名前は開発中のものです。** · 2010/04/22(木) 14:48:16

自分はC++からしか使ったことがないけど、先頭の DxLib:: を強制するようにしてる。
ヘッダの一箇所いじるだけだし。

**名前は開発中のものです。** · 2010/04/22(木) 19:33:21

>>414
「DX.」無しに出来ないことはないが……

1. DXクラスを継承する
2. DXクラスの内部クラスにする

正直どちらも個人的にオススメできない。

**名前は開発中のものです。** · 2010/04/22(木) 22:09:41

DXライブラリってクラス分け無視して全部DXクラスにぶち込んでるよね

**名前は開発中のものです。** · 2010/04/22(木) 22:22:34

Cと同じように書きたいんだったらなんでC#なんか使ってるんだろう
そもそもC#使うんだったらDX.が面倒に感じるくらいに至るところで
DXライブラリの関数呼ぶような作りにはしたくないと考えるのが正常

**名前は開発中のものです。** · 2010/04/23(金) 03:08:33

>>414
DX.はあった方がC#には都合良いと思うが、コード補完機能があるわけだし
安全にDXLibの関数を呼び出せる

**名前は開発中のものです。** · 2010/04/23(金) 08:43:52

おまいらは、C++でDxLib::って使ってる？

**名前は開発中のものです。** · 2010/04/23(金) 08:55:13

VBでDxLib. ってやってる

**名前は開発中のものです。** · 2010/04/23(金) 10:05:29

>>423
ラップする時に使った

**名前は開発中のものです。** · 2010/04/23(金) 16:11:34

ボーン情報を持ってないモデル同士を関連付けるにはどうすればいいですか？
軸ベクトルと原点位置は親に従うから親クラスが持ってればいいかと思うけど
移動処理を必ず親側から先にやらないと分離しちゃうよね？

**426** · 2010/04/23(金) 16:33:55

うーむ・・・例えがいまいちかな
人が歩くパターンはボーン関係なく、アニメパターン通りのポリゴン読み込ませれば済むが
歩きながらクビだけ動かしたいときに
全部の動きのアニメパターン作るわけにいかないよね
フレームやメッシュを相対的に回転させるにも、原点や軸ベクトルが別途要るよね・・・
どうやってるの？

**名前は開発中のものです。** · 2010/04/23(金) 16:50:31

元で頭と胴体を分けりゃいいだろ。

**426** · 2010/04/23(金) 16:57:17

>>428
分けただけでは
体が上下しながら歩いてる最中に
頭だけ平行移動する

**名前は開発中のものです。** · 2010/04/23(金) 17:25:33

>>429
今、お前の胴体に頭は付いているか？

**名前は開発中のものです。** · 2010/04/23(金) 18:03:35

>>430
？
分けて同じアニメパターン再生しろと？
それで右向いたり左向いたり別のアニメパターンを用意するの？
答えにもなってない煽りほどアホっぽい

**名前は開発中のものです。** · 2010/04/23(金) 18:24:14

>>431
何言ってるんだ？

少しは頭使えよ……。

**名前は開発中のものです。** · 2010/04/23(金) 19:04:30

頭使えないからこんな阿呆な質問するんだろ

**名前は開発中のものです。** · 2010/04/23(金) 19:11:59

何も有益な情報は残さずに読むものを不快にさせるだけのレスをするやつは死ねばいいのにな

**名前は開発中のものです。** · 2010/04/23(金) 21:19:10

モーション付けするときに、体（首）の位置を変えなければいい。
頭は、体の位置から自分の位置を決める。
悩むことじゃないと思うんだけどな。

**名前は開発中のものです。** · 2010/04/23(金) 21:23:52

>>431
馬鹿発見

**名前は開発中のものです。** · 2010/04/23(金) 21:29:48

ちょっと荒れそうなところ申し訳ないんだけど

カメラの回転をしない２Dのクォータービューのマップを作るとしてさ
仮に立方体の単位ブロックを２次元的に並べると板ができるよね

この時手前にあるブロック以外のブロックは側面を隣のブロックの上面に上書きされてしまうよね

上書きされてしまう部分に書き込む位ならテクスチャのように元から上面だけのブロックを作ろうと思ったんだけど
この上面だけのブロックって結局元のブロックの側面を消しただけの代物で
ブロックの大きさをまったく変えてないんだけど効果あるのかな

極端な話
１００＊１００のサイズの画像内で10*10を残してそれ以外を透過してしまう場合と
透過せずに使う場合とではやはり負荷は変わりませんかという質問をしようと思ったけど馬鹿にされそうだし
試した方が早いから試してくるわ！

**名前は開発中のものです。** · 2010/04/23(金) 21:35:23

差はないんじゃないの
もしあったとしてもゲーム全体でみるとどう考えてもそれくらい有意な差にはならない

**名前は開発中のものです。** · 2010/04/23(金) 22:08:08

うん、試してみたら透過面積と負荷に関係は見られなかった。
当たり前だけど画像の大きさと負荷、それと透過フラグと負荷には関連が見られた。

なんとなくでクォータービューでマップ作ったらfps６０切るんだ
軽量作戦はいくつか考えてるけど結果からテクスチャ作戦はサイズ小さくしないと意味ないみたい

3Dの知識まったく無いけどつぎは新型画像表示のナントカプリミティブ作戦を試してみるわ！

**名前は開発中のものです。** · 2010/04/23(金) 22:18:26

ブロック画像を一つずつ別々のファイルにしてない?
まとめたら速くなるよ

**名前は開発中のものです。** · 2010/04/23(金) 22:31:32

別々でもメモリに読み込んじゃえば同じなんだと思ってた。
でもLoadDivGraphで配列にしてるよ！

**名前は開発中のものです。** · 2010/04/23(金) 23:13:53

>>435
>モーション付けするときに、体（首）の位置を変えなければいい。
なにその制約？知ったか乙

**名前は開発中のものです。** · 2010/04/25(日) 08:51:18

Visual Studio2010にしようと思っているんですが、
Visual Studio2010でDXライブラリは使えますか？

**名前は開発中のものです。** · 2010/04/25(日) 09:03:03

使えます

**名前は開発中のものです。** · 2010/04/28(水) 20:24:38

_beginthreadex関数でサブスレッド呼んでそっちで画像とかを読み込んでるんだけど数回に一回テクスチャの生成に失敗しましたとかログに出て死ぬんだけどなんでだろう
メインのスレッドはLoadingとか表示して待機させてる
さらに時々KERNEL_MODE_EXCEPTION_NOT_HANDLEDがnv4_disp.dllで発生して青画面になっちゃう

**名前は開発中のものです。** · 2010/04/28(水) 23:08:23

スレッドセーフじゃないからとか

**名前は開発中のものです。** · 2010/04/29(木) 03:07:22

一応サブのスレッドでLoadGraphによってアクセスする変数にはメインからは触らないようにしてる
別々のスレッドでLoadGraphとDrawGraphを同時に呼んでもどっちかが待つ仕様になってるらしい…
サブのスレッドでLoadGraphを呼んだ時にまれにテクスチャの生成に失敗してる

**名前は開発中のものです。** · 2010/04/29(木) 03:23:11

スレッドセーフじゃないから、動作自体が干渉するよ。そこらへん。
mutex使いな。

**名前は開発中のものです。** · 2010/04/29(木) 03:30:07

クリティカルセクションみたいなもんかな？勉強してくる

**名前は開発中のものです。** · 2010/04/29(木) 10:30:53

SetMultiThreadFlag( TRUE );使ってる？

**名前は開発中のものです。** · 2010/04/29(木) 13:28:46

>>450
その一行を足しただけでテクスチャ生成の失敗やブルースクリーンが全く発生しなくなった…

**名前は開発中のものです。** · 2010/04/29(木) 15:22:12

SetMultiThreadFlagだけじゃアクセス違反とかは完全に防げないんじゃなかったっけ。

**名前は開発中のものです。** · 2010/04/30(金) 10:56:10

ソースによってはエラーでたりでなかったりで運悪くでないままだと後で泣く

**名前は開発中のものです。** · 2010/04/30(金) 11:22:08

>>452 >>453
>>447がスレッド意識した組み方してるから動いてるんじゃないの
それともSetMultiThreadFlag( TRUE )はバグってて役に立たないのか？

**名前は開発中のものです。** · 2010/04/30(金) 11:26:52

フルスクリーンで表示して最小化した後戻すと画面が黒画になりますどうなってますか

**名前は開発中のものです。** · 2010/04/30(金) 12:08:47

①SetDrawScreenしなおす
②画像読み直す

**名前は開発中のものです。** · 2010/04/30(金) 12:14:25

①or②を実行するタイミングはどうやって知ればいいですか

**名前は開発中のものです。** · 2010/04/30(金) 13:13:07

ああ勘違いスマソ
最小化じゃなくてウィンドウ化と勘違いしてたわスマソｗ

**名前は開発中のものです。** · 2010/04/30(金) 13:18:26

別に解答は間違ってないよ
タイミングは最小化から復帰したことを知らせる関数があったはず

**名前は開発中のものです。** · 2010/04/30(金) 13:19:21

すいません。最小化というかalt+tabでのウィンドウ切り替えです。
あとフルスクリーンで起動してGetWindowModeFlagするとウィンドウ切り替え後もいつでも０しか返ってこないんですがどうなってますか

**名前は開発中のものです。** · 2010/04/30(金) 13:25:45

>>459
おお。関数名をずばりお願いします。

**名前は開発中のものです。** · 2010/04/30(金) 15:01:48

リファレンスはちゃんと探してみた？

**名前は開発中のものです。** · 2010/04/30(金) 15:46:31

>>461
めんどくさいからヤダ
本家掲示板の過去ログ漁れ

**名前は開発中のものです。** · 2010/04/30(金) 16:02:13

公式のリファレンスには載ってないようですね。隠れ関数というやつでしょうか。
つうかなんで最小化したら設定クリア＆画像読み込みし直しになる仕様になってるんだよマジめんどくせええ

**名前は開発中のものです。** · 2010/04/30(金) 16:13:59

それはDirectXかWindowsの作者に言うべき文句

http://hpcgi2.nifty.com/natupaji/bbs/patio.cgi?mode=past&no=349&p=4
これだな　復帰後に自動的に呼ぶ関数を登録出来るって奴だった

**名前は開発中のものです。** · 2010/04/30(金) 16:56:49

>>465
うおおお。フラグを立てるだけの関数を以下にセットして
フラグが立っていたら再設定処理を走らせるようにしたら復帰できました！
int SetRestoreShredPoint( void (*ShredPoint)( void ) ) ;

あなたま神ですありがとうありがとう。

**名前は開発中のものです。** · 2010/04/30(金) 17:42:11

ん？それ、たしか最新版付近で対応されたぞ？

**名前は開発中のものです。** · 2010/04/30(金) 17:44:11

みっけた。コレコレ。
>ChangeWindowMode や SetGraphMode を行った際に描画設定やグラフィック
>ハンドルを破棄するかどうかを設定する関数
>SetChangeScreenModeGraphicsSystemResetFlag の追加。

**名前は開発中のものです。** · 2010/04/30(金) 17:57:03

>>468
それ使ってんだけど、リセットさせないことで何か問題ある？
現状でもデフォルトでリセットされるのは
以前の仕様でハンドル復元するように作られてるものに合わせてであって
今現在作ってるならリセットさせないのがスタンダード？

**名前は開発中のものです。** · 2010/04/30(金) 22:03:36

独自形式の画像ファイルを読み込む場合は、コールバックを設定しなきゃダメだったよな。
今は違うんだっけ？

**名前は開発中のものです。** · 2010/05/01(土) 09:23:20

その独自形式が展開前のことなら
ハンドル消えないし読み込む必要なし

**名前は開発中のものです。** · 2010/05/01(土) 15:45:54

>>471
そうなのか。知らない間に細かい仕様も変わってたんだなあ。

**名前は開発中のものです。** · 2010/05/06(木) 22:39:08

画像の一部のみを透過させることは可能？

敵が倒れるときのエフェクトで、１ドットずつポツポツと消えるような感じを再現したいのだが・・・
なかなかいいアイデアが浮かばない。

**名前は開発中のものです。** · 2010/05/06(木) 22:43:16

SoftImageとか

**名前は開発中のものです。** · 2010/05/06(木) 22:46:02

ZBufferとか
ドットアニメなら普通は全部用意する

**名前は開発中のものです。** · 2010/05/07(金) 00:04:54

うーん、全部用意か・・・

**名前は開発中のものです。** · 2010/05/07(金) 00:22:38

背景の方の、（消える動きを表現した）ドット画像を全部用意して、
敵の画像の上にそれを上書き。

**名前は開発中のものです。** · 2010/05/07(金) 00:53:08

上書きじゃ透過はしなくないか・・・？
そのドット画像をマスクにしたら実現できるかもな

**名前は開発中のものです。** · 2010/05/07(金) 01:30:15

いや、敵キャラをボツボツと消えるようにするんじゃなくて、
敵キャラの上に背景と同色の絵を置いていく事で、敵キャラが消えるように見せかけたらどうか、
と言ってみただけだ。

全種の敵の消えるアニメを用意するより、背景のアニメを用意する方が少ないんじゃないかなと。
背景絵が固定なら、だが。

**473** · 2010/05/07(金) 02:06:16

ああ、そういうことね
だが背景はいろいろ変えるからその方法だと難しいな。

みんなレスありがとう、もう少し頑張る。

**名前は開発中のものです。** · 2010/05/08(土) 06:13:21

よくデザエモンとかでやった手法だなあｗ

**名前は開発中のものです。** · 2010/05/08(土) 13:34:25

マスクで出来そうに思える。
マスク使ったことないけど。

**名前は開発中のものです。** · 2010/05/08(土) 23:06:22

Visual Studio 2008で開発しているのですが、、コマンドラインでコンパイルすることはできますか。

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

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