タスクシステム総合スレ part5

**名前は開発中のものです。** · 2009/02/19(木) 02:21:01

タスクシステムについての議論、相談、質問、雑談などのスレです

part4 http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/
part3 http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/
part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

・タスクと呼ばれる実装は、非常に多岐に渡ります
　古典タスクシステムについての話題は「>>2」と明示してください
　そうでない場合はカスタム版タスクであることを明示してください

・人を憎んで言語を憎まず

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

>>529
なるほど。全くコンシューマーを知らないけれど、説得力がある
では潤沢過ぎる程のメモリと、無限の演算能力がもしあったとしたら
喜んでタスクシステムは棄て去る？

**ID:EEKBitmg** · 2009/03/04(水) 03:04:13

ありえない仮定を持ち出すとかスゲェな
厨だけどさすがにこれは真似できないな

お前は凄い。俺は頭痛がしてきた。寝る

**名前は開発中のものです。** · 2009/03/04(水) 03:13:07

突込みがあったので補足。
>>530は、タスクシステムが貧困な環境で使えるという>>529に対して、
ならば、十分豊かな環境だったらそうではないのか？という質問。
無限～は *話を簡単にするため* の誇張した表現。

**名前は開発中のものです。** · 2009/03/04(水) 03:29:05

>>530
無限のメモリと無限の演算能力があったら…？
それでも小規模なアクションゲーム系１人で作るならタスク進化系の管理システム使うと思う。
タスク系は下手に使うとバグの温床になるけど使いどころを間違えなければ便利だし。

まぁこれは慣れの問題なので、この手のゲームならこの手法で…とかだいたいやり方の想像つくし
タスク系固有のバグで苦しんだ結果、バグの温床にならない作り方が出来るようになってるから、ってのもある。
慣れた人間にとっては開発効率いいんだよね、あれ。

まぁでも新人込みのプログラマ数十人で大規模オンラインゲームを作る、とかならたぶん違う方法取るけどね。

**名前は開発中のものです。** · 2009/03/04(水) 04:55:07

>>533
無限の資源があってもリスクと教育コスト考えれば結局C++使うだろうねー
無限の納期と無限の人材があるなら・・・遊んで暮らすだろうなー

**名前は開発中のものです。** · 2009/03/04(水) 05:47:21

タスクシステムってソースがタスクなわけで
プロセスがタスクじゃないのね

ではマルチプロセス対応というのは真っ赤な嘘になるわけだ

**名前は開発中のものです。** · 2009/03/04(水) 06:56:53

>>527
タスクシステムはsingletonじゃねぇぞ。

タスクのなかに別のタスクシステムをcompositionで配置してタスクを
階層化できるが、お前本当にOOPわかってんのか？

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

そんなの全く意味がないじゃん
だいたいそんなのやるならはじめから分けてもてよ

**名前は開発中のものです。** · 2009/03/04(水) 07:34:46

並列化はどう考えても嘘
並列にするなら少なくとも並列にするデータは分けないと動かない
ごった煮でできるわけない

**名前は開発中のものです。** · 2009/03/04(水) 08:44:10

>>529
メモリ使用量の大半を占めるのはテクスチャ・モデル・モーションなどのデータで、
CPU使用時間の大半を占めるのはヒット判定や AI 処理。

いわゆるゲームオブジェクト (プレイヤーとか) で多少削ったところで、誤差にもならない。

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

>>537
> そんなの全く意味がないじゃん

そんなこたあ、ない。

**名前は開発中のものです。** · 2009/03/04(水) 08:49:26

数人で作るレベルなら擬似タスクでいいよ。
でもそれを超えると破綻すると思う。

**名前は開発中のものです。** · 2009/03/04(水) 08:49:27

>>538
阿呆すぎて泣ける。

前スレ510のプログラム、あれ並列化できないの？

本当に1行でもプログラム書けるの？

タスクシステム使わなくていいから、前スレ510のプログラム、並列化してみなよ。

**名前は開発中のものです。** · 2009/03/04(水) 08:51:55

>>508
彼を養護してるアンチはいないようだが
そこまでして印象操作したいの？

**名前は開発中のものです。** · 2009/03/04(水) 08:52:16

>>526
> それなら、最初からふつーにメンバ変数で持たせて終わりじゃない？

そのメンバ変数が指しているオブジェクトが生きていることを誰がどうやって保証するんだ？

**名前は開発中のものです。** · 2009/03/04(水) 08:54:00

>>543
このスレのアンチタスカーのレベルが総じて低すぎる。

タスクシステムに限らずフレームワークなんて、使える範囲で使えばいいだけのことなのに
完全否定する奴は完全肯定する奴と同罪で、頭おかしい。

**名前は開発中のものです。** · 2009/03/04(水) 08:55:29

>>542
> 前スレ510のプログラム、あれ並列化できないの？
そもそも、あれは名前がタスクなだけで、>>2 と設計全然違うけど。

いずれにせよ、データに依存性があり並列化はできない。

> m_vx = m_vx*m_m/(m_m+Star2.m_m) + Star2.m_vx*Star2.m_m/(m_m+Star2.m_m);
> m_vy = m_vy*m_m/(m_m+Star2.m_m) + Star2.m_vy*Star2.m_m/(m_m+Star2.m_m);

たとえばこのコード、複数の Star インスタンスの m_vx, m_vy を同時に読み書きしている。
複数スレッドで走らせた場合、値が保障できなくなる。

**名前は開発中のものです。** · 2009/03/04(水) 08:57:09

>>545
> 完全否定する奴は完全肯定する奴と同罪で、頭おかしい。
つ鏡

**名前は開発中のものです。** · 2009/03/04(水) 09:08:31

>>544
526のコードは、ポインタではなく実体で持たせているから、保障も何も要らんと思うが。
いずれにせよハンドルクラス (整数値とインスタンスの対応付け) は用意したほうが
便利だが、その場合でもプレイヤー・敵は別の ID 体系にしておくな。

たとえば、最大 2 プレイヤー同時プレイ可能なゲームで、プレイヤーに向かって
進む敵を作りたい場合。

class PlayerID { int id_; friend class Scene; }; class EnemyID { int id_; friend class Scene; };
class EnemyEnv {
　virtual ~EnemyEnv() {};
　virtual PLAYER_ID GetNearestPlayer(ENEMY_ID enemy_id) const = 0;
　virtual Vec3 GetPlayerPos(PLAYER_ID player_id) const = 0;
};

class Scene : public EnemyEnv {
　Player player_[2];
　std:::list<Enemy> enemies_;
public:
　void Update() { player_.Update(*this); enemy_.Update(*this); }
　virtual PLAYER_ID GetNearestPlayer() const { ... }
　virtual bool GetPlayerPos(PLAYER_ID player_id, Vec3* pos) const {
　　// 実際には、ここで player_id.id の値チェックを行い、生存していなかったら false 返す
　　*pos = player_[player_id.id_].GetPos(); return false;
　}
}

void Enemy::Update(EnemyEnv& env) {
　PLAYER_ID player_id = env.GetNearestPlayer(this.GetID());
　Vec3 pos = env.GetPlayerPos(player_id);
　// あとは pos に向かって自分の位置を調整
}

**名前は開発中のものです。** · 2009/03/04(水) 09:09:02

>>546
> たとえばこのコード、複数の Star インスタンスの m_vx, m_vy を同時に読み書きしている。

その言い方は不正確だし、並列化の本質をわかっていない。

そのコード、そもそも元コードがすこしおかしいのだが、タスクシステムを使おうと使うまいと
Starオブジェクトの集合から任意の2体を取り出して、その振る舞いを書きたいとする。

foreach(var star1 , star2 in stars)
{
　　star1.m_vx = star1.m_vx*star1.m_m/(star1.m_m+Star2.m_m) + Star2.m_vx*Star2.m_m/(star1.m_m+Star2.m_m);
　　star1.m_vy = star1.m_vy*star1.m_m/(star1.m_m+Star2.m_m) + Star2.m_vy*Star2.m_m/(star1.m_m+Star2.m_m); }
　}

これは、次のようにかきかえる。

foreach(var star1 , star2 in stars)
{
　　star1.m_vx_new = star1.m_vx*star1.m_m/(star1.m_m+Star2.m_m) + Star2.m_vx*Star2.m_m/(star1.m_m+Star2.m_m);
　　star1.m_vy_new = star1.m_vy*star1.m_m/(star1.m_m+Star2.m_m) + Star2.m_vy*Star2.m_m/(star1.m_m+Star2.m_m);
　}
foreach(var star in stars)
{
　　star1.m_vx = star1.m_vx_new;
　　star1.m_vy = star1.m_vx_new;
}

これは、コリジョン判定とそれに対するアクションを切り離すときもそう。
これをきちんと切り離しておかないと並列化できない。

前スレでコリジョン判定は並列化できないとか言ってた馬鹿がいたけど、アクションを切り離さないから出来ない。

**名前は開発中のものです。** · 2009/03/04(水) 09:11:17

>>549
その指摘は正しいが、前スレ 510 を使うかどうかとまったく無関係だよね。
タスクとやらを使ったから並列化できるようになるわけじゃないし、並列化が
楽になるわけでさえない。

けっきょく、同じ労力を咲く必要がある。

**名前は開発中のものです。** · 2009/03/04(水) 09:11:22

>>548
> いずれにせよハンドルクラス (整数値とインスタンスの対応付け) は用意したほうが

そんなものあえて作る意味があるか？boost::weak_ptrで済むだろ。

そもそも、548のソースは典型的なタスクシステムで記述するよりはるかに複雑なんだが、
あんたは、タスクシステムの否定派なのか肯定派なのか何なんだ？

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

>>550
> タスクとやらを使ったから並列化できるようになるわけじゃないし、並列化が
> 楽になるわけでさえない。

それは違うね。タスクシステムの側に並列化する部分を担当してもらう。
タスクシステムを使う側は、それを利用すればいいだけ。

タスクシステムは底辺の馬鹿プログラマが書かなくとも、別の、もっと優秀なプログラマが書けばいい。

並列化効率とか、メモリcacheとか、シェーダーに対するタスクの分配とか、そういうのを考慮して効率の
いい並列化プログラムを書ける奴がな。

こうして、はじめてゲームの分業が成立するんだが。
あんたはちょっとはまともなプログラマに見えるが、大規模なゲーム開発に取り組んだことはないのか？

**名前は開発中のものです。** · 2009/03/04(水) 09:17:40

>こうして、はじめてゲームの分業が成立するんだが。

脱字。「ゲーム開発における分業」の間違い。

いま読み返したら549は
>foreach(var star in stars)
>{
>　　star1.m_vx = star1.m_vx_new;
>　　star1.m_vy = star1.m_vx_new;
>}

ここ、左辺はstar1ではなくstarだ。ごめん。

**名前は開発中のものです。** · 2009/03/04(水) 09:24:16

>>551
> そもそも、548のソースは典型的なタスクシステムで記述するよりはるかに複雑なんだが、
以前から同じようなコード例書いてるんだけどな。前スレ 748 とか。

・コンポジションで良いじゃん
・規模が大きいプログラムだと、どのタイミングで何が呼ばれるか、変更されるかが
　分かることが重要。
　この例だと Enemy::Update 時には EnemyEnv 経由で Scene のメンバ関数が呼ばれる
　だけと確定する。Enemy::Draw みたいな処理があったときに、EnemyEnv const& 使うか
　別のクラスを用意するかは要検討（場合による）。

> そんなものあえて作る意味があるか？boost::weak_ptrで済むだろ。
スクリプトと連携するときに楽
boost::shared_ptr 使ってるとは限らない

別に weak_ptr 使える場合には、使えば良いと思うけど。

**名前は開発中のものです。** · 2009/03/04(水) 09:25:22

>>552
> タスクシステムの側に並列化する部分を担当してもらう。
名前がタスクシステムなだけで、前スレ 510 とも >>2 ともまったく違う設計・実装について
語ってるということで FA？

**名前は開発中のものです。** · 2009/03/04(水) 09:26:54

結局、並列化の本質は>>549なんだ。もう少し抽象化して書けば、こう。

foreach(var star1 , star2 in stars)
{
star1の新しく情報を書き込む領域 ← star1とstar2相互計算によって得る。
}
foreach(var star in stars)
{
starの新しく情報を書き込んだ領域をcommitする。
}

で、これをタスクシステム側に並列化する部分を受け持ってもらう。
例えば>>546であれば、次のように書けば上のプログラム(>>549)と等価になる構文を用意する。

foreach_parallel (var star1 , star2 in stars)
{
　　star1.m_vx = star1.m_vx*star1.m_m/(star1.m_m+Star2.m_m) + Star2.m_vx*Star2.m_m/(star1.m_m+Star2.m_m);
　　star1.m_vy = star1.m_vy*star1.m_m/(star1.m_m+Star2.m_m) + Star2.m_vy*Star2.m_m/(star1.m_m+Star2.m_m);
}

このとき、左辺は、shadow(m_vx_new , m_vy_new ) に対してアクセスしていて、実際はforeachを抜けてから

foreach(var star in stars)
{
　　star.m_vx = star1.m_vx_new;
　　star.m_vy = star1.m_vx_new;
}

これが実行される。この仕組みをタスクシステム側に提供してもらう。これなら簡単に並列化できる。
ゲームで使うコリジョン判定などはたいていこのように並列化できる。

**名前は開発中のものです。** · 2009/03/04(水) 09:31:11

>>555
> 名前がタスクシステムなだけで、前スレ 510 とも >>2 ともまったく違う設計・実装について
> 語ってるということで FA？

並列化とタスクシステムとは直交する概念だから、例えば>>2のタスクシステムを並列化することも出来るし
前スレ510のタスクシステムを並列化することも出来る。

どちらかと言えば、前スレ510のほうが>>2よりはある型のオブジェクト集合のうち任意の2体に対する
振る舞いが書けるのでその部分が並列化する価値が高いだけのこと。

そもそも、タスクに対して列挙したり、任意の型の2体を取り出したりする仕組みがどこにもない状態で
並列化なんて出来ないだろう。

俺がタスクシステムと呼んでいるのは、最低限、タスクシステムと名がつくなら、タスクに対する基底
クラスが存在して、それくらいの機能はあるんじゃねーの？と思うからだ。

**名前は開発中のものです。** · 2009/03/04(水) 09:32:48

>>554
>> そんなものあえて作る意味があるか？boost::weak_ptrで済むだろ。
>スクリプトと連携するときに楽

ふむ、それならok。

**510** · 2009/03/04(水) 11:11:12

>>556
shadowのアイデアもーらい。

transaction( hoge )//shadow初期化
{
　　task2_parallel( hoge, hoge )
　　{
　　　　_hoge1.x += hoge2.x;//例えば、変数の頭にアンダーバーがついていたらshadowとか。
　　　　//rollback;//ロールバックも出来るよ
　　}
　　task_parallel_end;
}
commit;//shadowコミット

あと、何か頭が統合ヘッダ？の人が来てたみたいだけど、
アップロードしたプログラムのヘッダファイルがごった煮だったのは
単にサンプルプログラムだったからだ。

**510** · 2009/03/04(水) 11:23:44

shadowは書き込みさきより参照元の方が良いな。

**名前は開発中のものです。** · 2009/03/04(水) 11:43:23

>>557
＞俺がタスクシステムと呼んでいるのは、最低限、タスクシステムと名がつくなら、タスクに対する基底
＞クラスが存在して、それくらいの機能はあるんじゃねーの？と思うからだ。

あー、やはりな。以下の内容は煽り抜きだから気を悪くしないでくれ

結局これはローカル用語の解釈を巡る相違でしかない
例えばウチの社内ではあんたの解釈を振りかざしても
意思疎通はうまくいかないだろう

ここでは色んな名無しが俺定義・俺解釈のローカル用語を
公衆の場に持ち出して一人相撲してる。あんたもそう

タスクシステムは権威不在の定義不明瞭なローカル用語だ
ということをまず再確認し、意思疎通を円滑にするために
それぞれがより確かな一般的な計算機用語に換言する努力を
すべきだ。でなければ、この実に不毛なすれ違いは無くならない

**510** · 2009/03/04(水) 11:50:03

俺はソースコードアップしてその上で、これが俺のタスクシステムだって言ってるんだから良いんだよな。
皆各々ソースコードアップすればよいと思うよ。

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

>>562
君のコードにはもっと相応しい個性的でカッコイイ名前を付けてあげなさい
手垢で汚れたタスクシステムなんて臭い名前では>>2と勘違いされてしまう
君のコードは泣いているぞ。不敏でならない

エターナル自動並列ブリザードデータベースでもなんでもいい
革新的であることを世の馬鹿共に知らしめる努力をすべきだ

**並列さん** ◆dPfetnROQg · 2009/03/04(水) 15:46:36

>>559
なかなかいいね。

俺、そろそろコテハンにしとくわ。
ちなみに前スレ510に対して、C++としては素人の書き方だと指摘したのは俺な。

原則煽り専門だから、よろしく。

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

で？
ごった煮でどうやってヒット判定の並列化をするって？
値を後で更新すると折角優先順位をつけても古い値でヒット判定をすることになるからおすすめできない
並列化を狙うならオクツリーにして位置で切らないと多分無理

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

演算器いっぱいのベクトルプロセッサにやらせる場合
移動フェーズと衝突検出フェーズと衝突応答フェーズに
分割してそれぞれのフェーズでいっせーのーせでやる

物理エンジンなんかもそう

もちろん空間領域分割もする

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

駄目
衝突は即座に補正かけないとそれだけでバグる
移動して衝突判定をすぐにしないと壁の向こうの敵と接触することになるぞ
しかし壁の当たりの優先順位はおそらく最後だろ？
でないと抜けるしね
しかしそうすると壁の向こうの敵と接触する
この辺をタスク縛りにするのは正直うまくない
やるならなにはなくともオクツリー

**名前は開発中のものです。** · 2009/03/04(水) 19:02:10

なんで衝突判定中に衝突以外の判定を入れるの？馬鹿なの？

**名前は開発中のものです。** · 2009/03/04(水) 19:02:19

それでバグらないようにする手法も研究されてるだろうね
考えるならなにはなくともまずはサーベイ

**名前は開発中のものです。** · 2009/03/04(水) 19:04:26

並列化とタスクと絡めて話してるのは極一部で
しかもタスクを使えば並列化できると主張してる人はいない。
今の話は並列化に対応したタスクがもし作れるとするなら
どんなものになるかという感じ。並列化に関する部分は一般論をしてる。

つか並列化はそろそろ別スレ立てた方がいいんじゃね。
並列化が目的でタスクは手段に過ぎないんでしょ。

**名前は開発中のものです。** · 2009/03/04(水) 19:08:59

>>567
上のは（Id Software系のエンジンでいうところの）エンティティ対エンティティ
のみに絞った話。相互作用。
壁抜けや床抜けに対するケア、これはブラシとの衝突（相互ではなく一方的作用）は
当然これは即座に補正される

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

>>571
即座に、ではなく、衝突検出フェーズにおいて、ブラシとの作用が先に反映される
だな

**並列さん** ◆dPfetnROQg · 2009/03/04(水) 19:25:13

>>567
> 衝突は即座に補正かけないとそれだけでバグる

俺物理エンジン書いたことあるが、そんなこたぁない。

どうせお前のプログラム、移動させて同時に衝突判定してぶつかってたら逆方向に移動とか
阿呆なことやってんだろ。本当、このスレは底辺プログラマ集まってんのな。

**名前は開発中のものです。** · 2009/03/04(水) 19:26:40

>>572
ついでに、高速移動体に対するケアの話もここでは割愛している

あと、俺は強烈なアンチだ

**並列さん** ◆dPfetnROQg · 2009/03/04(水) 19:30:44

ああ、ID:4u8TV8ZGは底辺プログラマではないな。俺的に除外しとく。

しかし、ID:NGMxgsfOは、底辺以下だな。俺的には、ゴミ扱い。

タスクシステムを使うと総合ヘッダが必要になるとか言ってる基地外と一緒。
ああ、ID:NGMxgsfOがその基地外なのか？

**並列さん** ◆dPfetnROQg · 2009/03/04(水) 19:33:21

>>574
あんたは、強烈なアンチなのか。それは意外だ。

俺はじゃあ、強烈なタスク信者ってことでヨロシク！

まあ、あんたとは仲良くできそうだけどな。

**名前は開発中のものです。** · 2009/03/04(水) 19:44:25

>>576
俺とあんたとの間に争点があるとすれば、それはタスクシステムという呼称だろうな
俺はあのローカル用語から発せられる腐敗臭が大嫌いなんだ

**名前は開発中のものです。** · 2009/03/04(水) 19:50:16

タスク（自分の信じる、おそらく誰とも同じものを指していない）信者
と
強烈なアンチ（なにに対してなのか自分でも解っていない）
か。

**並列さん** ◆dPfetnROQg · 2009/03/04(水) 20:28:42

>>577
ああ、それは同感。

まあ、俺のなかでは、タスクシステムは少なくともstd::listよりは少しはマシなことが
出来るように工夫してあんだろ、みたいな思い込みはある。

std::list以下のものなら、タスクシステムなんて大層な名前つけなくても黙って
std::list使っときゃいいわけで。

**名前は開発中のものです。** · 2009/03/04(水) 23:21:38

>>549
結局パフォーマンス向上しないだろコレ

**名前は開発中のものです。** · 2009/03/04(水) 23:55:44

全くしない(笑)
何を並列化したのかさっぱりわからん
あたりでやるとしたら全く関わることのない範囲を同時に・・・
ぐらいしかないけどな
こんなパラ単位で並列化なんて意味ねーよ

**名前は開発中のものです。** · 2009/03/05(木) 00:22:53

>>580
foreach の部分を OpenMP とかで並列処理できれば、まぁ多少は。

しかし、そもそも並列化するならゲームロジックが絡むところより、モーション計算
とかエフェクト（特にパーティクル）だろう。ゲームロジックは依存関係がキツいし、
仕様変更が頻繁に起こりうるからリスク大きすぎる。

もっとも PS2 のときから、技術力があるところは VU1 に持っていってたけどな。

**名前は開発中のものです。** · 2009/03/05(木) 01:46:15

ああくそ！
ID:NIkO1+LI祭に乗り遅れた！
書き込み規制が憎い

**並列さん** ◆dPfetnROQg · 2009/03/05(木) 07:31:17

>>580
するよ。

>>581
阿呆すぎて泣ける。どこの阿呆かと思ったら、
「衝突は即座に補正かけないとそれだけでバグる」とか言ってた阿呆か。
全然話にならんわ。

まともな物理エンジンのソース見たことないんだろうな。

**名前は開発中のものです。** · 2009/03/05(木) 07:49:58

でも実際動いたら補正かけないと壁の向こうの敵に当たる
間に壁がないかみて判定しなきゃならんときもある
この辺をタスク縛りにされるのは正直やりにくいにも程がある
ゲームやオブジェクトによってすり抜けがどうでもいいものもあるだけに一般化はできない
リングアウトだけ起こらないでは済まない場合は結構多い
べつに速度がとんでもない場合じゃなくても問題は起こる

**並列さん** ◆dPfetnROQg · 2009/03/05(木) 08:24:43

>>585
あんたは、ID:NGMxgsfOか？

それとも、ID:NGMxgsfO級の阿呆が何人もいるのか？
いい加減、コテハンにしてくれ。

まともな幾何的なconstraint solverを書いたことすらない奴が物理エンジンを語るなよ。

**名前は開発中のものです。** · 2009/03/05(木) 09:31:58

>>586
ここで物理エンジン語るのも、どうかと思うが。

**名前は開発中のものです。** · 2009/03/05(木) 09:41:46

>>586
何故 >>585 の問題が起こらないのか教えて欲しい

**名前は開発中のものです。** · 2009/03/05(木) 09:52:09

>>585,588
タスク以外でも585の問題をどうやって解決しているのか知りたい。
結局両方の例が無いと比較できないし評価を下すこともできない。

**名前は開発中のものです。** · 2009/03/05(木) 10:27:56

壁との当り判定&補正処理をした後で
敵との当り判定を取れば良いだろ。

**並列さん** ◆dPfetnROQg · 2009/03/05(木) 10:33:57

>>588-589
何度でも言うが阿呆共はコテハンつれてくれ。

>>590
そんなことをするとコリジョン判定を並列化できない。

**名前は開発中のものです。** · 2009/03/05(木) 10:56:14

壁との当り判定&補正処理と、敵との当り判定を、それぞれ別々に並列化すればよいだろ。

parallel { 壁との当り判定&補正処理 }
parallel { 敵との当り判定 }

**名前は開発中のものです。** · 2009/03/05(木) 11:00:40

さすがに優先度の在る処理を並列化する馬鹿は居ないだろ。

**並列さん** ◆dPfetnROQg · 2009/03/05(木) 11:53:25

>>592
素人すぎて話にならん。なんだよ、壁と敵って。動くか動かないかでわけてんの？馬鹿じゃねーの。

**名前は開発中のものです。** · 2009/03/05(木) 13:24:53

動くか動かないとか、誰も言ってないのに。
壁＝動かない、敵＝動く、という固定観念でもおあり？

>>592　は、
あらかじめ、物理的に問題の無い状態に落ち着けてから、
あらためて、ゲーム進行上ひつような当り判定を行う。
ということ。

**名前は開発中のものです。** · 2009/03/05(木) 13:26:57

並列さんも結局あてにならないんだよなぁ・・・

**並列さん** ◆dPfetnROQg · 2009/03/05(木) 13:50:52

>>595
> 壁＝動かない、敵＝動く、という固定観念でもおあり？

この議論の大元となっているのは、>>155で、そこには

> 衝突解決には、たとえば「壁は動かない」「プレイヤーが壁に当たったら押し戻される」

と書いてあるから俺はその定義に従っただけなのだが。

この流れで、オレオレ定義の「壁」とか「敵」を持ち出すなら、言葉の定義ぐらい先に書いて欲しいんだが。

**名前は開発中のものです。** · 2009/03/05(木) 14:02:23

あてになるかどうかというより基本的な部分で意志の疎通ができてないんじゃ。
共通認識を積み上げる作業をさぼったらコミュニケーション取れんよ。

そんな面倒なことは省略して結果を気にせずに出会い頭の辻切り対辻切り
みたいなやりとりを日常的にしてるのが2chでもあるけど。

**名前は開発中のものです。** · 2009/03/05(木) 14:03:36

どんだけ悔しかったのか知らないが、12日も前のレス持ち出して弁解ですか。
>>592の壁とか敵はオレオレ定義ではなく、>>585で出現しているそれ。
7つ上のレスも見れない池沼さんですか？
で、揚げ足取りは結構なんだけど、本文への反論は？

**並列さん** ◆dPfetnROQg · 2009/03/05(木) 14:18:31

>>599
> >>592の壁とか敵はオレオレ定義ではなく、>>585で出現しているそれ。

>>585に定義らしきことは書いてないじゃん。

> で、揚げ足取りは結構なんだけど、本文への反論は？

「壁」と「敵」についてきちんと定義を書いてくれ。話はそれからだ。

**名前は開発中のものです。** · 2009/03/05(木) 14:45:45

>>600
こいつは何を並列処理しようとしてるの？

**名前は開発中のものです。** · 2009/03/05(木) 14:56:23

(あ、また、
自分は7レス前の今朝の関係のあるレスも見れないのに、
他人には439レス前の12日前の無関係なレスを覚えていることを要求する並列さんが何か言ってるな)

>>600
ちょっともう、どうしたらよいの？国語やりなおせとしか言いようが無いのだが。。
>>585をよめば、
・壁とは、敵との当りを防ぐもの。
・敵とは、当たりをとる対象。
ということぐらい普通分かるだろ。
同時に、>>155が今件になんら関係ないことも分かるだろ。
結論から言うと、お前が一人で勘違いして勝手に煽ったりファビョったり一人相撲してただけだ。

**名前は開発中のものです。** · 2009/03/05(木) 15:05:28

文章が読めない奴ばかりだから、もう一度書き込むぞ。
>>585は、
衝突解決の途中でゲーム進行用の当たり判定を取ると、
ゲーム進行用の当たり判定がバグる、
と主張し、
それに対して俺は、
衝突解決が完了してからゲーム進行用の当たり判定を取ればよい、
と主張をしている。
予め言っておくが、衝突解決の優先順位の問題とは全く別の話。

**並列さん** ◆dPfetnROQg · 2009/03/05(木) 15:17:15

>>602
> ・壁とは、敵との当りを防ぐもの。
> ・敵とは、当たりをとる対象。
> ということぐらい普通分かるだろ。

それはわかるが、敵同士は重なっている状態が許容されるかどうかが>>585からはわからない。

もし許容されないなら、敵とか壁とか分けて考える必要はなく、どちらも対等な単なるオブジェクトだから
用語をわざわざ分ける必要がない。

それを >>592 のように処理を分けているというのは、あんたが勝手に敵同士の交差は許容されると
>>585 から解釈したとしか思えない。要するに>>585を拡大解釈しているのはあんただろ。

**並列さん** ◆dPfetnROQg · 2009/03/05(木) 15:20:29

>>603
> 衝突解決が完了してからゲーム進行用の当たり判定を取ればよい、

「ゲーム進行用の当たり判定」なんて、誰も話題にしてなくて
幾何的に重なりをもつ状態をいかに防ぎつつ処理を並列化するかしか
問題にしてないと思うんだが。

あんたは日本語が不自由以前に頭が不自由みたいなんで、
俺はあんたの相手はしないことにする。

**名前は開発中のものです。** · 2009/03/05(木) 15:41:13

まとめ
ID:2NL1rK1f　が正しい。
ID:rvhMBE/z　は間違っている。

なぜならここはタスクシステム(^^;)スレだから。
今は並列処理（笑）をどこまでシステムを組み込めるか議論する場なので、（たとえば整数のみで実数計算するにはどうするのが一番いいかのような）
ID:rvhMBE/zのように並列処理（笑）を使わない最も効率的で扱いやすい無駄の無い設計はスレ違い。
みんなそれが最善手段と知ってる上で議論している。
（まぁ>>604の敵同士の交差がどうこうというのは並列処理（笑）時の話であって交差しようがしまいが別に処理させているID:rvhMBE/zの設計に対するツッコミ（ボケ？）は意味不明だが）

**名前は開発中のものです。** · 2009/03/05(木) 15:51:13

本当に文章が読めないんだな。どうしようもない。
>>585にはプレイヤーという主語が抜けてるんだよ。
それぐらい行間読めよな。

だから、

>敵同士は重なっている状態が許容されるかどうか

は関係ない。

さかのぼってみれば、>>567が発端で、これは、

>演算器いっぱいのベクトルプロセッサにやらせる場合
>移動フェーズと衝突検出フェーズと衝突応答フェーズに
>分割してそれぞれのフェーズでいっせーのーせでやる

に対してレスされている。
内容は、それぞれのフェーズの呼び出し順が固定だから、
衝突検出フェーズ内で拾う値は必ず補正前の値になってしまうので、
壁の向こうの敵に接触してしまうなどの不具合が出る、というもの。
つまり、古典的タスクシステム固有の問題で、実は並列化は関係がない。

**名前は開発中のものです。** · 2009/03/05(木) 16:09:30

速度がでてないのに壁の向こうの敵にあたるって
壁薄くね？

**並列さん** ◆dPfetnROQg · 2009/03/05(木) 16:37:36

>>608
実際は、紙みたいな壁も存在して、単なる衝突判定でやってしまうと
次フレームでは通り抜けてることもある。

だから、まともな物理エンジンでは、そういうオブジェクトに対しては、
連続体として扱うようになっているのだが、この取り扱いは結構難しい。

これに関しては最近、いろいろ論文が発表されるなど、比較的hotなテーマだ。

**名前は開発中のものです。** · 2009/03/05(木) 18:58:37

君らってRogue Spear 知らないの？
http://www.youtube.com/watch?v=A7xiK-snyJk
そんな古臭い話が最近の論文なんて信じられないが

論文あるならソースだしてくれよ
多分読めないが

話変わって >>2 のタスクシステムのソースって
慣れてないと難しいね
拡張も慣れが必要
ちょっと自分流の方が早い気がしてきた

**ID:EEKBitmg** · 2009/03/05(木) 19:12:57

このスレは直列番長の>>2をボコるスレだろ

**ID:EEKBitmg** · 2009/03/05(木) 19:50:12

>>607
＞つまり、古典的タスクシステム固有の問題で

なんでそうなるんだよ

**ID:EEKBitmg** · 2009/03/05(木) 20:33:20

>>567はcontinuous collision detectionの話がしたいのか？

壁とか言ってるから違うだろ。隣部屋同士の誤判定の話くさいんだけど
空間分割された隣部屋同士なら『ドア（窓）を経由しない限り当たらない』
ドア（窓）を経由して侵入してくる疑いがある奴は移動フェーズの時点で
バレてんだから、移動フェーズが終わった時点で同期的処理かませれば
いいだけだろ。バカくせ

**ID:EEKBitmg** · 2009/03/05(木) 20:40:46

ドア（窓）を経由しないでポータルの外を飛び出るかもとか
そんなクズシステムの話を持ち出す時点で駄目だ

タスクバカ＝>>2信者＝直列バカはやっぱりバカだ

**名前は開発中のものです。** · 2009/03/05(木) 20:52:25

銃弾は壁も突き抜けるぜ！

**ID:EEKBitmg** · 2009/03/05(木) 20:54:34

そうか。>>567は銃弾の話をしてるのか。そうなのか？
そういや壁抜きでぶっ殺したら升使ってるとか言われたな
これだからnoobは困る

**名前は開発中のものです。** · 2009/03/05(木) 21:49:16

>>616
そういうツールありますから
あなたの方がnoobですよ

**ID:EEKBitmg** · 2009/03/05(木) 21:51:32

あー、わかったぞ
並列君は銃弾も人も同じエンティティとして平等に扱うのか
マジで狂ってるな。どんだけ無駄なことすりゃ気が済むんだよ

**名前は開発中のものです。** · 2009/03/05(木) 21:54:16

>>618
だから効率を求めてるんじゃなくて、並列でどうやって対処するか議論してるんだってば

**ID:EEKBitmg** · 2009/03/05(木) 21:57:28

>>619
は？誰だよお前。名無しに用はねーんだよ
効率を度外視した糞システムなんてみんな糞だ
お前らタスクバカはそうやって何でもツクールを目指すバカだから
並列処理も効率度外視とかウンコくさい話をしたがるんだろ

バカは氏ね。思想レベルで詰んでる

**名前は開発中のものです。** · 2009/03/05(木) 22:03:48

≡≡≡≡≡≡.　　　
日　▽　Ⅱ　日　　　／￣￣￣￣￣￣￣￣￣￣￣￣
≡≡≡≡≡≡　　　｜　IDさん今日は荒れてるなあ。
Ⅲ　∩　［］　　　｡〇＼＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿ ∧∧ﾟ＿＿＿＿＿＿
　　　 □ ( 　　 )
―――― | 　ヽ――――――
　　　　　　(＿___）～
━┳━ 　 ━┳━ 　 ━┳━
￣┻ ￣￣￣┻￣￣￣ ┻￣￣

**ID:EEKBitmg** · 2009/03/05(木) 22:07:27

>>2が時代錯誤的な直列処理してっからブッ叩かれ、それを気にして
カッとなって、今度は極度に逆方向にふれて究極の並列コードを
目指すし始めた一部の先進次世代タスクバカ。>>510が代表だな

お前らタスクバカはさ、いい加減『ナニを作るのか』具体的に書けよ
何でもツクール目指すから『ナニを作るのか』書けません、だとか
ミラクルドリーマーみたいな事をほざくなよ

**ID:EEKBitmg** · 2009/03/05(木) 22:19:07

>>621
俺、一応未成年だからお酒でそういう大人っぽいお店にいって
酩酊してウサ晴らすとかそういうことできないんだよね

これは芸風だから。昨日の並列君のお前らみんなバカ宣言
に対する報復である

**ID:EEKBitmg** · 2009/03/05(木) 22:20:46

×お酒でそういう大人っぽいお店にいって酩酊して
○そういう大人っぽいお店にいってお酒で酩酊して

**561** · 2009/03/06(金) 00:00:33

惚れた

**名前は開発中のものです。** · 2009/03/06(金) 07:47:43

>>622
そんなの無理だろ
タスク信者は動いてるプログラムにタスクウィルスを入れて
自分しかメンテできないようにして、自分の居場所を確保する
犬の小便的行動が本来の目的なんだから

**ID:EEKBitmg** · 2009/03/06(金) 10:06:54

いやー、昨日も面白い池沼がいて楽しかったわ
これだからこのスレはやめられないｗ

**名前は開発中のものです。** · 2009/03/06(金) 13:01:17

銃弾の事は外野の俺がネタで言ってみただけだお…＞＜

**名前は開発中のものです。** · 2009/03/06(金) 14:33:08

>>625
>427

>>626
そのくらいで地位を守れるなら失うよりはずっとマシだと真剣に思う、この不況。無職を叩く側から叩かれる側になるなんてやだもん。