タスクシステム総合スレ 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/03(火) 21:37:48

ああ凄いな。凄まじいなID:NIkO1+LIは。
とりあえず総合ヘッダー(笑)については、必要ないことを分かったかい？
まずはそこからだ。

**名前は開発中のものです。** · 2009/03/03(火) 21:39:53

ぬるぽ

**名前は開発中のものです。** · 2009/03/03(火) 21:48:44

>>504
お前は、OOPの基本がわかってない。

腐ってんのはお前の頭。

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

アンチタスカーって、なんで ID:NIkO1+LI　みたいな OOPすらまともに使いこなせない
糞野郎ばっかりなんだろうかね・・

**名前は開発中のものです。** · 2009/03/03(火) 21:57:27

さすがのアンチタスカーの俺も擁護できん。
同じPG職なら陰口叩かれてもいいレベル。

**名前は開発中のものです。** · 2009/03/03(火) 22:01:20

ID:NIkO1+LI
2009年ゲ製痛い(ﾉ∀`)ニュース第１位確定だな。
道理でアンチタスク厨とは、マトモな会話が成り立たないわけだ。

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

は？
どうせ総合ヘッダーよんでんだろ
そうじゃなきゃごった煮の意味ないもんな
悔しかったら総合ヘッダー無しでプログラム組んでみろよ
データベースなんだろデータベース(笑)

**名前は開発中のものです。** · 2009/03/03(火) 22:14:31

アンチタスカーは、タスクシステムを使って知ったうえで、叩くべきだわ。
使ったこともないのに想像だけで総合ヘッダーや癒着云々と否定しているのは滑稽すぎるわ。

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

ハイハイ、自機のソースから弾のソースを取り払ってから言ってね

**名前は開発中のものです。** · 2009/03/03(火) 22:21:10

大昔ポケコンでシューティングを作ってた時は
敵ワークx16 弾ワークx16 とか固定長バッファを用意して、使用中フラグのビットマップで管理して動かしてた
ワークエリア内にポインタを書いてリストや仮装関数を実現するには500kHz程度クロックのCPUには重荷だった
今はもうゲームとして動いてるならなんでもいいやって感じ

**名前は開発中のものです。** · 2009/03/03(火) 22:41:02

>>511
総合ヘッダー(笑)って何だよ！
総合病院にでも診てもらってこい。
C++入門者未満のくせに、デカイ顔してノイズ垂れ流しやがって。
タスクシステムを語るには２０年早いわ。

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

main.h に extern 使いまくりで
どこからでも #include "main.h" をすればコンパイルは通る
分割コンパイルの意味の分かっていないバカのやることだよ

ええそうですよ私の講師がそうだったように・・・

**名前は開発中のものです。** · 2009/03/03(火) 23:13:28

アンチタスカーだが俗に言うタスクシステムみたいな仕組みを
C++で実現している

ソース晒そうか？

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

**名前は開発中のものです。** · 2009/03/03(火) 23:37:31

仮想関数と総合ヘッダの話は
本元のクラスでなくて、抽象クラスを、includeするということ？
/*総合.h もしくはそれの#include*/
class IHoge : public ITask
{
virtual SomeFunc() = 0;
};
/*Hoge.cpp*/
class CHoge: public IHoge
{
SomeFunc();
};
ということ？
多分、総合ヘッダといった人は、IHogeを抜いて考えていたと思う
もしくは、それでもIHogeを利用するところからIHogeが見えないといけないジャンという
ことを言いたかったのかも

タスクとマルチコアとかの関連っぽい記事を発見したので張っとく
理解はしていないので、賢い人解説して
そして建設的な話をして
http://www.gamasutra.com/view/feature/3941/sponsored_feature_designing_the_.php?page=1

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

戻り値書き忘れたけれど、突っ込まないで

**名前は開発中のものです。** · 2009/03/03(火) 23:47:42

>>519
タスクと言う言葉を軽々しく使わないで下さい

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

>>519
馬鹿はどっかいけよ

**ID:EEKBitmg** · 2009/03/04(水) 00:02:09

厨房見参

総合ヘッダーさん（ID:NIkO1+LI）と引数さんは同じ人だと思うが、まぁそれはそれとして
総合ヘッダーさんはCodeZineの記事に出てくるようなタスクシステムのことを言ってるんだろ？

CodeZineの記事を書いた人は俺と同い歳くらいの学生さんだと思う。叩くつもりはないが
グチャグチャに絡み合ってる反面教師的なコードとしてはなかなか秀逸だなーと思う

task.hに
自機、敵機、自機の弾、敵機の弾　狙い撃ち、爆発、自機の制御、敵の出現制御
ステージ制御、ライフバー管理、スコア管理、タイトル画面、ゲームオーバー画面
といったTaskEx派生クラス全ての宣言をまとめてぶちこんでいる

で、例えば自機弾クラスのソースコードの中を見る。まず先頭でtask.hをインクルードしている
次に自機弾クラスの当たり判定メソッドの中を見る。こいつの中では

int 敵数=GetCount(ENEMY);　// 敵の数よこせ　（循環リストを総舐め）
for(int i=0;i<count;i++){
　　敵ｸﾗｽ *task=(敵ｸﾗｽ*)GetTask(ENEMY , i );　//i番目の敵よこせ　（ヒットするまで循環リストを舐める）
　　…
}
という感じで『"グローバルインスタンスホルダー"の検索結果 3 件中 1 - 3 件目』
に対して、『敵を全部くれ』と要求して、敵クラス型にキャスト（static_cast）している

循環リストを舐めまくりでびびった。HSPでこんなコード組んだら重くて普通に死ねる
C/C++を使うメリットを遺憾なく発揮してると思った

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

>>523
アンチだけれども、別にごった煮にして、
全てをなめるような実装にしなくてもいい気がする
最初から型ごとにリストを持ってそれごと返せばいい訳だし
ヘッダに全部宣言を入れていたのも、サンプルとしてそうしていただけで、
ヘッダが必要な個々の実装でincludeさせてそこでキャストさせればいい
そうすると、型ごとリストへ割り振りは、本当の型で判断できないので
別の情報で型を識別させるようにして型ごとリストを持たせればいいのでは？
タスクシステムに入れる時に型名を文字列で渡すとか
ここらへんは、タスクシステムの弱点ではない気がする
何回も語られているけれど、本当の弱点は、
静的に片付くものをわざわざ動的にして問題を複雑にしている点だと思う
素人考え？

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

> 静的に片付くものをわざわざ動的にして問題を複雑にしている点だと思う

意味がわからない。例えば？

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

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

class Scene {
　Player player_;
　Enemies std::list<Enemy> enemies_;
...
};

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

>>525
静的というのは、シーンクラスのメンバもしくはそのメンバに
自機、敵機、自機弾、スコア管理、ステージ制御などを階層を持たせて
配置しているということ
動的というのは、(少なくともインターフェイス越しには)ごった煮の
グローバルなリストから個々のインスタンスが勝手に互いを参照し合って
どうも統制が取れてなさそうに見えないこと
上の静的でも崩壊させることができるけれど、上手く設計すれば問題は起こらないはず
で、ごった煮はその問題をただ先延ばしにしてしまっているようなイメージを持っている
だからアンチ
>>524
そう。そう思う。
だからアンチ

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

>>どうも統制が取れてなさそうに見えないこと
どうも統制が取れているように見えないこと

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

>>448 の者だが、
タスク進化系がいまだにコンシューマゲーム開発の現場で生き残っているのは単純に無駄が無いから、ってのも理由の一つ。

スーファミからPS1へ、PS1からPS2へ、PS2からPS3へ移行するたびに、こんな大量のメモリ使い切れん、と思ったものだが
なぜかマスター寸前の修羅場になるといつもメモリも速度も足りなくなりチューニングに明け暮れる日々が続く。
これはメモリ128Kのスーファミ時代から256MBのPS3まで、コンシューマ開発では変わらん定例行事。

そして常にメモリとコードの無駄を減らす圧力にさらされるんだけど、タスクみたいに毎フレーム相当数呼ばれる処理に
無駄が見つかると真っ先に削られる。

この修羅場では「可読性が…」とか「OOP的に…」なんて甘い理由よりも少しでも軽量なコードで動かすことが優先される。
で、PS3時代にもタスク進化系が生き残ってる、というわけだね。

仮想メモリつんでてスペックはユーザ毎にばらばらのPC環境では特定ハード向けにガリガリにチューニングなんて意味ないので
PC環境でしか作ったことの無い人間には理解できんだろうけど、
コンシューマ開発や組み込み系とみたいに固有のハード性能を120％使い切る開発スタイルではよくあること。

**名前は開発中のものです。** · 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を拡大解釈しているのはあんただろ。