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/

**832** · 2009/03/16(月) 04:54:34

WM_DISPLAYCHANGEを捕まえて、グラフィックハンドルの復元処理のコードを書いた。
同じような問題で困っている人がいたら、試してみてくれ。

検証が必要な箇所はまだあるとおもうが、とりあえず叩き台のコードをアップししとく。
http://www.dotup.org/uploda/www.dotup.org0835.zip.html
passは1234

**名前は開発中のものです。** · 2009/03/16(月) 10:24:23

>>838
引き継ぎって具体的に何すればいいのさ？
そんなに利用者いるようにも見えないが。

**名前は開発中のものです。** · 2009/03/16(月) 12:40:25

>>840
ライブラリを使う側じゃなくて作る側になってWebで公開するってこと。利用人数なんて関係ない。
現状、国内じゃまともに使える3Dライブラリが皆無だからね。

ただDXライブラリ3Dが使いたいだけならやめとけやめとけ。
変化の多い3D周りにおいて、開発終了したライブラリを今から使い始めるなんてのは得策じゃないよ。
素直にIrrlichtやORGEを使いなよ。

**名前は開発中のものです。** · 2009/03/19(木) 16:51:59

DXライブラリってDX_SCREEN_BACKとDX_SCREEN_FRONT以外にもバッファって作れないの？
画像ハンドルでもできるってことは知ってるんだけど、それだと遅くなりそうだしなんとかいい方法はないものか

**名前は開発中のものです。** · 2009/03/19(木) 18:28:29

それは何の目的でそんな事をしたいのかな？

**名前は開発中のものです。** · 2009/03/19(木) 18:36:46

画面のスクロールとかするときに、バッファ二つじゃ不便だからなぁ
俺も最近そのために物凄く無駄な苦労をした
DrawGraphとかの引数に描画先のバッファID(またはグラフィックハンドル)を指定するとか、
または予め描画先を指定する関数を呼び出しておくとか、
そういう方法で複数のバッファを使えたら楽でいいと思う
もしそれが俺の無知によるもので、本当は別に手段があるのならぜひ教えてほしい

**名前は開発中のものです。** · 2009/03/19(木) 19:07:33

いや多分無知なのは俺の方だと思うんだが、
なぜスクロールさせる事にバッファが二つじゃ足りないのか理解できない。

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

例えば、新しく作ったバッファにステージ全体の様子を描画する
表バッファには、プレイヤーを中心にした長方形を、
さっきのバッファから指定矩形部分描画を使ってコピーする

実際はもうちょっとスマートな方法だけど、簡単に言うとこういう方法

**名前は開発中のものです。** · 2009/03/19(木) 19:29:45

>>846
毎フレーム絶対同じ絵を表示するならそれでもいいけど
実際にはキャラ移動したりするしそれだと良くないんじゃない？

描画開始位置を変数で持っといて、
それを変化させながら表示すればスクロールできるんじゃ？

**名前は開発中のものです。** · 2009/03/19(木) 19:42:32

javaあたりでアクションゲームのスクロールの解説あったろ
あれみたほうがいんでね
もっと簡単にできるし

**名前は開発中のものです。** · 2009/03/19(木) 19:48:14

うん？
例えば暗闇の中で自分の周りだけ見えてる、みたいなイメージかな。

てか、裏画面にステージ全体を描画っていうけど
裏画面でも表示できる範囲以上の部分は意味なさないんじゃないのかな。
それとも画面はみ出した部分もちゃんと描画されてるの？

**名前は開発中のものです。** · 2009/03/19(木) 20:03:26

でっかいバッファにステージ全体を書いておいて、画面にはそこから一部を切り取ったものを映すってこと？

**名前は開発中のものです。** · 2009/03/19(木) 21:53:29

>>850
そういうこと

**名前は開発中のものです。** · 2009/03/19(木) 21:58:54

それって何の意味があるの？

**名前は開発中のものです。** · 2009/03/19(木) 22:00:26

スクロールがとても楽

**名前は開発中のものです。** · 2009/03/19(木) 23:05:40

普通に>>847じゃあかんの？

**名前は開発中のものです。** · 2009/03/20(金) 00:14:40

何が楽なんだろう……？

全画面をバッファにおいておくっつーのなら結局メモリはそれだけ必要なんだから
そのまんま画像として持っていてもあまり変わらないと思うし
それを好きな位置に表示すればそれこそ楽だろうと思うし……。

それともあれか。
お絵かきツールみたいに、画面上でいろいろ書き換えたデータを
そのまんまメモリに重ね落として、それをまた画面上に呼び出すとか
するのだろうか。

でもステージって言ってるしなぁ……？

普通ならマップチップつかって必要なとこだけ表示するだけだから楽もクソもないと思うし……。

**名前は開発中のものです。** · 2009/03/20(金) 00:57:55

新しいバッファよりもむしろマルチスレッド使えるようにならんかな

**名前は開発中のものです。** · 2009/03/20(金) 01:19:57

詳しいこと全然知らないんだけど、
DXlibではマルチスレッドは使えないの？

**名前は開発中のものです。** · 2009/03/20(金) 02:05:01

>>855
リアルタイムで背景が拡縮したり回転したり端がループする場合は
一度メモリに書き込んでおいたほうが楽なんじゃないかな

**名前は開発中のものです。** · 2009/03/20(金) 02:35:45

画像自体は既にメモリへ読み込みさせてるだろうし、計算は軽いよ
マップチップじゃなくてもSetDrawAreaで領域も最小限で済ませるし

**名前は開発中のものです。** · 2009/03/20(金) 05:32:02

ははは。ワールドマップのような広大なマップに対しても同様の手法をとるのか見ものだな

**名前は開発中のものです。** · 2009/03/20(金) 05:40:13

ちなみに、
>>842
SetDrawValidGraphCreateFlag使えば作れる。
注意点も有るが、それは自分で調べてくれ。

**名前は開発中のものです。** · 2009/03/20(金) 05:49:13

非常に亀レスだが、
>>757
>>758
俺が確認したところDXライブラリ ver2.25bには、
// フォグを有効にするかどうかを設定する( TRUE:有効 FALSE:無効 )
SetFogEnable( int Flag ) ;
// フォグモードを設定する
SetFogMode( int Mode /* DX_FOGMODE_NONE 等 */ ) ;
// フォグカラーを変更する
SetFogColor( int r, int g, int b, int a ) ;
// フォグが始まる距離と終了する距離を設定する( 0.0f ～ 1.0f )
SetFogStartEnd( float start, float end ) ;
// フォグの密度を設定する( 0.0f ～ 1.0f )
SetFogDensity( float density )
が有る。

**名前は開発中のものです。** · 2009/03/20(金) 07:38:27

DXライブラリで３DやってもカメラとかZバッファどうすんだとかいろいろ問題あるんじゃないのか

**名前は開発中のものです。** · 2009/03/20(金) 07:43:26

カメラ周りは平行透視固定みたいだね
Zバッファ周りは一通りある
詳しくはDxLib.h見れ

**名前は開発中のものです。** · 2009/03/20(金) 11:47:58

>>862
まじかー！

よーしパパobjファイル読み込んじゃうぞー

**名前は開発中のものです。** · 2009/03/20(金) 17:30:45

そーいえば昔、>849みたいなことをやろうとしたものの
結局やり方が分からなくて諦めたことがあったなあ。

どうするのがスマートだったんだろう、と
コーヒー片手にリファレンスを読みなおす。

今は雑巾を片手に。

**名前は開発中のものです。** · 2009/03/20(金) 17:42:15

ｗ

**名前は開発中のものです。** · 2009/03/20(金) 19:41:01

そこで落とす必要があるのかｗ

**名前は開発中のものです。** · 2009/03/20(金) 20:39:51

ベランダで夕日を眺めながらブランデーでも飲んでたんじゃね？

**名前は開発中のものです。** · 2009/03/20(金) 23:14:17

マップチップの表示にメモリ・速度的にどちらも有利な磐石な方法ってのはないんだよね
毎回マップ画面を生成する必要があるのか無いのかによっても分かれるし、
生成後に加工する必要の有無によっても手法が変わってくる。

**名前は開発中のものです。** · 2009/03/21(土) 02:35:14

PCならメモリたくさんあるんだしマップチップすら作らなくてもいいような時代

**名前は開発中のものです。** · 2009/03/21(土) 02:56:48

当たり判定とかもピクセル単位でやんの？

**名前は開発中のものです。** · 2009/03/21(土) 04:12:19

できなくはないよね、10000*10000でも12.5Mbだし
セルオートマトンの砂シム作ったときそれでやったよ､まあそんときは800*800だったけど

ところでみんな2Dゲーム作るとき座標関係の変数ってint使ってるの？
自分は三角関数使ったりするから基本floatかdoubleなんだけど、今時のPCなら問題ないよね？
プログラム板のスレとか見ると「浮動小数点なんて遅すぎて使えねー」なんて書き込みが2002年にあったりする
ゲームつくり初めの頃は固定小数点とか聞きかじりでやったりしてたけどやっぱメンドいわ
そろそろ2Dゲームならどんな風に作っても快適な時代になったよね

**名前は開発中のものです。** · 2009/03/21(土) 05:15:05

2002年の段階なら当然の反応じゃねーかな。
ノートPCのことも考えると。

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

>>873
とにかくメモリーを節約したい場合以外は、floatよりdoubleの方が一般だと思う。
（今時のCPUなら早いし、精度も高いし）
あと、どのくらいその計算をさせてるかにもよると思う。
正直、２Dゲームならよほど大量のデータを演算しまくらなきゃ、
大抵は表画関連の処理時間に肉薄する事もないだろうし。
（パーティクルを超豪華に大放出です!!さらにパーティクル同士が当り判定します!
　みたいな時は分らんが、それ以外は問題無いと思う。）

**名前は開発中のものです。** · 2009/03/21(土) 09:43:50

現状、2Dゲームで浮動小数点がネックになることはほとんどない。というか無い。
そもそもDXライブラリは内部的にはサーフェスを3Dで扱ってるし、その上でいまさら固定小数点を使っても、
速度差はスズメの涙である。(ボトルネックになる部分はもっと他にある)
計算コストを見直すのであれば、当り判定を工夫したりする方がよっぽど建設的と考えるが。

**名前は開発中のものです。** · 2009/03/21(土) 09:46:34

昔は、float じゃなければ並列化が効かなかったんだよ。
doubleはどうあがいても高速化できないが、floatは腕次第でフルチューン可能だった。

そんな時代もあったのさ。

**名前は開発中のものです。** · 2009/03/23(月) 00:21:46

>>875
DXライブラリをデフォルトの状態で使うと doubeを使っても精度が float並になるよ。
つまり余計にメモリを食うだけってことに。

**名前は開発中のものです。** · 2009/03/23(月) 03:58:43

>>878
それ、なんかプログラミングが間違ってるか、何かを誤解して理解してると思うが。
引数がfloatでも、それまでに計算したdoubleの精度は精度で有効に使い続けられるわけだし。

**名前は開発中のものです。** · 2009/03/23(月) 04:14:27

ベクトルと行列演算はD3DX系命令に任せたいから俺はfloat派だ。
double精度が必要な時が出たらdouble使うと思うが今のところ無いな。

**名前は開発中のものです。** · 2009/03/23(月) 22:35:05

floatでずれが出ないなら殆ど好みでいいな

**名前は開発中のものです。** · 2009/03/24(火) 14:18:07

DXライブラリ3Dを配布してるサイトって無いのな
作者サイトも昨日までは普通にアクセスできたのに

**名前は開発中のものです。** · 2009/03/24(火) 14:20:54

>>882
3Dは DarkGDKを使え

**名前は開発中のものです。** · 2009/03/24(火) 17:18:13

>>882
3DがC言語初心者レベルで扱えるライブラリなんて設計上不可能だ。
DXライブラリ3Dが目指そうとしたのは砂上の楼閣だったのさ。
ORGEかIrrlicht使いなよ。

**882** · 2009/03/24(火) 20:15:11

ファイナルパックは持ってるよ
ヘルプが完全ではないから手探りだけど

**名前は開発中のものです。** · 2009/03/24(火) 20:42:07

OpenGL用だが、3DはGLUTってのはどうだろう？

**名前は開発中のものです。** · 2009/03/25(水) 00:48:05

Siv3Dは本当に出るかわからないし
現状、DXライブラリ3Dが最強なんだが…

**名前は開発中のものです。** · 2009/03/25(水) 03:39:15

暇なんでDXライブラリ3Dみたいだけど２ｃｈネラー向きのDirectXライブラリつーのを
作ってみるわ。もちろんWindowsネイティブな。少しまちなー。

**名前は開発中のものです。** · 2009/03/25(水) 04:22:27

>>888
まずその名前はややこしいから変えて欲しい。
DirectX自体がライブラリだし、DXライブラリに名前が似てるし。
そして次、作ってみるって思ってから完成するまで膨大な時間が掛かるって事。
少し位じゃ完成しないからやるならもうちょっと長いスパンで考えた方が良いよ。

**名前は開発中のものです。** · 2009/03/25(水) 06:56:03

音ゲーみたいなの作りたいんだけど
音がズレてるような気がする。
int GetNowCount( void ) を使ってるんだけど
違うソフトとか触ったりしたら時間だけ経過されたりして描画されなくなる。

**名前は開発中のものです。** · 2009/03/25(水) 07:26:34

これって.NETのユーザーコントロールって使えないの？
擬似ボタンとかならDXライブラリの関数で作れるが
スクロールバーとか高度なものだとちと無理臭いので気になったのだが。

**名前は開発中のものです。** · 2009/03/25(水) 08:21:26

>>890
非アクティブ状態でもタイマーは進むから、その辺考慮して設計すべし。

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

>>890
int SetAlwaysRunFlag( int Flag ) ;
か
int LoadPauseGraph( char *FileName ) ;
の関数を使えば、やりたい事は解決すると思う。

>>891
できない事はない。と思うが・・・・
.NETとDirectXは基本別物（.NETからManaged DirectX は動かせるにしても）
結局深い知識が必要だから、まぁ、普通の人はやらん方が無難。
スクロールバーぐらいなら自前した方が何かといいかと思う。

**名前は開発中のものです。** · 2009/03/25(水) 09:38:24

でけた　ｔｈｘ

**名前は開発中のものです。** · 2009/03/25(水) 09:51:13

>>891
ちょっと調べたが、簡単には無理っぽいな

試したことが無いが、
SetUseGDIFlag(TRUE)すればコモンダイアログ等のGDIの画面上乗せ出来るようだ。
メインウィンドウのHWND取得して、CreateWindowEx等のAPIで自作したウィンドウハンドルを子ウィンドウとして登録。
メッセージプロシージャ等はAddMessageTakeOverWindowすればコールバックで戻ってくる模様。
.NETではないが、コモンコントロールを扱うのなら、こういう方法しかないとおもう。

ちなみに俺はスクロールバー・ボタン等については必要になった時に自作している。

**名前は開発中のものです。** · 2009/03/25(水) 12:24:54

初心者向け3Dライブラリの条件は
C++でなく、C言語に対応していること
そして、コマンド数が多い事
単純であることだろう、よって複雑な事は出来なくても良い。

DarkGDKのコマンドリストをUPする。
コマンド名を見れば動作の予測ができるでしょう
http://www.csync.net/service/file/view.cgi?id=1237950965

**名前は開発中のものです。** · 2009/03/25(水) 19:28:42

>>893 >>895
レスTHX。ListViewとかボタン（WINAPIと同じ挙動のやつ）を
作るとなるとかなり大変だからManaged DirectXの方でやることにするわ。

**名前は開発中のものです。** · 2009/03/25(水) 21:17:20

>>896
そもそも初心者が3Dに手を出すこと自体にかなり無理があると思うんだが。

**名前は開発中のものです。** · 2009/03/25(水) 22:14:20

Easy3Dは初心者に対しては本当に良く出来てる
HSPで3Dってのが個人的にはありえなかった

**名前は開発中のものです。** · 2009/03/26(木) 00:21:46

そもそも初心者はゲームの作り方自体がわかんないと思うけどなあ

**名前は開発中のものです。** · 2009/03/26(木) 00:33:28

DXライブラリのおかげでなんとかゲームらしきものが作れてるレベルの俺としては
３Ｄものなんて夢のまた夢。

**名前は開発中のものです。** · 2009/03/26(木) 02:33:02

3Dもそこまでハードルが高いとは思わないんだけどさ、
2Dと違って素材集めやモデリングが難しいんだよね。そして興味ない。
さらに3Dで作るゲームにアイデアがない。
最後に、3Dゲーって2Dゲーと違ってしょぼさが如実にあらわれるんだよね。

**名前は開発中のものです。** · 2009/03/26(木) 02:55:38

ハードルなんてあるのか？軸が１個増えた程度にしか･･･。

**名前は開発中のものです。** · 2009/03/26(木) 03:28:44

あたり判定やらモーションが難しいし面倒
衝突した場合、３Ｄの場合は食い込んで表示されて不自然だし
回転とかしたときのモデルの先端の座標やらがイメージしにくい

**名前は開発中のものです。** · 2009/03/26(木) 04:42:32

>>903は次世代コンシューマでメインPGで何作も作ってる程の凄腕のプログラマーに違いない。

**名前は開発中のものです。** · 2009/03/26(木) 06:38:45

カメラを意識しないようなゲームなら、ホントに軸が１個増えただけだと思うよ
計算が複雑になったり、グラフィックに掛ける手間が増えるから
初心者は2Dでゲーム製作に慣れてからの方がいいとは思うけど

**名前は開発中のものです。** · 2009/03/26(木) 06:44:13

PRG作るときのキャラ表示って２次元のグラフィックを三次元空間に配置したほうが楽？
二次元のキャラが２マスのサイズあるので、
NPCの前に立つのと、後ろに立つので被さり表示順序を変えなきゃならん。

３Dならこんなのないだろうになぁ

**名前は開発中のものです。** · 2009/03/26(木) 07:38:35

>>907
3Dでも基本的に同じだよ
奥行きの値で表示順をソートする必要がある

**名前は開発中のものです。** · 2009/03/26(木) 08:50:05

>>907
俺は描画オブジェクトにZ値を持たせ、描画順をstd::listで記憶して表示順序変えてるよ。
Z値が同じ値なら、Y値の設置底面(top+heihtした値)で比較し、ソートする。

たぶんこれが一番楽で一番確実。
毎フレームソートするのはバカらしいから、極力必要最低限の回数にするようにしてね。

**名前は開発中のものです。** · 2009/03/26(木) 09:47:36

>>909
thx.
std::listってc++か・・

**名前は開発中のものです。** · 2009/03/26(木) 09:59:19

そうそう。これを機にSTL覚えなよ。
STLも万能ではないが、知っておくに越したこと無いね。
ちなみに、こういう並び替えが頻繁に行われるものはvectorやmapでもなく、list使うのが良い

**名前は開発中のものです。** · 2009/03/27(金) 07:03:04

オブジェクト指向のｃ＋＋のが、
何人いるかわからないNPCにとっては有効？

**名前は開発中のものです。** · 2009/03/27(金) 08:48:18

有効。C++じゃなくても書けるが、Cで書くよりははるかに柔軟に書ける。
スプライトを扱う基底クラスを継承してNPCクラス作ればいい。

厳密に言うと何人居るかわからないのはSTLのvectorが基本。(俺ならlist使うけどな)
NPC挙動はデザインパターンでいうところのStateかとStrategy

**名前は開発中のものです。** · 2009/03/27(金) 22:11:00

3D版で、衝突したポリゴンから法線ベクトルの取得ってできる？

**名前は開発中のものです。** · 2009/03/27(金) 23:21:19

3Dのスレ立てて、そこで議論しれ

**名前は開発中のものです。** · 2009/03/28(土) 00:15:58

俺は907じゃないけど。

今まで作ってきた２Ｄゲーでは画面表示の優先度が４段階くらいしかなくて
キャラの最大数も固定にして配列を利用して順番に表示していた。

次からはもうちっと一般的な組み方をするようにしようと、
listの使い方をいくつかのサイト巡って見てみたんだけど、どう使うんですか？　これ。

要素を追加とか参照する方法はいいとして……。

例えばDXライブラリ使って表示するとしたら、最低限でも
「表示優先度」「グラフィックハンドル」「表示座標(X,Y)」
が必要なわけですが、このうち「表示優先度」をlistに追加していき、最終的にソート？

でも「表示優先度」だけソートされてもしょうがない。「グラフィックハンドル」とかと繋がってないと。
とするとlistの項目に「グラフィックハンドル」その他も組み込める？

それとも、表示優先度の段階ごとにlistを用意して、それぞれに追加していく？
でもこれだと３Dゲーみたいに優先度がどこまで段階わけされるかわからない場合に使えないし……。

**名前は開発中のものです。** · 2009/03/28(土) 00:32:49

その3つをまとめた構造体をつくって優先度をキーにソートすればいいんじゃないの？

**名前は開発中のものです。** · 2009/03/28(土) 02:01:13

listをどう使うかなんてこのスレに関係ないだろ。

**名前は開発中のものです。** · 2009/03/28(土) 02:05:01

……と自治っぽいことを書いておくと、何故か反発して親切な馬鹿が教えてくれるよ。

**名前は開発中のものです。** · 2009/03/28(土) 09:35:01

>>916
クラスないしは構造体で「表示優先度」「グラフィックハンドル」「表示座標(X,Y)」などの情報をカプセル化して梱包する。
クラスには仮想関数でdraw()を持たせる。
この"クラスのポインタ"をstd::listとしてとあるImageListクラス(Singletonオブジェクト)が一律に保持し、優先度が変更されたタイミングでsortをして常に正しい描画順位になっているようにする。
そして、描画タイミング時(毎フレームに1回)に、drawを優先順位順になめるように実行すれば良い。
これで、簡易な描画システムの完成。システムと呼べるほどの出来ではないけどな。

俺の場合、さらにScreenクラス(独自の座標系とクリッピング領域を持つ)とノード型の親子関係で持たせることで柔軟に対応している。

**名前は開発中のものです。** · 2009/03/28(土) 09:41:07

>>919 - >>920
ﾜﾛﾀ

**名前は開発中のものです。** · 2009/03/28(土) 12:58:40

高度な話してるところ悪いんだけど初歩的な質問をさせてくれ。
ここで聞けって言われたもんで。

メニュー画面とゲーム画面を往復する度にメモリ使用量が上がってくんだけど、
読み込んだものはゲーム画面終了直前にInitSoundMemとInitGraphで全て削除するようにしても
上昇量よりはるかに小さい分しか変わらないし、
じゃあ今度は画像の読み込みを全部削除してみたら（画面は真っ暗になるけど）きれいさっぱり解決したから
やっぱ画像関係に原因があるのはわかったんだけど、

本題
DXライブラリって画像関係で、読み込んだの以外に変なのを生成したりしてるんですか？

あとどうやらそのゲーム画面で初めて登場する画像が描写される度にもメモリ使用量がちょっと上がるみたい。
これも画面真っ暗にしたらきれいさっぱりいった。

**名前は開発中のものです。** · 2009/03/28(土) 13:40:42

>>879
代入なら精度は落ちないけど、計算すると精度は落ちるよ。
double同士の四則演算をすると DxLib_Init前と後で、精度が違うから
同じ計算をしても結果が異なることがある。

**名前は開発中のものです。** · 2009/03/28(土) 13:50:45

>>923
何度読んでも俺には何言ってるのか分からん。
精度が違うって何言ってる・・・。

**名前は開発中のものです。** · 2009/03/28(土) 14:00:54

>>924
わかりにくくてすまん。
例を書いてみた。

double a = 0;

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
double v1 = 3.1415926535897931 + a;
ChangeWindowMode(TRUE);
if(DxLib_Init() < 0) return false;
double v2 = 3.1415926535897931 + a;
return 0;
}
v1と v2の値を比べてみてくれ。

**名前は開発中のものです。** · 2009/03/28(土) 14:04:24

>>925
あ、return falseはまずかった。
return 0の間違いってことで。

**名前は開発中のものです。** · 2009/03/28(土) 14:08:18

あ。わざわざ例挙げてもらってすまん。良いたい事は分かった。
DXライブラリでDirect3D使う場合だとFpuPreserveしてるからdouble型の演算レジスタ弄ってるわけね。
俺3D機能使わずにDirectDrawの方で書いてるから気づかなかったわ。

**名前は開発中のものです。** · 2009/03/28(土) 14:48:40

>>925,926
Direct3DのFPU関連の対処法についてDXライブラリのソース調べてみたら、
// FPUの精度を落とさない設定を使用するかどうかを設定する、DxLib_Init を呼び出す前のみ有効( TRUE:使用する(精度が落ちない) FALSE:使用しない(精度を落とす(デフォルト) )SetUseFPUPreserveFlag( int Flag );
を見つけたよ。
double型を使う場合はTRUEにしても良いかもね。（精度は上がるが速度が落ちるので好みに）

でも、俺はfloat派だから関係ないが～。

**名前は開発中のものです。** · 2009/03/28(土) 15:03:24

パンツってみんな脱いでるの？あとカップルいるけど警察に捕まったりしないの？

**名前は開発中のものです。** · 2009/03/28(土) 16:05:39

>>922
メモリ使用量の上昇具合ってどんな感じ？
コードを晒してくれると原因が分かりやすいんだがな。

画面遷移時に使われなくなったハンドルについて
・イメージハンドルはDeleteGraphで個別に全て解放をしているか？
・フォントの再生成をしていないか？
を見直してみてくれ。
特にフォントは文字サーフェスをキャッシュしているから、DeleteFontToHandleしないとメモリが解放されない。
その上で、フォントの再生成をしてしまうとメモリ使用量がじょじょに増大する結果になるよ。

**名前は開発中のものです。** · 2009/03/28(土) 16:48:52

>>930

・メモリの上昇具合
メ＝メニュー画面、ゲ＝ゲーム画面
メ59M
ゲ108M
メ107M
ゲ112M
メ118M
ゲ124M
メ129M

・イメージハンドルはDeleteGraphで個別に全て解放をしているか？
さっき言ったとおり、Init～で全部まとめて消去してる。

・フォントの再生成をしていないか？
よこわからないがフォント関係はいじらずデフォルト？の文字で単純に出力してるが、それでもアレ？
ていうかさっき言ったとおり画像を読み込むところだけ切り取ったら全部解決したので画像関係のアレだと思うんだが……

**名前は開発中のものです。** · 2009/03/28(土) 17:33:23

切り取らずに、画像を読み込み終えたところでInit～してみたらどうなるかな。

**名前は開発中のものです。** · 2009/03/28(土) 17:40:00

>>931
>ていうかさっき言ったとおり画像を読み込むところだけ切り取ったら全部解決したので画像関係のアレだと思うんだが……
ちょっとこの文章の意味がわからんな。
画像を読み込むのを切り取っちゃったら画像が読み取れないんじゃないか？
それとも、状態変移での2度目に読み込みを飛ばすってこと？
でもその前にInitGraphしてるのなら、グラフィックハンドルは解放されて無効になってるはずだよ。(描画できないはず)

えっととりあえず言うと、画面遷移時にInitGraphで全部消しちゃうのはオススメできない。
使い終わったグラフィックハンドルについては面倒でも個別にDeleteGraphしてみるのが良い。(サウンドもDeleteSoundMemを使う)
俺の場合これで画面遷移時でもメモリ上昇は変わらないよ。

未だ問題あるようなら、同じグラフィックハンドルに画像を読み直す命令としてReloadGraphというのがあるので、これで上書き読み込みする手もある。
あと、DXライブラリでのメモリ使用量と数を確認する命令DxGetAllocSizeとDxGetAllocNumを使って、どのタイミングで発生するのかを確認するのも手。

フォントについてはCreateFontHandleしてないなら問題ないよ。

**名前は開発中のものです。** · 2009/03/28(土) 18:38:40

>じゃあ今度は画像の読み込みを全部削除してみたら（画面は真っ暗になるけど）きれいさっぱり解決したから
>やっぱ画像関係に原因があるのはわかったんだけど、

って事でしょう。

>えっととりあえず言うと、画面遷移時にInitGraphで全部消しちゃうのはオススメできない。

これ、気になるので、よければその理由を教えて欲しい。

**名前は開発中のものです。** · 2009/03/28(土) 19:05:08

>>932　読み込んだ直後にInit～やったけどダメだった。なので

>>933　Deleteでそれぞれやってみたけどやっぱダメだった……
あと、WaitTimerとかでところどころ止めながその隙にタスクマネージャで見る方法でもいいよね？
上昇のタイミングはもちろん画像読み込みの時で、問題なのはデリートの時に少ししか下がらないで、
あと各画像がそのゲーム画面で初めて表示されるときも微量ずつ謎の上昇……

ていうか普通はデリートすればあっさり上がるんだな……なんでデリートがちょっとしか効かないんだ。

**名前は開発中のものです。** · 2009/03/28(土) 19:43:04

>>944
リソースの管理はなるべくプログラマが厳密にした方が良いって理由。
InitGraphだとMakeScreenやMakeGraphやCreateGraphFromSoftImageで作った画像も全部丸ごと削除されてしまうから。
DeleteGraphなら無効なハンドル渡したときに戻り値で-1返すし、どのハンドルが解放されたのかを明示的に指示した方が分かりやすい。
自分はグラフィックハンドル周りはクラスでカプセル化してデストラクタで必ずDeleteGraphして解放するようにしてる。

>>935
>あと各画像がそのゲーム画面で初めて表示されるときも微量ずつ謎の上昇……
これは正常な動作だよ。最初の表示1回目はメモリ確保される。

うーん。どっかでDXライブラリ以外の箇所でnew(malloc)したメモリをdelete(free)せずにメモリリークしてないかい？
MSVC環境なら_CrtSetDbgFlag()があるからチェックしてみて。

**名前は開発中のものです。** · 2009/03/28(土) 20:01:35

>>936　そうか最初の１回は上がって普通なのか。
あとメモリの動的確保ならやってない。画像関係の問題ってわかっててるし。
CrtSetDbgFlagって言うのをググってみたけどデバッグ環境が必要みたいだね。
そりゃ無理な話だ……

あまりしたくないんだけど、ゲーム画面のコードを晒せば原因判明するかな？

**名前は開発中のものです。** · 2009/03/28(土) 20:15:33

Borland C++使ってるのなら_CRT関数は使えない。Microsoft Visual Studio専用関数だからね。
さすがに現状で、要因を探すのは難しいな。

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

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