[表示 : 全て 最新50 1-99 101- 201- 301- 2chのread.cgiへ]
Update time : 05/09 09:54 / Filesize : 120 KB / Number-of Response : 355
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

タスクシステム総合スレ



1 名前:名前は開発中のものです。 [2007/03/12(月) 23:09:48 ID:8bV5Boxt]
どうぞ

2 名前:名前は開発中のものです。 [2007/03/12(月) 23:11:13 ID:0dA4mIiS]
重複です。

【新人は】ゲーム業界人の実情を吐露するスレ【20♀】
ex21.2ch.net/test/read.cgi/ghard/1171817509/

3 名前:名前は開発中のものです。 mailto:sage [2007/03/13(火) 00:18:53 ID:GEtPEl1r]
タスクシステムって基底クラス型ポインタに実オブジェクトを代入したらあかんの?

4 名前:名前は開発中のものです。 mailto:sage [2007/03/13(火) 01:05:48 ID:lSPAnQVN]
暇だったんで書いてみた。添削できる人がいたらよろしく。

タスク

プロセス・スレッド・ファイバなど実行パスの総称。
この用語はシステムによって異なるものを指すため、動作システムを明らかに
するか、「実行する何か」といった抽象的な意味でのみ使うことが推奨される。

古典タスク (別名: ファイバ/軽量スレッド/マイクロスレッド/ノンプリエンプティブスレッド)

→ファイバの項を参照

ただし、ゲームのプロセス管理システムとして実装されたものは、コンテキストスイッチの他に
優先順位や実行順序のソートなど各種管理機能を備えたものが通常である。

擬似タスク (別名: 関数ポインタリスト)

関数ポインタ・クラス・(関数ポインタを持った)構造体などをリストで繋いだもの。
古典タスクの機能のうち個々のタスクをリストで繋ぐ部分のみを継承したものと思われる。
データ構造にツリーや配列などの変種がある。一部のゲームプログラマのローカル用語。

注: Winedows3.1等の擬似マルチタスクとは関数のリターンが必要なところは同じであるが、
コンテキストスイッチが伴わないところが異なるため、同じものとは言い難い。

5 名前:名前は開発中のものです。 mailto:sage [2007/03/13(火) 01:06:36 ID:lSPAnQVN]
プロセス[Process]

ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9

注: 組み込み業界ではプロセスをタスクと呼ぶ慣習がある。
ゲーム業界は組み込みに近いシステムから同時代のPC並のものまで主流なシステムが
増えたため、異なる方面のエンジニアが交じり合い用語の混乱を招いていると思われる。

スレッド[Thread] (別名: ライトウェイトプロセス/プリエンプティブスレッド)

ja.wikipedia.org/wiki/%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89_%28%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%29

ファイバ[Fiber] (別名: 古典タスク/軽量スレッド/マイクロスレッド/ノンプリエンプティブスレッド)

軽量スレッドとも呼ばれる。並列的な記述が可能だが、スレッドで必要な
ロックが必要ない点がメリットである。コンテキストスイッチをOSではなく
アプリケーションが明示的に行うスレッド。WindowsではCreateFiber()で作成できる。


6 名前:名前は開発中のものです。 mailto:sage [2007/03/13(火) 20:18:34 ID:oceFcbYg]
コルーチンってやつだよね>ファイバ
スクリプト言語だと結構実装されてる。

7 名前:名前は開発中のものです。 mailto:sage [2007/03/14(水) 16:01:25 ID:r4GZS4Co]
最近はどうでもよくなってきたな、この辺の話。
どんな方法でやっても絶対どっかで引っかかって、
工数もバグの数も実行性能も結局一緒になるんだよ。

タスク、というかゲームオブジェクト管理周辺って永遠に何か気持ち悪いままなんじゃね。
自分のゲームは薄氷の上で踊ってるようにしか見えんし、
他人のゲームは堅牢に動いてるように見える。そのギャップはたぶん埋まらない。むかつくけど。

8 名前:名前は開発中のものです。 [2007/03/15(木) 10:57:04 ID:PMeVIICQ]
一応、タスク関連ということで、脱タスクな話もいいよね?

実は、最近、タスクは古いかな?という気がして、
今は、ABAさんのソース参考にして書いてる。

Titanion
www.asahi-net.or.jp/~cs8k-cyu/windows/ttn.html

昔から、ABA氏のソースは、追っているんだけど、大分洗練されていて面白い。

・敵、弾、パーティクルなどのActorがあり、タスクの代わりに、それぞれのリストを持つ
・これらのリストはいわゆるオブジェクトプールで、あらかじめ(敵なら敵の)インスタンスを生成しておくもの
・様々な行動パターン(仕様Spec)などは、個別にActorに割り当てられるようになっている。
例えば
パーティクルActor + 四角いパーティクルSpec
パーティクルActor + 線形のパーティクルSpec
みたいな感じ。
・Actor自身は、あまり情報を持っておらず、状態は、Stateオブジェクトに放り込む
別にこれはやらんでもいい気がするけど・・・
Actor自身においてもいいんじゃないの?という気がする


9 名前:名前は開発中のものです。 [2007/03/15(木) 11:02:03 ID:PMeVIICQ]
追記

・実際の動きや、描画は、Actorに随時割り当てられた、Specが担当する
パーティクルActor + 四角いパーティクルSpec なら、四角く描画
パーティクルActor + 線形のパーティクルSpec なら、ラインで描画

といったように

欠点としてはだな。
・Stateは、複数のSpecで共通なので状態は、融通が利かない。
例えば、
パーティクルActor + 四角いパーティクルSpec と
パーティクルActor + 線形のパーティクルSpec とで、
(というか、パーティクルActorに関連するSpecすべて)
Stateが共通なので、メンバなんかが煩雑に増えている

そこで、往年の方々なら、タスクシステムよろしく、ワーク領域用意して、
StateをSpecごとに無理やり定義とかやるんでしょうけど、
遭えてやってない感じ。(ABA氏はけっこう古くからいる人のはずなので)


10 名前:名前は開発中のものです。 [2007/03/15(木) 11:04:26 ID:PMeVIICQ]
ABA氏のゲームは、基本的にゲーム中にメモリの再確保はしない方向になってて、
逆を言えば、初期化時ならば、オブジェクトの生成はバンバンやってます。
それがわかれば、ソースは読みやすいし、理解し易い思います。



11 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 15:40:53 ID:b1+VxKry]
最初に確保してあとは使いまわしという事は
リソースプール見たいな感じなのかな

12 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 18:57:37 ID:4gWi6T6s]
脱タスクとか、タスクは古いかな、とかもうね。チラ裏じゃん。
僕の肛門も閉鎖しそうです並みの俺ニュースだろ。

まず俺定義・俺解釈・俺実装の「タスク」について補足説明しろ。
脱だの古いだの閉鎖しそうですだの言うのはそれからだ。

13 名前:名前は開発中のものです。 [2007/03/15(木) 19:16:14 ID:VzhOi8YW]
まあ、そもそも、関連リンクもなしに>>1がスレ立てたのが悪いのだが……。

White Paper - Programming
homepage3.nifty.com/moha/programming.html

タスクシステム
www5f.biglobe.ne.jp/~kenmo/program/task/task.html

CodeZine:本格的なシューティングゲームを実現するタスクシステム(タスクシステム,シューティング,ゲーム)
codezine.jp/a/article.aspx?aid=297

いまどきのタスクシステムの実装
omoikane.my-sv.net/gcss/tasksystem/index.php

ゲーム・ノ・シクミ 第11回 C++によるタスクシステムの実現
今は無き C MAGAZINE 2006年1月号
www.cmagazine.jp/contents/200601.html


「処理関数へのポインタ付きワーク構造体の連結リスト」ってのがしっくりくる

14 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 21:06:26 ID:ZqsnR0zJ]
Javaでやろうとして挫折した。
ワーク構造体とそれをメンバとしてアタッチするラップクラスを作ったんだが
あまりにも気持ち悪くてそこでやめてしまった。

タスクシステムはCで書くから美しく見えるんじゃないかと思ってしまう。

15 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 21:26:14 ID:EXzxsrWu]
JAVAってまともな構造体あったっけ?

16 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:02:28 ID:qutq4pqL]
Javaならインターフェイスとコレクション使えばすぐできるだろ。
ちなみにフレームレートとかは無視する方向で。

17 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:05:34 ID:yIBWThbm]
>>14
それは設計が悪いだけ。
ワーク構造体なんか作らなくても、
タスクインターフェースを実装した具体クラスに
好きな変数ガンガンぶち込めば済む。

18 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:13:03 ID:ZqsnR0zJ]
>>15
ByteBufferってクラス使えば共用体っぽく使えるよ。
ベースはchar配列だけどね。

>>16, 17
極力オブジェクトプールしてくのがタスクシステムじゃなくて?

19 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:25:27 ID:yIBWThbm]
別に>>16>>17の方法でもプールできると思うんだが…。

20 名前:名前は開発中のものです。 [2007/03/15(木) 22:37:01 ID:PMeVIICQ]
>>17
kwsk

動的生成するのかな?



21 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:54:30 ID:yIBWThbm]
>>20
別になんてことはない。

interface Task {
  public void update();
  public void draw();
};

class Enemy implements Task{
  private int x;
  private int y;
  public void update() {x++; y++};
  public void draw() {/*ごにょごにょ*/};
};

例えばこんな感じで超テキトーに作ったとすると、
xだのyだのの部分がワーク構造体部分で
updateだのdrawだのが処理関数部分。

あとはTaskを格納するコンテナに
new Enemyだのnew MyShipだのぶち込んで
順番にupdateだのdrawだの呼び出せばいい。

22 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:58:37 ID:XmQLFBDw]
ワークメモリを分割して使うようなやり方は、高級アセンブラたるC言語ならではといっても良いと思う。
C++ですらそのやり方は馴染まない。ましてや、Javaともなると、メモリ管理を極力隠匿してGCで
自動化しているわけで、それをわざわざ迂回しようとしてるのが>18なんだが、わかってる?
慣れたやり方でやろうとしてしまうのはわかるけども、もう少しオブジェクト指向とか勉強して欲しいとちょっと思った。

23 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:00:47 ID:b1+VxKry]
オブジェクト指向というか言語仕様というか

24 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:09:07 ID:ZqsnR0zJ]
それが気持ち悪いからまっさきに避けたんだが、平行線っぽいから議論はやめとく。

25 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:11:29 ID:yIBWThbm]
>>22
そもそもタスクシステム自体は
全然オブジェクト指向ではないし、
なぜその文脈でオブジェクト指向が出てくるのか。

26 名前:名前は開発中のものです。 [2007/03/15(木) 23:16:11 ID:PMeVIICQ]
>>21
あー、やっぱりそれか・・・。
interfaceないころから、俺は、それでやってた。Javaでないけど。

問題は、メンバが変わるような場合なんですよ。

タスクシステムってのは、実行時に、頻繁にメモリ確保しないのが前提だと思うのですが、
>>21のだと、動的にオブジェクト生成しないといけんよなあ。
まあ、いまどきなら、それでもいいんだけど・・・。
プール使うのは、パーティクルぐらいでも十分の最近の現実。

27 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:26:21 ID:yIBWThbm]
>>26
>>21の場合でEnemyが頻繁に出入りするような場合は
new Enemyで生成するのではなく、
Enemyを管理するEnemyFactoryクラスを作って
そいつからEnemyを引っ張ってくるようにすればいいだけ。
あなたが>>8で言っているActorのリストみたいなものを
EnemyFactoryに持たせればいい。

28 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:33:05 ID:XmQLFBDw]
>>24
御意。

>>25
>そもそもタスクシステム自体は全然オブジェクト指向ではないし、
>なぜその文脈でオブジェクト指向が出てくるのか。

プロセスやスレッドだってオブジェクト指向じゃないけど、クラスとして実装されている。
Javaというオブジェクト指向言語上でタスクと同じ役割をするもの(大抵クラスだろう)を
実装するなら、オブジェクト指向からやらないと、オブジェクト指向言語と処理系が
やっていることを理解できないんじゃないかな。

29 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:40:22 ID:EXzxsrWu]
>>21
その書き方だとたしかにJAVAらしいなあ。
ただ、そうすると、最初にワークスペースを全てのタスクで用意して、というやり方と違って
タスクをアクティブにするときメモリを動的に確保しに行く、ってせざるを得ないのかな?

30 名前:名前は開発中のものです。 [2007/03/16(金) 00:00:01 ID:wlk+IDOq]
>>27
Factoryに、敵別にプールつくって、あらかじめ生成しておいて、
そっからひっぱってくる感じ?

出現する敵の最大数をあらかじめ指定しておいて、
最初に敵出る分全部、生成しておくんかな?ステージのはじめとかに。


敵Aと敵Bが最大10体づつ出る場合、
敵Aのプール10体分と、敵Bのプール10体分とをあらかじめ生成しておくんかいな?



31 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 00:00:39 ID:yIBWThbm]
>>28
あなたが言っているのはカプセル化やクラス設計の話であって、
オブジェクト指向の話ではない気がする。
タスクシステムの構造自体がオブジェクト同士の通信などを
不自然なものにする要員になっていると思うんだよね…。まあこの話はいいや。

>>29
>>27読んでけれ

32 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 00:15:46 ID:4Zw2Xard]
>>30
最大数分を耳を揃えてきっちり用意する必要は必ずしもない。
以下、例えばの流れ。

準備段階。EnemyFactoryのプール容量は5でまだ空。

敵を4体くれという指令が来る。プールが空なので、慌てて4体newして渡す。

敵の出番が終わる。EnemyFactoryが責任を持ってEnemyを回収。プールに4体入る。

敵を3体くれという指令が来る。プールから3体分引っ張り出して、
メンバ変数を適切に設定し直して渡す。

敵を3体くれという指令がまた来る。プールから残りの1体を取り出して渡す。
2体分足りないので仕方なくnewする。

敵6体の出番が終わる。5体回収し、1体はプールに入らないので捨てた。

こんな感じで合計10体が画面に現れる場合だと、
回収して使い回したのでnewしたのは6体分だけで済む。

33 名前:名前は開発中のものです。 [2007/03/16(金) 00:22:25 ID:wlk+IDOq]
>>32
なるほど・・・
完全に動的確保は拒否するわけではなく、
あくまで、メモリ確保を最小限にする方向なのね
キャッシュみたいなものか

34 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 00:26:50 ID:xvDGcZpT]
メインループの中でLazy initializationさせるってありえないんだが・・・

35 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 00:43:11 ID:h9V7zR2G]
そうか?
メモリ確保は重くないだろうし、オブジェクトの初期化処理が重いと感じるのか?

36 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 00:47:28 ID:4Zw2Xard]
>34
>>32は一通りの動作(不足と超過)を示す例としてわざとこうしただけ。
実際はプールが不足しない程度に容量を増やすし、
メインループに入る前にプールは満たしておく。

プールから引っ張り出してメンバ変数を設定し直すことも含めて
Lazy initializationだと言っているのならば、さすがに気にしすぎだと思うが。
っていうか色々工夫したところで更新処理よりも描画処理の方が格段に重いから困る。

37 名前:名前は開発中のものです。 [2007/03/16(金) 01:18:43 ID:wlk+IDOq]
> っていうか色々工夫したところで更新処理よりも描画処理の方が格段に重いから困る。

まあ、そうなんだよなあ・・・。

超絶弾幕シューティングでもないかぎり、
重いのは3D処理だったり当たり判定だったり・・・

38 名前:29 mailto:sage [2007/03/16(金) 01:29:18 ID:ZxwtzxVV]
>>31
つーことは、同時に出現する敵の数は、そのEnemyFactoryの初期化時に生成する
Enemyのインスタンスの数までという制限があるという認識でおk?

古典的つーか、ワークスペースを確保してタスクごとにワークスペースの分割方法を変える場合は、
敵の最大数は、タスクの最大数に近くなるはずなんだけど、そこらへんに対してウィークポイントになるのかな?

いや、もちろん、>>21の場合、JAVAのオブジェクト指向に則った書き方なので、メモリ周りでバグが出にくいというのは理解している。

39 名前:32 mailto:sage [2007/03/16(金) 01:31:03 ID:ZxwtzxVV]
あ、>>30で割と答えが出てたね、失礼。


40 名前:39 mailto:sage [2007/03/16(金) 01:32:59 ID:ZxwtzxVV]
ごめんdでもない書き間違いしたorz

>>39 は、>>32じゃなくて>>29で、
答えがでたのが>>32だった。

一昨日妹が死んでまだ慌ててるのかなあ。



41 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 01:55:58 ID:xob5GmNS]
インスタンス変数初めからプールしちゃうとライフサイクル伸びて

じじい世代発見!→フルGC承認!!→光になれー!!

って重量GCシナリオが見えるんだが・・・
俺どこか間違えてる?

42 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 06:47:08 ID:RmBov5WG]
×じじい世代発見!→フルGC承認!!→光になれー!!
○じじい世代が世界に溢れる!→フルGC承認!!→光になれー!!

・初期化時に生成してプール→OLD領域に移動(使い回され領域は無駄にならない)

・短寿命のインスタンスを頻繁に生成→Eden領域がすぐに満杯になる→頻繁にGC発生
 →From・Toが短寿命のインスタンスで溢れる→長寿命でない物もOLD領域に押し込まれる
 →OLD領域が不足→フルGC承認!!→光になれー!!

(チューニングしてEden領域を大きくして(New領域を大きくして)、MaxTenuringThreshholdを増やせばFullGCは起きにくくなるか?

Javaには詳しくないから、嘘書いてたらエロイ人突っ込みヨロシク

43 名前:名前は開発中のものです。 mailto:sage [2007/03/17(土) 00:02:48 ID:ZM3wMuqd]
>>41
殿堂入りしたオブジェクトがゲーム終了まで参照を持つのに何故フルGCが起きる?
キャッシュさせたいインスタンスはさっさと殿堂入りさせる。
そしてキャッシュしないと決めたインスタンスは短いスパンで確実に使い捨てする。
フルGCを起こさせないための基本的なリソース管理だよ。

FPSを意識するゲームであるなら、ピーク時に的を絞ればいいだけだから簡単だよ。

44 名前:名前は開発中のものです。 mailto:sage [2007/03/18(日) 13:30:17 ID:opYiOvzt]
ゲームにおけるデータ構造・クラス設計・パターン
pc11.2ch.net/test/read.cgi/gamedev/1155209226/

話題的に上記のスレが適当だと思う。
っていうかタスクシステム単体で語るようなことが思い浮かばない。

45 名前:名前は開発中のものです。 [2007/03/21(水) 19:40:49 ID:v8Vhdcv6]
トラックバック:pc11.2ch.net/test/read.cgi/gamedev/1155209226/

46 名前:名前は開発中のものです。 [2007/03/23(金) 12:53:45 ID:28C6AFOi]
敵といってもたくさん種類いるし
敵以外にも色んなタスクがある場合、それぞれ個別にプールしとけってのか?

47 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 13:23:37 ID:vxAgs8Dc]
>>46
そんなのは場合によるだろ。
ただ、たくさん種類がいるからめんどくせーって理由だけで
プーリングを放棄するのはただの怠け者。

48 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 20:59:09 ID:V2teaCuf]
>>46
俺もそれ悩んだことがある。

で、悩んだ結果オブジェクトのプーリングはやめてnew/deleteを乗っ取って
自分でフリーリストを実装することにした。(キャッシュするものを一段低レベルな
ところに持っていくってことね。) C++の話でJavaでできるかは知らん。

ただ、敵が何体以上は出ないってゲームも割と当たり前なんで、プーリングの
数をハードコーディングしてしまっても別にいいとも思う。

49 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 21:08:45 ID:ZM8fpxF3]
new/delete 置き換えてできることなんて、大抵はデフォルトの実装でも
同じことやってるんじゃないの?

明確なボトルネックを見つける前から独自のメモリ管理を追加するのは
面倒なバグの元になるだけで終わる可能性がある。
もうちょっとコンパイラ(ライブラリ)実装者を信用してもいいんじゃないかと思う。

50 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 21:36:19 ID:V2teaCuf]
>>49
> new/delete 置き換えてできることなんて、大抵はデフォルトの実装でも
> 同じことやってるんじゃないの?

フリーリスト自体はCRT内にもあるものだし、汎用の用途ならdlmallocが最強(?)かも
しれないけど、例えば確保のサイズが大部分固定だったり、確保開放のパターンが
FIFO的だったりとか文脈に依存したパターンを見つけることで、もっと高速にする余地が
あるんだ。

> 明確なボトルネックを見つける前から独自のメモリ管理を追加するのは
> 面倒なバグの元になるだけで終わる可能性がある。
> もうちょっとコンパイラ(ライブラリ)実装者を信用してもいいんじゃないかと思う。

これは至極もっともだ。俺も自分でなんでも作りすぎるのはちょっと悪い癖だと思ってる。



51 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 21:57:58 ID:P2V386bO]
ある程度組み終わった後でも使用するアロケータを楽に変更できるように
組むことなんて可能なのかいな?

52 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 22:32:14 ID:V2teaCuf]
>>51
アロケータをオブジェクトにして種類別に派生させる。
生成部分を取り替えられるようにするって意味で、デザパタでいうところのアブストラクトファクトリに近いかな。

53 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 22:53:52 ID:vxAgs8Dc]
メモリ確保方法によらず、常に同じ記述で
オブジェクトの生成・破棄が行えると楽だな。
オブジェクト毎にメモリ確保方法が異なっていて、
さらに生成・破棄手順が違うとかだと悲惨だ。

自前でメモリ確保機構を作りたいって人は、
通常のnew、boostのobject_pool、LokiのSmallObj、
Efficient C++のMemoryPoolのソースを全部見てからにした方がいい。
大抵はこいつらで事足りる。
個人的に、boostのobject_poolが最強だと思う。

54 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 00:17:00 ID:OuD128ry]
自分で作ると最速のコードに出来ることがあっても
準標準級のライブラリに似たようなのがあれば作らないってのも勇気だわね

55 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 00:46:35 ID:SQuGfhfH]
>>50
> しれないけど、例えば確保のサイズが大部分固定だったり、確保開放のパターンが
> FIFO的だったりとか文脈に依存したパターンを見つけることで、もっと高速にする余地が

operator new にはサイズしか渡されないし operator delete にはポインタひとつしか
渡されないので、そういう文脈に依存した処理を組み込むのは難しい。
「new/delete 置き換えてできること」と限定したのはそういう意味だったんだが。

56 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 01:18:26 ID:8HwaAyp8]
>>55
> operator new にはサイズしか渡されないし operator delete にはポインタひとつしか
> 渡されないので、そういう文脈に依存した処理を組み込むのは難しい。
> 「new/delete 置き換えてできること」と限定したのはそういう意味だったんだが。

俺が>49で言ってた「乗っ取って」というのは字面通りの単純な置換って意味じゃなくて
生成機構を変更するって意味なので、まぁ、ほんとに置換しかやらないのなら、
そうですね、としか。
というか、オブジェクトプールがどうこうって流れだったんだからその辺は変更できるってのが
前提じゃないの?

57 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 01:21:37 ID:8HwaAyp8]
アンカーミスった。>49じゃなくて>48っすね。

58 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 02:30:22 ID:oJPw3lLB]
お前らはplacement newを知らないのか?

59 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 05:25:57 ID:SQuGfhfH]
>>56
グローバル opeartor new/delete の置き換えと勘違いしてたみたい。ごめんよ。

60 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 05:27:06 ID:SQuGfhfH]
>>58
知ってるけど、この流れでは当たり前というか関係ないというか、どうでもいい。



61 名前:名前は開発中のものです。 mailto:sage [2007/03/26(月) 22:37:04 ID:sS1yrghH]
タスカー様を復活させるのだ

62 名前:名前は開発中のものです。 mailto:sage [2007/03/26(月) 23:35:38 ID:15IZtZoB]
タスク・オム

63 名前:名前は開発中のものです。 mailto:sage [2007/04/02(月) 00:01:32 ID:xHA5oFU3]
タスケテシステムとスレタイ読み違えた

64 名前:名前は開発中のものです。 mailto:sage [2007/04/02(月) 22:36:55 ID:rjkFdofu]
いや、実は読み違えていない。スレ主が書き間違えてるんだ。

65 名前:名前は開発中のものです。 mailto:sage [2007/04/02(月) 22:55:04 ID:QJ3NujtS]
誰かボスケテシステムスレも建ててよ

66 名前:名前は開発中のものです。 mailto:sage [2007/04/10(火) 21:51:55 ID:DVQJ95h4]
Javaでタスクシステムをつくるとき、
各タスクに描画させるのか?(敵のタスクならその機体の描画とか。)

それともタスクは座標だけupdateして、別にTimerとかでPanelをrepaintさせるのか?

67 名前:名前は開発中のものです。 [2007/04/11(水) 08:50:01 ID:0dv8Cb9u]
>>66
ちらつく。
ダブルバファリングしても無理。

68 名前:名前は開発中のものです。 mailto:sage [2007/04/11(水) 09:13:43 ID:J3mbPVHZ]
LWJGL使えよ

69 名前:名前は開発中のものです。 [2007/04/11(水) 21:16:36 ID:S5YhMrov]
スプライトシステムか。

70 名前:名前は開発中のものです。 [2007/04/11(水) 23:21:45 ID:S5YhMrov]
YaneuraoGameSDK.NETのタスクシステムってどうよ。

yanesdkdotnet.sourceforge.jp/wiki/index.php?FrontPage

こういうののJava版とかないかね?




71 名前:名前は開発中のものです。 mailto:sage [2007/04/11(水) 23:58:37 ID:qhNv6z5v]
至って普通。フレームワークにするまでもないというか、使い方覚えるほうが面倒くさくね?というか。
でも、やね氏の作るものは氏が飽きたらそれまでなので今ならXNAでも使っといたほうがいいんじゃないかな。

72 名前:名前は開発中のものです。 [2007/04/12(木) 09:21:05 ID:gzUpXrks]
「シューティングゲームマニアックス」にタスクシステム結構詳しく載ってて、構造体キャスト使ってたけど、結構きつい様な気もする
どうなんだろう


73 名前:名前は開発中のものです。 mailto:sage [2007/04/12(木) 20:30:27 ID:mQKUb85m]
Javaの場合だとひとつのGraphics2Dをコンテキストとするから
タスクが描くってよりも、フレームワークが取り込むって形になりそう

74 名前:名前は開発中のものです。 [2007/04/14(土) 17:35:53 ID:F0D9RwXy]
統合開発環境やデバッガとの連携を全く考慮していない
聳え立つ糞のようなタスクシステムをしこしこ作ってる
孤独なオナニープログラマ諸君。
 
デバッグの容易さとか、保守のしやすさを考えて作ってますか?

75 名前:名前は開発中のものです。 mailto:sage [2007/04/14(土) 17:53:16 ID:3N17piRe]
>>74
あたりまえじゃん

76 名前:名前は開発中のものです。 mailto:sage [2007/04/14(土) 18:33:42 ID:tHggo9K5]
>>74
君はそんなものしか作れなかったのかな?
それはタスクシステムが悪いんじゃなくて、
君のセンスがないだけだから心配することないよ!

77 名前:名前は開発中のものです。 mailto:sage [2007/04/14(土) 18:56:15 ID:KurcdpHU]
そういや、今は亡きCマガにトンデモなタスクシステム紹介記事があったが
あれが出た辺りからタスクシステムというキーワードがすっかり香ばしくなったな。
今では>>13のリンク先の通り、厨房技術用語としての地位は不動のものだな。

78 名前:名前は開発中のものです。 mailto:sage [2007/04/14(土) 20:10:39 ID:KVgw3R/b]
Cマガの記事を書いたライターはおそらく、つか間違いなくド素人。

当時ウェブ上に転がってた情報を拾い集めて書いただけの内容だった。
Logician何とかというサイトの記述漏れや記述ミス(というか独自解釈か)
をご丁寧に全て継承していた。

ウェブ上で都市伝説のように紹介されていたものをまんま丸写しして
「いまどきwのプロが使うゲーム開発の秘技」みたいに神格化して
紙媒体を使って流布したおかげで、言葉だけが一人歩きを始めた。

実装方法は千差万別のローカル用語なのにね。

79 名前:名前は開発中のものです。 mailto:sage [2007/04/14(土) 20:19:46 ID:g5jEBpoC]
フレームワークみたいなもんだろ。
使えるというのは自前の実装で言ってるから判るんだが
使えないというのは自前の実装がへぼいと宣伝してるのかね。

それともあまりにもひどい実装を見たのだろうか。

80 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 02:36:38 ID:0Q+hD2uu]
タスクシステムに限らず、こういうフレームワーク的なものは
利点や欠点を見極めた上で採用不採用を決定するのが当然なわけだけど、
それを怠って何でもタスクシステムにすりゃいいと思っている
初心者が絶賛大量量産中だから困る。
そういう馬鹿どもが勝手に困る分には全く構わないが、
blogで上級者ぶって布教活動をしたり、
頓珍漢な質問をして場を混乱させたりするのは勘弁してくれ。



81 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 02:43:26 ID:KRgQ3nwE]
使えるというのは自前の実装で言ってるから判るんだが
使えないというのは自前の実装がへぼいと宣伝してるのかね?

82 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 03:12:12 ID:vOubHFUU]
>>81
まあ、そうなんだろう。
結局タスクシステムにしたってオブジェクト指向にしたって、理解できなかった奴が否定しているんだしね。

83 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 03:38:07 ID:ib4ZSVvj]
タスクシステムやオブジェクト指向よりも
ちょっと前のレスをわざわざコピペした>>81の真意が理解できません><

84 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 04:14:42 ID:xBb5xlIW]
ヒント:自作自演

85 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 04:28:01 ID:vOubHFUU]
そういや、単発IDが連続してるなここ

86 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 04:39:19 ID:W1PnAJQl]
同一ID:配列
単発ID:リスト→このスレで言うところのタスクシステム。

うむ、スレ違いじゃない。問題無い

87 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 04:47:32 ID:0Q+hD2uu]
>>86の例えが理解できる人、解説プリーズ

88 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 04:59:44 ID:KRgQ3nwE]
日付が変わってID変わっただけだアホ。

89 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 05:00:52 ID:W1PnAJQl]
まぁまぁ、隔離スレで熱くなるなよ。

90 名前:名前は開発中のものです。 mailto:OOもタスクシステムも御神託だね [2007/04/15(日) 05:45:42 ID:5XtjNBFQ]
82 : 「●●を正しく理解しない者が●●を否定するのだ。」

 

( ^??^?)…
●●を魔法か何かと勘違いして布教する厨房が否定されてるだけだろ。

タスクシステムの定義もOOと同様に抽象的なものでしかないわけだが
カビの生えた糞実装(しかも驚くほど似たものばかりが蔓延している)付きで
布教する厨房が頑張ってくれたおかげで、いつの間にかその糞実装込みで
タスクシステムという言葉が定義付けられてしまった感があるな。



91 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 07:11:04 ID:3dsdfwPB]
同列に語るならデザインパターンとだろう。

92 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 07:21:05 ID:5XtjNBFQ]
例えばだけどさ
複数の有限状態機械の相互作用・状態遷移を時間刻み冲の数値積分などで
逐次計算していく(時間発展させる)仕掛けになっていれば、皆タスクシステム
としての体を成してるんじゃないか?
 
>>13のリンク先の連中は、言っちゃ悪いが頭の引き出しが少ないんじゃないかな。
一般化して説明できるはずのものを遠まわしに分かりづらく説明してしまってるね。

結果、頭の引き出しが少ない視野偏狭な読者は、タスクシステムをゲーム業界固有の
ハイパーテクノロジーであるかのように錯覚する。>>13のリンク先を聖経のように
有難がってる趣味プログラマの人はもう少し見識を広めたほうがいいよ。

93 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 11:33:45 ID:vOubHFUU]
>>90
だから、おまいさんがタスクシステムを理解しているというのなら、
何が糞実装なのか教えてくれよせっかくだからさ。

後学のために俺も知りたい。

94 名前:名前は開発中のものです。 [2007/04/15(日) 12:09:21 ID:bzLlTmPF]
>>93
それは俺もしりたい。

上では、糞実装っというより、方言があるものを統一の定番のものように見せているのを
怒っているようにも思うけど。

95 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 12:59:53 ID:vOubHFUU]
>>94
そうかもねえ。
とにかく、具体的なことを、ID:5XtjNBFQが一切書かないおかげで、
なんか偉そうなことを長文で言っているように見えるけど、
実際に何を言いたいのか訳わからんし。

96 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 15:01:20 ID:+CRNM9AG]
>>82みたいなレスをする奴が何を叫んでも
まともに相手にされないだけだと思うが

97 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 15:07:19 ID:vOubHFUU]
はいはい

あいかわらず具体的な話が全く出てこなくなったなここは

98 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 16:27:50 ID:I+ZXuliP]
他人を否定したい。
でも具体的な話をすると自分が否定されるから絶対出来ない。
人間とはそういうもの。

99 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 16:35:35 ID:5XtjNBFQ]
   ∧,,∧
  (・∀ ・) < はいはい、あいかわらず具体的な話が
.  ノ(  )ヽ   全く出てこなくなったなここは。わろすわろすw
   <  >

pc11.2ch.net/test/read.cgi/gamedev/1173708588/82n
pc11.2ch.net/test/read.cgi/gamedev/1173708588/85n
pc11.2ch.net/test/read.cgi/gamedev/1173708588/93n
pc11.2ch.net/test/read.cgi/gamedev/1173708588/95n
pc11.2ch.net/test/read.cgi/gamedev/1173708588/97n

●理解できなかった奴が否定しているんだ
●偉そうなことを言っているように見える
●実際に何を言いたいのか訳わからん

      ズコー
   ヽ(・ω・)/ 
   \(.\ ノ

100 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 16:45:56 ID:vOubHFUU]
ID:5XtjNBFQ は、相変わらず顔真っ赤にして必死だなあw
早くどういう実装が糞実装なのか教えてよwww



101 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 19:44:58 ID:n9DKuG7P]
>>90>>92
暇だからググってみたけど、関数アドレス+汎用ワークのリンクリストという
環境(ゲーム)依存のひとつの手段に過ぎなかったものを、やたら例として
あげたがる所が多いみたいね。ちょっと意外だったわ。ネット文化なのかね。

これ、情報(都市伝説)の出所を辿れば同じところに行き着くんじゃないの。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<120KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef