2 :
仕様書無しさん:04/11/17 13:42:43
2げっと したカナ?
。 ◇◎。o.:O☆οo.
。:゜ ◎::O☆∧_∧☆。∂:o゜
/。○。 ∂(*゚ー゚ )O◇。☆
/ ◎| ̄ ̄∪ ̄∪ ̄ ̄ ̄|:◎:
/ ☆。|.. 新スレおめ .|☆
▼ 。○..io.。◇.☆____| 。.:
∠▲―――――☆ :∂io☆ ゜◎∂:.
4様
5.5
6 :
仕様書無しさん:04/11/17 15:41:21
6
7 :
仕様書無しさん:04/11/17 15:56:58
7
プログラマーを目指すのは負けですか
自殺したら負けかな
と思ってる
いや勝ち組だろ。永遠の安らぎが保証されてるわけで。
自殺に失敗したら負けかな
と思ってる
12 :
仕様書無しさん:04/11/18 00:49:31
俺がゲームプログラマーならHalfLife2とか見せ付けられたら
己の無能さを恥じて今すぐ自殺するね。
>>12 これだから素人は…
ゲームは個人の才能で作り上げるものじゃあないんだよ、坊や
一から十まで一人のプログラマが作ってるわけでなし、気にスンナ
QUAKEのソースとか見たら目ン玉飛び出るぞ。
超汚くて。
ソースの質とゲームの質の関連性はないしね。
ただ、ソースの質を高くすれば開発効率アップにつながり、ひいては期間短縮
コスト削減で利益率アップに繋がるとは思うが。
HL2も開発コストがすさまじそうだからなぁ。HL1の稼ぎをほとんどつぎ込んだ
という話もあるし。
HL2を10人チームで一年で作ったとか言われたら今すぐ出家する。
俺はゲームプログラマーなんだけどHalfLife2とか見せ付けられても
企画の奴らの無能さと会社の金の無さと社長の人の見る目の無さを
恥じながらもとりあえず今は目の前の仕事をやっつけるだけだな。・・・orz
>>16 もれなんぞはゲーム性に関係ないのわかってて、目先の仕事を片付けるので一杯一杯になってたら、
いつのまにやらソースコードの質ばっかり追いかける様になっちまったよ。
気がつきゃ専業ゲームライブラリ書きで、およそゲームプログラマとは言えない生き物になっちまった。
こういう役割の奴がいくらかでも居ないと仕事が立ち行かないのはわかっちゃいるんだが、
道を間違えた気もそこはかとなくしないでもない虚しさを感じる午前二時。
というかHL2なんてマシンパワーという制限を無視してやりたい(やれる)ことをただ詰め込んだだけじゃん。
奴らにとって現実っぽさ(リアル)=価値なんだろうけど、
かってに改蔵風に言えば、
「リアル、リアルって、シミュレートするのは現実だけですか?」
「非現実(非日常)のシミュレーションしてますか?」
ってところだな。
マシンパワーが上昇して、物理演算エンジンとか、環境光エンジンとか。どれだけ近づいても等しくはならんと思うがなぁ。
現実に絶対値で近づけ、越せるように、嘘世界に突き進むほうが全然ありだと思うが。
いや、あれは凄い。
あれだけのものを作るには、かなり最適化を施してるはず。
マシンパワーを無視してるとは思わん。
21 :
仕様書無しさん:04/11/18 13:09:19
つーか、ここの自称ゲームプログラマって
エロゲーのプログラマだろ?
超リアルに床や壁が壊れる3Dのドラゴンボールの格ゲー作ってよ。
23 :
仕様書無しさん:04/11/18 13:34:17
ちょっとはHL2でも見習って、ましな物作れよ
能無しどもがwwwwwwwwwwwwwwwwwwwwwwww
こ、この俺様が・・そんな釣り・・・に・・・・
∩___∩ |
| ノ\ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡、 |∪| | J
/ ∩ノ ⊃ ヽ
>>23 ( \ / _ノ | |
\ “ /__| |
\ /___ /
25 :
仕様書無しさん:04/11/18 14:57:42
>>「非現実(非日常)のシミュレーションしてますか?」
エロゲーの事かァァァァァァ
26 :
仕様書無しさん:04/11/18 15:03:07
>18 名前:仕様書無しさん[sage] 投稿日:04/11/18 08:13:55
>というかHL2なんてマシンパワーという制限を無視してやりたい(やれる)ことをただ詰め込んだだけじゃん。
>奴らにとって現実っぽさ(リアル)=価値なんだろうけど、
>かってに改蔵風に言えば、
>「リアル、リアルって、シミュレートするのは現実だけですか?」
>「非現実(非日常)のシミュレーションしてますか?」
>ってところだな。
ワラタw思考停止も甚だしいな。
そういう事を目指してた時期はもうとっくに過ぎてる。
マシンパワーという制限を無視してやりたい(やれる)ことをただ詰め込んだだけでは
ユーザー確保が厳しくなるので、HL2はわざわざ1世代前のPCでも動かせるような設定に
してあるし、現実っぽさ(リアル)=価値とか言ってゲームが破綻するよりは、
ハボックを使ってなにか新しい遊びが出来ないか?という試みが随所の物理エンジン
パズルであり、非現実(非日常)のシミュレーションはCity17丸ごとシミュしてる。
国内ゲームが、既成のループの中で育ちすぎた結果
新しい遊びをクリエイトできなくなった感があるな。これはw
新スレになってからワナビーくさい書き込みが増えたなあ……。
>>27 このスレはある意味それをニヤニヤするところですよ
で、そのHL2を正しく動作させられるマシン環境はどんなのなんですか?
わざわざ1世代前のPCで動かしたって意味ないでしょ?
HL2が凄いのは、みりゃわかるよ。
HL2どころか、国内のFFだって凄いわな。
大きな会社で、結構優秀な奴が、金と人手かけて作ってる
もんな。
で、それが何?
作る側の自己満足だよな
32 :
仕様書無しさん:04/11/18 17:33:39
だめな奴は何をやっても駄目
FF10はPS2用HDDに最適化された素晴らしいソフトだったしね☆
('A`)
34 :
957:04/11/18 19:45:03
テスト
俺的に気になるのは
「オレタチSUGEEEEEEEEEEEEEEEEEEE!!」
って作ったHL2はまぁ良いとして、
これからもずっと自己顕示欲のために既存のCG技術をリアルタイムで出来るように
追っかけていくだけを続けていくんだろうか?
少年少女が剣と楯もってお花畑を駆け回るゲームにももう飽き飽きだけどな。
37 :
仕様書無しさん:04/11/18 22:04:00
いや、いくらリアル指向が終わったろうとなんだろうと一番になれば別だよ。
物作りってのはそういうものだろ。
HL2を作る体力すらない日本のゲーム業界はそれはそれで「負けた」でいいだろ。
実際勝てねぇし。会社で自分がどれほどの技術もってたって、
そういうのがたくさんいなきゃHL2は作れねぇんだから。
金と人手にしたってあったところで使い方がうまくなきゃうまくまわらねぇよ。
向こうは環境整備から力入れてるってことだろ。
非リアルに走るのは、リアルを一通りこなせるようになってからだろ? ピカソみたいに。
日本には言い訳ばっかしてるヤツ多すぎ。
フェードアウトどころかフェードインすらしてねえだろお前らって感じ。
そうでないヤツももちろんいるけどさ。
39 :
仕様書無しさん:04/11/18 23:24:26
HL2おもしれええええええええええエええ!!
お前ら一生エロゲでもつくってろよwwwwwwwwwwwwwwww
エロゲはゲームの中でも最も簡単に作れるゴミだろ。
おちつけ子供
プログラマの皆さん、HL2用FPS酔い止めMOD作ってください。
>>38 そもそもマシンスペックがあがって物理エンジンを使ってリアルタイムで処理できるようになったから
リアル路線を走れるようになったからなんだが。
ぶっちゃけ面白ければメーカーの規制以外何でもありの世界なんだからさ
昔企画と酒飲みながらそんな話やってたな…
はやいとこ今のプロジェクト上げてゲーム事業部もどりてぇ、パチンコはつまらん・・・
客が求めてるのは「映画」じゃなくてゲームなんだよ。
絵だけすごくて遊びとしておもしろくないものばかり。
すごいCG技術ですごいムービー作ったからみんな見て見て〜的な。
ゲームに何を求めるかはその人次第だろ。
でもゲーム内の世界を歩き回ってるだけで
楽しいってゲームは国産物では久しく見てないな。
最後に出会ったのはJSR(F)かな。
# 音楽も糞つまらんゲーム音楽とは一線を画す出来だったし。
HL2も単純に歩いてるだけで楽しい。
46 :
仕様書無しさん:04/11/19 03:47:16
日本の業界の技術レベルを底上げする必要があるってのは感じてるんだけど
それを育てる土壌が無いよな・・・
数年前は清水や狩野や47氏の中の人の周辺(いわゆる3D野郎会)とBBXなんてサイト
が熱かった記憶があるんだけど、なんか清水本出た辺りから微妙な失速感が・・・
ちょい前だと2chのゲ術板あたりも荒らしが来るまでは割りと役に立ってたし。
今、アマレベルで3D関連技術の交流が一番活発なコミュニティ(サイト・BBS・ブログ・ML問わず)ってどこよ?
虫姫やってくる。
ベーマガ
51 :
仕様書無しさん:04/11/19 20:26:10
たいした仕事も出来ないお前らボンクラどもに払う金なんて
あるわけねえだろ ボケ
>>46 おまいは古いな。
いろんな意味で古いよ。
3D技術?(プゲラ って感じだな。
お前の周りだけ時間の流れが遅いんと違うか?
>>52 まぁな。確かに俺はロートルだしそれは認めるよ。
でも、これから学んで業界入ってくる奴のために有益なコミュニティがあれば
技術力の底上げができるんじゃないのかなぁ。
アマチュアレベルからプロまで一緒に切磋琢磨できる場がなければ
いつまでたっても国内のゲ業界は技術レベルもそれ以外も斜陽なままなんじゃないのか?
みたいな事を新人教育しながら痛切に感じてるんだよね・・・
#特にゲー専卒の奴ら・・・何もしらな杉・・・orz
もいっかい
>>52氏含めてみんなに聞くけど、3Dに限定しなくてもいいから
今一番活発なゲーム開発者コミュニティってどこだと思う?
54 :
仕様書無しさん:04/11/20 03:04:57
有名大学のサークルとかどうだろう
…アマチュアは加われないか
コミュニティって言うからにはそれ相当の程度の奴が集まるってことだろう?
だったら2chなんかでいんじゃね?
仮に最高水準のネタを扱うような場所があるとして、どれだけの人間が集まれるんだって話もある。
あといまさら技術話をアレコレするような程度かね?
ゲームにおいてはCGにしろなんにしろ、既成技術の後追いだけでいいみたいなもんだし、
それこそ"ゲームの技術"としてなんか新しいの発見しちゃったら人に教えたくは無いでしょ?
人に教えてもいい程度の話なんてのはゲ板でやってりゃいいんじゃねぇか?とは思う。
昔は俺も技術だのなんだの追ってた時期もあるけど、
むしろそんなこと追ったりする必要ないんじゃないかと思うにようになった。
>アマチュアレベルからプロまで一緒に切磋琢磨できる場がなければ
>いつまでたっても国内のゲ業界は技術レベルもそれ以外も斜陽なままなんじゃないのか?
敢えて言おう。90%以上プログラマのせいじゃねーだろ!
まあたしかにプログラマの技術力が足りない、と思えば今はRenderWareとか解決策はあるしなあ。
あとはそれを調達できるかどうか、だが。
最近ム板もゲ作板もきっかけなしに常時荒れてるよな。
ガキの頃に2chがあったらRUBY最強!!とか
嬉々として書き込んでたのかと思うとぞっとするよ。
タスクシステムとオブジェクト指向は相性が良さそうなのに
オブジェクト指向で実装している例を見たことがない件について
>>46 昔と違って3D技術の書籍や情報なんて巷に溢れているし、
nVIDIAとかATIが最新の技術情報は提供しているし、
コミュニティの必然性が薄れているんだよね。
だからBBSとかは、読んでも理解できません系の初心者質問が多くなる。
>>59 1.C++を理解できないプログラマが多い
2.仮想関数テーブルでは関数ポインタを動的に置き換えたりできない。
3.これからは見かけるようになると思うよ。
クラスにしちゃうと動作速度が落ちるような気が
漏れの経験上、純粋なオブジェクト指向設計とスピードは背反する。
落し所が何処かの問題だが、今のところスピード優先。
スピードや資源を気にしないのであれば、フルにオブジェクト指向でもいい。
>>66 俺の経験ではオブジェクト指向が速度のネックになったことは一度も無い。
お前のプログラムはなるのか?この下手糞w
クラスにすると実行速度が遅くなるって、どういう理由で?
ソースコードレベルで余計(?)な手続きが増えるから?
>純粋なオブジェクト指向設計とスピードは背反する?
"純粋な"オブジェクト指向で設計したら、そりゃたぶんムダな処理が増えるよね。
それは"純粋なオブジェクト指向"が"遅い"んじゃなくて、
ゲームのメインシステムの設計に"純粋なオブジェクト指向"を取り入れた"奴"が悪いだけだよね?
スピードや資源を気にしないのであれば、どうして"フルにオブジェクト指向でもいい"のかもわからんのぅ。
世の中わからんことばっかりじゃ。
OOすると遅くなるのは
・virtualメソッドの呼び出し
・委譲による制御のたらいまわし
・オブジェクトの動的な生成・廃棄
・高級感漂うコーディングw
あたりのオーバーヘッドってことでしょ。
C++使う限りはOOのメリットを享受しつつも工夫次第で
上のオーバーヘッドはかなり避けられるとは思うけど。
>>69 で、それってα物の2度描きのコストと比べてどのくらい遅いの?
オブジェクト指向=C++だと思ってる世界の狭い香具師ら
>>67 経験がないだけだろ?
>>68 オブジェクト指向を理解してないチンカス乙
>>70 わけわからん。いったいどういう答えを期待してるんだ・・・
「そんなの無視できる範囲だろ」と言いたいんだろう
>>69 工夫次第というか、既に作法の問題だよな。
Cだとマクロや関数ポインタって俺様ルールに頼るしかない部分が
言語仕様に組み込まれた時点で、後はコンパイラの成熟を待つだけの問題だった。
で、現在C++が性能面において純粋な意味でCに劣るのはRVOが利かない
返り値直渡しを深く深ーくやってるところくらいのもんだな。
メモリ面での無駄はいかんともしがたいものがあるが。
ていうか、オブジェクト指向が速度のネックになるって、未だにそんな原理主義者
生き残ってたんだな。オラ本気でびっくりだよ。
普通OOPって、結局のところデータに対する操作の形を規定することで
論理レベルのオーバーヘッドを最小に抑えることが可能な構築アプローチなんだから
OOP使用のオーバーヘッドが利益を上回っていたのはコンパイラなりの能力が追いついて
なかっただけの話しだし。
大体、それ以前にそもそも理論上最大限に最適化されたプログラムなんてこの世に存在し得ない。
ひとつのソフトの開発に無限の作業リソースをつぎ込めない以上は、単位時間あたりの
生産効率の高さこそが、最終的に最適化作業の時間を確保できる量を決めることになる。
つまり、限られた時間の中で最大の利益を上げたいなら、効率最優先でがっちりした
プログラムを短時間で書き上げて、残りの時間を最適化に回す、これしかない。
OOP使って生産性あがるわけねえだろこのハゲってんなら、もう語ることなんて何もないし。
好きにしろって感じだ。
77 :
おまいら給料貰ってますか?:04/11/21 07:37:23
くやしそうだな
>>79 勉強しろよw
無知に講釈たれても意味がないから書く気もないけど、
馬鹿を馬鹿と指摘するくらいいいんじゃない?
喪前ら、OOP上でスピードを優先したプログラムを書くことは何ら問題ない。
が、それが純粋にオブジェクト指向に沿ったプログラムなのかどうかは気にしてないだろ。w
いつも思うんだがOOを声高々にいう奴は必ずといっていいほど、仕事遅いし出来が悪いと思ふ。
OOする事に問題があるとは思えないのだが(藁
ゲームのときはどんなアセンブラコードになるかイメージしながらクラスを
書いてるから、クラス化で必要なパフォーマンス出せない個所はベタ書き
する。それだけなんじゃないの?
Cの場合でも速度が欲しい時はアセンブラだったりするんでしょ
だったらC+/OOPでやってても速度が欲しいなら、そこは非OOPでしなさいよ
ここにいるやつらってダイナミックバインディグとか知らないんだろうなあ
"ダイナミックバインディグ"に該当するページが見つかりませんでした。
検索のヒント
- キーワードに誤字・脱字がないか確かめてください。
- 違うキーワードを使ってみてください。
- より一般的な言葉を使ってみてください。
>>76 一人で勝手に話を進めて勝手に結論を出すタイプ
>>78,79
負け惜しみはみっともないですよ
>>80 そのレス自体、意味がないから書かないでほしかった
>>81,83,84
正論
>>82 的外れなことを言って自己満足にひたるタイプ
>>85 ゲームでそんなの使うなと言いたい
86はホントに知らなかったみたいですねw
>>85 最適化すれ
ダイナミックバインディングってdll使用みたいなもん?
そういうシステムを実装する?OOと関連した話?
ちょっと詳しく教えてくれ。
バカにされたのが悔しいからって
脊髄反射で関係ないこと書いちゃうヒトってキモ-
late bindingのことだろ
メソッド呼ぶたびに検索するんだもんなあ。
そりゃ遅くもなるわ。
けっきょく、適材適所ってことでFA?
FAだが、今のところオブジェクト指向設計がゲームプログラミングに最適とは言えない。
使用できるリソースが多くなれば最適になる可能性もある。
>>97は、オブジェクト指向設計の真意を知らないと見た。
まあ自分に都合よく考えてもオブジェクト指向だからな。w
みんなあいまい論が好きだねぇ
保守フェイズが無い上に新規案件もタイトル名はともかく内容は0から書き直し
開発が長期化してるとはいえOOPが役に立つとは思えん
101 :
仕様書無しさん:04/11/21 15:52:27
>>98 アホか。
オブジェクト指向にそんな深い概念なんかねぇよ。
あんなの10分で覚えろって感じw
まあ、覚えられない人にとっちゃ一生かかっても無理らしいけどねw
お前は勘違いしてるみたいだから不適合者だった性質だろ?wカワイソウに・・・w
>>101、10分か・・・・・・喪前のアホさ加減がばれたな。w
103 :
仕様書無しさん:04/11/21 16:09:50
>>102 うほw
マジで不適合者だ。
これからツライナw
煽り合いはこれで終わる、「最後ペ」↓ど〜〜ぞ。w
>78-104
自演乙
10分とか言ってる香具師は明らかに釣りだろ。反応しすぎ。
w多用している釣り師が釣れる釣堀はココですか?
お前らさっきから言ってることが難しすぎる。
これにて煽り合い終了。
ここです。w
タスクでは「自由に使っていい領域」ってのを用意するみたいだけど
たとえばJavaでタスクをクラスにするときはどうやるの?
変なキャストはできないから無理なんじゃ?
タスクっていうぐらいだから
デッドラインとかの設定ってあるの?
ちょっとウンコタスクと食事タスク実行してきまつ
さてこのへんで、まずは「タスクとは何か」を厳密に規定するところから議論を始めようじゃないか。
それはOSから見たタスク
やりたい事を小分けに出来て、尚且つあまり同期が必要としない仕事の単位を
タスクと読んでもいいんじゃないかな。
まあ、ゲームの場合自由に定義してもいい。
ゲームシステムでいうタスクとOSのタスクと一般的なタスクは別物。
>>111 Javaではできないが、C++なら継承すればよい。
struct TASK{
void* pfunc;
int common;
};
struct TASK_A : public TASK{
int param; //固有のパラメータ
};
struct TASK_B : public TASK{
int state; //固有のパラメータ
};
で、タスク作るときは固定長のメモリから割り当てるようにoperator newをオーバーロードね。
メモリがからむとムズイ
122 :
仕様書無しさん:04/11/21 19:10:28
チンコに毛がからむとムズカユイ
プリエンプティブな処理のまとまり = スレッド
ノンプリエンプティブな処理のまとまり = ゲームプログラミングにおけるタスク
でいいのかな
>>123でいいんじゃないかな。スレッドと目的は同じだけど、CPUの
コンテキストチェンジを使わずにコードレベルで似たような機能を実現するのがタスク。
設計上の概念だから、技術的な定義はむつかしい。
fiber
メモリ配置まで気にしないなぁ…… と、内部ライブラリべったりの俺様ですよ。
スレッドにはスタックを与える.
スレッドの切り替えは,スタック(& レジスタ + PC)の切り替え.
プリエンプティブうんぬんは関係無し,,,だと思う
処理のつながりを表現できる点がタスクの特徴では?
スレッドだとたくさんループ作らなきゃいけないのに対して。
……テレビを見ていたら、Uが。ワロタ
Cマガ立ち読みしたけどさあ、タスクの解説って、ウェブでも本でも
処理順序とか相互干渉とか泥くせーところが必ずスルーされる希ガス。
そりゃギャラクシアンみたいなの作るぶんには何も考える必要ないけどさあ。
書いてる奴もよくわかってないから避けたいとこなんだよ。
よくわかってるこのスレの住人がサイトを開設してくれ
>>128 そうかい?
なんか使いかた間違ってない?
タスクはあくまでも1つの処理を独立させるためのものだと思うよ。
ゲームに向いてるとかいう人いるけどどうかなぁ。
自分のやり方曲げたくないだけで思考停止してない?
俺はぶっちゃけ向いてないと思うよ。
タスクほどタスク同士の関連や状態遷移が多くなればなるほど複雑な構造って無いと思うよ。
ゲームのタスクシステムってただ関数ポインタを線形リストで繋いだだけなんでしょ?
>>134 そうなんだよな。
まったく意味が無い。
別に処理順序なんて変えないし。
なんでわざわざタスクにしたがる奴がこう増えたんだろうな。
処理順序なんて固定じゃなきゃバグるだろ?
なんかコマンド入力の1文字ずつを関数にして
なんたらとかいう記事を読んだ。
タスクって便利そうだと思った。
>>135 古式ゆかしいタスクの利点は処理が軽い、これにつきる。
今でも十分に使い出のあるテクには違いない。
安全性は、C++の型チェックだのテンプレートだのに活躍してもらうことで
コンパイルの時点かなりのレベルまで確保できる。
複数の状態をまたぐ処理なんぞは、
生まれから死亡してリソースの後片付けさせるまでタスク単位で区切って
あとはルータに回させれば、さっくり並列処理のできあがり。
必要な時に必要なタスクを起動して、必要なくなくなったら死んでもらう。
で、タスク同士は無駄に干渉せず、通信は間接的に行う程度にとどめる。
タスクの調停役が必要なら、上位にルータタスクなり監視タスクなりを設ける。
ぱっと見に何やってんだかわかりづらくなるのは当たり前だし、
前もってタスク間の現在状態やらなにやらをダンプする仕掛けとか用意しとかないと
いざデバッグの段になって酷い目見るのも当然だが、否定されるようなもんじゃない。
状態マシンが過剰に複雑になりすぎる前に、まとまった処理単位でボコボコ
タスクに切っちまえば保守も楽。
すこぶるOOP。
タスクって、スレッドみたいに複数の処理を1フレームに一度ずつ
平行して呼び出す仕組みを言語ロジックだけで実現する仕組みだと
思ってたんだが、みんなが言ってるタスクとは違うものなのか・・・
処理が軽い以外に何かメリットないの?
>>139 保守が楽。
いやマジで。
>>138 それにはある程度歴史的な事情もあると思う。
ゲームは長いこと1アプリ1プラットホームでやってきてて、概念からして
プリエンプティブなマルチタスクなんて代物自体が無いも同然だった。
やりたきゃ勝手にスライシングでもなんでもしてくれと。
狭義でのマルチプロセス(タスクも含んどくか)は、OSなり上位のマネージャーが
リソースの競合を解決しつつ、公平に資源を分配してくれる単位。
スレッドは通常メモリ空間を共有してる処理の単位で、OSの保護がない分、
重いシステムコールを仲介せずにオブジェクト間でのやりとりができるので高速。
で、ゲーム機に紛いなりにでもOSが乗っかり、スッドレだの同期オブジェクトだのを
意識できるようになったのは比較的最近のこと。
タスクって言葉が世間様のそれと乖離しちまうには十分な時間があったってことじゃ
ないだろか。
いや、俺妄想だけどね。
だからさ、関数ポインタでアクセスするのを軽いっていいはるのは
別にいいけどさ、タスクである必要は無いんだよ。
タスクってさ、要するにウィンドウズの下っちょにあるタスクよw
まあ、メモ帳とか、VCとか、ギコナビとかIEとか実行されてるもんがおさまってるわけじゃん?
これらのものってさ、互いに干渉しあわないじゃん。
んで、「実行されるものにフォーカスを移す」って動作が
タスクの醍醐味じゃん。
こういう構造ならタスクはわかるよ。
でもさ、互いに干渉しあって尚且つフォーカス云々じゃなくてすべてが
平行動作してるって状況でなんでタスク?w
タスクスイッチとかクリティカルセクションとかプライオリティとかいらないだろw
そもそもタスクじゃなくていいからw
俺、絶対、選択間違ってると思うんだけど。
言葉遊びだが、それは「プリエンプティブ・マルチタスク」。
タスク実装の一形態に過ぎないぞ。
別段メモリ保護もなんにもなしに関数ポインタ受け渡しまくって
ぽこぽこ状態を遷移してく狭義のタスクをどう呼びたいのか知らんが、
関数自身が次に呼び出される関数を知っていて、状態遷移を繋いでいく仕組みには、
ロボット式なんて呼びもがあるそうだ。
こと遷移対象となるオブジェクト(つーか状態マシン)の実装のことを
タスクと呼びたくないなら、そう呼べば。
正直お前らが何の話をしたがっているのかサパーリわからん
俺も論点がワカンネ
ていうか、「タスク」よりも英語圏のGameObjectとかの考え方のほうが
すっきりするけどなあ。OO的にも。
145 :
仕様書無しさん:04/11/23 10:29:36
状態を表すのに、変数使うか、関数使うかだけの話じゃないの?
今週のCマガジンに書かれてないような便利な仕組みを教えて欲しいな。
開発現場ではどんなコードがかかれてるんだろ?
あと、同じくCマガジンでゲーム用スクリプトをつくる記事があって、
なるほどなぁって思ってるんだけど、
FFとかで使われてるスクリプトってどんな仕様なんだろうか?
ジャンルごとにいろいろあるんだろうけど、ゲーム用スクリプトに特有のアイデアを
知りたい。
>>141 ゲームじゃあ、独立性はないに等しいっすね。おっしゃるとおりで。
OSというか、ユーザー(?)から考えるとタスクなんてものは、同時に実行しているアプリの数、との指摘は正解、というか大多数のタスクの定義ですな。
と言っておきながら、線形ポインタによる関数羅列を順次実行するだけでもタスクと呼称するのは、旧いタームでしょ。
新しいプログラマと旧いプログラマの認識の違いが露出していると思う。
>>146 そういうことを言いなさんな。みんな、サバイバル仲間なんだからさ。
FFとかドラクエのソース見たいなぁ
コンシューマゲームってC++で書かれてるの?
うん。
アーケードもC++だよ
Windows上のゲームもC++が多い。
結論から言うと、ゲームプログラミングにおけるタスクの定義は、
そのゲームプログラミング上必要な形で使用され定義されるで良いかな。
一意に決めることが無理と。
正直なところそのタスク議論とやらに参加してた奴はみんなアレな気もするが
実装テクの1つということで…。
>>153 なんでそこまでタスクがいいのかとw
すでにタスクじゃねぇのにタスクタスクうるせーってのw
>>156 単に言いやすいだけだろ。言いたくないやつは言うな。
漏れは彼女に「愛している」て言うのと一緒だ。
ギャラクシアン時代のテクニックをいまだにありがたがっている連中がいるのは笑える。
>>158 藻前の中は何も成長が無いのだな。 あ・わ・れ・よ。
ギャラクシアン時代のテクニックが今どのあたりで駆使されてるのかが気になる
HL2, OO, taskと今スレは上々の立ち上がりですな。
たんにナムコがやってるから凄いことだろうってことで俺もやりたいってだけでしょ。
有名人がマックつかってるから俺もマック買うってのと同じレベル
ていうかごく普通に洗練された当たり前の実装テクだと思うんだが。
いまの時代にわざわざそのままを使うほどのものかは別にして。
有難がるもへったくれも、普通だろ。
タスクって、コールバックとかと違うの?
タスク -> ワーカースレッド
タスク -> メソッドコールスタック
タスク -> ゲームシステムレベルでの処理の最小単位
タスク -> ○○輔って名前の奴がいつだったか同級生でいたなぁ
話題になっているゲームタスクの代替としては(色々あるだろうけど)どんな実装があるの?
つか、オープンソースになってて参考になりそうな
ゲームタスクのソースってないかな
タスク管理をC++でシャープにまとめてる
サンプルだせよ
172 :
仕様書無しさん:04/11/24 11:08:46
答 え は 君 た ち の 胸 の 奥 に あ る
>>171 LINUXのソースでも読め。シャープかはしらん。
ゲームプログラムなら、ゲームおきにあるから一意には無いと言っとろうが!
オブジェクトがわらわら出てくるようなアクションゲームやシューティングを
作ってたら、普通にタスクシステムに行き着かないか
漏れは上手いシステムを考案したぞと思ったら既に何十年も前から実現されてたわけだが
単にタスクという呼び方が嫌なら
stateパターン
strategyパターン
flyweightパターン
あたりで説明すればおkでわ?
単にタスクという呼び方が嫌なら
クラス
あたりで説明すればおkでわ?
クラスは異質すぎるぞ、OOから文句が山ほど出てくる。
所で、このスレにタスクを有りがたがってる香具師はいるのか?
>>178 お前の言うタスクがなんなのかわからんと何とも言えんだろうに
さてこのへんで、まずは「タスクとは何か」を厳密に規定するところから議論を始めようじゃないか。
さてこのへんで、まずは「
>>180は健忘症か」を厳密に規定するところから議論を始めようじゃないか。
あーうるせーw
タスクやデザインパターンなんて使ってねぇよ。
逆に聞くけど、タスクやデザインパターン使わないで
一辺でもゲーム作って見たの?
俺、ゲーム会社もう3つ目(業界8年目)になるけど、
タスクとかデザパタとかって言葉、現場できいたことないんだよね。
ネットのソース公開ゲームとかではよくみるっちゃあみるけど(でもほとんどSTGw)
不安定な実装だなぁって思うよ。
これ、普通に動いてるうちはいいけどバグったらどうしようもないね。
一番複雑になるオブジェクト同士の関連に関する解決策がはいってないしね。
なんでこんなの使うんだろ?
>>182 お前の言うタスクやデザインパターンがなんなのかわからんと何とも言えんだろうに
>>182は自分がタスクやデザインパターンが無くても
>>182の知識だけで
ゲームが作れるほど優秀だと言いたいだけだろ。ほっとけ。
>>184 ちがうな。
ぶっちゃけ、お前等の話てるもんを現場で見た事が無い。
>>185 経験豊富なプログラマーは、普通にプログラミングをしてても、デザインパターン
になっているもんなんだよ。デザインパターンはその知識を解かる様にまとめて
名前を付けただけさ。それも知らないのか?
とりあえず>182がどんなゲームを開発してきたか、
それがどんな環境で動くものであったかを聞こうじゃないか
>>187 大手だ大手(自慢)
1回だけ100万越えあるよ。
10万未満も1回だけあるけど。
もうね、俺の実力っていうか。
どのプロジェクトに入れたかっつー運だけだなw
>>188 そんな情報ではどんなゲームの開発かまったくわからん。
>>188 わかったわかった、藻前はコダーだな。上から落ちてきた仕様のプログラムを書くだけ。
わからないのも無理は無い。
そもそもデザインパターンは現場でよく使われている設計テクニックを
概念として理解しやすいように整理して命名したものだぞ。
と書こうと思ったらすでに書かれていた・・・
まぁ、なので普通に設計してたら大抵デザパタのいくつかは
使ってる。
おれんとこの現場じゃデザインパターンという言葉使ってる奴いないけど、
休み時間とかにデザインパターンの本読んでる奴は普通にいたな。
末席
普通、作ってるところでXXXデザインパターンとはほとんど言わないぞ。
教育時ぐらいは使うか。とにかくだ、
>>193は根本的にデザインパターンを
思い違いしている。そのまま好きなように生きて行けばいい。
つまりスレを総合すると言語に不自由な奴が多いということですね。
2ちゃんのお約束とはいえ、馬鹿がいるほど伸びるスレだな
なあ、中小ゲーム会社に転職して半年ぐらいたつんだけど
ずっと土祝祭日休みなし、終電帰りが殆どデフォなんだけど
これってゲ業界では普通なのか?
>>202 まあ、一年ずっとその調子ってときもあったことあるから
たまたまそういう時期に入ったのかもわからんよ。
2〜3年もその状態が続いてたらもう駄目だろ。その会社。
前いた会社で200日以上土日祝祭日完全に休みなしの経験したとかいう奴いたけどな。
中小系は基本的に人で足りないからしょっちゅうプロジェクト間の人の行き来があるから、
スケジュール前倒しで進めていって、土曜日に休みもらおうと思っても(←この辺で何か間違ってるかもしれない)
何かあれば「手の空いてる奴」ってことで引っ張られていくんだよな…
どうしてそんな悲惨なことになるのですか?
1.企画もしくはクライアントが馬鹿で、練りこみにグダグダ時間かけたり、途中で仕様が変わったりするから
2.そもそも最初の納期見積もりが間違ってる
3.人手が足りない
4.会社としては使える人間遊ばせておく余裕がないから、手が空き次第、別プロジェクトへ放り込まれるから
タスクシステムってコンテナにクラス突っ込んでぐるぐる回すのと何が違うん?
ループの処理がないぶんタスクシステムのほうが若干軽いのはわかるんやけど一緒やろ?
一緒、関数ポインタが書き換えれんとかのたまう阿呆がいるが
んなもんメンバ関数ポインタをもう一段噛ませば同じやし
>>206 追加してくれ。
5.プログラマが疲弊しているので遅刻の常習犯。
会社に来ても午後まではボーっと2chで時間を潰し、夕方からやっと手を動かし始める。
夜中までそのまま仕事して終電で帰るので、次の日は眠くて起きられない。で、また遅刻の繰り返し
で、プロジェクトが遅れると。
6.そういう勤務が普通なので周りのモチベーションも下がりまくり、
「ちょっとぐらい遅れててもいいや」的考え方が蔓延する。
耳が痛い…
さらにこんなんもある
7. 勤務がしんどいから転職を考え、そのネタを仕込む為に勤務時間にせっせと内職するようになる。
8.なんか最近チンコがやたらとカユイ。
9.一部を除いてほとんどの人が人生を悲観してる
10.マンコは臭いほうが好きだ
>206>209
当たってんなー
特にうちだと、人が足りないって事で進行中のプロジェクトから
人を回したりするもんだから、初期と末期だと一部以外は一新って事もあるし
で、俺は5番そのもの… orz
遅刻は…あまり無いと思いたい
>>207 > ループの処理がないぶんタスクシステムのほうが若干軽いのはわかるんやけど
軽いっつーてもタスク1つあたりせいぜい数〜数十ステート、
ギャラクシアン時代の8bitハードならともかく、今なら完全に問題外の差じゃろう。
まあ、少なくとも俺は、Cマガに載ってたような仕掛けをそのまま使ってくるヤツがいたら
どういう考えでそうしたのか小一時間問い詰めるからそのつもりで。
C++で自然に組んでくるやつのほうがよほど心証がいい。
Cmaga読んでなんだけどそのライターって何者なの?
やはりループだと柔軟性ではタスク(処理の線形リスト)に負けてると思った。
ループで何か特別なことをやろうとするとすぐコードが汚くなる気がする。
タスクならもとから構造なんてないに等しいからなあ。
タスクってことは、
scenestart(){
task.add(titledraw);
task.add(menudraw);
task.add(input);
task.add(syncwait);
}
scenemain(){
while(loop()) task.execute();
}
sceneend(){
task.releaceall();
}
こんなかんじか?
たしかにメインはすっきりするけどなぁ…
ぶっちゃけ、ポインタしらんでもいける。
>Cマガに載ってたような
これってどういうの?
Cマガなんかよまねーっつの
チェーンリストに処理タスクをつなぐ方法だと、
メインループに手を入れなくても個別の処理タスクを
追加できるからエンバグを抑えることができる・・って
理由と考察。
>>218 そのかわりタスク間の依存関係に注意しないとならん。
安定で堅牢に動作させるためには、ある程度抽象化した通信層が必要になる。
ゲームプログラム的には、その層が厚すぎると「まだるっこし杉」だったり
「処理オーバーヘッドでか杉(てほどじゃないけどもう少しダイエットしたいの)」とかだったりで
設計にバランス感覚の求められる部分とかになることもあるかもしれん。
実際には言うほど難しいもんじゃないし、言うほど重たい代物にもならないのが普通だと思うけど。
>>215 自覚してるならせめて深夜か早朝にレスしてくれ…
見てて哀れだorz
>>225 北米産のゲームスクリプトやゲームエンジンのサンプルによくあるタイプのゲームだよね。
タスクシステムを作る人ってなんでコンテナを使わないんですか?
>>227 仮に作るとしてもコンテナなんてまだるこしいのは使わん。
コンテナって何の用語ですかと聞いたら叩かれますか?
このスレでオープンソースをやったらどんなソフトが出来るんだろう
オープンソースって呼ぶより、単にソース公開即終了になりそうな悪寒
遅刻しても評価とか下がったりしないのか?
C++は使えないと言ったら叩かれますか?
使えない理由を述べよ。
今時C++が出来ない人間ってなんなの?って感じ。もう袋叩き。
やったことが無いから使えないのならともかく一通り勉強してまだ使えないのは問題。
ちょっと待て
C++が使えないってことはゲーム系の人じゃないのでは?
WEB系かCOBOL系か、VBも有る。
しかしだ、どの系をやっててもC++ぐらい余裕でやらないと先が無いと思うぞ。
(年寄りのCOBOL系は除く)
A. 日曜プログラマなうえにMac使いだから
Ans. 携帯ゲームプログラマだから。
JavaとPHPなら分かるんだよぅ・・・orz
死んで詫びろ
?
?
誤爆スマソ
ゲーム系でもメインにはC++使わんって奴は多い希ガス
いや、すげえ困りもんなんだけどね
今更こ汚いCのソース読まされてもみたいな
C++ならソースは綺麗なんかー!!(AA略
まあ、あれだ。年末は抜けた。だからここにもこられた。だれか俺を誉めてくれ。
>>251 忙しいのにここに常駐しる香具師に比べれば賞賛に値する
253 :
仕様書無しさん:04/11/26 14:40:00
>>251 乙。でもさぁ、他からひっぱられない?
早く終わらせても、作業時間は変わらないんだよね。
4、6と似てるけど、
頑張って早く終わらせても報われないってのがあるな。
>>254 まぁ、クリティカルパス上にいる奴は後れる事はあっても早まる事は絶対にないからな
そして、そこに来る奴って大体決まっているし
256 :
仕様書無しさん:04/11/26 17:19:36
>>253 プログラマーの方々おつかれさま。
私がプログラマーをやめて10年くらい経ちましたが、
労働条件は多少は良くなったんですか?
私の時代には、納期前は週100時間労働は当たり前でしたが
現在もあまり変わってないのですか?
何となく気になったモノで...。
あー、256ゲトしそこなったorz
なんで職業プログラマってそんなに大変なの?
というか、なんでいつまでたっても改善されないの?
>>257はめでたく−1をGETしたではないか。(おめ
漢ッスね
>>257 何処も改善したいと思っているのが本音なのだろうが、なかなか難しい。
作業量が定量的に判断できないのが一番の問題かな。
三大長時間労働職
プログラマ
量販店
トラック運転手
こうして並べてみるとプログラマって迷惑かける相手が素人じゃないって事だけが救いだな。
計算間違えてもコンピュータに怒られるだけだし居眠りしても死ぬのは自分だしな。
死ぬのかよw
ぼうや…プログラマってのは男が命をかけられる数少ない職業なんだよ
会社が利益と社員の命を天秤にかけてるわけですね
正確に言うと、利益より過労死で死んだ方会社にはマイナスなわけだが。
過労死じゃなくて、「自分の才能に悲観して自殺したんですよ彼は」と言われて終わる罠
「プログラマじゃなくてコーダだろ」
コーダさんはかわいそうだったね
また、分けの分らない香具師が・・・・
「休みたければ時間内に終わらせろよ」
ゲームコーダっていう言葉はあるのですか?
>>272 俺「やた!終わった!帰るよ!」
糞「まてよ!」
俺「なんだよ、動作確認はそっちの仕事でしょ?」
糞「また、バグってたらどうするのよ?」
俺「はぁ?バグレポート出しとけよ。後で直すよ。
だいたい来週でいいじゃん。なんで今日直そうとするの?
いきなり変な仕様変更するからバグるんじゃん。
あと、俺の範囲外の部分もあやしいから、多分、休暇中の○○君とも
話合わないと直らないよ。今回俺がいじった部分だってトリアエズ動くようにしたってだけだかんね。
つまり、○○君の休暇が終わる三日後ってことですよ。」
糞「それじゃ、期限(俺の)に間に合わない。」
俺「そりゃそうだろう、仕様変更したんだから。」
糞「それじゃ、元に戻してよ。」
俺「(なにいってんだこの馬鹿w)それも無理でしょ○○君いないんだから」
糞「それじゃ、期限(俺の)に間に合わない。」
俺「それさっき聞いたよ。」
以下ループw
つまりプログラマにはバカが多いってこと?
つーかバカな同僚の被害を受けやすいってことか
>>274 俺「やた!終わった!帰るよ!」
糞「まてよ!」
俺「(無視)お疲れさま〜」
相手が糞野郎とわかってるのなら、普通はこうだろw
>>273 名刺に入れかけた。ウケ取ろうと思って。
額面どおりに取られるのがオチだと思って即ヤメにしたが。
元のままのリビジョン渡せばいいじゃん
炎が噴出すエフェクトを作れって指示があったのね
まぁ、見上げないとわからない場所だから、気合入れる必要もないなと思って
指示書も特にないから自分で適当に作ったのね
そしたら、そこのデザイン担当という人から猛抗議が入って、
じゃ、指示書出せといったら、ムービーと写真数点が送られてきただけ
現実のムービーじゃ意味ないだろ…俺の作ったのが似てない訳じゃないし
その後、
「プログラムがおかしい、思っているものと違う」
「指示書に書いてある事を誤解か誤記しているという意味?」
「ベースプログラムがおかしいと思う」
「ベースプログラムの意味、わかってる?」
「とにかくどうにかして、良くないので」
良くないって言われてもなぁ…俺の価値観では悪いとは思わないし
どうにか、ってあんたが全然駄目といい始めたわけだし…
挙句の果てには、書いてある数値は表示して確かめてないと言い出すし…
どうにかしてくれ ('A`)
パラメータ操作する機能つけて満足いくまでいじらせてやれ('A`)
>>280 (279ではない)
いい案では有ると思うが。しかしだ!(強調したい)
このような奴に限って、ツールを2〜3時間使って、そのままで良いとのたまう事は間違いない。
「ツールを作った時間は何だったんだ!」と激しく思う。
C++でポインタの管理、どうしてますか?
1.スマートポインタテンプレート(boost or 自前)
2.COMインターフェース風に AddRef(), Release()
(デストラクタを隠して、クラスに自前で参照カウンタを管理する機能を付加など)
3.生ポインタ
4.その他(ハンドルの類)
自分はとりあえず生ポインタを使ってますが、
AがBを半永久的に参照(ポインタか参照)していて、Bが delete されたとき、
Aはそれに気づかず不正アクセスしてしまうような状況をどのように回避すべきでしょうか。
(そのような状況を回避するような設計方法など)
とくにタスクや GameObject, Actor などの類の、
複数のオブジェクトが相互参照(メッセージのやりとり)するような状況での
常套手段などをお聞かせください。
>>282 毎回、管理クラスにキーを突っ込んでオブジェクトを取ってくるか
オブジェクトをラップして生存チェックを追加するかが多いな
でも、俺自身やっぱりDOSの時代の印象があって、
deleteを頻繁に行う、って事があまりないんだよな
シーンの初めにまとめて確保して、開放する時はシーンの最後のみ、が多い
>>282 俺のところは、寿命管理は侵入型参照カウントを利用。
ただし外部に公開する場合にはポインタを生で公開せず、ポインタから生成した
整数値(ハンドル)を渡すようにしてる。
>>282 ぶっちゃけ、ポインタ(自体)に管理が必要になってしまうような構造自体がすでに駄目。
基本的にポインタってのは言語の機能であって設計ではない。
>AがBを半永久的に参照(ポインタか参照)していて、Bが delete されたとき、
>Aはそれに気づかず不正アクセスしてしまうような状況をどのように回避すべきでしょうか。
ポインタを使うということはこういう問題が発生してしまうということであって
この問題がおきるような設計にした時点ですでに設計ミスといって間違いない。
よく、DirectXでデバイス初期化してLPD3DDEVICEを各クラスで保持してて
Alt+TabされるとLPD3DDEVICEが無効化しててアボーンってなるプログラムを
みかけるけど、アレがポインタの一番まずい死に方w
何が駄目だったのかというとLPD3DDEVICEを保持するとかいう奇行が駄目だったわけよ。
似たようなことしてプログラム組んでない?
>>285 > ぶっちゃけ、ポインタ(自体)に管理が必要になってしまうような構造自体がすでに駄目。
> 基本的にポインタってのは言語の機能であって設計ではない。
> ポインタを使うということはこういう問題が発生してしまうということであって
> この問題がおきるような設計にした時点ですでに設計ミスといって間違いない。
そうならない良い設計方法を聞かせてくれませんか?
> よく、DirectXでデバイス初期化してLPD3DDEVICEを各クラスで保持してて
> Alt+TabされるとLPD3DDEVICEが無効化しててアボーンってなるプログラムを
> みかけるけど、アレがポインタの一番まずい死に方w
> 何が駄目だったのかというとLPD3DDEVICEを保持するとかいう奇行が駄目だったわけよ。
いや、LPD3DDEVICE 自体は機能として無効化するだけで、
そのポインタをアクセスしても問題ないです。(参照カウンタがあるので保持しても問題ないはず)
無効化したときにはどこかでリセットすればいいですし。(再作成した場合は問題あり)
> 似たようなことしてプログラム組んでない?
まさしく 282 の最後の文章にあることで悩んでいるので。
>>282 規模によって変わるんじゃないかね。今のコンシューマゲームは、
不正アクセスをバグと割り切って、コードロジックの見直しで対応できるぎりぎり
の規模だと思う。
ただ、これ以上ソフトの規模がふくれあがって、動作時のオブジェクトの
ライフサイクルが把握できない状態になれば、スマートポインタなりを
使わざるをえなくなってくる。
べたに書くほどスピードとコーディング効率があがり、間をかますほど安定性と
デバッグ効率があがるので、適応個所にもよるなぁ。
>>285に同意
基本的に消滅する可能性のあるポインタはコピーしない
仮にコピーしても、コピー先ポインタのライフサイクルが、
コピー元より長くなるような設計を避ける
もしくは、決められたポイントになるまでdeleteしない
これさえ守ってればそこそこいけない?
>よく、DirectXでデバイス初期化してLPD3DDEVICEを各クラスで保持してて
>Alt+TabされるとLPD3DDEVICEが無効化しててアボーンってなるプログラムを
>みかけるけど、アレがポインタの一番まずい死に方w
これって確かフォーカス失った時に、別のアプリがDXにアクセスするかして、
DXへのアクセス権がロストした時に、そのまま続行しようとするとなるんじゃなかったっけ?
DXGraphicsはフォーカス外れてWindowsになんか描画処理されるとVRAMとかロストするでしょ。
再取得するイベント用意すればいいのに、
昔ながらの一直線コードで書いてるから最初に初期化するだけで、
「フルスクリーンで動作させてるんだからフォーカス変えるんじゃねヴォケ!そんな真似する奴の事なんか知らんわ!」
って発想でなぜかWindowモード用とFullScreen用二つの実行ファイルがある同人ゲームを見たことがあるなぁ。
ぶっちゃけDX1からずっと見てる者としては、DX開発チームの奴をグーで張っ倒したくなるのは俺だけですか?
仕様変更云々じゃなくて、「公開するんだったら全部公開しろ! 隠すんなら責任もって処理しろ!」って言いたいトコたくさんあるんだが。
>>282 まずポインタ参照で相互操作なんて処理はさせない。
ハンドル(ID)使って外部で処理。
どうしても必要ならもう一個上位のクラス作って管理させるか。
そもそも実行時に消滅する可能性のあるポインタへのアクセスはよろしくないだろう。
消滅プロセスの時になんか処理するような設計しちゃだめなんじゃないかな?
>>285 それを設計レベルで回避するのはいまどきじゃないよ
設計が関わってくると変更が難しくなる、ポインタの実装で回避できるので実装で回避すべき。
そうしないと、仕様変更の激しい開発ではボロボロになってしまうよ。
>よく、DirectXでデバイス初期化してLPD3DDEVICEを各クラスで保持してて
>Alt+TabされるとLPD3DDEVICEが無効化しててアボーンってなるプログラムを
>みかけるけど、アレがポインタの一番まずい死に方w
>何が駄目だったのかというとLPD3DDEVICEを保持するとかいう奇行が駄目だったわけよ。
>似たようなことしてプログラム組んでない?
アホ発言過ぎてワリタw
LPD3DDEVICEを保持しないって、まさか使うときにいちいち再取得するのか?
LPD3DDEVICEが無効化する可能性って、極めて致命的なエラー出るような状況でないとありえなくないか?
もしかしてD3DX使いまくりメンなのかな?
Alt+Tabされた時に復活させりゃ良いだけの話だと思うが・・・
294 :
仕様書無しさん:04/11/27 20:50:06
上げ足取りしか出来ないのかよ(w
で、ドラクエは買った?
今回はちょっとやってみたい衝動に駆られたが買わなかった。
揚げ足とられたくなかったらアホなこというなよ
良い設計って難しいよね。
C++の高度な機能やSTL/Boostを駆使した設計が良いとは限らない。
なぜなら使う側のプログラマの理解が追いつかないから。
理解が曖昧なまま使うと余計なバグを生みやすくなるし、学習コストもかかる。
結局ハンドルで抽象化した複雑なライブラリより、関数一発で値が取ってこれる設計が好まれるわけよ。
それを設計の問題とはいわないw
>>292 Alt+Tabや解像度変更で無効化は簡単におこりますが何か?
>>286 >いや、LPD3DDEVICE 自体は機能として無効化するだけで、
>そのポインタをアクセスしても問題ないです
そういうプログラム組んでると伸びないよ。
「そのポインタをアクセスしても問題ないです」とか言ってるけど、
これは「プログラムは落ちないです」って言ってるようにしか聞こえないんだけど。
実際、その無効化したポインタをアクセスしたときにアクセスしたクラスの動作はどうしてるの?
アクセスしたクラスにはLPD3DDEVICEが無効化されたときにする動作を定義してあるの?
これはさ、何処でも起きる問題なんだよ。
例えばホーミングミサイルなんか作ってターゲットをポインタで保持してて、
敵の存在の有無をポインタの無効化で判断してるような設計でしょ?
>>298 > なぜなら使う側のプログラマの理解が追いつかないから。
底辺に合わせていたら、先がありませんぜ。教育しましょう。
>>302 高所に合わせすぎたらコストがかかるからバランスを考えましょう、という意味だ
>>301 デバイス(あるいはハンドル)が無効になるのと、ポインタが無効になるのは
全く別の話だと思うが。
後者だと不正なメモリアクセスが発生してプログラムが死ぬ可能性があるが、
前者だと想定通りのエラー処理をしておしまい。
ただまあ、逆に言えば寿命の保証さえクラスのコンストラクト順ででもなんでも
保証されてりゃ一向に構わないわけでもあるわけで、あんま拘泥しても
大して益のある話じゃない。
スタックで済ませられるところはスタックで書く様にする程度のことで、
上の生ポインタとその管理寿命云々の話は、少なくとも問題の顕在化は
ほとんど避けることができてしまう。
SmartPtrの類も使ってりゃいいってもんでもなく、今度はリソースが残り続けて
メモリたんねえよ処分のタイミングどうしましょみたいな間抜けな事態招く
素敵なプログラムはいくらでも書き得るわけだし。
最近のHDD搭載ゲームプログラム的には美味しいネタとしては、この手の関節参照の手段として、
参照カウンタつきの配列インデクスを「ハンドラ」に固めて、リソースマネージャ
(シングルトン化しとく)に一々問い合わせに行く方法がある。
これの美味しいところは、テクスチャマネージャの状態さえ丸々復元可能
(管理IDの何番目に何のテクスチャが入ってるか控えておく)になってれば、
テクスチャハンドラ自体は例え再起動なりなんなりでメモリ内容変わっても
変わらず復元可能なこと。
FPSみたいに、死亡〜即復活みたいなスナップショット型のセーブデータ形式
考えたりする時には常套の古典的手法。
アホみたいに単純だけど利益は絶大。
ゲームキャラの座標とかHPとか保存するのと同じように、構造体丸々控えるだけで
シーンで何のテクスチャ使ってんのかとかまで復元できるようになる、
つまりまあ、適材適所で色々考えて使えや、でもあんまし無駄にこだわりすぎても
窮屈なだけですよー、てとこだろか。
つまりまとめるとDirectX作った奴は屑、と
俺はクズだといいたいがな。
いつだったかのバージョンでは定数だか構造体だか誤字のままリリースされてたし…
>>306 いや、そうじゃないだろ。
まとめると、ポインタ管理の実装にはいろんな手段があって、それぞれに目的や前提条件も違うので
ポインタの管理はこうすべきなんですよね??などと聞いてもしょうがないし、この手法がまずいよなんてことも言えない。
つまり、ぶっちゃけて言うと
ま ぁ 、 好 き に や れ や
てことかとw。
いろいろ参考になりました。(LPD3DDEVICEは置いといて)
結局適材適所ってことになりそうなんで、改めて具体的に聞かせてください。
同系統のオブジェクトの集まりの中にAとBがあり、そのどちらもいつ死ぬかわからないとする。
(したがって生ポインタやリファレンスを直接保持することはできない)
このときAがBを参照する必要がある場合(その逆や相互参照も考えられる)、
不正アクセスを起こさないためにどのような手法が考えられるか?
(寿命がわかっていて順番付けできるのであればこのような心配は無いはず)
1.ハンドル(数値、クラスなど)からポインタ(NULL可)に変換し、
必要であればキャストして使用する。ハンドルは唯一無二とする。
管理できる数に制限がある?
2.仲介クラスのようなものを用意し、参照元と参照先を管理させる。
参照元は自分と参照先を仲介クラスに登録し、返されたIDを使って参照先のポインタを必要なときに取得する。
(結局ハンドルと一緒?)
仲介クラスも登録されたオブジェクトを不正アクセスしないように注意する必要があり、
登録されたオブジェクトは仲介クラスに自分が死ぬことを伝えなければならないなど面倒。
3.参照カウンタを導入する。
相互参照している場合、解放されない事態に陥る。
一箇所でも解放し忘れると芋づる式に解放されず、管理が難しい。
4.オブジェクトの集まりから、参照先を逐一取得する。
オブジェクト一個ごとに固有のID付けが必要、条件検索ができるようにする。
基本的に毎フレーム取得(検索)する必要があるのでコストがかかるが、
数が少なければ気にするほどでもない?
自分が思いつくのはこんなところで、1か4あたりが有効だと思いますが、
ほかにはどのような手法があるでしょうか?
>>310 検索のコストは std::hash_map とか使っておけば、あまり気にしなくて OK。
2, 4 いずれにせよ、オブジェクト死んだときに管理クラス側に通知して、
対応する ハンドル (ID) を無効化する手続きが必要になる。やりかたとして
1. オブジェクトから管理クラス側のメソッドを呼び出して無効化する
2. 管理クラス側からオブジェクトに問い合わせて、無効になっているか
確認する
と二通り考えられる。
インターフェースと実装の分離を徹底すると、同一のオブジェクトを複数の
管理クラスに登録する機会が出てくるので、俺は後者にしてる。寿命管理は
参照カウントをオブジェクト側に持たせて、管理クラス側から削除するときに
参照カウントを減らす (Win32 の COM と同じ方式)
>>310 >同系統のオブジェクトの集まりの中にAとBがあり、そのどちらもいつ死ぬかわからないとする。
そもそもこの前提がありえない。
解決策としては1か2になるが、文章を読む限りド級の馬鹿のようなのでツッコミはしないw
もはや一生てめぇ1人で悩んでろよアフォっつった感じw
オブジェクトの生存期間はプログラムを動かす前(組む前)に必ず決まる。
片方が消失して片方がその消失した事実を知らないなんて構造は設計が間違ってる。
ていうか、設計でこれを解決しないで何を設計しとるのかと。
ごちゃごちゃ悩む前にLPD3DDEVICEをグローバル変数やらポインタ保持しないで管理してみろよ。
Alt+Tab押しても平気なようによw
>>310 だから好きにやれよ。
>不正アクセスを起こさないためにどのような手法が考えられるか?
"そのどちらもいつ死ぬかわからないように"するな。
そんなやつにアクセスさせるな。
答えなんか基本的に一つしか出せないだろう。
どこが具体的? そんな抽象的な説明じゃなんともいえないと思うが。
>>310 おれっち流の解は、A B を強参照でコンテナに入れておく。
A から B または B から A は弱参照で参照。
オブジェクトの破壊はコンテナ中の強参照をnullクリアして破壊、
もしくはデストラクタで強参照をクリア
ってな感じかな?
>>312 そーんな事いってるとどんどんロートル化すんよ〜
知る必要が発生したときに知る事ができるというのは楽なんです。
組む前に決めると完成する前に疲れ果ててしまいます。
はいはい、こまりましたね〜
リリースが少ないんだったら、全検索して自分の参照を切る、ってのもありだし、
自分が複数から参照される事がないんだったら双方向にして、
自分自身が消滅する前に消滅通知を出すとか・・・
いずれにせよ、そんなもん組めよ、四の五の言わずに
>>314が言うほど駄目とは思わないが、
そのまえにいつ死ぬかわからないのにAからBを直接参照する可能性がある設計自体に問題があるということを310は理解しろな。
前提条件が駄目なことを要求してるから、回答も駄目な物になるのは仕方ないとは思う。
元々の要求仕様がどんな物かによるだろうが。
大元の設計がそのような現象を発生しないように設計するに賛成。
試しに上の仕様を出してみないか?
相互参照の内容により1〜4も有りえるし違う解決策も有ると思う。
こんなくだらない事を設計でやるなんて……
悲しくなってきます
>>318 いつ死ぬか分からんというのは設計としてダメだろう、というのは同意。
でも、同一インター内で死ぬことは確定しているんだが、その順序を
確定したくない(仕様変更が入ったときに面倒なことになるのが目に
見えてるから)ってのはあるな。
俺の場合、ホントに汎用的なものなら抽象度が高いメッセージ通信
システムを作り、必ずそれを介して情報をやりとりするように書くが、
特殊なモノだとスマートポインタでよろしくやって終わりってことも多い。
>>321 逆だよぉ、特殊なものはスマートポインタ使わんほうがいいよ
どうでもいいもんに使っとけぇ
単に親子関係で済むことを、わざわざ同列に扱おうとしてはまってる気がしないでもない。
>>311 いいヒントになりました。
「いつ死ぬかわからない」という言い方が誤解を招いたかもしれません。
→どのタイミングでオブジェクトが無効化するのかが不定
オブジェクトが直接deleteされるのではなく、一旦無効化フラグを立て、
オブジェクト管理クラスでそのフラグが立ったオブジェクトを
毎フレーム一括deleteするという仕様です。
なので、実際には無効化するきっかけが必ずどこかにあるので、
まったく不明ということはないです。
>>324 その答えと、相互参照している場合の不正アクセス対策とどう関係が有るか分らないな。
一体何が聞きたかったのだろう?それともあんたバカな展開か。w
結局さ、判定入れる場所は2箇所しかないでしょ
・オブジェクトが死んだ瞬間に判定、自分自身を保持しているクラスに終了通知
・オブジェクトを使う瞬間に判定、そのポインタが有効かチェック
あとは、設計や処理速度、メモリと相談だろ
>>325 答え?
その文章は単に「いつ死ぬかわからない」に対しての説明であって、
「相互参照している場合の不正アクセス対策」とは直接関係ないですよ。
>>326 そうでしょうね。
結局、考え方はみんな同じで、実装方法が違うだけなんでしょうな。
間接的にアクセスするってことで。
旅行にいく目的地は決まっていて、
車で行くか電車で行くか飛行機で行くか船で行くか、どのルートがいいんですか?
と聞いたわりには、そのレスなのか
>>328 ルートなんか聞いてないし、どのルートが最善なのかなんで聞いてない。
>282 をよく読め。
だから好きにやれよw
>>327 326の最初の方法は直接アクセスしているわけだが
よく見たらこのおばかちゃんのネタで50レス進んだんでつね
>>331 間接的にアクセスしているともとれるよ。
>>332 進んでよかったな。
もうこれで終いにするよ。
まぁある程度回避策はわかってるんだけど、
みんなどんな風にやってるか聞きたかったわけ。
ただそれだけ。
別に議論する気も無いし、手法に優劣つける気はさらさらない。
出てきた使えそうな情報をチョイスしていくだけ。
まともに答えてくれた人ありがとね。参考になったよ。
変なイチャモンつけてくる奴は不思議だよなぁw
まったく質問の意図がわかってない。
まぁゲームプログラマーやってる奴は全員「俺の人生はこうなるはずではなかった」
っていう思いをもっているからこういう場所で発散する必要があるんだよ。
ツレタ
しかしほんと真面目に答えてる人がいるならすげぇと思うなぁ。
利根川先生のAAキボン
大 人 は 質 問 に 何 一 つ 答 え た り し な い
俺的には上のレス見てみんな上っ面しか答えてないように見えるが、
>>334には答えになったらしい。
まあABが相互参照していて、どちらか片方が死ぬなんていうシチュエーションはゲームならよくある。
敵A,敵Bが相互に相手を見ながら動いていて、片方がプレイヤーに殺されるとかね。
まあ、そういう時は死亡通知期間を設けることが多い気がする。
つまりAが死んだ後、deleteは次の次のフレームの先頭でマネージャーがする。
1フレーム間はBはAが死んだことを確実に知ることができる。
まあハンドル使ってもいいんだけど、手間とメモリとオーバーヘッドがかかるからね。
タスクシステムだと相互参照解決できねーな
>>339 >まあABが相互参照していて、どちらか片方が死ぬなんていうシチュエーションはゲームならよくある。
>敵A,敵Bが相互に相手を見ながら動いていて、片方がプレイヤーに殺されるとかね。
そんな簡単な処理に相互参照なんかするのか、頭悪いな。
するだろ。
だが片方が居なくても差し支えないように作る、それだけだ。
>>341 簡単な例を上げただけ。
実際はもっと複雑に絡み合う。
それがゲームプログラミングというもの。
>>342>>343 >実際はもっと複雑に絡み合う。
そんな事は、藻前らの考える相互参照の方がよほど複雑になるんだがな。
そんな設計しか出来ないから、あんな質問があるんだろ。
マジ勝手に悩め。
>>344 はいはい。
本当にちゃんとしたゲーム作ったことある人?
あーんなゲームや、こーんなゲームもそんな設計になってるんだけどね(ワラ
まあ理想論だけじゃゲームは作れんってこと。
今までの話を総合すると。
・シューティングゲームで
・単純タスクシステムで総てをやろうとして。
・敵機が相互に動いてるので、相互参照してコントロールしようとして。
・泥沼にはまっている素人。
以上!
>>344 第三者だが、複雑になんかならんよ
ちょこっとスマートポインタの知識があれば考える必要すらない本当にばかばかしい話。
多分はまっているのはこういった細かい所まで設計に凝ろうする貴方のほう。
ちなみに昔自分もそんな風に考えていた頃があったので、なんとも見てて痛い気分。
>>346 そういう時は、複数の敵を見て制御するコントロールタスクを作ると良いよ。
C++を覚えたてのころは、設計に凝りたい時期って誰にでもあるよね。
敵はクラスで仮想関数にして、状態ごとにステートクラスを作って、大量にマネージャー作ってとか。
ま、結局ガチガチに固めると仕様変更に直面するたびに破綻していく現実に直面するわけだけど。
なんで、洗練されたゲームほど基本部分はシンプルな設計になっていることが多いね。
まあ、一度は通らなきゃらなない道だとは思う。
バカに付ける薬は無いな。
と、井の中で申しております。
>>350 > ま、結局ガチガチに固めると仕様変更に直面するたびに破綻していく現実に直面するわけだけど。
がちがちに固めないために、インターフェースと実装を分離して
それぞれにインターフェースを管理するマネージャクラス作る
のだと思うが。
何でもかんでも単一のマネージャクラスに突っ込むと、それこそ
後で辛くなる。
……って、そういう話じゃないのかなぁ。みんな書いてることが
断片的なんで、何を話してるのか良く分からんが。
なんかプロジェクト移動して
前のプロジェクトとオブジェクトの意味を全く違う意味で使ってる状態に似ているな
オマエの設計が悪い、と決め付けるヤツはすごいな。
なんで自分が間違ってるのかもしれない、とは露ほども思わないの?
今までの自分の知識は絶対、とか思わない方がいいよ。
年取ると思考が硬直化するもんだけど、そのままじゃ置いてかれるよ。
設計や言語仕様に五月蝿い奴に限って、生産性低いんだよなぁ。
C++知らない人が多いからって理由で未だC言語でやってるチームもあるけど、
それも一概には誤った選択とは言えないところがまた。
C++を導入したがいいが、収拾つかなくなって失敗したプロジェクトとかあるし。
まあ、メンテナンスなんてしねーし、移植は外注に投げるし、
設計の美学なんかより、動いてなんぼってぐらいが実はうまくいったりする。
>>355 同意
物事は、柔軟に考えなくては。。。
トレンドだからといって最新の技術ばかり追って、
どれも身になっていない奴がうちの社内にいる。
そういう奴に限って、
「○○さん!そんな手法は古いっすよ」なんて吐きやがる。
うんじゃ、その新しい手法使って書いて見れといいたい
以前、PS1の仕事を下請けに出した事があるのだが、
その会社は、そのプロジェクトで C++つかっていて、
new、delete 使いまくりだった・・・
てっきり、独自にメモリ管理の処理を作成したのかと思って
いたのだが、仕様の変更や、追加をお願いする度に、
「メモリ足りないのでこれ以上仕様追加できません」
なんて言われてさ、
そんなまだ開発の序盤じゃん!何で?って思っていたのさ。
で、そのプロジェクトが1年延び、2年延び
(延びたのは開発会社だけの責任ではないのだが・・・)、
いよいよクライアントから怒られちゃって、
あと数ヶ月で完成させないと、賠償問題ですよ
なんていわれて。。。
で、そのプロジェクトをうちの会社で引き受けたのだが、
new、delete は、虫食いの事も考えず使っていようで、
ガックリきたよ・・・
そりゃ、メモリ足りないはずだよって・・・
C++の問題じゃないじゃん
>>359 上の文章読んで、なんでC++の問題だって思うんだ??
使えもしない新技術に飛びつきたがるヘボPGがいたって話だろ?
>>360 C++じゃなくてC言語使ってても同じ結果になるだろ…
なんかもう痛すぎ
>C++を導入したがいいが、収拾つかなくなって失敗したプロジェクト
WindowsNTのことかぁッッッッッッッッ!!!
365 :
仕様書無しさん:04/11/29 00:45:38
>>362 昔ながらに固定長配列+関数ポインタでやってりゃ大丈夫っしょ。
仮想関数使ったはよいが、operator newをオーバーロードするのを知らなかったとかそんな落ちでしょうが。
358 ですが、
仕事中に書いていたのもで、あまり考えず書いてしまいました。
詳しく書くと、関係した方々(とクライアント)にばれてしまうので
かけないのですが・・・
もともと、そこの開発会社は、ウィンドウズしかやった事無い会社で、
あまり、メモリとかの事を考えず作っていたようで、引継ぎをした
ソースはそりゃ物凄いものでした・・・
1から作り直しました。
っていうか、スレ違いな話に・・・・
まぁ、そこで、プログラマ諸氏に質問!!
というわけで、実は、この2年以上かかったプロジェクト
実は4ヶ月で作り直したのは、ゲームを買ってくれたお客様には
内緒なんですが、そんな感じの体験をした方いますか?
いるかいないかつったら、いるよ、ここに。
4年かかって作ったものを手渡されて半年でゼロから作り直した香具師らの一人が。
まあなんつーか、最初ッから作るものわかってて迷走する余地がなければ
実際の作業量はそんなもんなんじゃねーの?って感じで面白かった。
1年かけて2Dで作ってたマップを3ヶ月で3Dに組み直したことはある。
つっても死んでたのはデザイナの方だったがな。
358 です
>>368 確かに面白くはあったけどね・・・
迷走の余地がなかったから、
俺を含めたプログラマ達は、コード
打ちマシーンと化してましたね・・・
あれで、かなりスキルがあがったと思うけど、
みんな燃え尽きました・・・
ドラクエ8ってプログラム的にはすごいんじゃないの?
ダンジョン内なら戦闘で読み込みまったく感じないし
メッセージスピードが変えられないのも理由があるんだろうなぁ
こういう話しが知りたいけど、ゲーム雑誌とかじゃ絶対に載らないよね
企業秘密とかかな
やっぱプログラマーの人ってゲーム遊んでても、ここどうやってんだ?
とか思ったりするんでしょうか
ストーリーとかより気になっちゃったりして
Professional Game Programmingとかって本でもだしゃいいのに。
まともな技術と文章力もった人材が日本にはいないだろうけどさ。
各社技術的蛸壺に引き篭もってて生産性が悪いったらありゃしない。
>>372 そりゃすごいけど。
部分部分をとってすごいだのどうやんだろうなどとは思わないな。
全体の構成やら、安定したシステムやら、ボリュームとか
すごいってのは総合的に出てくるもんだしゲームなんかやっても
勉強になんかならないよw
>>372 > ダンジョン内なら戦闘で読み込みまったく感じないし
シンボルエンカウントじゃないからねぇ。
あれは「敵と出会ったら読み込み開始」ではなく「読み込みが終わった
時点で戦闘開始」にしてる予感。
うちのPS2は初期型だから、動作音が戦闘開始の合図。
それよりも、戦闘終了から戻るときがどんくさいのですが、新しい型番ではさくさくなんでしょうか?
詳しくないのですが、あの遠くのものがやがて近くなるってマップはミップマップの延長に近いのでしょうか?
LPD3DDEVICEが、ポインタとして無効になってるのか、
デバイスが無効になっているのか、はっきりさせろ。
ポポロクロイス?
>>376 DQ8は会話ウィンドウが1フレ遅れて消えるのが気になる。
DQ8は、奥のキャラクタが突然現れるので違和感がある。
離れたところから見て「店に誰もいねえな」と思いながら
近づいたら突然キャラが出てきた。
LODしてないのかな。
プログラム的にはDQ8は「すごい!」ってとこはない。
よく作ったよなあ、と思うだけ。デバッグ苦労したんだろうなあ。
>>よく作ったよなあ、と思うだけ。デバッグ苦労したんだろうなあ。
んー。それは「すごい!」には当たらないの?
歴代のDQ総じて1、2くらいしか「すげぇ!」って思えるような要素無くない?
DQ8はやっぱあのグラフィックをそのまま3Dで作ったのに感動したな
ゼルダなんかは最初違和感ありまくりだったけど(で、慣れたけど)
DQはSSみてああ、DQだ、って感じの印象をそのまま保っているし
>>383 1、2に触れたときの手前の年齢と職業を求む。
HLは中身がない
DQは技術がない
喪前らどっちにしても褒めないのなw
開発期間があれだけ長いと技術的に遅れたものになるのは仕方ないだろう。
おまいら有名なデモと比べてるんだろうし
尖った技術的 (デモ系) には DQ はたいした事ないんだろうけど、
バックグラウンドで読み込んで読み込み終わったら敵とエンカウントとか
やってるのは (
>>375 が言っているのが正しければ) 技術的にすごい事だと
おもうけどねぇ。
より多くのポリゴン出すとかじゃなくて、そういうところに
気がついて作り込めるプログラマになりたいなぁ。私は。
>>372 ところで、一昔前のゲーム雑誌には結構「プログラムで
こんなところ苦労しました」みたいな話をしている
プログラマが記事になっていたような気がするんだけど
最近はそうでもないのかな。
大昔に雑誌に載った時にそのへんをうきうきと話そうとしたら
どうも、そんな空気では無かったので別の話をしていたけど…。
>>382 ゲームのデバッグは外注やボランティアの人の方が頑張ってるからなあ…
>>383 DQ の凄いところは、技術じゃないからなぁ。一つのことが片づくと
すぐ目の前にもう一つ片づきそうな課題が出てくる、ついつい手が
離せなくなってしまうイベントの配置とかバランスが素晴らしい。
でも俺なら 5 年も同じプロジェクトに関わりたくないが。
8の開発は実質3年ぐらいじゃね?
ドラクエなんて正直どうでもいいよ。
もっと綺麗なドラクエがみれると思ったら
予想の範囲内だし。
別にゲームでもなんでもそうだけど、考えた人が凄いのであって、
プログラム作った人なんでカスだろ。
誰でもいいんだよ。どうせ外注に出すだけだからな。
395 :
仕様書無しさん:04/11/29 22:57:07
じゃあゲームプログラマ的に凄いゲームって例えばどれ?
フランツーリスト
ドラクエのグラフィックって既存のゲームと同程度なの?
PS2のゲームって最近みてないけどレベルあがってるんだな。
一応、影もそれなりのがついてるし。
PS2はICO以降進化が止まってるな
ドラクエ8は輪郭のぼやけた影がバリバリ動いてるみたいだけどどうなってんの?
買った人教えておくれ。
へー、ソフトシャドウやってるんだ。
PS2のフィルレートに任せて半透明重ねまくりで書いてるわけじゃなくって?
>>399 そりゃ、技術的に頑張れば製品が差別化できる時代は終わったから。
見た目に関してはもはやプログラマより、デザイナさんのがんばりに
掛かってる。
まさにドカタ
>>400 ドラクエ8の影は、シャドウボリュームで影領域を算出した後、
ポストプロセスでブラー処理して輪郭をソフトにしている様子。
カメラ手前に来ると影がパキッと消えるし、真下に近い位置に落としているので、
ラバストなシャドウボリュームではなく単純に視錐台カリングっぽい。
階段に落ちる影を見て一瞬吐きそうになった。w
>>394 かくいう手前もPGじゃねーの?
プログラマなんてもともと縁の下の力持ち。日陰者。
コンピュータゲーム黎明期が異常だっただけ。
DQ8のフレームあたりポリゴン数はFFと比べて多少少ないのでは?
奥のキャラがおきなり登場するのもそうだが、店員との会話時の
キャラ配置が悪いと(奥まで視界が開いている状態)、文字描画が
遅くなる。
あるいは、あの絵柄を実現するために結構なポリゴン数が使われてるのかな。
情報学科の学生でこれから就職活動なんですが、コンピュータがすごい好きって感じではありません。
コンピュータがそんなに好きではない人がプログラマーになってもやっていけないでしょうか?
僕みたいな人がIT関係の仕事に就こうと思うと営業になってしまいますか?
教えてください。
>>408 その前に好きなものを教えてくれないか。
スカトロ
好きとか嫌いとか最初に言い出したのは誰なのかしら?
好きとか嫌いとかはいい。
う○こを食べるんだ。
大手のSEとかならなれるんじゃないの。
スカトロジストに?
>>408 好きでもないけどやってる奴なんて山ほどいるよ。
オタ的なくだらないこだわりがない分良い仕事する人もたくさんいる。
ただ、それとは関係なく大きいところに入ると故人の遺志が
無視されて営業に回されることもあるらしいね。
やっぱりただの七光りだけじゃ親が死んだらそれまでだよね
>>480 仕事として選ぶのならゲーム業界はやめといたほうがいい。
最初の職場は大事だよ。多かれ少なかれ、その職場の雰囲気に
染まってしまうからね。
預言者キター
予言してほしいのか?
だったら言ってやるが
あと5年もするとプログラマなんかよほど優秀な奴以外みんなリストラ
ソフトウェアクライシスはどこへ行った
>>419 5年じゃ無理だよ。藻前、IT業界の惨状を知らんだろ。
あと、10年以上はかかる。下手すると、もっと必要になる
とさえ言われているぐらいなんだが・・・
日本の場合、不況だ不況だなんて言われていても、
一般人が簡単に、パソコンや携帯電話が買える国だからな。
こんな国、他には無いぞ。
物体の衝突が関係するゲームやシミュレーションを作るとき
いわゆる「めり込み衝突」が厄介すぎて困っちゃう件について。
1)イベントドリブン方式:
衝突発生時間を計算してそこまで移動→衝突処理→残り時間まで繰り返す
(参照
http://www.se.cs.titech.ac.jp/~oda/tips/billiard.html#eventdriven)
2)時間巻き戻し方式:
めり込んだら時間を巻き戻す→時間刻みを小さくして再試行→
めり込まなくなったらそこまで移動→衝突処理→残り時間まで繰り返す
3)お気軽方式:
ループ終了時にめり込んでたら強制的に位置を補正→衝突処理
(ループ中の衝突は無視するので「すり抜け」が起こる)
衝突処理は漏れの手に負えない・・・orz
4.めり込まないくらい時間刻みを小さくする(or速さを小さくする)ってのは?
3
壁との衝突ならともかく、
相手も動いてると(そして反射すると)もはや・・・
>>423 優先順位を付けて適当に押し戻す程度で良いって。
厳密にはおかしな挙動になるんだが、十分にそれっぽい振る舞いには
なる。シミュレータ作ってるワケじゃないので、そこにこだわる暇と CPU
時間があるなら、他に回した方が良いぞ。
まぁ、物理エンジンを売りにしているゲームを作ってる場合は別だが……。
>>423 制限付バネ&ダンパー処理でだいたいなんとかなる。
個人的には1の方法かなぁとは思うんだけど、ビリヤードの初期状態見たく
まったく同時に複数の物体にぶつかった場合なんかの処理が面倒なので適当にやってる。
#とかいいつつ、1)のサイト見てみたけど・・・もしかして計算式の妄想だけで実装してないのかよ!!!!!
#Javaアプレットもあの程度だし、本当にあのアルゴリズムを実装できてるのかはなはだ疑問。
#つーか、球同士の判定なら適当計算でもそれっぽくできるんじゃ!こんなの参考にもなるか!ぼけぇ!!!!
>>423 適当な処理だったら、3とかでもいいと思うけど、
相手も自分もかなりな速度で移動していた場合、
いろいろと厄介だから、1が良いと思う。
どんなものを作っているか次第だな・・・
>>423 1は、平たく言えば
全物体の移動ベクトルの交点を求めて、
一番近いオブジェクトの交点にぶつかっている地点を採用して、
あとは、同じ事を全オブジェクトに対して行ってやるって感じでしょ。
一番下のリンク先ワロタ
>>429 つうか、お前がはなはだ疑問。
あのページの内容たいした処理じゃないよ。
4)軌跡交差方式
移動の軌跡を線分として、他物体の軌跡との交差を判定。
ループ中は等速運動で近似してるので交点がわかれば衝突時刻もわかる。
線分が短いときの扱いに難あり。
5)斥力方式
一定距離内の物体には距離の2乗に反比例する斥力が働く(静電気力の公式)。
斥力にもめげずにめり込んだ場合、距離が近いため斥力が非常に大きくなり、
ものすごい速度ですっ飛んでいく罠。
距離が物凄く短くなると浮動小数点の精度や計算誤差が大きく影響してきません?
みなさん、そのへんってどうやって処理してます?
>>429 >制限付バネ&ダンパー処理
詳細きぼんぬ
世界の果てとの衝突なら3で決まりですな。
問題は大きな速度で小さな物体と衝突するとき。
無限精度の計算機があれば4でFAなんだが・・・。
どんだけの、小さいもんと衝突させて来たのか聞きたい
>>438 移動速度の絶対値が物体の直径より大きければ余裕ですり抜けるべ
>>436 基本的にめりこみをゆるしつつ、めり込んだ分はバネの処理ではねかえす。
めり込み量が大きくなると吹っ飛ぶのでダンパーとして適当に摩擦係数をかけて抑制。
あとは動きを見ながら発生する力や速度の最大値とかに制限を加える。
いわゆる、テキトーな俺様物理計算処理でつ・・・orz
典型的かつ現実的だと思うがなあ。
利点はいらんエネルギーを与えさえしなければ最終的に動きが勝手に収束すること。
動きの破綻も少ないし、位置関係の解決もそれなりにまとまるしで極めてゲーム向きだと思う。
メインで使わなくても、賑やかしの背景オブジェクトの動きとかに適用するだけでも
画面の動きの現実感は随分増すしねえ。
>>440 「すり抜け」対策はどのようにしてるの?
>>442 めり込み量としては検出できているのだから、すり抜けはしないよ?
改めて良スレだと思った
>>439 移動ベクトルの交点を求めれば、すり抜けることは無いべ
>>443 442じゃないけど、どういうことかわからん。
バカな私にどうかご説明くだされ orz
>>444 土日に雰囲気が一変するがな(w
前々から思ってたんだが、スレが時々異常に伸びるときって、方法論を戦わせてるだけか、
厨房が妙な煽りをかまして粘着してるときのどっちかなんだが、その厨房側って
お休みの現役プログラマなのか、学生さんなのか、どっちなのか判断に苦しむものがあるんだよな。
いや、別にどっちでもいいんだけどさ。
>>446 そこで浮動小数点の精度が問題になる。
交点を求めたはいいが精度のせいで微妙に重なっていたりするので
超低速での衝突だとか、複数の物体同士が極めて近い位置にいる状態で
玉突き状態の衝突が発生すると、突然へんな方向に跳ね返ったり、めり込み始めたり・・・
結局、適当なところで衝突判定をやめたり、切り替えていかないとしょうがないような気が。
>>450 なるほどね・・・
そういう時は、限りなく0に近い値は0と見なすとか、
やってたな、オレ
>>448 まず衝突判定って物体の位置を比べるだけじゃだめで、移動をベクトルとして判定するんだけど、その部分はOKだよね?
物体AとBがあるとして、あるフレームでAがA1からA2へ動き、BがB1からB2へ動いたとする。
ベクトルA1->A2とベクトルB1->B2の交点を求め、交差してれば交点をCとする。
物体の移動ベクトルが交差している=めりこみが発生したってことにして
ベクトルC->A2がAのめり込み、C->B2がBのめり込み量になる。
んで、めり込み量に応じてテキトーに反発処理を行う。
・・・単純に言うとこういうことかと。
#すりぬけもめりこみとして処理する訳です。
実際には点、線分、面など相互に衝突判定を行う要があったり、
空間を区切って絞り込んだりと色々面倒なのでつが・・・
>>452 にゃるほど。ちゃんと交差の判定もするのね。ありが?ォ
ありがてん?
>>434 すまん。4では間に合わなかったよ。w
>>449 「ききたい」だから、まぁ、それもよしでは、とおもってみたり。
つーか、盛り上がっているのが2:30スレと大して(ry
性欲を持て余す
>>442 速度に上限を設ける。1 インターでコリジョンサイズより大きな移動を
するのを禁止。
いや、そんなもんだって。
>>458 今の世の中、それは現実的じゃないなぁー
っていうか、あんたいつの人?
SFCとかの時は、そんな事やってたけど。
あー、あのころが懐かしい
>>459 安心しる。携帯アプリは今でもそんなもんだ。
とかいいつつ最近機種だとついに浮動小数に対応してきやがった。
3D化&大容量化の波がこっちまで来るのか・・・
ヽ(`Д´)ノ 1カ月ジャ作レネェシ モト トレネェヨ! ウワァァン!
>>458 そのゲーム斜め方向には√2倍速く移動できそうだなw
>>461 大多数の2Dシューティングはそうだね。
物理に忠実か忠実でないかがゲームの面白さに結びつかないからね。
3Dになっても、擬似物理でも見た目面白ければいい。
>>463 な、ここまで計算式を複雑にしてしまうと(加速度とか摩擦とか)
バグったときやゲーム的にもっと細かい動きを付けたいときとか
できるのか疑問だよな。
>>464 そういう計算ってサブルーチン化して組み合わせて使うのが普通だろ?
「できるのか疑問」っていったいどういうコードの書き方してるんだ??
いや、まさかとはおもうけど・・・・・
Havokは「4+衝突とみなす範囲を広げる」ですね。
グラVのジャガイモごろごろとかはどうやってるんだろ。
場面によっては同時に何個もの岩同士がぶつかってるんだけど・・・
>>465 >サブルーチン化して組み合わせて使ったところで
違うよ。
そういう問題を言ってるわけじゃない。
その動きをしたまま、ちょっとアレンジを加えてくれと注文を付けられたときの
ことを言っている。理解できた?
>>464-465 このスレこういった曖昧なレスのまま罵り愛が始まると長くなるんだよな・・・
>>459 作ってるゲームによるでしょ。RPG とかバイオハザードのようなスローペースの
アクションなら(弾丸は別として)問題ない。
>>467 移動距離が小さければたいした問題はないと思われ。
すりぬけUzeeeeeee!!
衝突のテストに作ったプログラムがジャガイモごろごろっぽくなって楽しい
>>462 ここ数年ではバトルガレッガか、ヘタレ同人シューくらいしかねーぞ(w
斜めの方が早いとちょっと不自然に見えるぞ
俺は、真横3斜め2、減速時2斜め1って感じでやってた
>>468 正確に物理計算した結果に対して「アレンジしてくれ」とか
いわれた時点で拒否権を発動するのが正解w
>>477 物理正確さより面白さ優先の漏れん所では不可!
>>477 お前、融通きかないなぁー
うちの会社では、
そういうプログラマ干されてるよ
まぁ、拒否権発動してろや
めっちゃ叩かれてるなあ
というか叩いてるのはプログラマじゃないと思うのだが。
>>483 も干されそうだな。orz
コードの美しさや単純さを優先するあまり、
例外処理的なことを排除するようなプログラマは
少なくともゲームプログラミングには向いてないよ。
絶対に面白いゲームにはならないから。経験者談 orz
ところで藻前ら、当たり判定ってのはどのタイミングで行ってるよ?
それぞれのオブジェクトが1回分移動した後?それとも全オブジェクトの動作終わってからまとめて判定?
それともその他?
前に一回メチャメチャ悩んだことあるんで他の人がどう考えてるか聞いてみたいのだが…。
プログラマが干されるより先に、ゲーム業界自体が社会から干されそうな予感
>>486 >全オブジェクトの動作終わってからまとめて
これやっちゃ駄目。
壁とキャラの当りはキャラを動かすごとに判定しなきゃ壁の向こうにいるキャラに当たるぞw
1キャラ動かすごとに少なくとも壁当りだけはチェック&補正しなきゃだめ。
>>486 全オブジェクトの動作が終わってからにしてる。そうしないと、オブジェクトの
動作の順番によって判定結果が変わることもあるし。
オブジェクトの動作の中で判定するのがクラス設計的にはきれいなんだけどね。
>>489 >>488さんと対になる意見ですが、
補正前の壁を超えてのキャラ同士の当り判定はどうやって回避しているのでしょうか?
そういうのは衝撃波とみなす
企画としてゲーム会社に就職する予定です。
その際に、COBOL検定の資格は
ゲーム会社の就職に、履歴書としての武器に成り得ますか?
「無いよりマシ」、「基本程度」、「書いたら恥」・・・等
COBOLがゲーム製作で、どんなポジションなのか分かりません。
プログラマーさんたちの意見を聞かせてください。
>>492 眉毛を0.1ミリ動かすくらいの威力だ。
ひのきのぼう 程度の威力も無い。
書いておいても毒にも薬にもならないが、
もっと他の君の強さをアピールしよう。
面接官「特技はイオナズンとありますが?」
学生 「はい。イオナズンです。」
面接官「イオナズンとは何のことですか?」
学生 「魔法です。」
面接官「え、魔法?」
学生 「はい。魔法です。敵全員に大ダメージを与えます。」
面接官「・・・で、そのイオナズンは当社において働くうえで何のメリットがあるとお考えですか?」
学生 「はい。敵が襲って来ても守れます。」
面接官「いや、当社には襲ってくるような輩はいません。それに人に危害を加えるのは犯罪ですよね。」
学生 「でも、警察にも勝てますよ。」
面接官「いや、勝つとかそういう問題じゃなくてですね・・・」
学生 「敵全員に100以上与えるんですよ。」
面接官「ふざけないでください。それに100って何ですか。だいたい・・・」
学生 「100ヒットポイントです。HPとも書きます。ヒットポイントというのは・・・」
面接官「聞いてません。帰って下さい。」
学生 「あれあれ?怒らせていいんですか?使いますよ。イオナズン。」
面接官「いいですよ。使って下さい。イオナズンとやらを。それで満足したら帰って下さい。」
学生 「運がよかったな。今日はMPが足りないみたいだ。」
面接官「帰れよ。」
COBOL固有の知識は置いといてプログラミングの基礎は
わかってるんだろうなという印象を与えられるかもね。
うまくいけば開発部隊にまわされるかもよw
>>493、
>>495 意見ありがとうございます。
はぐれメタルも1ポイント差で逃げたりもしますから
一応書いておいてみます。
面接官「COBOL検定の資格とありますが?」
>492 「はい。COBOLです。」
面接官「・・・で、そのCOBOL検定は当社において働くうえで何のメリットがあるとお考えですか?」
>492 「はい。プログラムの基礎がわかっています。」
面接官「では開発部隊にすぐ入れますね。」
>492 「はい。がんばります。」
いや、そうじゃなくて・・・
492氏はその会社に受かる気があるのだろうか。
面接のHowTo本でも読んだほうが・・・
専門学校生ですが、学校での成績(出席率等含む)は
就職のときに武器になりえますか?
あと、VC++でのプログラミングしか経験がないのですが、
現場でも(VC++のような)IDEを使ってるんでしょうか?
( ´_ゝ`)
おまいはどこの専門学校に通ってるのかと問いたい
釣りじゃないなら学校の先生に聞け
んー。漏れから質問。
専門学校って、コードウォリアーとか使ってないのけ?
>>498 悪いよりは良いほうがいいだろうけど、あまり当てにならないし。
人間性と提出作品から総合的に判断して、全く同じレベルの人が複数
いる場合に悪すぎたら、落とす理由にする。作品が駄目なのに成績が
優秀だから取る、ってことは(ウチは)あまりない。
大手ならいろんな部署があるし、成績重視の所もあるだろうけど
でも成績で勝負するなら、少なくとも大卒じゃないとなぁ…。
面接官「COBOL検定の資格とありますが?」
>492 「はい。COBOLです。」
面接官「・・・で、そのCOBOL検定は当社において働くうえで何のメリットがあるとお考えですか?」
>492 「はい。プログラムの基礎がわかっています。」
面接官「ふざけないでください。なぜ今更COBOLなんですか?他の言語を勉強した方がよっぽど使えますよ?
初級シスアドや基本情報検定はうけましたか?オブジェクト指向についてどの程度理解していますか?
”プログラムの基礎がわかっています”というからには現場でプログラマの専門用語を理解できるということですよね?
本当にプログラムの基礎がわかっていますか??」
>492 「運がよかったな。今日は知識が足りないみたいだ。」
面接官「帰れよ。」
コボラー学生にむかって一人で熱くなってる面接官も痛いなw
そのコピペ改変するときは面接官はいじっちゃダメだよ・・・
まぁ、あれだ。
COBOLの経験なぞあっても無視されるし、現在のゲーム開発とは
あまりにかけ離れているのでかえって知らない方が良いぐらい。
COBOL検定持ってますと言うのは別にかまわないが、間違っても
それでプログラムの基礎がわかったなどと口走ってはいけないってこった。
これがJavaやCプログラミング能力検定だったらもうちっと評価があがるんだがなぁ。
実際に動くコードがあればさらに良いんだが。。。
>>501 専門なんてフリーなのしか使わないだろ。
秀丸+コマンドラインとかじゃないの。
だいたい学習用にはCW高杉。
かつてLSI-C使ってたという奴もいたな。
>>505 論点ずれてるぞ。元ネタは企画。
面接官だってそっち系の人間だろ。
508 :
仕様書無しさん:04/12/03 15:15:56
専門はVC++使ってるよ。だってMFC使わないとGUIの一つも作れないからね。
ちょっと腕のいい講師が作ったDirectXラッパーライブラリを使ってゲーム制作。
生のDirectXなんて使えない。VSYNC同期?なにそれ、みたいな。
フルスクリーンモードでCPU100%占有するのも当然という感覚ですよ。
コマンドライン? 使えるわけないじゃないの。
目糞鼻糞を笑うってのはこのスレのことだなと一瞬オモタ
いや、鼻糞食べると糞になるんだよ。
出口は一緒。
>>508 最初はMFCでもラッパーでもいいと思うが。
当然、平行して言語自体の勉強もしてんだろうし。
>>506 んー。何のために金払ってまでフリーソフトをつかわにゃならんのだー。
教材がフリーソフトじゃあ、高い授業料分の価値は無いわな。
インターネットと独学で十分じゃん。
>>514 インターネットと独学でできない人が行くんじゃん
その人たちには価値あんだろ
余計な事まで口はさむなや
(プ
515=糞ゲー専講師
必死すぎて哂える
CSの開発機で教えてるとこってあるのか?
522 :
仕様書無しさん:04/12/03 18:03:16
晒しage
>>515 おまえ何様?2chで口はさむなって馬鹿じゃねーの。
>>523 馬鹿は
>>523 社会の底辺ゲームプログラマーは哀れだな
明日はリストラか?自殺するなら止めはしないぞ
525 :
仕様書無しさん:04/12/03 18:22:51
↑
なんですか、この人?
スレが上がると、途端にくそレスの嵐だな。w
逝ってよし
(^^)
>>492 COBOL検定か、漏れが査定人ならそれだけしかないと少し引くかな。
他の経験があれば良し。
>>498 VC++なら妥当だと思うぞ。
CWなんかやった日には、そのまま業界に就職できれば良いが、
独学も出来ないだろうし(CW環境が買えないだろ)
独学できる言語を勉強するのが潰しも効いて良いと思われ。
LSI-Cはちょっと思うが、実力があれば良し。
はっきりいってコンシューマ開発でもないのに
初心者にVC+DirectX以外のもの進める奴はかなりの馬鹿。
プログラマに向いてない。いますぐやめて実家帰れ。
俺の職場にいる余計なことして仕事増やす馬鹿と同じレベル。
何か調べさせても、いっつも劣悪な選択肢しか見つけられない奴っているよね。
ほんと何やらせても足でまとい、この上無い。
喪前はいったい誰にブチきれてるんだYO
面接官にじゃないのか。
>>531 お前、俺の職場にいるバカと同レベルだな。
ほんとに週末になるとレベルが地底を這いずるね
就職準備の奴にはVC++よりLinuxで環境構築からはじめろって薦めたほうがよくない?
>>537 それ、たしかユーザーの名前がそのままトラックにでるんじゃなかった?
で、ショーでその名前で入力したやつがいて、
そんな変な名前になってるとは知らずに写真を撮ったと
スコアランキングとかのNGワードリスト保守してると悲しくなってくる。
携帯のゲーム開発してるとfloatが懐かしくて私・・・お国がわからなくなっちゃうっ!
>>541 PS1も懐かしくなるな。
12Bit固定少数懐かすぃ…。
>>541 喜べ。ボーダの新機種はfloat使えるぞ。どうせ使わんけどな・・・
日曜丸々放置されてると、皆仕事してるんだなあという気になる。
お前らせいぜいガンガレ(pgr
『ガンガレ(pgr』?
ああ、そうか、『ガンガレprogrammer』の略だな、ありがとう
最近気付いたんだが
俺は
もしかしたら
X星人かも知れない
スケジュール再調整の名目で遅れている奴の作業が俺に回ってきた。
さようなら俺の年末年始休暇…
>>549 これ最悪だよな。
仕事が間に合わなくなってからまわってくるのって。
俺、その作業をどういう風にやろうか作業期間までに計画立てるほうだから
いきなりこういう風にまわってきて「はい、あと2週間で作ってね」とか
言われると、会社辞めるきっかけに十分なっちゃう。(俺の場合ね)
2週間分の仕事を片付けるとき
最初の一週間は何もしない。やってるフリだけする。
月、火、に仕様眺めてだらだら考え始める。
水、木、金で一気に作り上げる。
テスト勉強と同じパターンですな
それが分かってるからこそ、俗に経験則でマイルストーンは2週間ごと、2ヶ月刻みと言われてるわけだ。
毎週末にその時点で動くものを成果として確認する。最強。
555 :
仕様書無しさん:04/12/06 13:24:30
延期延期の癖に偉そうなことぬかすなボケ
ボケ 出ました!
>>556 了解。
こちらも ボケ 目視で確認しました。
引き続き ボケ の警戒を続けます。
558 :
仕様書無しさん:04/12/06 22:54:07
報ステでゲーム脳特集放送中・・・
ゲームやると脳が退化していくことになってます・・・
エロゲーでオナニーしすぎてチンコが右寄りになってしまいましたが
こ れ は ゲ ー ム チ ン コ で す か ?
暗算するとゲーム脳が回復することになってます・・・
おいおい、まだゲーム脳なんて論理的に否定されたもの
信じている奴がいるのか?
確か体育教師か何かがお手玉普及させようとして
詭弁を展開していたんだっけ?
リラックスしたときに出る良いα派が
ボケ老人も出してるから悪い物だとかw
論理的に否定できるのか
>>563 そもそも脳波なんてもの自体が胡散臭いからどうにもならんですな。
暇つぶしに二桁暗算ツール作ってみたけど
20問解いて1問あたりの時間:3.1921秒だった。
眠いのもあるけど時間かかりすぎ・・・orz
しばらく続けてみるかな。
頭悪い奴がゲームばっかりやるっていうだけで
ゲームのせいで悪くなったんじゃねーよ!!
同じゲームばっかやってないでしっかり勉強して褒美にガンガン買ってもらえ
ダラダラプレイがゲームデフレの原因なんだよ
連中が何をもって頭の良し悪しを決めているのかは知らんが
例えば東大生でもゲームばっかりやってる香具師は多いぞ
頭が悪くなるとはあのアホ教授もいってない
コミュニケーション能力に乏しく切れやすくなるらしい。
久しぶりにモノポリー遊んだら、お釣りの計算ができない自分に呆然。
俺もリハビリ用のiアプリか何か作ろ。
>>568 ゲーマーというより最近の若(ry全般の傾向じゃないか。
親の教育に最大の原因があるのは明らか。
おまいらもそろそろ最大の原因になるわけだが(とっくにか?)
何歳ぐらいから子供にゲームをやらせますか?
>570
>最近の若(ry全般の傾向
そうなの?ソースは?
デスマのあとに休暇とかってある?
昔FFかなんかは、開発後に長期休暇をとれるって聞いたけど。
俺は3歳の頃からカセットビジョンやってたので物心つく前からやらしても問題なし。
「子供のコミュニケーション能力の減退と、ゲームの普及は同時期に進行している。
ゆえに子供のコミュニケーション能力の減退はゲームである」
「子供への携帯電話の普及と、子供の平均身長の増加は同時期に進行している。
ゆえに携帯電話の普及の原因は子供の平均身長の増加である」
前者は正しくて後者は正しくないと思った人がいるかもしれないけど、
論拠としては「同時期に進行してる」ことだけを根拠にしてるのであって
原因と結果を結びつけるには不十分
他には、脳波を使ったよくわからん実験をしてたり
「残酷なゲームをプレイした子供は残酷になる」って本人の主観が堂々と語られてたり
とにかく学者としてはうさんくさい筆者
でもなぁ、この前も近所の小学校で講演会やってたし(行けなかったけど)
親たちの間でも普通に
「ゲームやるとゲーム脳になるからやらせられないよねぇ」
見たいな会話が飛び交っているぞ。
うちは1年生だけど1日1時間と決めてやらせてる。
やっぱ、子供がゲーム脳になるのは嫌だしw
ママさんがとび付いたことが
ここまで生き残ってる理由なんだろうね・・・
お勉強の障害を排除する理由になるし
あと、マスコミにとってもテレビを占有するコンピュータゲームは敵。
579 :
仕様書無しさん:04/12/07 11:38:16
皇太子殿下がファミコン好きなのは有名ですが
ゲーム脳になるとあのようになられてしまうのでしょうか。
ばばあどもが何の疑いも無くボーっとみてるワイドショーのほうが1000倍害があるぞ。
他人の思想と自分の考えの区別すらつかない。テロップで笑いどころを教えられないと笑えない。
581 :
仕様書無しさん:04/12/07 13:22:08
>>581 「ゲーム」という単語が一度も出てきてない訳だが
まぁ一行目は同意
勉強は勉強でちゃんとやらなきゃね・・・
>>573オメ
それはさておき、それなりの大型プロジェクトなら貰えたことがある。
1〜2週間。休出残業の振り替えって形に近いし、それで数えると勘定に合わんくらいだが。
それ以前に、プロジェクト終了と同時に辞める人も多い。
彼らの休日については推して知るべし、つーか俺も辞めたことあるけど、
2ヶ月くらい仕事もなんもせんでぼへーっとしてた。
>>576 > やっぱ、子供がゲーム脳になるのは嫌だしw
子供の脳の前に、自分の判断力の低下を嘆いた方が良いと思われ。
もうさ
ゲーム脳=ゲームのやりすぎによる諸々の弊害の総称
でいいんじゃないの。森某はどうでもいいよ。
ゲーム脳にさせたくないからゲームをさせない
で
おまいさんたちは子供を何脳にしたいんだ?
放置してお花畑脳に
無脳
ていうかおまいら自分のお仕事に誇りはありませんかそうですか。
実はまだ学生の漏れ
>>584 >>586 俺はゲPGやってて子供もいるんだけど、確かに自分の判断力の無さは認めるよ。
だがな、子育てやったことある奴いるか?
一人の人間を全く未経験のところから初めてまともな大人にまで責任を持って育てなきゃならない。
しかも、途中でやり直しはきかないし、こっちの思い通りにも動いてくれない。
目隠しでヨチヨチ歩きの子供を連れて地雷源歩いてるようなもんだぞ?
俺が過剰に心配性なだけかもしれないが、親としてはちょっとでも不安があったらなるべく距離を置きたいもんなんだよ。
昔ほど周りに大人の目が行き届いてるでもないし、ニュースでは毎日、基地外や炉利痕が起こした犯罪がバンバン放送されてる。
しかもそれに触発された模倣犯がさらにそこらじゅうに潜んでるときた。
そりゃぁ、過保護になるってもんだろ。
俺もゲーム屋だし、ゲーム脳なんて信じちゃいねぇよ。
だがな、俺らが作っているテレビゲームって奴はな、常に刺激を与え続けプレイヤーを没頭させる方向で進化してきたんだよ。
それをおまいらは完璧に無害だと断言できるか?できないだろ?
確かに俺らは自分の手でゲームを作ってはいるけど、子供の成長に及ぼす影響が0%だと断言できない限り、
まだ精神が未発達な子供に無闇にゲームを与えたくは無い。
ゲームはガキがやるには早すぎる。
オレの場合
RPGで雑魚と戦ってレベル上げしてるときなんて
完全に思考が停止してるな。
完全パターン化したシューティングの序盤面やってるときも
絶対止まってるな。
しかし何もせずにボーっとしてるときよりはマシだとは思うがねぇ
シューティングとかはまだいいんだけどさあ。
ゲームやる奴同士にしか通用しないコミュニケーション言語化してるゲームが
幅を利かせてる点については言及する奴すくねえなあ。
端的にはエロゲとかギャルゲとかの類なんだけど、萌えとかがどうこう以前に、
あれ同好の士を囲い込んで、それ以外の人間にはまったく通用しない言語に
なったりするわけで、作る側もやる側もそれで良しとしてしまってるところがあるっぽい。
そりゃ無関係な第三者が叩く口実にはなる罠。
どんな領域にもそういう内輪はあると思うけどなあ。
だが、テレビゲームと同じで生産性ゼロの一人遊びでも、トランプとかは叩かれない。
なんでテレビゲームだけ叩かれるのかってーと、古い世代は「実体がないモノ」への不安が大きいんじゃなかろうか。
トランプとは中毒性がケタ違いってのもあるが。
多分にそれはある。
お年寄りの携帯電話恐怖症って、あれが複雑なデバイスだから受け付けないんじゃなくって、
簡単だろうとなんだろうと未知のパラダイムの担い手であり、かつ、最も身近で未知であるところの
子供たちの象徴であるからであって、仮に誰でも使える優しい携帯電話とかがあったところで、
それまで携帯電話に拒絶反応示してたじい様ばあ様が、コロリと宗旨替えするってことは
(少しはあるだろうが)大多数においては、まあ有り得ない話。
よって漏れらに出来ることはといえば、誰もに胸張ってエヘンと威張れるゲームを作ることだけですよ。
胸のゆれとかは関係なくな、とりあえず。
たとえば携帯電話がコードでどっかとつなげて使うようなものなら老人でも抵抗が少なくなるんだろう。
自分の理解できない映像と向かい合っている姿や小さな箱と会話してる姿の
「得体が知れない・原理がわからない」ことに対する拒否反応のようなものだと思う。
>591
> 子供の成長に及ぼす影響が0%だと断言できない限り、
> まだ精神が未発達な子供に無闇にゲームを与えたくは無い。
じゃあ、小学校に通わせるのはやめた方がいいな。
子供の成長に及ぼす影響が大きすぎる。
598 :
仕様書無しさん:04/12/08 08:11:30
ホント?それはまた狂言だな。
充分なサンプルと相関関係を統計的に証明してれば別だけど。
>>591 > 昔ほど周りに大人の目が行き届いてるでもないし、ニュースでは毎日、基地外や炉利痕が起こした犯罪がバンバン放送されてる。
統計的に見る限り、昔と比べて犯罪が増えてる&深刻化してるという結果は
出てないぞ。マスコミの取り上げ方がセンセーショナルになってるだけだよ。
> それをおまいらは完璧に無害だと断言できるか?できないだろ?
まずは空気が汚れてる都会に住むのをやめるべきだな。
> それをおまいらは完璧に無害だと断言できるか?できないだろ?
コンピュータの発している電磁波が完全に無害だと断言できるか?できないだろ?
602 :
仕様書無しさん:04/12/08 22:03:42
他人様の子供にはさんざんっぱらゲーム売っといて
自分の子供にだけはやらせたくないなんてふざけるなと。
まずはお前ら自身の倫理観を何とかしろ。
俺の場合はヤクを作ってる感覚はないが酒・タバコぐらいの害あるかな〜と頭の隅っこにおいてある。
あと、この業界で数年やってると毎朝ヒゲそって、ネクタイ締めてないと怒られるってのは想像の範囲外にいっちゃてるのよ。
正直、世間様でいうところのちゃんとした会社ってのは一ヶ月耐えれるか怪しいのね。
まあ入社そうそうデスマ体験して死ぬかと思ったが一週間程度で結構適応できたから何とかなるかもしれないけど。
>>488-489 亀レススマソ。
基本的には、壁との判定は移動時、その他の判定は最後、って感じなのかな?
ちなみに、以前迷ったのは「動く壁」とか「壁判定を持った敵(グラ5のじゃがいもなど)」とか出てきた場合。
整理の仕方に問題があったのか、考えれば考えるほどドツボにはまった記憶がある。
なんか「鶏が先か卵が先か?」をまじめに考察したような気分になった。
>>605 ちがう。
良く考えろスケベ。
壁判定は動くたびにやらなきゃいけないんだよ。
敵との判定は一発だけにあきらめ、敵と自機のめり込みを許す。
敵と自機との衝突後の移動で壁判定をしなければならない。
敵との判定を一発だけにあきらめるのは永久ループを回避するため。
要は敵とのめり込みはある程度あきらめて、
絶対にぬけちゃいけない壁の判定だけ確実にするっていうこと。
なのでワンフレームで壁判定は何回も発生し、
かつ、高速化はできない。
処理的には動く物体が動いたら、即、壁判定でいい。
別に、子供に対して有害なのはゲームに限らないしな。
酒にタバコにギャンブルに、環境フォルモン、電磁波、
放射線、子供の教育も満足にできない親、過保護な親、
学級崩壊を発生させるアフォ、etc
今の時代、ゲームどころか、漫画すら読んだことのないガキが、
珍しくないらしいけどな。
正直なところ俺が死ぬ頃社会がどうなっていようと知ったことではない。
それに内戦だの銃乱射だのやってる国よりは
2chに入り浸ってたまに一人二人カッターで切り殺していた方ががまだましだ。
俺は
ゲームは子供にとって1日1時間程度なら
テクノロジーへの知的好奇心を刺戟してくれるいいものだと
信じてるよ。もちろん息子にもプログラマになってほしい。
子供のころに親が教育してくれたら…と思うときあるな
まぁ俺の親はドカタだったからそこまで期待しちゃいけないけど
でも小学校のころから触ってたけど、ゲームしたり年賀状作っただけ、
っていうやつだとそれほどアドバンテージは無いと思う
じゃあどういう勉強をさせればいいんだ、って言われると困るけど…
親が子供にできる事は、しつけをする事と、飯を食わせる事、
様々な物に興味を向けさせる事、顔を合わせた時に話をする事、
ぐらいしかないだろ。勉強なんてモノは自発的にやる事で、
押し付けられてやる事ではないと思うけどな。
そりゃ、教えてもらう方が楽なのは認めるが・・・
つーか、飯の時間に顔を合わせてもTVに夢中で、
話すらできない親が、世の中には珍しくないからな。
>>608 なにやって遊んでるのかな。
普通に外で友達と野山をかけまわってるでもあるまいし。
親に飯くわせて貰っただけでも感謝だぜっと
当たり前の事だが、当たり前の事に感謝せにゃな
ぶっちゃけ、ゲームが無害と力説してるやつって
そんなに人畜無害な空気みたいなもの作ってて楽しいのかと思うわけよ。
裏を返せば社会的影響力ゼロってこったろ?
想像してみろよ。俺のゲームに影響されて銃乱射とか、発売日に強盗とか、
教室で必殺技の真似していじめとか、実に心躍る話だと思わんのか。
そこまで行かんにしても、ゲームに溺れて成績落としたり
会社休んで怒られるダメ人間を量産できれば俺は「成功」だと見るね。
オレが作ったゲームをプレイするとモテモテになります。間違いない!
なんか邪悪な人が紛れ込んでいますね
俺は任天堂系のゲームなら一日1時間でガキにやらせても良いと思っている。
なんだかんだで任天堂はめっさ優秀だと思う。
それにつけても嫁の欲しさよ。
622 :
仕様書無しさん:04/12/10 11:31:08
給料いくらですか?
他業種に比べれば安いよ。
月15〜20万ぐらいがいいとこで、まぁ年齢×1万円の月収があれば勝ち組。
具体的には転職系サイトでゲームPGのとこを見れ。
624 :
仕様書無しさん:04/12/10 11:46:49
30〜40歳になったときどうなってるの?
有能な人と並な人それぞれで。
30〜40になるまでに大体辞めてr(ry
ゲームプログラマ辞めた人はどうしてるの?
ゲームショップを開いているか、テクニカルライター、ゲー専講師とか。いろいろ。
ゲームそのもの以外を作るほうへ回るのが大多数では。
技能は並以下だが、とりあえず手取りで年齢*1万貰ってるもう直ぐ33歳。
職種そのものをやめる気は無いが、会社は辞めたがりになってて、次で10社目。
いい加減腰を落ち着けたいと思うがどうも上手く行かない。脳の病気かも知れん…
>>628 医者行ってらっさい。
きょうび珍しくも無いよ。
630 :
仕様書無しさん:04/12/11 11:15:03
趣味でゲームプログラミングしようと思って
いろいろ調べた結果、
C→C++(かじる程度)→VC+かVC#
という順で勉強しようと思いますが無難でしょうか。
プログラミング歴はVB1年(データベース)・C言語1ヶ月です。
最終レベル目標は「いたスト(SFC版)」です。
C#かC++かで迷っているのですが、
上のレベルの作品を作るのにC++は必要でしょうか。
現職のPGではないので言語の将来性は重要視していません。
VBでつくればいいだろ
マシンのスペックを気にしないならVB、
数多くの人に遊んでほしいならVCかな?
634 :
630:04/12/11 13:11:17
いろいろな回答ありがとうございます。
みなさんの回答を読んだところ、上に挙げたレベルの作品なら
言語はそれほど関係ないと捕らえてよいのでしょうか。
経験のあるVBの使用も考えましたが、画像を
操作するようなプログラムを組んだことがないので、
果たしてVBで組めるのかどうか想像がつきませんでした。
>>633 いたスト(SFC)と書いたのは「3Dではないボードゲーム」を
想定していたからです。2人〜4人のオンライン対戦も
考えているので特にスーファミに拘るつもりはありません。
スーファミでもオンライン対戦できるよん
VBでも組めるよ、ただフリーソフトで広めようとするならランタイムが邪魔かもな。
その前に、魅力ある絵が描けるがどうかが疑問である。
オンラインならC++でやると色々ややこしそうだな。
いたスト程度ならVBでやってもスペック的な問題が出るとは考えづらい。
VBでつくったプログラムって臭いで判るんだよね。中身見なくても。
なんでだろうな?
VB使いに厨房が多いのが一つの理由かもしれん。
>>638 ウィンドウのあるアプリならGUI一つ一つの詳細な設定ができないためだと思われ。
細かい動作をVBで設定するためには、APIコールをしなくてはならない。
そうするとVCのン十倍の手間がかかる。
ん?VB6の話なのか。
まぁ、ゲームだったらDirectX系じゃないの?
VBだろうがVCだろうが作れるもんは作れる
そもそも、ゲームを仕上げる技能があれば、言語を理解するのは余裕
VBをマスターした、っていえるレベルまで使いこなせば、
VCでも1週間もあれば使いこなせるはず
構造化BASIC以上ならCでもJavaでもPascalでも骨格は同じ
だな。GUIの場合、言語が理解出来るかどうかよりも、
イベントトリブンが理解出来るかどうか、だからな。
あと、状態変位か・・・管理が面倒なんだよな、コレ。
そこでタスクシステムですよ
644 :
630:04/12/11 15:53:15
>スーファミでもオンライン対戦できるよん
おそらくエミュレータやKailleraのことと思いますが、
どうもスーファミにする利点がなさそうです・・・
>その前に、魅力ある絵が描けるがどうかが疑問である。
たしかに難しい問題ですが、今の段階ではまだまだ先の話です。
とりあえず製作中は既存のゲーム画像を使用することになると思います。
>細かい動作をVBで設定するためには、APIコールをしなくてはならない。
私が使っているのはVB.NETですが、このへんのことは
VB6と変わってないようですね。
そのためか多くのウェブサイトでVB経験者はVC#に乗り換えろという
記述をよく目にします。
いろいろなご意見ありがとうございます。
私としてはC#がよさそうだという結論になったのですが、どうでしょうか。
VB.NET = APIが面倒
VC++ = オンラインがややこしい
VC# = VB経験者に推奨らしい
VC#か・・・MSの意向としては、Windowsアプリは
これ一本に絞って欲しいのかもしれんケド・・・
まあ、MS-Officeがこれで作られるようになったら、考えるかな?
>>644 ははは・・・w
VB6からVB.NETであれだけ酷い目にあって、
まだ、MS言語手放せないんだw
君はずっとツールを探し続ける類の人だよ。
会社にいたらちょっと笑えない。
今からC,C++覚えるぐらいなら C# でもいんでない?
>>647 なんでわざわざMS言語覚えさせるの?
C#はMS言語だよ。
そこらへんわかってるの?
.NETでグラフィックだとDirectXを使わないとゲームにならんよ。
まったくアニメーションさせないならいいけど。
ところで宣言が必要+API=???
やってることがおかしいと思うんだが。
>>648 JavaもC#も事情は似たようなもの
C/C++だって基本文法の枠を超えたらどこかのベンダーにおんぶに抱っこだ
>>648 VC++でもMS言語みたいなもんだろ。
>>651 え?そういうあいまいな表現やめてくれない?
@C++ + Win32API
AMFC
ってあるけど@は旨く作ればWin32APIだけ切り離すことは比較的容易。
Aはどうしようもない。MS言語でいいと思う。
まだMS嫌いとかって存在したんだ!?ダッセーw
MS嫌いって共産党支持者っぽいよね。
どうでもいい話が続いているな。
MS言語を定義せよ
>>656 先に言語の定義をしろ、定義に問題が無いならMS言語の定義をしてもいい。
たまーに「ボク、MS嫌いですから」とか言う奴っているけど、恥ずかしいからやめておけよ。
660 :
仕様書無しさん:04/12/11 17:17:24
>>656 まあ、定義はあいまいだけど。
これは使ってみた感覚でうなづいてくれると思うな。
VC++でMS言語っていうのは俺はMFCのことだと思ったけど。
(俺の定義ではMFCはMS言語じゃない)
C#とVBはもうどっぷりMSが仕様を変えちゃうことによってコンパイルできなくなっちゃうよね。
バージョン定義でわけることも不可能だし。
バージョンの移り変わりに対応していくのがオマエラの仕事だろ。
ついて来れない奴は辞めろ。
663 :
仕様書無しさん:04/12/11 17:28:10
つか、VB6で組んだプログラムはVB.NETに修正できなければソースを捨てるしかない。
VB6を使い続けて組み続けるという手もあるが、今度はWindowsのバージョンアップで動かなくなったらアウト。
#ちなみにVC6とWindowsXPの相性は最悪。
#実行時にハングアップするといじってたソースが真っ白けになるw
で、開発者の人数が増えてもVB6を購入する手段がヤフーオークションしかない。
まとめると
MS言語の怖い話一覧
・MSのサポートが切れてWindowsのバージョンがあがったとき
動かなくなったときが本当の最後。(これがランタイムまわりのバグだと致命的)
・バージョンアップによる仕様変更。
システムがC++などのメジャー言語の上に載ってるようなものなら変更はAPIの使用箇所のみで済むが
言語自体がMS仕様だと最悪。(今回のVB6→VB.NET等)
664 :
仕様書無しさん:04/12/11 17:28:59
>>662 だから、なるべく負荷を減らす話をしてるんですけど。
あなたアホみたいなので、あっちいっててもらえます?
C#はIETFで標準化されたから他の言語より条件が悪いということはない。
>>664 甘えんなよ。負荷の軽減に配慮してばっかりいたら進化しねーんだよ。
この時代までVB6が生き残ってしまったのは、配慮の結果だよな。
おかげでそのへんクズPGばっかりだwww
668 :
仕様書無しさん:04/12/11 17:39:10
ボク、MS嫌いですから
669 :
仕様書無しさん:04/12/11 17:39:50
>>666 目先の仕事こなすことしか頭に無いくせに
進化なんて口に出しちゃうところが君の駄目なところだと思う。
670 :
仕様書無しさん:04/12/11 17:41:34
>>668 てゆうか俺はMS嫌いでこんなこと話してるわけじゃないんだけどw
君はレスをよく読もう。
>>652 条件付けでいいのならVBでも可能だが。
>>669 目先の仕事もこなせない馬鹿がよくいうぜw
くだらねえ議論してねーでさっさと仕事しろよ。
>>670 Windowsアプリの話してるんだろ?MSに従ってるのが一番いいんだよ。
って書くと、おまえら末端PGは「一番いい」をもっと定量的に示せとかごちゃごちゃ言うんだろうが。
>>673 >Windowsアプリの話してるんだろ?MSに従ってるのが一番いいんだよ。
議論部外者だが、↑の考え方だけでは身を滅ぼすよ。
少なくとも数年先のWindowsと.NET構想のロードマップが発表されてるからな。
C#を憶えることに多少安心はある。
つうか互換性うんぬん言ってる人。先のバージョンの情報くらい仕入れろや
>>675 その前になんでそんなの信じちゃうのかわからない。
>>676 あなたどっちの事言ってんの?
どちらにせよ自分がこれだ、と思った発表情報を信じなくて何を信じるのさ?
出てきてから文句たれながら対応すんの?
その歯車プログラマすするんならそれでもいいと思うけどね。
>>677 MSの大本営発表しかあんたは見てないのか?
C#は例の件でおしゃか決定なんだよ。
例の件自体を知らんから、んな間抜けなことを言ってるんだろうが。
679 :
仕様書無しさん:04/12/11 18:50:20
>>678 間抜け?
そのC#の気になる例の件とかは確かに俺は知らんけれど、問題があると思うなら今からでも対策を考えれるだろう。
俺はWindowsと.NETに対して言ったんだが、C#ボツネタを持ち出してきて間抜け扱いは酷いな。
C#言語がボツになっても.NETもボツなのか?
C#がボツっても皆がいうように、新しい言語はすぐに憶えなおせるだろう。
.NETフレームワークが無くなったとしても今から対策を考えることが出来るだろう。
そんなにMSが信用できないなら、おとなしく自分で全部作りなよ
急に死滅スレ化してきたな・・・
>>680 つか、一連の書き込みは別に1人の人間が書き込んでるわけじゃないぞ。
>>660,663,670は俺だけど後は全部他の人だよ。
>>678の人はなんかC#は終わりってことを言いたいだけで書き込んだっぽいぞ。
ちなみに俺はC#とVB.NETはなんか嫌な匂いがするね。
久しぶりに来てみたら何でWindowsオンリーのC#で揉めてるんだ。
将来コンシューマにC#が使えるのかと言う論議ならともかく。
そういや、PS2の出だしのときはLinuxと仲良しっぷりをアピールしてたが、
あれはその後どうなったんだ?
>>681、682
スマンカッタ
C#は俺も嫌な雰囲気を最近は感じるが、別にC#が無くなるのはかまわないと思うのよ。
散々既出なように言語なんてすぐ憶えれるんだから(今の俺に辛いのは.NET自体が無くなること)
でさ、一度作ったツール類の開発ってWindowsの寿命以上に生涯使われていく事ってそうないよな?
ゲームエンジンとデータ構造だって数年おきに新しい技術を吸収して(1からでは無いにせよ)作り直してない?
その時に製品寿命を考えて、期間内ら動作する言語とバージョンを選んでいるんじゃないの?
>>683 一応Linux用のC#コンパイラも出てるよ。
>>683 (´-`).。oO(XBox・・・・・・)
687 :
630:04/12/11 19:41:04
( ゚д゚)ポカーン
>>685 Win32APIは95の時代から長続きしてるがな。
689 :
仕様書無しさん:04/12/11 19:51:20
MS言語だと何かマズいのか?
何十年も使い続けられる業務システムでもあるまいし。
630自身が趣味で作ると言っているのだから問題ないだろう。
CやC++だと、言語そのものとWindowsのAPIが分離されてるから
具体的なゲーム制作に入る前に力尽きてしまうのではないか
(挫折ではなくモチベーションがなくなる)と思うんだが。
別にVBでも構わんと思うが、質問が
>C#かC++かで迷っているのですが
ということだったので。
691 :
630:04/12/11 20:10:47
>VB6からVB.NETであれだけ酷い目にあって、まだMS言語手放せないんだw
あまり奥深いものを作成しなかったのでまだ酷い目に遭ったことがありません。
>今からC,C++覚えるぐらいなら C# でもいんでない?
それほどCとC#は別物なんでしょうか。
現在Cを勉強中ですが、どうもVBはプログラミングというより
アプリケーションの使い方を勉強しているような気がして、
今ではGUIよりコマンドラインに新鮮味を感じます。
(所詮その程度しか使いこなせていなかったということですが)
>>皆さん
貴重な書き込みありがとうございました。
皆さんの書き込みを見てC→VC#と勉強することにしました。
ここでも議論されている通り、言語の優劣は付け難いものだと思いますが、
ここで挙がるような言語なら最低でも5年は持つと思います。
5年あれば私はゲームはあきらめて今までどおりデータベースオンリーに
なるか、他の言語に移るにしてもさほど苦にならない程度の実力は
ついているでしょう。
>>688 NT3.1 は95より前だったけどな。
しかもWin3.1にWIN32APIを実装するWIN32sってのもあった。
>>691 賢明だな。MSだから〜とかガキみたいなこと言ってる馬鹿どもに尻穴のシワに付着したカスを煎じて飲ませてやりたい。
ま、痛い目みればいーんじゃないの?
俺は別にMSが嫌いってわけでいってたわけじゃないんだけど
そこのへんが理解できない馬鹿がいるみたいだし、
説明するのも面倒だからこの辺でやめよう。
>>694 プ。痛い目痛い目って、どれだけ低スキルなんだよ。
おまえはいつまでも環境選びしてろよww
低脳は言い訳だけは一人前ですから
>>685 あ、Monoは知ってる。
PCオンリーって言うべきだったな。
698 :
仕様書無しさん:04/12/11 20:40:00
俺も、MS言語で痛い目、って意味が良くわからん
今のところ、バグだからけで困った、という自体にも遭遇してないし…
多少のバグは別の方法で解決できるケースが多いしな
量子コンピュータができたら電子コンピュータ産業が痛い目
Windowsの新バージョンが出たら直前に旧バージョンを買っちまったユーザーが痛い目
って言うのと同じ理屈だな。
C++以前にC言語やってたやつが他の言語に移行していないとでも考えてるんだろうか。
☆ チン
☆ チン 〃 ∧_∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄
ヽ ___\(\・∀・)< 「例の件」マダー?
\_/⊂ ⊂_)_ \_______
/ ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
|  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
| .|/
「例の件」 「例の件」 とうるせーな!この低脳が!
と、他人が煽ってみるテスト。
つうかコンシューマの話をしようぜ。XBOXとPCは就業人数少ないでしょ。
PSPの開発環境っていまだstableじゃないって聞くけど、実際どうすか?
CEDEC2004のPSP講義では他人事ながらヤバそうだなと思ったけど。
706 :
仕様書無しさん:04/12/12 00:19:08
>>678 例の件って何ですか?
逃げモードですか?
例の件を知らないって、素人かよww
趣味の問題なのにいちいち下らん宗教戦争に持ちこむなよ。
>>705 XboxとPCって一緒くたに扱われるほど少ないのか?
漏れん所はむしろXboxの話ばっかし来てるんだが。
真面目に3Dに投資してきた会社は今更後に引けないものがあるし
Xboxも悪いことはないつーか、あの開発環境の優秀さ考えれば
むしろ大歓迎。
出資元外資ばっかし、海外向けタイトルばっかりだけどorz
血湧き肉塊踊るFPSとかスポーツゲーとかプロレスとか…
まあ、割り切ればそれもまた楽し。
710 :
仕様書無しさん:04/12/12 03:20:02
本当にプログラマーなら例の件というのがなんのことか考えるまでもなく
わかる。わからないやつは(ry
712 :
仕様書無しさん:04/12/12 03:29:03
リアル学生なんで説明キボンヌ
これだけ引っ張ってるんだから、さぞ血湧き肉塊踊る
オチがあるんだろうね>例の件
714 :
仕様書無しさん:04/12/12 10:56:17
>>709 日本はゲーム界のガラパゴス諸島だから
全世界で流行りまくりのXboxが普及しないんだよね。
>>714 そのガラパゴスが世界の市場を作り上げた。( ゚∀゚)アヒャ
日本で売れない理由は研究対象となるべき事項ですよ。
国産ゲームですら売れてないのに海外ゲームが売れる理由ないよね。
>>715 まるでイースター島の人口増加→人口過疎化現象の研究だなw
日本のXBOXはやっぱ同発ソフトで損したと思うよ、うん。
あと、初期のディスクに傷が付く問題とか、
他のゲーム機に比べてやたらでかいとか、
導入部分での失敗は多かったね。
719 :
仕様書無しさん:04/12/12 11:24:19
人間がアフリカ発祥だからといって先進国がアフリカで商売するのは難しいっしょ。
国内の囲い込みたがり企業のせいで結果的に将来
技術の遅れを取るパターンは何度みたことか
企業の囲い込みもあるけれど、技術者の風土として情報共有の空気がないでしょ。
gems を読んでいても Nintendo Of America の人が執筆していたりするしね。
そういう意味では CEDEC や IGDA には少し期待している。
人を重視する国か、技術を重視する国かの違いだよ。
日本は、技術が企業の存続を決めると言いかねんぐらいに、
技術者よりも技術を重視する国だからな。だから、
技術流出に対しては異常なまでに慎重になる。
米国は、技術よりもむしろ、技術者を重視する国だからね。
だから、オープンソースが普及しやすい。
利いた風なことを…
青色ダイオードの件だけでも、
723の説を肯定するには十分な話だぞ。
そりゃ、そーゆー企業ばかりではないという事実を、
知っている人は知ってるかもしれんが、知らない人も大勢いる。
それだけこの国が病んでるって事だろ。
日本はボトムアップの文化だからな
細かい所は技術力があっても抽象的な話ができない
米が低性能バグだらけのフレームワーク、日本が使い道のないラッパーライブラリだらけ
なのが象徴してると思うYO!
>>726 >>米が低性能バグだらけのフレームワーク、日本が使い道のないラッパーライブラリだらけ
設計できるステイツのほうが全然上だと思うが。w
PCは異様に寡占というか、選択肢がないのにゲームではまったく逆ってところがスゴイ。
PSPの開発は愉しいのかなぁ。同じ携帯機なのにっ……w
>>711 誰にも分らんぞー、オラオラとっとと書け「例の件」とやらを
「例の件」って、イオナズンよりつおいかな
731 :
仕様書無しさん:04/12/12 16:20:38
>>723 日本のゲーム企業が技術流出に慎重ってのは、何かの冗談にしか
聞こえない……。
技術は人と一緒に巡り巡ってる。ただ、外に発表する機会もなければ
メリットもないから、業界の外に出てこないだけで。
仕事忙しいからあまり2chもしないみたいだしね
それはつまりここにいる人たちは仕事がないってことですか
736 :
仕様書無しさん:04/12/12 21:35:36
おい、768よ。
藻前が答えないと、多分、このスレを使い切るまで、
例の件って何ですか?と聞かれるぞ、それでも良いのか?
じゃ、768頼むな
しつこく聞いてるフリして荒らしてんのは一人だけだろ
いっぱい居ると思う、オレもオチが気になるし(笑
下手すりゃC#死滅だもんなw
こんな所に具体的に書けるわけないだろ。
例の件でわかる奴だけわかればいいよ。
743 :
仕様書無しさん:04/12/12 22:17:42
例の件…
まさかD言語がC++の後継言語に認定された事とかじゃねーだろーなw
なんだそりゃ? ソースは?
例の件?
次期OfficeはCOBOL.netで開発されることか?
確かにMSの今後の主流はCOBOL.netに移行するだろうがC#が消滅するわけじゃねえよ。
知ったかぶりするなバカ
↑その落ちは寒すぎ。
漏れん所は力ないから出来ないが、藻前らの会社はMMORPGやらんのか?
日本製が無さ過ぎで韓国に市場取られるぞ。
まだ市場が小さいしなぁ > オンラインゲーム
やるにしてもコンソールのオマケみたいな感じでしょ。
>>750 全力を尽くしても、出来ることと出来ないことの判断はつく大人なんだが何か?
>>750は全力を尽せば何でも出来ると思っている消防か?
>>750は日本に追いつくとか言ってる韓国人並のアホ
見事なまでに休日モードだな
>>749 ■eの11が結構な利益上げてても市場小さいのか?
そんなに儲かるなら、任天堂がとっくに進出してるでしょ。
任天堂に比べたら、スクエニなんぞ取るに足らん。
MMORPGの客層と任天堂の客層は違いすぎるだろ。
751「おまえらMMORPG作んないと韓国に負けるだろコラ。おれは努力しねーけどなw」
>>750が漏れに20億円ぐらい出資してくれればMMORPGリリースに全力を尽くすぞ。
だから750は全力を尽くして20億円用意してくれ。
>>754 合併前のエニが失敗してる。
結構やってた所は多いぞ。
>>759 日本のPC市場は難しいと思うぞ、ゲーム機でよろ。
資金を集めることは『全力』には含みません。
なぜならただのコーダに過ぎないからです。
仕事の都合で、あんまり有名じゃない映画をDVDで山ほど見たんです。
そこで見たうちの一つが韓国映画「リザレクション」。
世の中韓流だの韓国ブームだの、日本は韓国映画やドラマを
見習うべきだとかよく言われてるけど、そういうことかぁ、ってオレ、わかっちゃったんだなあ。
「このオリジナリティはすごいよ! 主役はさえない韓国男性なんだけど、
仮想現実の世界でヒーローになって、拳銃とか拳法とか使えるようになるわけ!
仮想現実の世界を表現するのに、
黒ににグリーンのハングル文字がランダムに雨のように降ってくる斬新な映像もすごい!
仮想現実の世界を彼から守るため、システムが主役を殺そうとするんだけど
至近距離から銃で撃たれて、その瞬間に弾丸がハッキリ見えるくらいのスローモーションになるのね、
撃たないでーって思って見てた僕らの心の声が、そこで 避けないでー、に変わるわけなんだけど
もちろんえびぞりでブリッジで弾丸を避けますよ!」
「一緒に見たほかの国の映画に比べれば、この韓国映画は非常にストーリーがよくできてるんですよね、
元本があるから!(大爆笑
いやあ、これは皆さん絶対見てくださいよ、おすすめする人はね、マトリックスを見てない人ね(大笑
これいいの? これが許されるなら俺とタシロ(若手芸人)が青と赤のジャージ着てホワイ♪とか
踊りながら歌っても許されるんじゃないの?
で、ネットでこの映画調べてみたら、韓国のアカデミー賞に相当する映画賞で、映像技術賞とか
いろいろもらってるんだよねこの映画! 賞はダメだろ?
見てない作品がひとつ、ありますよね選考委員」
「こんな作品に賞まで出してる韓国なのに、冬のソナタの音楽はテレビやラジオで使っちゃダメとか
すっげー細かい権利とか言ってくんの。オカシイだろオマエそれ、と!」
>>761はただのコーダか!、口達者だけの愚か者か。
>>763 なんか日本語が不自由になってるぞ。
動揺してるのか?w
つーか、
>>750を受けて
>>751でいきなり青スジ立てて噛み付くあたり、
神経質なキモグラマの匂いがプンプンする。
キモグラマw
>>755 任天堂がポケモンオンライン出したら他のメーカー死滅だろw
>>754 この業界に入ってみれば分ったんだろうけどね、作ってた所は結構あったのさ、
問題は死屍累々というだけ。
エクスリュージョン思い出したw
蒸し返しすまんが、どうにも気になるんだ「例の件」
というわけで、答えてくれ
>>678
どのサイトだよ。
それより、プレステ3はOpenGLってホント?
開発がムチャクチャ楽になるんだけどw
こんな所に具体的に書けるわけないだろ。
あのサイトでわかる奴だけわかればいいよ。
VGAもCPUも別物だし、メモリもPS2より大幅増でしょ?
グラフィックもだいぶ綺麗になりそうw
つーより、PS2のライブラリがウンコ過ぎた。
>VGAもCPUも別物だし、メモリもPS2より大幅増でしょ?
SCEにへんな期待しない
絶対またギリギリに決まってる
779 :
仕様書無しさん:04/12/13 01:58:25
ヘタレデザイナーしかいない俺んとこには関係ねーや。
TVに出力する時点であの映像は無理、
D3、D4とか対応してくれるのかな?
>>779 なんだよ。
GPUはnVidia製使うんだ。
もう、PCでいいだろw
いやまったく
>>762 冬のソナタの曲もパクリだったって話だったと思ったが・・・
紅白出るとかで問題になってなかったっけ?
今のPS2の開発環境から、OpenGLに移れるならそれだけで満足だw
ネットワーク対応がどうのこうの言われてもこまるよな。
PCもってない家庭が茶の間まで電話線ひっぱってこれるとは思えない。
据え置機に変な幻想抱いてる開発者逝って良し。
次世代機が出るまでにモデリングソフト作ってる会社からリアルタイム用のシェーダエンジンが配布されて(DX用GL用)
開発者はモデルまわりはモデルロードしてシェーダロードしてアニメーションゲットして
終わりってところまでいっててほしかったが無理だったか。
つーことは、地道にこっから作るっきゃねーなw
まあ、いくらかましか。
>>779 正直、凄いと思った。
これ、PS3発売開始までキープだな。
>>789 >正直、凄いと思った。
なにが?
Unreal Engine3.0が?
そりゃすごいよ。
でもPS3にのるかどうかはただの記者の妄想だろw
変な夢もつなよw
UnrealEngineは開発ツールだろ、PS3に載らなくても
ライブラリを購入すれば
使えるんでねぇの?
つーか、ハードの性能差はソフトじゃ超えられないんだな。
>>793 笑って済ませて金もらって自分で買いに行けよ…
次あたりになると、ドッターだけでなくローポリ職人も氏にそうな予感。
最後の砦かとおもわれる遠景ローポリなんぞ
もはやライブラリ任せになりつつあるからな
って果物ナイフ全然関係ねえじゃん。刺したと思い込んで暗い気分に
なったじゃん。
しかも新聞社のサイトじゃないじゃん。ネタサイトじゃん…。
うむ、なぜ唐突にアレが張られたのが理解できんが
>鈍器のようなもの
めっさワロタ
しかし父親に並ばせといてあまつさえキレ出すとは・・・(#´,_ゝ`)
>>795 その頃にはローポリ職人は携帯系へ完全移行してくる予感
SCEにしてみりゃ自分が苦労してサードパーティー楽させる義理はないからな。
生かさず殺さずの手の抜き加減がいいのさ。
ドラクエ8をやって、ローポリはまだまだいけるな、むしろ、と思った次第。
>>802 そんな高度なことは考えてないよ、単にSCEの内部組織がハチャメチャなだけ。
805 :
仕様書無しさん:04/12/13 12:06:49
806 :
仕様書無しさん:04/12/13 12:14:13
面接官「特技は例の件とありますが?」
>>678 「はい。例の件です。」
面接官「例の件とは何のことですか?」
学生 「MSです。」
面接官「え、MS?」
学生 「はい。MSです。例の件でC#に大ダメージを与えます。」
面接官「・・・で、その例の件は当社において働くうえで何のメリットがあるとお考えですか?」
学生 「はい。それを知っていれば言語で痛い目を見なくて済みます。」
面接官「いや、当社にはたかだか開発言語の事で痛い目みるとかぬかすような輩はいません。それにそもそもコンシューマだとC#なんて使いませんよね。」
学生 「でも、MSの大本営発表にも勝てますよ。」
面接官「いや、勝つとかそういう問題じゃなくてですね・・・」
学生 「C#がおしゃか決定なんですよ。」
面接官「ふざけないでください。それにおしゃかって何ですか。だいたい・・・」
学生 「おしゃかです。死滅とも書きます。おしゃかというのは・・・」
面接官「聞いてません。帰って下さい。」
学生 「あれあれ?怒らせていいんですか?言いますよ。例の件。」
面接官「いいですよ。言って下さい。例の件とやらを。それで満足したら帰って下さい。」
学生 「運がよかったな。今日は宿題が忙しくて時間が足りないみたいだ。」
面接官「ワナビーは帰れよ。」
そんな長文を打ち込んでるヒマがあったら、一行でもコード書けと
808 :
仕様書無しさん:04/12/13 14:35:15
>>779 Half Life2が一気にショボゲーの部類に入りそうだなw
そうかなぁ・・・
個人的にはDOOM3みたいなテカテカのマネキン系のCGは好きじゃないな。
かといってドラクエみたいなのもあまり量産されて欲しくない。
DQ8は草木と衣装にポリゴン当てすぎ。
トゥーンシェーダのこと?>ドラクエ
元ネタが漫画のゲームはトゥーンシェーダのほうがいいな。
とりあえずハードの性能が上がってOpenGLも使えるなら満足だよ。
Ninja最高Ninja
813 :
仕様書無しさん:04/12/13 21:13:17
トゥーン?ただ、テクスチャをそういうふうに書いてるだけだろ
814 :
仕様書無しさん:04/12/13 21:55:59
学校の本屋のDirectXの入門書でも解説されてたw>トゥーンシェーダ
なんか2通りのやり方があるらしいけど、入門書で扱ってるモン。
815 :
仕様書無しさん:04/12/13 21:59:43
予備知識のない俺様が今即座に3通り思いついたわけだが。
トゥーン=段階的な陰影+輪郭描画
DQ8はあそらく後者だけ。
光を発する敵と並べてみたけど
トゥーンレンダしてるようには見えんが・・・・
つか、リアルタイム処理のトゥーンシェーダなんて誰も望んでないよ。
どうしたってモデリングソフトでレンダリングしたトゥーンシェーダみたいには
綺麗にはならない。ジャギってて汚いし見るに耐えない。
それでも使うのは開発者の自己満足、勘違い。
ゆめりあってゲームあったじゃん?
アレってトゥーンシェーダじゃないけど、
モデリングソフトでレンダリングしたトゥーンシェーダみたいに
綺麗にできてたじゃん。
これは開発者のセンスがよかった。
821 :
仕様書無しさん:04/12/14 00:38:24
そういや、DSの開発環境ってどうですか?>すでにやってる人
守秘義務
すくなくとも前のよりまし
でもあの動作はないよな 任天にしては珍しい
ところで、ゲームPGはあまり詳しくないんだが
コンシューマとネトゲはどちらもCかC++で組まれているのか?
昔はそうだったが最近だとHSPが多い、あとはDelphi
HSPって面白いよなーいろんな意味で。
あとはlisp、fortranも増えつつある
COBOLだよ! COBOLしかないって!
もじぴったんの辞書なんかはPrologで実装されてるよ。
人間の優しさの80%はHSPで出来ています。
たまに気分転換にBrainfuckやwhitespaceかな。
>>824 可哀想だから一応マジレスしておいてやるC++だよ。
というか今の所はそれ以外に選択肢がない。
ていうか、C++以外いらねw
コンシューマプラットフォームでCodeWarriorを使用しているのですが、
プロジェクトが大規模化してくるにつれリンク時間が無視できなくなってきました。
現状でリンクに3分くらいかかります。なんかいい方法ないかと探しているのですが、
有効な解が見つかりません。いい事例があったら紹介きぼんぬ。
地球シミュレータを借りる
フルコンパイルはしかたないとして。
肝になるヘッダ(更新するとかなりのソースをコンパイルしてしまうようなの)は腫れ物を触るように扱うことだろうなぁ
C++だったらかなりの確立で設計ミスだと思うが。オブジェクトそれぞれが一蓮托生になってたりしない?
コンパイル時間かかり過ぎならまだわかるが、
リンクでかかりすぎるのは単にシンボル数多すぎなんじゃなかろうか。
とりあえず普段の作業ではリンク時最適化切っとけば?
数%しかかわらんし。
>>835 オーバーレイ?
リンクで3分なんて信じられん。
RAMディスク作って、Temp をそこにしてみたら?
>>837 えーと、コンパイル時間は問題ではないのです。問題はリンク時間なのです。
ちなみにコンパイル時間は、
・プリコンパイルヘッダ
・ブリッジパターン
・Pimplイディオム
・先行宣言
等々を駆使し、依存性の排除によってかなり高速化されています。
いま問題になっているのは、リンクが長いことによって実行までのターンアラウンドが長く、
効率が落ちているといことなのです。リンクテクニックはあまり文献がなく、
正直どうすれば良いかがわからない、というのが実情です。
速いパソコンを買うのが一番低いコストで大きい効果を得られる。
>>835==
>>840です。
>>838 そうなんです。シンボル数が多いのはその通りです。
通常作業時はすぐにデバッガで追うことができるようにデバッグビルドしています。
なので、シンボルはアホみたいに多いです。
ですが、デバッグビルドは開発の上で必須です。(経験上)
>>839 RAMディスク! すばらしいです。その案を検討してみます。
>>841 痛いほどその重要性を上司が理解しているので、
現状で手に入りうる最高性能のPCを使っています。
dll使う。
よほどの特殊事情が無い限り、RAMディスクでは多分何も変わらんぞ。
だってOSがほっといても使える限りのキャッシュ利かせてるのが普通だもの。
erxどうよ。
846 :
仕様書無しさん:04/12/15 06:07:06
保守
>>842 > ですが、デバッグビルドは開発の上で必須です。(経験上)
俺のところは、デバッグシンボルは出力してない。デバッガもソースコード
デバッガは使わず、マシン語レベルで追えれば良いや、で済ませてる。
どうせ C++ で最適化すると、ソースコードとマシン語の対応とれないんで。
代わりにソースコード中に assert() ばらまいて、そこでバグをひっかける
ようにしてる。
CodeWarrior ではなく gcc 使ってるが、リンクは数秒だよ。
848 :
仕様書無しさん:04/12/15 08:59:24
>>844 キャッシュしても書き込み速度分の向上はあるよ。
しかし微々たるものなのは同意。
デバッグビルドでそんなにリンク時間かかるの? > CodeWarrior
何MBくらいのオブジェクト吐き出してるんだろう。
Pimplイディオムを駆使した結果クラス数が増えて大量のシンボルができた、
それで、コンパイル時間がリンク時間に転嫁されたとか?
と想像してみる。
3分は長すぎるね、大規模とはいえ。
ライブラリ間の循環参照みたいな無茶なことはしてないよね。
3分て長いの?
フルビルドに一時間とか掛かるから相対的にどうでもいいかも。
グリッドコンピュータで分散コンパイルとかやらないのかね。
その前にマルチコア対応コンパイラが先か?
>>854 グリッドなんて待たなくても、分散コンパイルなら rsh でネットワーク上の
ホストにプロセスばらまくだけで OK じゃん。
あとマルチプロセッサのマシン使ってるなら GNU make の -j オプション
調べとくとよろし。
インクリメンタルリンクってなにげに重要なのかしら。
>>855 IDEがシームレスにサポートしないと使ってあげない。
おまいら、そうやって俺に残された貴重な言い訳(「あ、今リンク中なんで、ちょっとタバコいってきまつ♪」)を潰そうとしてるな?
いいか?フルコンパイルってのはなぁ、プログラマに残された最後のオアシスなんだよ!
仕事中でありながらPCの前に座ってなにもしなくても許される。そんな至福の時間。
ゲームで遊んでても「今コンパイル中で他にやること無いんですよ」と切り返せる。まさに最後の切り札。
バグの原因がつかめず思い当たるフシも無い。そんなときの一縷の希望。
そ れ が フ ル コ ン パ イ ル な ん だ よ
それを、それを、、高速化だ? RAMディスクだ!? 3分が待ちきれないだ!!??
ごめんなさい、ボクが悪ぅございました・・・orz
>>858 俺も同意。
フルコンパイルに20分(最近じゃ25分ちかくなってる)近くかかるから
そのおかげでちょっとゆっくりできる。
あんまりいそいで仕事やる必要ないって。
この業界の他の業種と比較したら俺等がダントツで
働いてる時間多いんだからちょっとゆっくりしようや。
あんまりイスに座りっきりだと痔になるぞ(実際なったし日帰り手術代5万円ふっとんだ)
何?3分まちきれないって、馬鹿じゃねぇの。
イスたって柔軟体操でもやってろって。
うちの会社は仕事中に離席しても何も言われないから
>>859 > この業界の他の業種と比較したら俺等がダントツで
> 働いてる時間多いんだから
なんつーか、自業自得という単語が脳裏に浮かんだ。
>>860 連絡係以外なら
キッチリスケジュール通り進めていたら10分ぐらい姿消していても何も言われんのが普通じゃないか?
うちはプロジェクト末期でもCWでフルコンパイル5分程度だけどな。
P43GHzでデバッグビルドでオーバーレイもそれなりに使ってる。
なんか別の原因な気がするな。
>858
俺も同意。
>>835 リリース用のビルド(デバッグ情報なし)でも同じリンク時間?
バイナリデータを配列で持ってて、それをコンパイラが
ご丁寧にリストファイルに書き出したものだから、
ディスクアクセスが大変なことになったことがある。
>>862 ウチは、10分どころか、半日いなくても平気。
外出してても。
>>868 それは単に居ても居なくてもいい存在だと(略
それはさておき、
デバッグシンボルが多くてリンクに時間がかかりすぎる、てのは正直納得遺憾。
CWは漏れ自身は嫌いだが、奴のビルド性能は決して悪くない、つーか優秀なはず。
仮にシンボル数が多くても、そんなに時間食うのは別の理由がありそな気がする。
>>866 リリース用ビルドのほうが時間が早いとか言ってる?
自分は
デバッグ版はオプティマイズ off
リリース版はオプティマイズ on
で圧倒的にデバッグ版のほうがビルド早いんだが…
>>870 コンパイル時間とリンク時間の区別がつかない奴は黙ってろよ。
速いマシン、速い回線があなたから休憩時間を取り上げる。
遅いマシン、遅い回線があなたから休憩時間を取り上げる。
とマーフィーを思い明日。
コンパイル時間は短いほうがいいに決まってる。
「貴重な休憩時間が〜」とかって理解できない。
早く仕事終らせて早く帰ったほうが休めるのに。
ごめん、ホント理想を語っちゃった
コンパイルが速くなるほど、生産性があがるほどおまいらは安くなっていく・・・・。
理想:
>>873 現実:早く仕事終らせると仕事を振られる。
厚生労働省の通達に、会社は従業員が一時間につき10分は画面見ないように
仕事させること、ってのがあるから、ちょうどいいんだよ。
>>835 です。仕事中こっそり。
>>866 いろいろと試したところ、リリースビルドだと圧倒的にリンク時間は早くなりますね。
やはり、C++のシンボルがあふれてる感じです。デバッグビルドで実行ファイルが
300MB近くになってます。(リリースだと数MB)
>>870 コンパイル時間ではおっしゃるとおりです。デバッグビルドのオプティマイズoffの
コンパイル時間は速いですね。
コンパイルが中途半端な時間だとやる気しなくなるというか、ストレスたまるなぁ・・・。
激しく長いか、一瞬じゃないと嫌だ。
コンパイル開始と同時にうちわを手にしていたあの夏。
当然、網蛾をあおいだわけですが。
883 :
仕様書無しさん:04/12/16 18:20:57
理想:
>>873 現実:早く仕事終らせると追加仕様がくる。
>>870 俺のところは optimize off だと、すでにがメモリ足りない今日この頃。
どんな環境でもプログラマの仕事量は一定である。
| //ヽ/i
!! 、ヽヽ//ノ
ヾ、 〃 iヽ _/ /i ヽ
| ヽr', ヽ/ i }
街 | ヽ / i }
に の |二二二二二} イ
お 中 6――□ ,□/―――ヾ
= う 心 = \ /´_..、--―┴ヘ !!
だ で r'〃 ̄ ̄ ̄ __.-<\} ヾ、 〃
ち {:.|l _....--―T ̄ .._ |
は ハ:.ゞ_、´ソ:! | `T "j ハ や
! r、:.:.:.:.:.:.:.:j |/ ノ ! / ッ め
〃 ヾ、 {三:::::.:.:.:.イ j ! /= サ て =
!! _.ノ´:.:.:::::::/ / ! / ン く
r':.:..:.:.:.:.:.;r' `ニ´ / '/_ ! れ
/ゝ、_/!{ ∠ { \ `ヽ
! : : : / ヾ / \ヽ二二ン ト、 / 〃 ヾ、
! : r'´ / ヾ\ \ \ !!
r┤ _イ _.\ |. \ ヽ \
ヘ_ゝ∠:_ノー<´:::::::::\ |:. \ ! ヽ
l::::::::::::::::::::::::ノ`7| \ ! ハ
l::::::::::::::::::;:イ、_/:::| 〉|! |
l:::::::::::::::f|≡!|::::::| / !| j
いやぁ、久々につまらないバグ埋め込んじまったよ
int Dat[2] = { 1, 2 };
int Pt = 0;
int GetDat() { return Dat[Pt++]; }
main() { printf("%d,%d\n", GetDat(), GetDat()); }
1,2を期待してたのに、ひっくり返るんだもんな。
アセンブラジジィにはC言語は高度すぎるぜ。
ひっくり返る保障もないんじゃなかったけ?3になる可能性も。
>>835 です。まだ仕事中です。
>>880 ごめん。書き間違えました。300MB近くメモリ使用量が増えて、生成された実行ファイルは
16MBぐらいでした。ほとんどメモリ上でリンク処理をしているらしく、RAMディスクはあまり
効果がありませんでした。残念!
なぜまずいのかすぐに分からなかった。_| ̄|○
>>871 少なくとも洩れの Visual C++ にはリンク時のオプティマイズもあるんだが?
だからコンパイル/リンクといわずにビルドといってるんだが?
>>889 300MBの実行ファイルは想像を絶してしまったが、16MBと聞いて一安心(^_^;
にしてもCWのビルド時間ってこんなに遅いものなの?
>>892 CodeWarriorの話してるのに・・・・
894 :
仕様書無しさん:04/12/16 23:15:33
プログラマーになるにはどの学科に行けばいいんですか?
京都コンピューター学院
>>893 コンパイル時間とリンク時間とビルド時間の区別がつかない奴は黙ってろよ。
897 :
仕様書無しさん:04/12/17 00:13:09
ビルド時間=ンパイル時間+リンク時間で良いか?
898 :
仕様書無しさん:04/12/17 00:14:23
ンパイル!ンパイル!バイン!バイン!
900 :
仕様書無しさん:04/12/17 00:37:45
スレが盛り上がっているところ、申し訳ありません。
ドラクエ8にキラーパンサーという乗り物がありますが、これを呼び出すときのムービーついて
お聞きしたい。開発者の説明によれば、このムービーの役割はロード時の暗転を防ぐためと
いうことですが、町からフィールド上に出たときや、鳥になって空を飛ぶときのロード時間に
比べて長く感じます。それに素人目にはキラーパンサーのデータを読み出すだけでよいような
感じがします。
本当に開発者がいうように、ロードするのに時間がかかりすぎてこのムービーが必要になって
いるのか、ゲームプログラマの目から見てどう予想されますか?
ageるな
>>889 リンクに3分なんて信じられんから貧相なマシンを使ってると思ってRAMディスクと書いたまでで、まともなマシン使ってたら効果なんて無いだろうな。
オーバーレイのターゲットはいくつくらいあるの? 1つ当たりどの程度リンク時間かかる?
誰かが言ったようにerx試してみたら?
>>900 演出が長すぎるという話でいいのかな?
・演出として意味のあるカットの長さ
・DVD読み込みのリトライがおきても十分な長さ
という理由だろう。
単に演出としての長さの問題でしか無い気がするなあ。
>>902でFAなんじゃないだろか。
>>880 それ、リンク時最適化の影響だよ、やっぱり。
具体的にはデッドコードストリップと、関数呼び出しプロトコル類の調整による最適化。
で、疑問なんだけど、デバッグ用のシンボルが多いと言うが、そのデバッグ用のシンボルって奴、
大半はリリースビルド時にははずしておけるものじゃない?
ちょっとした関数や定数類はインライン化される様に組んじまえば、リンク時に
直接相手にしなければならないシンボル数は事前に相当減ってるはずなんだけど…
905 :
仕様書無しさん:04/12/17 07:39:10
>>894 プログラマーなんか高卒でもなれる。
とりあえず東大行っとけ。
>>904 おかしいだろ。
「リリースビルドだと圧倒的にリンク時間は早く」なるんだぞ。
>>904 CodeWarrior ではなく gcc だと、マップファイル書き出すと動作がきわめて
遅くなるコトがあったなぁ。
>>894 プログラマーは、プログラムを作る人だから、
プログラムを作ればいい。プログラムを作る事に対して、
特別な許可も必要ない。開発環境は金を出せばそろう。
>>889 >300MB
メモリースワップしていないですか?
あれが起こると極端に遅くなるよ、解決策はメインメモリーの追加、RAMディスクは削除がいいと思われ。
>>911 いくらなんでも、それでご飯食べてるやつに言うレスじゃないだろ。
ゲーム方面行くなら数学とか物理とか工学とかのほうがいいんじゃねーの。
プログラミング自体は独学で十分だし。
>>913 >ゲーム方面行くなら数学とか物理とか工学とかのほうがいいんじゃねーの。
いらないいらないいらないいらないいらないいらないいらないいらない
いらないいらないいらないいらないいらないいらないいらないいらない
いらないいらないいらないいらないいらないいらないいらないいらない
いらないいらないいらないいらないいらないいらないいらないいらない
いらないいらないいらないいらないいらないいらないいらないいらない
いらないいらないいらないいらないいらないいらないいらないいらない
>>913 会社によって違う
某社では物理ができない奴は開発部隊になれないといってました
某社では入社してから覚えればいいといってました
某社ではそんなものよりワードやエクセルの資格を取りなさいといってました。
とりあえずゲーム系は提出物が勝負だから気合入れて作っておけ
大手ならSPIとか筆記(PC系)で大半が死滅するけど
917 :
仕様書無しさん:04/12/18 03:00:13
>>某社ではそんなものよりワードやエクセルの資格を取りなさいといってました。
プログラマに必要か?
>>917 意志疎通を行うために必要なツールとしている会社も、
1%ぐらいはある。その程度の常識。
っていうか、あんな、バグをユーザーに回避させる
ようなソフトよりも、日本人なら一太郎だろ!(藁)
>バグをユーザーに回避させるようなソフト
???
>>918 どっちもバグで蹴られますが、何か?まあ、
あんなモノの検定がある事自体が信じられんのだが・・・
ゲームと関係ない会社だろw
偽装派遣とかw
922 :
仕様書無しさん:04/12/18 03:46:37
>>919 下手に削除機能を用いると、罫線があちこちにうごきまくって、復帰困難に陥る。
そもそも、罫線機能が非常に扱いづらい。インデントが簡単に狂う。
タブのシート名を少しでも長い名前に変更すると落ちる。・・・・・・etc
>大手ならSPIとか筆記(PC系)で大半が死滅するけど
SPIはともかく、筆記ってどんなんでるんでしょ?(難易度とか)
当方、田舎なもんで試しにうけることも辛いので情報あったら教えてほしいです。
>>924 数年前のN社で数学とLinuxとプログラムの問題がでた
どれも基本的なのばっかりだったよ
基本情報やLPIと大差ない程度
>>925 ありがとうございます。
なるほどぉ、でもそれって新卒用ですかねぇ。
中途の技術も同じようなもんなんですかねぇ。
とりあえず、今日は寝ます。
つか、LINUXは死ねるなぁ。
DOSプロンプトならかろうじて覚えてるがorz
そもそもプログラミングできてワードやエクセル使えないヤツなんて存在するのか?
チャッとF1キーでも押してその場で使っちまうだろふつー。
>>927 ただ文章を打つだけでは使えるっていうレベルじゃない
>>928 ただ文章を打つだけのレベルで留まるようなヘタレプログラマがいるのか?
>>928 段組して文章を打つ以上のことをするには、
大抵のプログラマはデザインセンスが足りない
ところで、エクセルだとVBAは良く使うが、
ワードでVBA使うのってどんな時?
MS Accessとか使うんじゃない
顧客への年賀状トカ (藁
>894
重要なのはどの学科に行くかではなく、そこに行って自分が何をするかだ。
その方向に専門的じゃない学科を選んだ方が有利、とか聴いたことがある
全て自分で勉強しなければならないから向上心がある、とか
>>923 最近罫線が消えないようにする技覚えたよ。
エクセルって意外と難しいぜ。
ゲームのデータをエクセルで管理してんだけど
罫線もしっかりつけないとデータずれちゃうから意外と手間。
あと、仕様書かくのに社内の共通フォーマットにワードの
アウトライン機能が使われてるから、はじめはわけわからんかった。
こっちはなれるまで一ヶ月近くかかった。
>>935 問題は本職でもねぇのに意外と手間って部分だと思う。
個々の問題に目を向ければ簡単だけど全部知ってるのは難しいってそんなとこだろ。
要は覚えるのがダルイw
>>934 >最近罫線が消えないようにする技覚えたよ。
教えちくり、どうやってやるんだ?
Excelの最大の欠点はバグトラッキングがむちゃくちゃ不得手だと言うことだな。
Gem3 の日本語版出てたんだね。買ってきますた。
なんか理由があって3は出せないんじゃなかった?
気になるな。
942 :
仕様書無しさん:04/12/18 13:28:14
>>914 新人の皆さんは「使い捨て」にならないように、
数学と物理を勉強した方が良いですよ。
学校を卒業したら三角関数なんて使わない
そんなふうに考えていた時期が俺にもありました(AA略
>>942 そう?技術で給料上がった例があるならお目にかかりたいねw
>>935 ローカライズの講演で「台詞の管理にはエクセルが最適」と述べられていましたよ。
>>945 つか、データ全般でエクセルは使えるだろ。
カンマ付きCSVで吐き出せ!
もちろん直接ゲームでCSVファイルを使うんではなくて
変換をかけてからって・・・いわんでもわかるかw
>>946 直でカンマ区切りテキストを拡張子だけ変えて使っているのをみましたね。特定はしませんが。w
>>つか、データ全般でエクセルは使えるだろ。
適当にハードつなげてマクロ組んでデータ収集しますね。……うちだけ?
>946
VBAつかって変換すれ
というか、データ打ち自体はプログラマの仕事ではないわけだし、
仮に.xls から直接エクスプートするツール作るにしても
内部フォーマットまでは資格の勉強ではわからんわな。
進行状況をOpenOfficeで書いてる自分は負け組。
>>944 技術は利用するもの
持ってるだけじゃ意味がない
査定に影響するように利用汁
某社でデータフォーマットの設計までプログラマの仕事じゃないらしい。
ゲームデザイン担当の奴が一所懸命VBAのお勉強してたよ。
外部仕様を平プログラマに任せる会社はないと思われ
>>951 >>ゲームデザイン担当の奴が一所懸命VBAのお勉強してたよ。
ぶっちゃけ、ゲームデザインはPGのスーパーセットだとおもうのだが?
>>951 こういうのちゃんとできてればいいけど
中途半端な知識で中途半端にやられるのが一番頭に来る。
もちっというとエクセルを使うことによってお手軽にデータを整理できるのが
一番のみそなのにVBAのデバッグまで必要になったら本末転倒にもほどがある。
いまのところエクセルで変換や計算の類をするのは開発者(誰かの)自己満足意外なにものでもないと思う。
>>956 >>いまのところエクセルで変換や計算の類をするのは開発者(誰かの)自己満足意外なにものでもないと思う。
そうかなぁ。
簡単な関数を10〜20個くらい使うくらいならそうでもないと思うが、
プログラマーとしての素人さんがせっせとマクロ書いてる所を目撃すると・・・
素人つっても学生時代に何年もやってるだろ?
ゲームには決まった作り方が無いからね。
規模とか内容とかによっても一番良いやり方は違ってくるし、
それぞれの経験でやり方が変わってくるのは仕方ないかも。
製作終了と同時に辞める奴も多いからノウハウも
なかなか蓄積されていかないしね。
>>960 > 製作終了と同時に辞める奴も多いからノウハウも
> なかなか蓄積されていかないしね。
人が辞めるってのが、会社によってどれだけの損失になるかを
分かってない人多いんだよねぇ。
同じ一人月でも、チーム組んでしばらくたって円滑に仕事が
進むようになった人と、来たばかりで右も左も……って状況
だと、生産性が全く違う。
人件費抑制に神経使う前に、離職率押さえる方法を考えて
クレ>人事
>>961 >人が辞めるってのが、会社によってどれだけの損失になるかを
>分かってない人多いんだよねぇ。
分かっているからこそ辞めるわけですよ。
>>961 順序が逆です。
まずはヒット作連発してからでかい口を叩いてください。
964 :
仕様書無しさん:04/12/18 23:03:35
>そう?技術で給料上がった例があるならお目にかかりたいねw
>
バーチャ・グラツー・無双の開発チーム
ゲームプログラマのレベルは低いよ。
GameProgrammingGemsレベルのことすら実践できない奴らがほとんど。
>>965 そんな、自分で言ってて悲しくないのか?