- 1 名前：名前は開発中のものです。 mailto:sage [2009/04/03(金) 11:25:39 ID:aSgRO8Wl]
- タスクシステムについての議論、相談、質問、雑談などのスレです
part5 pc11.2ch.net/test/read.cgi/gamedev/1234977661/
part4 pc11.2ch.net/test/read.cgi/gamedev/1233459490/
part3 pc11.2ch.net/test/read.cgi/gamedev/1226199100/
part2 pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 pc11.2ch.net/test/read.cgi/gamedev/1173708588/
・タスクと呼ばれる実装は、非常に多岐に渡ります
古典タスクシステムについての話題は「>>2」と明示してください
そうでない場合はカスタム版であることを明示してください
・人を憎んで言語を憎まず
- 97 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 01:31:57 ID:B8zjnpJZ]
- >>92
Bだな。
ところで、お前が>>42で示した実装だと、型ごとにポインタをcollectionしてるから、
型を飛び越えて処理順序のプライオリティーをつけることは出来ない。
だから、>>92で言うプライオリティーとは、同一型内での処理順序のプライオリティーだと考える。
だからvector<T>（のようなもの）に実態を持っておいて、プライオリティーの変更があれば、
その都度vector<T>内の該当要素を挿入しなおす実装で問題ない。
>B.なら、上に書いたのと同じ理由に加えて、動的な型を判定してvector<T>に突っ込んだり、
>その参照を書き換えたりするコストが必要になるので、あんたが思っているようには速くならない。
テンプレートを使えばよい。
template < class _T >
std::vector< _T > *get_heap(){ static std::vector< _T > heap; return &heap; }
template < class _T >
_T *New()
{
get_heap<_T>()->resize( get_heap<_T>()->size()+1 );
return &get_heap<_T>()->back();
}
hoge_task *p = New< hoge_task >();
お前本当にソフト屋か？
- 98 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 01:51:15 ID:y7ZcPLoJ]
- >>93
> 最適なデータ配置はゲームの仕様によりけりで、
> ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は
> 無意味だと言うのに。
全くその通りなんだけど、ほぼ
タスクシステムを実装する人＝それを使う人
なんじゃないのかな。
少なくとも仕様について直接話ができる関係でないと
タスクシステム自体を使えないと思う。
つまりありえない仮定を置いて否定するのはフェアじゃないし
技術の話としても意味が無いと言いたい。
- 99 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 01:53:56 ID:B8zjnpJZ]
- 並列さん ◆dPfetnROQg よ・・・
現実逃避目的にプログラム書くのなら、もうプロ辞めろ。
タスクシステムでキャッシュヒット率を上げようという目的も不味ければ、
その実装手段も不味い。
普通、どちらかぐらい真っ当なものなのだが。
これからは農業の時代だと聞くぞ。
- 100 名前：98 mailto:sage [2009/04/06(月) 01:59:15 ID:iTEC611J]
- 一応書いとくと並列さんの味方したいわけじゃなくて
並列さんの主張は独善的で視野が狭いと思う。
# 技術的な話を盛り上げるためにつっこみどころ満載の
# ネタを意図的に投下してるのかもしれんけど
- 101 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 02:07:50 ID:B8zjnpJZ]
- >>98
>タスクシステムを実装する人＝それを使う人
だったとしても、
>ゲームの仕様を知れないタスクシステム側
であることには変わりないわけで。
どうであれ、キャッシュヒット率まで考えたデータの配置を考えると言うのなら、
(タスクシステムを実装する人＝それを使う人、で有ろうが無かろうが)
タスクシステムの外から行う方が話が早い。
- 102 名前：98 mailto:sage [2009/04/06(月) 02:44:56 ID:H9N6h/U7]
- >>101
ごめん。ゲームの仕様に合わせて毎回設計するという仮定をしてることに
101で気がついた。書かなきゃわからないのに話があうわけないよね。
話に参加できるほど賢くないとわかったので観客に戻ります。
- 103 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 02:57:00 ID:yXbkibtb]
- >>93
> 最適なデータ配置はゲームの仕様によりけりで、
> ゲームの仕様を知れないタスクシステム側からデータ配置の最適化をする事は無意味だ> と言うのに。
違うね。タスクシステムであるからには、タスクプライオリティに従って
タスクが呼び出されることは保証されるわけで、呼び出し順がわかっているので
それに従ってGCするときに配置換えすることは出来る。
> 型ごとに配列で保持してコンパクションかければ良いだけのものを、
これも違うね。型ごとに集めればworking setは小さくなるが、
その集合に対してメモリの先頭から逐次的にアクセスしていく
保証はされない。
- 104 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:00:20 ID:yXbkibtb]
- >>95
> ゲームの仕様によって変わるものをその下の層に
> 無理やりねじ込もうとしてる時点でもうダメなんだよ
これも違うね。
GCはどんなゲームを作る場合でもあって困るということはあまりない。
GC環境下(例えばXNAでも.NET Framework + WPFでも)で
プログラムをすればその便利さがわかると思うのだが。
GCを否定する馬鹿がこんなにいるんだな。このスレ阿呆の集まりか？
>>96
馬鹿はあんただろろ。ろくにプログラミング経験もないなら
口出ししてくるなよ。
- 105 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:10:23 ID:yXbkibtb]
- >>97
> プライオリティーの変更があれば、
> その都度vector<T>内の該当要素を挿入しなおす実装で問題ない。
「挿入しなおす」って、removeしてinsertするって意味？
プライオリティが変わるごとにstd::vectorに対してそんなことしたら
重くて仕方ないんだけど。
何がどう問題ないと思えるの？頭大丈夫？
> hoge_task *p = New< hoge_task >();
> お前本当にソフト屋か？
それnewしたときに型がわかっていて、その型のvectorに
突っ込んでるだけじゃん。>>92のBじゃなく、Aでしょうに。
あと「その参照を書き換えたりする」必要があると俺は書いてるが、
それはどうやって解決するつもり？
- 106 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:13:17 ID:yXbkibtb]
- >>99
> 現実逃避目的にプログラム書くのなら、もうプロ辞めろ。
あんたが俺が言ってる内容を何も理解してないだけじゃん。
あんたは日本語の勉強しなおしてきたほうがいいよ。
- 107 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:14:58 ID:yXbkibtb]
- >>101
> どうであれ、キャッシュヒット率まで考えたデータの配置を考えると言うのなら、
> タスクシステムの外から行う方が話が早い。
わかっちゃいると思うが、俺の言っている
GCは実際はタスクシステムの"外"に実装されているよ。
GCにタスクの呼び出し順というヒントを与えて、それを利用して
うまくオブジェクトをアレンジメントできるかということを
問題にしているだけなんだが。
- 108 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 03:20:24 ID:B8zjnpJZ]
- >違うね。タスクシステムであるからには、タスクプライオリティに従って
>タスクが呼び出されることは保証されるわけで、
>>42 を見る限り、型ごとにcollectionを持っているようだが。
どの型のcollectionのupdateから実行していくかは、for_eachを記述した順に決定されるわけで、
プライオリティーによらないと考えるが。
>その集合に対してメモリの先頭から逐次的にアクセスしていく
>保証はされない。
だったら並べ替えればよい。要は最適化する順番が逆。
まず型ごとに集めることを考えて、それから並べ替えることを考える。
まぁそれすら意味がないどころか余計なことだと思うがな。
どうせやるならということで。
>GCはどんなゲームを作る場合でもあって困るということはあまりない。
だから、いつからGCの話になったんだ？
- 109 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 03:33:51 ID:B8zjnpJZ]
- >プライオリティが変わるごとにstd::vectorに対してそんなことしたら
>重くて仕方ないんだけど。
プライオリティーなんて滅多に変わらないだろうし、現実問題として、それで問題ないだろう。
付け加えて、俺はそもそもコンパクションなんて要らないといってるわけで。
それにはコンパクションが重い処理だからという理由も含まれている。
>それnewしたときに型がわかっていて、その型のvectorに
>突っ込んでるだけじゃん。>>92のBじゃなく、Aでしょうに。
お前の日本語が分かりにくいんだよ。自分の世界の定義で言葉使うから。
>B. 動的にオブジェクトを移動させvector<T>に入れる
の意味が謎。型なんて生まれてから死ぬまで変わらないんだから動的に管理する意味なんてないだろ。
>あと「その参照を書き換えたりする」必要があると俺は書いてるが、
>それはどうやって解決するつもり？
好きな方法でやれば？これはお前の言うところのコンパクションでも同じ問題が発生するでしょ。
- 110 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:36:49 ID:yXbkibtb]
- >>108
> >>42 を見る限り、型ごとにcollectionを持っているようだが。
> どの型のcollectionのupdateから実行していくかは、for_eachを記述した順に決定され> るわけで、
それは、俺がGC側でcompactionを行なうときにタスクを並び替えて、
並び変わったあとのcollectionを返しているからそうなっている。
あんたが、自前でcompactionを行なうなら、自分でタスクプライオリティに
従って並び替えをしないといけないし、並び替えをした上で同じ型のcollection同士を
集めたものを用意してからupdate(vector<T>)のような関数を呼び出す必要がある。
> まず型ごとに集めることを考えて、それから並べ替えることを考える。
「型ごとに集めることを考えて、それから並べ替える」ほうが、
「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは限らないんだが。
そんな自分のやりやすい方法を言われても。
- 111 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 03:38:52 ID:B8zjnpJZ]
- >>107
タスクシステムの外と言う言葉を使ったが、下位層は含まず、上位層という意味で使った。
ごめんね、そこまで細かく言ってあげなきゃ分からないよね。
それとも、下位とか上位という概念がなく、内か外でしか物事を考えられないのかな？
まぁ、GCにタスクの呼び出し順を食わせようとしている時点で既にアレなのだが。
- 112 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:41:43 ID:yXbkibtb]
- >>109
>>B. 動的にオブジェクトを移動させvector<T>に入れる
>の意味が謎。型なんて生まれてから死ぬまで変わらないんだから動的に管理する意味なんてないだろ。
確かに上の(俺の)日本語、わかりにくいな。それはすまんかった。
生成時にいったんvector<T>に入れてオブジェクトが死ぬまで
アドレスの変更などが発生しないのがA。
それに対して、描画フレーム毎に、オブジェクトを移動させ
compactionを行なうという意味がB。
- 113 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 03:45:41 ID:yXbkibtb]
- >>109
>>プライオリティが変わるごとにstd::vectorに対してそんなことしたら
> プライオリティーなんて滅多に変わらないだろうし、現実問題として、
> それで問題ないだろう。
あんたの実装、vector<T*>ではなく、vector<T>だよな？
オブジェクトが死ぬごとにremoveが発生してそこ以降のオブジェクト全部
コピーすることになるんだが、これ、いつ後始末するつもりだ？
また死んだオブジェクト(タスク)はどうやって判定するつもりだ？
オブジェクトひとつずつにデリートマークがあって、foreachのときに
デリートマークをチェックしながらiterationを行なうのか？
それともどこかで死んだオブジェクトを詰める(removeする)作業をするのか？
そのときにそこ以降のオブジェクトのアドレスが書き換わるから、
それを参照しているポインタ全部書き換えなきゃならんのだが。
本当にそんな実装が速いと思うのか？
- 114 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 03:53:18 ID:B8zjnpJZ]
- >あんたが、自前でcompactionを行なうなら、自分でタスクプライオリティに
>従って並び替えをしないといけないし、並び替えをした上で同じ型のcollection同士を
>集めたものを用意してからupdate(vector<T>)のような関数を呼び出す必要がある。
型ごとにheapを持つようにすれば同じ型同士を集める必要はないし、
タスクプライオリティーも、変更されるその都度挿入し直せば、並べ替えを行う必要もなくなる。
当たり前だが、挿入と並べ替えだと、並べ替えの方が重い。
>「型ごとに集めることを考えて、それから並べ替える」ほうが、
>「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは限らないんだが。
>そんな自分のやりやすい方法を言われても。
後者よりも前者の方が常に速い。
前者だと、
１．型ごとに集める処理を端折れる。
２．型ごとに並べ替えた方が速い。なぜなら並べ替えの計算量はO(n*logn)だから。
- 115 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:00:55 ID:yXbkibtb]
- >>114
> タスクプライオリティーも、変更されるその都度挿入し直せば、
> 並べ替えを行う必要もなくなる。
> 当たり前だが、挿入と並べ替えだと、並べ替えの方が重い。
並べ替えは毎フレームしなくとも良いが(GCが走るのはときどきなわけだし)、
タスクプライオリティは変更と同時に挿入しなおさなければならないから
その比較はおかしい。
まあ、タスクプライオリティを頻繁に変更するかと言われれば
確かに普通はノーだと思うんだが、生成は頻繁に行なうわけで、生成時にタスク
プライオリティが与えられていてその適切なところにinsertする
コストはとても無視できない。
- 116 名前：ID:B8zjnpJZ mailto:sage [2009/04/06(月) 04:01:06 ID:RuQXDnG2]
- >>113
それは好きにすればよいと思うが。
>それを参照しているポインタ全部書き換えなきゃならんのだが。
オブジェクトに不変なハンドルつけて間接参照にしたり、
ポインタをラップしてリストアップしたり。
>本当にそんな実装が速いと思うのか？
コンパクションを行うということはそういうことだろうに。(だから要らないと言ってるのだが)
つーか、並列さん ◆dPfetnROQg はコンパクションを何だと思ってるんだ？
- 117 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 04:09:51 ID:RuQXDnG2]
- >生成は頻繁に行なうわけで、生成時にタスク
>プライオリティが与えられていてその適切なところにinsertする
>コストはとても無視できない。
型ごとにheapを持ってればそんなむちゃくちゃな事にはならないし、
どちらかというと、不定期にGCが発動して、そのフレームだけ局所的に負荷が高くなる方が困る。
ゲームでGC使うのが嫌われる理由と同じだな。
- 118 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 04:13:47 ID:RuQXDnG2]
- >並べ替えは毎フレームしなくとも良いが(GCが走るのはときどきなわけだし)、
>タスクプライオリティは変更と同時に挿入しなおさなければならないから
>その比較はおかしい。
リアルタイム処理では一番負荷の高い瞬間で比較しなければならないので、
その比較であってる。いわゆるボトルネックという奴。
- 119 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:19:36 ID:yXbkibtb]
- >>114
>>「型ごとに集めることを考えて、それから並べ替える」ほうが、
>>「並べ替えてから型ごとに集める」だとか「その二つを同時に行なう」より速いとは
>> 限らないんだが。
>> そんな自分のやりやすい方法を言われても。
>後者よりも前者の方が常に速い。
>前者だと、
>１．型ごとに集める処理を端折れる。
>２．型ごとに並べ替えた方が速い。なぜなら並べ替えの計算量はO(n*logn)だから。
1.は、意味不明。「型ごとに集めることを考えて」なのだから、端折れてないと
思うんだが。
2.は、どうもあんたはまだ話がわかっちゃいないと思う。
- 120 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:22:45 ID:yXbkibtb]
- >>114
次の4つのインスタンスがあるとしよう。
Task A : プライオリティ = 1
Task A : プライオリティ = 4
Task B : プライオリティ = 2
Task B : プライオリティ = 3
Task A,BはTaskという基底クラスの派生型でvector<Task*>にぶち込まれていて
これをいま呼び出し順を考慮しながら型ごとに分類しないといけないとしよう。
collection I.
Task A : プライオリティ = 1
collection II.
Task B : プライオリティ = 2
Task B : プライオリティ = 3
collection III.
Task A : プライオリティ = 4
呼び出し順を考慮して、上のように分類されてcollectionが
生成されなければならない。
「型ごとに集めることを考えて、それから並べ替える」ほうが速いか？
それに同じ型に対するcollectionは上のように複数いるぞ。
この意味で、>>97のような実装は不可だ。
- 121 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:32:06 ID:yXbkibtb]
- >>116
> オブジェクトに不変なハンドルつけて間接参照にしたり、
> ポインタをラップしてリストアップしたり。
だから、そんなプログラムが速いわけないだろ。
ハンドルに対する実アドレスのテーブルをcompactionのときに
更新しないといけないぞ。
他のタスクオブジェクトを参照するごとに
TaskA taskA= dynamic_cast<TaskA*>HandleToPtr(taskA_handle);
みたいに書く必要が出てくる。
プログラムが汚い上にハンドルだから型が不明になってしまう。
これひどくないか？
> コンパクションを行うということはそういうことだろうに。
それは、全然違うと思うぞ…。
少なくとも俺のシステムにあんたの実装のような欠陥はないな。
- 122 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:33:07 ID:yXbkibtb]
- >>116
> 型ごとにheapを持ってればそんなむちゃくちゃな事にはならないし、
(一般的には)型ごとにheapを持てない。理由 >>120。
- 123 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 04:35:38 ID:RuQXDnG2]
- >>119
型ごとに既に集まってるんだから、型ごとに集め直す必要はないだろ。
例えば、林檎と蜜柑と梨が何個かずつ有って、それぞれ種類別に箱に入ってるとする。
それぞれの果物には賞味期限があり、売れ残りを防ぐため、古いもが手前に来るように陳列したい。
A：林檎と蜜柑と梨をごちゃまぜにして、賞味期限順に並べ替えてから、改めて種類別に分け直す。
B：単にそれぞれの種類内で賞味期限順に並べ替える。
どっちが早いか。
- 124 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:38:38 ID:yXbkibtb]
- >>117
> どちらかというと、不定期にGCが発動して、そのフレームだけ局所的に負荷が高くなる方が困る。
さすがにそんなことは普通はない。
いや、あるにはあるが、そうならないように気をつけてコーディングする。
それすら出来ないなら、そもそもXNAでゲームプログラムなんて出来ないわけで…。
>>118
> リアルタイム処理では一番負荷の高い瞬間で比較しなければならないので、
> その比較であってる。いわゆるボトルネックという奴。
ボトルネックがコマ落ちしたりするほど大きくないなら、全体的なスループットのほうが大切。
- 125 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:39:51 ID:yXbkibtb]
- >>123は>>120を読む前に書かれたものだと思うので無視する。
- 126 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 04:46:06 ID:gHjH+Kkr]
- もうね、
タスクシステムありきでいろんな問題（コンパクション・キャッシュヒット）に対処していくと、
最終的にはこんなことになってしまうかもしれないという悲劇の具体例にしか見えない。
- 127 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 04:50:53 ID:yXbkibtb]
- このスレではなんかメモリのコンパクション不要論を唱えてる
馬鹿ばっかりなんだが実際「ワンダと巨像」でもメモリの
コンパクションは、行なっている。
しかも「ワンダと巨像」ではテクスチャ、地形データのみならず、
プログラムコード自体も再配置の対象となっている。
ある程度の規模のゲームなら、やらざるを得ないと思うんだが。
お前たちは、本当にゲームを作っているのか？
夢のなかで作ってるだけなんじゃね？
プログラミング見習いとか、同人ゲー作ってますとか
サブプログラマーとしてスプライト処理手伝いましたとか
そんなゴミクズみたいな奴ばっかり出てくんなよ。
俺はもう寝るぞ。明日も早いからな。おやすみ。
- 128 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 04:55:46 ID:RuQXDnG2]
- >>120
後出しじゃんけんのごとく次から次へと変な実装例を出してくるなよ。
プライオリティーも型として扱えば？まぁプライオリティー固定になるが。
template < class t, int priority > とかして。
>>121
>プログラムが汚い上にハンドルだから型が不明になってしまう。
>これひどくないか？
そう思うのならラップすればよいだろ。本質的には同じこと。
- 129 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 05:18:01 ID:WGJzP9Yk]
- ＞プログラミング見習いとか、同人ゲー作ってますとか
いや、そもそもここはそういう人のための場だろ。
メイン張ってるプロ中のプロがこんな場所に出てくるんだったら、
そういう人たちに分かるように説明すべきじゃないのか？
つか、場当たり的に情報小出しにするより、ちゃんとまとめて本でも書いてくれ。
次のやねう本より先に出せば結構売れるんじゃないか。
- 130 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 05:24:15 ID:B8zjnpJZ]
- >>124
>そうならないように気をつけてコーディングする。
だったら、普通にメモリプールで十分なわけで。
>ボトルネックがコマ落ちしたりするほど大きくないなら、全体的なスループットのほうが大切。
意味不明。コマ落ちしないなら、既に仕様を満たしているわけで、スループットも糞もないだろ。
>>127
ほとんどのゲームでは行ってないだろ。でもちゃんと動いている。それが現実。
一部の例外だけ取り上げて、さも当たり前かのように言うな。
- 131 名前：名前は開発中のものです。 [2009/04/06(月) 05:40:29 ID:FyQkrEyW]
- 横からだけど、ID:B8zjnpJZさんはちょっと素人っぽいよね。
私から見てても、なんか言ってることのレベルが低いというか。
実際に商用である程度の規模のゲームを作った経験のある人が
もっと並列さんに質問してほしいな。
- 132 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 06:20:06 ID:/+Me6qfs]
- まだ、やってんの？
あったまわるい
話受けるほうも相手にするなよ
- 133 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 06:43:47 ID:VcqDZA+W]
- 夜を徹して生産性を下げる工作が成功してるようだな
しかしまともな議論をするなら情報後出しと言われないように議論命題に関する
クラス図なり、シーケンス図（サンプルシナリオ）なりを先に明示すべきだと思う
土台が無い状態で前提の違う俺言語同士の闘いをしてて不毛すぎる
- 134 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 07:10:15 ID:QqdC07mx]
- >103
> これも違うね。型ごとに集めればworking setは小さくなるが、
> その集合に対してメモリの先頭から逐次的にアクセスしていく
> 保証はされない。
アクセスループに入る前にキャッシュの先読みくらいしとけよ。
- 135 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 07:24:50 ID:QqdC07mx]
- >127
> ある程度の規模のゲームなら、やらざるを得ないと思うんだが。
フリーラン系でも無い限り、プレイ中にコンパクションなんてやらない。
シーン切り替えのタイミングでコンパクションすることはあるけどもね。
それよりも、シーンごとに破棄できるデータと常駐データを幾つかのレベルに分けて管理したほうが
楽だよ。
- 136 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 09:03:31 ID:yXbkibtb]
- >>128
> そう思うのならラップすればよいだろ。本質的には同じこと。
全然同じじゃない。
>>133
> しかしまともな議論をするなら情報後出しと言われないように議論命題に関する
そんなもん誰が読むんだ？悪いけど俺はそんなもの作成するのは嫌だ。
>>134
> アクセスループに入る前にキャッシュの先読みくらいしとけよ。
そんなことで解決する問題じゃない。
一般的に言って、L1に相当するメモリは極端に小さいからループに入る前に読み込んでも無駄だし、
指定しなくともどこか1バイトを読み込んだら、次のalignmentまで自動的に読み込む設計になってるのが
普通だから、いまどきのCPUアーキテクチャはランダムアクセスに対してはすこぶる弱い。
だから、先読みでは解決しない。
- 137 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 09:06:56 ID:yXbkibtb]
- >>135
> それよりも、シーンごとに破棄できるデータと常駐データを幾つかのレベルに分けて管理したほうが楽だよ。
そりゃ、仕様が事前にわかっていればそりゃそうしたほうが楽だろう。
しかし、いまどきのゲーム、シーン切り替えなんてほとんどなくてシームレスにつながっていることが多いから、
そういうケースに備えて、ライブラリ的なものを準備するのが俺の仕事。
- 138 名前：並列さん ◆dPfetnROQg mailto:sage [2009/04/06(月) 09:14:12 ID:yXbkibtb]
- >>129
> メイン張ってるプロ中のプロがこんな場所に出てくるんだったら、
> そういう人たちに分かるように説明すべきじゃないのか？
そんな面倒な説明、俺は嫌だ。
少なくとも商用ゲーム開発してるプログラマだけ俺に質問してくれ。
それ未満の見習い君は黙ってROMってて欲しい。
>>131
確かにID:B8zjnpJZは素人っぽいではある。>128,130とかひどすぎて答える気にもならん。もうスルーしとく。
そもそもGC環境下でゲームプログラムを書くメリットとか、俺がこのスレで説明するこっちゃないと思うんだ。
実際に自分でXNAとかで開発して理解するか、もっとお偉方に聞いて欲しいなぁ。
- 139 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 09:49:19 ID:ptgzTYVC]
- アンチの中に配列好きの厨が混じってて吹いたw
- 140 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 09:58:39 ID:LCTic4Nk]
- つーかこの分量になると流し読みすらせずに流しちゃうな
- 141 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 12:07:22 ID:10SNKjhU]
- アンチかつプロの人はステージとかシーンでゲームをくぎって、その場面に必要な物だけをハードコーディングするような昭和ゲームつくってるんだろ
now loadingとかやめろよwww
- 142 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 12:13:20 ID:2tToa48s]
- 本当に叩きたい人に当たるようにブーメラン投げてるんですね。
わかります。よくある手ですから。
- 143 名前：名前は開発中のものです。 [2009/04/06(月) 18:50:33 ID:EhlRmjEd]
- 速度の話に区切り付けてから次の話題振れよ
- 144 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 19:12:19 ID:/+Me6qfs]
- >並列さん
根幹がズレてるのに
まだ、長々と話してるの？
自分のはじめた話のケツぐらいふけるようになってから議論しろよ
理論的にはじめの一歩目ですでにダメなのにそこには目を瞑って
オレオレシステムのいいとこ探しなんてはじめた時点で
お前はもう技術者でもなんでもねぇ
ただのクズだ
- 145 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 19:25:58 ID:TigQ7s0b]
- まだ続けるつもりか
いいぞもっとやれ
- 146 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 19:30:18 ID:YVQYCAyD]
- 古典タスクシステムとそうでないのとの違いを教えてください。
比較があるHPが有りましたら教えてください。
- 147 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 19:36:40 ID:/+Me6qfs]
- >>146
そんな受身で技術なんか見に付くわけない
やめちゃえ
- 148 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 19:39:57 ID:VcqDZA+W]
- つかえない子が頑張ってるのがたのしいな
まともに説明できてない時点で自分の脳内でしか認められないものだと気付かないの？
- 149 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 19:52:04 ID:kenh3Yca]
- ワンだと虚像って前評判ほど面白くなかったな。
見た目が派手なだけでパターン憶えゲーの中でも平凡なゲーム。
- 150 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 20:15:34 ID:uIjIdPYQ]
- 面白さがタスクシステムと関係あるの？
- 151 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 21:21:10 ID:B8zjnpJZ]
- ゲーム業界VSアマチュアという構図が出来つつなるな。
ゲーム業界でがんばって来た人には、それなりにプライドもあるだろうし、触れられたくないこともあるのだろうな。
すべてが無駄だと薄々感づいてはいるのだろうが、気づかないふりをして毎日がんばってるのだろう。
- 152 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 21:23:11 ID:QqdC07mx]
- >136
> そんなことで解決する問題じゃない。
> 一般的に言って、L1に相当するメモリは極端に小さいからループに入る前に読み込んでも無駄だし、
> 指定しなくともどこか1バイトを読み込んだら、次のalignmentまで自動的に読み込む設計になってるのが
> 普通だから、いまどきのCPUアーキテクチャはランダムアクセスに対してはすこぶる弱い。
> だから、先読みでは解決しない。
コンシューマ触ったこと無いのバレバレだな。
- 153 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 22:20:23 ID:kRCgeJ2q]
- XNAで開発された商用ゲームってあるのかなぁ？今のところ国内メーカーはネイティブで作ってるみたいだけど。
カンファレンスでもXNAはホビーユース向けって感じだったし。
まぁそもそもMSと心中するつもりがなきゃMS縛りのXNAで開発なんてしたくないけどな。
- 154 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 23:13:38 ID:lXwqXQrR]
- >>153
黙ってろ
- 155 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 23:17:12 ID:/+Me6qfs]
- >>154
ＭＳ社員m9（＾Д＾）プギャー
- 156 名前：ID:EEKBitmg ◆HSP4mee/SU mailto:sage [2009/04/07(火) 00:14:39 ID:lzvNjqQS]
- ガキの直感だけど
並列君ってやねうらおさんの臭いがする
- 157 名前：ID:EEKBitmg ◆HSP4mee/SU mailto:sage [2009/04/07(火) 00:44:42 ID:lzvNjqQS]
- >>10
（；・∀・）えー、なにそれ。そんなむつかしーこと考えたことないよ厨房だから
ぜーんぶダイレクトエックスにお任せだよ
テクスチャは基本的にD3DPOOL_MANAGEDでロードしてる
（ポストエフェクト用のバッファとかはD3DPOOL_DEFAULTだけど）
＞一括解放するタイミングは存在せず、仕様切りなおしもできないとして
ナニそれよくわかんない。どんなゲームなの。
厨房はレベルデータをロードするときにテクスチャも何もかもまとめて
ガバーって読み込んじゃってるけど
数GBのメインメモリに数百MBのオンボードメモリを使い放題のやりたい放題だし
メモリ足りないド貧乏PCユーザーはHDDにスワップでジリジリやってろってかんじ
＞使用期間不定の大量のサイズ不定テクスチャをコンパクションを使わずにどう管理する？
寿命がわかんねー大量のサイズ不定テクスチャがあるってどんな状況なの？
厨房が作るゲームはリソースの寿命が明らかだから、よくわからない
- 158 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 00:46:51 ID:chqHE1jh]
- 並列さんはポリアンナ症候群だろ
- 159 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 01:22:29 ID:TxMcBONy]
- >>155
本当に知ったかウザい
心中云々言ってたらBrewもiPhoneもDirectXもやってられません
- 160 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 02:06:38 ID:6TbCKYIt]
- HSPにXNA…
このスレにはマイナー言語に命かけてる人たちがいるねぇ
どっちもタスクシステム向きでないけど
- 161 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 02:23:02 ID:5k9r+ezc]
- HSPはともかくXNAをマイナー言語扱いするのはどうだろう
- 162 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 03:00:31 ID:7U5MSg6Z]
- >>159
任天堂系もＳＣＥ系もダメですね・・・
- 163 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 12:38:34 ID:d98F5Avl]
- >>156
あんたそのレベルの人なのか
- 164 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 13:00:48 ID:t5WTHMua]
- なんとかシステムとかつけるなら
スクラッチパッドみたいな局所メモリを活用するとか
ある程度ハード特化した実装にするのも手なのかな
GDC2009のGOW3の解説がなんというか燃える内容だったんだけど
game.watch.impress.co.jp/docs/series/3dcg/20090401_80260.html
これはもはやなんとかシステムとか呼ぶ範疇を超えてる気がするけど
将来はこういうのがなんとかシステムとか呼ばれるようになるのかね
- 165 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 17:07:05 ID:CbUdK8rx]
- 確かにワンダつまんなかった。
ムービー見て終わり。
メタルギア4もそう。
- 166 名前：名前は開発中のものです。 [2009/04/07(火) 17:28:04 ID:rVXLClOu]
- で？
技術批判できなくなったら今度はゲームそのものに攻撃か。
あたたかい頭してるな。
- 167 名前：名前は開発中のものです。 [2009/04/07(火) 19:14:31 ID:1GDmqaJq]
- タスクシステム関係無いじゃん
- 168 名前：名前は開発中のものです。 [2009/04/07(火) 19:21:43 ID:1GDmqaJq]
- タスクシステムもメリット挙げてみろって言われると
途端にはぐらかすからな
いろいろ虎の威を借るなんとやらで参考文献および資料ばっかりもってくるけど
そういうの自分の言葉で説明できるようになってからやらないと説得力ないよね
引用レスも引用したものがメインじゃ誰も相手にしないって
- 169 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 19:25:38 ID:CBx7pnt0]
- だからメリットはリンスインシャンプーだっての！
- 170 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 20:08:43 ID:WMY4fAPQ]
- お金稼げてるからいいんじゃね？
それを否定するともっとお金稼げるなら俺もアンチになる
- 171 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 20:20:07 ID:chqHE1jh]
- >>170
金がほしいならゲーム会社なんて辞めたほうがいいぞ
かなりマジで
業務系いけば、ゲーム系で月１４〜５万でこき使われてる人ならいきなり給料倍とかある
- 172 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 21:33:44 ID:ulVvxTge]
- ID:EEKBitmgはもうあまりにレベルが低すぎて、みんなスルー状態だな。
- 173 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 23:00:06 ID:chqHE1jh]
- >>172
俺は並列のがうぜぇ
- 174 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 23:06:56 ID:2stCxtH4]
- まあフェードアウトオヤジ臭という意味では
並列さんとやね先生は同じ体臭を放ってるけどな
- 175 名前：名前は開発中のものです。 mailto:sage [2009/04/07(火) 23:23:22 ID:wsnDcgD2]
- だいたい、アタマがまともな本職やセミプロは、こんなところで『オレ様スゲーだろwww』とか
書き散らかさないって。
- 176 名前：名前は開発中のものです。 mailto:sage [2009/04/08(水) 00:39:13 ID:DU4wvLd/]
- 本人も、今頃しまったと思ってるころだろ。
- 177 名前：名前は開発中のものです。 mailto:sage [2009/04/08(水) 01:29:22 ID:9bhojcbs]
- てゆーかここ
どんだけ偉人ばっかりなんですかｗ
みんなめちゃくちゃ上から目線なんですけどｗｗｗｗ
- 178 名前：名前は開発中のものです。 [2009/04/08(水) 07:38:26 ID:uu59oW9Z]
- 別にそんな感じはしないけど
何か気に入らないレスが付いちゃった？
- 179 名前：名前は開発中のものです。 mailto:sage [2009/04/08(水) 09:16:12 ID:Ju8SopqO]
- 並列擁護は「第三者の"人達"から見て」 的なレスが多くてうんざりだな
国際社会とか地球市民とかそういう匂いがする
語ってる内容はどっちも滅茶苦茶なのでもうどうでもいいんだが
まあ勘違い分裂君劇場みたいなノリでヲチしようや
- 180 名前：名前は開発中のものです。 mailto:sage [2009/04/08(水) 09:18:37 ID:0OsF5j6c]
- ワンダつまらんかったな。初日にクリアしてすぐ売った。
- 181 名前：名前は開発中のものです。 mailto:sage [2009/04/08(水) 10:02:02 ID:DTjWnb4t]
- じゃ、そろそろタスクシステムについて議論していこうか。
- 182 名前：名前は開発中のものです。 mailto:sage [2009/04/08(水) 11:29:12 ID:ZcZVPfWq]
- タスクシステムの主な役割
・単位時間内に1回何かを実行する為の窓口
・生存管理
・依存の管理
こんなものかな？
- 183 名前：名前は開発中のものです。 mailto:sage [2009/04/08(水) 12:10:26 ID:6q9I65fW]
- タスクシステムはそこにある、ただそれだけだ
- 184 名前：名前は開発中のものです。 [2009/04/08(水) 20:23:55 ID:uu59oW9Z]
- メリットやデメリットのあるタスクシステムなんてタスクシステムとは言えない
女子供は黙ってみてろ？
- 185 名前：名前は開発中のものです。 mailto:sage [2009/04/08(水) 23:24:44 ID:Ju8SopqO]
- その疑問符は何だ？
- 186 名前：名前は開発中のものです。 mailto:sage [2009/04/08(水) 23:41:33 ID:P81F6nRk]
- 語尾上げで、柳原可奈子的可愛さを演出してみたんじゃないか？
- 187 名前：名前は開発中のものです。 mailto:sage [2009/04/09(木) 00:22:04 ID:q+cTqKgL]
- むしろ姫ちゃん的な〜？
- 188 名前：名前は開発中のものです。 mailto:sage [2009/04/09(木) 01:27:01 ID:FGj8z8j8]
- そういう使い方にしても間違ってるような
- 189 名前：名前は開発中のものです。 mailto:sage [2009/04/09(木) 05:09:42 ID:0O2qwazX]
- 雑談ストップ？
- 190 名前：名前は開発中のものです。 mailto:sage [2009/04/09(木) 18:55:18 ID:/k3TfSjT]
- タスクってCしかできない人のための技法？
- 191 名前：名前は開発中のものです。 mailto:sage [2009/04/09(木) 19:04:45 ID:trH83J91]
- あまねく言語でタスクパターンは実装可能ですよ。
- 192 名前：名前は開発中のものです。 mailto:sage [2009/04/09(木) 20:14:35 ID:/k3TfSjT]
- 非常にサラッと内容をチラ見してきたけど、まあ特に議論するべきことでもないな
- 193 名前：名前は開発中のものです。 mailto:sage [2009/04/09(木) 22:57:42 ID:n4y/QroV]
- FlashのSTGで、EntityとかActorとか作ってやってるのを見たことがあるな。
- 194 名前：ID:EEKBitmg ◆HSP4mee/SU mailto:sage [2009/04/09(木) 23:40:00 ID:vLLC2UDG]
- バカにつける薬は無いと言われることもあるけれど厨房は今日も元気です
さて、そんな厨房でもタスクシステムとかいう怪しげなものに取り憑かれる
人々というのが、なーんか筋の悪そうな人が多そうだなーということに気付く
筋が悪いというのは、ガラが悪いという意味では区、頭が鈍いというかバカ
というか、一から十まで具体的に作り方を手解きしてもらわないとなーんにも
動かすことができないセンスの悪そうな人、という意味
こういう生意気書くとまたボコられるわけですが、この直感は当たってると思う
>>128
例えばこういうの。もう何言ってるのかサッパリ分からない。思考が腐臭を放ってる。
＞・単位時間内に1回何かを実行する為の窓口
なにそれ。役立たずの糞みたいな仕掛けをねじ込もうとしてるだけじゃん。
居るだけ詐欺の盲腸の無駄飯食らいの穀潰しのないほうがマシな無駄な機構を
何故かゲームプログラムの中に噛ませたがるタスクバカの香りを放ってる
＞・生存管理
なにそれ。something managerなの？生存管理？何してくれるの？
タスクディスパッチャーが何で生死を司るの？ゲームのシミュレーション結果で
決定されることを、なぜタスクディスパッチャーごときが口を挟むの？設計腐ってない？
余計なお節介をして茶々を入れてくる強烈にウザイものにしか見えない。吐き気がする
＞・依存の管理
なにそれ。またsomething manager？依存の管理？何してくれるの？
タスクディスパッチャーに把握させる依存関係って具体的に何？それをどうしてくれるの？
なんか臭そう。
- 195 名前：ID:EEKBitmg ◆HSP4mee/SU mailto:sage [2009/04/09(木) 23:43:36 ID:vLLC2UDG]
- >>193
EntityやらActorやらいう要素があるのはごく自然なことだよね
でも、このスレのタスクバカに言わせれば、それはタスクシステムらしいよ。
バッチイからあっち行けって思う
- 196 名前：名前は開発中のものです。 mailto:sage [2009/04/10(金) 00:22:24 ID:1GdYQJdO]
- なんで>>128が叩かれてるんだろうと思ったら>>182か
2chブラウザとか使ってないのかな
- 197 名前：名前は開発中のものです。 mailto:sage [2009/04/10(金) 00:25:41 ID:4YdM/w1Y]
- 関数インポがメインのタスクシステムを使わずにC++の仮想関数でやるのは速度不足か？
CPU４００MHZのPDA用に上記の方法で作ったことあるがとても快適に動作したがなあ。
携帯ならともかく今のハイスペックのマシンでタスクシステムいらんだろ
|
 |
