500m美術館、展示物入れ替え中

地下鉄大通〜バスセンター間の
500m美術館の展示物がなくなっていてビックリ！

「初音ミク冒険記」、マップめりこみ問題が解消できたっぽい

エアリアルステップ（２段ジャンプ）で
パズルエリアのギミックにめりこんだり
壁を突き破るという問題は、解消できたと思う。

最終的に矩形と矩形の当たり判定を使って
ぶつかっていたら動かないことにした。

敵の弾や敵の当たり判定が円じゃないパターンについては
第１章では考えないことにした。

第２章のフィールドマップを作る頃までに
もう少し、検討したいところだ。

次は、細々した気になる部分の調整かな。

「初音ミク冒険記」、週末に当たり判定を作るつもりが・・・

できなかった(;´д｀)ﾄﾎﾎ…

なんか現実逃避したように「当たり判定の部分」じゃないところが
気になりだして、そのあたりの微調整をしているうちに
週末が終わってしまったと言う・・・

一応、細かな不具合がいろいろつぶれたので良かったとしよう。

と言いつつ、その気付いた部分の対処を検討するのに
探索系ドラキュラを参考にすべく動かして確認していたら
ついついゲームに熱中してしまったとも言うけど

「初音ミク冒険記」、当たり判定について考えてみる

なんとか画像関連のメモリ調整が終わった。

次はエアリアルステップの当たり判定関連だ。

今後のことも含めて当たり判定でやりたいことを
テキストエディタに書き出してみたら
思ってたよりも「おおごと」になりそうだ。

当面の問題は、移動速度が速くて判定円が
接触判定に使う線通り越した場合などで
平山さんの本の８章を参考にすれば良さそうだけど
今後出したいと思っている敵の攻撃パターンとかを考えると
今のデータの持ち方じゃダメっぽい。

具体的には、敵の弾や敵の当たり判定が円じゃないパターンがダメだ。

ドラキュラに出てくるルーラーソードみたいな
「線状の敵自身、とか線状の弾」とか
放射状に発射されるレーザーっぽい攻撃とか
（回転した四角形といった線よりも厚みがある当たり判定）
のものが駄目そうだ。

敵の弾や敵の当たり判定の形を変更すると
少なくとも形の種類を格納する変数や
判定に使う複数個の座標を持たないといけない。

敵の弾や敵の情報は、セーブデータにも持っているので
セーブデータの形式も変更になる。

セーブデータの形式は何回も変更したくない。
そう考えると、データの持ち方は吟味する必要があるな。

データの持ち方によって当たり判定も変わってくるしなぁ。
当たり判定が複雑になるとテストも時間がかかるし
次の公開はどうしたものかなぁ。

いっそ、今の段階で一度公開しようかな。
ななしあさんの指摘してくれた不具合も直っているし。
マップとの当たり判定があやしいけど
２段ジャンプも実装できたしなぁ。

週末にもうちょっと考えるか

「初音ミク冒険記」、まだメモリ関連の調整中

LoadGraphのメモリリークが解消されたことで
躊躇無くDeleteGraphを使ってメモリを空けられるのだが
いかんせん思いつきで作っている関係で
「この状態でこういうデータをロードしたら、ここがおかしい」だの
「あっちを変更したから
　ゲームオーバーでリトライを選ぶとメモリリークしてるぞ」だの
いろいろと考えることが多い。

しかも紙に書き出したり、テキストエディタやら表計算ソフトを使って
まとめたりもしていないので余計に大変だったりする・・・

いまさらだが、もう少し考えてからプログラムした方が良いかもしれないな。
仕事のプログラムと違ってドキュメントをほとんど書いていないからなぁ・・・

あとは第１章のボス戦のマップへ切り替わるとき
空きメモリが少ないのでDeleteGraph→LoadGraph系の処理をするので
以前よりちょっと時間がかかるようになった。
この為、画面切り替わりまでの間は、
「Now Loading...」を出すことにした。

といった状況なので、まだしばらく次の公開はできそうもない・・・

さて、ちょっと話題を変えてセーブデータのアイコンの話を。

以前の記事、「初音ミク冒険記」のセーブデータアイコンで
次からはシステムメニューでセーブを選んだとき
一瞬、下のような画面が出るようになると書いたのだけど
覚えているだろうか？

記事にも書いたけど、ちょっとダサいのだが
一度、保存するセーブデータアイコンの画像を
画面に表示しないといけないのだ。

どんな仕組みになっているかというと

１．キャンプメニューを開くとき、その直前の画面状態を
　　Dadrfyさん作のMakeGraphFromScreen関数で画像ハンドルとする

２．１の画像ハンドルをアイコンサイズ（144ｘ80）に縮小したものに
　　タイトルロゴをアイコンサイズの半分のサイズに縮小したものを画面に描画する

３．Dadrfyさん作のMakeGraphFromScreen関数をちょっと改造した
　　かげさん作のMakeGraphFromScreenIcon関数で画像ハンドルとする

４．３の画像ハンドルをDadrfyさん作のSaveGraph関数で
　　スクリーンショットディレクトリに保存

５．４で保存した画像を読み込んで画像ファイルサイズ分
　　動的にメモリ確保し、セーブデータアイコン用の配列とする

という手順になっている。

１で使っているMakeGraphFromScreen関数は、
既に画面に描画されている内容を
基にして画像ハンドルを作るので
ダブルバッファリングの裏画面の内容を取れないのだ。

たぶん、ダブルバッファリングの裏画面の先頭アドレスが分かれば
画面表示しなくても良いのだろうけど、
かげさんは、ちょっとわからない。
（知っている人がいたら教えて欲しいです）

４でファイルに保存しているのも、
保存しなくても良さそうなものだが
png_～関数たちが何をしているの分からないので
ファイルに保存せずにPNG形式の画像情報を
メモリに載せるやり方が分からない・・・

こういった手順になっているので
市販ゲームのほどスピーディには公式セーブダイアログが出てこない。
というか、2012/1/10版と比べてもセーブ処理は遅くなっている。
４と５のファイルの読み書きがなくなれば
ある程度の速度は確保できると思うんだけどね。

まぁ、この速度問題は、
セーブデータのアイコンとして
セーブ時点の画面状況が分かることに対する代償なので
現状は、仕方が無いと思っている。

ただ、上にある画面じゃさすがにダサいだろ
ということで、ちょっとキャンプメニューやシステムメニューを変えてみた。

もともとメニュー説明の噴出しの下には
かげさんの「ぼやき」が描画されていたのだが
その文言を取っ払って
セーブデータとして格納されるアイコンを出すようにしてみた。

今は、アイコン上のロゴの縁取りの白い部分の
がたがた加減が気になっているところ。

DrawExtendGraphでタイトルロゴ画像を縮小するのではなく
事前に縮小したアイコンを用意しておいた方が良いのでは？
と思ってみたり。

実際、Gimpで縮小したロゴと比較すると分かりやすい。
左がDrawExtendGraphで縮小したロゴのある画像、
右がGimpで縮小したロゴ画像だ。

Gimpでの縮小案を採用すると画像が増える、
しかもメモリに展開していた大きいサイズのタイトルロゴを
常に持っている必要性がなくなる
（タイトル画面だけデカイロゴがあれば良い）ので
タイトル以外ではデカイロゴのデータを解放しておいた方が
メモリを有効活用できたりするわけだ。

こんな風に関連箇所のソースコードが修正になったりして
意外と時間がかかっている。

Lua関連は、思ったほどメモリを使っていないようだったので
マップ切り替え時のLua関連の初期処理をちょっといじったくらいで済んだ。　

もう少しでメモリ関連のやりくりは、何とかなりそうだ。
ここが突破できたら、エアリアルステップで問題になっている
衝突処理に進むことになると思う。

ゲームプログラマになる前に覚えておきたい技術

この本の第８章が、そのものズバリなので
方向性を検討しようと思っている。

あまりにハマるようだったら、
気分転換に第１章のエンディングを先に作るかもしれない。

そもそもエアリアルステップは、第１章では使えない予定だ。
探索系のドラキュラでも２段ジャンプはアイテム入手後が多いみたいだし。

それかボカロタウンで登場するキャラたちの
顔グラを用意するとかしてるかも。

ボカロタウンの最初のバージョンに誰が登場するかは
まだ秘密と言うことで

４個パックのツナ缶が強くて困る

４個パックのツナ缶を買って初めて経験したこと。

縦に４つ連結している缶が
固くて取れなかった・・・(;´д｀)ﾄﾎﾎ…

１つが取れた途端に残りもポロポロと取れたのだが
かれこれ５分は対決したと思う。

強いな、ツナ缶！

ＤＸＰのLoadGraph内のLoadPngImageに怪しいところ発見！

DadrfyさんのDX Library Portable kai v3.2にある関数
MakeGraphFromScreenで作った画像ハンドルは問題なく
DeleteGraph後に完全解放されているので
怪しいのはDeleteGraphじゃない気がした。

そこで空きメモリチェック関数を1024バイト単位ではなく
1バイト単位にしてから
LoadGraphに焦点を絞って調べてみた。

LoadDivGraphでも内部的にLoadGraphを使っているので
LoadGraphが怪しいだろうと思ったからだ。

「初音ミク冒険記」で調べるのは、正直確認しづらかったので
確認用のちょっとしたプログラムを作って確認。
昨日、記事にした宝珠の画像１つに絞って調べてみる。

すると解放されないメモリサイズ1566に近いサイズのmallocに気付いた。
実際にmallocで確保しているのは1560バイト。

6バイト合わないけど、解放していないポインタのサイズとかの
問題かもしれないと想像。

問題の箇所は、loadgraph.cのLoadPngImage関数のbuf。

bufはローカル変数でparams.srcにアドレスを渡している。
paramsは、dxppng_decodeの引数なのでdxppng_decodeも確認。
srcを解放しているところは無い。

エラー時にはbufをfreeしているのだが
正常時にはfreeしていない。
やはりここが怪しいだろう。

そこで正常時のリターン
return texptr;
の直前に
free(buf);
と書いて確認してみる。

おぉ！
DeleteGraph後の空きメモリサイズが
LoadGraph前の空きメモリサイズ値とピッタリ同じになった！

一応、初音ミク冒険記とリンクして通しプレイし
第1章クリア後も数回セーブデータをロードしたりしてから
ログを確認してみる。

うん、どうやら「画像関連でのメモリ関連のおかしい」のはなくなったみたい。
なんか、それとは別に空きメモリが減っていっているようだが
おそらくLua関連の問題じゃないかなと想像している。

そもそもLua関連はロードしっぱなしで解放とか作っていないからな。
まぁ、それは次の問題と言うことで。

猫山Ｐの「png画像の読込＆削除を繰り返すと挙動がおかしくなる」が
これで解決すれば完璧にコレが原因だと思う。

あれ？DeleteGraphで解放されないメモリがあるぞ

「初音ミク冒険記」の第１章ボス戦のプログラムで
空きメモリのチェックをしていて気付いたこと。

どうやらDeleteGraphで完全にメモリ解放がされていない。

第１章のボス戦で使っている画像は３つある

１．ボスがトコトコ移動する画像

２．ボスがジャンプするときの画像

３．宝珠

これを１と２の画像は、LoadDivGraphでそれぞれ２枚の画像にして
３の画像は、LoadGraphで読み込んでいる。
読み込む順番は、１→２→３としている。
これまではDeleteGraphを使っていなかったがボス戦に勝利した後
３→２→１の順にDeleteGraphしてみた。

ログを抜粋し、説明用に英字を入れてみた
Ａ：Boss LoadDivGraph 1 before Free Memory=3,001,344 byte
Ｂ：Boss LoadDivGraph 2 before Free Memory=2,211,840 byte
Ｃ：Boss LoadGraph before Free Memory=1,423,360 byte
Ｄ：Boss LoadGraph after Free Memory=1,418,240 byte
＜中略＞
Ｅ：Boss DeleteGraph 1 before Free Memory=1,418,240 byte
Ｆ：Boss DeleteGraph 2 before Free Memory=1,422,336 byte
Ｇ：Boss DeleteGraph 3 before Free Memory=2,207,744 byte
Ｈ：Boss DeleteGraph after Free Memory=2,994,176 byte

期待していたのはＣの空きメモリとＦの空きメモリが一致していること
なのだが、1,024合わない。
同様にＢとＧも一致すると思ったのだが、4,096合わない。
同じくＡとＨも一致すると思ったのだが、7,168合わない。

LoadDivGraphは、１の画像を読み込んだ後に２つの画像に分けている。
つまりLoadDivGraph１回で内部的には３つのイメージハンドラを使っている。
ということは、LoadDivGraph２回とLoadGraph１回だと７つのイメージハンドルを使う。

DeleteGraph１回で未解放なのが1,024。
７つのイメージハンドル×1,024＝7,168となるので計算は合う。

これだと猫山Ｐが
「png画像の読込＆削除を繰り返すと挙動がおかしくなる」
で書いた通り、そのうち画像を読み込めなくなるだろう。

１つの画像ハンドルあたり1024バイトなのは
かげさんの空きメモリチェックの単位が1024バイト単位だからだと思うので
実際には、もっと少ない解放漏れかもしれないけど。

DadrfyさんのDX Library Portable kai v3.2にある関数
MakeGraphFromScreenで作った画像ハンドルは問題なく
DeleteGraph後に完全解放されているので
違いが分かれば解決できるかもしれないけど
DXライブラリPortableの中は難しいんだよなぁ・・・

PSPの空きメモリ

DXライブラリPortableのLoadGraph系関数が
エラーを返してくることがあるので調べてみたら、
やはりmallocでメモリ確保ができないでいるっぽい。

ならば空きメモリはどうなっているのか？

SDKの中に空きメモリを取得するものがあるだろう
と思い調べていたら
sceKernelTotalFreeMemSize
というのを発見。

カーネルってついているけど
ユーザモードでも使える関数なのかな？

実際に動かしてみる。
動いた。

どうやら使えるっぽい。

じゃあ、DeleteGraphの前と後で空きメモリを比べてみよう。

あれ？
DeleteGraphの前と後で空きメモリが同じなんだけど・・・

ちとくのホームページでメモリ関連を見てみる。
メモリの確保 その2によると
mallocで確保するヒープメモリと
APIで獲得するメモリは分けて考えるらしい。

DXライブラリPortableの内部ではmallocを使っているので
APIでは空きメモリが分からないようだ。

うーむ、と思っていたら
Dadrfyさんの「C言語？何それ？おいしいの？」の
「メモ -空きメモリ取得-」の記事に
空きメモリを取得する関数発見！

そうかmallocで確保できるメモリが空きメモリと判断するんだ。
確かに納得だ。
Dadrfyさんが記事を作ってくれていて助かった。

関数では、100KB単位でやっているので
ちょっと改造して100KB単位でメモリ確保できなかったら
10KB単位、同様に1KB単位として空きメモリのチェックをするようにしてみた。
これで若干精度があがるだろう。

試してみる。
うん、キャンプメニューを表示するときの画像をメモリに展開する前の空き容量と
メモリ展開した後のメモリ容量に変化があって
DeleteGraphするとメモリ展開前の空き容量と同じになった。
少なくとも1KBを超えるメモリリークはしていないようだ。

早速、ログで空きメモリを確認すると「初音ミク冒険記」では
DxLib_Initが正常終了した段階で空きメモリが約20M。

PSPのメモリは32Mで、8Mはカーネルに持っていかれるから残りは24M。
つまりDxLib_Initで4Mメモリを使っているってことだ。
たぶんイントラフォントとかの読み込みとかだろうと想像。

「初音ミク冒険記」の初期処理が終わって
タイトルロゴが出る段階では、空きメモリが6.7M。
初期処理では効果音のロード、
汎用的に使う画像の読み込み、
Luaの初期化をしている。
この段階でも結構メモリ使っているのね。

第１章のボス戦までのマップ画像を読み込むと、空きメモリが2M。
ここでキャンプメニューを表示し、その直前の画像をメモリ展開すると残り１M。
つまり、キャンプメニューを開く直前の画像をセーブデータのアイコンにしたければ
常にメモリを1M以上は空けておけってことだな。

うーん、こりゃ第１章のボスの画像を一度読み込むと
メモリがパンパンになってしまうのも、うなづける。

ボス画像の読み込み失敗の後に宝珠の画像が読み込めることがあるのは
単純にメモリ展開するときのサイズが小さいからだな。

となると、ボス戦のマップに入ったら
ボス戦のマップでは使わない画像をDeleteGraphして
ボス戦関連の画像読み込みするようにすれば良さそうだ。

後は、猫山Ｐさんが教えてくれたDeleteGraphを繰り返すと
DXライブラリPortableがおかしな動きをするって件の発生頻度しだいだな。

キャンプメニューに入るときにメモリ確保して
キャンプメニューを抜けるときにメモリ解放するようにしているので。

DXライブラリPortableの中を詳しくトレースしてないので
確定的なことは言えないけど
LoadGraphなどで取得した画像ハンドルをDeleteGraphして
もう一度画像ハンドルを作ると同じ画像ハンドルが返ってくるときと
違う画像ハンドルが返ってくるときがあるみたいなので
違う画像ハンドルが返ってきたときには、
前の画像ハンドルの分のメモリが
余分に使われている状態なのかも？と想像してる。
（検証が微妙なので気のせいかもしれない・・・）

一応、これで様子を見てみよう。

ごはんが炊けていなかった・・・ｏｒｚ

１月末までに受講しないといけない
ｅラーニングの１つ目が終わり
２つ目を始める前に晩御飯を食べようと思った。

今日は天気が悪いので家にあるもので作ろう。
どうやらカレーが良さそうな感じ。

ぐつぐつとカレーが出来上がった、その時
気付いてしまったのだ。
ご飯を炊くスイッチを押し忘れていたことに。

ｏｒｚ、なんてこったい。