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

**名前は開発中のものです。** · 2008/11/09(日) 11:51:40

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

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

**名前は開発中のものです。** · 2008/11/09(日) 11:56:00

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

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

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

Logician Lord　…　【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

**名前は開発中のものです。** · 2008/11/09(日) 12:19:21

１乙

**名前は開発中のものです。** · 2008/11/09(日) 13:02:33

1おつ

前スレ>>995を実行しようとしたら、
「MSVCP60D.ｄｌｌがみつかりません」って出て実行できんです。

**名前は開発中のものです。** · 2008/11/09(日) 13:37:28

同じく下記2ファイルがみつかりませんと出てきた

　　MSVCP60D.DLL
　　msvcrtd.dll

**名前は開発中のものです。** · 2008/11/09(日) 15:05:15

windows用の関数のスタブを用意したりして
linuxにてコンパイルして動作確認はできた
boost, boost build必須だけど…

**名前は開発中のものです。** · 2008/11/09(日) 15:15:38

boostはいらんな、
なんかCTextBuffer::Openで落ちるから色々調べてたときに使ってただけね
パスやらファイル名の問題で*.mqoが開けなかったときにぬるぽが発生して落ちてただけね
あとglutの初期化忘れとか

タスクシステムと全然関係無いですねゴメソ

**名前は開発中のものです。** · 2008/11/09(日) 21:43:46

>>4
それVC6のデバッグ版のDLLだな
うちは入ってるから気づかなかったが

>>995はリリース版でビルドしちゃれよ

**名前は開発中のものです。** · 2008/11/09(日) 22:46:40

>>8
もしくは CRT をスタティックリンク。

**名前は開発中のものです。** · 2008/11/09(日) 23:28:18

ここで10年前に買ったVC6の恩恵を初めて受けることになるとは

**名前は開発中のものです。** · 2008/11/10(月) 22:26:56

>MSVCP60D.ｄｌｌがみつかりません

だっせー！＞俺
すびばせんでした。再うｐしました。

http://uproda11.2ch-library.com/src/11133655.zip.shtml

DLキー task

修正項目
・実行ファイルを Release ビルド
・背景スクロールを実装してみた。
・データローダの別スレッド動作のテストなど

**名前は開発中のものです。** · 2008/11/10(月) 22:36:07

>>7
ｶﾞｯ!(AA略）

>linuxにてコンパイルして動作確認はできた
さすがゲーム板。いや、LinuxでブートCD配布とかできたらと思ってたので。

>前スレの人
・実行順制御よりオブジェクト相互の関係が重要

サンプルを組んでみて、そのあたりの解決が提示されているわけではなさそうですね。< タスクシステム

サンプルのなかで、プレーヤーオブジェクトをポインタで保持してたり、その弊害を
避けるためにフラグ立ててたりとけっしてスマートとはいいがたいような。

TCB+関数ポインタをクラスで置き換えるのは悪いとはいわないが、オブジェクトの
生成削除が頻繁に起こるゲームで、std::listで管理するのはどうかなと思いました。
手軽ではあるのだけど。

**名前は開発中のものです。** · 2008/11/10(月) 22:42:17

>前スレの人
＞実行順制御・描画順制御
まだ慣れていないので評価しにくいですが、サンプルではシナリオの読み込みとか優先度を高くしてありますね。それなりに意味はあるのか？

描画順制御についていえば、OpenGL を使っていても半透明オブジェクトの重ねがき
みたいに描画順をメンテする例もあるので、まあ、あれば使うかなと。
（爆発表現にちょっとつかってみた）

描画に関してはもっとちゃんとしたやり方があるように思いますが。

**名前は開発中のものです。** · 2008/11/11(火) 22:13:14

>>12
> オブジェクトの生成削除が頻繁に起こるゲーム
今時のマシンなら高がしれてるよ。エフェクトでパーティクル個別に new するとかだと、さすがに
氏ねと思うが。

**名前は開発中のものです。** · 2008/11/11(火) 23:33:37

>>14
>今時のマシンなら高がしれてるよ

CPU負荷や処理速度じゃなくて、サンプルの例だと、stl::list からオブジェクトを
削除する場合のトリッキーに見える処理がちょっといやらしいかなと思ったんですよ。

ただ、シーケンシャルな処理だと考えればそんなに問題もないのかな。

**名前は開発中のものです。** · 2008/11/11(火) 23:45:14

>>15
そういう話なら同意。というか、何でもかんでも一つのリストにつながなくても、ふつーに
std::list<Enemy> enemy_list;
std::list<Effect> effect_list;
と分けとけば良いのにね。

**名前は開発中のものです。** · 2008/11/11(火) 23:45:44

今時のマシンでもメモリ問題は意識すべきだよ。
少なくとも自分以外の人に遊んでもらえるゲームを作るつもりならね。
モジュールのライフスパンに応じて適切にヒープを分けるだけなんだから
最初からやれば手間はかからない。

今時はコンシューマゲーム機の開発者でさえもメモリ管理をおろそかにする未熟者が多い。
マスターアップ近くになってフラグメント化のためゲームがハング。
対策を練ろうにもグローバルでnew、deleteだったから全部書き直しするしかないという
実話もあるほど。

**名前は開発中のものです。** · 2008/11/12(水) 00:46:23

1GHz 512MB VRAM8MBで起動した
超絶スローで

**名前は開発中のものです。** · 2008/11/12(水) 01:05:05

>>17
CodeZine のサンプルはメモリ管理にこだわってたよね。
「タスクシステム」の要件にメモリ管理を加えるべきか、みたいな
話もあったけど。

**名前は開発中のものです。** · 2008/11/12(水) 01:07:38

>>18
>VRAM8M て、trio64とか？w
さすがにOpenGL のハードアクセラレーションないとちょっときついかと。

**名前は開発中のものです。** · 2008/11/12(水) 06:58:36

>>17
> 対策を練ろうにもグローバルでnew、deleteだったから全部書き直しするしかないという

なんでそうなるんだ？
「モジュールのライフスパンに応じて適切にヒープを分けるだけ」なんだろ？
後でもできるじゃん。

**名前は開発中のものです。** · 2008/11/12(水) 08:16:49

>>17
メモリの断片化が問題になるのは、極端にサイズが大きいものと小さいものを
同じヒープから確保する場合。

テクスチャ・モデル・モーション・サウンドなどのリソース類だけ分けておけば、
あとのゲーム制御用のインスタンスは気にせずグローバルなヒープから new,
delete で OK だよ。

**名前は開発中のものです。** · 2008/11/12(水) 12:09:14

そんなどんぶり勘定が許されるのは素人ゲーだけだよ
少なくともヒープ使用量の最大値は見積もれていないと
売り物にしてはいけないね。
フラグメント化対策の方法論なんて確立されているんだから
それをおろそかにするのは単なる手抜き以外の何者でもない。

**名前は開発中のものです。** · 2008/11/12(水) 12:25:51

まったくだ。

「おそいかも」とか「フラグメンテーションが発生するかも」なんていう
どんぶり勘定で面倒なメモリ管理コードなんて追加しちゃいけない。

「ここがおそいことがわかったから」「ここでフラグメントが問題になったから」と
言えるなら何か細工を入れてもいい。言えなきゃおとなしく new/delete 使っとけ。

**名前は開発中のものです。** · 2008/11/12(水) 12:41:37

問題になるまではGCやsmart_ptrを使っていてもおkと

**名前は開発中のものです。** · 2008/11/12(水) 13:08:03

いいよ
仕事でやってるやつはみんな何回も痛い目見てるから自然と神経質になる
問題が出ないうちから考えてもアタマでっかちになるだけ

**名前は開発中のものです。** · 2008/11/12(水) 23:22:51

>>23
> そんなどんぶり勘定が許されるのは素人ゲーだけだよ
気のせい。

**名前は開発中のものです。** · 2008/11/13(木) 05:53:34

newとdeleteはやたら使用メモリの全体量がわかりずらいな
mallocからしてロクなもんじゃなかった気がするけど
newとdeleteほどアフォ仕様じゃなかったよな
オーバーロードするといちいちそのヘッダ呼ばないと
newとかdeleteとか呼べないしで糞面倒くせぇ

せめてデバッガで見えれば助かるんだけどそういう機能ってないの？

**名前は開発中のものです。** · 2008/11/13(木) 07:37:37

>>28
ふつー ::operator new() ではなく、クラス内の operator new をオーバーロードするから、
必然的にヘッダ読み込むことになると思うが。

メモリ使用量は、使ってるライブラリによるな。俺は自前で書いたのがあるから、それを
使ってるけど。

**名前は開発中のものです。** · 2008/11/13(木) 16:57:10

タスクシステムと分岐予測やパイプラインの関係を考察してるようなサイトありませんかね？
ググッてもこのスレばかりヒットしますw

**名前は開発中のものです。** · 2008/11/13(木) 19:06:42

>>28
＞mallocからしてロクなもんじゃなかった気がするけど

それ実装対象・OS・ライブラリの組み合わせに依存した話
例えばおまいらが大好きなx86系PCとWindowsとVisualStudioの組み合わせの場合
VS付属のmalloc、デフォルトのnew/delete、STLのデフォルトアロケータの中身を見れば
どれもHeapAllocに行き着く

暇だった頃にベンチマークテストして遊んだけどHeapAllocが他のアロケータ
(GNU libc malloc、BSD Malloc、etc)と比べてロクでもないという感想にはならなかったな。
HeapAllocはおそらくDoug Lea Mallocそのものかその親戚筋に相当する実装だろうと思う。
>>28はdlmalloc系がロクなもんじゃないと言いたいの？それともヒープ使用量をモニターする
手段が見つからないからロクなもんじゃないと言いたいの？

**名前は開発中のものです。** · 2008/11/13(木) 19:34:18

>>22
＞極端にサイズが大きいものと小さいものを
＞同じヒープから確保する場合

「極端に生存期間が大きいものと小さいものを同じヒープから確保する場合」
も付け加えといとくれ

**名前は開発中のものです。** · 2008/11/13(木) 20:38:35

>>32だけど>>21で既に生存期間の話出てるね。文盲だね

ネトゲのサーバプログラムとかだとオブジェクトの生存期間の差はかなり強烈なものになるから
例えばWindows系ならHeapCreateとかで適切にヒープ領域を分けといたりするけれど、PCゲーの
クライアントプログラム限定の話ならぶっちゃけこんなの要らん

数ステージを巡回するデモンストレーションモードで数日間ぶん回してメモリ確保に失敗し始めたり
タスクマネージャのグラフが愉快な絵を描いてるとかNtQuerySystemInformationでログ取り続けたら
驚きの結果が、とかならフラグメンテーション云々の可能性を考えてもいいかもだが

そういう場合はステージ毎にHeapCreate/HeapDestroyでドバっと確保・ドバっと開放でもしとけばいい。
これならステージ中のオブジェクトはみんなHeapAlloc系使ってもフラグメントの心配いらね
弾とかパーティクルみたいなサイズ・生存期間共に粒度極小のオブジェクトを大量にばら撒く
ゴジャースなゲームなら表示MAX分だけドバっと確保したboost::pool使うか配列で順序なしのリスト
みたいなことやっとけばいいよ

ところでタスクシステム？ﾊｧ？って感じだな

**名前は開発中のものです。** · 2008/11/13(木) 21:32:18

>>31
俺はそんな難解な話してない
使ってるメモリの使用量がわからない・わかりにくいってただそんだけのこと
あと、メモリリークとかも全然わかんねぇ
IDEの問題になるけど分かる要素がないのがひでぇｌ

で、俺の知識だけだと自分でmallocをラップした関数を実装して
それに使用メモリの総量・使用メモリ状況やメモリリークなんかを
チェックできるようにしてるんだけど

この辺っていつまでたってもウンコじゃね？
とかそういうこと言ってる

（俺が知らないだけかもしれんが少なくともVCはウンコだと思う）

**名前は開発中のものです。** · 2008/11/13(木) 21:49:37

>>30
マジに最適化し出すと、関数の並び順とかまで見直す必要がある。PS2 のときには
キャッシュがマジ少なかったので、ライブラリチームは T15000 使って最適化してたけど、
今はそこまでやってないんじゃないかなぁ。

ゲームロジックはキャッシュミス起きまくりだが、そもそも大して CPU 使ってないので
気にしない。昔も今も。

**名前は開発中のものです。** · 2008/11/13(木) 21:51:07

>>33
パーティクルとかの小さなオブジェクトは STLport の node allocator 使ってた。メモリが
多少無駄になるけど、早いし断片化しないので。

**名前は開発中のものです。** · 2008/11/13(木) 21:56:23

>>34
確認するが、CRTデバッグヒープくらいは使ってるという前提でいいよな？
http://msdn.microsoft.com/ja-jp/library/974tc9t1(VS.80).aspx
その上で不満ということならもう少し詳しくお話をしてほしい

もし使ってないってんなら幾らなんでもネタだろう…（´-`）

**名前は開発中のものです。** · 2008/11/13(木) 22:13:53

>>37
こっちも確認するけど
それアフォがソース見てもわかる奴しかでない奴でしょ？
難しいリークだとアウトプットウィンドウに変なコードがずらずら出てもどこのコードが
リーク起こしてるかまったくわからない機能でしょ？
そんなの使えないよ

正直、その機能に頼るぐらいなら自分でmallocをラップしたほうがよっぽどいい

**名前は開発中のものです。** · 2008/11/13(木) 22:21:07

ちなみに使ってるのはこれ

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF|_CRTDBG_LEAK_CHECK_DF);

なんでこれさ
こんなアフォなんだろうね
俺のいる会社の新人だってこんなアフォな機能作らないと思うよ
やっぱり俺の使い方間違ってる？
ってかそれとももうちょっといい使い方あんの？

さすがにこりゃねぇだろうと思った
だって自分でやればどこのソースのどのコードが使ってるメモリなのか
余裕でわかるようにできるじゃん
これまったくわかんねぇじゃん
動的（わからない法則がちょっとわかってないが）に確保したもんだとほぼお手上げじゃね？

**名前は開発中のものです。** · 2008/11/13(木) 22:53:24

飯くってた
>>36
node allocatorは良いものらしいね

>>38-39
把握した

WindowsだのVisual Studioなど言ったって、なんだよ結局はユーザープログラム固有の
モニタプログラム（システムモニタ（リソースモニタ）やジョブモニタ）を用意しなくちゃ
いけなくなるのかよバーローつー話だよな

通常、ゲーム開発用のフレームワークはデバッグ支援用のツール群とセットになってるけど
それに相当するサービスをVS標準機能に期待するのは難しいね

ま、同人ゲームとか、ここでタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら
無用の機能だが

**名前は開発中のものです。** · 2008/11/13(木) 23:55:15

前>>969
（前略）だからコンテキストスイッチは不要では。

＞コンテキストスイッチは要らなくネ？

ゲームに要求される表現は多様化・高度化し続け、それに伴いゲーム内で処理されるジョブの粒度も多様化し
１イント内に処理すべきジョブ数も増大の一途をたどった。ジョブ（ゲームコード。例えばAI）を記述するスタッフも
増大し多様化した。時間ステップ毎に単純に数値積分していくだけのジョブばかりではなくなり、継続（continuation）
が必要なジョブが増えた。にも関わらずゲームの特性上個々のジョブはμsecオーダーで終了ないし中断することを
要求される。継続に必要な手続きをユーザープログラム側に丸投げする（ユーザープログラム側にリエントラントな
仕掛けを用意させる）原始的なFSMモデルのジョブ制御だけではお話にならなくなり、ファイバーやコルーチンのような
仕掛けも必要になった。これらのジョブの粒度はスレッドを使うには小さすぎ、また数も多すぎる

まぁ、同人ゲーやタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら無用の機能ではあるが

**名前は開発中のものです。** · 2008/11/14(金) 00:06:03

ｽｹﾞｰ参考になってありがたいけど同人シュー制作者の俺にはテラコンプレックスｗ

**名前は開発中のものです。** · 2008/11/14(金) 01:05:26

（訂正）
----------------------------------------------------------
＞（前略）だからコンテキストスイッチは不要では。
＞
＞＞コンテキストスイッチは要らなくネ？
↓
＞（前略）だからコンテキストスイッチは不要では。
----------------------------------------------------------
＞１イント内に
↓
時間ステップ毎に
----------------------------------------------------------
（補足）
一部素人がタスクシステム（以下>>2と呼ぶ場合アリ）とか呼ぶものの実態が>>2程度のものであるという前提に立つならば
これは70年代のハードに依拠する簡素なゲームにとっては無難なジョブ制御プログラムとかモニタプログラムの【断片】だね
しか言いようがない。もはや今となってはね。
これは非常に簡素でオーソドックスなFSMモデルのジョブ制御であり、大昔から科学計算で頻繁に使われ
大昔の計算機、現代でも組み込み用途の超貧弱なマイコン（安いものなら50円前後。RAM数KBとROM数百KBの
ワンチップのやつ。半ば使い捨て）のために用意される超原始的なモニタプログラムにも見られる。
継続に必要な仕掛け、つまりコンテキストスイッチに必要な記述は全部ユーザープログラム側に丸投げ。
何もしてくれない。誰が書いても同じようなものになるってくらい凡庸な、道端の雑草並みのありふれた仕掛けだ。
でも「タスクシステム」という呼び方は珍しい。かなりエキセントリックだ。これは特定の職場内の固有名詞
ローカル用語の粋を出ることはないだろうね

**名前は開発中のものです。** · 2008/11/14(金) 01:22:07

>>41
ＡＩについてで実装できてるわけじゃないから強くは言えんけど
タスクシステムの構造を大きく変えるような手を入れなくてもできそうな気がする。

別スレッドで定期的にタスクを位置等のグループ毎に分割して、グループ内での状況を解析する。
そしてタスクに次に処理がきたときに、次にどう動かすか考えるの役立つ情報をセットする。
とかではだめですか。

**名前は開発中のものです。** · 2008/11/14(金) 01:24:09

>ゲームに要求される表現は多様化・高度化し続け

で、そんなリソース大量消費型ゲームと小規模DSゲームの売り上げが変わんなくて
涙目、という話ですね。わかります。

とかそんなつまらんイヤミはおいとくとして、タスクシステムのサンプル打ち込んで
おもしれーなとか言ってる俺には雲の上の話なんだけど、

>原始的なFSMモデルのジョブ制御だけではお話にならなくなり、

こういうところはなんとなく予想できるんだよ。ただ現実問題として

>同人ゲーやタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発

が、手軽に手をだせる、楽チン開発できてウハウハなフレームワークってあるの？
どうせ勉強するんならそっちのほうがいいような気がすんだけど。

**名前は開発中のものです。** · 2008/11/14(金) 01:26:10

>>45
C++ でふつーにメインループ書いて、continuation っぽいこと必要な部分はスクリプト言語 + スタックレス VM で良いじゃん。lua とか。

**名前は開発中のものです。** · 2008/11/14(金) 01:32:05

Ｑ．【>>2のようなプログラムを「タスクシステム」と呼ぶことに固執し広めようとする人間がしばしば笑い者になるのは何故？】

技術は進歩し続け、計算機は猛烈な勢いで処理速度を向上させ、現代のナウいハードに依拠するナウいゲームを
作るために『『不可欠』』となったナウいフレームワークだのゲームエンジンだのと比べるともはやミジンコ級であり
お世辞にもシステムとはとても呼べない玩具みたいな代物であることは否めない
>>2のような小規模で簡素なFSMモデルのジョブ制御は、原始的なモニタプログラムといえるかもしれない。
しかし一般にOSを表す非プリエンプティブマルチタスクシステムとは明らかに異なる。共通項は非プリエンプティブ
という点だけでありコンテキストスイッチをサポートしていない（その責任をユーザープログラム側に丸投げ
してしまってる）時点でマルチタスクシステムとは明らかに異なる。マルチタスクという用語自体は1960年代半ば
オペレーティングシステムという用語と共に誕生した。UNIVACとかSystem/360のOSが出てきた時代の話。
エンジニアは用語の意味が輻輳を起こし意思疎通に齟齬が生じることを嫌う。OSが提供されないカスタムボードで
走るゲームプログラムの開発者なら兎も角、立派なOS下で走るゲームプログラムの開発者にとってタスクはプロセスだ。

>>2は、過去に「とある開発チームで使われていた原始的なモニタプログラム」が固有名詞として「タスクシステム」と
呼ばれていたのかもしれないね、程度の理解でいいと思う。当時のゲームプログラムはOSが提供されないカスタムボードで
走るものであり、ゲーム開発者自前のモニタプログラムを用意しハードの全てを自分でコントロールした

＃google2001の検索結果によると当時「タスクシステム」などと呼んでるページはほぼ皆無だったことが判明している
＃ほんの一部でその単語を使ってたページは出典としてLogician Lordを紹介していた。ネットで徐々に伝播しCマガで
＃松浦とかいう素人プログラマが出典を明記せずに紹介し急速に流布し広めた「タスクシステム」なる呼び方の出所は
＃Logician Lordだろうと思われる。これがネット発の「タスクシステム」なるものの出自だ。都市伝説と呼ぶに相応しい

**名前は開発中のものです。** · 2008/11/14(金) 01:55:22

>>46
スタックレス + lua でググった。
なるほど、いまどきはタスクシステム(FSM)でｶﾘｶﾘやる、やれるくらいの規模の開発
なら、単純なメインループとスクリプト言語のほうが楽だしパフォーマンスも出る
ってこと？

難点はあのパスカルくささに耐えねばならんとこかなあ。ﾆﾝﾄﾓｶﾝﾄﾓ。

**名前は開発中のものです。** · 2008/11/14(金) 01:57:27

>>48
状態遷移が複雑な部分、たとえばアクションゲームのプレイヤー制御とかは
C++ で書いといて、continuation あった方が楽な部分、たとえば「何秒後に
エフェクト発生」とかはスクリプトとかデータファイルで書くのがふつーじゃね？

**名前は開発中のものです。** · 2008/11/14(金) 02:05:40

>>42
必要ないものは取り入れる必要はない。コンプレックスは持つ必要ない。
俺も同人ゲーを作ったことあるが規模相応の簡素なコーディングで済ませてた。
いわゆるタスクシステムとか紹介されてるあのヘンテコな仕掛けも不要だった。プライオリティ？ハァ？って感じだ。
敵の配列が弾の配列があって。そんな感じだ。
タスクシステムを心の底から崇拝する人間が心の底から子バカにしている様子がたまに見受けられる
配列厨のコードそのものだ。

同人ゲームを悪く言うつもりで書いたわけではないのだが、もし>>40-41の「同人ゲーム～」の部分が気に障るなら
そこは撤回する。すまなかった

**名前は開発中のものです。** · 2008/11/14(金) 02:05:58

>>49
luaはver4のころちょっとかじっただけなんだけど、スクリプト処理のために
組み込んでみようとは思ってたんで、考えてみるよ。ありがと。

**名前は開発中のものです。** · 2008/11/14(金) 02:22:54

>>44
多種多様な人間が多種多様なジョブ（ユーザープログラム）を記述することになると
「FSMモデルのみ」という拘束条件は必ず無理が生じる。これはやれば分かるという他ない
RAM数KBの組み込み用モジュールのモニタプログラムでもコンテキストスイッチをサポートしたがる。
FSMモデルでジョブを記述させると色々面倒くせーことになるから。説明するよりも組んでみたほうが
分かるという他ない

＞別スレッドで～

よく分からんがコンテキストスイッチをサポートしたくないがためだけに
何やら複雑怪奇な仕組みを導入する話のような気がしてならない
素直にLuaとか使ったほうがいいよ。というか眠いばいばい

**名前は開発中のものです。** · 2008/11/14(金) 02:29:54

>>50
＞規模相応の簡素なコーディングで済ませてた
そこんとこがよくわからんのだよなあ。
単純な配列とループで組めて問題ないならぜんぜんOKでしょ。俺もそうする。

ただ、サンプルでも使ってる GLLib の人のサンプルソースは単純ループ
だけど、けっこうきつい印象を受けた。

俺も「タスクシステム」を採用するだけでバラ色の未来が開けるとは思わん
(まだかじっただけなんで実はすごい泥沼が待っているのかもしれない)けど、
そこそこ使いまわしが効いて、それなりに見通しがいいように思う。

要は適材適所じゃないかと思うんだが、用語を使うことすら非難するほどの
問題があるの？

**名前は開発中のものです。** · 2008/11/14(金) 02:37:14

＞何やら複雑怪奇な仕組みを導入する話のような気がしてならない

こういうのは、同意できるんだよね。
そこそこ便利そうだけど決してわかり易い仕組みとはいいにくいから、
なんか泥沼にはまりそうな気がする。

まあ、小学生の感想文ですまん。

**名前は開発中のものです。** · 2008/11/14(金) 02:38:50

タスクシステムが有効なのは小規模システムだな
メモリの単位がkまでの環境
Mになると不要

**名前は開発中のものです。** · 2008/11/14(金) 02:46:45

>>55
キャッシュじゃねーかw<k
あー、PICのプログラムとかそれっぽい。

**名前は開発中のものです。** · 2008/11/14(金) 02:49:24

AVRは俺の嫁

**名前は開発中のものです。** · 2008/11/14(金) 07:52:52

i君はルサンチマンに満ち溢れてるなｗ

**名前は開発中のものです。** · 2008/11/14(金) 16:00:01

>>48
Luaの文法が嫌いならSquirrelもいいよ。
ム板でスレタイ検索してみてくださいな。

>>53
自分の書いた文章で古い設計方法に名前がついたことにより
予期せぬ形でもてはやされるようになってしまった。
そのことに対する責任感から現代的な知識を伝えると共に
言葉狩りを行っている。

彼の行動はこのように解釈することもできる。あくまで妄想だが。

**名前は開発中のものです。** · 2008/11/14(金) 19:49:55

タスクシステムを使ってるプログラムの
メモリ・ポインタまわりのバグり具合はハンパじゃないな
フツーに書けとあれほど言ってるのにやって
ゲームと違うところでいっつも四苦八苦してるとなりのプロジェクト

あんまりポインタ周りのバグが酷いからプロジェクトをまたいだ会議で
原因を指摘してやったのにまだごにょごにょ言ってる
もう、お前（となりのプロジェクトのウンコリーダー）に逃げ場はねぇよ

グローバル変数とタスクシステムとポインタの悪用は絶対に全部セットなんだよな
タスクシステム使わないプロジェクトはグローバル変数も使わないしポインタの悪用もしない
だからプログラムがメインから必ず終えるし
組み込むべき箇所もすぐにわかる
第三者がきてもすぐに全体が把握できるってのはでかいね

もういい加減に信者も目を覚ますべき

**名前は開発中のものです。** · 2008/11/14(金) 20:17:38

メモリ、ポインタを怖がるってプロとしてどうなのｗ

**名前は開発中のものです。** · 2008/11/14(金) 21:58:54

馬鹿が触ったポインタほど怖いもんはねえぞ

**名前は開発中のものです。** · 2008/11/14(金) 22:21:45

確かにコンテキストスイッチがないとグローバル変数に頼らざるをえない。

コンテキストスイッチがあったところでスパゲティにする奴はするけどなw

**名前は開発中のものです。** · 2008/11/14(金) 22:34:07

nullポはいねぇがあ～？

**名前は開発中のものです。** · 2008/11/15(土) 00:05:57

>>48
昔Delphi使ってたから、馴染みはあるんだけど、C/C++と併用すると間違うんだよね。
演算子とか。

>>60
あー、それは俺も気になった。
親クラスのメソッド呼んだら、内部で自分自身を削除してて戻ってきたところで落ちるとかw
俺がタコなだけなんだけど、基本的にポインタを多用するスタイルみたいだしな。
几帳面なやつ向きかも。実はちょっとびびってるw

**名前は開発中のものです。** · 2008/11/15(土) 00:27:43

それタスクシステムとかいうナニに限った話ではないと思うんだけどな
相互参照オブジェクト（インスタンス）の取り扱いについてのごく初歩的な
あらゆるプログラムに通じる基本的なお作法の話だと思うんだ

**名前は開発中のものです。** · 2008/11/15(土) 00:34:05

ポインタなくてもタスクシステム組めるけど？