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

**名前は開発中のものです。** · 2014/05/07(水) 19:44:28.30

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

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

【関連スレ】
C/C++ゲーム製作総合スレッド Part5
http://toro.2ch.net/test/read.cgi/gamedev/1389798031/
ゲームプログラムなら俺に聞け30
http://toro.2ch.net/test/read.cgi/tech/1388933972/

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

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

>>319
左上の座標＋物体のXサイズYサイズの情報があればそれで4点あるのと同じだろ（原点、原点+x、原点+y、原点+x+y）

その数値を使って重なった位置を求めるだけ

余計なおせっかいだが、マリオみたいなゲームなら地上側の下座標を原点として考えるのをおすすめする

**名前は開発中のものです。** · 2014/11/19(水) 17:21:35.64

>>321
>左上の座標＋物体のXサイズYサイズの情報があればそれで4点あるのと同じだろ（原点、原点+x、原点+y、原点+x+y）
あ、そうだった。ごめんごめん

>>320
＞あとはごまかしの技術
これも気になる、、というか>>312の方法はあんまりお薦めしないってこと？？

ID:XOzf+VjYは別のお薦め方法があるよってわけではない？
別に無いなら、>>310の概念図とあなたのくれた画像と>>312の内容で
進めてみようと思うんだけども。

**名前は開発中のものです。** · 2014/11/19(水) 17:29:56.75

アクションゲームを作りたいという前提で説明すると、
踏み付けとか体当たりというのは下や横への攻撃だから、
相手のどの面に当たったかじゃなくて、攻撃判定を特定方向に出すと考える。

自分も敵もキャラサイズより小さめのダメージ判定を持たせる。
ジャンプ下降中や体当たり中は、自分のダメージ判定をはみ出す形で、
足の位置や体側面に攻撃判定を作る。

**名前は開発中のものです。** · 2014/11/19(水) 17:32:33.82

連続書き込み引っかかったわ
>>322

>>312のはあたったオブジェクトが動いてた方向がわかるだけで、あたった面を判定する処理とは別だよ
斜めに動く物体があると高確率で誤判定する

ほぼ縦に動いてる物体同士が真横同士でぶつかった場合でも、>>312の方法だと縦に衝突したと判定される
俺の解説した方法で判定しきれない高速物体との衝突の時、補助として使うといい

ごまかしが必要というのは初心者向けの判定方法だから。厳密にやるとお前のレベルだと対応しきれない複雑な処理になる

**名前は開発中のものです。** · 2014/11/19(水) 17:39:25.95

Box2Dとかに丸投げするのはどうだろう

**名前は開発中のものです。** · 2014/11/19(水) 18:24:56.94

色々と意見が出てから言うのもなんだけど、
ジャンプアクションならアクション特化のエディターで作った方がいいと思う
俺はどうあってもC＋＋でゲーム制作技術を習得するんだ！とか、
既存のエディターではどうしても再現できない独創的な仕様がある！ってんでもない限りはね…

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

そんなん言ったら全部Unityでいいじゃん
個人的には、今だにこういうライブラリ使ってる人って実行ファイル全て手作りしたいというか、開発工程も楽しみたい人だと思うんだよね
「俺の考えた最高の神ゲー」の方向にベクトルが向いてない作業はやりたくないというかなんというか
エディタの学習コストだってバカには出来ないし、エディタが想定していること以上の事は出来ないしわけだし

**名前は開発中のものです。** · 2014/11/19(水) 20:14:48.98

うん、エディタは使いたく無いよ
今は、C++でがんばりたい。

ただ、>>324
＞>>312のはあたったオブジェクトが動いてた方向がわかるだけで、
＞あたった面を判定する処理とは別だよ、斜めに動く物体があると高確率で誤判定する

が気になってね。
俺のやろうとしてることはそんなに面倒なことなんだ？と。
キャラは16×16のサイズで作るんだが、1フレームの移動量もしれてる。
斜め同士で誤判定するかな？
最初にあたる場所って、必ず四面のうちのどこか一面じゃない？

**名前は開発中のものです。** · 2014/11/19(水) 20:55:19.20

当たった瞬間のキャラの方向計算して
角度範囲を区分けすりゃいいだけだろ

**名前は開発中のものです。** · 2014/11/20(木) 02:40:41.39

移動量は方向には関係ないから容赦なく誤判定するぞ
もっとハッキリいうと「正しい方法じゃない」

移動量が少しなら尚の事>>318で済ませるべき
面倒だとか言ってるが、ゲーム制作においてこの程度全然面倒なレベルじゃないぞ

普通にゲーム作ってりゃ、1ループは数千行以上になるからな

**名前は開発中のものです。** · 2014/11/20(木) 08:41:44.89

ここんとこDXライブラリ関係ない話ばっかでてないか？

**名前は開発中のものです。** · 2014/11/20(木) 19:36:33.97

自キャラと敵、それぞれに上半分、下半分の矩形を作って、

＼敵上下
自＼
上　　跳潰
下　　死跳

とかやったら良いんじゃね？

**名前は開発中のものです。** · 2014/11/21(金) 22:49:14.07

もっと単純に、矩形が衝突したら原点を比べて、
敵の原点より自機が上なら「踏み｝、同じか下なら「ヤラレ」
くらいの判定でいいんじゃないのかな

**名前は開発中のものです。** · 2014/11/22(土) 22:45:34.33

マリオだとそれプラス、縦の速度で判定範囲が変わる感じだね

**名前は開発中のものです。** · 2014/11/26(水) 23:22:57.28

天体の周りを回るロケットのシミュレータっぽいのをDXライブラリで作ろうと思って
ロケットのコックピットから進行方向前方を見た視点を実装したくなったんだけど、
1メートルくらいの至近距離から数万キロの彼方まで描画範囲に含めるのはやっぱり無理？

ワールド座標系の単位をメートルとみなして1メートル～10万キロまでの範囲を描画範囲にする
（SetCameraNearFarで手前クリップ距離を1、奥クリップ距離を10万×1000にする）と
Zバッファの精度が足りなくなって表示が破綻するし、そうかといって単位を1000キロとみなして
手前クリップ距離を100万分の1、奥クリップ距離を100くらいに設定すると今度は手前クリップ距離が
小さすぎてまたまた表示がおかしくなってしまう

超至近距離から超遠距離までの表示を破綻なく行わせるうまいやり方があれば教えてください

**名前は開発中のものです。** · 2014/11/27(木) 03:01:51.80

描画を複数回に分けてその描画結果を合成すりゃいいじゃん

**名前は開発中のものです。** · 2014/11/27(木) 07:13:48.90

>>336
レスｻﾝｸｽ
それって最初はロケットの近くだけを描画するようクリップ距離を設定して
その後遠くの天体だけを描画するようにクリップ距離を変更するってこと？

なにぶんDXライブラリに慣れてないので概念とどういう関数を使えばいいのかだけでも
教えてもらえるとありがたいです・・・

**名前は開発中のものです。** · 2014/11/27(木) 14:33:04.80

描画可能な画像ハンドルはMakeScreen関数で作成できる

**名前は開発中のものです。** · 2014/11/27(木) 18:34:12.41

数万キロの彼方を実装するのはともかく、
表示するだけならある程度以降はガワだけにした方がいいというのはある
重いではすまないとんでもない世界がそこにはある…

なおテキトーな尺を設定して数万キロと言い張る事もできる模様

**名前は開発中のものです。** · 2014/11/27(木) 20:48:52.28

では諸君に聞くがUnityが2ｄ対応の今なぜ使うのかということだ

**名前は開発中のものです。** · 2014/11/27(木) 21:14:59.42

宇宙にいけば光年単位で異動できるなｗ

**名前は開発中のものです。** · 2014/11/28(金) 00:27:03.41

>>338-339
うーん・・・やっぱり厳しいのかな
MakeScreen関数についてはちょっと調べてみます

**名前は開発中のものです。** · 2014/11/28(金) 04:18:58.91

どのくらい置くのかは知らないけど、
1m～10万km以内の全てのオブジェクト全部表示ははっきり言って現実的ではないね
自分の近場のオブジェクトだけ表示して、後は背景でごまかしちゃうのが一番いい
物にもよるけど実際に表示したとしても多分見えないし…
これはかなりよく使う手だよ

**名前は開発中のものです。** · 2014/11/28(金) 11:03:42.37

335読む限り、遠くの天体はやっぱり背景が良いんじゃないかね
労力と計算コストに対して、あんまり目立った変化なさそう

**名前は開発中のものです。** · 2014/11/28(金) 12:55:10.70

EVEオンラインとかどうやってんだろうな
天体の星も場所によって見え方が違うし、その方角に実際に星もあるし
LoVの応用でいけるか

**名前は開発中のものです。** · 2014/11/28(金) 14:08:48.35

マリオの話だけど「状態」を考えるといいよ
　静止状態 0
　歩き 1
　ジャンプ上昇中 2
　ジャンプ下降中 3

もう少し状態を持つと
　しゃがみかどうか　1 か0

右向きか左向きか　1か0

これでマリオの全ての状態を番号で表現出来た
ジャンプ中、2か3の状態のとき、しゃがみ状態なら、壁との当たり判定が小さいから
高いところのすきまに入れるとか
ジャンプ下降中のときしか敵を踏めない。上昇中ならダメージになる
switch文で状態番号で処理を分岐できるでしょ

これでもうまく判断しきれないことがあって
マリオが壁にめり込んだりするんだけどねw

**名前は開発中のものです。** · 2014/11/28(金) 17:31:27.53

めり込みバグなら本家にもあるししゃーない

**名前は開発中のものです。** · 2014/11/28(金) 19:56:51.44

>>343

サンクス
オブジェクト自体はロケットを表す球2つに中心の天体、あとはロケットの軌跡を描画するための
線分が合計で2000くらいだから大した数じゃないとは思うけど、ゲームなら背景でごまかしてもいいんだけど
シミュレータだからそれだと辛いんですよね・・・

まあでも仕様上キツそうならどこか妥協するしかないのかな

**名前は開発中のものです。** · 2014/11/28(金) 21:23:48.54

星の数にもよるけど Z バッファを切ってしまって
Z ソートして遠い順に描画するって手もある

**名前は開発中のものです。** · 2014/11/28(金) 22:54:18.04

全体用の縮尺されたデータと近距離視界用の細かいデータの2種類を用意すればいいだけだと
思うんだが、それじゃだめなん？

**名前は開発中のものです。** · 2014/11/28(金) 23:29:34.56

km単位で作る。太陽系の内側だけにする。外側はティクスチャを貼る。
directXが扱えるのが7桁だから、その範囲に収めるのがかんたん。

例えば、こんな感じ。
http://www1.axfc.net/uploader/so/3365583

**名前は開発中のものです。** · 2014/11/29(土) 01:34:52.16

>>340
XPから7に移行したようなありがちなPCじゃ処理落ちするから

**名前は開発中のものです。** · 2014/11/29(土) 06:50:46.91

>>351
うーん・・超至近距離は諦めた方がよさそうですね
FPS視点なしでTPS視点のみの実装にすれば最小距離は数キロメートルレベルで問題なくなるんで
まずはそっちに絞って作ってみることにします

**名前は開発中のものです。** · 2014/11/30(日) 12:23:19.96

それが、地球と月くらいの範囲ならば細かく出来る。
計算してみてください。

宇宙を扱う別の方法として、
VC++のLongを使う、32bit整数型。
計算をLongを行い、描画だけをfloatに代入して行う。

まず、やってみてください。

**名前は開発中のものです。** · 2014/12/01(月) 06:27:18.42

地球と月くらいの範囲じゃないから困ってるんだろう
俺は数段階描画するしかないと思うけどな
必要な最小単位が違う以上数度の描画にしないとどうしようもない

**名前は開発中のものです。** · 2014/12/01(月) 07:27:47.91

>>354-355
ｻﾝｸｽ
範囲自体は地球の周りでせいぜい数万キロなので、月までの範囲よりは一桁くらい小さいです
ただ実装したい手前側の最小範囲がそれこそ1メートルレベルなので8桁くらいの範囲にまたがってしまうため
そこが問題になっているようで・・・
数段階描画ってのは例えば2桁のスケールで区切るとして

1:カメラから1000キロ～10万キロの範囲を描画
2:カメラから10キロ～1000キロの範囲を描画
3:カメラから100メートル～10キロの範囲を描画
4:カメラから1メートル～100メートルの範囲を描画

としてそれを合成するっていう理解でOKですか？

**名前は開発中のものです。** · 2014/12/01(月) 07:43:04.23

>>356
そういう理解でおｋ

**名前は開発中のものです。** · 2014/12/01(月) 08:35:53.95

>>357
どうも
単純計算で描画時の負荷が4倍になりそうだけどやってみる価値はありそうですね
ちょっと試してみます

**名前は開発中のものです。** · 2014/12/01(月) 14:29:15.75

鉄ヲタのお前らに聞きたいんだけど、鉄道模型シミュレーターってあるじゃない?
あれだと遠景の建物がかなり接近してからじゃないと描画されないからリアリティいまいちなんだけど、
もしあんなかんじの一から自作したとしたら
グラボはここ45年のなら2-3キロ先の建物もうまく描画されますかね？

**名前は開発中のものです。** · 2014/12/01(月) 17:08:44.10

建物とか風景だと、個々のオブジェクトの作りこみにも拠る
前方3kmの半円の範囲で14km^2内の建物の数とかちょっと気が遠くなる

ゲームだと一定の距離以上のオブジェクトと近景用のオブジェクトを差し替えたりして
計算量を減らす努力する

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

鉄ヲタは2、3キロ先の建物も見えるの？

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

鉄オタじゃないけど、少なくとも2～3km先が何もない空間にはなってないな

**名前は開発中のものです。** · 2014/12/03(水) 20:49:17.35

間に障害物があるから先が見えないだけで、
2～3キロ先の建物なら見えないのは目が見えない人くらいだと思う
ためしに高い所から見下ろせばすぐわかる

**名前は開発中のものです。** · 2014/12/09(火) 01:31:23.02

公式の掲示板見てると中の人は本当によく対応してるよなあ。
なんかもう馬鹿みたいな奴のトンチキ質問にも丁寧にちゃんと答えてて感心するよ。

**名前は開発中のものです。** · 2014/12/09(火) 07:56:34.09

わからない人の気持ちがわかる人なんだろうな
本人は出来る奴でも、出来ない奴の気持ちがわからない奴は結構いるし
総じてそういう奴らは教えるのが下手だ

教えるのが下手な教師についてしまうと悲惨だから
成績がいいって理由だけで教師を決めないでほしい

名選手が必ず名監督になるわけじゃないんやで

**名前は開発中のものです。** · 2014/12/09(火) 09:41:18.54

そういうのあるよね。
頭いいからこそ頭悪い人の思考ルーチンがわからず、自分のルーチンを押し付ける。

**名前は開発中のものです。** · 2014/12/09(火) 16:52:15.23

それも厳密には分かっているとは言いがたいんだがな
なんとなくこうできてしまうのでやっているというのは反射で動くひよっこと一緒
理系を名乗るからにはやはり理論を確立せねば

**名前は開発中のものです。** · 2014/12/09(火) 18:58:06.62

＞わからない人の気持ちがわかる人

単純に、すげー人だなあとおもった

**名前は開発中のものです。** · 2014/12/09(火) 21:08:17.55

気持ちが分かるってか、どこでけつまづいてるのか分かるというか
それが分かれば後はそれに従って指示を出すだけ

**名前は開発中のものです。** · 2014/12/09(火) 21:11:42.81

「だけ」っていうけどそれを何年も延々とやってんだぜ・・・
ときどきぶしつけな態度のやつもいるしさ。
凄いと思うよ。

**名前は開発中のものです。** · 2014/12/10(水) 09:49:54.85

>>367
誰が理系を名乗ってるんだ？

**名前は開発中のものです。** · 2014/12/12(金) 12:26:52.93

DXライブラリを使った簡易的な画像ビューアを作ろうとしているのですが、
DrawGraphのTransFlagをFALSEにするとPNGのαチャンネルが有効になりません。
かといって、TransFlagをTRUEにすると何かしらの色が透過されてしまい、
どんな画像が読み込まれるかわからない以上使うわけにはいきません。

αは使うけれど透過色は使わない方法をどなたか伝授してくださりませんでしょうか

**名前は開発中のものです。** · 2014/12/12(金) 16:13:10.80

単なる画像ビューアならファイル内で指定された色を透過するだけじゃろ

**名前は開発中のものです。** · 2014/12/14(日) 02:12:45.36

>>372
LoadGraphの前にSetUseTransColor(FALSE);実行すればおk

**名前は開発中のものです。** · 2014/12/16(火) 18:05:06.77

マップの配列を外部読み込みにしたいのですが
2次元配列がどうしてもうまく読み込めません

FileRead_getsを使用するのは間違いでしょうか？

**名前は開発中のものです。** · 2014/12/16(火) 21:31:26.98

>>375
データを入れる配列は二次元配列である必要はない
1次元配列を作って

y座標*横幅 + x座標

でアクセスすれば良かろう

**名前は開発中のものです。** · 2014/12/16(火) 22:12:06.59

二次元配列も内部では一次元配列なので
FileRead_read((char*)&data[0],sizeof(char)*x*y,hn);（←適当）
こんな感じでまとめて読めるのでは

FileRead_getcでも
for (int y=0...) {
for (int x=0...) {
data[x][y]=FileRead_getc(hn);
}
}
でいけるんじゃないかな

**名前は開発中のものです。** · 2014/12/16(火) 22:33:58.07

>>377

>二次元配列も内部では一次元配列なので
newで動的に確保するとそれは無理。

**名前は開発中のものです。** · 2014/12/16(火) 23:50:13.90

>>376
すみません、よくわかりません
それでなぜアクセスできるのでしょうか

**名前は開発中のものです。** · 2014/12/17(水) 02:29:47.10

>>375
http://hpcgi2.nifty.com/natupaji/bbs/patio.cgi?mode=view&;no=1764

**名前は開発中のものです。** · 2014/12/17(水) 04:24:38.55

>>379

[00][01][02][03][04]
[05][06][07][08][09]
[10][11][12][13][14]

↑これは1次元配列を横幅５で並べたものだが
Y=1 で X=2 はどこかって言うと、 Y * 5 + X で [07] だとわかる。

もちろん左上の座標は(0,0)ね。

**名前は開発中のものです。** · 2014/12/26(金) 09:22:47.67

cairoで描いたグラフィックをcubeのテクスチャに貼りたいのですが3Dになるとcairoが描画してくれません。
どなたか詳しい方いませんか？

**名前は開発中のものです。** · 2014/12/26(金) 13:00:38.81

DirectX11を学ぶのはDXライブラリを学ぶ何倍ぐらい難しいですか

**名前は開発中のものです。** · 2014/12/26(金) 14:01:48.35

DXライブラリって学ぶことあったっけ。
全部やってくれるでしょ。

**名前は開発中のものです。** · 2014/12/26(金) 21:58:01.29

ゼロ除算が発生しそうな会話だ…

**名前は開発中のものです。** · 2014/12/27(土) 02:21:57.70

ゼロ女産

**名前は開発中のものです。** · 2014/12/27(土) 05:09:51.41

しかしホントこれいいな
まさかVBでこんなお手軽にDirect3Dアプリが作れるとは思わなかった
VC++＆生DirectXでやろうとしたらまず間違いなく挫折してたわ・・・

**名前は開発中のものです。** · 2014/12/30(火) 07:59:47.80

マイクロソフトもDXライブラリみたいなサブセットくらい用意すりゃいいのにと思うよな。
ゲーム作りたい人なんかほとんどこういうので事足りるんだから。
実際はテンプレートな設定を肩代わりしてほとんどラッパーだとしてもその作業、本当にめんどくさいからな。
しかもゲーム作りとほとんど関係ないし。

**名前は開発中のものです。** · 2014/12/30(火) 08:24:55.35

DorectXTKとかあるけど

**名前は開発中のものです。** · 2014/12/30(火) 08:51:26.05

DirectXTKはデバイスの初期化を簡単にできるインターフェースがあればいいのに

**名前は開発中のものです。** · 2014/12/30(火) 09:15:08.48

その昔、XNAというものがあってのう…

**名前は開発中のものです。** · 2014/12/30(火) 12:26:30.78

ブラウザー戦争みたいにMS製のUnityのパチモンは見たいな

**名前は開発中のものです。** · 2014/12/30(火) 17:17:21.30

MSといえばパチモンで稼いだ企業だからなｗ

**名前は開発中のものです。** · 2014/12/30(火) 21:13:34.02

DXUTもCodePlexにあるで

**名前は開発中のものです。** · 2014/12/31(水) 01:45:03.95

MSみたいなプラットフォーマーがXNAみたいなの作るとどうしても自社プラットフォーム専用になるから難しいところ

**名前は開発中のものです。** · 2014/12/31(水) 09:57:13.40

そのイイトコどりを有志がやる、と

**名前は開発中のものです。** · 2014/12/31(水) 13:52:11.29

質問させてください。
AddFontResourceExを使ってフォントを読み込んだ場合
RemoveFontResourceExで削除する、というのは理解できるのですが

Microsoftのリファレンスによると

FR_PRIVATEであれば
プロセスが終了すると、システムは、そのプロセスが AddFontResourceEx 関数を使って
インストールしたすべてのフォントを削除します。

と書かれているのですが、

その下の解説には
アプリケーションが、AddFontResourceEx 関数を呼び出してロードしたフォントリソースを必要としなくなった場合は、
RemoveFontResourceEx 関数を呼び出してリソースを削除してください。

と書かれています。

これは、アプリケーションの起動中にフォントが必要なくなったらRemoveFontResourceExで削除してね、
あとはアプリケーションの終了と同時に削除するよ

という解釈でいいのでしょうか？
お願いします。

Microsoft リファレンス : http://msdn.microsoft.com/ja-jp/library/cc428288.aspx

**名前は開発中のものです。** · 2014/12/31(水) 15:44:53.74

なんでMSDNにはっきりくっきり条件が書いてあるのに勝手な解釈してるの？
MSDNに書いてあることがすべて。勝手に推測する必要はない

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

ロードされたフォントはプログラムが終わったら自動的に削除しとくけど
使い終わった後すぐ削除したかったらこの関数使ってご自由にどうぞ～

**名前は開発中のものです。** · 2015/01/01(木) 02:58:41.45

やっと理解することができました。
ありがとうございます。

サイトで使い方を調べていたら
必ずと言っていいほどRemoveFontResourceExが書かれていたり
ロードしたフォントはRemoveFontResourceExを使わないと
残ったままになると書いている人もいたので混乱してしまいました。

**名前は開発中のものです。** · 2015/01/02(金) 01:21:26.38

フォントはふぉんとうに容量がバカにならないからね　ナンチテ

**名前は開発中のものです。** · 2015/01/03(土) 21:11:17.55

山田君、座布団全部もってって

**名前は開発中のものです。** · 2015/01/03(土) 23:58:15.82

質問です。

DXライブラリで3Dのアクションゲームを作っています。
キャラクターメイキングを実装しようと思うのですが、どのように実装すべきでしょうか。

Skyrimやデザインドールのようなパラメーターで変形は行わず、
いくつかある素体とそれに付け足す服や小物を選択していくようなものにしたいと思っています。

DXライブラリではモデルごとに物理演算を行っているようなので
別モデルをダミーボーンにつける方式だとスカートなどの貫通が起こってしまい、
剛体のアタリ判定を切れないので同モデル別フレームにアクセサリを配置して
表示非表示を切り替えるという方式では選択していないアクセサリのアタリ判定にぶつかってしまいます。

新しい方向性でも打開策でもいいのでアドバイスを頂けたら幸いです。

**名前は開発中のものです。** · 2015/01/04(日) 03:03:25.48

自己解決しました。

アクセサリ側に素体と同じ剛体を埋め込むことで解決できそうです。
アクセサリ同士の貫通はしょうがないですね。諦めます。たぶん。

**名前は開発中のものです。** · 2015/01/04(日) 19:50:02.43

質問です。
衝突後の位置と回転なんかの物理演算は自前でやるのかと思ってたのですが、
MV1PhysicsCalculation は何に使うのですか

**名前は開発中のものです。** · 2015/01/04(日) 20:25:09.71

>>405基本的にDXライブラリで物理演算っていったらMMDモデルの物理演算のことになると思います。
モデルごとの演算のようなので移動、衝突時の判定は自前か物理エンジンライブラリの力になるのではないでしょうか。

**名前は開発中のものです。** · 2015/01/04(日) 21:31:23.63

なるほど。MMDを知りませんでした。ありがとうございます。

**名前は開発中のものです。** · 2015/01/05(月) 22:24:34.25

使ってないグラフィックハンドルは早めにDeleteGraph( int GrHandle ) ;でメモリから削除した方がいいよね
指定のグラフィックハンドルを使ってるか使ってないかチェックする仕組みってどんな風に作ればいいんだろ？
１分に１回くらいのペースで消し損ねをチェックする仕組みを作りたいんだけどアドバイス下さい

**名前は開発中のものです。** · 2015/01/06(火) 01:51:44.04

1分に一回は効率悪い
普通はシーンごとに生成するはずだから、シーンが終了したときにチェックすればいい

あと、複数のシーンで使いまわすものはリストに登録しておいて、使ったら先頭に持ってくると
使用頻度が少ないものは後のほうになるので、決めた個数オーバーしたのは適当に削除する

でもね、今の時代は富豪的プログラムしていいのよ？

**名前は開発中のものです。** · 2015/01/06(火) 01:57:01.16

あと、お手軽なのはハンドルを参照カウンタで保持するの
ハンドルは使いまわすだろうから、どれからも参照されなくなった時点で勝手に解放される

でも、たとえば一か所からしか参照されなくて、さらにわりと頻繁にロードされるような画像の場合は効率が下がるので
シーンの最初で、ハンドルをつかんで離さないオブジェクトとか作ると回避可能

**名前は開発中のものです。** · 2015/01/06(火) 13:15:08.20

ほう、なるほどね（参照カウンタってなんだよ…教えてグーグル先生…）

**名前は開発中のものです。** · 2015/01/06(火) 14:34:55.18

グーグル先生「このエロ画像でも見て休め・・・」

**名前は開発中のものです。** · 2015/01/06(火) 14:36:15.85

通信関数使ってゲームをつくろうとしてるのですがチャットやゲームの情報などをのデータの受け渡し
をする際どのようにすれば区別するようにできるのでしょうか

**名前は開発中のものです。** · 2015/01/06(火) 15:00:24.04

プロトコルを作る
そしてヘッダに情報載せればいいかと

**名前は開発中のものです。** · 2015/01/06(火) 15:07:04.31

>>412
お前そんなものばっかり見てるんだろ、ハゲだし

**名前は開発中のものです。** · 2015/01/06(火) 16:55:57.47

　　　　　　　　　　　|
　　　　　　　　　　 |　　彡⌒ミ
　　　　　　　　　　　＼ (´･ω･`)また髪の話してる
　　　　　　　　　　　　　(|　　　|)::::
　　　　　　　　　　　　　(γ　/:::::::
　　　　　　　　　　　　　　し＼:::
　　　　　　　　　　　　　　　　　＼

**名前は開発中のものです。** · 2015/01/06(火) 22:50:39.79

よっぽどVRAMを消費するようなゲームでない限り、起動時に一括で読み込んでそのままの方がいい
無駄なロード・開放を減らすためのメモリ容量だ

**名前は開発中のものです。** · 2015/01/07(水) 00:05:44.05

それもある意味富豪的まあ、使用容量にもよるけど
そう考えると今は本当に余裕ができるようになったよな

**名前は開発中のものです。** · 2015/01/07(水) 01:05:00.67

今はVRAM256MBはあるのが普通で、512*512の画像1枚で1MBだから、100枚や200枚は読み込んでおいても問題ない

**名前は開発中のものです。** · 2015/01/07(水) 15:56:23.05

読み込みや解放が手間だからって、
果たしてゲーム中一度でも使うかどうかすら分からない画像をあらかじめ読み込み
結局使わずに遊ばせておくってのは個人的にはもやっとする
まあ、ギガビットのメモリがある時代に一桁メガビットのメモリ領域なんてのは、
反対側が遠くにかすむほどでかい倉庫の片隅にそっと積まれた荷物のようなものだけど

一応、メガビットメモリPCでブラウザ開いてゲームやる奴くらいは
想定しておいた方がいいのだろうか？

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

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