07/06/07 00:55:02
>>259
インスタンスの所在が把握しにくい上に
ガベージコレクタなんて走るから思いっきりゲーム向きじゃない
263:仕様書無しさん
07/06/07 01:16:41
>>259
春予定だったのが延びて夏になっていたが、これも伸びるかもしれない
暫らくは、アマ用ので遊んでなさいといった所かと。
264:仕様書無しさん
07/06/07 01:23:20
>>262
あれはGCが走るから、じゃなくて、GCが走らないように組むんだぜよ。
265:仕様書無しさん
07/06/07 01:49:02
>262
ゲームpg向きじゃないな、喪前。
266:仕様書無しさん
07/06/07 02:20:27
CGは慣れ次第でmalloc以上にできるからな、というか今時GCが問題とか言っている奴、mallocを自作した事も無いんだろな
それよりVMXを直接組めないのが痛い。
267:仕様書無しさん
07/06/07 04:01:43
>>266
GCは開発効率を上げる為のもので、実行効率はよっぽど変なアーキテクチャ
相手じゃなきゃ上がらないよ。「慣れ次第であまり下がらずに済む」程度だね。
VMXの方が寧ろJITオプティマイザ次第でC++で組むより速くなる可能性がある。
直接組んだのにはかなわないだろうけどね。
268:仕様書無しさん
07/06/07 07:21:18
ビット演算ないから移植にも向いてないな
269:仕様書無しさん
07/06/07 09:51:18
ごめん。ちょっと教えて。俺はアセンブラ時代のゲーム屋で今は別のもの作っているのね。
当時は開発効率を度外視して実行効率を上げていたのだが、昨今の開発ではゲーム開発でも
開発効率優先になっているの？もしそうなら昔の職人技みたいな要素をゲーム屋上がりに求める事
ってできなくなっちゃった事なの？
270:仕様書無しさん
07/06/07 10:15:03
>>269
「アセンブラ時代」の実行効率を上げるテクニックは、コンパイラが前提になっている
今の環境ではほとんど役に立たない。それどころかコンパイラの最適化を阻害して逆に
効率を下げる結果になることもある。今は実行効率を得るためにもコンパイラの
最適化を阻害しないように言語に関する正確な知識を持つことが大事。
別にどっちが大事というわけじゃないけど、開発効率を犠牲にして得られる実行効率の
向上っていうものがそもそも発生しにくい。
ハードべったりのライブラリを書いてる人ならアセンブラレベルの技術が身に付いて
いるだろうけど、ただのゲーム屋上がりってだけだと、そんな人にはめったにお目に
かかれないだろう。むしろゲーム屋くずれのパチンコパチスロ屋のほうが期待できる
かもしれない。
271:仕様書無しさん
07/06/07 10:22:43
>>269
いまどきのCPUだと、昔やってたような最適化コード書いても体感速度変わらないし、
コードが汚くなるだけで敬意される。
でも職人芸が無くなったわけではないけど。
扱うデータが大量になったから、ポイントポイントを抑えて重くなるところを最適化はあるし、
3D,ネットワークとか昔よりプログラムでやるべき幅が広がったので、
速度面以外で職人芸を発揮する場所はある。
272:仕様書無しさん
07/06/07 13:56:33
>>270-271
なるほど。ありがとうございます。
ゲーム開発も変わったのですねぇ・・・昔に比べれば楽になったって事なのかな？
273:仕様書無しさん
07/06/07 14:30:02
>>272
PCゲーっぽいな
PCゲーは昔より糞になったぞ
全ては糞OSのせいだが
274:仕様書無しさん
07/06/07 14:31:34
今は、速度より安定化の為に労力が費やされるのだよ
275:仕様書無しさん
07/06/07 14:51:56
単にユーザーの要求のレベルが上がっただけじゃね？
276:仕様書無しさん
07/06/07 15:42:48
PCは昔より遥かに楽だろ？
性能も互換性も随分上がったし、DirectXもシンプルになったし。
277:仕様書無しさん
07/06/07 16:32:16
>>275
というかゲームプログラミング自体の規模が大きくなったことが原因かと。
昔は単にCPUパワー足らないからアセンブラで手動最適化コードを書く必要があった。
ゲームの規模自体はたいしたことないので高速化のためにトリッキーコード書いてもかまわなかった。
今は規模がでかいから、ちゃんと設計して読みやすいコード書かないと破綻する。
その代わりCPUパワーが上がったから、昔ほど最適化コード意識する必要がなくなった。
278:仕様書無しさん
07/06/07 16:33:13
>>273
コンシューマやアーケード物が大半で、あとDirectXがまだGameSDKと呼ばれていた頃から
DirectX2が出た頃まででゲーム屋やってました。今は別物の開発やってます。
正直、マイクロソフトが作るOSの上でなにかを作る行為がむなしくて・・・
いまでも安定させる為の努力って大変みたいで、お疲れ様です。
もう、開発の現場に戻れるほど若くはないので、若い人にがんばってもらって
楽しい奴を期待しております。ではでは。
279:仕様書無しさん
07/06/07 16:37:47
年金記録照合のプログラム、ＮＴＴデータと日立に委託
ｽﾚﾘﾝｸ(news板)
280:仕様書無しさん
07/06/07 22:11:49
>>272
俺はちょっと違う意見だな
確かに馬鹿みたいにメモリマップ作って最適化する必要は無くなったけど
サイズの大きいインスタンスを意識しないで管理しきれるほどは楽になっていない
それで規模が大きくなっただけに基底部分を重く作ってしまうとやっぱり相乗的に重くなる
確保したワーク（メモリ）はやっぱり開放しないで使いまわす程度の考慮は必要
文字列なんて一文字増えるたびに領域開放して再確保してなんてやっぱりできない
その程度のもの
だからＣ＃やＪａｖａはやっぱりまだゲーム開発には向かないと思ってる
281:仕様書無しさん
07/06/07 23:56:28
>>280
実際にパフォーマンスを計測してみたほうがいいかもよ、今の世代のハードは一番重いところが予想外の部分になっているケースが多い。
それにスレッド駆使し始めると、マジでスレッドセーフに作られたガベージコレクタ欲しくなるから。
これがないとコアの使用率全然上げられないし処理分散できない、無理してやろうとするとスレッドに関わる各種問題の回避のためのコードの山になる。
こうなると高速化のために低速化を余儀なくされるコードの大量投入という意味不明な事になってしまう。
282:仕様書無しさん
07/06/08 00:07:32
職人コードが書けたのは、命令一つ一つに固定のクロックが対応していてメモリーのレイテンシやバスバンド幅を意識する必要が無い時代までだな。
今はそんなコードは書けないし、無理して書いたら型番変わるたびに不具合が発生してしまう問題ソフトになってしまうね。
283:仕様書無しさん
07/06/08 00:41:57
>>281
駄目だなぁ・・・
俺が>>280で挙げた例はゲームがストップしてしまうぐらい影響がでるもの
こういうのさ、「ちょっと気をつけていれば大丈夫」だと全く意味がないと思う
「全く気にせず使っても大丈夫」までクオリティが上がってはじめて意味があるものだと思う
ガベージコレクタは気を付けてれば大丈夫
じゃなくて
ちょっとでも気をつけなきゃいけないんならはじめっから全部自分でやるよ
って感じ
てか、その方が楽だし、しっかり管理できる
この状態が続く限りＣ＃とか正直使えないと思う
後で「実はこうしなきゃならなかった」ってのが一番困る
284:仕様書無しさん
07/06/08 00:56:24
>>283
そのぐらいは、跡でうんぬん言わずに勉強して欲しいかもw
それに、たまにふっと深いガベコレが走る事があってもゲームに支障はないだろうし
支障が出るほどのガベコレするコードを作ろうとすると、それはもう見た目に分かる怪しい位コードになるし
それより暫らくほっといたり、ゲームの進行順序でメモリーリークやスラッシング問題で止まってしまうコードの方が余程悪いかと。
つか、最近増えているしな、この種のハングアップと思わし現象が起こるゲームが。
285:仕様書無しさん
07/06/08 00:58:32
間違い
見た目に分かる怪しい位コードになるし > 見た目に分かるぐらい怪しいコードになるし
286:仕様書無しさん
07/06/08 01:04:55
>>269
>（略）昔の職人技みたいな要素をゲーム屋上がりに求める事
>ってできなくなっちゃった事なの？
昔の職人技を求めることはできないだろうが、今の職人技を期待できる。
外れが多いのは今も昔も変わらないから、外れを引いても非難するな。
287:仕様書無しさん
07/06/08 01:08:07
>>284
自分だけならまだしも他の人間もいるしなぁ・・・
正直、どこで起きてるかわかってても直さないで出しちゃうだろうね
こんなのお金に絡む部分じゃないし
弄ったことによるバグのが怖い
288:仕様書無しさん
07/06/08 01:15:24
それといままで蓄積したC++の資産がたんまりあるから
正直C#になんか絶対以降なんかできねぇｗ
ビット演算ありまくるのになくすなよ＞C#
移植のために残しておけって感じ
なんで最近の言語作る奴って移植仕事多い環境たくさんあることを知らない無知な奴ばっかなの？
アホが気分で言語作ってんの？
289:仕様書無しさん
07/06/08 01:17:21
あらゆるシナリオに対応できて管理の必要がなくパフォーマンスが出せなきゃ駄目、
なんてのはお花畑の発想だと思うけどねぇ。
プロファイルで取得できる情報が充実してるってのがマネージな世界のメリットかしら。
とはいえヒープ確保が起きるからforeach文禁止とか見るとちょっぴり萎えるなやっぱり。
290:仕様書無しさん
07/06/08 01:26:53
管理せずとはいかんだろうけど、全部管理しろとか言われたら勘弁して欲しいかも
C++ってそういう所が嫌だ
291:仕様書無しさん
07/06/08 01:32:58
>>289
そこまでする必要はねぇけど
すくなくとも過去の反省やらアリガチなもんもサポートしとらんようなのは論外だと思う
>>290
そういうのノウハウあると結構楽なんだけどな
あと、メモリとか細かいところをちゃんと管理することで全体の質があがることもあるよ
292:仕様書無しさん
07/06/08 01:42:30
C#やJavaのような言語で、細かいメモリー制御をする場合、メモリープールならぬオブジェクトプールを作るといいよ
それでもって作った直後にガベージコレクト手動実行してプールを旧世代入りにしてやるんだ。
これでプールは新しい世代のガベコレの対象から外れる、処理負荷軽減、でもきっちりガベコレの管理下。
293:仕様書無しさん
07/06/08 06:19:37
>>292
誰もそんなこと聞いてないけど
突然どうしたの？君
294:仕様書無しさん
07/06/08 09:16:26
C#のGCは完全にスレッドセーフだから何も気にせずに使える
295:仕様書無しさん
07/06/08 09:36:54
>>280
なるほど。
私もクソみたいな.NETや目標はすばらしいJAVAとか使っているけど、
これでリアルタイムなゲームを作ろうとする事を考えたときに、
教科書通りの正規のやり方ではパフォーマンスでないし、
非正規なやり方ではバージョンアップ後には動かなくなるだろうなぁ・・・
なんて思ってた。
やっぱり、現場ではC/C++が多いのでしょうか？
296:仕様書無しさん
07/06/08 09:56:15
普通にリアルタイムゲームは作れるでしょ。
パフォーマンスが堕ちるのは当たり前、それを認識した上で
.NETならではのサービスを受けたいかどうかだべ。
現場で使われてないのは間違いないけどな
297:仕様書無しさん
07/06/08 09:59:03
スレらしくなってきたな
うんこルーチン以来だな
298:仕様書無しさん
07/06/08 09:59:13
CLRがアップデートしていくのが怖いのは私だけ？
299:仕様書無しさん
07/06/08 10:55:14
>>296
パフォーマンスが落ちても.NETの恩恵を受けたいと思うケースってあるのかな？
ユーザー側がWindowsUpdateとかでマイクロソフトは互換性あるから大丈夫っていったところで、
CLRの動作が変わるのは想定内だしね。
300:仕様書無しさん
07/06/08 14:31:56
アップデートはデバッグやって下さいって意味だから、バグらなきゃそれがバグだよ。
301:仕様書無しさん
07/06/08 21:50:32
>>299
スレとはあんま関係ないけど.NETはSide-by-sideちゅー技術っちゅーかバージョン別全部ぶち込みというかそんな仕組みで
基本的に動作は変わらんよ、接続先ライブラリを切り替えるには exe のあるフォルダにxmlで、このライブラリはこのバージョンを使うとかいった情報を置いてバージョン違いに対応する方式。
そんな訳でプログラマからの見てくれのCLRの動作は固定
302:仕様書無しさん
07/06/08 21:59:52
まぁオナニーは一人でやってくれ。
303:仕様書無しさん
07/06/09 06:41:24
>>301
ここにいる連中は、「マイクロソフトが保証する」所を信用していないと思うよ。
なんども騙されているから
304:仕様書無しさん
07/06/09 07:23:04
>>303
金ありゃなんでもできるってのと
現実問題いろいろ絡むと例え自分でやったとしても矛盾が出てくるから
正直、強くは言えんな
305:仕様書無しさん
07/06/09 08:00:40
ゲームPGがC++においてスマートポインタを使うのは
事実上の標準みたいなもんになっていると思うけど、
その上の、メモリプール兼コンパクション可能なGC的なもの（これ何て言うんだ？単にGC？）
っていうのはどの程度普及しているものなの？
私のところの開発では、それは社内ライブラリに整備されているのだけど、
出来ればオープンでいけてるライブラリを探して、個人で使ったりしたいと思ってる。
誰か、オススメあったら教えてくれろ。
例えば、単純なGCであろうと思われるBoehmGCはやたら検索で出てくるが、これどうなの？
使ってる人居る？大分古いようだけど。
306:仕様書無しさん
07/06/09 08:10:44
>>305
スマートポインタなんか使いだしたらバグが止まらんな
307:仕様書無しさん
07/06/09 08:23:58
>>305
俺はスマートポインタ使わずにハンドル使ってるな。
308:仕様書無しさん
07/06/09 08:31:51
「気にする必要のない構造」が
気が付くと「管理できてないだけ」に代わるのなんて開発してると時間の問題なんだよな
どっちにしてもめちゃくちゃになるなら使ったほうがいいかもしれんが
いままで厳密に管理してきてうまくいってるなら使わないほうがいいと思う＞スマートポインタ
ソース汚くなるし
こういうメモリまわりのお便利ライブラリってあんまり役に立つのみたことない
なんつーか、考えが浅い思考で作ったもんしかない
本質に踏み込んで真の解決をしようと挑戦した跡がない
309:仕様書無しさん
07/06/09 08:47:53
スマートポインタってそんなにヤバイんですか…
やっとboostとかに参考にして作った軽量shared_ptrとか使い慣れてきたんですが
そんなの使うよりは生のポインタを上手く管理する手法を考えた方がいいということなんですね
やっぱ奥が深いです…
310:仕様書無しさん
07/06/09 08:53:07
>>309
いやぁｗ
その辺は使い手次第ってこと
そうやって安易になんでも鵜呑みにしてしまうのは駄目だぜ
スマートポインタ云々とは別問題
311:仕様書無しさん
07/06/09 09:36:50
おまいらゲームPG的ブログやらんの?
いろんな意味でリスク高い割りに得るもんがあまりないかね。
312:仕様書無しさん
07/06/09 10:17:03
とはいえ、スマートポインタ無しではやり切れないレベルになってもきているけどね
この間スマートポインタを使ったコードを無しに書き換えたらコードが3.7倍に膨れ上がってたまげた。
313:仕様書無しさん
07/06/09 10:26:20
>>305
どぞ
URLﾘﾝｸ(www.namikilab.tuat.ac.jp)
個人的な感想としても、ゲーム用なら boost::shared_ptr / boost::weak_ptr の組み合わせがベストだと思われます。
それに、これらのスマートポインタは次期C++の標準化に入る予定なので、いずれコンパイラ付属の標準品と交換する事も想定下にいれられますので保守性の面でも有利かと。
314:仕様書無しさん
07/06/09 10:28:03
>>312
コード量にそんな差はでないでしょ？
また、スマートポインタにしたからってそんな差が出てしまうソースはなにかまずい
315:仕様書無しさん
07/06/09 10:29:28
scoped_ptrは要らない子ですかそうですか
316:仕様書無しさん
07/06/09 10:32:42
>>314
でるでる、スマートポインタはメモリの管理だけでなく汎用リファレンスカウンタとしての機能もあるし。
さらにマルチスレッド・マルチコアになると、オブジェクト所有権譲渡が高度になってくるのでますます差が出る。
317:仕様書無しさん
07/06/09 10:33:58
>>315
誰もそんな事いっていないって、auto_ptrだっていい子だよ
318:仕様書無しさん
07/06/09 10:39:19
たかが自動delete機能をそんなに崇拝するのか疑問なんだよね
319:仕様書無しさん
07/06/09 10:43:36
関数内でmallocとfreeを実行するようにするだけの話だし
使って何がおこるってわけではないよな
さすがにコード量が３倍になるなんてないだろ
320:仕様書無しさん
07/06/09 12:34:50
スマートポインタイラネって言ってるのは、例外安全性を気にしない人なんだろうな。
気にしだしたら、スマートポインタ無しでやってられるわけがない。
321:仕様書無しさん
07/06/09 13:09:43
Gemsのハンドルマネージャー派は少数派なのか
322:仕様書無しさん
07/06/09 13:12:26
使ってるよ
323:仕様書無しさん
07/06/09 13:16:42
ハンドルってのはポインタの置き換えであってスマートポインタとは関係なくないか？
ハンドルがクラスで表現されててデストラクタで自動解放とかするの？
324:仕様書無しさん
07/06/09 15:37:08
>>320
何？例外安全性って？
一般的じゃない言葉をいきなり使い出すあたりあんまり人に説明するの上手くないでしょ？
とりあえずコンストラクタで落ちるとかいう話だったら
コンストラクタにそんな処理させんなで終了だけど？違うこといってる？
325:仕様書無しさん
07/06/09 15:53:50
>>324
オマエの C++ は１０年遅れてる。
とりあえずググレカス。
326:仕様書無しさん
07/06/09 16:01:40
>>318
殆どの場合テンプレな開放処理を書かないで良いってだけでありがたい
327:仕様書無しさん
07/06/09 16:04:00
基本的な考え方が生まれたところから考えれば１０年とも言えるだろうが、
一般的に知られるところとなった時から考えると１０年は言いすぎ。
328:仕様書無しさん
07/06/09 16:26:17
些細なことに拘りすぎる奴は大抵たいしたこと無いというか、
矛盾だらけで殴りたくなる。
もう切れそうだヤバイ。
329:仕様書無しさん
07/06/09 18:00:16
人に何か話すときにけんか腰はよろしくない。
周りとトラブルおこしてないか？
いや、起こしてることすら気付かないか。
330:仕様書無しさん
07/06/09 19:00:43
>329
そういう風にイイ子ぶってると、そのうちみんなから相手にされなくなるよ。
331:仕様書無しさん
07/06/09 19:01:17
>>329
レスｔｈｘ！
いいよクビになっても。
矛盾だらけで論理破綻してる奴と仕事なんて出来ないから。
来週は定時帰宅して気分転換しようと思う。
332:仕様書無しさん
07/06/09 20:11:14
GK必死だな。
そんなことしてもPS3は売れねーからｗ
333:仕様書無しさん
07/06/09 22:08:32
C++使っておいて例外安全性を一般的な言葉じゃないとか真顔で
言われちゃうと同業者としては悲しくなるな。
ターゲットのコードでは確かに使用機会殆ど無いけどさぁ。
334:仕様書無しさん
07/06/09 22:15:14
>>333
>C++使っておいて例外安全性を一般的な言葉じゃないとか真顔で
泣いていいよｗ
URLﾘﾝｸ(msdn.microsoft.com)
>C++ 標準規格では、例外安全性という言葉を（auto_ptr のコンテキストで）使用していますが、
>その定義は示されていません。C++ に精通している人たちの間でも、この言葉は、使う人によって違うものを指します。
335:仕様書無しさん
07/06/09 22:22:22
>エンティティが例外を、キャッチあるいはスローしても、その例外が持つ
>パブリック セマンティックが保証されるなら、
>そのエンティティは「インターフェイス安全性」を備えています。
>インターフェイス安全性を備えているエンティティは、
>それらセマンティック保証の効力に応じて、
>クライアントに対して例外をまったくリークできない場合があります。
日本語でおｋ
336:仕様書無しさん
07/06/09 22:24:36
>>335
>22:22:22
すげー、フィーバーしてるぞ
337:仕様書無しさん
07/06/09 22:25:02
M$っていつまで経っても日本語うまくならんよな。
338:仕様書無しさん
07/06/09 22:32:02
>>334
リンク先よく見ろ。
> 2000 年 1 月 6 日
だから遅れてるってんだよ。
339:仕様書無しさん
07/06/09 22:32:54
>>334
勉強になるな＞ＭＳＤＮ
「バランスの問題」のところとかたしかにそのとおりだ
340:仕様書無しさん
07/06/09 22:34:16
>>338
そのページに出てるような問題はすでに解決済みだってこと？
341:仕様書無しさん
07/06/09 22:36:13
今「例外安全性」って言ったらこれだろ。
URLﾘﾝｸ(boost.cppll.jp)
342:仕様書無しさん
07/06/09 22:37:04
>>341
それは>>334の問題を解決してるの？
343:仕様書無しさん
07/06/09 22:39:47
>>339-340
そのページは続く第１６部で訂正されてる。
URLﾘﾝｸ(msdn.microsoft.com)
これでもまだコンストラクタから例外送出に懐疑的な記事だけど、
それも 2000 年 2 月 17 日の話。
コンストラクタからの例外送出は戻り値が無い以上当然であり、まったく問題ない。
344:仕様書無しさん
07/06/09 22:47:05
>>343
こっちはなんか言わされた感があるなｗ
345:仕様書無しさん
07/06/09 22:49:19
結局、投げられた例外は誰が処理するべきなの？
俺は例外なんて投げずにそこで終了すりゃいいと思うけどｗ
呼び出し元で処理すると１つのクラスを１００回呼び出したら１００回同じコード書くことになるぜ
例外出したら出した奴がなんらかの挙動をすべきもんだと俺は思う
346:仕様書無しさん
07/06/09 22:51:26
>>345
大丈夫。 catch() をひとつも書かなければプログラムが異常終了すると
標準で規定されてるから、望んだとおりの結果になるよ。
347:仕様書無しさん
07/06/09 22:52:47
例外使用のチェックを外してビルドしてます。
348:仕様書無しさん
07/06/09 22:54:21
>>347
仲間だｗ
javaでもそうだったな
自分の出した例外他の奴に処理させだしたら収集つかねぇよ
349:仕様書無しさん
07/06/09 23:05:03
>>348
その環境だと戻り値でエラーを伝えるようにしても収集つかんだろ。
350:仕様書無しさん
07/06/09 23:05:59
>>323
スマートポインタって一つのオブジェクトを複数箇所から参照するときに、
生のポインタだと不正なポインタできたりするんで使うってイメージが強いんだが、どうなんだろう。
自分の場合、そういう場面ではハンドルマネージャー使ってるんだ。
まだスマートポインタじゃないとヤバそうなほどややこしいプログラム組んでないしな。
351:仕様書無しさん
07/06/09 23:11:47
>>350
複数箇所からの参照は shared_ptr の仕事だな。
ハンドルマネージャ自作するほうがよっぽどややこしいだろうに。
352:仕様書無しさん
07/06/09 23:41:52
>>350
俺もその使い方が嫌い
そりゃプログラム管理できてないだけだろって思う
オブジェクトの生存＝敵の消滅
とか言語の機能とシステムの仕様を混同してるプログラム書く奴
まあ、普通に使う人なら大丈夫だろうけど・・・普通に使う人はそんなにベタ褒めしないよね・・・
353:仕様書無しさん
07/06/09 23:46:18
>>349
経験上、戻り値で成功・失敗を返すのはうまくいくけど
戻り値でエラーステータスまで返す仕様にすると確実に失敗する
bool initXXX()
if(!initXXX()){
までならいいんだけど
int initXXX()
ret = initXXX()
switch(ret){
case 0:
までやるとだんだん破綻してくる
354:仕様書無しさん
07/06/09 23:55:03
>>351
Gemsのやつを元に単純な実装のハンドルマネージャーtemplate作ったからそれほど面倒でもない。
355:仕様書無しさん
07/06/09 23:55:40
>>352
遅延して問題をよそにやっているだけなので、決定的解決にはなってないと思うよ。
356:仕様書無しさん
07/06/09 23:57:27
モジュール内で処理間を横断するするロガークラス作って全ての関数がそいつに
エラー投げるようにして、そいつから得るようにするとか
そういうめんどくさい仕様にしないと駄目なの？
357:仕様書無しさん
07/06/10 00:01:23
だから素直に例外投げりゃいいんだよ。
358:仕様書無しさん
07/06/10 00:01:27
>>355
いや、俺がいってるのは言語の機能に頼るんじゃなしに
ちゃんとそういうことを判断できるようなシステムを作れってこと
まあ、これはスマートポインタを自動delete以外の用途で使ってしまってる人が対象だけど
スマートポインタが駄目ってんじゃなくてね
359:仕様書無しさん
07/06/10 00:03:22
>>356
引数に管理クラス放り込めばいいんじゃね？
360:仕様書無しさん
07/06/10 00:11:34
shared_ptr の利点といえば、単なる生存管理の域を超えて色々な応用ができる点だと思うよ。
生存しなくなったかどうか分からないオブジェクトのポインタ(もしくはハンドル)が、検索等のコスト無しで調べられるといった性質も
もし、これを高速検索をハッシュ等で作ろうと思えば、結構なコストだ。
また通常、所有権を発生されるため shared_ptr はマネージャ等に持たせて、参照するクラスがweak_ptrを持たせるところ、
これを逆の関係にして、マネージャ等にweak_ptr、参照するオブジェクトに shared_ptr を持たせれば、参照カウンタつきリソース管理機能の出来上がりだ。
自前で作れば、これも恐ろしい量のテストデバッグが必要になるね。
これらは全く違う用途になるが、shared_ptrを多重に使っていくため非常に無駄もすくなくなる。
他にも、参照カウンタ方式のガベージコレクタにあって、マークスイープには無い特徴もいくつか有る。
このまま書き続けていると大量になりそうなので、このあたりにしておこうかと思うけど、こういったノウハウが付いてくると、冗談抜きでこれを使うかどうかで三倍にも及ぶコード量差がでるのは本当。
361:仕様書無しさん
07/06/10 00:14:45
>>358
システムの仕様を言語の動作に対応させられる場面では、そうしたほうが
簡単でいいだろ。資源の確保・解放とコンストラクタ・デストラクタとかね。
広義のスマートポインタでスレッド安全性を保つ目的のものも考えられる。
そこは否定するところじゃないと思うよ。
本当に対応させられる場面なのかって見極めは難しくて、間違ってるプログラムに
遭うこともあるだろうけど、だからって何でもかんでもマニュアル操作にすべきってのは
同意しかねる。
362:仕様書無しさん
07/06/10 00:30:26
>>360
だから、問題は変な使い方してる人達だってばｗ
わかったよｗスマートポインタ役に立つよ。すごいすごい。ゴイスゴイスーｗ
>>361
駄目だと思う
別に定義は無いから俺の経験でしか言えないけど
言語の機能をシステムの仕様として実装するのは間違ってる
バグの原因になる
俺の考えるプログラミング上で最もやっちゃいけない組み方の１つ
こういうのは図でもなんでもいいけど書いてみるとすぐに設計の破綻具合がわかる
オブジェクトの生存を確認する処理はあるのに判断する変数が１つもない
場合によっては処理すらない、バグった箇所を登録できない、書類に残せない、すべてがまずい
管理すると必ず管理クラスが必要になるのにそのクラスも欠落してるからすぐわかる。
ゲームは許されるけど、業務でやったら確実に突っ込まれる
363:仕様書無しさん
07/06/10 00:34:28
>>345
たぶんゲームは例外向いてなさげ。
「例外」という事自体が起きるべきじゃないという気もする。
ウェブ系だと例外は重宝する。誰もcatchしないと大元の呼び出し側で
まとめてcatchしてエラー画面表示とか。コード減るよ。
364:仕様書無しさん
07/06/10 00:34:56
>>360
スマートポインタに限らないんだけど
アセンブラレベルのバグが出たときの
対応についてはどう考えてる？
365:仕様書無しさん
07/06/10 00:37:43
>>363
実際に例外を投げてるゲームの
実機プログラムを実際に見たことは一度もないな。
っていうか、そういうゲームあるの？
366:仕様書無しさん
07/06/10 00:40:18
>>363
うあーやな思い出
スルーした例外をたらいまわしにしてるのと、また、まわされてる間にも形を変えるから
どこでどの例外が出たのか全くわからなくなって酷い目にあった
これはjavaのお仕事のときの話
元のプログラムが必ず呼び出し元に例外投げるように作ってあってまたその例外の種類が多い
１つ１つ例外の対処方法も複雑だし、よく呼び出す関数にそんな量の例外があるから大変
１００回呼び出したら１００回例外対処かかなきゃならん
死にそうになった
まあ、開発途中で無理って結論になって例外全部消したけど
367:仕様書無しさん
07/06/10 00:41:28
>>362
361じゃないが、一度 shared_ptr の中身を読み込んでみる事をお勧めする、
これがどれほどC++の分かりにくい問題を封じ込めてくれていくか読めるようになるまで徹底的に読み込め。
自分は、結構古くからやっていて手動にも随分自身があったが、boost.orgの説明を見ながら読み込んだら
自分の技術は全然話にならないと確信した、こまごました物から、高度なスレッドセーフから例外に至るまで
しかしながら、自分より無知で簡単にポカするプログラマは履いて捨てるほど居る、まして今のC++は素人にはまともに扱えないと
現実問題として、自分も今に至っても、時折やらかす、これを使う事で何回助けられたか分からない
だから、知ってから、コード読み込んでから、御託はそれからにしろ。
と言いたい所だが、所詮ゲームだし、遊べない程でなければバグも許容だしと思うと釈然としないが・・・
まぁそれもありかな。
368:仕様書無しさん
07/06/10 00:44:04
367 続き
もうね、C#なりJavaなりになっちゃえばいいんだと思うよ、マジで
369:仕様書無しさん
07/06/10 00:45:29
>>367
いや、俺の言ってることが全くわかってないな
機能がよくできてるとかそういう話をしてるんじゃないんだよ
人の話聞いてるのか？コラ
370:仕様書無しさん
07/06/10 00:48:21
>>365
ないんじゃないかなぁ。
自分はもうゲーム業界やめちゃったけど、例外使うかどうかという話したときは、
やっぱ使わない方がいいってことになったな。
例外って使う基準も人によってあいまいだし、へたするとただのたちの悪いgotoになりかねない。
そもそもエラーが起きたらエラー画面とエラーコード出すという事自体あっちゃだめだしね
>>366
例外は組み方次第。いちいち随所でcatchするような仕組みにすると確かにコードは増える。
Javaがそういう自体に陥るのは、throwsに投げるクラスをいちいち書くという習慣があるからだと思う。
catchしてSystemExceptionにして投げ直すとかアホ。
そういうのは無視。全部throws Exception。
例外はあくまで不測の事態のときに投げて細かいとこでは全然catchしない。
371:仕様書無しさん
07/06/10 00:53:33
>>370
念
372:仕様書無しさん
07/06/10 00:58:21
デバッグモードのときだけ便利に使う方法ないもんかね
373:仕様書無しさん
07/06/10 01:04:18
>>364
そういうのはスマートポインタ以前の問題だから、スマートポインタだろうがそうでなかろうがデバッガで追う
ステップしながらメモリとレジスタを追います、それ以外方法ないです。むしろもっといい方法があるなら教えて欲しいです。
ICEのある時代は追いやすかったなと過去を思い出す今日この頃です。
374:仕様書無しさん
07/06/10 01:08:57
自分でアセンブラコード書いてないのにアセンブラレベルのバグが出たら
コンパイラメーカにネジ込む他あるめぇ。
375:仕様書無しさん
07/06/10 01:09:31
>>362
必要ないなら、変数も管理クラスも登録も書類も無いほうが簡単でいい。
> 言語の機能をシステムの仕様として実装するのは間違ってる
無茶言うな。
仕様に数値インデックスでのデータ参照があっても配列変数使っちゃ駄目だと？
自動変数による自動的なスタック割り当ては駄目で全部グローバルかヒープにしろと？
たぶんこういうことが言いたいんじゃないだろうけど、こんなことを言い切ってしまう
人の言うことはあまり信用できない。
376:仕様書無しさん
07/06/10 01:16:03
>>363
起きるべきじゃないエラーも、コーディングにおいてはすべて意識するべき。
そうじゃないと、バグが出るたびにどこで想定外のことが起こっているのか、
極端に言うと全部のコードを対象にして探す破目になる。
メモリ確保の失敗をスルーしてたせいで物理的に時間的に遥か遠くのコードで
落ちるとか、さらにたまにしか落ちないとか、泣くっしょ。
377:仕様書無しさん
07/06/10 01:27:43
>>375
は？何言ってるの？
別に自動変数でもいいよ
ただ、ちゃんとそのオブジェクトの生存を表す変数があればいい
ただ、ポインタを使ってオブジェクトの生存を確認するってことは兼用してるよね？
これは駄目
そういうのが必要なら
おおげさな話こうしろ
Object *obj[100]; //100体用意
bool obj_flag[100]; //100体の生存フラグ
ってちゃんとobj_flagに当るもんを用意しろ兼用するな
生存確認をポインタで兼用するなとそういうこと
378:仕様書無しさん
07/06/10 01:36:54
>>377
その Object の「生存」と C++ オブジェクトモデルにおける生存が対応してないんなら、
そんなふうにする必要があるだろうね。
でも、できることなら対応していて欲しい。対応していてくれれば別でフラグを持つ
必要も無いから、メモリも節約できるしフラグの管理コードもなくなるからバグも減る。
あくまで「できれば」ってことだよ。
仕様によっては楽ができるはずなのに、どうやら「できれば」の場合もひっくるめて
否定してるように見えるんだけど、その理由がわからない。
379:仕様書無しさん
07/06/10 01:37:15
>>362の後半4行の意味が分からんのは自分だけだろうか・・。
あと、>>352の後半で言ってることも意味わからん。
てか、これはもしや「クラスを使うな」と言っているのか・・？
380:仕様書無しさん
07/06/10 01:38:51
何か嫌な思い出が頭にこびりついてて、具体的なそのときの話と
一般的な話とが区別できてないんだろう。病んでるな。
381:仕様書無しさん
07/06/10 01:41:38
>>376
意識しないとはいってない。そこを例外に頼らないという話。
メモリ確保失敗したらASSERTとかは入れる。
あらゆる状況でASSERTが出ないかはデバッガに洗い出してもらう。
リリース版でのASSERTの処理を、どうするかは悩ましいところ。
たとえばメモリの確保失敗したときの処理なんて実装のしようがないことが多い。
自分はリリース版はASSERT失敗したらそこでハングするようにした。
へたに続行しちゃって狂ったデータがメモリカードに蓄積されるよりは、そこで落ちた方がいいと思ったので。
この辺は人によって考えが違うので何とも言えないが。
382:仕様書無しさん
07/06/10 01:44:21
>>378
同感。
もっと言えば、仕様レベルの記述とコードレベルの記述をできるだけ一致させるように
してきたのがプログラミング言語やプログラミング手法の進化そのものとも言える。
一方で「仕様と実装を混同してはならない」という考えももちろん大事。
結局、程度の問題ってことかもね。
383:仕様書無しさん
07/06/10 02:06:48
>>381
それなら「ゲームは例外向いてない」という話にはならないでしょ。
ライブラリの中だと assert みたいな全体的な処理の決定もできないから、
やっぱり例外が生きてくるところだと思うよ。一つのエラーに対して呼び出し側で
いろんな対処が選べるのは魅力的でしょ。
例外使ったほうが理論的にはコンパイラの最適化も効きやすいだろうし、
最近のコンパイラだと例外使ったほうがパフォーマンスが良くなるってのも
嘘ではなくなってきてるんじゃないの？
384:仕様書無しさん
07/06/10 02:12:58
いやーC++では例外は止めたほうがいいと思うよ
例外の有効性は否定しない
385:仕様書無しさん
07/06/10 02:14:52
ゲームといわず、C++の例外はヤバイ
自動変数放置しすぎ、せめて finally 句があればちょっとは使い物になるのだが・・・
386:仕様書無しさん
07/06/10 02:18:02
>>378
だから問題が起きるんじゃん
そのオブジェクトの生存を確認するってことはプログラムからすれば
そのオブジェクトの状態を確認することに他ならない
ってことは
obj[obj_id]->state
で調べることであって、
if(!obj[obj_id])
じゃないんだよ
ここが言語の仕様とゲームの仕様を混同してるところ
下は非常にまずい、プログラマがオブジェクトの
生存期間（ゲーム上のキャラの生存期間ではない）を管理しきれてない可能性がある。
obj_idが生きてるのに指し示す先のオブジェクトがすでに死んでる状態になる
これが管理できてないと俺がいう理由
obj_idはミサイルのターゲットなりそういうのな。
この辺踏まえてどうよ？
387:仕様書無しさん
07/06/10 02:19:01
>>383
エラーから正常に復帰する事ができたり、その必要があるなら
有用性もありそうだけど、そうじゃないと強制ハングの方が
問題解決には有効な気がするな。
388:仕様書無しさん
07/06/10 02:21:41
>>386
おれはそんな事より、生存フラグを色々なスレッドからよってたかって操作されたらどうなるのかワクワクするよ
389:仕様書無しさん
07/06/10 02:24:14
>>385
finallyってC++でもなかったっけ？
390:仕様書無しさん
07/06/10 02:24:56
じゃあ生存フラグを触る奴は一人にして他のやつはそいつを窓口にして操作するとか
…遅くなるってか
391:仕様書無しさん
07/06/10 02:27:03
>>389
ないんだな、これが（笑
392:仕様書無しさん
07/06/10 02:28:10
finallyない…
393:仕様書無しさん
07/06/10 02:31:24
C++で例外をやるにはfinallyまたはガベージコレクタの実装が不可欠だな
394:仕様書無しさん
07/06/10 02:38:11
>>385,393
finally の用途って全部 RAII で対応可能じゃね？
最悪 ScopeGuard とか使ってさ。
それぐらいで、あんまり必要性は感じないなぁ。
それに Java の finally だけで RAII 無しってのは、
あれはあれでキツイよ。
395:仕様書無しさん
07/06/10 02:39:17
>>388
それは組み方次第
Object *obj[100]; //100体用意
bool obj_flag[100]; //100体の生存フラグ
これ見た時点で思考停止してるでしょ？
これは別々に扱うもんなのかな？と。
>>386の内容のが重要なんだけどね
396:仕様書無しさん
07/06/10 02:40:13
>>386 ほぼ間違いなく >>380
397:仕様書無しさん
07/06/10 02:44:04
>>395
回避方法は分からなくもないが途轍もなくスマートじゃないなとw
398:仕様書無しさん
07/06/10 02:45:16
>>396
自分の理論の破綻に気が付いてるけど他の方法を知らないから
そうやってはぐらかしてるんでしょ？
俺の同僚もそうだったから知ってるｗ
399:仕様書無しさん
07/06/10 02:46:46
>>397
君のスマートは何を基準にしたスマート？
知らずに実装を基準にスマートを語る奴がいるけど実装時間なんて問題にならないよねぇ
もちろんソースの行数とかもね
400:仕様書無しさん
07/06/10 02:47:07
クタたんの事かー！！
401:仕様書無しさん
07/06/10 02:48:32
>>386,398
「できれば」って念押してあるのに、わざわざできない場合を挙げて
説明しようとしてるのが病んでるとしか思えない。
402:仕様書無しさん
07/06/10 02:57:15
>>401
プログラマで自分の理論を戦わせることをしない奴は馬鹿になるぜ
戦わない奴は弱い
君、いっつもそうやって技術以外の内容に逃げてるでしょ？
正しいと思ってるなら口に出していってみないと伝わるものも伝わらないし
いつまでたっても自分の間違いに気付けない
403:仕様書無しさん
07/06/10 03:18:03
永遠のリーサルウェポン刺激するなｗ
404:仕様書無しさん
07/06/10 09:05:18
そもそも>>377みたいなのが嫌だからshared_ptr使うんじゃないん？
405:仕様書無しさん
07/06/10 10:53:22
月残業４０ｈぐらいの漏れから見ればどうでもいい話だ。
この商売楽だw
座って作業するだけでコンビニバイト以上のお金くれるんだから。
406:仕様書無しさん
07/06/10 11:03:09
ゲーム業界で月残業40hって随分と楽な仕事だな
一週間で突破するだろ普通。
407:仕様書無しさん
07/06/10 11:15:11
・・・昼間どんだけ2chみて遊んでんだよ。
408:仕様書無しさん
07/06/10 12:26:41
他の人は１日４時間ぐらいだべって遊んでる。
その時間仕事してるだけ。
期限までに間に合わないから、遅れますｗという要求が通るだけなんだけどね。
409:仕様書無しさん
07/06/10 13:20:16
>>402で何かカッコイイこと言って悦に入ってるみたいだけどさ、
>生存期間（ゲーム上のキャラの生存期間ではない）を管理しきれてない可能性がある。
>obj_idが生きてるのに指し示す先のオブジェクトがすでに死んでる状態になる
>これが管理できてないと俺がいう理由
これどういう意味？「obj_idが生きてる」って何、それただの添え字じゃん？
皆あなたの説明が分かり辛いから突込みを入れにくいだけだと思うんだけどな。
ちなみにその例でいけば、obj_idを参照の代わりに色んなオブジェクトが持つ場合があると思うんだけど、
そのobj_idのオブジェクトが消滅した時の処理ってどうするの？
参照が色んなところにコピーされてる可能性があるからそれを無効化しなきゃいけないじゃん。
まあやり方は色々あるだろうけど、基本的に面倒だしコードも膨れるでしょ。
ここで問題だったのは、obj_idというものがグローバルに存在するものなのに、それを参照として使うこと。
その点スマートポインタは、必ずインスタンスに対して1:1にポインタの管理領域を持ち、インスタンスは消失しても参照が残っている限り管理領域も残る。（多くの実装では）
だから、オブジェクトが消失しても、参照側では「そのオブジェクト」は無効ということが、確実に検知できる。
スマートポインタだけあって、やはりこのやり方が最もスマート（基準は今書いたこと）だと感じるぜ。
これは、あなたの言う、言語の仕様とゲームの仕様を混同してる、っていうことなのか？
410:仕様書無しさん
07/06/10 13:39:02
>>409
あーあ、触っちゃった。
411:仕様書無しさん
07/06/10 15:28:14
>>409
>そのobj_idのオブジェクトが消滅した時の処理ってどうするの？
>参照が色んなところにコピーされてる可能性があるからそれを無効化しなきゃいけないじゃん。
>まあやり方は色々あるだろうけど、基本的に面倒だしコードも膨れるでしょ。
それだよ！
その状態が正に俺のいう管理できてない状態
特にこれ
>参照が色んなところにコピーされてる可能性があるからそれを無効化しなきゃいけないじゃん。
参照が色んなところにコピーされてる可能性があってそれを把握できてないからよくわからないっていうんだろ
これを言語の機能使って解決しようとしてるところがもうまずいっての
詳しい説明は端折ったが、俺が前に出したやり方は
stateメンバ変数をもつObjectクラスのインスタンスを消さずに持ち続けるやり方と
Objectクラスとは別にフラグを同じ数だけ持たすやり方
だが、言いたいことは生存を確認できる変数をもつということ
だからスマートポインタを変な使い方してる人と比べると
スマ：ポインタの有効・無効でそのオブジェクトの生存を確認する
オレ：オブジェクトの生存を確認できる変数をもつ
ということ
412:仕様書無しさん
07/06/10 15:28:22
ゲームプログラム以外では面白かったり、熱いんだが、
ゲームは寒いままなんだよね。
楽屋で面白い芸人みたいだ。
413:仕様書無しさん
07/06/10 15:38:22
ゲームデザイナ不在ですから。
414:仕様書無しさん
07/06/10 15:45:10
>>412-413←こういう
どうせゲームなんて到底作れそうにないクズってなんでこのスレにくるの？
415:仕様書無しさん
07/06/10 15:59:23
GKだから工作活動に必死なんです
察してあげてください
416:仕様書無しさん
07/06/10 16:16:13
>>414
底辺板だからだよ。
わかる？
417:仕様書無しさん
07/06/10 16:35:56
底辺板で工作活動お疲れ様です
418:仕様書無しさん
07/06/10 16:45:14
>>411管理出来てないというより、管理したくないからスマートポインタを使うんでは？
ステータス引き出したいなら、そいつがどこで使われてるか全部知っておかなくちゃダメなんて、
開発人数が増えれば増えるほど、コストがかかるでしょ
それをスマートポインタで一気に解消できる
419:仕様書無しさん
07/06/10 16:49:59
触るなって
420:仕様書無しさん
07/06/10 17:11:38
>>419
>>412-417みたいな悲惨な流れよりはよくね？
421:仕様書無しさん
07/06/10 17:13:21
>>411
把握できてない、ってそれは何故？
参照のコピーが存在することは、参照カウンタ方式によって把握できる。
またその参照がどこに存在するかも、リンクリスト方式なら辿っていける。
そういうことの「把握」ではないの？
あなたの言ってるのは、違う「把握」なの？
それから、スマートポインタのどの辺りが言語の機能だと捉えているの？
例えばC++のRTTIを言語の機能と考えて、なるべくそれを避けようというのなら理解できるけどね。
それからそれから、あなたのその２つのやり方に共通に言える事なのだけど、
・オブジェクトを消去した時に、そいつのコピー参照の全ての無効化というのをしない場合
同じインデックスに、過去に存在したオブジェクトと新しく生成されたオブジェクトが違うことを証明する情報が必要になる。
（これは大抵ユニークID的なものを使うと思う）
またオブジェクトの利用側コードではそのチェックが必要になるから多分大変。
・オブジェクトを消去した時に、そいつのコピー参照の全ての無効化を行う場合
恐らくは、参照変数へのポインタのリストを保持したりすると思う。
でもそれって、結局スマートポインタのリンクリストを使っているようなものではないのかな。
といったことから、「えー泥臭ぇー、スマートポインタ使えよ。」って話になるのが一般的と思うがいかがか。
422:仕様書無しさん
07/06/10 17:19:56
>>418
まぁ、管理できていない状態でスマートポインタを使ってて
さらにバグ状態になったら、デスマ確定だけどな。
423:仕様書無しさん
07/06/10 17:21:51
>>421
> 例えばC++のRTTIを言語の機能と考えて、なるべくそれを避けようというのなら理解できるけどね。
RTTI を避ける理由なんてあるのか？
実は RTTI にしちゃいけない誤用とかも確かにあるけど、
基本的には利用したほうが話が単純にできるんじゃない？
424:仕様書無しさん
07/06/10 17:23:30
>>422
「だからスマートポインタは危険だ」とでも言いたいのか？
425:仕様書無しさん
07/06/10 17:27:42
>>423
コードサイズが膨れ上がる場合がある。
426:仕様書無しさん
07/06/10 17:29:19
>>420
妊娠馬鹿がわけばあんな流れにしかならんよ
どの板でも
427:仕様書無しさん
07/06/10 17:32:16
>>424
いや、何でもそうだと思うけど
実装の仕方やシステムによって話は全然変わる程度の話。
スマートポインタを使えば大丈夫とか、駄目とかの話じゃないだろ？
実際に、スマートポインタがデスマを助長した
プロジェクトも結構あると思うんだが。
428:仕様書無しさん
07/06/10 17:36:47
>>425
RTTI を使うことによってコードサイズが膨れ上がるのはどんな場合でしょう？
小さいコードで実例をもらえませんか？
429:仕様書無しさん
07/06/10 17:39:43
>>427
そんなのは「スマートポインタ」を言語なり開発ツールなり何に置き換えても言える。
毒にも薬にもならない話。
430:429
07/06/10 17:40:28
ごめんなさい。
431:421
07/06/10 17:57:59
RTTIはコードサイズよりも実行コストかな。
あとコンパイラの挙動が統一されてなさそうなのが問題かな。
これは結構読んだよ→URLﾘﾝｸ(ray.sakura.ne.jp)
ちなみにRTTIは趣味でしか使ったことありません。＼（＾o＾）／
JavaからC++への移植とかであれはRTTIを使った方が早くできそうだね。
432:仕様書無しさん
07/06/10 18:04:05
>>428
実例って言われてもなぁ…
ランタイム型情報って知ってる？
433:仕様書無しさん
07/06/10 18:23:29
>>431-432
なるほど。お手数おかけしました。
434:仕様書無しさん
07/06/10 18:52:42
何かややこしい話してるな。
まあ俺は管理用のインスタンス（Singletonとか）作ってハンドルで管理させておこう。
435:423
07/06/10 18:52:50
>>421
うは。すまねぇ RAII とごっちゃになってた。
あれ？そのあと普通に続いてる？
スレ汚しごめんよ。
436:仕様書無しさん
07/06/10 19:02:36
>>418
それを放棄してしまったら何をプログラムで管理するのかと思ってしまうんだが・・・
コントロール不能のプログラムだと思う
おかしい動作してないうちはいいけどバグり出したら多分すごいよ
437:仕様書無しさん
07/06/10 19:10:07
ほんと、ナントカマネージャとか作らないと気がすまない奴って居るよな。
プログラムなんて書かなきゃバグらないんだよ。
438:仕様書無しさん
07/06/10 19:17:12
>>421
>参照のコピーが存在することは、参照カウンタ方式によって把握できる。
>またその参照がどこに存在するかも、リンクリスト方式なら辿っていける。
ゲームの話に戻るけどそれってプログラムのオブジェクトの存在を
ゲームのオブジェクト参照してる奴からみたらどういう位置付けになるわけ？
まあ、わかり易いところでＳＴＧの敵とかだったりしたら酷くあいまいだよね？
２つできてしまうわな
１．プログラムのオブジェクトとしての存在の有無
２．ゲームの敵としての存在の有無
１は単純に画面外やら行動パターンの終了なんかでゲームから消えた（？）状態で
２はゲームとしてＨＰ０で敵が死んだ状態と考えてる
そもそも「なくなっちゃう」って状態が駄目だと思うんだけどね。
例えばObjAとObjBというインスタンスがあったとして、
ObjBはObjAのターゲットとなってたとして
ObjBが勝手に消失したときのObjAの処理を定義するのが面倒だから
スマートポインタ使ってるような奴が駄目だって言ってるんだぜ俺は
439:仕様書無しさん
07/06/10 19:23:25
ここにいる奴らってみんなすげぇ知識と才能を持ってるみたいだけど
具体的に成果物を聞くととたんに「守秘義務が・・・」とか言い出すよね。
別に技術の細部を聞き出そうとしてるわけじゃないのに何か勘違いしてるのかな？
440:仕様書無しさん
07/06/10 19:29:50
>>439
そりゃ現場に行けば１人の力で物なんか作れないということがわかるから
みんなで作ったもんを偉そうに自分の手柄のように語るとろくなことがない
広報やら営業やら別の会社の人やら顔もみたことがない人とかも頑張ってるだろうしな
最近、日曜日にやってるグレンラガンってアニメ知ってるか？
あそこのスタッフがいわゆる「わかってない奴」で色々と大変なことになってしまっただろ
最悪、一生かかっても払いきれない賠償金まで請求されることがあるぜ
441:仕様書無しさん
07/06/10 19:31:31
じゃあスマートポインタを利用してスマートハンドルを実装するのはおｋ？
442:仕様書無しさん
07/06/10 19:34:53
>>441
仕様がわからないと判断のしようもないな
443:デフォルトの名無しさん
07/06/10 20:02:27
最近、並列がはやっていますが
ゲームプログラマーのみなさんは並列設計で何か
標準の手法など使用されていますか？
444:仕様書無しさん
07/06/10 20:11:52
>443
とりあえずマルチスレッドのパターンを使うくらいかな。
445:仕様書無しさん
07/06/10 20:14:11
>>439
まあ、リスク背負ってまで、こんな所で教える義務はないし、>>440の言う通りなんだけど、
アンタの推測してるとおり、こんな2chの僻地の過疎板の低レベル論議に
スキルある人が加わる事はまずないよ。
まれに覗く事があっても、すぐ立ち去るだろ。
得るものがないからね。
大学生が分数のかけ算の論議には加わらないのと同じで。
446:仕様書無しさん
07/06/10 20:26:18
分数のできない大学生とか言って一時期テレビで取り上げられてなかったっけ？
447:仕様書無しさん
07/06/10 20:30:43
必要なスキルを短期間で必要なだけ習得する
それが求められる人材
受験に必要なスキルを必要なだけ習得した彼らは優秀なんだよ
おまえらみたいに一生使わないスキルをWEBで自慢するためだけにコーディングするのは人生の無駄遣い
448:仕様書無しさん
07/06/10 20:35:25
>>447
ゲーＰＧこそ今日か明日使う技術しか覚えんと思うがな
受験勉強も受験でつかうっちゃそうだな
みんなその場限りで生きてんだよｗ
449:421
07/06/10 20:48:34
>>438
>そもそも「なくなっちゃう」って状態が駄目だと思うんだけどね。
あなたはどうしてそこまでインスタンスの消滅を拒むの？
STGにしろ何にしろ、そいつ固有の情報が必要なくなったら始末する。
現実世界の「存在」という状態に最も近くて、
仕様と実装に差異も少ない良い方法だとしか思えないけど。
それから、駄目って言うからには理由があるの？
それはもしかしたら私が考えもしていなかった事かも知れないから、教えて欲しい。
>ObjBが勝手に消失したときのObjAの処理を定義するのが面倒だから
>スマートポインタ使ってるような奴が駄目だって言ってるんだぜ俺は
既成のスマートポインタで楽して消失処理をしようなんて許せない。ということ？
もしかして、スマートポインタでも、自分でコーディングしたものなら許せる。ということ？
もしくは>>421の後半で書いた参照への参照をやはり自分で実装するべきだ。ということ？
あなた、職業プログラマだよね？
何か殆ど答えて欲しかったことがかわされてるように思われます。
450:仕様書無しさん
07/06/10 21:01:27
>>449
え？俺がいいたいことは>>438の最後の１文ぐらいなもんだけど
ちゃんと管理できてるなら問題ないぜ
ただ、決まって無い仕様を勝手に都合のいいように
解釈していかにも決まった仕様のようにいうとろくなことないよってだけだけど
動作の定義抜けは定義抜けとしてちゃんと企画の人間に相談しような
そうすりゃ消失ルーチンなんて基本的には絶対に走ることはない処理なんだからよ
単純に君の作るゲームはオブジェクトがとあるどっかのオブジェクトを参照してる状態で
その参照してるオブジェクトがなんの前触れもなしに消えてしまうようなのが仕様としてあるの？
そんときの処理は定義無しのままゲームの開発を進めちゃうわけ？
451:仕様書無しさん
07/06/10 21:16:58
> ただ、決まって無い仕様を勝手に都合のいいように
> 解釈していかにも決まった仕様のようにいうとろくなことないよってだけだけど
> そうすりゃ消失ルーチンなんて基本的には絶対に走ることはない処理なんだからよ
ずーっと前のレスから言われてるのに、やっぱりそう決め付けて話してるよな？
このスレの流れの中では、「いかにも決まった仕様のように」言ってるのはオマエ一人だ。
452:仕様書無しさん
07/06/10 21:33:20
2人とも話がずれてきてるから一度冷静になってログを読み返してきたら？
453:仕様書無しさん
07/06/10 21:46:37
>>452
ずれてねぇだろやっと論点がはっきりしてきたじゃねぇか
もう後は平行線なんだろ
俺はしっかり管理しないと気がすまないって言ってて
スマートポインタで変なことやってる奴はそれでいいってだけの話だろ
それでいいって言ってる奴をこれ以上どう説明しても説得するのは不可能だろう。
俺も似たような構造のプログラムに付き合わされたことあるしね。
仕事で上司がそういう組み方してたな
でも、開発するたびにバグが大量にでるんだ。
１０００や２０００も出るからこりゃねぇだろって考えた
どの部分が難解なのかどうしてバグが出易いのか考えた結果が
ポインタや変数、インスタンスが管理しきれてねぇからバグがでるんだって結論になった。
そういう経験やら解決策を探したりした経験がないとなに言ってるのかわからんこともあるだろうし
そもそも俺と同じこと考えても解決策を別のことに見出す奴もいるだろう。
上司に話しても全く聞く耳もたなかったな。多分同じ反応する奴もたくさんいるだろうね。
まあ、俺のやり方はこうで相手のやり方がこうって理解できるだけでもいいんじゃない？
暇なときや自分のやり方に疑問をもったときに次のネタは色々あったほうがいいわけだし
454:仕様書無しさん
07/06/10 21:58:45
やっぱり >>380 で FA だぜ。
455:仕様書無しさん
07/06/10 22:00:07
ずれてきたんじゃなくて、最初からずれてたのか
456:仕様書無しさん
07/06/10 22:03:52
>>454-455
お前等、本当にＰＧなの？
会話に参加できないほど馬鹿なのか、
参加する必要がないほどレベルが低い会話だったのかは
知らんけど態度がウザ過ぎる。
スタンスをはっきりさせてどっちかにしろ
457:仕様書無しさん
07/06/10 22:05:15
当時、聞く耳もたれなかったんだろう？
今、誰も同意してくれないだろう？
それは何故かよく考えてみる必要があるんじゃないか？
自分を疑うことができなければ、いくら口に出して伝えたとしても
「いつまでたっても自分の間違いに気付けない」
458:仕様書無しさん
07/06/10 22:19:04
>>457
いいや、ただ頑固なだけで時間が立てば俺が言ってることがどういうことか理解できると思うぜ
ただ、自分のやってきた方法にちょっと思い入れが強いだけだ
耳にいれるだけでもずいぶん違う
なんにせよ知ってしまったら試さずにはいられないだろ
なんたって自分のやってきた方法を否定してこっちのがいいって主張する奴がいるんだから
少なくともメリットとデメリットを理解して語れる程度にはならなきゃね
そこまできたら好きな方使えばいいさ
ただ、食わず嫌いでいるのはもったいないね
459:421
07/06/10 22:23:16
ごめん私はもう疲れました。
話を小出しにするな。自分の出来る話へ逸らそうとするな。
まして真剣に話してくれている人に対して茶化すな、失礼に値する。
おまえは業務系か？オブジェクト指向って分かるか？結合度って分かるか？
おまえのソースは本当にC++か、いやCに違いない。
自分の分からない事を避けて生きてないか？
自分の考えが常に正しいと思っていないか？
長く書き込みし合ってるのに名前をつける頭も無いのか？
俺はおまえとはぜーーーーったいに仕事したくねーよばか！！！
などと考えておりましたら>>453が書き込まれて、
１０００や２０００の部分で吹きました。なんだそりゃ。
しんどいプロジェクトを経験したことには同情する。
そして確かに動的な情報の管理は難しいね。暴言ごめん。
何か言いたい事が頭から吹き飛んでしまったけど。
多分これ。
スマートポインタは出来る新人だよ。今までの手法と上手く調和させる事が出来、かつ意外に良い仕事をしてくれるよ。
460:仕様書無しさん
07/06/10 22:26:39
>>459
クズはすっこんでろよ
461:仕様書無しさん
07/06/10 22:30:21
>>441
じゃあ俺はハンドルの仕組み利用してスマートポインタのパチモン実装する。
462:421
07/06/10 23:34:59
すまない。IDも無い板で誰が書いたかも分からないのに
憶測だけで自分の中で人間像を作り暴言を吐いてしまった。
もっと冷静になれるはずだった。本当に言い過ぎたと思ってる。
スレ汚しになってしまうが謝らせて欲しい。本当に、ごめん。
463:仕様書無しさん
07/06/10 23:48:03
クズが逃げたｗ
464:仕様書無しさん
07/06/11 00:05:59
いい頃合だ。もう触るなよ。
465:仕様書無しさん
07/06/11 01:16:57
>>464
お前が一番わけわからん
なんでそう接触を避けるの？
自分がやってきたことを覆されるのが嫌なの？
掲示板で語られることで自分の常識がひっくり返されるのが
嫌ならこんなところこなきゃいいじゃない
多少破綻してても自分の思ったことははっきり言えよ
馬鹿にされるのを怖がっていてはいつまでたっても成長しないぞ
466:仕様書無しさん
07/06/11 01:18:48
【審議中】
∧,,∧ ∧,,∧
∧ (´・ω・) (・ω・｀) ∧∧
( ´・ω) Ｕ) ( つと ﾉ(ω・｀ )
｜ Ｕ ( ´・) (・｀ ) と ﾉ
ｕ-ｕ （l ) ( ﾉu-ｕ
`ｕ-ｕ'. `ｕ-u'
467:仕様書無しさん
07/06/11 01:19:08
421じゃないが、それなりにスマートポインタを使い込んできた、出たバグとは何だい具体的にいってみな、
何が問題でどうなったらうまくいくのか考えてやるよ。
>でも、開発するたびにバグが大量にでるんだ。
それから簡単に管理管理といってているが、何をどういう目的で管理するのかしっかり考えてないんじゃないか？
>ポインタや変数、インスタンスが管理しきれてねぇからバグがでるんだって結論になった。
不必要なものまで管理するの馬鹿げているし、管理すべきものが管理に入ってないなら問題だ。
スマートポインタを使おうが、管理用のクラスを作ろうが、問題発見→解決方法の考案という流れは変わらない。
そもそもスマートポインタとは何か知らないんじゃないかと思えるので気になった。
一応言っておくが、スマートポインタとはポインタ演算子 operator -> をオーバーロードしたクラスの事をいう。
要するに各種機能を追加して -> 演算子を使って操作できる「かしこい」ポインタ風オブジェクトの事だが大丈夫か？
リファレンスカウンタやなにかとごっちゃになっていないか？
リファレンスカウンタを持つスマートポインタもあるが、リファレンスカウンタが無いスマートポインタも考えられる。
468:仕様書無しさん
07/06/11 01:31:14
>>467
途中参加の方ですか？
上のほうからちゃんと読もうぜ
スマートポインタを変な使い方してる人に対して言ってるのであって
そうでない人は対象にしてないよ
なんかこれまでの議論の経緯をぶっちぎってそう勝手に吠えられても困るんだよね。
わかりにくいし
アンカーもついてなければ、俺の意図も汲んでくれてなさそうだし
文章から不親切が滲みでてるのですげー嫌なんですけど？
469:仕様書無しさん
07/06/11 01:33:17
なんだそりゃ、精神やんでんなぁ
470:仕様書無しさん
07/06/11 02:09:15
あれで議論したつもりかよ
471:仕様書無しさん
07/06/11 03:44:12
>>438
>ObjBが勝手に消失したときのObjAの処理を定義するのが面倒だから
>スマートポインタ使ってるような奴が駄目
ってのが結論だけで途中がさっぱりなので説得力に欠ける。
実際こういう使い方はするし、面倒だから簡単に解決するために使うってのは正しい事だし
そもそもなんで管理してなきゃ駄目なのか？が、わからない。
バグが出るからって言われてもねー・・・殆どの人はこの使い方でバグを出さないだろう。
2000もあるんなら具体例を一つぐらい聞きたいけど・・・
スマートポインタのせいには思えないんだよね。
472:仕様書無しさん
07/06/11 06:58:45
>>471
参照オブジェクトが無効になったときの処理を全部かかなかったら全部バグるだろ
ちゃんと書けば問題ないかもな
473:仕様書無しさん
07/06/11 08:48:56
頼むからコテハン付けてくれ。
474:仕様書無しさん
07/06/11 10:44:19
>>472
オレも理解できないよ、即座にデストラクトしてもらわなくてはならない場合、たとえば shared_ptrとweak_ptrのケースなら、ロックするときに書くしか無いし
そもそもやり方としては、使いたいスコープの中で、shared_ptrを使って消失をロックするのが普通だしな
475:仕様書無しさん
07/06/11 12:07:09
ゲハでやれよ。スレ立てようか？
476:仕様書無しさん
07/06/11 12:08:32
いや、お前だけ帰ればいいと思う。
477:仕様書無しさん
07/06/11 13:09:48
うんこルーチンの方が読めた分楽しめた
478:仕様書無しさん
07/06/11 17:45:26
●下記の話題は何度繰り返されても結論が出ず、無駄に荒れるだけなので避けましょう
・全角英数でのレス
・コーディングルール全般
・古典タスクシステム
・オブジェクト指向
・バージョン管理システム
・エクストリームプログラミング
・テスト駆動開発
・言語論争
・進路問題（大学にいくべきか、ゲーム専門学校にいくべきか等）
・エディタの強制
・読解力の指摘
・プラットフォームの優劣について
・スマートポインタ
479:仕様書無しさん
07/06/11 19:43:39
無闇にNGリスト入りさせるのはいくないだろ
そんなことしてたら話すことなくだろ
多少カオスってても誰かの参考になる情報があるかもしれないんだからさ
480:仕様書無しさん
07/06/11 21:38:50
>>474
うん、だから自動delete機能として使ってる分には問題無いって何度も言ってるよね
481:仕様書無しさん
07/06/11 21:56:04
話してるやつも平行線だって認識してるわけだし、NGリストでおｋでしょ
482:仕様書無しさん
07/06/11 21:58:12
結論の出ない議論を延々やりつづける以外にここで話すことなどあるのかい。
483:仕様書無しさん
07/06/11 22:29:05
>>480
だったら auto_ptr や shared_ptr は自動 delete 機能しか持ってないから
何の文句もないんだよな。よかったよかった。
484:仕様書無しさん
07/06/11 23:34:26
>>482
錬金術自体は不可能だったけどその過程で得たものは大きい
485:仕様書無しさん
07/06/11 23:45:05
>>478
同じ人間が同じ思考でぶつかればそりゃそうだろうな
だが実際は別の人間が別の思考でぶつかってるので意味が無いわけではない
場として正常?に機能しとる
486:仕様書無しさん
07/06/11 23:49:33
誰かがまとめてくれるなら意味があるかもな
487:仕様書無しさん
07/06/11 23:52:05
>>486
そんなの必要なのお前だけだろ
488:仕様書無しさん
07/06/12 10:55:05
ゼ○ラルサポート社って自社開発なのか…
489:仕様書無しさん
07/06/12 16:37:45
バグではなく不良箇所と言おうぜ
490:仕様書無しさん
07/06/12 17:50:32
蟲と言う名のマトリクス
491:仕様書無しさん
07/06/12 19:47:09
特定できないのに不良箇所とは
492:仕様書無しさん
07/06/12 20:10:34
不良箇所という名の無限ループ
493:http://www.gatekeeper03.sony.co.jp.2ch.net/
07/06/13 00:20:07
guest/guest
触手
494:仕様書無しさん
07/06/13 00:41:25
（ ＾ω＾）マスターアップしたお
495:仕様書無しさん
07/06/13 20:28:51
アセンブラでゴリゴリ書きたい
496:仕様書無しさん
07/06/13 20:50:44
>495
組み込みに来たまえ。
8bitアセンブラは楽しいぞ(w
497:仕様書無しさん
07/06/14 06:18:13
最近はPICですらCで書くからなぁ・・・
498:仕様書無しさん
07/06/14 07:01:01
CPUパワーは偉大だ
499:仕様書無しさん
07/06/14 07:01:56
組み込みはRTLか？
一応C言語で組むもんがあるけど
全く使えネー
C言語とかいっててC言語じゃないし
500:仕様書無しさん
07/06/14 07:29:25
Cじゃ2kBのメモリに収まらないんだよ…。
アセンブラでゴリゴリ書いた方が効率良いんだ。
501:500
07/06/14 07:30:23
>500
×2kB
○32kB
2kBはさすがに少なすぎだって。
502:仕様書無しさん
07/06/14 07:40:18
汗厨は偉大だ
503:仕様書無しさん
07/06/14 07:46:00
SH-4AとかARMはC++も使えるんだってね
504:仕様書無しさん
07/06/14 08:45:16
ちょっと質問です。
>>413を見て思ったんですけど、
みなさんの会社には、ゲームデザインまたはレベルデザイン専門でやってる人っているんでしょうか？
海外のゲーム会社の記事には、たまにこういう単語や専門としてやってるらしき人が出てきてますが、
日本のゲーム会社の記事だと、単語自体ほとんど眼にしません。
日本ではそこまで細分化されていないんでしょうかね？
505:仕様書無しさん
07/06/14 10:25:52
8ビットアセンブラってパチですか？
組み込みでも最近はめっきり8ビットは聞かなくなったな
506:仕様書無しさん
07/06/14 10:39:19
>>504
日本では企画屋の仕事だな、どういうシチュエーションで遊んでもらうかといったレベルまでまとめてやるケースが多い気がする。
古くから任天堂の影響が大きかったからだろうな。
実際問題として、ゲームの方向性がばらばらになってしまわない為にも細分化はしない方が良いと思うよ。
507:仕様書無しさん
07/06/14 11:04:25
>>501
2KBと聞いて興奮したのに・・・。
アセンブラで32KBじゃぬるすぎる。
508:仕様書無しさん
07/06/14 12:50:15
32KBってと少なく感じるが32000Bとすると大きく感じる
509:仕様書無しさん
07/06/14 16:59:35
2KBって初期のポケコンレベルじゃん
アセンブラどころか機械語で組むつもりかよ
510:仕様書無しさん
07/06/14 19:18:19
オレの認識不足ならごめん
アセンブラと機械語て1対1の関係じゃないの？
511:仕様書無しさん
07/06/14 20:13:13
俺もそうだと思うが。
512:仕様書無しさん
07/06/14 20:22:28
>505
玩具系の組み込みだと、未だに8bitとかよくある。
513:仕様書無しさん
07/06/14 21:46:27
>>510
というわけでもない。
514:仕様書無しさん
07/06/14 22:06:14
1:1の関係に出来る限り近づけたプログラミング言語がアセンブリ
機械語は0100010001001010…の羅列
515:仕様書無しさん
07/06/14 22:25:50
去年入った新人が今日辞めて行った。
イイヤツだったんだけどな…。今は部署が違うんでよく状況がわからんのだが、
何かあったんだろうか…。
516:仕様書無しさん
07/06/14 22:28:27
ソース書く->アセンブル->オブジェクトをROMに焼く
ソース書く->ハンドアセンブル->オブジェクトをROMに焼く
2KBだとアセンブラ使えないような違いが何かあるか？
ターゲット上でアセンブルするとか最初からあり得ないだろうし、
最適化を殺せない糞アセンブラなんかはお目に掛かったことないし。
517:仕様書無しさん
07/06/14 23:13:40
>>513
間違っているのはもまえだ
518:仕様書無しさん
07/06/14 23:43:04
>>517
間違ってないよ？
519:仕様書無しさん
07/06/14 23:50:34
おおよそ2：2で良いよ
520:仕様書無しさん
07/06/15 00:02:52
>>506
ばらばらの問題はコミュニケーションの問題じゃね?
そりゃ同じ人がやれば必要ないから間違いはおきないけどさ
521:仕様書無しさん
07/06/15 03:43:53
ハード的には複数命令に渡るシーケンスをアセンブラ１命令に規定している
ケースも（稀に）存在するので>>513は正解。ARM-thumbのblとかね。
522:仕様書無しさん
07/06/15 05:49:32
勉強になりました
523:仕様書無しさん
07/06/15 23:07:36
例えばPen4の pause 命令は実は rep nop だ。話の趣旨のニュアンスとは
若干違うけど、まあ似たようなもの。
524:仕様書無しさん
07/06/15 23:24:17
>>521
そういうのはアセンブラでは一般に命令とは呼ばずマクロ命令とかマクロとか呼ばないか？
525:仕様書無しさん
07/06/16 00:06:16
でもそんなのある時点ですでに１対１じゃねぇよな
用語辞典のほうが間違ってる気がするぜ
だって結局Ｎ個の組み合わせを認めちゃったらなんでもできるわけだろ？
526:仕様書無しさん
07/06/16 00:15:17
アセンブラは特に理由がなければ一対一にするんだよ
アセンブラにおけるマクロというのは、ある種サブルーチンのような意味合いのあるもので、
最近は言語ツール類も揃ったし、メモリーもてんこ盛りで簡単だから、良くあるパターンは自分で定義しなくても最初から使えるようにしておけって付いているんだよ。
527:521
07/06/16 02:33:03
>>524
まぁ、そうなんだけど、例で挙げたARM-thumbのblの場合、構成コードの
個々を吐くアセンブラニモニックとかが定義されてないので、個別の命令
として使おうとしたらバイナリ定数で埋め込むしかない。
まぁ、>>521で書いた様にこういう例は稀であって、>>526が書いている
様に「標準でマクロ命令が沢山ある為に、１：１対応が崩れているケース」
の方が多いだろうね。
528:仕様書無しさん
07/06/16 03:33:52
ディスアセンブルしたら別のニモニックで表示されてるなんてことはいくらでもあるわけで、１対１で対応してるなんて思い込む必要は無いと思うがね。
.noreorder なんてディレクティブのあるアセンブラもあるわけだし、>510 に対して >513 程度の返答なら穏当じゃないか？
529:仕様書無しさん
07/06/16 09:45:36
すまん、かなり初心者的かつローカルな質問で悪いんだが疑問がある
ネットゲームやPCゲー（非エロ）などで音楽データが丸々むき出しで突っ込んであるのは何故？
毎回それに疑問をもっていたんだが･･･ネットゲーはほとんどがむき出しだと思う
俺が今までやってきた奴でちゃんとパッケージされてたのは１つしかない
あと家庭用PCではファル○ム系（他はしらん）もoggだけどむき出しだし
サントラとかの商品化を考えてるならナンセンスだと思うんだが･･･
530:仕様書無しさん
07/06/16 11:26:50
対策したところで吸い出す奴は吸い出すから、そんな無駄なコストはかけない。
無料でデータ吸い出せるからサントラ要らないなんていうガキは最初から対象外。
531:仕様書無しさん
07/06/16 11:45:27
>>529
APIやDLL上の仕様
532:仕様書無しさん
07/06/16 12:01:19
パッチ当てやすいからだと思ってた
533:仕様書無しさん
07/06/16 12:21:53
ストリーミングがまんどくさいからでしょ
534:仕様書無しさん
07/06/16 12:23:45
だからコンシューマが流行っているんじゃないか
535:仕様書無しさん
07/06/16 12:36:09
プログラマーが無能だからだろ
536:仕様書無しさん
07/06/16 15:23:18
>>529
だってその方がmodとか改造や改良するのやりやすいじゃん
537:仕様書無しさん
07/06/16 21:54:43
別に変えるのは簡単だけどね
oggだって拡張子やファイルのヘッダまでoggであることを強制する仕様じゃないし
吸い出す奴がいるにしてもとりあえずはXORぐらいはかけておくと思うよ
チェックいれても半日あれば十分だろ
それすらやらねーのは怠慢だろ
538:仕様書無しさん
07/06/16 21:59:08
泳がせているだけ。
539:仕様書無しさん
07/06/16 23:05:51
物故抜かれてもかまわないと思ってるんじゃね？
割り切っちゃえば余計なことをやる必要もないだろ
540:仕様書無しさん
07/06/16 23:07:06
ファルコムの場合は宣伝効果も期待しているだろう
541:仕様書無しさん
07/06/16 23:53:02
>>539
好評ならサントラ売れるかもしれないのにわざわざタダであげてやることはないだろ
542:仕様書無しさん
07/06/17 01:04:21
サントラの価格分もソフトの値段に含まれてるとしたら？
543:仕様書無しさん
07/06/17 01:17:06
>>542
そしたらサントラ１枚分余計にもうかるじゃない
544:仕様書無しさん
07/06/17 03:43:11
>>506
やはり日本では専門でやってる人はいないんですね。
専門の人がいなくても、日本のゲームは海外と比べて遜色ないですから、
細分化しなくても大丈夫なんでしょうね。
回答ありがとうございました。
545:仕様書無しさん
07/06/17 04:37:20
サントラを発売できるくらい好評なら、たとえ中にoggが直に置いてあったとしても
それなりにサントラが売れそうなのはなんでだろうか
546:仕様書無しさん
07/06/17 10:06:57
サントラなら多少は音質上がってそうだから(特にデータがMP3とかOGGの場合）・・・
って、ゲームデータのMP3をそのままCD化したなんてひでー話もあったっけ。
547:仕様書無しさん
07/06/17 10:09:02
それRO
548:仕様書無しさん
07/06/17 10:17:15
MP3ってたしか販売数5000超えで料金が発生しなかったっけ？
著作権もうるさいデータ形式だからゲームでは使用しにくいとか
そのわりにはネットゲームではほとんどがMP3だよな、クライアント無料配布なら料金は発生しないのか？
そのへんおせーてください
549:仕様書無しさん
07/06/17 10:31:56
そりゃ無料ゲームのDL数5000超えで使用料発生とか常識的に考えて有り得ないだろ
550:仕様書無しさん
07/06/17 11:13:48
無料なら使用料が発生しないと思い込むのは甘いだろう
GIF特許問題を思い出せ
551:仕様書無しさん
07/06/17 12:15:40
>>550
gifのはpngに以降させるためにやったんだろうか？
と思ったりして
たしか権利もってるの同じ会社だよねぇ？＞gif,png
552:仕様書無しさん
07/06/17 12:22:40
>>551
全く違う
Png is Not Gifって通名があるくらい違う
URLﾘﾝｸ(www.gnu.org)
553:仕様書無しさん
07/06/17 13:21:40
電子すかしを仕込んで、簡単にデータ抜きできるよううにしたまま販売というのは最近はありかなとか
引っこ抜いたデータでMAD作ってもらう分には、むしろ宣伝効果の方が高そうだし
本格的に商売始めやがった奴だけ狙い撃ちにしておけばいいかと最近は思ったりするよ。
554:仕様書無しさん
07/06/17 14:31:35
.pngはアニメーションGIF相当の機能を取り入れなかったから（別フォーマットに分割）
結局GIFの代替にはなれなかったんだよな。
555:仕様書無しさん
07/06/17 14:45:26
>>553
それは経営者やデザイナの契約内容も絡んでくるからよくわからんな
556:仕様書無しさん
07/06/17 14:48:31
当時のIEはpngにちゃんと対応してくれなかったので使い物にならなかった
557:仕様書無しさん
07/06/17 20:49:27
>>551
pngはbmpの代わりだろ
jpegは破綻するからスキンに成り得ない
558:仕様書無しさん
07/06/17 23:21:16
今、gifに変わるアニメーションのフォーマット作って本書いたら売れるかな？
この辺アルゴリズムが浮かぶだけじゃなくて権利関係も詳しくないと仕事できないから嫌なんだよな
とりあえず画像をフレーム同士で圧縮掛けたものを
適当にフリーの圧縮アルゴに放り込んだだけのもんでも代わりにはなるだろうか？
559:仕様書無しさん
07/06/17 23:31:33
>LZWのGIFはUNISYSが権利持ってて
>LZ77のPNGは特に権利問題とか無いはず
ってレスが落ちてたから多分ここだろうと思って拾ってきました
560:仕様書無しさん
07/06/17 23:32:33
IEが対応しなきゃ何にもならん
gifが使えるようになった今となっては
よほど利点がないと・・・・・
FLASHにも勝たないといけないし
561:仕様書無しさん
07/06/17 23:56:43
gifってショボイ絵しかできないとかそういう制約あったっけ？
全色使えるんだっけ？
562:仕様書無しさん
07/06/18 00:05:08
>558
つ『mng』
563:仕様書無しさん
07/06/18 00:09:30
mngってIE対応してないんだよな
やっぱ一社独占はまずいわ
564:仕様書無しさん
07/06/18 00:36:12
CellスレでMacオタが妄想100%でゲームPGを語ってるな。
565:仕様名無しさん
07/06/19 23:50:07
みなさんは、ゲーム業界に入る前どれくらい勉強してましたか？
566:仕様書無しさん
07/06/20 00:00:04
>>565
一流大学じゃないけど首席で卒業するぐらいは勉強した。
567:仕様書無しさん
07/06/20 01:04:55
情報系はトップだったけど就職すらできなかった俺がきたよ
568:仕様書無しさん
07/06/20 01:25:17
仮に○○ぐらいと言われて、ふーんそれぐらいでいいんだと思うために聞いたなら、間違いなく向いて無いよ。
全力でやれ。
569:仕様書無しさん
07/06/20 01:27:11
一桁まではいったけど、さすがにトップは無理だったな
なんで底辺大学にいるのか不思議なくらい頭のいいやつがいた
570:仕様書無しさん
07/06/20 01:55:38
そりゃ上澄みはどこでも凄いよ、専門や五流私大でも東大京大の底辺より上だって
571:仕様書無しさん
07/06/20 13:03:07
>>565
Fランク大学の情報工学部だけど、プログラムに関しては、
そこにいる教授なんか糞としか思えなくなるまで勉強した。
3年間、1日8時間以上はプログラムやってた。
勉強してたってよりハマった。
画面に絵が出たり十時キーで動かしたり、全てが楽しかった。
572:仕様名無しさん
07/06/20 17:59:54
やっぱりそれくらいやらないとだめなんだ・・・・。わかりました。
俺も、頑張ります。
573:仕様書無しさん
07/06/20 19:37:32
ここでへっぽこゲー専卒の俺が登場。
他は全くダメだったけど、プログラムだけなら
毎日放課後残ってコツコツやってたし、夏休みも毎日勉強してたな。
ゲームを作ること自体が楽しいから、勉強も全然苦にならなかった。
574:仕様書無しさん
07/06/20 19:59:21
8時間くらいじゃまだまだだな
俺なんか寝てるときとアニメ見てるとき以外ずっとプログラミングしてた
たまに夢の中でもやってた
575:仕様書無しさん
07/06/20 20:23:36
俺は一時期ゲーム業界を目指したけど、やっぱりやめてシステム系にいったよ
でもゲームを作るのは楽しいので趣味で作ってる
ちゃんと画面に絵が出て自分で絵を動かしたりシーン変えたりとか出来るようになると面白くなってハマるよね
ただそれに行き着くまでに挫折する人が多そうだけど
業界に行く人はそのハマり具合いが凄かった人かな、まさに寝るときと食べるとき以外はプログラムって感じ
デバックとかならまだしも、プログラムを組む時点で苦痛な人には向いてない職業だと思う
576:仕様書無しさん
07/06/20 23:34:24
何でもいいからとりあえずなんか生み出せてそれに人が寄ってくるなら
最低限の適正はあると考えてもいいんでねーの
577:仕様書無しさん
07/06/20 23:35:47
ゲーム作るのと会社に入る適正は別ものだと思うのです。
578:仕様書無しさん
07/06/21 01:30:38
プログラムを組むという感覚は無いな。
動かすのにプログラムが必要だっただけ。
外へ行くのに服を着るようなもの。
579:仕様書無しさん
07/06/21 02:40:46
そういう人は早々とプログラマを「卒業」する法則
580:仕様書無しさん
07/06/21 11:04:31
コミュニケーション能力が普通にある奴はそうだな
無い奴は永遠にコーダー生活を続けるだけ
581:仕様書無しさん
07/06/21 19:31:15
趣味でゲーム作ってる時は何でこんなにハマってんのかわかんないくらい一日中プログラム組んでる時がある
食事は取るけど軽食で済ましてるしほとんど食べながら作業
つか、時計見ないと腹減ってるのか眠いのかも分からないのが怖い
でもやる気出ない時は10分くらいで飽きる
582:仕様書無しさん
07/06/21 20:53:25
就職するまで、実習以外でプログラムなんて組んだことの無い理系旧帝大卒が
来ましたよ、と。
やったことない？ プログラムなんて２週間でどうとでもなるヨ。
と初日に言われて、実際２週間でなんとかなっちゃいました。
583:仕様書無しさん
07/06/21 20:58:07
自慢したいのかもしれないけど大したことしてない奴だってのはわかった
584:仕様書無しさん
07/06/21 20:59:17
それ以前にスレタイも読めない大卒って
585:仕様書無しさん
07/06/21 21:02:07
おい、お前らXbox360ソフトださねーと本社前にウンコするぞ
586:仕様書無しさん
07/06/21 21:08:04
プログラムの本質なんて物理や数学でほとんど習っちゃうからな
587:仕様書無しさん
07/06/21 21:08:59
>>585
XNA デベロッパー センター
URLﾘﾝｸ(www.microsoft.com)
588:仕様書無しさん
07/06/21 22:33:36
>>585
ウンコライブラリをどうにかしてくれ
589:仕様書無しさん
07/06/21 23:13:44
とりあえず3社とも触ったけど、MS>N>>>>>>>SCEっつーことか？
590:仕様書無しさん
07/06/21 23:15:17
>>589
ＰＳはそんなに作りにくいのか。
591:仕様書無しさん
07/06/21 23:21:34
初代はつくりやすかった
592:仕様書無しさん
07/06/22 00:07:52
いわゆる次世代機のことじゃね？
593:仕様書無しさん
07/06/22 00:08:15
>>578
最近ちょっとスカートにフリルがついたり
襟に綿毛がついたり、アクセサリーまで必須になってきて
服を着るのが目的なのか外へ出るのが目的なのかわからななってきた
594:仕様書無しさん
07/06/22 01:24:25
ブラジャーしれ
595:仕様書無しさん
07/06/22 12:27:26
作りやすいゲームが作りたいならPCでやってろ
596:仕様書無しさん
07/06/22 13:40:49
知逝くゲーばっか作ってるくせにナマ言うんじゃねぇ
597:仕様書無しさん
07/06/22 14:06:39
国内市場のみを見るならばXBOX360で出す意味は全くない。
国内市場のみを見てもWiiではどうせ任しか売れない。
マシンなんかどれでも同じ。
どっか金のあるメーカが売れるゲーム作れば、それに便乗して似たもの作るだけ。
今は売れてなくても、売れたゲームが出たならPS3でも構わない。
CでもKでもNでもどこでもいいから、早く次世代機でヒット作を出せ。
でないと便乗するまえにウチが死ぬ。
598:仕様書無しさん
07/06/22 14:07:41
って、うちの馬鹿社長が言ってた。
599:仕様書無しさん
07/06/22 16:55:41
いやぁ、ある意味PCのが大変だと思うぞ。
特定のハードウェアで問題起きたり。
コンシューマーはDirectXみたいなライブラリはないかもしれんが、
ハード依存の問題はない。
600:仕様書無しさん
07/06/22 17:07:22
明らかに企画段階で売れそうにないと思うゲームのプログラムを組んでいる時の心境を教えてください
601:仕様書無しさん
07/06/22 17:27:48
売れなくても新しい技術が身につけられればそれでいいや
602:仕様書無しさん
07/06/22 17:51:23
遊びじゃないんだから、どうやったら面白くなるか考えるがな。
603:仕様書無しさん
07/06/22 17:54:40
>>602
プログラマの意思で面白くなるように仕様を変更することってできるの？
提案したとしてもそれが通ることってあるの？
604:仕様書無しさん
07/06/22 17:57:03
>>600
企画にGoサインが出るということは、それなりに採算とれるっつう事だから、
別に何も感じない。というか、ゲームで遊んでるわけではないので、
作ってるものが自分の趣味に合うかどうかなんて関係ない
605:仕様書無しさん
07/06/22 17:57:42
俺はもっとも遊びに近い仕事だと思ってるけどな
606:仕様書無しさん
07/06/22 18:03:14
>>603
普通はない。
上流が下流に仕様変更を指示することはあっても、下流が上流に対して
変更を提案したところで、「お前にとって面白いかどうかは重要ではない。
客層から見たときに最適なのはこの仕様である。」と蹴られる。
そのゲームの対象がゲーマー層であり、プログラマがゲーマーであり、
プログラマ主導な古い作り方をしているときにはありうるかもしれない。
607:仕様書無しさん
07/06/22 21:45:32
>>603
会社もしくは上の人間、そして変えたい奴による
やりかたは色々あるだろうけど、上を納得させられるなら仕様変更は十分可能。
608:仕様書無しさん
07/06/22 23:01:21
>596
痴育ゲームはなかなか売れないねぇ…。
609:仕様書無しさん
07/06/22 23:29:52
角田の筋トレゲーム出るってな。
ビリーズ来日にあわせての発表だったのかね？
610:仕様書無しさん
07/06/22 23:40:09
>>582
自慢なのか、一生懸命頑張ったのか分からんが
甘く見て自分のプライド崩された時に死にたくなるよ
611:仕様書無しさん
07/06/23 01:28:17
ゲームプログラマなんてそんなもんだよ。
PG自体は誰でも出来るんだから。
作ったら漏れ偉い？ →偉い偉い僕ちゃん凄いね。
こういう世界。
612:仕様書無しさん
07/06/23 01:49:14
>610
既に壊れてないとあんな発言2chにすら出来んとｵﾓ。
613:仕様書無しさん
07/06/23 08:05:56
>>604
×：それなりに採算とれるっつう事
○：それなりに採算がとれるとうまく言いくるめた
そして売れなかったら「おまえらが糞なソフト組むから、俺の神企画がクソゲーになったじゃねーか！」と逆ギレ
614:仕様書無しさん
07/06/23 08:22:08
プログラムで難しいのは生産性と規模
615:仕様名無しさん
07/06/23 14:44:02
俺は、数学や物理が苦手だからかなり不安だ・・・・。
616:仕様書無しさん
07/06/23 15:10:07
誰でも出来るってもレベルの差ははっきりしてるけどな
617:仕様書無しさん
07/06/23 15:21:06
>>615
自分の得意なところで勝負すればいいんじゃねーの？
ゲームつったって全てが数学と物理とか描画だけで出来てるわけじゃないし
618:仕様書無しさん
07/06/23 16:00:31
>>615
トップクラスの会社、組織以外ではたいした事無いから安心しる。
ロジックを組むという事だけならたいした奴は居ないと思って良い。
たまに凄い奴もいるけど、それはレアケース。
その開発環境に習熟していると言う事、長年やってるからいろいろなコネがある
と言う事をレベルの差と言うんだよ。
あるいは、使えない奴が、さも使えるかという触れ込みで入ってきてるのが普通。
使えないのがデフォだから、Ｃで普通にプログラムできるだけでネ申だぞw（ちょっと誇張しすぎか）
それを埋めるには、コードを読みまくって、環境に慣れる努力をすれば良い。
やる気があるなら、すぐに追いつけるw
619:仕様書無しさん
07/06/23 16:38:56
>>618が業界人で言っていることが本当なら>>582みたいなやつでも普通に業界の第一線で活躍できるんだろうな
そしてそれは同時にゲーム業界がどれだけレベルの低い集団（プログラマ）の集まりかというのを物語っている
620:仕様書無しさん
07/06/23 17:02:30
開発環境に習熟していて、普通にプログラムが組める（抽象的だけど業界的にそんな認識）なら
十二分にプログラマを名乗れるぞ。
ゲームのエンジンは使いまわし、画面効果とかは同じような物をよく見かけるだろう？
ツールさえ使えれば十分なんだ。
３Ｄのゲームのエンジン作ってる奴以外はそういう環境依存型のベテランだと思っている。
621:仕様書無しさん
07/06/23 17:15:38
カプコンって結構プログラマのレベル高いような気がするけどどうなんだろ
最近は微妙だが
622:仕様書無しさん
07/06/23 17:40:00
げりぱぶに大量に引き抜かれたお
623:仕様名無しさん
07/06/23 19:12:14
>>618
わかりました。とりあえずプログラムを地道に頑張って見ます。
624:仕様書無しさん
07/06/23 19:14:53
>>620
二週間あれば殆どの現場で雑用出切る位には十分なれる
お前の言うレベルってなんだよ
625:仕様書無しさん
07/06/23 19:39:56
なんかゲームプログラマってレベル高いというイメージがあったんだけど違うのかな
とりあえず自前でDirectXの適当なライブラリ組めてシューティング作れる程度なんだけど
あんま問題ないってことかな？
626:仕様書無しさん
07/06/23 19:51:36
>625
井の中の蛙ってやつにならないように、外に眼を向けようぜ。
自分で自分のレベルを勝手に決定しているやつは馬鹿だ。
627:仕様書無しさん
07/06/23 20:47:56
>>582
プログラムなんて組んだことの無いのに就職できるって、理系旧帝大卒ってのはすごいんだね
2週間も教えてくれるなんて、いい会社だね。
なんて一瞬関心してしまった。よく読んだら実習はやってたんだ・・・だまされた気分だ
628:仕様書無しさん
07/06/23 21:01:15
二週間の講習で3年兵扱いで派遣にだされるのはよくあること。
629:仕様書無しさん
07/06/23 23:25:29
すみません、質問なんですが
COBOL言語をマスターしてる人にとって
C++言語は勉強しやすいですか？
C++は今までノータッチだとして。
630:仕様書無しさん
07/06/23 23:54:09
>628
2週間も講習があるなんて、スバラシイ会社ですね。
631:仕様書無しさん
07/06/23 23:56:28
過去のプログラムの経験有る無しに関わらず勉強するのは困難だ、そびえ立つ糞！！それがC++
しかし、現状これ以外の選択肢はない、まったくこの世は地獄だぜ
二週間の奴はとりあえず見ただけレベルだろ
632:仕様書無しさん
07/06/24 02:39:50
職種の中で、他職種から一番嫌われる職種って噂は本当ですか？
633:仕様書無しさん
07/06/24 02:45:22
>>629
コンピューターの存在すら知らなかった人よりは勉強しやすい
634:仕様書無しさん
07/06/24 02:59:07
>>617
食わず嫌いはよくないと思う
直感が働く奴よりはじめ苦手な奴のほうが基礎がしっかりできていいときもあるぞ
なまじ高校大学と勘で数学できてきた奴ってのは
いざ３Ｄやったときに直感が頼りにならなくて壁に当る奴もいる
人により色んなタイプがいる。
はじめ得意だからといって最後まで伸び続けるとは限らない逆もまたしかり。
結局こういうのって自分を最後まで信じることができるかどうかなんだよね。
くだらん人生歩んできた奴ってのはここで腐る
難しい課題をクリアすることができる自分を信じていてやれない
才能以前にここで死ぬ
635:仕様書無しさん
07/06/24 03:46:41
>>633
お前、頭大丈夫か？
636:仕様書無しさん
07/06/24 08:09:45
>>629
COBOLをマスターしてる、ということは論理の組み立ては完璧、ということ。
使い方にもよるけど、ほぼ問題はない。
だが、ゲームプログラマとCOBOLはあんまり関係がない気がするぞ。
637:仕様書無しさん
07/06/24 08:23:17
COBOLができるからってC/C++ができるとは限らん。
コボラの再教育やったことは何度かあるが、ポインタあたりで撃沈する奴の
比率は素人と大差無いような気がする。
638:仕様書無しさん
07/06/24 08:48:25
1日目 事務手続き、社則等
2日目 社会人としてのマナー
3日目 プログラミングとは
4日目 現場投入
639:仕様書無しさん
07/06/24 10:37:18
>>638
ゲームプログラマにそんなもの必要ない。
挨拶が出来るだけで上出来だ。
１日目から現場投入。
出来ない奴は１～３ヶ月以内に切る。
640:仕様書無しさん
07/06/24 13:09:44
１日目 事務手続き、自分のＰＣ組み（デザイナも全員）
２日目～１週間ほど ２Ｄ周りの講習
１週間～２週間目 ３Ｄ周りの講習、なんか簡単なゲーム作れ
２週間目～ 現場へ投入
でした。
641:仕様書無しさん
07/06/24 13:11:16
訂正：３週間目から現場へ投入
642:仕様書無しさん
07/06/24 18:28:44
1日目 事務手続き、社則等
2日目 ビジネスマナー
3日目 コーディング規約
4日目 現場投入
私はこんな感じだった。
643:仕様書無しさん
07/06/24 18:50:29
3回ほど名刺変わったが、実際仕事で渡したことは一度も無い。
644:仕様書無しさん
07/06/24 18:59:36
みんな現場投入早いな…。
俺、新卒で入社して最初の三日間はPC渡されただけで殆ど放置されてたよ。
4月に入社して、現場投入されたのも12月だし。
645:仕様書無しさん
07/06/24 20:05:05
中小は即現場。
大手はちゃんとオリエンやる。
646:仕様書無しさん
07/06/24 20:07:48
ゲーム業界って先が暗い割には業界就職志望者が多いらしいけど人材って溢れてるもんなの？
647:仕様書無しさん
07/06/24 20:26:00
>638
今年の新人君は２日目まではやったみたいだぞ、ウチの会社は。
３日目に現場投入だった。
648:仕様書無しさん
07/06/24 20:27:35
>646
人は溢れてるけど、『材』とか『財』とかは希少なんじゃないか？
どっちかというと『罪』の方が多そうな気がする。
今までノンベンダラリと生きてきてゴメンナサイ。
649:仕様書無しさん
07/06/24 21:12:21
>>644
そ、それは才能も経験もなｋ
650:仕様書無しさん
07/06/24 23:11:34
>645
９ヶ月もオリエンはやらないだろ、いくらなんでも。
651:仕様書無しさん
07/06/25 01:42:05
講習って何やるの？
ごっつい糞ライブラリがある会社なら、その説明当たりだと思うけど、それが無いならサンプル見ておいてぐらいしか無いと思うんだが。
652:仕様書無しさん
07/06/25 03:56:06
>>648
罪ってｗｗ
こんなところで懺悔かい
653:仕様書無しさん
07/06/25 04:58:57
>>651
みんながお前のように会社が使ってる開発環境やコーディング規則、
そもそもその言語に通じているわけじゃないからな
その会社の常識や、そもそもマとしての常識も叩き込まないといけないわけよ
654:仕様書無しさん
07/06/25 07:08:49
ウチの会社結構大きいけど、コーディング規約無いな。
655:仕様書無しさん
07/06/25 08:12:58
「プログラマー＆テスターやってます」って自己紹介文をたまに見るんだけど
このテスターってなにをする人の事ですか？
656:仕様書無しさん
07/06/25 08:18:09
バグを洗い出すために徹底的にソフトウェアをいたぶる為の人
657:仕様書無しさん
07/06/25 08:36:16
技術の多様化に人間がついていけなくなってんだよ
658:仕様書無しさん
07/06/25 13:09:16
技術的ではなく、やる気的にね
659:仕様書無しさん
07/06/25 20:09:56
テスターが何もせずにチェック項目にチェックを入れるのは
よくあること。
660:仕様書無しさん
07/06/25 20:27:47
ゲーオタ垂涎の発売前のゲームを遊びまくった上に金までもらえる夢のお仕事。
661:仕様書無しさん
07/06/25 22:18:32
エロゲのデバッガーはやはりおちんちんが大きくなるかも答えなくてはいけないのですか？