[過去ﾛｸﾞ] ゲームにおけるデータ構造・クラス設計・パターン2 (627ﾚｽ)

ゲームにおけるデータ構造・クラス設計・パターン2 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/

上下前次1-新
通常表示 512ﾊﾞｲﾄ分割 ﾚｽ栞
抽出解除 ﾚｽ栞

---

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ

---

501: 名前は開発中のものです。 [sage] 2009/03/18(水) 23:45:50 ID:1sOkzJT6 デバイスに直接アクセスする処理ってどこに書いてる？ 今まであちこちに散らばって状態で書いてたんだけどなんか扱いづらい。 下みたいな感じで一箇所にまとめた方がいいのかな。 今：あちこちでデバイスにアクセス void draw_landform(void) { 　　... 　　lpD3DDEV->draw(...); } void draw_menu(void) { 　　... 　　lpD3DDEV->draw(...); } 案：デバイスアクセスは１箇所。デバイスに渡すデータをあちこちで作る。 const DrawData *draw_landform(void) { 　　... 　　return ...; } const DrawData *draw_menu(void) { 　　... 　　return ...; } void main_loop(void) { 　　draw_data.push(draw_landform(), ...); 　　draw_data.push(draw_menu(), ...); 　　lpD3DDEV->draw(draw_data, ...); } もし既に案の方法でやってる人いたら使い勝手教えて！ http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/501

505: 501 [sage] 2009/03/20(金) 00:10:41 ID:/TREybMM レスありがとう。 >>502 「案」の方に似たやり方だよね？ draw_dataがリスト相当で。 やっぱやってる人いたか。採用してるってことは使いやすいんだろうか >>503 void LandForm::draw(LPDIRECT3DDEVICE9 lpD3DDEV) { 　　... 　　lpD3DDEV->draw(...); } みたいな感じ？ デバイスに直接アクセスする処理が複数のクラスに散らばるのはＯＫという判断？ この方が使いやすいってことかな？ うーん。。。 >>504 Draw_data::draw(...) { 　　this->lpD3DDEV->draw(this->draw_data, ...); } こんな感じ？　ラッパー作れって話？ 「案」ではないってことは 503 さん宛てのコードと同じ感じでやってるのか うーん、デバイスクラスに依存するクラスが増えると身動き取りづらくなると思うんだけど 気になる人って少ないんだろうか。 0人では無かったけれど。 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/505

509: 501 [sage] 2009/03/21(土) 12:54:05 ID:Y4F/PoMw >>506 今回の話ではModelとControllは関係なくて、Viewの枠内だけで完結する話だと思ってる >>507 複雑すぎて俺の頭では完全には理解できないけど、 >    virtual void visit(Landform& x) { pDevice->draw(x.getLandData()); } >    virtual void visit(Menu& x) { pDevice->draw(x.getMenuData()); } ここを見るとデバイスに直接アクセスする処理を１クラス内、複数関数にまとめたって感じかな うーん…、複数の関数にデバイスアクセス処理が分散してるとこがあまりうれしくないかな。 （俺には複雑過ぎるのはさておき） 俺が扱いづらいと思ってるところは、 pDeviceさえあればdraw()以外にもbegin_render()とかset_camera()とかいろいろ デバイスに対して変更加えることができちゃうわけで、 それをばら撒くってことはいつどこでデバイスに変更が加わるか、例えばいつどこで何回begin_render()されてるのか とかが追跡しづらくなる。これは１週間後の自分に優しくない。 こんな感じでデバイスに直接アクセスする処理をどう管理したもんかと考えて ひとつの対策案としてデバイスアクセス処理を１関数内に限定しちゃえってのが >>501 の「案」。 だから例えば複数の関数に同一デバイスへのアクセス処理が分散してるのは自分的には問題が解決していないと感じる。 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/509

510: 名前は開発中のものです。 [sage] 2009/03/22(日) 03:32:29 ID:O7e3N6nq 描画するにはデバイスに対して様々なパラメータを設定しなけりゃならんわけだが >>501だとそこをどう処理するのかがよく分からない。 各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？ そうじゃないなら、結局デバイスをやりとりしなきゃならなくなるような。 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/510

511: 501 [sage] 2009/03/23(月) 00:38:25 ID:/nVLLFvd >>510 確かに。描画スクリプトかー、どうしよう。 ポリゴンの描画順番の最適化とかやり始めたら必要になりそうな気もするけど 今の自分のプログラムでは大げさすぎるかなぁ。今のところ2D的にしか使ってないし。 あとデバイスってサウンドとか入力装置とかもあるけど、それらもおんなじ感じで取り扱いたいし。 デバイスにアクセスする処理が関数１個の中に「ひとまとまりで」収まってればＯＫとするなら 下のように書いて済ませられるかな？ void dev_state1(void) { 　　lpD3DDEV->BeginScene(); 　　lpD3DDEV->set_parameter(...); 　　lpD3DDEV->draw(draw_landform(), ...); 　　lpD3DDEV->set_parameter(...); 　　lpD3DDEV->draw(draw_menu(), ...); 　　lpD3DDEV->EndScene(); } ひとまとまりってのは１フレーム分のデバイスアクセス処理全部。 描画内容を大きく変えたい時はdev_state2()とかをまた別に作っておいて、 ゲームのステートに応じてどれを実行するか切り替える。 なんか描画スクリプトの方が夢があるな。 外部GUIツールで描画内容を設計して 吐き出した描画スクリプトをゲームで解釈して表示とかおもしろそう。 でも描画システムの根幹過ぎて汎用的に作るのめんどくさそう。。。 うーん、とりあえず簡単に済ませたいからdev_state1()みたいにベタ書きで どこまでいけるかやってみるかな。 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/511

552: 名前は開発中のものです。 [sage] 2009/11/16(月) 14:29:49 ID:FF5xAAX0 >>501 その後どうなった？ 俺も今描画周りを考えてる http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/552

563: 501 [] 2009/12/30(水) 05:37:23 ID:CHdRD74o >>552 描画スクリプトっぽく進めてる。>>510 の言うとおりの方法。 >各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？ 描画スクリプトみたいなのを作るほうがプログラム構造は単純になった。 >>511に書いたやり方は結局デバイスアクセス処理が分散していて大して煩雑さは改善されなかった。 簡単な2Dゲームだと描画は大部分が画像描画コマンドだけで構成されてた。思ってたより単純。 あとは少ないながらもカメラ位置変更コマンドと文字列描画コマンドも使った。 コマンド構造体を配列に突っ込んでカウンタを+1とかしてコマンド列（描画スクリプトみたいの）を作ってる。 あと画像描画コマンドでは描画すべき画像は番号で指定してる。番号に対応する画像を用意するのは解釈側の責任。 デバイスデータの引き回しはなるべく避けたかったので。 デバイスを関数間で無闇に引き回さなくても済むようになったので気が楽だし、 メモリデータの変更だけで描画内容が変わるのもおもしろい。 やって良かったと思ってる。 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/563

564: 501 [sage] 2009/12/30(水) 22:40:42 ID:CHdRD74o >>563を読み返したらちょっと違うところがあったので訂正。引用したこの文。 >各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？ 自分の場合、描画スクリプトを作るのは「各オブジェクト」というより「各シーン管理オブジェクト」になった。 つまり シーン管理オブジェクトが自身の所有する各オブジェクトの情報をアクセサ経由で読み取って 描画スクリプトみたいなものを組み立てる。 たくさんある細かい各オブジェクトに描画スクリプト的なものを作成させるのは責任というか依存性が散らばりすぎて複雑になる。 だから数の少ない管理オブジェクトがconst修飾済みの読み取り専用オブジェクトから得た情報だけを元に描画スクリプト的なものを組み立ててる。 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/564

---

ﾒﾓ帳

(0/65535文字)

---

上下前次1-新書関写板覧索設栞歴

---

ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ

---

Google検索

Wikipedia

---

ぬこの手 ぬこTOP 0.019s