- 1 名前：仕様書無しさん [2007/02/03(土) 20:11:09 ]
- ま、聞かない方が良い事もあるけどね。
ゲームプログラマーの人に聞きたい
ttp://pc.2ch.net/test/read.cgi/prog/1062855581/
ゲームプログラマーの人に聞きたい 2問目
ttp://pc3.2ch.net/test/read.cgi/prog/1078293745/
ゲームプログラマーの人に聞きたい 3問目
ttp://pc5.2ch.net/test/read.cgi/prog/1080491019/
ゲームプログラマーの人に聞きたい 4問目
ttp://pc5.2ch.net/test/read.cgi/prog/1086890676/
ゲームプログラマーの人に聞きたい 5問目
ttp://pc5.2ch.net/test/read.cgi/prog/1093629292/
ゲームプログラマーの人に聞きたい 6問目
ttp://pc5.2ch.net/test/read.cgi/prog/1100665806/
ゲームプログラマーの人に聞きたい 7問目
ttp://pc5.2ch.net/test/read.cgi/prog/1103458370/
ゲームプログラマーの人に聞きたい 8問目
ttp://pc5.2ch.net/test/read.cgi/prog/1108481342/
ゲームプログラマーの人に聞きたい 9問目
ttp://pc8.2ch.net/test/read.cgi/prog/1110993642/
ゲームプログラマーの人に聞きたい 0xA問目
ttp://pc8.2ch.net/test/read.cgi/prog/1115375538/
ゲームプログラマーの人に聞きたい 11問目
ttp://pc8.2ch.net/test/read.cgi/prog/1119537622/
ゲームプログラマーの人に聞きたい 12問目
ttp://pc8.2ch.net/test/read.cgi/prog/1125150865/
ゲームプログラマーの人に聞きたい 13問目
ttp://pc8.2ch.net/test/read.cgi/prog/1131010658/
ゲームプログラマーの人に聞きたい 13問目 (※実質14問目)
ttp://pc8.2ch.net/test/read.cgi/prog/1131024006/
ゲームプログラマーの人に聞きたい 15問目
ttp://pc8.2ch.net/test/read.cgi/prog/1143779166/
- 91 名前：仕様書無しさん mailto:sage [2007/02/12(月) 19:11:49 ]
- 75 任天堂
70 SCE ＭＳ
67 コーエー
63 セガサミー スクエニ
60 ナムコ バンダイ
58 コナミ HAL研
56 カプコン
53 ハドソン インテリジェントシステムズ フロム
52 チュンソフト ゲームフリーク ディンプス レベル5
51 メディアファクトリー アイディアファクトリー キャメロット ファルコム
50 バンプレスト ブラウニーブラウン ユークス スパイク eb! アルゼ
49 アトラス ゲームアーツ テクモ
48 アートディンク サンソフト アスミック サクセス
47 ガスト トーセ タイトー
46 イマジニア アイレム アテナ アリカ 元気 アルファシステム
45 トレジャー 日本一ソフトウェア SNKプレイモア 魔法
44 NECインターチャネル ケイブ
43 彩京 タクミ パリティビット
42 アルケミスト プリンセスソフト キッド
トーセ下げた。キッド下げた。タイトー上げた。アルゼ上げた。ファルコム上げた。
- 92 名前：仕様書無しさん mailto:sage [2007/02/12(月) 21:11:58 ]
- 洋ゲー好きからすれば、カプコンとスパイクは80ぐらい。
サイレントマジョリティを考慮して、75か70あたりだな。
- 93 名前：仕様書無しさん mailto:sage [2007/02/12(月) 21:31:04 ]
- キッドは０でいいんでない？
最近０になった会社ならいくつか知ってるが。
- 94 名前：仕様書無しさん mailto:sage [2007/02/12(月) 22:42:43 ]
- だんだん、ゲハ板でスレ立ててやって欲しい気がしてきた。
- 95 名前：仕様書無しさん mailto:sage [2007/02/12(月) 22:57:04 ]
- ゲハ板には業界人総合スレあるし
というか今のゲハ板は懲罰鯖より酷い実験鯖にあるから、
今よりも更に過疎るぞ
- 96 名前：仕様書無しさん mailto:sage [2007/02/12(月) 23:02:15 ]
- そういやゲハで業界人格付けスレがあったな。
最近のゲームファンと古参（パソコン時代からやってる連中）の間で、
各々が好きなゲーム製作者をどのランクにするかでさんざんもめてたな。
個人的には木屋善男（ザナドゥとかイースとかロマンシアとかの作者）がCランク扱いで悲しかったが・・・
- 97 名前：仕様書無しさん mailto:sage [2007/02/12(月) 23:10:39 ]
- 木屋氏にランク付けるなんて恐れ多くてできたもんじゃない
- 98 名前：仕様書無しさん mailto:sage [2007/02/12(月) 23:30:18 ]
- 木屋善男氏とは、以前一緒に仕事した事ある。10年ぐらい前かな〜。
たぶん相手は名前も顔も覚えていないと思うけど、
俺にとってはゲーム屋人生の中でTOP3に入る重要な出来事だったよ。
なんつーか、第一印象は「達人プログラマ」を地で行く人物だな。
話してる内容が凄く高度なのに、ペーペーの俺にでも理解できるように丁寧に説明してくれるし
普通の雑談の中でも、コードの書き方や変数の命名規則から始まって、どのようなツールを用意するべきかとか
データは圧縮すべきでCDROM上の配置も考えろとか、なぜ乱数をMOD演算してはいけないのかとか
そういうゲームプログラマとしての基礎（だが物凄く重要なトピック）がバンバン出てくる。
＃つーか、あの頃の会話を録音して「ゲーム開発心得集」として本出したら絶対売れると思う。他人の褌だけどｗ
真のゲームプログラマってこういう人の事なんだろうなと思った。
マジ天才にして骨の髄までプログラマー。
木屋氏と仕事したのは駆け出しの頃の本当に短い期間だけだったけど、あの時の記憶が今の俺を支えてる。
いつかは追いつけるといいなぁ。
- 99 名前：仕様書無しさん mailto:sage [2007/02/13(火) 02:01:38 ]
- げーむぷろぐらまーさんたちもうんちしますか？
- 100 名前：仕様書無しさん mailto:sage [2007/02/13(火) 03:11:59 ]
- 360のフリーの開発キットがC#ベースってなってるんですけども、
360の開発は現場の商用でもC#使ってらっしゃるのでしょうか？
- 101 名前：仕様書無しさん mailto:sage [2007/02/13(火) 05:41:18 ]
- マッカーサー
- 102 名前：仕様書無しさん mailto:sage [2007/02/13(火) 05:50:28 ]
- 面白くねえオヤジギャグだな
- 103 名前：仕様書無しさん mailto:sage [2007/02/13(火) 08:57:11 ]
- ツールくらいじゃね？
- 104 名前：仕様書無しさん mailto:sage [2007/02/13(火) 15:04:19 ]
- >>100
C++だよ
- 105 名前：仕様書無しさん mailto:sage [2007/02/13(火) 15:34:33 ]
- >>98
これは奇遇だな。俺も一緒に仕事をした事があるが、はっきりいって糞野郎だった。
二度と一緒に仕事をしたくない。技術は古いし、チーム開発不向きな性格。
ちなみに俺が一緒に仕事をしたのは俺が１０年目の頃ね。
技術的な面でかなりブチブチ文句いわれたもんだ。最終的には俺のコードが製品に組み込まれたがな。
たぶん未だにメインループからサブルーチンを呼び出すスタイルで、フラグ云々な遅い
やり方でやってるんじゃないのかなぁ・・・
もうとっくに昔の人。少人数でたこ部屋にこもって仕事をしていた過去の人。
- 106 名前：仕様書無しさん mailto:sage [2007/02/13(火) 17:44:58 ]
- C++からは当分逃げられませんよ。
ム板でも、C++が許されるのはゲーム屋までよねーとか言ってるでしょ。
- 107 名前：仕様書無しさん mailto:sage [2007/02/13(火) 19:23:17 ]
- >>105
>メインループからサブルーチンを呼び出すスタイル
多少違いはあれど、これ以外の方法ってなによ？
しかも、遅いのか？これ？
- 108 名前：105 mailto:sage [2007/02/13(火) 20:03:16 ]
- メインループにコードを全部書くんだよ。
呼び出しが無いから速いぞ。
- 109 名前：仕様書無しさん mailto:sage [2007/02/13(火) 20:27:28 ]
- それは相当しっかり紙面で設計しとかないとコケそうだな。
というか、それほどの節約をしないといけないほど大変な処理をしてるのか？
バーチャファイター５みたいな画像を１ポリゴンごとに関数呼び出しして描画してたら
たしかに大変な負荷にはなりそうだが。
- 110 名前：仕様書無しさん mailto:sage [2007/02/13(火) 20:30:39 ]
- 大昔の低速CPU時代の携帯ゲーム（JAVA）ではそうしてた。
JAVAはCと違って翻訳をクライアント機で実行時にやるから
変数名も短くしたり（ファイルサイズ）関数も減らしたり（関数呼び出しのオーバーヘッド）、
全然JAVAらしくなかった。1人開発だからどうでもよかったけど。
それでも便利なサブルーチンはいくつかそのまま使ってた（文字数の都合もあったけど）。
あんな気持ち悪い仕事はもう堪忍どすえ。
- 111 名前：仕様書無しさん mailto:sage [2007/02/13(火) 22:09:03 ]
- 明日は待ちに待ったバレンタイン！
- 112 名前：仕様書無しさん mailto:sage [2007/02/13(火) 22:16:38 ]
- 悪しき習慣「義理チョコ」 「バレンタイン」もうやめろ
news.www.infoseek.co.jp/topics/entertainment/valentine/story/20070213jcast200725496/
恋人たちが愛を誓い合う――そんな2月14日の「バレンタインデー」の習慣に、なんだか今年は異変が起きそうだ。
渋谷では、「バレンタイン粉砕デモ」が起こり、海外でも「アンチバレンタイン」のTシャツやカードまでが
出回っている。好きな人だけやっていればいい、とも思えるバレンタインだが、急に風当たりが強まってきた。
世界各国で「アンチバレンタイン」の機運
「バレンタインに向け情勢が緊迫化する中、反動的カップル集団は非モテ・喪男（編注：モテない男）・童貞の
フラレタリア階級に対しさらなる弾圧を深めている。恋愛ブルジョワ階級は恋愛普遍/至上/資本主義によって
人々を搾取と収奪の限りを尽くし階級的な諸矛盾を爆発させる状況を示しているのだ」
「義理チョコに対する三倍返しといった明らかな収奪と言える行為を強要する連中に徹底的に
思い知らせなければならない。そう、我々はバレンタインを拒否すると非妥協的に闘わねばならない。
同志諸君、今こそ立ち上がる時が来たのだ！！万国のフラレタリアよ団結せよ！」
- 113 名前：仕様書無しさん [2007/02/13(火) 23:02:28 ]
- どんな物を貰っても３００円に変換される俺は、別に３倍返しでもいいかなぁと思う。
- 114 名前：仕様書無しさん mailto:sage [2007/02/13(火) 23:11:23 ]
- 義理チョコすらもらえないから関係ない
- 115 名前：仕様書無しさん mailto:sage [2007/02/13(火) 23:11:58 ]
- ソースｗ
ttp://www.geocities.jp/job_ranking/industry/famicom.htm
- 116 名前：仕様書無しさん mailto:sage [2007/02/14(水) 01:17:19 ]
- >>105
おまえ自身が昔の人に見えるがw
- 117 名前：仕様書無しさん mailto:sage [2007/02/14(水) 02:08:22 ]
- 最後に整形ツールで関数名を1文字にしろよ。
ログとっておいて復元もできるようにしとけ。
- 118 名前：仕様書無しさん mailto:sage [2007/02/14(水) 02:46:30 ]
- >>108 メインループにコードをぜんぶって・・・
そんな奴に糞野郎呼ばわりされたんじゃ木屋たんは吊るしかないねｗ
- 119 名前：仕様書無しさん mailto:sage [2007/02/14(水) 06:31:26 ]
- 今日は待ちに待ったバレンタイン！
- 120 名前：仕様書無しさん mailto:sage [2007/02/14(水) 10:42:56 ]
- >>105のイタさが際立つスレはここですか。
- 121 名前：仕様書無しさん mailto:sage [2007/02/14(水) 11:22:16 ]
- ところで、リセットベクタから書かなきゃいけないハードの場合、タスク切り替えOSを実装して
レジスタの内容をPC込みで変更するようなコンテキスト切り替えロジックとかつかわないの？
まさか、最近の若い人はmainから全部サブルーチンコールとかして無駄な時間をかけているのか？
ちなみに108は105とは別人。俺が105。
- 122 名前：仕様書無しさん mailto:sage [2007/02/14(水) 11:31:03 ]
- >>121 そもそもそんな古臭いハードで仕事しないからな。
今時リセットベクタから書くってどんな機種だよ。
アーケードの子供向け機とかか？
だいいちサブルーチンコールの時間が無駄っていうけど
メインループからスイッチ文で分岐したとしても、
各ループでサブルーチンコールとスイッチ文判定が一回増えるだけだろ
ボトルネックになる部分はいくらでもあるから、そんなところをケチって俺OS
作る暇があれば描画や衝突判定周りのロジックを見直した方が効果がある。
アセンブラが使えるところを誇示したいのか知らんけど
効果の薄い所にこだわるのはロートルのオナニーでしかないぜ。
- 123 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:01:17 ]
- 最近のコンパイラが吐き出すアセンブラが気にくわないなんてこと全然無いね。
どうしても高速化必要なら最下層ループのアセンブラを再配置するくらいでしょ。
最近の最下層は大抵GPU関係だからその必要すら無さそうだけど。
- 124 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:08:24 ]
- >>122
マルチタスクのOSの上で、各タスクにキャラクタのコードが書かれる感じ。
毎フレーム必要な処理（描画や衝突判定等）
タスク切り替えの時間としてはレジスタとメモリの移動だけ。
mainループから各キャラクタがそのフレームで必要な処理にたどり着くまでの時間よりは
早くなるし、独立したプログラムになるので汎用性も高まる。
まぁたしかに俺はロートルで大昔からやってはいるが引退気味ではあるが現役だよ。
あまりコードいじる時間はないがな・・・・
最近じゃアセンブラまで使わなくてもなんとかなるとは思うけど、
ゲーム屋としてはアセンブラが使える事ぐらいは当然だともおもっている。
１フレーム内で動かすための努力は惜しまぬ方が良いと思う。
ハードが良くなっても手抜きコードじゃすくわれない。
- 125 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:12:38 ]
- 批判するより、持ち上げて情報を引き出した方が得だと思う次第です。
- 126 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:17:41 ]
-
for(i=Num-1;i>0;i--){
for(i=0;i<Num;i++){ ←なんと言われようがこっち派
- 127 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:22:54 ]
- >126
なんか違いがあるの？
…… i>0 がゼロとの比較だから i<num より多少速いのかな？
- 128 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:42:43 ]
- アセンブラのことを考えると、これが一番速いってことになるのかな？
int i = NUM;
do {
} while (--i);
- 129 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:43:07 ]
- >>124 それってバグが出たときに追いかけるの大変じゃない？
切り替え部分はバグが無いの前提なんだろうけど
もっとシンプルな実装にした方が、複数名で開発するようなところでは安全だと思う。
あと機種依存が激しそうなので、それが使えない環境ではどうするんだよと。
そのやり方が社内では枯れてて、複数機種で実績もあるんなら問題は無いんだろうけど
新機種への移植とか考えると、あんまり採用したいやり方だとは思えないなぁ。
どうしても速度が出ないときに、最後の武器としてアセンブラを持ち出すのはありだけど。
>１フレーム内で動かすための努力は惜しまぬ方が良いと思う。
>ハードが良くなっても手抜きコードじゃすくわれない。
そら手抜きはイカンけど、シンプルさや分かりやすさの方を大切にするてのが最近の流れだしょ。
- 130 名前：仕様書無しさん [2007/02/14(水) 12:43:50 ]
- >>125
情報提供。例；画面上に弾むボールが１００個あり、ボールは壁や他のボールにぶつかると動きが変わる。
--------------------
親プロセスは
ボールプロセスランダムな位置を指定して１００個作成。
衝突判定プロセス作成
描画プロセス作成
--------------------
ボールプロセス
INIT:
終了メッセージの受付登録
衝突メッセージの受付登録
衝突判定プロセスへ自プロセス登録
描画プロセスへ自プロセス登録
PROC:
永久ループ(ボールの移動、適当なフレーム眠る）
衝突メッセージ受信：
衝突したボールの位置等から移動ベクタ変更
PROCへ戻る
終了メッセージ受信：
衝突判定プロセスへ自プロセス削除要求
- 131 名前：仕様書無しさん [2007/02/14(水) 12:44:34 ]
- --------------------
衝突判定プロセス
登録されたプロセスに対して毎フレーム処理。
衝突検知した場合は該当プロセスへメッセージ送信
--------------------
描画プロセス
登録されたプロセスに対して毎フレーム処理。
------------------------------------------------
こんな感じにすると、PROC内で必要なフレームだけ処理を行い、毎フレーム動く必要の無い処理は
タスク切り替えが発生しない状態になる。mainループから呼び出す方法にすると、呼び出した先で
結局無処理でメインループに戻らなければならない時が無駄になる。全てのオブジェクトが毎フレーム動作しなければならないようなゲーム（そんな物があるのかはわからないが）
では効果が薄いが、そうでない場合はサブルーチン呼び出しコストを最小限に抑えることができる。
- 132 名前：仕様書無しさん mailto:sage [2007/02/14(水) 12:51:01 ]
- >>124
デバッグは同じ。
切り替え部分はすごく簡単。全てのレジスタとメモリの移動だけ。
複数名で開発しているし、当然機種依存なので機種単位でOSは作る。
枯れた技術だし、実績も大量にある。
mainループから呼び出す方法からマルチタスクに変更した時には確かに
プンスカ社内から文句が出たけど、一度導入して大量のキャラクタが１フレーム
で動作するデモ見せたたら、文句が出なくなったよ。
あと使いまわしが楽になった。描画部分とキャラロジックが分離してるから。
- 133 名前：仕様書無しさん mailto:sage [2007/02/14(水) 13:05:24 ]
- >>130
えー、そんなのアセンブラレベルでやらなくてもいくらでもやりようがあるっしょ。
わざわざageてまで言うほどのもんじゃねーぞ
いわゆる古典タスク方式だと思うけど、最近はクラスでその辺を実装してるよ。
まず、全ての実行タスクはCTaskインターフェースを継承してて、
CTask型のリストなり配列なりのタスクバッファにインスタンスを登録。
メインループではタスクバッファに登録された処理を優先度にしたがって実行。
CTaskインタフェースにフラグを持たせれば、呼び出しをスキップもできるし
一時的に動作を保留するとか描画のみ行うとか衝突後再処理させるとか好きに制御できる。
あ、C++はそもそもオーバーヘッドが・・・とかの話題は勘弁な。無駄に荒れるからｗ
- 134 名前：仕様書無しさん mailto:sage [2007/02/14(水) 13:13:02 ]
- >>129
fiberとかmicro threadとか言う人もいるやつかな
状態管理をステートパターンにする必要がないとか
利点はあるけど、それを使う必要性はそれほど感じないな
それ以上はあまり突っ込まないほうがいい気がする
>>3にあるタスクシステム方向に話が流れるおそれがある
- 135 名前：仕様書無しさん mailto:sage [2007/02/14(水) 13:24:56 ]
- 「タスクじゃ！タスクさまの祟りじゃぁ！！
その話題には深入りしてはならぬぞえ・・・・」
- 136 名前：石田智史 mailto:sage [2007/02/14(水) 13:32:45 ]
- 呼んだ？
- 137 名前：前田神 mailto:sage [2007/02/14(水) 13:49:53 ]
- 死ね
- 138 名前：仕様書無しさん mailto:sage [2007/02/14(水) 13:53:12 ]
- やってる事は同じなのに「fiber（コルーチン)」なら最先端で「アセンブラによるタスク切り替え」だとロートル呼ばわりされる件
- 139 名前：仕様書無しさん mailto:sage [2007/02/14(水) 14:26:48 ]
- まずコルーチンと書けば済むことを長々と説明するところがロートルだな
- 140 名前：仕様書無しさん mailto:sage [2007/02/14(水) 14:36:23 ]
- ロートルは無駄にアセンブリャーで小技を駆使するからな。
C++で普通に書いてもかわらんちゅーに。
マルチコアでのパフォーマンス追及するならまた話が違ってくるけど。
- 141 名前：仕様書無しさん mailto:sage [2007/02/14(水) 14:47:29 ]
- 小技すら駆使しないロートルしか見たことがない。
- 142 名前：仕様書無しさん [2007/02/14(水) 14:48:18 ]
- みなさーん！
C++でアセンブラを使わずに、fiberを「普通に」実現する方法を
スーパープログラマーの>>140氏が公開するそうです。
- 143 名前：仕様書無しさん mailto:sage [2007/02/14(水) 14:52:51 ]
- おっさん「最近の若いもんはアセンブラも書けんのか」
若いもん「古株のおっさんはシェーダーも書けんのか」
- 144 名前：仕様書無しさん mailto:sage [2007/02/14(水) 15:04:51 ]
- > mainループから各キャラクタがそのフレームで必要な処理にたどり着くまでの時間よりは早くなるし
今のハードや複雑なゲームロジックで一体どの程度の差があるというの。つーか昔のハードでも。
> 独立したプログラムになるので汎用性も高まる。
どう見ても低レベル層に依存して低下している。
> ゲーム屋としてはアセンブラが使える事ぐらいは当然だともおもっている。
そうですね。俺もZ80や68000やx86でバリバリ書いてましたよ。
昨日もWrite Great Code買おうとしたけどぬるぽすぎてやめた。
> １フレーム内で動かすための努力は惜しまぬ方が良いと思う。
fiberにしない人間が惜しんでいないとでも？？
> 一度導入して大量のキャラクタが１フレーム
> で動作するデモ見せたたら、文句が出なくなったよ。
fiberを使うとキャラが大量に出せるんですか。8ビット時代のハードですら誤差範囲内としか思えませんが。
まして今なら保守性やGPU資源について頭を悩ませたほうがよいかと。
> あと使いまわしが楽になった。描画部分とキャラロジックが分離してるから。
fiberとは無関係。
タスクを全部fiberにしてしまうような文化、あるところにはあるんだろうけど
俺はそんなコードに関わりたくないし、幸いにも関わったことがない。
こういう非標準的な我流殺法にこだわる人間が近くにいると大変だろうな。
まあ、世の中にはLispを採用するような突き抜けたのがいるみたいだから、まだ可愛いものかもしれない。
- 145 名前：仕様書無しさん mailto:sage [2007/02/14(水) 16:32:02 ]
- ゲームロジックに関して言えば、今も昔も変わらないと思うよ。
- 146 名前：仕様書無しさん mailto:sage [2007/02/14(水) 16:35:21 ]
- FiberってWindows以外のプラットフォームで実装されている？
俺、Win物ずーっと作るわけじゃないから、プラットホームに依存した考えしか受け付けないのはいやだな。
- 147 名前：仕様書無しさん mailto:sage [2007/02/14(水) 16:41:24 ]
- >>138
スタック切り替え式のタスクで公開されたまともな実装というのは見たことがないし、
〜社に入社しないと教えてもらえないような技法じゃ、そんなものは存在しないと言われても仕方ないんじゃ。
技法をオープンにしてこなかったロートルにも責任はあるんじゃないかと。
>>146
自分で実装するんだよ。
カーネルモードに依存するものじゃないから、WindowsでもCreateFiber等の
APIと同じものを自分で実装できる。
- 148 名前：仕様書無しさん mailto:sage [2007/02/14(水) 18:04:10 ]
- >>144
Z80の頃を知っているのに、誤差範囲とか言える所に？
- 149 名前：仕様書無しさん [2007/02/14(水) 20:04:09 ]
- 一度だけタスクシステム（？）で開発してるところにいたことあるけど
とにかくバグが半端じゃなかった。
こらやめたほうがいいわ。
メインからサブルーチン呼び出す形が一番安定して動くしなによりバグら無い。
これがでかい。
- 150 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:19:18 ]
- メインルーチンから呼び出すやりかたのうが単純だからな。
きにしなければいけない所もすくないしね。
少しでも処理を軽くしたい昔のハードには有効なのかもね。
今ならハードにおんぶにだっこでいくらでも楽に作れるし。
まぁ、昔の人乙。
- 151 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:22:23 ]
- シェーダーも書けんのか。シェー
- 152 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:23:36 ]
- V
＿＿＿＿
∧＿∧ ／＿＿＿／|
( ´･ω･`) .| ∧＿∧ !／!
／ ＼ |（´Д｀ ）|／|
.＿＿| |__＿＿| |______..| /／／ヽ|／|
||＼／＿＿＿／| ／| .| ／.／ | | ＿＿＿＿＿
||＼|..∧＿∧ .|/.| (⌒＼|_＿./ ./|／|／＿＿＿＿／.|
||. | （ ） |/.| ~＼___＿_ノ |.| || ∧＿∧ |／|
|/ ／／|/.| ＼|.!／!!（ ）... | /.|
|| ／／ ..|/.| ＼.!/ ／／ ヽl／|
|| ／／ | |二⌒) ／|.|...|／／ | ll／|
|.|／／ .| | ヽ＼∧＿∧ (⌒＼|_＿./ /.!
- 153 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:52:34 ]
- 「うちはオブジェクト指向のタスクシステム」とかいうところにヘルプにいったら、
無駄に仮想関数使いまくりだったりダイナミックキャストの嵐でパフォーマンスが
ぼろぼろ（ステージ途中でインスタンス作りまくりのおまけつき）、
しかもタスクシステムのリソース開放タイミング管理が甘くて、ぬるぽとメモリリークの嵐で後始末が大変でした。
- 154 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:57:29 ]
- >>149
それは言い訳ジャマイカ。
システム組んだ奴や使ってる奴が糞ならどんなやり方でもバグは出るだろうに。
>>150
参考までに聞きたいんだが、そのメインルーチンから呼び出す単純な方式って奴で
複数のキャラが非同期に生まれたり死んだり、お互いに干渉するようなケースって
普通に多いと思うけど、そんな場合はどういう風に組むのが正解だと思う？
俺は昔の人なのでタスク風の書き方以外知らないんだよ。
つーかマジで教えてください、たのんます・・・
- 155 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:03:05 ]
- >>153
馬鹿が使うとそうなる
- 156 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:07:32 ]
- >>154
ゲームと関係無い。
普通にプログラムの能力が低いと思う。
- 157 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:12:56 ]
- いまどきの組み込みはX68000よりはるかに速いから
サブルーチンコール程度でグダグダ言わない。
- 158 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:23:14 ]
- >>154
普通はキャラクラスとか敵弾クラスとか地形処理クラスとか作ってメインループから呼び出すんじゃね？
タスクなんて処理作らなくてもいけると思う。キチンと設計すれ。
- 159 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:44:04 ]
- CPUの仕組みを理解すればメインだけに全部いれようが
タスクにしようがサブルーチンにしようが違いはないということがわかると思うが。
人間のための仕組みですよ。
- 160 名前：仕様書無しさん mailto:sage [2007/02/14(水) 22:26:17 ]
- >>154
>メインルーチンから呼び出す単純な方式
1.状態の数だけenumでswitch
2.状態の数だけ関数ポインタ
3.デザパタのステートパターン
4.有限状態遷移機械(FSM)でデータドリブン
- 161 名前：仕様書無しさん mailto:sage [2007/02/14(水) 22:41:39 ]
- タスクシステムとかおなかいっぱい('A`)
別に好きなように組めばいいじゃん。
いい加減、細かい処理を自前でset→long jumpとかもうそんな時代じゃないの気づけよｗ
OpenMP でガシガシ書いたほうがはるかに効率いいっつーの。
- 162 名前：仕様書無しさん mailto:sage [2007/02/14(水) 22:58:26 ]
- 擬似タスクとマジタスクが混じってる予感。
- 163 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:03:20 ]
- マジタスクってPCとスタックが復帰するやつのことですか？
- 164 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:18:37 ]
- >>160
１．ありがちだが、これだとシーンの遷移程度にしか使えんだろ。複数キャラを効率よく動かすのには別の仕組みが必要では？
２．これもよく見るけど、微妙にデバッガで追いづらい。
あと、ポインタが破壊されたらあっという間に再現しづらいバグに変化するよな。
つーか、今時関数ポインタとか古臭いよ。
３．オサレに名前を変えただけで本質的には１と変わらんよなｗ
４．データによって変化するという事はコードだけでは処理の流れが追えなくなる。
元データをそのまま使う場合はまだマシだけど、データの内容によって流れが変化するような仕様にすると（そういうケースは多いが）とたんにバグだらけ。しかも再現させずらい最悪のパターンに陥りやすい。
なんかもっとこう、スマートでエレガントでオサレでぬるぽな実装は無いのか？
- 165 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:23:59 ]
- 関数ポインタは古いのか・・
- 166 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:29:30 ]
- Gems3に関数ポインタをWrapしたtemplateクラス使った状態遷移マシンのネタがあったな。
なぜかツボにハマってそれ使わせてもらってる。
- 167 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:48:02 ]
- 個人的にhotateのページの擬似タスクのテンプレートクラス版使ってるけど
集団で作る時は、メインの人がC++好きか嫌いかで
クラスの擬似タスクか構造体の擬似タスクかのどちらかになってる。
どっちにしても関数ポインタとメモリ管理の安全がミソのコーディング手法だけど。
仕事で初めて見た時、C++の擬似タスクだったけど、これが有名な擬似タスクですね、って言っても
メインの人が「？」って感じの返答してたから。通称が無いのかもしれん。
自分は Hotate's Core とかいうホームページで実装方法知ってその人が”擬似タスク”と言ってたからそう覚えてる。
- 168 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:58:54 ]
- >>164
１と３は全然違う。１だとメイン側が状態の数を全部知ってる必要があるんで、
状態が増えるたびにメイン側をいじる必要がある。
関数ポインタがデバッガで追いづらいって、仮想関数も同じ理由で使わなかったりするの？
- 169 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:01:32 ]
- ぐぐってみたが、Hotate's Coreって無くなってるね。
- 170 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:10:06 ]
- >>167
どうせ抽象クラス（へのポインタ）をコンテナに突っ込めばできあがりな構造だろ。
NGワードを持ち出してまでひとくくりにする必要は無いと思われ。
- 171 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:13:34 ]
- >>167
５年以上前の過去ログにぴったりなレスを見つけて
面白いというか、悲しいというか変な気分になった。
pc.2ch.net/tech/kako/985/985540361.html
ここの 150 ね。
- 172 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:18:02 ]
- 最近自分のwindowsはこんな↓
メッセージスレッド（メインループ）
計算スレッド（座標ヒットチェックとか入力判定とか）
描画スレッド
サウンドスレッド（DirectSoundのおかげでほされそう）
通信スレッド
各スレッドが擬似タスクにクリティカルセクションでアクセスする感じ。
- 173 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:26:51 ]
- >>171 そのスレの65-68とか128-165とかのレスを読んでたら全米が泣（ｒｙ
2001年時点から全然進歩してねーのな、おまいら。
たぶんもっと前から同じ議論が繰り返されてるんだろうなぁ。
こりゃ日本のゲームが衰退するはずだわｗ
- 174 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:27:55 ]
-
トップクリエイターが福岡に集結！「Game for Future 2007」イベント開催！
ttp://www.gff.jp/newsDetail.php?key=20070201-020011-ip-test01-ip-t
- 175 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:54:44 ]
- まあカプコンがまだタスクとか言ってるんだから大丈夫だろ。
- 176 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:03:10 ]
- >>164
> なんかもっとこう、スマートでエレガントでオサレでぬるぽな実装は無いのか？
>160とFiberで満足できなけりゃあとはSchemeの継続でもやってくれと言うしかないね。
ゲームの状態遷移なんてその場限りの使い捨てなんだからswitchかFiberの
汚くなりやすいが軽量な手法が向いてるんじゃないかと思うけど。
- 177 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:05:42 ]
- >>165
時代はクロージャーだ関数オブジェクトまんせーデレゲートまんせーとかw
つか関数生ポインタはデータに対する生ポインタより障害は少ないと思うし、有効だと思うんだが駄目な理由はなんなんだろうな？
壊したら普通即飛びで、スタック追えは一発だと思うのだが。
- 178 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:09:34 ]
- 配列よりListやVectorがいいとかそういう程度の問題では。
初期化忘れや未定義変数へのアクセスが出来てれば
アホにもいじってもらえる。
- 179 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:30:35 ]
- >>176
＞その場限りの使い捨て
だといいですねぇ、ほんとにまったく。
- 180 名前：仕様書無しさん mailto:sage [2007/02/15(木) 05:42:52 ]
- >>177
実行するもんによって引数違うことのが多いから役にたたね。
関数ポインタ使う＝グローバルでアクセスできるなにかが必要になる。
だから、あんまりうまい設計にならないことに気がついて辞めた。
- 181 名前：仕様書無しさん mailto:sage [2007/02/15(木) 06:50:53 ]
- 稲葉敦志。神谷英樹。三上真司。そして、選りすぐりのスタッフ達。
新会社SEEDS。
ttp://www.seeds-inc.jp/index.html
- 182 名前：仕様書無しさん mailto:sage [2007/02/15(木) 06:53:09 ]
- SEEDSは社員を募集しています。
プログラマー
ゲームプログラム全般、
ツール及びライブラリ制作
CGツールプラグイン制作（XSI等)
サウンドドライバ制作
C/C++言語でのプログラミング経験
ゲーム作りに対する強い意志と忍耐力
- 183 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:04:13 ]
- なんか話が食い違うと思っていたらやっと原因がつかめた。
オレは昔の人なんだけど、擬似マルチタスクとかを作って使っていた世代。
昔は機械の性能が低くて「開発のし易さ＜実行時のパフォーマンス」だったのね。
今は機械の性能が高いから適当にできる「開発のし易さ＞実行時のパフォーマンス」なのね。
だから、ソースも出てこないFiberとかデバッグがしずらいウンヌンとかいっているのか・・・
日本のゲームプログラマも落ちたもんだ。オレは日本のソフトウェア屋でゲーム屋が一番賢い
と思っているし、日本が海外へ輸出する数少ないソフトウェアだと思ってた。
ゲーム以外のソフト開発もしているからわかるが、ゲーム屋は間違えなく平均艇に賢いし、
手際もいい。土壇場で逃げ出さない根性もあるはず。だからハードに頼らずいいものを
作って欲しい。
Cコンパイラもなく、メーカーからライブラリが提供されなくて、あるものはハードの仕様書のみ。
って状態でコツコツ作っていた時代に戻れないのはわかっているが、もうすこし魂を入れて開発
してもらいたい。
- 184 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:30:29 ]
- >なんか話が食い違うと思っていたらやっと原因がつかめた。
>>3を読めば原因は明らかだよなｗ
- 185 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:34:10 ]
- ネタにしちゃ面白くないし、マジなら引退した方がいいんじゃね？
- 186 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:38:17 ]
- >>183
俺も昔からやってるけど、擬似タスク使う奴は昔からバグ多かったよ。
１フレーム単位のキャラの動作からいって同期してねーようなもん作る奴ばっかりだった。
- 187 名前：仕様書無しさん mailto:sage [2007/02/15(木) 08:05:14 ]
- >>186
1フレーム単位のキャラの動作の同期が気なるようなゲームの場合こそ、
擬似マルチの方が適切だと思うが・・・
各タスクの動作順番をリアルタイムで変更できるし、同じタスクを二度動くように
スケジューラーをいじる事もできるし・・・・
使い方を知らないだけだと思う。
- 188 名前：仕様書無しさん mailto:sage [2007/02/15(木) 08:38:38 ]
- ttp://60.43.240.156/profile/index.html
↑DNSが反映されていない人向け
- 189 名前：仕様書無しさん mailto:sage [2007/02/15(木) 09:22:13 ]
- >>183
>昔は機械の性能が低くて「開発のし易さ＜実行時のパフォーマンス」だったのね。
>今は機械の性能が高いから適当にできる「開発のし易さ＞実行時のパフォーマンス」なのね。
違うよ、昔は開発規模が小さかったから高速化をしようとプログラム全体をチューニングできたが
今は開発規模が大きくなって、全てをチューニングしていたら何年かかっても完成にこぎ着けない、いつの間にか途中で妥協する事になるんだよ。
だからポイントを絞って高速化する必要があるし、高速化のための作業時間を捻出する必要があるの。
パフォーマンスの事ばかりをやっているとかえってパフォーマンスが下がる事に気づけ。
- 190 名前：仕様書無しさん mailto:sage [2007/02/15(木) 22:35:48 ]
- >>181>>188
こうだな
ttp://www.seeds-inc.jp/
ttp://60.43.240.156/index.html
↑DNSが反映されていない人向け
- 191 名前：仕様書無しさん mailto:sage [2007/02/15(木) 23:07:26 ]
- >>187
各タスクの動作順をいじる意味が全くわからない
長いことゲーＰＧやってるけどそんな需要は欠片もねぇ
|
 |
