ゲームにおけるデータ構造・クラス設計・パターン

**名前は開発中のものです。** · 2006/08/10(木) 20:27:06

具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。

**名前は開発中のものです。** · 2007/01/31(水) 19:22:58

弾幕だったら各機で同時に発射しうる最大数に応じた領域確保しちゃうかな。
頂点バッファは１つあれば十分だし。

**名前は開発中のものです。** · 2007/01/31(水) 20:28:29

>>219
パーティクルは出現数の上限を決めて、それを超えたら適当に消すのが常套手段。
多少消えても人間は気づかんから。

メモリ管理自体は PS2 以降のハードなら大した工夫は要らなくて、pool なり STLport の
node allocator なりで十分な性能が出る。それよりベクトル演算効率化することを考えとけ。

**名前は開発中のものです。** · 2007/01/31(水) 22:47:38

>>221
おまいの賢さは分かったが数個前のレスくらい読んでやれ

**名前は開発中のものです。** · 2007/01/31(水) 23:00:17

>>222
同時に発射しうる最大数を確保して超えないことを保証するのと、適当な数を
確保しておいて越えたときに消しちゃえってのは、一見似てるけど使いどころが
違う。

一般にヒット判定があれば前者、単なる見た目だけなら後者。ヒット判定がある
ものを適当に消すと致命的なバグになったり、予期せぬ挙動をすることがある
ので。

**219** · 2007/01/31(水) 23:25:03

まあ、実際、別のプロジェクトで、毎回、インスタンス生成しても、
描画の方が圧倒的に遅すぎるというプロファイル結果が出たりしたので、
そんなに神経質になる必要はないんですけどね orz
（動作環境は、PCです）

新しいプロジェクトで、
パーティクル一杯出したいから、それぐらいは、pool化したいなって思ったんです。

**名前は開発中のものです。** · 2007/03/21(水) 22:27:58

>>224
シミュレータの場合、速度最優先で描画をしない状況もあるから、
それが免罪符にならない場合もあるんだよね

**名前は開発中のものです。** · 2007/03/23(金) 13:48:25

良スレage

**名前は開発中のものです。** · 2007/03/26(月) 06:10:31

ところで、
キャラクターの構造体は何で取ってる？
今じゃ普通にダブルでとっても問題ないよな。
むしろ、その方が微調節がしやすくって良いよね。
俺は貧乏癖がついててイントでとって微調節がやり辛くなって、
結局後で困ったりしてるんだよね。

皆は何で取ってる？

**名前は開発中のものです。** · 2007/03/26(月) 06:11:56

あ、ゲームは普通の２ｄのアクションゲームとかです。

**名前は開発中のものです。** · 2007/03/26(月) 08:35:24

doubleでおｋ

次の話題どうぞ

**名前は開発中のものです。** · 2007/03/26(月) 12:51:40

単純にintのかわりにすると計算誤差で困ることも多いからちゃんと使ってくれ
具体的にはイコールで判定とかやっちゃだめだぞ

**名前は開発中のものです。** · 2007/03/26(月) 18:43:03

>>227
自分で固定小数点数作るのが楽ちんだろ
浮動小数点数の等号問題も出ないし

**名前は開発中のものです。** · 2007/03/26(月) 19:09:19

桁落ちの誤差で困ったことはないなあ。
「本当はセーフだったのに、桁落ちしたせいで等号が成立して
　敵に当たったことになって死にました」みたいな状況は
あるだろうけど、まず気づかないと思うし。

そのあたりを完璧にしたいのであれば、丸め誤差も考慮に入れて
10進固定小数点数クラスを作らなければならないだろうけど、
そこまでしたくないというのが正直なところ。

**名前は開発中のものです。** · 2007/03/26(月) 19:20:52

>>232
そんなクラス作らなくてもいいんじゃね？
16ビットシフトするだけでゲームの精度的には十分かと。

**名前は開発中のものです。** · 2007/03/26(月) 21:35:29

ttp://shinh.skr.jp/template/gamenum.html

**名前は開発中のものです。** · 2007/03/26(月) 22:10:26

>>232
なんか勘違いしてるけど、固定小数点数にするのに１０進は関係ないぞ。

**名前は開発中のものです。** · 2007/03/26(月) 22:13:45

>>235
10進って言ったのは、丸め誤差を考慮しての話なんだけど。
桁落ちとは関係ない。

**名前は開発中のものです。** · 2007/03/27(火) 01:42:55

10進でも2進でも丸め誤差は出るってば。

**その1** · 2007/03/27(火) 06:12:21

「キャラの座標の型に関して」

・整数か小数か -> 断然小数

・小数の表現方法
　-> 浮動小数点数 or 固定小数点数
　-> 2進表現 or 10進表現

・浮動小数点数
　○ 基本型であるので扱いが楽
　× 演算速度が遅い
　△ 非常に近い値同士を比較したときに桁落ちが発生する
　　 (桁落ちが発生したところで別段問題がない場合も多々ある)
・固定小数点数(クラス実装)
　○ 比較による桁落ちが発生しない
　○ 実態は整数型なので演算速度が早い
　　-> × 汎用性の高い実装(シフト数の異なる固定小数点数同士でも演算を
　　　　　可能にするなど)を行うと、結局浮動小数点数以下の演算速度に
　× 固定小数点数オブジェクトの生成が頻繁であると遅くなる
　　 (特にオペレータ・オーバーロードに注意)
　△ 小数点以下の精度(桁数)が固定
　　 (ただし、精度が足りなくて困ることはまず無いと思われる)

**その2** · 2007/03/27(火) 06:13:22

・2進表現
　○ 基本型は2進表現なので扱いが楽
　× 10進表現で有限小数となるが2進表現で循環小数になるような値の場合、
　　表現できない桁が切り捨てられるなどして丸め誤差が発生する

・10進表現
　○ 循環小数に対する丸め誤差が起きない
　　-> × 一般によく使われるであろう加算減算処理では問題ないが、
　　　　　除算を行うなどすると何進数であろうが丸め誤差は発生する
　XX 基本型とは程遠い別次元の演算手法が要求される
　　 (2進表現で循環小数となるような値を基本型で記述した時点でアウト)
　× 同じバイト数で表現できる値の範囲が2進表現より狭い

勝手にまとめっぽい形式で書いてみた。
固定小数点数に関してはクラスとして実装した場合を想定した。
個人的に、固定小数点数を素のintで表現して、その都度シフト変換を行うような手法は、
変換方法に依存した関数/クラスを大量発生させるので論外だと思う。

**名前は開発中のものです。** · 2007/03/27(火) 06:39:01

10進表現ってBCDのことだったの？
俺はてっきりintを10^nで割って使う話だと思ってた。

**名前は開発中のものです。** · 2007/03/27(火) 06:42:53

色々書いたけど、結局俺は無難なdoubleを使っちまうかなあ。
試しに固定小数点数クラスを作ってみたけどあんまし早くならなかった。
っていうかコンパイラによって速度が大きく変わりそうな予感。

10進表現での計算は、誤差が出たら切腹必至の
銀行システムとかでのみ使うものだと思っている。
言語的にサポートされていれば話は別だけど。

以上長文&駄レスすまん。

**名前は開発中のものです。** · 2007/03/27(火) 06:45:51

>>240
俺は流れ的にBCDのことだと思ったが…。違ってたらすまん。

**名前は開発中のものです。** · 2007/03/27(火) 10:06:48

昔は、固定小数点使ってたな
今は、さすがに、浮動小数だわ

問題は、環境によっては、リプレイでずれるとかその辺
（D3DXの最適化とか最適化とか最適化とか）

**名前は開発中のものです。** · 2007/03/27(火) 12:34:52

浮動小数点だと0.1ですらがあらわせないからな
表せないのに無理しているのが浮動小数点
あらわせないのなら扱わない、問題が出ないようにするのが固定小数点

0.1を10回たしたら１になるとか思ってるような人は固定小数点つかっとけと

**名前は開発中のものです。** · 2007/03/27(火) 14:36:14

アナログコントローラーとか3D処理やったこと無いのかな

**名前は開発中のものです。** · 2007/03/27(火) 19:55:06

Flashとかだと0.5ずつずらさないと隙間が空くとかあるんだよね

**名前は開発中のものです。** · 2007/03/27(火) 20:06:13

微妙に関連する話題だと思うんだけど、
皆は(無限)多倍長精度整数を使ってたりする？

**名前は開発中のものです。** · 2007/03/28(水) 00:55:28

>>247
固定小数点数使ってたら、上の桁が足りなくて、
仕方なしに64ビット整数を使っちゃったことはある

**名前は開発中のものです。** · 2007/03/28(水) 05:12:49

>>247
そういうのは学術用だと思うよ。
ゲームなら実際問題そんないらんっしょ。

**名前は開発中のものです。** · 2007/03/28(水) 05:53:37

得点計算で使われることもあると思う。
32bit符号なし整数では40億程度しか表せないし。

恐ろしい桁数の得点をガンガン加算させて、
かつ一の位までキッチリ使っちゃうような
血も涙もない鬼の方御用達です。

**名前は開発中のものです。** · 2007/03/28(水) 07:59:56

無限多倍長精度整数って書いてるんだよな。
long longより上だと3倍長で7.9x10の28乗とかになるけど……要るか？

**名前は開発中のものです。** · 2007/03/28(水) 11:11:39

>>249
んなーこたーない。
経営シミュレーションで多倍長な変数を使うことはあるよ。
キャッシュとか資産とかの額で。
まさか、浮動小数点使うわけにはいかんし。

**名前は開発中のものです。** · 2007/03/28(水) 12:08:50

ビルゲイツの資産とか32bitに収まりきらんもんな

**名前は開発中のものです。** · 2007/03/28(水) 12:54:06

そもそもビルゲイツの資産は、株価がちょっと変わるだけで
とんでもない額が変動するから、下の方の桁にあまり意味はない。

**名前は開発中のものです。** · 2007/03/28(水) 15:10:12

32bitどころじゃないだろ。

まあ、毎年訳分からん団体に１兆寄付してるおっさんだからな。

寄付してるのは妻の方だけ？

**名前は開発中のものです。** · 2007/03/28(水) 16:57:57

自分の設立した財団じゃないのあれ？

**名前は開発中のものです。** · 2007/03/30(金) 00:16:52

Delphiの日付用構造体TDateTimeを馬鹿にするなよ？
日付なのに、不動小数

**名前は開発中のものです。** · 2007/03/30(金) 01:10:16

不動ならいいや('ー`)

**名前は開発中のものです。** · 2007/03/30(金) 03:52:48

MSのAccessも日付はdoubleでもってたような・・・

**名前は開発中のものです。** · 2007/04/01(日) 02:13:01

いいシーン管理方法が思いつかない…。
「シーンはスタックに積む」って話をよく聞くけど、
積みっぱなしでメモリは大丈夫なのかとか、
タイトルシーンやメニューシーンはその都度生成した方が
再初期化の手間いらずで楽なんじゃないかとか、
ロードの際にスタックの中身をいちいち
再現しなきゃいけないんじゃないかとか、色々疑問が残る。

**名前は開発中のものです。** · 2007/04/01(日) 13:27:10

>>260
何が「いい」かは作るプログラムによって違うからな。
疑問に思うんならやってみろとしか言えない。

**名前は開発中のものです。** · 2007/04/01(日) 14:21:19

なるほどそういうときにシリアライズを使うのか

**名前は開発中のものです。** · 2007/04/01(日) 15:15:13

>>260
Gemsの５巻にスタックを使ったシーン管理が載っている。

試してみたら、なかなか使い易かったよ。

**名前は開発中のものです。** · 2007/04/01(日) 15:35:35

>>262
javaのシリアライズの話ならそういう時の為のものじゃないぞ

**名前は開発中のものです。** · 2007/04/01(日) 20:39:12

>>260
作ってるゲームによるでしょ。

シーン切り替えの度にブラックアウト & ロード処理が入るふつーの RPG だと、
シーンは必要な都度 new して作る（ただしテクスチャ・モデル等のリソース類は
事前に割り当て決めておく）、状態遷移はプログラム側でベタに行う…で十分に
管理できる程度だった。

**名前は開発中のものです。** · 2007/04/05(木) 20:02:57

>>263
Gemsうｐ！！
って、無理だｗ

ソースコードだけでも配ってないのか・・・

**名前は開発中のものです。** · 2007/04/06(金) 02:24:49

【警告】
日本はカルト教団に支配されてしまいます。
選挙に行きましょう。

**名前は開発中のものです。** · 2007/04/06(金) 16:07:18

スタックベースのシーン管理に参考になるページはないですか？

**名前は開発中のものです。** · 2007/04/07(土) 09:34:17

どっかのやねうの昔のサイトに解説がなかったか。

**名前は開発中のものです。** · 2007/04/07(土) 12:47:03

YaneSDK.Netのソース読め

**名前は開発中のものです。** · 2007/04/08(日) 01:31:41

本人がいらっしゃるようなので一言申し上げますが
yaneSDK3rdの更新してください＞＜
2ndからトランジエントビルトを移植しようとしたんですが正直無理です＞＜

**名前は開発中のものです。** · 2007/04/08(日) 01:42:46

無理とか言ってたらなんも成長しないがな。
つか本人が来たとか本気で思ってるのか。

**名前は開発中のものです。** · 2007/04/08(日) 02:50:06

皮肉にマジレスしてどーする

**名前は開発中のものです。** · 2007/04/08(日) 13:14:13

そういや、やねうらおの会社の社員が、やねうらおを訴えた件はどうなったんだろうな。

**名前は開発中のものです。** · 2007/04/09(月) 03:25:15

騙された馬鹿が、ギャーギャー文句言ってただけ

**名前は開発中のものです。** · 2007/04/09(月) 03:38:12

いい加減スレ違い。

**名前は開発中のものです。** · 2007/04/09(月) 13:14:13

スタックベースのシーン管理について質問

つくってみたけど、いまいち利点がわからん・・・
何が便利なんだろう・・・

**名前は開発中のものです。** · 2007/04/09(月) 15:13:20

スタックみたいな古臭いのじゃなくて
デザインパターンでオブジェクト指向的にスッキリと出来ないものなんだろうか

**名前は開発中のものです。** · 2007/04/09(月) 16:14:10

シーンをオブジェクトと見なしてスタックに積むんだから、
十分オブジェクト指向じゃないかと思うんだけど、そういうことではない？

**名前は開発中のものです。** · 2007/04/09(月) 18:50:04

>>277
利点かー。
末端のシーンがどこに戻るか把握しなくていいから、シーンを柔軟に組めるとか、シーンを再利用しやすいとか。
ごめん、思いつきで書いた。

**名前は開発中のものです。** · 2007/04/09(月) 20:46:27

>>279
うん。
それ自体が定型になるなら、スタックベースのシーン管理というのも
ゲームにおけるデザインパターンといっても過言ではないと思う。

**277** · 2007/04/09(月) 20:49:46

とりあえず、googleして、定番とおもわれる

・呼び出し（Call)
・移動(GoTo)
・呼び出し側に戻る（Return)

をシーン管理オブジェクトに、実装して、シーンを状態遷移してみたりしたんだけど、

これって、シーンを遷移するときって、前のシーンは開放しちゃっていいのか？
開放しちゃうと、
しなかったらしなかったで、リソース圧迫するし

クソー、Game Programing Gems 5がほしいZE

**277** · 2007/04/09(月) 20:54:13

> 開放しちゃうと、
開放しちゃうと、呼び出し(Call)の意味あんのかな？と思うし

**名前は開発中のものです。** · 2007/04/09(月) 23:33:21

ところでシーン間の関係はだれが持つの？

シーンクラス？シーン管理クラスとか他のクラス？

分岐のあるゲームだとこれ重要。
次に進めるべきシーンを決める奴が持てばいいのか・・・？

シーン遷移管理とシーン関係管理＋フラグ管理に分けるとか？

>シーンを遷移するときって、前のシーンは開放しちゃっていいのか？

javaだとこれ厄介なんだよね。何しようが使ってなかったら勝手に拾われるから。
一応クリーンアップなりシャットダウンなり処理して放置かな。

こういうときにファイナライザ使うもんじゃないしね。

**名前は開発中のものです。** · 2007/04/10(火) 00:13:19

>>277
シーンは最初に全部確保して
最後に全部解放してるよ。

シーンスタックそのものが「アクティブなシーン」のスタックであって、
今アクティブじゃないシーンは別のリストに保管してる。
でスタックに積まれてるものは一通り処理する。

こうすることで移動画面中にメニューも表示して移動もメニュー選択も可とか
裏画面でデモ（通常ゲーム処理）回しながら上にウィンドウ表示とか
出来ますよ　って趣旨だったと思う >Gems5

ただ、ウィンドウ関係以外には特に利点は無さそう。

**名前は開発中のものです。** · 2007/04/10(火) 01:08:35

マルチスレッドを実現する手段の一種ということ？

**名前は開発中のものです。** · 2007/04/10(火) 01:12:58

>>285
＞でスタックに積まれてるものは一通り処理する。
これ、厳密にはスタックって呼べなくね？
LIFO≠スタック

**名前は開発中のものです。** · 2007/04/10(火) 01:16:37

なんだ、シーンの遷移がスタック的なのかと思ってた。

**285** · 2007/04/10(火) 01:26:00

>>287
上にシーンを積んだときにサスペンド処理（シーンクラスのメソッド）を呼ぶようにして
サスペンド中も実行したいシーンはその処理でサスペンド時も実行してねフラグを立てる
とかそんな処理になっていたと思うから　一応一番上に積まれているのが
現在のシーンってことになる。
立ち読みだから細かいことは忘れたｗ

スタック全体をなめるんだからスタックとは言わないと俺も思う。

**277** · 2007/04/10(火) 01:59:26

わかった。
かなり勘違いしていた・・・。

>>288
俺もそう思ってたｗｗ

**名前は開発中のものです。** · 2007/04/10(火) 09:19:06

これ読んで、久々にパックマン作りたくなったな～。
アクションゲームは、作ってないけど、デザインパターンを、正しく使うと、プログラムがスッキリするし、大好き。
デザインパターンって、しらない人多いのかな？

**名前は開発中のものです。** · 2007/04/10(火) 09:47:11

Large-Scale Stack-Based State Machines
James Boer
Game Programming Gems 5, 2005.

**名前は開発中のものです。** · 2007/04/11(水) 01:26:38

>>291
> デザインパターンって、しらない人多いのかな？
んなわきゃない

**名前は開発中のものです。** · 2007/04/11(水) 05:40:08

スタックベースのシーン管理、結局、状態遷移をスタックベースに作ってしまったｗ

これで、

　タイトル画面→(呼び出し)→ゲーム処理→(戻る)→タイトル画面

とか、
　タイトル画面→(呼び出し)→リプレイのメニュー→(呼び出し)→ゲーム処理→(戻る)→
　リプレイメニュー→(戻る)→タイトル画面
とかできるようになったｗ

スタックベースといったらやっぱりこっちだろｗ

**名前は開発中のものです。** · 2007/04/11(水) 05:56:16

スタック的に自然な状態遷移しかしないのであれば役に立つだろうけど、
そうではない大部分のゲームにとっては役立たず以外の何物でもないと思う。

**名前は開発中のものです。** · 2007/04/11(水) 07:47:20

スタックというデータ構造を状態遷移を表現するために利用するからには
・次のシーンに移る＝push操作
・1つ前のシーンに戻る＝pop操作
という対応関係が常に成り立っていて、この操作のみで完結すべきなんだが、
これだけの操作でOKなゲームがどれだけあるかっていうと、ぶっちゃけほとんどない。
スタックにこだわるあまり、データ構造を破壊したり
オブジェクトの役割を破壊したりするような例が後を絶たないのだが、
>>279と>>281のようなやり取りが行われている現状では仕方がないか。

**名前は開発中のものです。** · 2007/04/12(木) 03:38:40

実質が状態遷移ならstateパターンでいいやんって事ですか？

**名前は開発中のものです。** · 2007/04/12(木) 04:43:05

>>297
Stateパターンとか全く関係ないよ。
シーンの遷移をうまく表現するためのデータ構造に関する話。

どこまで理解しているかわからないから基礎から説明する。
Stackというデータ構造は、
・オブジェクトを1つStackに積むpush操作
・最後にStackに入れたオブジェクトを1つ取り出して捨てるpop操作
・最後にStackに入れたオブジェクトを参照するtop操作
を持つ。ここで、
・push操作＝次のシーンに移る
・pop操作＝1つ前のシーンに戻る
・top操作＝現在のシーンを取得する
と対応付けると、これはシーン管理に使えそうだぞってことになる。
これが、今話題に上がっているStackベースのシーン管理。

これをStateパターンにしたところで、Stackの中に入るオブジェクトが
シーンオブジェクトから状態オブジェクトに変わるだけで、
シーン遷移のための操作やベースとなるデータ構造は変化しないってのはわかる？

**名前は開発中のものです。** · 2007/04/12(木) 05:16:23

(続き)
で、何故Stackベースのシーン管理に関して
>>295と>>296(俺)のような批判が出るかって言うと、
>>298で挙げた3つの操作だけでうまく管理できるような
状態遷移になっているゲームが少ないから。

例えば、Stackの状態が
タイトル <- メニュー <- ゲーム処理 <-
だとして、ゲームオーバーシーンに移りたいとする。そうするとpush操作で
タイトル <- メニュー <- ゲーム処理 <- ゲームオーバー <-
となるが、次にタイトルシーンに移りたくなったときに、
これに対応する操作がない。あくまで与えられている操作は、
次のシーンに移るか、1つ前のシーンに戻るかだけだから。

"ゲームオーバーシーンから戻るときだけは
topがタイトルシーンになるまでpopする"というような特例を
不都合が生じる度に設けると、Stackベースにした意味がなくなる。
これが>>296で言った『データ構造の破壊』に相当する。

"Chain of Responsibilityパターンを使ってシーンオブジェクト間で
データをリレーしていけば実現できるよ"って意見をどこかで
見たことがあるのだが、そもそもシーンオブジェクトには
状態遷移を正しく行う責任はないので、オブジェクトの動作的に不自然。
これが>>296で言った『オブジェクトの役割の破壊』に相当する。

ここまで神経使うかよって思うのが普通だとは思うけど、
せっかくのデータ構造スレなので色々グダグダと言ってみた。
よさげなデータ構造があれば是非ともそれを利用したいし。

**名前は開発中のものです。** · 2007/04/12(木) 07:27:37

Stackのシーン管理を、必要なところだけ使うようにすればいいんじゃないの。
セーブ画面とか、オプション画面とか。

**名前は開発中のものです。** · 2007/04/12(木) 11:44:45

>>185-
ちょっと参考になるよ

**名前は開発中のものです。** · 2007/04/12(木) 18:19:58

色々考えて、俺はスタック的な遷移も結構いいんじゃないかと思えてきた。

スタックだと、シーンの遷移の責任は全て親に任せることができる。
キャンペーンモードなのか、単独のマップを遊ぶだけのモードなのかは、自分は
知る必要もなく、遷移する理由（勝利、敗北、キャンセル…etc）だけを伝えれば
次にどのシーンになるかは親が決めてくれる。

各シーンが自分で次のシーンを選んでダイレクトに遷移していくよりは、
親に一任した方がすっきりするね。

スタックそのものでなくても、スタック的な遷移ができることは便利だと思う。

**名前は開発中のものです。** · 2007/04/12(木) 20:03:01

うむ、完全にpush/popに収める必要はないよな。

**名前は開発中のものです。** · 2007/04/12(木) 20:15:13

素直に多方向リンクリストでやれよ。

**名前は開発中のものです。** · 2007/04/12(木) 20:25:07

それは実装・データ構造の話じゃん。

**名前は開発中のものです。** · 2007/04/12(木) 21:46:48

>>302
遷移する理由を伝えることによるシーン遷移ってのはいいね。
が、これは別にスタックに限った恩恵ではない
(っていうのは>>302もわかってると思うけど)。
>>304の言う多方向リストでも可能(っていうか本来はこっち)だし、
イテレータが指すシーンを現在のシーンとする双方向リストでも可能。

多方向リストで工夫して実装すれば、
リソースを食うシーンに移ったときに
前のシーンをいくつか解放するといった処理が行えるし、
シーンを激しく前後するような操作をしても
オーバーヘッドがかからないのでいいかも。
もっとも、ゲーム起動時にリソースを全部先読みしても
全く問題ないようなゲームだったら、
積みっぱなしのスタックで全く問題ないし、
これが一番簡単だと思うけど。

**名前は開発中のものです。** · 2007/04/12(木) 22:34:50

"多方向リンクリスト"に該当するページが見つかりませんでした。

**名前は開発中のものです。** · 2007/04/13(金) 01:17:14

双方向リンクリストじゃない？

**名前は開発中のものです。** · 2007/04/13(金) 01:37:40

色んな方向につながってるってことは…
vectorじゃねぇの？

**名前は開発中のものです。** · 2007/04/13(金) 02:13:59

遷移元シーン番号と遷移事由コードで
テーブルから遷移先シーン番号（またはシーンオブジェクトの参照）を
引くだけというのはだめだろうか

**名前は開発中のものです。** · 2007/04/13(金) 04:18:27

ヒント：C言語などの関数

**名前は開発中のものです。** · 2007/04/13(金) 04:47:41

>>311
エレガントじゃない気がする

**名前は開発中のものです。** · 2007/04/14(土) 05:39:36

状態の保存方法なんて画面にあわせて stack なり queue なり
vector なり list なり、適当に作ったツリー構造なりを使えばいいよ。

コンテナ実装するのも一苦労だったアセンブラやCで組む時代じゃないんだから、
全体でどれに統一するか悩む必要なんて無いでしょ。

**名前は開発中のものです。** · 2007/04/15(日) 10:34:45

ログ

**名前は開発中のものです。** · 2007/04/15(日) 14:31:59

参照カウント付きスマートベクトルポインタ使ってシーンの遅延生成や破壊を自動管理したり
夢が広がりまくりんぐ

**名前は開発中のものです。** · 2007/04/19(木) 13:16:55

シーン間の遷移（例えばクロスフェード）とかどうやってる？

**名前は開発中のものです。** · 2007/04/19(木) 13:42:33

俺はシーン別に切り分けてバッファを持っている。

**名前は開発中のものです。** · 2007/04/19(木) 22:50:53

自分は、Viewで処理してて、Modelでのシーン自体は完全に移行済みにしとく。

あくまで、表示（演出）は表示（演出）ときりわけやったほうがいいと思うし、
また、切り分けとくと変更も楽だし、テスト時とか演出要らん場合はさっさと飛ばせるし。

**名前は開発中のものです。** · 2007/04/20(金) 18:21:55

やべ。意味が分からん^^
ちょっと確認させて欲しい。

class IScene {
　 virtual void update(ISceneContext& ctx);
　 virtual void draw(ISceneContext& ctx);
};
class SceneStack {
　 void push(IScene *scene);
　 void pop();
　 void call(IScene *scene);
　 void update(ISceneContext& ctx) { /*登録されたシーンの更新*/ }
　 void draw(ISceneContext& ctx) { /*登録されたシーンの描画*/ }
};

自分の理解では、こんなのがシーン処理の実装なんだけど、
まずこの解釈はあってる？
当然、シーン変更時はscenestack.call(new_scene)とかやるわけね。

>>317
シーン別にバッファを持ってるってことは、
シーン遷移時の処理はSceneクラスで遷移を行うか、
他の遷移専用クラスがあるってことですか？

>>318
↑の例でいうと、ISceneまたはSceneStackのdraw内のみで
遷移処理を実行するということですか？

全然分かってないかもです。
理解が足りなくて申し訳ない。