タスクシステム総合スレ 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(水) 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
そのくらいで地位を守れるなら失うよりはずっとマシだと真剣に思う、この不況。無職を叩く側から叩かれる側になるなんてやだもん。

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

ついにタスク信者自身が自分がクソを入れてることを認めたか

**並列さん** ◆dPfetnROQg · 2009/03/06(金) 18:18:57

なんじゃそりゃ

**名前は開発中のものです。** · 2009/03/06(金) 19:15:57

>>622
タスクシステムが直列処理だとは思わんが。
どっちかっていうと、並列かと。

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/06(金) 23:46:34

>>627
ちょっとー。何なのおまえ誰なのおまえそこへ直れよおまえ！このイジメっ子ザザ虫！
平日の朝っぱら１０時から暇そうに２ちゃんで厨のIDコテ使って何ふんぞり返ってるの？
イイ歳した大人が虎の威ならぬ厨の威を借りて一段高くなれるの？低くならないの？恥ずかしくない？

お前、今まで俺のことをHSPしか使えない基地外とか繰り返し叫んでたウンコ君でしょ？
気になるあの子が振り向いてくれないからって、あの子の目の前であの子の名札つきの
体操服を着てあの子のピアニカをチュアパチュパしゃぶりながらあの子のリコーダーに
ポークビッツを差し込んで教室で待ち構えて本人登場したらポークビッツが健気に膨張
圧迫されて抜けなくなって保健室に運ばれちゃう変態、超ド変態の子供時代を繰り返すの？

タスクバカのことをバカバカエンガチョって指差してきたけど流石にトリップ無しIDコテ厨を
騙るほど堕ちちゃいないだろうと信用してたのに買いかぶりだったみたい。もう大嫌い

**並列さん** ◆dPfetnROQg · 2009/03/06(金) 23:55:00

>>633

>627は偽物だったのか・・。まあ、もとより俺には、本物が誰なのかよくわからないのだが。

>633を見る限り、なんか内容は支離滅裂だが、それでもあんたの日本語は他の奴よりは
断然読みやすいのでまだ許せる。

日本語の不自由な奴は、ゲームなんか作ってる場合じゃなくて、
もっと先に勉強すべきことがあるだろ、とか思うんだけどな。

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/06(金) 23:56:33

>>632
正確には並行処理じゃないの？

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/06(金) 23:59:28

寮に帰って2ちゃん見てワナワナプルプルしながら顔真っ赤に怒ってるから
支離滅裂なんだ！ちなみに昨日の書き込みには大変な矛盾があるので
訂正したかったが、>>627は俺らしいから彼にやらせてみようと思う

**名前は開発中のものです。** · 2009/03/07(土) 00:46:01

>>635
優先順位がつくばあいもあるから正確には並列とは言えないだろうな。

**並列さん** ◆dPfetnROQg · 2009/03/07(土) 00:55:26

>>637
その理屈はおかしい。
マルチスレッドのプログラミングでもセマフォで他のスレッド待ったり普通にするじゃん。

処理に順序があろうが無かろうが、並列なものは並列だ。

>>635が並行と言ってるのは、タスクを実行しているスレッド(プロセス)が通例、
1つだけだという理由からだろう。

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

>処理に順序があろうが無かろうが、並列なものは並列だ。

並列さんの言ってることは意味が分からん。
処理に順序があれば、同時に実行できないのだから、並列でないだろ。
マルチスレッド≠並列。

煽り専門と名のってたが、嘘ばかりを書き込んでスレの機能を麻痺させる気？
名前変えたら？

**並列さん** ◆dPfetnROQg · 2009/03/07(土) 01:17:59

>>639
> マルチスレッド≠並列

言葉の定義の問題だから、まあどうでもいいが、まあ普通は
マルチスレッドで実行されている以上、並列だし、あるスレッドが他のスレッドを
待っていてスループットが悪かろうが、並列なものは並列。

処理順序が厳密に定められていて、まったく逐次実行しか出来ないなら、
シングルスレッドと同じか、それ以下のパフォーマンスしか出ないけどな。

実際はゲームのタスクはそこまで処理順序に関しては制約が厳しくないので
いくらでも並列化できる。

**名前は開発中のものです。** · 2009/03/07(土) 01:37:59

>マルチスレッドで実行されている以上、並列だし、
並列ではない。並列な部分もあるってだけ。
今は、「正確には並行処理じゃないの？」と問われていたわけで、
純粋に並列でないなら、正確には並列とは言えない。

だいたい、マルチスレッド云々は実装レベルでの話しだし。
タスクシステムがアーキテクチャ的に並列処理かどうかとは関係ない。

**名前は開発中のものです。** · 2009/03/07(土) 01:42:09

コーヒー牛乳は牛乳か→YES
コーヒー牛乳は正確には牛乳か→NO

タスクシステムは並列的か？→YES
タスクシステムは正確には並列か？→NO

**並列さん** ◆dPfetnROQg · 2009/03/07(土) 01:58:35

>>641
> 今は、「正確には並行処理じゃないの？」と問われていたわけで、
> 純粋に並列でないなら、正確には並列とは言えない。

この文章、意味不明だ。この文章、俺の解釈では↓こうだ。

　今は、「正確には並行処理じゃないの？」と問われている。

　スループットが1以下の並列実行なんて並列実行には含まれないので
　「正確には並列」とは言えないので、単なる「並行処理」と見なすべきだから、
　この「正確には並行処理じゃないの？」は正しい。

もし、そういう意味で書いているなら、俺は別に反対意見は唱えていない。

しかしそれなら>>637の書き方が悪い。
「優先順位がつくばあいもあるから正確には並列とは言えない」
だと、「優先順位がときどき偶発的について、そのときに限り並列性が落ちるから
並列とは言えない」と読める。だから俺は>>638のように反論した。
>>637は、正しくは
「優先順位がつく場合、並列化が難しく、並列度が極端に低下して、単一スレッドで実行
しているのと変わらないから、並列と呼ぶべきではない」と言うべきだっただろう。

しかし、俺はそうは思わない。
処理に優先順位がついていようが並列度を上げることは十分可能だからだ。

**名前は開発中のものです。** · 2009/03/07(土) 02:03:29

コーヒー牛乳は牛乳か→NO

**名前は開発中のものです。** · 2009/03/07(土) 02:08:20

>>643
見苦しいです

**並列さん** ◆dPfetnROQg · 2009/03/07(土) 02:10:52

>>645
見苦しいか？ふむ。

それなら、日本語の不自由そうな奴に絡むのはもうやめるわ。疲れるだけだ。

**名前は開発中のものです。** · 2009/03/07(土) 02:23:08

>「優先順位がつくばあいもあるから正確には並列とは言えない」
>だと、「優先順位がときどき偶発的について、そのときに限り並列性が落ちるから
>並列とは言えない」と読める。

優先順位がときどき偶発的について、そのときに限り並列性が落ちることがあるから、
正確には並列とは言えない、であってるよ。
タスクシステムは正確には並列か？という命題に対して、
タスクに優先順位が付く場合を判例に挙げたまで。
処理に優先順位が付く場合、理論的にピュアな並列処理とは言えないからな。
完全な並列性とは、なにをどの順で実行しても構わない場合のみ。

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

>それなら、日本語の不自由そうな奴に絡むのはもうやめるわ。疲れるだけだ。

自分がまともに日本語を扱えないくせに。
>>643とか、これ日本語ですか？

Q：タスクシステムは正確には並列か？
A：タスクの処理の優先順位をサポートするタスクシステムの場合には、
　　タスクの処理に順序が出来るので、この場合は正確には並列とは言えない。

たったこれだけのことが何で分からないのか。

彼はこの問題を実装レベルの並列度の話に持ち込もうとするが、
そもそも、すべてのタスクを同時に実行できるハードが存在しない現状で、
実装レベルでの並列性をもってして、
「タスクシステムが正確には並列かどうか」を判断するのはナンセンス。
なぜならタスクシステム自体による制限よりも、
ハードウェアによる制限の方が先に現れるから。

**並列さん** ◆dPfetnROQg · 2009/03/07(土) 02:49:57

>>647
> タスクシステムは正確には並列か？という命題に対して、

だが、あんたは、>>635を誤解している。

635は
> 正確には並行処理じゃないの？
と書いてあって、並行ということはconcurrentなのだから、スループットは1倍を絶対に超えない。

635を書いた本人は、「タスクシステムの構造ではスループットは1倍を絶対に超えない」ので
「並行処理と呼ぶほうが正しいのではないか」と言ってるわけ。

それなのにそれに対する受け答えとして、あんたは、>637で「スループットがN倍になっていなければ
pureな並列とは呼べないので並行ではない」と言っている。あんたが「並列度1.0(そんなもの現実的に
存在しないんだが)ではない並列」を「並列」とみなさないのはあんたの勝手だが、635に対する返答として
637は、おかしい。

**並列さん** ◆dPfetnROQg · 2009/03/07(土) 02:52:08

>>648
> Q：タスクシステムは正確には並列か？
> A：タスクの処理の優先順位をサポートするタスクシステムの場合には、
>　　タスクの処理に順序が出来るので、この場合は正確には並列とは言えない。
> たったこれだけのことが何で分からないのか。

Qが間違っている。誰もそんなQをしていない。詳しくは>>649

**並列さん** ◆dPfetnROQg · 2009/03/07(土) 03:03:47

俺、もう寝る。

どうか、ID:EEKBitmg ◆HSP4mee/SU は、 ID:ZZNOCL1sの相手をしてやって欲しい。

ID:EEKBitmg ◆HSP4mee/SU の書く内容は、技術的に間違ってることも多々あるし、態度も生意気だけど、
日本語は意味明瞭だし、技術用語の使い方も比較的正しいので俺としてはかなり好感が持てる。

まあ、勉強熱心なんだろうな・・。