- 1 名前：仕様書無しさん [2007/02/03(土) 20:11:09 ]
- ま、聞かない方が良い事もあるけどね。
ゲームプログラマーの人に聞きたい
ttp://pc.2ch.net/test/read.cgi/prog/1062855581/
ゲームプログラマーの人に聞きたい 2問目
ttp://pc3.2ch.net/test/read.cgi/prog/1078293745/
ゲームプログラマーの人に聞きたい 3問目
ttp://pc5.2ch.net/test/read.cgi/prog/1080491019/
ゲームプログラマーの人に聞きたい 4問目
ttp://pc5.2ch.net/test/read.cgi/prog/1086890676/
ゲームプログラマーの人に聞きたい 5問目
ttp://pc5.2ch.net/test/read.cgi/prog/1093629292/
ゲームプログラマーの人に聞きたい 6問目
ttp://pc5.2ch.net/test/read.cgi/prog/1100665806/
ゲームプログラマーの人に聞きたい 7問目
ttp://pc5.2ch.net/test/read.cgi/prog/1103458370/
ゲームプログラマーの人に聞きたい 8問目
ttp://pc5.2ch.net/test/read.cgi/prog/1108481342/
ゲームプログラマーの人に聞きたい 9問目
ttp://pc8.2ch.net/test/read.cgi/prog/1110993642/
ゲームプログラマーの人に聞きたい 0xA問目
ttp://pc8.2ch.net/test/read.cgi/prog/1115375538/
ゲームプログラマーの人に聞きたい 11問目
ttp://pc8.2ch.net/test/read.cgi/prog/1119537622/
ゲームプログラマーの人に聞きたい 12問目
ttp://pc8.2ch.net/test/read.cgi/prog/1125150865/
ゲームプログラマーの人に聞きたい 13問目
ttp://pc8.2ch.net/test/read.cgi/prog/1131010658/
ゲームプログラマーの人に聞きたい 13問目 (※実質14問目)
ttp://pc8.2ch.net/test/read.cgi/prog/1131024006/
ゲームプログラマーの人に聞きたい 15問目
ttp://pc8.2ch.net/test/read.cgi/prog/1143779166/
- 124 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:08:24 ]
- >>122
マルチタスクのOSの上で、各タスクにキャラクタのコードが書かれる感じ。
毎フレーム必要な処理（描画や衝突判定等）
タスク切り替えの時間としてはレジスタとメモリの移動だけ。
mainループから各キャラクタがそのフレームで必要な処理にたどり着くまでの時間よりは
早くなるし、独立したプログラムになるので汎用性も高まる。
まぁたしかに俺はロートルで大昔からやってはいるが引退気味ではあるが現役だよ。
あまりコードいじる時間はないがな・・・・
最近じゃアセンブラまで使わなくてもなんとかなるとは思うけど、
ゲーム屋としてはアセンブラが使える事ぐらいは当然だともおもっている。
１フレーム内で動かすための努力は惜しまぬ方が良いと思う。
ハードが良くなっても手抜きコードじゃすくわれない。
- 125 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:12:38 ]
- 批判するより、持ち上げて情報を引き出した方が得だと思う次第です。
- 126 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:17:41 ]
-
for(i=Num-1;i>0;i--){
for(i=0;i<Num;i++){ ←なんと言われようがこっち派
- 127 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:22:54 ]
- >126
なんか違いがあるの？
…… i>0 がゼロとの比較だから i<num より多少速いのかな？
- 128 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:42:43 ]
- アセンブラのことを考えると、これが一番速いってことになるのかな？
int i = NUM;
do {
} while (--i);
- 129 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:43:07 ]
- >>124 それってバグが出たときに追いかけるの大変じゃない？
切り替え部分はバグが無いの前提なんだろうけど
もっとシンプルな実装にした方が、複数名で開発するようなところでは安全だと思う。
あと機種依存が激しそうなので、それが使えない環境ではどうするんだよと。
そのやり方が社内では枯れてて、複数機種で実績もあるんなら問題は無いんだろうけど
新機種への移植とか考えると、あんまり採用したいやり方だとは思えないなぁ。
どうしても速度が出ないときに、最後の武器としてアセンブラを持ち出すのはありだけど。
>１フレーム内で動かすための努力は惜しまぬ方が良いと思う。
>ハードが良くなっても手抜きコードじゃすくわれない。
そら手抜きはイカンけど、シンプルさや分かりやすさの方を大切にするてのが最近の流れだしょ。
- 130 名前：仕様書無しさん [2007/02/14(水) 12:43:50 ]
- >>125
情報提供。例；画面上に弾むボールが１００個あり、ボールは壁や他のボールにぶつかると動きが変わる。
--------------------
親プロセスは
ボールプロセスランダムな位置を指定して１００個作成。
衝突判定プロセス作成
描画プロセス作成
--------------------
ボールプロセス
INIT:
終了メッセージの受付登録
衝突メッセージの受付登録
衝突判定プロセスへ自プロセス登録
描画プロセスへ自プロセス登録
PROC:
永久ループ(ボールの移動、適当なフレーム眠る）
衝突メッセージ受信：
衝突したボールの位置等から移動ベクタ変更
PROCへ戻る
終了メッセージ受信：
衝突判定プロセスへ自プロセス削除要求
- 131 名前：仕様書無しさん [2007/02/14(水) 12:44:34 ]
- --------------------
衝突判定プロセス
登録されたプロセスに対して毎フレーム処理。
衝突検知した場合は該当プロセスへメッセージ送信
--------------------
描画プロセス
登録されたプロセスに対して毎フレーム処理。
------------------------------------------------
こんな感じにすると、PROC内で必要なフレームだけ処理を行い、毎フレーム動く必要の無い処理は
タスク切り替えが発生しない状態になる。mainループから呼び出す方法にすると、呼び出した先で
結局無処理でメインループに戻らなければならない時が無駄になる。全てのオブジェクトが毎フレーム動作しなければならないようなゲーム（そんな物があるのかはわからないが）
では効果が薄いが、そうでない場合はサブルーチン呼び出しコストを最小限に抑えることができる。
- 132 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:51:01 ]
- >>124
デバッグは同じ。
切り替え部分はすごく簡単。全てのレジスタとメモリの移動だけ。
複数名で開発しているし、当然機種依存なので機種単位でOSは作る。
枯れた技術だし、実績も大量にある。
mainループから呼び出す方法からマルチタスクに変更した時には確かに
プンスカ社内から文句が出たけど、一度導入して大量のキャラクタが１フレーム
で動作するデモ見せたたら、文句が出なくなったよ。
あと使いまわしが楽になった。描画部分とキャラロジックが分離してるから。
- 133 名前：仕様書無しさん mailto:sage [2007/02/14(水) 13:05:24 ]
- >>130
えー、そんなのアセンブラレベルでやらなくてもいくらでもやりようがあるっしょ。
わざわざageてまで言うほどのもんじゃねーぞ
いわゆる古典タスク方式だと思うけど、最近はクラスでその辺を実装してるよ。
まず、全ての実行タスクはCTaskインターフェースを継承してて、
CTask型のリストなり配列なりのタスクバッファにインスタンスを登録。
メインループではタスクバッファに登録された処理を優先度にしたがって実行。
CTaskインタフェースにフラグを持たせれば、呼び出しをスキップもできるし
一時的に動作を保留するとか描画のみ行うとか衝突後再処理させるとか好きに制御できる。
あ、C++はそもそもオーバーヘッドが・・・とかの話題は勘弁な。無駄に荒れるからｗ
- 134 名前：仕様書無しさん mailto:sage [2007/02/14(水) 13:13:02 ]
- >>129
fiberとかmicro threadとか言う人もいるやつかな
状態管理をステートパターンにする必要がないとか
利点はあるけど、それを使う必要性はそれほど感じないな
それ以上はあまり突っ込まないほうがいい気がする
>>3にあるタスクシステム方向に話が流れるおそれがある
- 135 名前：仕様書無しさん mailto:sage [2007/02/14(水) 13:24:56 ]
- 「タスクじゃ！タスクさまの祟りじゃぁ！！
その話題には深入りしてはならぬぞえ・・・・」
- 136 名前：石田智史 mailto:sage [2007/02/14(水) 13:32:45 ]
- 呼んだ？
- 137 名前：前田神 mailto:sage [2007/02/14(水) 13:49:53 ]
- 死ね
- 138 名前：仕様書無しさん mailto:sage [2007/02/14(水) 13:53:12 ]
- やってる事は同じなのに「fiber（コルーチン)」なら最先端で「アセンブラによるタスク切り替え」だとロートル呼ばわりされる件
- 139 名前：仕様書無しさん mailto:sage [2007/02/14(水) 14:26:48 ]
- まずコルーチンと書けば済むことを長々と説明するところがロートルだな
- 140 名前：仕様書無しさん mailto:sage [2007/02/14(水) 14:36:23 ]
- ロートルは無駄にアセンブリャーで小技を駆使するからな。
C++で普通に書いてもかわらんちゅーに。
マルチコアでのパフォーマンス追及するならまた話が違ってくるけど。
- 141 名前：仕様書無しさん mailto:sage [2007/02/14(水) 14:47:29 ]
- 小技すら駆使しないロートルしか見たことがない。
- 142 名前：仕様書無しさん [2007/02/14(水) 14:48:18 ]
- みなさーん！
C++でアセンブラを使わずに、fiberを「普通に」実現する方法を
スーパープログラマーの>>140氏が公開するそうです。
- 143 名前：仕様書無しさん mailto:sage [2007/02/14(水) 14:52:51 ]
- おっさん「最近の若いもんはアセンブラも書けんのか」
若いもん「古株のおっさんはシェーダーも書けんのか」
- 144 名前：仕様書無しさん mailto:sage [2007/02/14(水) 15:04:51 ]
- > mainループから各キャラクタがそのフレームで必要な処理にたどり着くまでの時間よりは早くなるし
今のハードや複雑なゲームロジックで一体どの程度の差があるというの。つーか昔のハードでも。
> 独立したプログラムになるので汎用性も高まる。
どう見ても低レベル層に依存して低下している。
> ゲーム屋としてはアセンブラが使える事ぐらいは当然だともおもっている。
そうですね。俺もZ80や68000やx86でバリバリ書いてましたよ。
昨日もWrite Great Code買おうとしたけどぬるぽすぎてやめた。
> １フレーム内で動かすための努力は惜しまぬ方が良いと思う。
fiberにしない人間が惜しんでいないとでも？？
> 一度導入して大量のキャラクタが１フレーム
> で動作するデモ見せたたら、文句が出なくなったよ。
fiberを使うとキャラが大量に出せるんですか。8ビット時代のハードですら誤差範囲内としか思えませんが。
まして今なら保守性やGPU資源について頭を悩ませたほうがよいかと。
> あと使いまわしが楽になった。描画部分とキャラロジックが分離してるから。
fiberとは無関係。
タスクを全部fiberにしてしまうような文化、あるところにはあるんだろうけど
俺はそんなコードに関わりたくないし、幸いにも関わったことがない。
こういう非標準的な我流殺法にこだわる人間が近くにいると大変だろうな。
まあ、世の中にはLispを採用するような突き抜けたのがいるみたいだから、まだ可愛いものかもしれない。
- 145 名前：仕様書無しさん mailto:sage [2007/02/14(水) 16:32:02 ]
- ゲームロジックに関して言えば、今も昔も変わらないと思うよ。
- 146 名前：仕様書無しさん mailto:sage [2007/02/14(水) 16:35:21 ]
- FiberってWindows以外のプラットフォームで実装されている？
俺、Win物ずーっと作るわけじゃないから、プラットホームに依存した考えしか受け付けないのはいやだな。
- 147 名前：仕様書無しさん mailto:sage [2007/02/14(水) 16:41:24 ]
- >>138
スタック切り替え式のタスクで公開されたまともな実装というのは見たことがないし、
〜社に入社しないと教えてもらえないような技法じゃ、そんなものは存在しないと言われても仕方ないんじゃ。
技法をオープンにしてこなかったロートルにも責任はあるんじゃないかと。
>>146
自分で実装するんだよ。
カーネルモードに依存するものじゃないから、WindowsでもCreateFiber等の
APIと同じものを自分で実装できる。
- 148 名前：仕様書無しさん mailto:sage [2007/02/14(水) 18:04:10 ]
- >>144
Z80の頃を知っているのに、誤差範囲とか言える所に？
- 149 名前：仕様書無しさん [2007/02/14(水) 20:04:09 ]
- 一度だけタスクシステム（？）で開発してるところにいたことあるけど
とにかくバグが半端じゃなかった。
こらやめたほうがいいわ。
メインからサブルーチン呼び出す形が一番安定して動くしなによりバグら無い。
これがでかい。
- 150 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:19:18 ]
- メインルーチンから呼び出すやりかたのうが単純だからな。
きにしなければいけない所もすくないしね。
少しでも処理を軽くしたい昔のハードには有効なのかもね。
今ならハードにおんぶにだっこでいくらでも楽に作れるし。
まぁ、昔の人乙。
- 151 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:22:23 ]
- シェーダーも書けんのか。シェー
- 152 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:23:36 ]
- V
＿＿＿＿
∧＿∧ ／＿＿＿／|
( ´･ω･`) .| ∧＿∧ !／!
／ ＼ |（´Д｀ ）|／|
.＿＿| |__＿＿| |______..| /／／ヽ|／|
||＼／＿＿＿／| ／| .| ／.／ | | ＿＿＿＿＿
||＼|..∧＿∧ .|/.| (⌒＼|_＿./ ./|／|／＿＿＿＿／.|
||. | （ ） |/.| ~＼___＿_ノ |.| || ∧＿∧ |／|
|/ ／／|/.| ＼|.!／!!（ ）... | /.|
|| ／／ ..|/.| ＼.!/ ／／ ヽl／|
|| ／／ | |二⌒) ／|.|...|／／ | ll／|
|.|／／ .| | ヽ＼∧＿∧ (⌒＼|_＿./ /.!
- 153 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:52:34 ]
- 「うちはオブジェクト指向のタスクシステム」とかいうところにヘルプにいったら、
無駄に仮想関数使いまくりだったりダイナミックキャストの嵐でパフォーマンスが
ぼろぼろ（ステージ途中でインスタンス作りまくりのおまけつき）、
しかもタスクシステムのリソース開放タイミング管理が甘くて、ぬるぽとメモリリークの嵐で後始末が大変でした。
- 154 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:57:29 ]
- >>149
それは言い訳ジャマイカ。
システム組んだ奴や使ってる奴が糞ならどんなやり方でもバグは出るだろうに。
>>150
参考までに聞きたいんだが、そのメインルーチンから呼び出す単純な方式って奴で
複数のキャラが非同期に生まれたり死んだり、お互いに干渉するようなケースって
普通に多いと思うけど、そんな場合はどういう風に組むのが正解だと思う？
俺は昔の人なのでタスク風の書き方以外知らないんだよ。
つーかマジで教えてください、たのんます・・・
- 155 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:03:05 ]
- >>153
馬鹿が使うとそうなる
- 156 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:07:32 ]
- >>154
ゲームと関係無い。
普通にプログラムの能力が低いと思う。
- 157 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:12:56 ]
- いまどきの組み込みはX68000よりはるかに速いから
サブルーチンコール程度でグダグダ言わない。
- 158 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:23:14 ]
- >>154
普通はキャラクラスとか敵弾クラスとか地形処理クラスとか作ってメインループから呼び出すんじゃね？
タスクなんて処理作らなくてもいけると思う。キチンと設計すれ。
- 159 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:44:04 ]
- CPUの仕組みを理解すればメインだけに全部いれようが
タスクにしようがサブルーチンにしようが違いはないということがわかると思うが。
人間のための仕組みですよ。
- 160 名前：仕様書無しさん mailto:sage [2007/02/14(水) 22:26:17 ]
- >>154
>メインルーチンから呼び出す単純な方式
1.状態の数だけenumでswitch
2.状態の数だけ関数ポインタ
3.デザパタのステートパターン
4.有限状態遷移機械(FSM)でデータドリブン
- 161 名前：仕様書無しさん mailto:sage [2007/02/14(水) 22:41:39 ]
- タスクシステムとかおなかいっぱい('A`)
別に好きなように組めばいいじゃん。
いい加減、細かい処理を自前でset→long jumpとかもうそんな時代じゃないの気づけよｗ
OpenMP でガシガシ書いたほうがはるかに効率いいっつーの。
- 162 名前：仕様書無しさん mailto:sage [2007/02/14(水) 22:58:26 ]
- 擬似タスクとマジタスクが混じってる予感。
- 163 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:03:20 ]
- マジタスクってPCとスタックが復帰するやつのことですか？
- 164 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:18:37 ]
- >>160
１．ありがちだが、これだとシーンの遷移程度にしか使えんだろ。複数キャラを効率よく動かすのには別の仕組みが必要では？
２．これもよく見るけど、微妙にデバッガで追いづらい。
あと、ポインタが破壊されたらあっという間に再現しづらいバグに変化するよな。
つーか、今時関数ポインタとか古臭いよ。
３．オサレに名前を変えただけで本質的には１と変わらんよなｗ
４．データによって変化するという事はコードだけでは処理の流れが追えなくなる。
元データをそのまま使う場合はまだマシだけど、データの内容によって流れが変化するような仕様にすると（そういうケースは多いが）とたんにバグだらけ。しかも再現させずらい最悪のパターンに陥りやすい。
なんかもっとこう、スマートでエレガントでオサレでぬるぽな実装は無いのか？
- 165 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:23:59 ]
- 関数ポインタは古いのか・・
- 166 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:29:30 ]
- Gems3に関数ポインタをWrapしたtemplateクラス使った状態遷移マシンのネタがあったな。
なぜかツボにハマってそれ使わせてもらってる。
- 167 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:48:02 ]
- 個人的にhotateのページの擬似タスクのテンプレートクラス版使ってるけど
集団で作る時は、メインの人がC++好きか嫌いかで
クラスの擬似タスクか構造体の擬似タスクかのどちらかになってる。
どっちにしても関数ポインタとメモリ管理の安全がミソのコーディング手法だけど。
仕事で初めて見た時、C++の擬似タスクだったけど、これが有名な擬似タスクですね、って言っても
メインの人が「？」って感じの返答してたから。通称が無いのかもしれん。
自分は Hotate's Core とかいうホームページで実装方法知ってその人が”擬似タスク”と言ってたからそう覚えてる。
- 168 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:58:54 ]
- >>164
１と３は全然違う。１だとメイン側が状態の数を全部知ってる必要があるんで、
状態が増えるたびにメイン側をいじる必要がある。
関数ポインタがデバッガで追いづらいって、仮想関数も同じ理由で使わなかったりするの？
- 169 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:01:32 ]
- ぐぐってみたが、Hotate's Coreって無くなってるね。
- 170 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:10:06 ]
- >>167
どうせ抽象クラス（へのポインタ）をコンテナに突っ込めばできあがりな構造だろ。
NGワードを持ち出してまでひとくくりにする必要は無いと思われ。
- 171 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:13:34 ]
- >>167
５年以上前の過去ログにぴったりなレスを見つけて
面白いというか、悲しいというか変な気分になった。
pc.2ch.net/tech/kako/985/985540361.html
ここの 150 ね。
- 172 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:18:02 ]
- 最近自分のwindowsはこんな↓
メッセージスレッド（メインループ）
計算スレッド（座標ヒットチェックとか入力判定とか）
描画スレッド
サウンドスレッド（DirectSoundのおかげでほされそう）
通信スレッド
各スレッドが擬似タスクにクリティカルセクションでアクセスする感じ。
- 173 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:26:51 ]
- >>171 そのスレの65-68とか128-165とかのレスを読んでたら全米が泣（ｒｙ
2001年時点から全然進歩してねーのな、おまいら。
たぶんもっと前から同じ議論が繰り返されてるんだろうなぁ。
こりゃ日本のゲームが衰退するはずだわｗ
- 174 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:27:55 ]
-
トップクリエイターが福岡に集結！「Game for Future 2007」イベント開催！
ttp://www.gff.jp/newsDetail.php?key=20070201-020011-ip-test01-ip-t
- 175 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:54:44 ]
- まあカプコンがまだタスクとか言ってるんだから大丈夫だろ。
- 176 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:03:10 ]
- >>164
> なんかもっとこう、スマートでエレガントでオサレでぬるぽな実装は無いのか？
>160とFiberで満足できなけりゃあとはSchemeの継続でもやってくれと言うしかないね。
ゲームの状態遷移なんてその場限りの使い捨てなんだからswitchかFiberの
汚くなりやすいが軽量な手法が向いてるんじゃないかと思うけど。
- 177 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:05:42 ]
- >>165
時代はクロージャーだ関数オブジェクトまんせーデレゲートまんせーとかw
つか関数生ポインタはデータに対する生ポインタより障害は少ないと思うし、有効だと思うんだが駄目な理由はなんなんだろうな？
壊したら普通即飛びで、スタック追えは一発だと思うのだが。
- 178 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:09:34 ]
- 配列よりListやVectorがいいとかそういう程度の問題では。
初期化忘れや未定義変数へのアクセスが出来てれば
アホにもいじってもらえる。
- 179 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:30:35 ]
- >>176
＞その場限りの使い捨て
だといいですねぇ、ほんとにまったく。
- 180 名前：仕様書無しさん mailto:sage [2007/02/15(木) 05:42:52 ]
- >>177
実行するもんによって引数違うことのが多いから役にたたね。
関数ポインタ使う＝グローバルでアクセスできるなにかが必要になる。
だから、あんまりうまい設計にならないことに気がついて辞めた。
- 181 名前：仕様書無しさん mailto:sage [2007/02/15(木) 06:50:53 ]
- 稲葉敦志。神谷英樹。三上真司。そして、選りすぐりのスタッフ達。
新会社SEEDS。
ttp://www.seeds-inc.jp/index.html
- 182 名前：仕様書無しさん mailto:sage [2007/02/15(木) 06:53:09 ]
- SEEDSは社員を募集しています。
プログラマー
ゲームプログラム全般、
ツール及びライブラリ制作
CGツールプラグイン制作（XSI等)
サウンドドライバ制作
C/C++言語でのプログラミング経験
ゲーム作りに対する強い意志と忍耐力
- 183 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:04:13 ]
- なんか話が食い違うと思っていたらやっと原因がつかめた。
オレは昔の人なんだけど、擬似マルチタスクとかを作って使っていた世代。
昔は機械の性能が低くて「開発のし易さ＜実行時のパフォーマンス」だったのね。
今は機械の性能が高いから適当にできる「開発のし易さ＞実行時のパフォーマンス」なのね。
だから、ソースも出てこないFiberとかデバッグがしずらいウンヌンとかいっているのか・・・
日本のゲームプログラマも落ちたもんだ。オレは日本のソフトウェア屋でゲーム屋が一番賢い
と思っているし、日本が海外へ輸出する数少ないソフトウェアだと思ってた。
ゲーム以外のソフト開発もしているからわかるが、ゲーム屋は間違えなく平均艇に賢いし、
手際もいい。土壇場で逃げ出さない根性もあるはず。だからハードに頼らずいいものを
作って欲しい。
Cコンパイラもなく、メーカーからライブラリが提供されなくて、あるものはハードの仕様書のみ。
って状態でコツコツ作っていた時代に戻れないのはわかっているが、もうすこし魂を入れて開発
してもらいたい。
- 184 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:30:29 ]
- >なんか話が食い違うと思っていたらやっと原因がつかめた。
>>3を読めば原因は明らかだよなｗ
- 185 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:34:10 ]
- ネタにしちゃ面白くないし、マジなら引退した方がいいんじゃね？
- 186 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:38:17 ]
- >>183
俺も昔からやってるけど、擬似タスク使う奴は昔からバグ多かったよ。
１フレーム単位のキャラの動作からいって同期してねーようなもん作る奴ばっかりだった。
- 187 名前：仕様書無しさん mailto:sage [2007/02/15(木) 08:05:14 ]
- >>186
1フレーム単位のキャラの動作の同期が気なるようなゲームの場合こそ、
擬似マルチの方が適切だと思うが・・・
各タスクの動作順番をリアルタイムで変更できるし、同じタスクを二度動くように
スケジューラーをいじる事もできるし・・・・
使い方を知らないだけだと思う。
- 188 名前：仕様書無しさん mailto:sage [2007/02/15(木) 08:38:38 ]
- ttp://60.43.240.156/profile/index.html
↑DNSが反映されていない人向け
- 189 名前：仕様書無しさん mailto:sage [2007/02/15(木) 09:22:13 ]
- >>183
>昔は機械の性能が低くて「開発のし易さ＜実行時のパフォーマンス」だったのね。
>今は機械の性能が高いから適当にできる「開発のし易さ＞実行時のパフォーマンス」なのね。
違うよ、昔は開発規模が小さかったから高速化をしようとプログラム全体をチューニングできたが
今は開発規模が大きくなって、全てをチューニングしていたら何年かかっても完成にこぎ着けない、いつの間にか途中で妥協する事になるんだよ。
だからポイントを絞って高速化する必要があるし、高速化のための作業時間を捻出する必要があるの。
パフォーマンスの事ばかりをやっているとかえってパフォーマンスが下がる事に気づけ。
- 190 名前：仕様書無しさん mailto:sage [2007/02/15(木) 22:35:48 ]
- >>181>>188
こうだな
ttp://www.seeds-inc.jp/
ttp://60.43.240.156/index.html
↑DNSが反映されていない人向け
- 191 名前：仕様書無しさん mailto:sage [2007/02/15(木) 23:07:26 ]
- >>187
各タスクの動作順をいじる意味が全くわからない
長いことゲーＰＧやってるけどそんな需要は欠片もねぇ
- 192 名前：仕様書無しさん mailto:sage [2007/02/16(金) 00:49:26 ]
- それより動作順でバグが出る方がおかしいと思うよ。
- 193 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:05:33 ]
- まあ知能が低いみたいだからスルーで。
- 194 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:19:11 ]
- 擬似タスク＝クラス
擬似タスクは所詮クラスが無かった頃に、同じような機能をCで実現する為の仕組みでしかない。
ようは関数呼び出しの定型化と関数とデータのカプセル化、マルチプルインスタンスの実現を
Cでやる為に考え出されたテクニックに過ぎん。
いまさらタスクというやり方にこだわらなくても、各キャラごとのクラスを作って
シーンクラス内で処理すればまったく問題ない。
C++で組んでるくせにワザワザ、タスク処理を実装する奴がいまだにいるんだよな（激爆笑
そういう奴に限って枯れた技術マンセーとか慣れたやり方のがいいとか、ぬるい言い訳ばっかりしやがる。
…まぁ、俺のことなんだがな。
- 195 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:27:43 ]
- この流れを見て改心してくれたんなら、それはとてもうれしいことだ。
何事も完全に無駄ではないと言うことだな。
- 196 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:35:29 ]
- 動的にタスクを増やしたり親子構造にしたりできるようにすれば
タスクを名乗っててもあんま恥ずかしくないんでは。
- 197 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:45:30 ]
- 動的にインスタンスを作るのは普通にできるし
親子構造もテンプレートなりでツリー構造を実装すれば良い。
そろそろゲーム屋は擬似タスク（又は古典タスクシステム）という言葉の呪縛から脱却した方がいいと思うぞ。
- 198 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:50:17 ]
- 親子構造やツリー構造に名前をつければ解決すると思われ。
- 199 名前：仕様書無しさん mailto:sage [2007/02/16(金) 02:37:43 ]
- >>196 ダメ。ゼッタイ。
- 200 名前：仕様書無しさん mailto:sage [2007/02/16(金) 03:19:21 ]
- 魔流血多巣苦
- 201 名前：仕様書無しさん mailto:sage [2007/02/16(金) 07:10:01 ]
- >>192
壁とキャラの判定順が変わるだけですり抜けバグが多くなると思う。
- 202 名前：仕様書無しさん mailto:sage [2007/02/16(金) 11:03:18 ]
- 親子構造ってのがそもそも直感的ではなく、バグの温床になる。
ここはぜひとも、お兄ちゃんと妹構造 にすべき。
- 203 名前：仕様書無しさん mailto:sage [2007/02/16(金) 11:18:40 ]
- ワーク領域という発想の無かった俺には、天啓以外のなにものでもない。
- 204 名前：仕様書無しさん mailto:sage [2007/02/16(金) 11:32:51 ]
- >>199
ttp://www.dapc.or.jp/info/poster.htm
- 205 名前：仕様書無しさん mailto:sage [2007/02/16(金) 13:09:09 ]
- ネタが無いな。
AIについてでも語ってくれ。
- 206 名前：仕様書無しさん mailto:sage [2007/02/16(金) 13:25:31 ]
- >205
君のひとみに乾杯。
- 207 名前：仕様書無しさん mailto:sage [2007/02/16(金) 13:49:40 ]
- タスクはおいといて、ゲームのメインループってやっぱりステータスみてswitch文てのが一般的なん？
状態を変数で持つんじゃなくて評価関数を持たせる事でもっと柔軟に実装できるような気がするんだが。
たとえば色んな条件が組み合わさって、キャラの移動60%＋ジャンプ15%＋攻撃25%みたいなパラメーターを渡すと
処理の方でも渡された行動比率に従って、それぞれの処理をキャラクタの行動にフィードバックするみたいな。
たとえば通常の移動でも速度100がMAXってことにしておけば、それこそ一度処理しておくだけであとは計算の必要が無く
次回以降は比率を掛けて返すだけ。攻撃も同じで動作のモーションに対してパラメーターが渡されれば
あとは比率に応じてアニメパターンを適当に変更したり速度を変えたりするだけ。
キャラ間の干渉も比率の操作だけで住むので処理順序などに依存する必要も無く強固な構造が可能になる。
個別の処理は極力単純化しつつ、オブジェクト間の干渉度をパラメーター操作するだけで複雑な結果を作成する事ができる。
こういう風にすればゲームはもっと柔軟にプログラムすることが可能になるはず。
・・・とか妄想してみたんだが、やっぱ意味わかんねえよな。
実は俺もだ。
すまん。
- 208 名前：仕様書無しさん mailto:sage [2007/02/16(金) 14:11:32 ]
- >>207
最初の一行しか意味がわからんが、
> ゲームのメインループってやっぱりステータスみてswitch文てのが一般的なん？
C++ でそれは無い。 C でもやらない人が増えてるんじゃないの？
- 209 名前：仕様書無しさん mailto:sage [2007/02/16(金) 15:05:12 ]
- ＞C++でそれは無い。
そうか？stateパターンとか言いつつ実態はswitchで実装してるだけってのを見た事あるが・・・
＞最初の一行しか意味がわからんが、
なんか3Dでモーションをブレンドする時にパラメーターによって微妙に変化するじゃん。
そういうのを通常の処理に組み込めたら面白いなって思っただけなんだ。
キャラクタの行動やステータス変化など全てをパラメーターで操作できるようにしておいて、
外部からはパーセンテージのみでそれをいじくれて、ブレンドできたら面白いかなって。
たぶんデバッグで死ぬると思うが・・・
- 210 名前：仕様書無しさん mailto:sage [2007/02/16(金) 15:38:25 ]
- 別に長文で語るほどのことではないでしょ。
その程度のことはどこでも実装しているよ。
状態でswitchフラグだけのほうが不自然だわ。
- 211 名前：仕様書無しさん mailto:sage [2007/02/16(金) 16:17:54 ]
- >>209
ゲームでは高速化のためにブレンド比率の固定値をまわしてるだけだし、
そういうことを動的にするアプリって、モデリングソフトとかじゃまいか？
そういうゲーム作ってるってんなら星飛雄馬の姉ちゃんなみに草葉の陰から応援するけど。
- 212 名前：仕様書無しさん mailto:sage [2007/02/16(金) 16:40:35 ]
- ＞その程度のことはどこでも実装しているよ。
そうか？俺の知る限り、>>209のアイデアを形にしてるのって、「Spore」ぐらいなんだがな。しかもまだ製作中のハズ。
video.google.com/videoplay?docid=8372603330420559198
これをその程度とは・・・ハッ！？ウィルライト降臨か？
- 213 名前：211 mailto:sage [2007/02/16(金) 17:46:26 ]
- トゥイーニングがじゃなくって
その頂点がボーンマトリックスに対してどの程度ブレンドするか
を動的に設定できるようにするってんでしょ？
なんか仕事っぽいゲームしか想像できないｗ
- 214 名前：仕様書無しさん mailto:sage [2007/02/16(金) 23:03:57 ]
- 自分は、各処理毎にメイン(メッセージ)ループを持つかな。
各シーンで関係ない所を分岐チェックするのがじゃま。
- 215 名前：仕様書無しさん mailto:sage [2007/02/16(金) 23:09:15 ]
- うーん・・・そういうのもたまに見るけど、シーンの分岐チェックが嫌だからって
ループのコードが分散するのも無駄にコードが増えて美しくないような希ガス
- 216 名前：仕様書無しさん mailto:sage [2007/02/16(金) 23:39:24 ]
- 確かに、コードはかなり増える。
ただ例えば、昔のドラクエなんかだと、
戦闘中は戦闘中の事だけできればいいから、
フィールドコマンドの事には触れたくない。
戦闘ループに入る時に、味方の能力、敵の能力などの
必要なデータだけを渡し、戻り値で勝ち負けを返す感じにする。
ただ逆に、戦闘中にフィールドの情報、
例えば、水に居る時は水属性が有利になるとか、
拡張させる時に、めんどくさくなる場合もある。
- 217 名前：仕様書無しさん mailto:sage [2007/02/16(金) 23:52:20 ]
- 俺は個別にループを作る方が好きだな。
フラグのon/offが分散する方が嫌だ。
といっても好きに組めることはほとんどないし、さすがに慣れたけど。
- 218 名前：仕様書無しさん mailto:sage [2007/02/17(土) 00:12:36 ]
- おお、数少なき同士よ・・
自分は個人製作だから、共同の場合は、
switch型、個別loop型が向いているとかあるんかな。
- 219 名前：仕様書無しさん mailto:sage [2007/02/17(土) 00:40:18 ]
- >>218
個人と法人(共同開発)は、その部分に限らず別物だわさ。
手間よりも品質と分業効率が優先される。
- 220 名前：仕様書無しさん mailto:sage [2007/02/17(土) 00:59:33 ]
- 誰かが使ってくれると信じて作ってはみたものの、使われないクラスたち・・・
- 221 名前：仕様書無しさん mailto:sage [2007/02/17(土) 01:12:43 ]
- >>215
そういう時は関数の銘銘規則を見直して、関数の配置位置を整理してみるといいよ。
はー、最近自動リファクタになれてしまってリファクタつらい、自動リファクタツールが欲しい、C++のリファクタ面倒くせー
誰かー諸悪の根源プリプロセッサをぶっ潰してくれー
- 222 名前：仕様書無しさん mailto:sage [2007/02/17(土) 01:43:44 ]
- 必要のないものは親子構造から切り離す。
ツリー式のタスク作ればループ1個で必要なものだけを
処理できて幸せになるよ！
- 223 名前：仕様書無しさん mailto:sage [2007/02/17(土) 02:07:07 ]
- またNGワード出たな。
Stateパターンでいいだろ。適当に入れ子にして。
- 224 名前：仕様書無しさん mailto:sage [2007/02/17(土) 02:20:20 ]
- ループをいっぱい作ってるやつに言ってやれよ。
|
 |
