ゲームプログラミング相談室【Part6】

**名前は開発中のものです。** · 04/03/06 01:25

ゲームプログラミング全般の質問スレッド。
扱う話題のダイナミックレンジはやや広め。包容力高め。
他の初心者質問スレとの棲み分けを探りつつ
これからもマターリと活用しておくれ。
　
■過去スレ
【Part2】http://pc.2ch.net/tech/kako/985/985540361.html
【Part3】http://pc.2ch.net/tech/kako/1002/10028/1002894129.html
【Part4】http://game.2ch.net/gamedev/kako/1005/10050/1005040025.html
【Part5】http://pc2.2ch.net/test/read.cgi/gamedev/1036410116/
■関連スレなど
>>2-5

**名前は開発中のものです。** · 2006/02/18(土) 19:38:52

3Dゲームは描画用マップとコリジョンマップに分けると聞いたのですが、
描画用マップとコリジョンマップは1ステージ全て1つのXファイルで作るんですか？

**名前は開発中のものです。** · 2006/02/18(土) 20:10:32

キャラクターと衝突判定する部分だけに特化したデータを作ってもらうといいじょー。
例えば天井に衝突しないゲームなら、デザイナーさんに天井無しにしてもらうとか。
描画用ではカーブでも衝突用のは多少ごつごつしてても平気っす。
描画用もヒットチェック用もXファイルじゃなくってもいいけど、基本別々です。

**８０３** · 2006/02/18(土) 20:13:53

×カーブ　○滑らかなカーブ

**名前は開発中のものです。** · 2006/02/18(土) 21:07:24

>>803
なるほど、描画用マップはテクスチャ情報の付いたXファイルなど、
コリジョンマップは壁や各オブジェクトの位置を表したデータファイル・・・であってますか？

>作ってもらうといいじょー。
業界人ではないので誰にも作ってもらえないですorz
コリジョンマップエディタとかあるらしいのですが有料でしょうか

**名前は開発中のものです。** · 2006/02/18(土) 21:28:28

逆にコリジョンマップを含めたステージの論理的なデータから
風景を生成するっていう考え方もあるが、まぁ普通は別々に作るんだろうな

**８０３** · 2006/02/18(土) 21:51:17

>>805
そそ、描画データが大体、x,y,z,nx,ny,nz,u,v,面情報,マテリアル情報などなど～、とかだけど
コリジョン用は、x,y,z,面情報、で十分なので。

>コリジョンマップエディタ
オラにはわかりませんです。

>>806
風景データの完成後、それをコピって別レイヤーで
がすがす頂点削ってく作業なので結構すぐ作ってくれます。
２～３週間で作るデータでも、１・２日でコリジョンデータは出来てくるっす。

**名前は開発中のものです。** · 2006/02/18(土) 23:15:29

gtkradiantだっけ？
そういうのもあるらしい。

**名前は開発中のものです。** · 2006/02/19(日) 00:17:34

FF７～９のように一枚の２Ｄ絵に描かれた３Ｄ世界の中を３Ｄのポリゴンキャラが動き回るゲームって
どうやって実現しているんでしょう？
特に、スクロールとかやった時にどうして遠近感や空間関係が破綻しないのか不思議です。
なんたって、キャラは３Ｄで背景は２Ｄですからね。作るの難しいですかね？

**名前は開発中のものです。** · 2006/02/19(日) 01:57:03

あれは一枚のように見えるけど一枚じゃないぞ

**名前は開発中のものです。** · 2006/02/19(日) 09:01:11

>>809
フィールドは、全部３Ｄでおおまかなブロックにわけてスクロール。ＦＦ７で時々読み込み失敗する；；（飛空挺？とかで）
ダンジョンは、カメラの視点・注視点が動かないシーンは背景を２Ｄでプレイヤーの前面にくるオブジェを
３Ｄ計算で（これは２Ｄ計算（描画順序のみ）のままでもいけるところもあるかも）。
ムービーへ切り替えするときは、背景をムービーとして、カメラワークとプレイヤーの前面にくるオブジェだけ３Ｄ計算。

**名前は開発中のものです。** · 2006/02/19(日) 14:15:08

注視点が動かないシーンなら分かるんです。コンポジションソフトと同じ要領でしょ？
問題はカメラがキャラを追って大きくパン（背景絵もスクロール）するような広いダンジョンの場合は？
空間関係を保持出来ませんよねぇ？

**名前は開発中のものです。** · 2006/02/19(日) 15:12:31

コツとしては絵の中の道は実際の３Ｄデータとして考えて、
カメラワークをキャラクターの位置から背景２Ｄ絵に対して平行にすべらせるとＦＦ７～９のようにできます。
（道がキャラクターより前面にくる時は当然３Ｄオブジェとして描画します。
というかＦＦ７～９の背景データは３Ｄデータから２Ｄにおとしてる？）

背景データが３Ｄじゃないと表現できないのはカメラ視点が平行移動せず奥へ向かって行く場合っす。
ＦＦ７～９ではそういう時、ムービーを使用しています。
そういえばバイオハザードとかも同じっすね。

**名前は開発中のものです。** · 2006/02/19(日) 15:14:58

FFに視点・注視点が動くような場面あったかな
単純にスクロールしてるだけだと思ったが
http://gamdev.org/up/img/4707.jpg

**８１３** · 2006/02/19(日) 15:41:30

×奥へ　○奥や手前へ

>>814
そう思います。プレステ１だし風景まで３Ｄってわけにはいかなかったのかも。

**名前は開発中のものです。** · 2006/02/20(月) 00:21:23

理解しました。つまりカメラがキャラの移動に対して常に平行移動する限り、カメラアングルに「角度」的変化は無いので背景絵と矛盾しなかったんですね。
しかしその場合でも、ｽｸﾘｰﾝ何個分もスクロールするような長い道などの場合ﾏｯﾌﾟ絵の読み込みだけで相当なメモリを消費するんじゃないかと思うんですが。
それに3D処理とマップ描きは別の工程での作業になると思うんですが、
実際プログラム上で実行した時に3D処理上の当り判定とマップ絵上の壁とが
寸分違わず一致してますよね～。一体どうやってるんでしょう？

**名前は開発中のものです。** · 2006/02/20(月) 00:22:51

寸分違わず一致しない理由がわからん。

**名前は開発中のものです。** · 2006/02/20(月) 01:44:52

だってだって、普通少しくらいズレたって良さそうじゃん？
3D処理用の簡易モデル・シーン情報→マップ描く人のツールに移す→細かいパーツとか付け足し、テクスチャ貼り→プリレンダ絵完成
この工程のどこかでズレそうじゃん、どこかでマウスがブレたりして。またはカメラの設定トチったりして。

**名前は開発中のものです。** · 2006/02/20(月) 01:52:21

製品レベルではズレることは許されない

**名前は開発中のものです。** · 2006/02/20(月) 02:14:38

じゃあ慎重な作業と根性でズレないようにしていると理解してよろしいですか？

ちなみにこういったシステム（FF7･8･9/初期ﾊﾞｲｵﾊｻﾞｰﾄﾞ）のゲームを作るにはどの程度のプログラムの技術が必要になりますか？
自分はプログラムは組めないので、出来る人を探さなければいけないんですが。
例えばこのスレにいる皆さんなら作れます？キャラモデルやマップ等は全部こっちで用意すると仮定して。

**名前は開発中のものです。** · 2006/02/20(月) 02:33:26

>>820
出来る人は結構いるけど、あんたに付き合っている暇がある人はいないと思われ。

**名前は開発中のものです。** · 2006/02/20(月) 04:31:14

割と大変な方。

**名前は開発中のものです。** · NG

>>820
技術もさることながら、単純にマンパワーが必要になるよ
ＦＦ７～クオリティ・量のグラフィックデータを自前で全部作れるのならそんな心配無いのかもしれんけど

**名前は開発中のものです。** · 2006/02/20(月) 12:13:27

上司「高速化がご飯作ってくれるの！？」
オラ「でもスクエ二君の家は・・・」
上司「スクエニ君の家はスクエニ君の家！！うちはうち！！」

**名前は開発中のものです。** · 2006/02/20(月) 13:24:47

プロの作品って技術もさることながらマンパワーが凄まじいよなぁ

**名前は開発中のものです。** · 2006/02/20(月) 15:48:34

確かに。

**名前は開発中のものです。** · 2006/02/20(月) 19:14:27

Softimage|XSI FTKに詳しい方に質問です。
XSIのスケルトンをエクスポートしたいんですが、BASEPOSE とSRTの相関関係が良くわかりません。
BASEPOSE, SRT を4x4行列変換済みメンバーとして、スケルトンがRoot->bone->bone2 というチェーンとし、
rootのグローバル変換行列とジオメトリブレンディングは無視するとして、最終的にbone2に結び付けられたenvelopeというメッシュのローカル変換行列Lを得たいとします。
このとき、↓のようにBASEPOSEを無視してよいのか、
Matrix L = bone.SRT * bone2.SRT * envelope.SRT
それとも↓のようにBASEPOSEと相対的にSRTがあるんでしょうか？
Matrix L = (bone.SRT * bone.BASEPOSE) * (bone2.SRT * bone2.BASEPOSE) * (envelope.SRT * envelope.BASEPOSE)
それとも何か別の考え方に基づいているんでしょうか？

**名前は開発中のものです。** · 2006/02/20(月) 19:21:56

>>827
ＣＧ技術板じゃないか？

**名前は開発中のものです。** · 2006/02/20(月) 19:27:55

>>825
そりゃ、ゲーム作るのに50人とか使えるんだからな。
アマチュアはどう頑張っても10人程度が限度だろう。

**名前は開発中のものです。** · 2006/02/20(月) 19:34:52

プロジェクト管理する人は、相当な交渉能力と
カリスマ性と幅広い知識が無いと、５０人なんて統制できないんだろね

**名前は開発中のものです。** · 2006/02/20(月) 20:11:51

金がありゃ何とかなるんじゃね？

**名前は開発中のものです。** · 2006/02/20(月) 22:32:44

2Dのファミコンのドラクエの洞窟みたいなマップのシステムを作るには
どのようなやり方がよいですか？
参考になるようなサンプルとかないでしょうか。

環境：ＶＣ＋＋

**名前は開発中のものです。** · 2006/02/20(月) 22:32:58

>>828
XSIの中間フォーマットdotXSIからゲーム製作などに必要なデータをコンバートするためのライブラリがFTKのようだ

**名前は開発中のものです。** · 2006/02/20(月) 22:58:49

>>827
以前自分がやった時は、良く分からないまま試行錯誤してたら上手く行った感じに
なっただけなので、もしかしたら問題あるかもしれんが書いてみる。
ソース見ても良く思い出せないけどね。バージョンによっても違うかもしれんし。

基本的に、SRTを階層で乗算していった物がそれぞれのBASEPOSEになるみたい。
なので、アニメーションさせないならBASEPSOEだけ使えば、SRTによる階層での乗算は不要かと。
SRTはFCurveで値を変更できるようなので、アニメーションするならSRTも必要。
FCurveでアニメーションさせる場合、SRTにはFCurveの1フレーム目が入っているようだ。
ジオメトリブレンディングをやるならSRTだけじゃ駄目で、BASEPOSEが必要と思われる。
自分のソース上では、BASEPOSEの逆行列保持して、SRTで動かして元に戻す感じになってる。

自分で書いてても良く分からなくなってしまった。
聞きたい事と全然違ったらごめんね。

**名前は開発中のものです。** · 2006/02/21(火) 01:05:32

今度オリジナルのカードゲームをＨＳＰで作ろうと思うのですが
どういう風にプログラミングすればいいのでしょうか？

**名前は開発中のものです。** · 2006/02/21(火) 02:30:10

>>835 オリジナルでおｋ

**827** · 2006/02/21(火) 13:28:47

>>834
>基本的に、SRTを階層で乗算していった物がそれぞれのBASEPOSEになるみたい。

どもです。BASEPOSEはIKで使うようですね。エフェクターを動かした後、この逆行列を掛けて変換行列を得るようです。

**前430** · 2006/02/21(火) 22:19:53

>>835
割り込みがあるルールの場合は、お互いのカードをスタックに積んで上から処理する。

**名前は開発中のものです。** · 2006/02/24(金) 03:15:19

Direct3D使ってゲームを作りたいのですが、クラス構成で悩んでます

WinMain┬Rendererクラス　･･･レンダラーの初期化と描画開始･終了･Present()
　　　　　└Sceneクラス　　　･･･シーンの構築と描画　レンダラークラスからポインタで呼び出される

今のところこんな形になってるのですが、(某DX本の構成)
ここにキャラクターの移動や描画などの処理をまとめたCharクラス
マップのスクロールや描画をまとめたMapクラス
などのオブジェクトを表すクラスを組み込むとしたらどこに入れればいいのでしょうか？
上の構成はぶっ壊してもいいです

**名前は開発中のものです。** · 2006/02/24(金) 12:49:41

悩むところなんだろうか？ぶっちゃけどこに入れても
その先の部分をきちんと書けばちゃんと回ると思うんだが。

**名前は開発中のものです。** · 2006/02/24(金) 16:44:36

オブジェクトクラスが入力と描画どちらにも対応しないといけないから
描画用クラスに組み込むとおかしくなるし
描画用クラスの外に出すとどうやって描画するかが分からなくて

**名前は開発中のものです。** · 2006/02/24(金) 17:07:15

ひょっとすると俺には想像もつかない複雑な構成になってるのか。
そもそも説明文と図が矛盾してる（レンダラーからシーンが呼び出されるのに
図ではWinMainを介してしか繋がってないように見える）しな。

**名前は開発中のものです。** · 2006/02/24(金) 19:48:30

ttp://dream.my-sv.net/upload/src/up0140.zip
ごめん今こんなものしかない
WinMainからレンダラー呼び出してその中でDirectXの初期化
次にシーンクラスのCreateScene()呼び出してテクスチャとかメッシュとかアニメーションとか設定
WinMain最後にスレッド生成。スレッド内は無限ループ。
レンダラークラスのRenderScene関数にシーンクラスへのポインタ渡して
RenderScene関数内で画面クリア後、シーンクラスのDraw関数呼び出してモデルを描画
その後RenderSceneに戻ってpresent()したらWinMainに戻る
打っててなんかおかしいとおもた
長々とｽﾏｿ

**名前は開発中のものです。** · 2006/02/24(金) 20:43:19

CSceneクラスにオブジェクトクラスなりそのポインタなりのリストを保持させる

**名前は開発中のものです。** · 2006/02/24(金) 21:50:22

やっぱりシーンクラス内になりますか
スレッド内で移動処理などしたいのでWinMainにクラス持たせてポインタを渡すことにします
ありがとう

**名前は開発中のものです。** · 2006/02/26(日) 21:47:41

タスクシステムとやらを組んでみた
コンパイルエラーの嵐
関数ポインタとメモリが絡んでくると毎回酷いことになる

**名前は開発中のものです。** · 2006/02/27(月) 08:33:07

コンパイルエラー云々言ってる段階じゃ
まだ話にならんと思うんだが。

**名前は開発中のものです。** · 2006/02/27(月) 16:41:18

いや関数ポインタの方はあまり使ったことないからその辺はまぁ･･

Class1::test(TASK *t)　　//TASKはタスク用の構造体
{
　　･･･
}

この関数をタスクの行動関数に指定してタスクを生成したいんだけど
タスククラスのpTask->TaskCreate(test, NULL, 1, 1)でタスク生成関数に関数testのアドレスを渡しても
「void (* (_closure )(TASK *))(TASK *)' 型は 'void *' 型に変換できない」とかエラーが出る
渡す先はタスククラスメンバ関数の
TASK* TaskCreate(void* Func, void* Release, DWORD Priority, DWORD Type)

クラスのメンバ関数はvoid*型に変換できないの？

**名前は開発中のものです。** · 2006/02/27(月) 16:45:29

>>848
＞クラスのメンバ関数はvoid*型に変換できないの？
ムリ。
いや、無理すれば出来るけど。
bind1stで調べてみると分かる、かも？

**名前は開発中のものです。** · 2006/02/27(月) 16:46:40

あとクラス内のメンバ関数ではなくクラス外の関数なら普通に渡せた
void test(TASK *t){/*･･･*/}とか

**名前は開発中のものです。** · 2006/02/27(月) 16:47:36

>>849
更新してなかった
>bind1st
ありがとう、ちょっとググってくる

**名前は開発中のものです。** · 2006/02/27(月) 20:12:08

>>848
クラスの多重継承を考えると、sizeof(メソッド)は
sizeof(単純な関数ポインタ)＋sizeof(オフセット)
が必要になるよ。

**名前は開発中のものです。** · 2006/02/27(月) 20:35:03

しばらく検索してみたけどどうにも･･

>>852
よく分からんです･･
タスク用のデータエリアのことなら
pTask = new CTask;
TASK* Task = pTask->TaskCreate(行動関数,開放関数,優先度,タイプ);　//タスク生成、リスト追加
Task->Data = new データ型;
Task->Data = (void*)データ;
で確保してるのでサイズは大丈夫だと思う

タスクってポインタをガシガシ切り替えて処理するものだと思ってたけど
CじゃなくC++のクラスを使ったタスクシステムを見てみると
どれも継承元で仮想関数使って継承先に処理を記述する処理固定のしかないんだなぁ･･･

**名前は開発中のものです。** · 2006/02/27(月) 20:47:17

つStateパターン

あと、関数ポインタじゃなくてboost::function使うと色々できるよ。
パフォーマンスは知らんけど。

**名前は開発中のものです。** · 2006/02/27(月) 20:50:42

>>853
C++でもポインタの切り替えはできるよ。というかできたよ。
理由は>>852の通りなんだけど、
とりあえずクラスメソッドはvoid*型に変換できないんで
TASK* TaskCreate(void* Func, void* Release, DWORD Priority, DWORD Type)
は
typedef ...(ClassName::*FuncType1)(...);
typedef ...(ClassName::*FuncType2)(...);
TASK* TaskCreate(FuncType1 Func, FuncType2 Release, DWORD Priority, DWORD Type)
のようにする必要がある。

**名前は開発中のものです。** · 2006/02/27(月) 21:47:38

>>854
>Stateパターン
Stateで検索してたつもりがいつのまにかデザインパターン全般のページ見てた
奥が深いね･･･こっち関連の書籍持ってないから今度買ってみる
boostはライブラリをあまり使いたくない派なので迷う
>>855
異なる複数のクラスに対応させる場合、
生成関数をその分用意しないといけないので大変ですね･･
なんでクラスメソッド渡せないんだか･･

デザインパターンに興味を持ったのでStateパターン覚えてからしばらくそっちに走ってみます

**名前は開発中のものです。** · 2006/02/27(月) 22:08:46

> 異なる複数のクラスに対応させる場合、
> 生成関数をその分用意しないといけないので大変ですね･･
> なんでクラスメソッド渡せないんだか･･
まさにここが工夫のしどころで、
いちいち作らないようにする方法はある。

**名前は開発中のものです。** · 2006/02/27(月) 22:13:28

>>857
今思い出したからうろ覚えだけど
もしかして関数テンプレート機能？

**名前は開発中のものです。** · 2006/02/27(月) 22:47:19

ういうい。
このくらいはできて当然だから、がんばっちくり。

**名前は開発中のものです。** · 2006/02/27(月) 22:49:43

ありがとう
俺物忘れ激しいな･･
C++基礎からやり直した方がいいかも

**名前は開発中のものです。** · 2006/02/27(月) 22:53:02

タスクシステムなんて言うから C で組んでるのかと思ったら、 C++ だったのかよ。
普通に仮想関数使えば終了だな。キモイキャストの連発ともおさらばだ。

関数ポインタから void* への変換は、メンバ関数に限らず不可。
もしできたように見えたとしても、それはコンパイラの独自拡張だろう。

**名前は開発中のものです。** · 2006/02/27(月) 23:23:15

>>861
やってみれば分かるけど、仮想関数のみだとキャストしないと無理。
あと、関数ポインタからvoid*への変換は確かに環境依存なんだけど、
boost.function はそれを駆使して実装されてるんで、
boost.function が動く環境ならどこでもできるよ。

**名前は開発中のものです。** · 2006/02/27(月) 23:37:54

>>862
単に「タスクシステム」っていうと、メインループがタスクのポインタ握って
ポインタから仮想関数を呼び出すぐらいしか無いと思うんだけど、
何にキャストが要るの？

boost::function が関数ポインタから void* への変換を駆使してる？
どこにそんな情報があるの？
とりあえず現状のソースでは union 使ってるみたいだけど。
http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/function/function_base.hpp?view=markup

**名前は開発中のものです。** · 2006/02/28(火) 00:21:53

class ClassA {
public:
  void static funcA(void* se1f)
  {
    ClassA *self = (ClassA*)se1f;
    cout << self->num++ << endl;
  }
private:
  int num;
};

void call_func(void (*func)(void*), void *arg)
{
  func(arg);
}

int main()
{
  ClassA *class_a = new ClassA;
  call_func(class_a->funcA, class_a);
}

Perlとかに慣れているなら self の存在を許せるよね…

**名前は開発中のものです。** · 2006/02/28(火) 00:29:02

>>863
タスクシステムって言うのは
class Task {
public:
　void begin_task() { ... set_task(&Task::task1); }
protected:
　void task1() { ... set_task(&Task::task2); }
　void task2() {}
};
とか、こういうのを指してると思うんだ。
で、コールするべきメソッドを保存するためには、
テンプレートを使わないならキャストする必要があるよと。
もちろん１タスク１関数を遵守してもいいんだけど、これはこれでなかなか便利だよ。
あと、boostの方は間違えた。
関数オブジェクトを保存しているフィールドと関数ポインタのフィールドを見誤ったようだ。

**名前は開発中のものです。** · 2006/02/28(火) 00:31:23

↑set_taskとそれを呼び出すメソッドは適当に補完して。

**名前は開発中のものです。** · 2006/02/28(火) 00:31:28

ゲームの描画と処理は別にした方がいい？
別にする場合の構成とかどんなもん？

**名前は開発中のものです。** · 2006/02/28(火) 03:24:56

>853
C++でやるならもっと型安全に気を使おう。
そんな古典的な手法を使うならCでやれ。

C++的には
>継承元で仮想関数使って継承先に処理を記述する
その継承先の処理の記述で、
ifやswitchやメンバ関数ポインタやstaticメンバ関数へのポインタを使って分岐するのが、
型安全でカプセル化でスマート。

>861
void *に変換した物は、何も弄らず元の型に戻せば、
正しく復元される（関数ポインタだとしても）って聞いたんだが。

**名前は開発中のものです。** · 2006/02/28(火) 09:48:42

>>867
普通は別にするとおもわれ。
構成なんて漠然としたこと聞かれても困る。
例を示されよ。

**名前は開発中のものです。** · 2006/02/28(火) 12:17:07

>>868
オブジェクトポインタと関数ポインタの間での変換は規格では認められていない。
C の時からそう。

**名前は開発中のものです。** · 2006/02/28(火) 12:57:51

タスクシステムってまさかCodezineに載ってるアレのことか？
C++でやるならStateパターン+1キャラクタ1クラスでFAだろ。

**名前は開発中のものです。** · 2006/02/28(火) 13:39:14

>>865
その形でどこにキャストが要るのかわからない。

**名前は開発中のものです。** · 2006/02/28(火) 21:40:21

>>870
確かにコンパイラの独自拡張なんだけど、もはや共通拡張と言ってもいいくらい浸透してるみたいだね。
条件付きではあるけれど。
ttp://forums.belution.com/ja/cpp/000/015/67s.shtml

>>871
状態によって処理を変える必要しかないならそれでもいいだろうね。
ただ、例えばタイトル画面なんかの場合は
１）タイトル文字をフェードイン＋移動しながら表示
２）サブタイトルを移動しながら表示
３）全体にエフェクトをかける
みたいに状態によって左右されないシームレスな記述が必要になる。
これを扱う方法としてswitchやマイクロスレッドがあるんだけど、
もう一つの方法がこのオリジナルタスク。
オリジナルとはいっても
Codezineのタスクシステム＋ Move or Drawメソッドの呼び出し先を変えられる
ってだけなんだけど。

>>872
新規クラス Task2 や Task3 を導入したときに問題になる。

**名前は開発中のものです。** · 2006/02/28(火) 22:38:49

状態によって処理を変えるのが、Stateパターンじゃないのか

**名前は開発中のものです。** · 2006/02/28(火) 23:36:27

タスクシステムのあとから生まれた、関数ポインタとか隠蔽しているC++で
タスクシステムの方を優先して設計するのはナンセンスだと思うよ。

関数ポインタを使って実現したいことは処理の共通化だろうし、それは仮想関数だけじゃなくて
普通に継承元になる側にも関数いれときゃいいし。
継承元のクラスポインタに、派生したいろんなクラスをまとめていれられる。

**名前は開発中のものです。** · 2006/02/28(火) 23:47:24

WinMain下の構造教えてくれ

**名前は開発中のものです。** · 2006/03/01(水) 00:51:17

>>865の言ってるタスクシステムとか百害あって一利無しじゃね？
>状態によって左右されないシームレスな記述
ってのは単に処理をどこで区切ってStateに分けるかの話だろ。

**872** · 2006/03/01(水) 00:59:35

>>873
> 確かにコンパイラの独自拡張なんだけど、もはや共通拡張と言ってもいいくらい浸透してるみたいだね。
> 条件付きではあるけれど。

そんなに必死に正当化しなくても、非標準なんだから使わないようにすれば済む話。
「共通拡張」なんて胡散臭い言葉を持ち出すのは混乱の元。

> 新規クラス Task2 や Task3 を導入したときに問題になる。

やっぱりわからない。わかんないのは俺だけ？
何から何へのキャストが要るのか、書いてもらえると分かるかも。

**名前は開発中のものです。** · 2006/03/01(水) 01:09:15

>>878
もういいじゃん。
そっとしておいてあげようよ…。

共通拡張の時点で分かるでしょ。
もういっぱいいっぱいなんだよ。
わかってやれよ。

**名前は開発中のものです。** · 2006/03/01(水) 01:28:04

これは例が悪かったのかな。もう一度プログラムを書いてみる。
これは擬似コードなので動かないし、NULLチェックとかもしてないよ。

// 描画系のメソッドは略
class TaskBase {
public:
typedef ① FuncType;
TaskBase() : m_func(&TaskBase::begin_task) {}
void set_task(FuncType func) {m_func = func; /*②*/ }
void update() { m_func(); }
protected:
virtual void begin_task() {}
private:
FuncType m_func;
};

class Task1 : TaskBase {
public:
Task1() {}
protected:
void begin_task() { set_task(&Task1::task1); }
void task1() {}
};

class Task2 : TaskBase {
public:
Task2() {}
protected:
void begin_task() { set_task(&Task2::task1); }
void task1() {}
};

**名前は開発中のものです。** · 2006/03/01(水) 02:16:32

>>875
関数ポインタを使ってしたいことは、処理の共通化でもあるんだけど、
タスクの場合は主に長い処理を１フレーム分に分割することにある。
マイクロスレッドなりスレッドなりを使わないと、どうしてもぶつ切りにせざるを得ないので。
もちろん、templateメソッドみたいに呼び出すメソッドがあらかじめ分かっていれば、
継承元側に仮想関数を追加しておくことはできるよ。
ただタスクシステムの場合、それはほとんど不可能。

>>877
Stateを使うってことは、状態一つに対してクラスを一つ作るってことなのかな？
例えば、>>873にあげた１）２）３）でそれぞれに対してクラスを作るの？
これの代替機能としてはswitchやマイクロスレッドがあげられると思うんだけど、
何でステートパターンにこだわるんだか、俺には分からない。
これだと粒度大きすぎると思うんだけど。
(細切れの関数に対していちいちクラスを作らないといけないってことね)

>>878
> そんなに必死に正当化しなくても、非標準なんだから使わないようにすれば済む話。
> 「共通拡張」なんて胡散臭い言葉を持ち出すのは混乱の元。
一緒に示したソース見た？
その中に「共通の拡張」って表現があるから、それを借りただけなんだけど・・・
この辺は>>868や俺のように間違えてる人が多いから、一応確認しただけ。
これは本題ではないので、こちらからはこれ以上レスしないよ。

あと、>>880に示したプログラムではテンプレートを使ってないので、
①に何を書いても②でキャストすることになる。
使わない方法があれば、俺も知りたい。

**名前は開発中のものです。** · 2006/03/01(水) 02:36:11

>>881
×　①に何を書いても②でキャストすることになる。
○　①に何を書いてもset_taskの呼び出し時にキャストすることになる。

**名前は開発中のものです。** · 2006/03/01(水) 03:14:04

>>880,881
キャストが要るようになったらプログラムが間違ってるのを疑えよ。
なんで仮想関数で得られる型安全を自ら壊すような「タスクシステム」に
こだわるんだ？そんなシステム要らない。

↓これでいいんじゃないの。

class State {
public:
　virtual void update() = 0;
};

class State1 : public State {
public:
　State1() : m_update_task(&State1::begin_task) {}
　void update() { (this->*m_update_task)(); }
private:
　void (State1::*m_update_task)();
　void begin_task() { m_update_task = &State1::task1; }
　void task1() {}
};

**名前は開発中のものです。** · 2006/03/01(水) 04:00:38

>>883
ようやく伝わったようだ。イメージとしてはそんな感じ。
で、テンプレートを使えば m_update_task 周りの処理をすべて
継承元の xxx<Task1> に投げられますよというだけの話。
例でtemplateを使って無いのは、>>882に説明するため。

**名前は開発中のものです。** · 2006/03/01(水) 04:08:48

一体何を話しあっているのか分からない俺ガイル

State1() : m_update_task(&State1::begin_task) {}
void (State1::*m_update_task)();
void begin_task() { m_update_task = &State1::task1; }

この辺りの記述ははじめた見た
詳細きぼん

**名前は開発中のものです。** · 2006/03/01(水) 04:18:04

あーすまん分かった
コンストラクタとメンバ関数ポインタか
コンストラクタでbegin_taskを関数ポインタに代入して
それが呼び出されれば関数ポインタにtask1を代入するわけか
またひとつ賢くなった

**名前は開発中のものです。** · 2006/03/01(水) 04:25:23

>>884
また分かりにくいかもね。
>>883の例でいくと、
class State1 : State<State1> { ... };
とすれば、m_update_task 周りの処理を
継承元であるState<>で行うことができますよという話。

**名前は開発中のものです。** · 2006/03/01(水) 06:34:35

根本的に勘違いしてると思うんだよねぇ。
つーかさ、switchでつくりゃいいじゃん。ポインタにしてもいいことないよｗ
最適化かからなくなるし。

switch( TaskType )
{
case TaskType1: funcType1(); break;
case TaskType2: funcType2(); break;
case TaskType3: funcType3(); break;
　default： assert( false /*TaskTypeError*/ );
}

ああ、安全安全。

**名前は開発中のものです。** · 2006/03/01(水) 07:51:41

タスクの良い点は状態遷移が単純なときに状態変数みたいなものをつくらずに
関数に分けて、特定の状態のときに行う処理がかけることかな。
状態遷移が複雑だったり外部の環境の変化によって遷移の仕方が大きく変わるようなら
Fiberつかったほーがいいけど、適材適所ということで。

キャストとかtypedefとか必要ない俺のつくったタスクシステムのきれっぱしを参考にしてくれ
正直つくったはいいがザコキャラがでてきてうろうろしたり弾幕があったりするようなゲームを
つくらなかったので使いどころがなかった。

// タスクの管理者はlist<TaskManagable*>をメンバに持ち、Run()を順番に呼んでいくのだ
class TaskManagable {
public:
　virtual void Run() = 0;
};

//タスクになりたいクラスは class MyEntityTickTask : public Task<MyEntityTickTask>
// … とやってMain()を実装する。ChangeTask( hoge ) で自分のメンバ関数 void hoge() へ状態遷移できるよ
//管理者に登録するのはこのMyEntityTickTaskクラスをnewするやつの仕事だ。当然だね（＾ー＾ｂ
template <typename T> class Task : public TaskManagable {
public:
　Task() { ChangeTask(Main); };
　void Run() { (((T*)this)->*m_doit)(); }
protected:
　virtual void Main() = 0;
　void ChangeTask(void (T::*fp)()) { m_doit = fp; }
　void (T::*m_doit)();
};

**名前は開発中のものです。** · 2006/03/01(水) 09:15:15

>>889
> キャストとかtypedefとか必要ない俺のつくったタスクシステムのきれっぱしを参考にしてくれ
>　void Run() { (((T*)this)->*m_doit)(); }

キャスト入ってるよ。まぁ型安全は使い方で確保されてると言えるけど。
あんた、たぶん VC 使いだな。メンバ関数ポインタの &ClassName:: は
規格では省略できないことになってるから、気をつけてな。

>>884,887
たぶん 889 と似たような形のことだろうな。

これまでに挙がったコードだと template も継承も持ち出さずに
自分でメンバ関数ポインタを宣言（>>883）すれば十分に見えるんだけど、
「 m_update_task 周りの処理」ってのは代入と呼び出し以外に何か有るの？
State の実装がメンバ関数ポインタによる処理に切り替えを必要とするとも
限らないし、これをわざわざ「システム」として組み込んでしまうのは
template や継承（特に自己言及的 template など）おぼえたてで
使いたいだけに見えなくも無い。ほんとでそんな構成に利点があるんだろうか？

**名前は開発中のものです。** · 2006/03/01(水) 09:45:30

Cマガのやつじゃだめなの？

**名前は開発中のものです。** · 2006/03/01(水) 11:08:16

>>890
ほとんど似たようなコードを置きながらちっともリスペクトしなかったのは俺の不注意だが
そこまで嫌味をいわんでもええやん

**名前は開発中のものです。** · 2006/03/01(水) 19:11:17

C#あたりでポインタのない世界を勉強するほうがいいかも。
C++がこんな言語なのはCとの互換性を保っているからだしね。

なんつーか、WindowsのDOS窓でプロテクトモードじゃないと動かないような
プログラムをいまさら作ってるくらい違和感がありますよ関数ポインタ。

**名前は開発中のものです。** · 2006/03/01(水) 19:11:48

勉強として使ってみるのは十分ありだと思う。

**名前は開発中のものです。** · 2006/03/01(水) 21:06:02

>>888
あたし、一生あなたについていきます(*･_･)

**名前は開発中のものです。** · 2006/03/01(水) 21:06:39

少なくともC++において設計の時点でキャスト前提に話してるのって絶対おかしいだろ

**名前は開発中のものです。** · 2006/03/01(水) 21:44:02

>>890
分かってるとは思うけど>>880はサンプルだし、
実際に使うとなると他にもいろいろと書き加えないといけない。
そうなったときに、継承先クラスの実装とタスクシステムが
分離されてることはいいことだと思うけど。

>>893
もちろん実装として、メンバ関数ポインタの代わりに
boost.functionやらそのたぐいを使うことは十分に考えられる。
そういったことはすでに提案されている。

**名前は開発中のものです。** · 2006/03/01(水) 23:16:45

俺も昔はC++で関数ポインタ使うタスクシステムってのを作ってたけど、
今はtemplateとstateパターンだなぁ

**名前は開発中のものです。** · 2006/03/01(水) 23:24:58

グローバルに宣言した変数ならextern使えば他ファイルのクラス内からでもアクセスできるんだな
ファイル分割の辺りを飛ばしてたから初めて知った
グローバル変数をクラスにポインタ使って渡してた自分が馬鹿みたいだ･･

**名前は開発中のものです。** · 2006/03/01(水) 23:32:08

その変数をローカルにするんだ。

**名前は開発中のものです。** · 2006/03/01(水) 23:32:30

>>899
いきなりC知らない人間がC++やると碌なことが無い

**名前は開発中のものです。** · 2006/03/01(水) 23:38:46

>>899のやってる事の中でC++独自の機能を目を皿のようにして探す漏れ。
っていうかぁ、

　○　○　○　シ　ス　テ　ム　云　々　っ　て　馬　鹿　ぁ？

達成すべき処理に対して最適なアルゴリズムで組んでいけば、
それが最強のシステム。「よし○○○導入するぞ？」ってのは、
自分でまともなアルゴリズム組めない思考停止。PG才能無し。