読者です 読者をやめる 読者になる 読者になる

ゲームプログラミング等における画像などリソースの管理がわからない

ゲームプログラミングあるある。リソース管理がだるい

何がだるいね?というといまいちスマート感に欠ける辺りがとてもだるい

  • 管理法1:管理しない

とてもKOOLなメソッド。とても直観的、とても奇麗。そしてとても...Big♥

class A{

Texture texture;//=Texture("pic")

};

textureの諸々の使用メモリが30byteぐらいだったら割と普通の方法。でも実際はその10倍以上ある

Aが大量に生成されるクラスじゃなければ、例えば背景クラスとかならこれでもいい気がするけどエフェクトとか敵キャラとかの場合はまあ、うん。大変だね

 

  • 管理法2:リソース管理クラスを使って起動時にガっと読み込む

FlyWightパターン的な。

自作するもよいし、既存のものを使うもよいし

//main

GraphLoad();//なんやかんやを読み込む関数

class A{

const Texture &texture;//=TextureAsset("pic")

};

どこか(主にstaticな空間)にtextureを管理するクラスがあってそこから検索して引っ張ってくる

管理クラスを使う場合(使わない場合に比べて)複数Aが作られる場合に強い

この方法は積極評価であり、大きかったり前処理が必要なリソースには強いが、余計な画像を読み込むことになるかもしれない。あとGraphLoadに”LoadLoadLoad...”と命令が続くことになり大変吐きそう

 

  • 管理法3:リソース管理クラスを使って必要になったら読み込む

メインでLoad関数が無くなるだけで コードは大体上と同じ。管理クラスは必要に応じて画像を読み込む

管理クラスを使う利点は2と同じだがこれは上に比べて前処理や大きいリソースに弱い。ただし、余計なリソースを読み込まないで済むという利点がある。あとLoadLoad書く必要がない

 

  • 管理法3.5:(参照カウント式)リソース管理クラスを使って必要になったら読み込む

Boost::Flyweightとか。上の2,3ではうっかりうっかり解放について書いてない(というか原則解放されない)がこれは管理法3に解放処理を加えたものである。これの利点はメモリが必要に応じて解放されること。欠点は 一つのオブジェクトのみで参照る場合管理法1と同じになってしまうこと

 

  • 管理法4:適当なタイミングで一気に読み込み解放する

いわゆる「Now Loading」

積極評価と遅延評価の中間をいいとこどりしようとしたもの。悪くないがLoadLoadLoadが管理法2以上にメンドイ

 

管理法4ないし2を使う場合の面倒臭さはキャラクタークラスAで使う画像をその画像を直接必要としない誰かに読み込ませる歯痒さに起因していると思われる

これをなんとか解決しようとした場合、Aが使われる……つまりインスタンス化される前にどこかAの所有者なりなんなりが画像を読み込む必要がある

それをするために無理矢理思いついた方法のがクラスpreTextureをAにstaticで持たせてstatic構築時に必要な情報を持たせるとなんやかんやで画像がロードされるという方法

class A {

static preTexture texture;//="pic"

}

//main

preTexture::data;//={"pic",......}

 実装については何も考えてないが仮にうまくいったとすると、mainに入る時には規定のどこかに必要なリソースの情報が溜まることになり、歯痒さは全自動化される

 

 

ただ便利か?というと悩ましい。歯痒さは減ったが別のところがなんかかゆい

嗚呼リソース管理がわからない