HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2019
0530
るかかHGIMG4のメモリリークについて29解決


るかか

リンク

2019/5/30(Thu) 22:52:55|NO.87516

質問があり、スレッドを立てさせて頂きます。

今、HGIMG4を使ってゲームを作っております。
ゲーム中、何故か消費メモリがドンドン増えて行ってしまい
調査していたところ、
下記のように同じウィンドウIDに別画像をcelloadしているところで
問題が起きていそうだというところまで掴めました。

つきましては、メモリリークがおきない
メモリ解放する手段があるのかどうか。
(マニュアルみたけど見つかりませんでした…)
もしくは、HSP自体のバグなのか。
問題の切り分けをしたいと思っております。

HSPのバージョンは3.51です。
皆さんよろしくおねがいします。


---------------------------------------------
#include "hgimg4.as"

// - HGIMG4の初期化 -
gpreset

#packopt xsize 1280 // 横サイズ
#packopt ysize 720 // 縦サイズ

setcls CLSMODE_SOLID, $000000 // 画面クリア設定(黒)

repeat
id_window=5

if cnt \ 2=0: celload "res/image/Evt/EvtChr.png",id_window
if cnt \ 2=1: celload "res/image/Evt/EvtChr2.png",id_window

gsel 0
redraw 0 // 描画開始
gpdraw // シーンの描画

px=0:py=0
pos px,py
alfa=255:red=252:green=255:blue=255
gmode 3,,,alfa
gmulcolor red,green,blue

zmx=1:zmy=1
SpltNo=0
rotrad=0

celput id_window,SpltNo,zmx,zmy,rotrad

gmode 2
gmulcolor 255,255,255

redraw 1 // 描画終了
await 1000/60
loop



この記事に返信する


るかか

リンク

2019/5/30(Thu) 22:56:33|NO.87517

ソラさんが同じような質問をされていることを確認しました。
(5/30現在、コメントは無いようです)
大筋同じ内容にはなりますが、よろしくおねがいします。

http://hsp.tv/play/pforum.php?mode=pastwch&num=84312



砂時 計

リンク

2019/5/31(Fri) 22:06:10|NO.87520

HSP3 に限らず、1秒間に30回もリソースを読み込むようなコードは書かないようにするのが一般的です。
以下のように必要分を先にロードしておいて
高頻度に描画するところではロード済みのリソースを切り替えるようにするとよいです。


#packopt xsize 1280 // 横サイズ #packopt ysize 720 // 縦サイズ #include "hgimg4.as" // - HGIMG4の初期化 - gpreset setcls CLSMODE_SOLID, $000000 // 画面クリア設定(黒) // プリロード dim id_windows, 2 celload "res/image/Evt/EvtChr.png" id_windows.0 = stat celload "res/image/Evt/EvtChr2.png" id_windows.1 = stat repeat if (cnt \ 2) == 0 { current_id = id_windows.0 } else { current_id = id_windows.1 } gsel 0 redraw 0 // 描画開始 gpdraw // シーンの描画 px=0:py=0 pos px,py alfa=255:red=252:green=255:blue=255 gmode 3,,,alfa gmulcolor red,green,blue zmx=1:zmy=1 SpltNo=0 rotrad=0 celput current_id, SpltNo,zmx,zmy,rotrad gmode 2 gmulcolor 255,255,255 redraw 1 // 描画終了 await 1000/60 loop



るかか

リンク

2019/5/31(Fri) 23:18:41|NO.87521

すいません、言葉が足りませんでした。

ハッキリ分かりやすくするために1秒間に30回としましたが
例えば1秒に1回とか、そういう場合でも発生します。



#include "hgimg4.as"

// - HGIMG4の初期化 -
gpreset

#packopt xsize 1280 // 横サイズ
#packopt ysize 720 // 縦サイズ

setcls CLSMODE_SOLID, $000000 // 画面クリア設定(黒)

repeat
id_window=5

if cnt \ 60=0: celload "res/image/Evt/EvtChr.png",id_window
if cnt \ 120=1: celload "res/image/Evt/EvtChr2.png",id_window

gsel 0
redraw 0 // 描画開始
gpdraw // シーンの描画

px=0:py=0
pos px,py
alfa=255:red=252:green=255:blue=255
gmode 3,,,alfa
gmulcolor red,green,blue

zmx=1:zmy=1
SpltNo=0
rotrad=0

celput id_window,SpltNo,zmx,zmy,rotrad

gmode 2
gmulcolor 255,255,255

redraw 1 // 描画終了
await 1000/60
loop



るかか

リンク

2019/5/31(Fri) 23:24:25|NO.87522

頻度に関しては、ちょっと調べてみないと分からないですが…

出来るだけ画像をまとめて
celput時に分割画像No.を指定するよう設計したつもりです。

すくなくとも1秒に何回もLoadするって所は
あってゲーム起動時くらいのはずです。
(ある程度纏めてリソースを読み込んでいる)



ソラ

リンク

2019/6/1(Sat) 01:09:42|NO.87523

その質問をした本人です。
結局解決策は見つからず、HGIMG3で作ることにしました。
開放命令は本当に欲しいのでなんとかなりませんかね・・・



ソラ

リンク

2019/6/1(Sat) 01:14:39|NO.87524

>>砂時 計さん
ある程度の規模のゲームだと、全ての素材を予め読み込んでおくというのはメモリの都合上無駄が多くロード時間も長くかかるので、
シーン(場面)毎に必要な画像だけを読み込む感じになると思います。
ですがこのメモリリークのせいでそれができないんですよ・・・



るかか

リンク

2019/6/1(Sat) 06:52:38|NO.87525

ちなみに、おにたま氏にTwitterにて連絡はしています。
調査して頂けるとの事です。

私はHSP3.5に潜んでいるバグだと思っていますが
確証はないので…。
修正されることを期待したいです。


ソラさん:
私はもう開発がかなり進んでいるので
いまさらHGIMG3で作り直すのは工数が多すぎますねぇ…。
HSP3.6に期待です。



砂時 計

リンク

2019/6/1(Sat) 10:46:45|NO.87526

おお、大規模でリソース管理のチューニングにまで突入されている方々だったのですね、
失礼しました。
# そら リリース ができる手段が無いと困る;;

HGIMG4 は 3.6β が進んでいるのでβ2あたりに
バグの改修または2Dリソースの指定関数が入るといいですね。


るるか さんにご指摘いただいて、訂正。

×HSP3 に限らず、1秒間に30回もリソースを読み込むような
〇HSP3 に限らず、メインのアクションループ内で毎秒30回もリソースを読み込むような

"初期ローディングでも短い時間にロードしちゃだめ"という意図はありませんが
紛らわしかったです。すみません。
この後は同じで、私が規模感を勘違いしていたというオチに続きます。



KA

リンク

2019/6/1(Sat) 11:42:05|NO.87527

暇つぶしにやってみました。

サンプルのresフォルダーをコピーして適当な画像を
入れて見ましたが、タスクマネージャー上では38MB
付近で一定でした。(画像1個でも同じ)

環境依存?
画像の問題?
resフォルダの必須ファイルがおかしい?



るかか

リンク

2019/6/1(Sat) 12:59:23|NO.87529

KAさん

えっ? っておもって調べ直してみました。

確かに1秒に1回のcelload とcelput では、
タスクマネージャでの変化はある程度したら安定しました。

しかし、最初に示したような1秒に30回だと
タスクマネージャの変化はあり、消費メモリがドンドン増えて行っています。

なんだろこれ・・。


取り敢えず様子見しておきます。



KA

リンク

2019/6/1(Sat) 14:09:35|NO.87530

書き方が悪かったので書き直します。

最初に提示されたスクリプトで

1:適当な画像で実行すると命令エラー
2:3.4だったので3.51に更新
3:今度は黒画面のまま数秒で終了
4:しばらく悪あがきしてみても同じ
5:説明に
>>・リソースフォルダについて
>>HGIMG4では、起動時に実行するスクリプトと同じフォルダにある
>>「res」フォルダから必要なリソースを読み込みます。
>>リソースファイルは、「sample/hgimg4/res」のフォルダに含まれています。
>>以下のファイルは、起動のために必要ですので、実行ファイル作成時なども必ず入れておいてください。
>>res/font.gpb
>>res/shaders フォルダ(中のファイルも含む)
なので、resをそのままコピーした。
6:その結果、メモリ使用量は安定
---------------------------------------------
ちなみに
OPENGL版(hgimg4.as)で38MB程度
DX版(hgimg4dx.as)で22MB程度
で、双方とも安定しています。



MillkeyStars

リンク

2019/6/1(Sat) 15:00:26|NO.87531

メモリリークを引き起こして、プログラムに何らかの異常(この場合は、メモリの異常は含まない)は起きるのかなー?



るかか

リンク

2019/6/1(Sat) 15:26:20|NO.87532

画像や必要なres、プログラム一式を纏めました。
sample/hgimg4からファイルコピーし直してやってみました。

画像は適当に、今私が創っているゲームより拝借。

しばらくタスクマネージャ見ていましたが、0.1MBずつ増えて行っていました。

https://1drv.ms/u/s!AiA5ToZBNqDxio48winR0qxP4__a1w



KA

リンク

2019/6/1(Sat) 18:41:32|NO.87534

>>画像や必要なres、プログラム一式を纏めました。
誰でも検証出来る状態を、最初から提示するべきですね。

そのままじゃあ10分ぐらい放っておかないと変化が分かりません
でしたが、await 1 で再現が確認出来ました。画像サイズを変えて
も増え方は同じようですね。

#include "hgimg4.as"
repeat
id_window=5
celload "res/image/Evt/EvtChr.png",id_window
await 1
loop

これでも現象は確認出来ます。



るかか

リンク

2019/6/1(Sat) 18:49:23|NO.87535

KAさん:
仰るとおりですね、失礼しました。
現象確認ありがとうございます。

おにたま氏の連絡を待つことにします。

何か情報ありましたら、引き続きお待ちしております。



MillkeyStars

リンク

2019/6/1(Sat) 20:45:29|NO.87536

OpenHSP ソースコード(hsp3gp)からも、celload でのメモリリークを確認しました。

【問題の箇所】
gameplay::Texture::Sampler::create



るかか

リンク

2019/6/1(Sat) 23:00:16|NO.87539

MillkeyStarsさん:

情報ありがとうございます。



zakki

リンク

2019/6/2(Sun) 13:42:36|NO.87542

そこが問題ならgpmat.cppに1行追加で解決しませんか?

// Bind the texture to the material as a sampler Texture::Sampler* sampler = Texture::Sampler::create(texture); // +ref texture mesh_material->getParameter(samplerUniform->getName())->setValue(sampler); sampler->release(); // <-- samplerの寿命をmesh_materialのリファレンスカウントで管理するようにこれを追加



おにたま(管理人)

リンク

2019/6/3(Mon) 23:07:42|NO.87551

ご指摘と情報ありがとうございます。
こちらでも確認して修正してみたいと思います。



るかか

リンク

2019/6/3(Mon) 23:25:21|NO.87552

おにたまさん:

ありがとうございます。
ご対応、よろしくおねがいします。



おにたま(管理人)

リンク

2019/6/8(Sat) 02:22:50|NO.87556

>るかか さん

MillkeyStarsさん、zakkiさん、ありがとうございます。
gameplay::Texture::Samplerのリークを修正したバージョンをテスト作成してみました。
こちらのhsp36beta内にあるhsp3gp.exeのみ上書き更新で試して頂ければと思います。
ただ、環境にもよると思いますが、1/30や1/60単位でテクスチャを入れ替えると、バックグラウンドでシェーダーを含めた色々な更新がかかるため正しく更新されないようです。
もう少し遅めの入れ替えで、まだメモリ使用量が増え続けるようならばお知らせください。
https://onedrive.live.com/embed?cid=EC425522ED849DA7&resid=EC425522ED849DA7%211229&authkey=AB-pNztAqBp6BcU



るかか

リンク

2019/6/8(Sat) 19:12:22|NO.87563

おにたまさん


早速の修正ありがとうございます。
サンプルプログラムでは問題が起きないことを確認しました。

しかし、肝心の私の製作しているゲームの方では
メモリリークは起きたままのようでした。

入れ替えは1/30単位ではやっていないはずです。
問題点は他にあるようです…。

ソースファイルをおくって、見て頂くことは可能でしょうか?

お時間あるときに、確認頂ければ幸いです。

問題がある場合
次のリリース時にでもメモリリーク改善して頂ければと思います。

ご検討よろしくおねがいします。



るかか

リンク

2019/6/8(Sat) 20:34:51|NO.87564

現象としては、突然数十メガバイトくらいガッと消費メモリが増えていき、
それが減らないという状況です。
最初は80MBくらいだった消費メモリが800MBくらいに膨れ上がってしまいます。



ソラ

リンク

2019/6/8(Sat) 20:35:54|NO.87565

横からすみません。
おにたまさんも忙しいと思うので、るかかさんの方で発生条件をできるだけ特定したほうがいいのではないでしょうか?
他人が書いたプログラムは内容を把握してそこからデバッグで絞り込むとなると、かなり手間がかかりますし・・・



るかか

リンク

2019/6/8(Sat) 20:57:07|NO.87567

はい、重々わかっております…。

勿論、私の方でも発生条件を調査中です。

分かり次第、お伝えするつもりです。



るかか

リンク

2019/6/9(Sun) 16:42:20|NO.87575

もう一カ所怪しいところを見つけました。

現在作っているのは3DダンジョンRPGで
壁とかを3Dモデルを使用しています。

フロア全体に壁とか床を設置するとオブジェクトの数が1024を越えてしまうため
setreq SYSREQ_MAXOBJを設定しようとおもったのですが
現在未実装?と思われるので

現在位置付近の壁やモデルのみ、マスターとして用意したオブジェクトから
gpclone し、不要な場所はdelobjを行い、オブジェクトの数を節約するという
やり方をやっていました。

で、歩く度に毎度delobj&gpclone とやっていたのですが
多分、これが原因かなっておもいます。

解決策として一番最初にgpclone をして
プレイヤーが動く度に、オブジェクトも一緒に動き(setposし直し)
setobjmode OBJ_HIDEで、壁があるところのみ表示ってやってみようとおもいます。

やってみてまだ駄目なようなら相談とさせてください。


おにたまさん:
以上により、糸口が見えてきたので
先ずは試してみます。
駄目そうならまたご相談させてください。



るかか

リンク

2019/6/12(Wed) 15:49:36|NO.87587

皆様にご報告です!

無事、解決できました!!
これで引き続きゲーム作って行けそうです。

本当にありがとうございました!!



zakki

リンク

2019/6/13(Thu) 13:15:03|NO.87593

以前のバージョンではsetreq SYSREQ_MAXOBJできてたんですが駄目ですか?
http://hsp.tv/play/pforum.php?mode=pastwch&num=75135



るかか

リンク

2019/6/13(Thu) 20:13:20|NO.87594

あれ? そうなんですか?

取り敢えず、1024を越えないように出来たので
今は増やす必要がなくなりました。

どうしても増やす必要がでたら試してみます。



ONION software Copyright 1997-2023(c) All rights reserved.