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

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

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

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

class A{

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

};

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

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

FlyWightパターン的な。

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

//main

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

class A{

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

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

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

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

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

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

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

いわゆる「Now Loading」

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

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

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

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

class A {

static preTexture texture;//="pic"

}

//main

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

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

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

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