今プログラムの構造について悩んでおりまして…
DXライブラリで画像や音声データなどをロードしてハンドルを取得しますよね。
今リソースを一括ロードして配列に格納、必要なときにハンドルを取得するということをしたいのですが、
予め大きく要素数を確保したグローバルな配列を用意して取得してくるべきか、
ハンドル群を管理するクラスを用意してデータが必要なときにそのクラスを渡して取り出すべきかで悩んでます。
前者はとても楽でプログラムの見た目的にもわかりやすくすっきりした感じになるのですが
メモリとかの視点で見たらこれでいいのか不安になってきます。
後者はそのメモリの方では問題はないのですがクラスのやり取りで
プログラムが見た目と構造双方の意味でめんどくさくなってしまいます。
どちらのほうがいいかご意見のほどよろしくお願いします。
ロードした画像などのデータの取り扱い
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: ロードした画像などのデータの取り扱い
オブジェクト指向的には、各クラスが自分で利用するリソース(画像など)を管理しているのが望ましいのですね。
一括配列ロードはデータの受け渡しとか、すごくオブジェクト指向っぽくない動作になる気がします。
簡易化した擬似コードとかでやりたいことを示してもらうと、具体的な回答が得られやすいと思いますので書いてみてもらえませんか?
一括配列ロードはデータの受け渡しとか、すごくオブジェクト指向っぽくない動作になる気がします。
簡易化した擬似コードとかでやりたいことを示してもらうと、具体的な回答が得られやすいと思いますので書いてみてもらえませんか?
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: ロードした画像などのデータの取り扱い
具体的にはシーンごとに使うリソースを一括でロードして
リソースを使うクラスを生成するときにハンドルを渡したいです。
クラス生成する度ロードするのはよろしくないので(当たり前ですが)
とりあえず先ほどの前者の方で書いてみます
リソースを使うクラスを生成するときにハンドルを渡したいです。
クラス生成する度ロードするのはよろしくないので(当たり前ですが)
とりあえず先ほどの前者の方で書いてみます
//データを格納する領域を用意するヘッダー
#define RESOUSE_MAX 1024
static int RESOUSEDATA[RESOUSE_MAX];
int GetDataHnd(int dataID)
{
return RESOUSEDATA[dataID];
}
//1シーンを定義したクラス
//メンバ変数にEffectクラスmEffを用意
void PlayScene::PlayInit()
{
//シーンに対応したロード作業
LoadData(SCENE_PLAY);
mEff.Initialize();
}
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: ロードした画像などのデータの取り扱い
画像データを管理するクラスをグローバル公開するのは有りだと思いますけど。
シングルトンで1つだけ生成してグローバルクラスにして、画像データをもらうときにはそのクラスにアクセスするってのはどうでしょう?
これなら、生成したデータ管理クラスを受け渡さなくて良いですし、ロードや破棄のメソッドも作れるし、まぁあんまり元と変わっていないと言う感じもしますが。メモリリークを避けるためにデストラクタが使えるのが唯一のメリットかな。
あと配列で管理せずにSTLのvectorかmapを使うことをお勧めします。
シングルトンで1つだけ生成してグローバルクラスにして、画像データをもらうときにはそのクラスにアクセスするってのはどうでしょう?
これなら、生成したデータ管理クラスを受け渡さなくて良いですし、ロードや破棄のメソッドも作れるし、まぁあんまり元と変わっていないと言う感じもしますが。メモリリークを避けるためにデストラクタが使えるのが唯一のメリットかな。
あと配列で管理せずにSTLのvectorかmapを使うことをお勧めします。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: ロードした画像などのデータの取り扱い
グローバル生成したクラスですかね、やはり…
まあ自分が心配しているのはデータの倉庫として扱う配列なりクラスなりのグローバル化が
果たしてプログラミングのマナー上よろしくないのかどうかってことで前者の方法とその提案された方法を躊躇してました。
で、最初後者のクラス渡しでやってたんですがどうも見た目がわかりにくいし打っててめんどくさかったので…
まあ自分が心配しているのはデータの倉庫として扱う配列なりクラスなりのグローバル化が
果たしてプログラミングのマナー上よろしくないのかどうかってことで前者の方法とその提案された方法を躊躇してました。
で、最初後者のクラス渡しでやってたんですがどうも見た目がわかりにくいし打っててめんどくさかったので…
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: ロードした画像などのデータの取り扱い
配列などをグローバル公開するのはいただけませんが、管理クラスを公開するのは私的にはありだと思います。
ロードできていないデータのアクセスをトラップできますし、不用意に破棄される心配もありません。
>「最初後者のクラス渡しでやってたんですがどうも見た目がわかりにくいし打っててめんどくさかったので…」
これは、結局管理クラスに依存してますのクラス間の依存度の意味合いにおいては引数であろうとグローバル公開であろうと変わりません。
あとは、どちらが楽かとかデータの変更タイミングが分りやすくバグがでないと言う話ですが、管理クラスに集約しているのでさほど問題はないと思います。
と言っても私がゲームプログラマやってた時はC言語ばかりで組んでいたのでC++の本格的ゲームプログラミングとしては他に人と共同作業した事がありません。会社や人によっても意見は違うと思うので他の人の意見を待ってみるというのも良いんじゃないでしょうか。
ロードできていないデータのアクセスをトラップできますし、不用意に破棄される心配もありません。
>「最初後者のクラス渡しでやってたんですがどうも見た目がわかりにくいし打っててめんどくさかったので…」
これは、結局管理クラスに依存してますのクラス間の依存度の意味合いにおいては引数であろうとグローバル公開であろうと変わりません。
あとは、どちらが楽かとかデータの変更タイミングが分りやすくバグがでないと言う話ですが、管理クラスに集約しているのでさほど問題はないと思います。
と言っても私がゲームプログラマやってた時はC言語ばかりで組んでいたのでC++の本格的ゲームプログラミングとしては他に人と共同作業した事がありません。会社や人によっても意見は違うと思うので他の人の意見を待ってみるというのも良いんじゃないでしょうか。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: ロードした画像などのデータの取り扱い
うーむ、了解しました。
一応グローバル生成したクラスの方法を取ってみます。
ご意見ありがとうございました。
と言ってる合間にも途中で切れるレーザー作りとか弾幕風ライクな記述の再現とか
色々難しい悩みが出てきてしまっているこの現状。
とりあえず調べたり書籍買って勉強してみます…
一応グローバル生成したクラスの方法を取ってみます。
ご意見ありがとうございました。
と言ってる合間にも途中で切れるレーザー作りとか弾幕風ライクな記述の再現とか
色々難しい悩みが出てきてしまっているこの現状。
とりあえず調べたり書籍買って勉強してみます…