【初心者】ｽﾚを立てる前にｺｺで質問を【Part18】

>949
どっかに自分で解放忘れがある

だからfreeのし忘れは無いって。

デバッガの使い方を覚える

>>953
あーぁ、言っちゃった。

>>949
1. メモリの断片化
2. そのとき、他のアプリが動いた
3. 消したつもりが消えてない(画像/音/ヒープ(動的メモリなんちゃら))
4. そもそも扱うデータが時間と共に増加する仕組みになってる(動作ログ/ハイスコアランキング/アンドゥ機能)

delete [] p;となるハズの所をdelete p;と書いてるとか

しかし、ここは初心者スレだからな。
自分で確保してるメモリは開放しても、宣言したデバイスの後始末してないとか。
WM_QUIT に開放宣言書いてても、そこを通らずにウインドウ破棄してるとか。

よくあるのはリソース関係だけど、DirectX使ってるならリソース使ってないケースが多いからなあ。

リソースというかGDIオブジェクトとかその辺ね。

>>956
1.原始的なことしかしてないからないと思う。
2.他のアプリとかそういう問題じゃなくて、タスクマネージャを見ると実行ファイルgame.exeのメモリが単純に上がってくんだよ。
3.何度確かめても関数で唯一のリターンの直前で消してるので、画面が変わる毎に上がる理由にはならないかと。
4.単純（せいぜい配列や構造体）な変数と画像と音しか使ってないので無いはず。

>>957
だから、freeもdeleteも、動的確保を使ってないなら関係ないんだよな？　全く登場しない。

>>958
デバイスとやらを調べてみたけどどうやら3Dの話みたいね。俺は3Dは使ってないので関係ないかと。
WM_QUIT云々は調べてみたけど終了時にプロセスが残ってしまう類のことを言ってるのかな。
タスクマネージャによると、終了時にはきれいさっぱり消えてるから関係ないかと。

>>959
やはり原始的なことしかしてないので関係ないかと。
やってることなんてキャラの動きを計算してその結果によって画像を描写して音を出してるだけだし、
DXライブラリとやらに入ってる描写関数しか使ってないっていうかそれ以外の方法があるのか。


だけど一番の候補はメモリの断片化とやらかなぁ。

>>961
画像を消してるっていうのは、LoadGraphとDeleteGraphがちゃんと対応してるってことだよね。
ハンドルの番号を間違えたりしてない？
音を消してるっていうのは、LoadSoundMemとDeleteSoundMemがちゃんと対応してるってことだよね。
ハンドルの番号を間違えたりしてない？


メモリ使用量が延々と増加するというのは、どこかでリソース開放のし忘れがあるとしか思えないんだよな。
OSやライブラリのバグが１００％無いとは言い切れないけど、
絶対大丈夫だと思ってるところほどバグが隠れやすいぞ

珍しいパターンとしては、スレッドやプロセスとかがが多重起動しまくってるとか、
タイマーで重複動作してるとかかな？あるいは、再起が終わって無いとか。

>>962ていうかInitで全部削除してるからな。
ライブラリはDXライブラリしか使ってないし、メジャーだよな？
リソースってのが良く分からないんだけどそこまで言うなら調べてみます。

一応そもそもの話確認しておくけど
初回メニュー画面では３０MB代で実際のゲーム画面で９０台になって少しずつ増えていって１００超えて。
メニュー画面に戻っても下がらず、次からはゲーム画面に行く度に１５ぐらい増えてゲーム画面継続中にも少しずつ増えていくって異常だよな？

あとみなさん回答ありがとう。

ステップ実行して一行進める度にメモリ使用量を確認していけばどこでミスがあるか分からんのかな

>>961
だから〜、なんていわれても
こっちはそっちのコードなんか知らないよ。

win32apiは使ってるのかな

>デバイス　3Dは使ってないので関係ないかと。
そういう知識程度なら、もうステップ実行しろ
効率的なデバックの仕方書いても無理だと思うから
１行１行見たほうがいい

やってみたけどあらゆる場面で上昇してる感じかな……
うん、諦めます。ありがとうございました。

画像などのリソース読み込みを疑ってみる。
例えば、こういうパターンに陥るケース。

　1.ゲームを起動　　　 ：画像はまだ読みこまれていない。
　2.メニューを表示　　　：タイトルロゴを読み込み。
　3.実際のプレイ画面　：プレイ用画像を読み込み。メモリ上にはタイトルロゴが残っている。
　4.メニュー表示に戻る：メモリ上にはプレイ用画像とタイトルロゴが残っている。


あと、DXライブラリの専門スレで聞くのもいいかも。

>>969
あーひとつ思い立ったが
DXライブラリの詳細はよくしらんからあれだけど、
仮に>>969のゲームがテキストを描画していて、文字列描画時に
ハッシュにないキャラクタのフォントデータ（テクスチャ）をリアルタイムに生成する
仕組みだとしたら、テクスチャデータが逐次増加する可能性はある。
こういうケースでは実行中に微妙に使用メモリは増えていく。

あらゆる場面で上昇してる感じってどういうことだよやる気ねえな釣りか

一つ言えるのはコードも晒さずに情報の小出しする奴は
まともな回答を最初から期待していないという事だ

描画するたびにLoadGraphしてるとか

なんだレス乞食か

>>970
だからちゃんとInitしてますって。
あと、そうかDX専門スレで聞くべきだったか。

>>971
よくわからないけどDrawStringかDrawFormatStringでDX内臓のフォントで文字文字列描写してるだけ。

>>974
もちろん各フレーム毎のループに入る前にロードしてますって。


うん、諦めます。ありがとうございました。

Initって何さ

InitGraph 　読みこんだグラフィックデータをすべて削除する 。
InitSoundMem 　メモリに読みこんだ音声データをすべて消去する 。
DXライブラリ説明ページより

DXライブラリは知らんけどinitって普通初期化でしょ
初期化してもメモリは解放されないと思うけど

宣言 int InitGraph( void ) ;

概略 読みこんだグラフィックデータをすべて削除する

引数 なし
戻り値 　０：成功
　 −１：エラー発生

解説 　LoadDivGraph、LoadGraph、MakeGraph等で読みこんだ（作成した） グラフィックをすべて削除し、初期化します。これによって占有 されていたメモリ領域を開放することができます。

>>980
自分もDXライブラリは使ってるけど、その関数は使ったことないな。
> だからちゃんとInitしてますって。
毎フレームInitGraphをコールしてるってこと？

あとこんな説明の仕方しか出来ないようであれば、
DX専門スレに行ってもソース晒さない限り誰も分からないと思うよ

うん。だからいいんです。
あとループに入る前にロードしてるんだから削除はループ抜けてから関数終了する間に入れてる。
ちなみにDeleteGraphで消してみたけど変化無かった。

>>982
そか、じゃぁ最後に。
フレームのループ中に、DXライブラリのLoad〜関数・Make〜関数をコールしてないと言い切れる？

言いきれる。

Load、Makeを使う関数をループ内でコールしてないとも言い切れる？

DXライブラリソース公開してたから調べてみたよ。
DrawStringは初めて描画するキャラクターコードのテクスチャを
随時キャッシュしていくから、文字を多く使うゲームならメモリ
使用量は必然的に増えてく。他の関数は見てないけど、
ライブラリ内部で高速化のためになんらかのインスタンスのキャッシュを
逐次生成していく仕組みがどこかにあればそれなりに増えていくだろうね。
そのへんはDXスレで聞いてみたら？

言いきれる。もういいから。

>>986　ありがとうございました。

>>987
なるほど、じゃぁ残るは>>986の可能性か
ムービーとかFileRead〜関数は。。使ってないよね。

>>989　ムービーは無い。FileReadは何それって感じ。一応検索してももちろん無かった。
あともう１０００行っちゃいそうだしほんとお騒がせしてすみませんでした。

そのソース固有の問題なのか、DXライブラリ自体の問題なのかが気になるからな
ロード関係をWinMainの頭で全部やってInitをDxLib_Endの直前前に持ってきていても
なるなら986みたいなのが原因かな

そろそろ次スレ頼む

立ててみました
【初心者】ｽﾚを立てる前にｺｺで質問を【Part19】
http://pc11.2ch.net/test/read.cgi/gamedev/1236761855/

>>990もう帰ってこないことを心から願っています

ここから俺の日記

今日は４時に寝て８時に起きるつもりが、気づいたら夜の７時だった

俺はこれからどうすればいいんだ

とりあえずオナニーしてたら、こんな時間になってしまった

俺の日記　終わり

1000なら次スレにエスパー常駐

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。