C/C++ゲーム製作総合スレッド Part7 [転載禁止]©2ch.net

**名前は開発中のものです。** · 2015/01/11(日) 10:19:31.85

ゲーム製作におけるC/C++全般に関するスレです。

元スレ
DXライブラリ総合スレッドその18
http://peace.2ch.net/test/read.cgi/gamedev/1399459468/

前スレ
C/C++ゲーム製作総合スレッド Part1
http://toro.2ch.net/test/read.cgi/gamedev/1337516528/
C/C++ゲーム製作総合スレッド Part2
http://toro.2ch.net/test/read.cgi/gamedev/1351015269/
C/C++ゲーム製作総合スレッド Part3
http://toro.2ch.net/test/read.cgi/gamedev/1357899040/
C/C++ゲーム製作総合スレッド Part4
http://toro.2ch.net/test/read.cgi/gamedev/1376262450/
C/C++ゲーム製作総合スレッド Part5
http://peace.2ch.net/test/read.cgi/gamedev/1389798031/
C/C++ゲーム製作総合スレッド Part6
http://peace.2ch.net/test/read.cgi/gamedev/1404815419/

**名前は開発中のものです。** · 2015/02/03(火) 04:40:14.90

>>243
ありがとうございます。

**名前は開発中のものです。** · 2015/02/03(火) 13:03:57.60

スレはあってるけど板が違う的な。
まあ、ゲーム関係かどうかの境目って結構曖昧だけれども。

**名前は開発中のものです。** · 2015/02/03(火) 13:07:01.87

いずれにしろコードもなしに質問されてもエスパーしか回答出来ないですし

**名前は開発中のものです。** · 2015/02/05(木) 07:36:31.37

開発期間が長すぎて、開発環境が何度も変わるのってどう思いますか？
開発環境を固定する？それともコードを書き直して対応する？

**名前は開発中のものです。** · 2015/02/05(木) 08:11:52.44

boost辺りならまだしも、言語自体のバージョンが上がるまでって
一体どんだけ開発期間が長いか間が悪いんだよ…

どうしても使いたい追加要素でもなければ変えない　トラブルの素

**名前は開発中のものです。** · 2015/02/05(木) 09:22:24.85

CSのSDKとかじゃないの？
開発序盤なら対応、終わりが見えてたらそのままってのが普通だと思うけど

**名前は開発中のものです。** · 2015/02/05(木) 10:05:22.41

昔VS2008から2010に上げたけど特に問題は起きなかった

**名前は開発中のものです。** · 2015/02/05(木) 12:20:47.44

vsの2005から2012に上げたら、Releaseでは動くけどdebugでは動かなくなった
自前で作ってた文字列クラスが弾かれたから、現在、std::wstringに置き換え中

**名前は開発中のものです。** · 2015/02/05(木) 17:18:01.03

>>247
何年にもわたって開発を続けていくようなものなら
あんまり気にせずに変えちゃう

**名前は開発中のものです。** · 2015/02/05(木) 19:05:51.48

iOS向けなら変えざるを得ない

**名前は開発中のものです。** · 2015/02/05(木) 19:45:56.22

プロの人も来てるのかも知れないけど、同人ならぶっちゃけ
DirectX9辺りの技術基盤があれば十分じゃないの。

新技術に取り組むこと自体が目的化して、ゲームを完成させる方が
疎かになってしまうって、何かありがちな気がする。

**名前は開発中のものです。** · 2015/02/05(木) 22:51:52.09

別に必要ないなら使わなければいいんです、エロい人にはそれが分からんのです

**名前は開発中のものです。** · 2015/02/06(金) 08:51:59.99

だまれ朝鮮人

**名前は開発中のものです。** · 2015/02/06(金) 08:53:55.71

idがバグ

**名前は開発中のものです。** · 2015/02/06(金) 09:00:23.95

>>254
DirectXがそもそも出来ない人が話に混じってるだけだから気にしない方が
DXライブラリ程度でいいんじゃないかな？同人なら
自作ライブラリ作れる人ですら少ないよ

**名前は開発中のものです。** · 2015/02/06(金) 11:05:36.91

面白けりゃ何でもいいんだよ。

**名前は開発中のものです。** · 2015/02/06(金) 14:58:45.96

もとの環境で大体完成していたのに、
無理やり次世代機用に作り直そうとしたがうまくいかず、
そのまま爆死した家庭用機向けソフトのプロジェクトなら知ってる

**名前は開発中のものです。** · 2015/02/06(金) 17:34:24.75

>>260
RomからCD-ROMへの移植は苦労が多かった
ROMの容量が4Mバイト超えてるとRAMご足りなくなって、動的に入れ換えしようとするとリソースのマネージメントが大変だったから

**名前は開発中のものです。** · 2015/02/06(金) 22:49:06.68

しかもそれだけ苦労したにもかかわらず、ロードが遅いと文句言われたに違いない…。

**名前は開発中のものです。** · 2015/02/07(土) 13:13:21.00

>>260
PS3だな　そうに決まってる

**名前は開発中のものです。** · 2015/02/07(土) 13:42:24.95

>>251
置き換えたらさらに別の場所が動かなかったから2013へと移行したりｗ
いや、ネットでは動くコードと書かれているんだよ、2013からは動くと
うちのPCで2013はマトモに動くかな？今インストール中だが

**名前は開発中のものです。** · 2015/02/07(土) 14:45:09.34

ヘッダで前方宣言したはずのクラスがCandidates are: struct SimpleAudioEngineとエラーを出され
定義でreference to 'SimpleAudioEngine' is ambiguousとエラーを出されます
ヘッダではポインタしか使ってません
思うところがあるとすればSimpleAudioEngineの名前空間をusing namespaceしてるぐらいです

**名前は開発中のものです。** · 2015/02/07(土) 14:58:01.00

>>265
http://melpon.org/wandbox/permlink/8WYv9UpPeF3DROcf

**名前は開発中のものです。** · 2015/02/07(土) 16:04:21.06

異なる名前空間の中で前方宣言すると別物だとみなされて
あとでusing namespaceすると区別できない

**名前は開発中のものです。** · 2015/02/07(土) 19:26:49.25

開発環境をvs2012からvs2013に変更したのは大当たりだった
エラーの位置は分かりやすくなったし、デバッグ機能は大幅に強化されてるし、
文字列クラス(std::wstring)は扱いやすくなったし、全般的に軽くなった

**名前は開発中のものです。** · 2015/02/07(土) 20:51:50.60

std::wstringって何か変更あったっけ？

**名前は開発中のものです。** · 2015/02/07(土) 23:10:30.01

operaterがほとんど対応してなかったんだよ。
+=はあるのに+は無いとか、map<wstring,wstring>で使えないとか。

**名前は開発中のものです。** · 2015/02/07(土) 23:18:38.16

ためしてないがそれはないだろ。
あとSTLやC標準ライブラリ、C++標準ライブラリは備え付けのを必ずしも使う必要がない。
実装は多数ある。

**名前は開発中のものです。** · 2015/02/07(土) 23:55:35.77

たまたまインストールされてるのがVS2012だったから試してみたが普通に使えた

**名前は開発中のものです。** · 2015/02/08(日) 00:06:03.58

あれ？って事は、vs2005を後から入れたせいでおかしくなってるのか？？

**名前は開発中のものです。** · 2015/02/08(日) 00:15:39.03

UMLのツールを買ってみて、たまたま家のVSで対応してるのが2005だけだったから、
後からインストールし直したんだよな

そっか、VS2005のコードでC++のコードが上書きされてたか

**名前は開発中のものです。** · 2015/02/08(日) 00:52:07.50

とんでもない話だなｗ

**名前は開発中のものです。** · 2015/02/08(日) 01:13:03.19

VC6でもoperator+位あったような気もするけど
不便な所は連続したメモリ領域の保証が無いから
実装上はともかく厳密にやろうとするとvectorじゃないとダメな所

**名前は開発中のものです。** · 2015/02/08(日) 09:15:03.02

連続領域かどうかに関しては
- vector C++03/11 → 連続保証
- string C++03 → 実装依存 / C++11 → 連続保証
らしいぞ。最近のVCなら大丈夫なんじゃないかな。

**名前は開発中のものです。** · 2015/02/08(日) 13:48:18.26

連続性が保証されるようになっているとはな
外見は変わらなくても内部は少しづつ変わってるんだな

**名前は開発中のものです。** · 2015/02/08(日) 13:51:09.60

地味ではあるが重要なことだな。

**名前は開発中のものです。** · 2015/02/08(日) 13:58:02.91

mallocのメモリ配置はOSで変わるんじゃなくてコンパイラで変わるみたいやね

**名前は開発中のものです。** · 2015/02/08(日) 15:05:56.00

依存するのはコンパイラじゃ無い
ランタイム依存

**名前は開発中のものです。** · 2015/02/09(月) 20:39:13.54

なんにせよ、ポインタはむやみにいじらない方がよさそうね

**名前は開発中のものです。** · 2015/02/10(火) 22:00:30.08

ポインタは使い勝手がわかると色々出来るが、無くても問題無くなってきてるからなぁ……

**名前は開発中のものです。** · 2015/02/10(火) 23:49:52.25

それなりのもの作ろうとしたらアロケーター自作になるゲーム制作はポインタ必須なんじゃないの

**名前は開発中のものです。** · 2015/02/10(火) 23:59:52.09

プラットホームによるとは思うが、いまだにカスタムアロケータなんて使うのか？
OSや言語処理系を書いているわけではないだろうに

**名前は開発中のものです。** · 2015/02/11(水) 00:01:51.67

車輪の再発明が好きなんだろ

**名前は開発中のものです。** · 2015/02/11(水) 00:26:12.68

流石にOSデフォルトのアロケーターは使わないんじゃないの
ライブラリのメモリプール使うにしてもポインタは使うだろうし

**名前は開発中のものです。** · 2015/02/11(水) 00:38:39.31

アロケーターはC言語かSTLのやつのことだろ?
OS自体のメモリ管理はOS自体のソースからビルドしないと変更むりでは。

**名前は開発中のものです。** · 2015/02/11(水) 00:41:52.28

普通にnew、deleteしたらOSのAPIでメモリ確保するんでないの？
STLはどうかわからんけど

**名前は開発中のものです。** · 2015/02/11(水) 00:51:21.24

>>288
mallocの置き換えぐらいリンクするライブラリー変えるだけだよ
tcmallocでググれ

**名前は開発中のものです。** · 2015/02/11(水) 00:52:08.05

new deleteの動作なんて実装によるとしか言いようがない
STLのstd::allocator<T>の話なら、単にnewとdeleteを呼び出す実装になってる

**名前は開発中のものです。** · 2015/02/11(水) 00:59:11.50

mallocやnewを置き換えてもOSの命令を使ってたら
OS自体のメモリ管理の制約は受けるわけで。
OSと完全に独立できるものか?
OSが既に管理してるところを横取りしないとならないが。

**名前は開発中のものです。** · 2015/02/11(水) 01:01:23.93

ちょっと前に「ゲームの場合、出現オブジェクトの個数に上限を設けることが多いから
new deleteせず自分でプールを確保する手もある」という話をしなかったっけ。

とりあえずstd::allocator<T>で書いといて、あとでカスタム化してもよいのでは。

**名前は開発中のものです。** · 2015/02/11(水) 01:03:22.28

malloc - Wikipedia

OSのカーネルでもアプリケーションと同様にメモリ確保が必要である。
カーネル内にもmalloc相当の関数はあるが、その実装はCライブラリのものとは大きく異なる。
例えば、DMA用のバッファには特別な制限が課せられることがあるし、割り込み処理でメモリを動的に確保したい場合もある。
このため、カーネルの仮想記憶サブシステムと密に連携した malloc 実装が要求される。

**名前は開発中のものです。** · 2015/02/11(水) 01:04:29.98

余程特殊な用途でないかぎり既成の物使った方が速いから

**名前は開発中のものです。** · 2015/02/11(水) 01:06:40.34

自作アロケーターは最初に領域確保してその分を切り盛りするでしょ
ていうかそれ以外の作り方を知らない

**名前は開発中のものです。** · 2015/02/11(水) 01:06:46.81

>>294
スレ違い
お前はゲームをOSから作るんか？

**288** · 2015/02/11(水) 01:16:23.87

>>287に対して、自作アロケータ、マイアロケータってのは
ほとんどのケースで、OSデフォルト、カーネルアロケータに依存してるだろ?って反応なわけで。

**名前は開発中のものです。** · 2015/02/11(水) 01:32:15.63

そうだな
>>287
が言ってるOSデフォルトってのが悪かった。
アプリケーションが使うメモリアロケーターの殆どの実装はライブラリが行ってる。
OSからシステムコールでブロック単位でメモリを貰いアプリケーション内で分配な。

**名前は開発中のものです。** · 2015/02/11(水) 01:41:17.25

すんませんVC++のメモリ確保がWin32APIの関数呼ぶだけって何かで見たからそういうもんだと思ってました

**名前は開発中のものです。** · 2015/02/11(水) 01:49:31.11

>>296
アプリケーションとしてのゲームはこれで確定だと思ってた
動的と言えば動的だけど都度都度確保はあり得ないって意味でこの手の話はスルーしてたけど、そう言うものでも無いみたいだと知ったわ
取れなかった場合の処理は思い付かないけど

**名前は開発中のものです。** · 2015/02/11(水) 01:55:07.09

ヒープ、動的確保は丸投げに近いが。普通のauto変数とかは最初に確保した領域を使いまわす。

メモリの4 領域
http://brain.cc.kogakuin.ac.jp/~kanamaru/lecture/MP/final/part06/img6.png
http://brain.cc.kogakuin.ac.jp/~kanamaru/lecture/MP/final/part06/node8.html

テキスト領域：機械語に翻訳されたプログラムが格納される. この機械語の命令が 1 行づつ実行されることでプログラムが動く。

静的領域：グローバル変数などの静的変数が置かれる。

ヒープ領域：メモリの動的管理 (C 言語の malloc 関数や C++ の new 演算子でメモリを確保すること) で用いられる。

スタック領域：今回の演習で扱ったように CPU のレジスタを一時的に退避させたり、また C 言語の自動変数 (多くのローカル変数) が置かれる。

**名前は開発中のものです。** · 2015/02/11(水) 02:24:49.00

いわゆるメモリープールのようなものは既にランタイムに実装されてる場合もあるし
自分で実装する・しないは実行環境によると思う。
最近はこの辺のことは既に当たり前になってるのかどうか知らないけど、
検索してもあまり引っかからないね。とりあえず引っかかったところ
http://vcpp-ml.ldblog.jp/archives/1169943.html
ではVCのランタイムのソースみればとなってるので
興味ある人は読んでみては。

**名前は開発中のものです。** · 2015/02/11(水) 02:41:42.58

俺が昔作ったベンチ引っ張り出してきた
10000個確保して解放を1セットで、10回繰り返す

malloc 0.0104349686516726 100
new 0.0170437163409596 163.332702856062
tlsf 0.0327989992535455 314.318138831095

右側がmallocを100とした場合の倍率。意外とtlsfは遅い。
んで下が自作のメモリアロケータでnewとdeleteをオーバーロードしてて
上で使ったnewするソースをそのまま使ってる。

fixpool 0.01086365697986310 104.108189899754
fixpool-ss 0.00270476282206395 25.9201815774541

アルゴリズムは一回使ったものをリストにつなげておいて、newのとき取り出すだけ。
ssは上限が分かっている場合で、先にメモリ確保するのでmallocを上回れる。

まぁ、はっきり言って速度だけを考えると自作アロケータの必要はないかなレベル・・・と思う。
確か、スマートポインタのベンチもどっかにあったはずなんだが、どこだったか・・・

**名前は開発中のものです。** · 2015/02/11(水) 02:52:05.14

>>303
ゲームエンジン•アーキテクチャ（ソフトバンククリエイティブ）によれば、デフォルトのnewが遅い理由は管理コストとOSのコンテキストスイッチとあるけど
URL先の内容からすると最初に確保された分越えなければコンテキストスイッチは発生しないって事なんかな
ていうか2000年の時点でそういう仕様だったのか

**名前は開発中のものです。** · 2015/02/11(水) 02:52:16.60

>>304
その自作アロケーターって複数スレッドから呼んでも大丈夫なように作ってんの？
だったらたいしたもの。

今時モバイルですらマルチスレッドが当たり前だからベンチマークも複数スレッドで実行すべき。
スレッド使うライブラリーをリンクしないとシングルスレッド版のmallocとリンクする環境もあるし

**名前は開発中のものです。** · 2015/02/11(水) 03:06:07.85

>>305
ライブラリが貧弱な環境だと効果はあったんじゃない？
ライブラリが貧弱で有名だったPS3とか。
ゲームエンジンアーキテクチャって本PS専門デベロッパーだった人の著書みたいだし

**名前は開発中のものです。** · 2015/02/11(水) 03:24:52.81

>>306
データ読み込みや通信で「now loading…」、ムービー再生とか以外でマルチスレッドって何に使うの？
いろんな判定でシングルでないと困らない？
俺はコンシューマ長すぎのせいか、マルチスレッド(タイムスライス型)は、そもそもゲームシステムとして実装が思い付かない
どうしてもタスク()で疑似マルチしか作れないや

**名前は開発中のものです。** · 2015/02/11(水) 03:29:13.74

>>306
ポインタのつなぎ替えの部分に一応クリティカルセクション使ってる。
が、これのベンチがねぇ・・・
複数スレッドで同時に確保しまくって人為的にコリジョン起こしても、
シングルの場合と違って純粋な値が取れないので。

**名前は開発中のものです。** · 2015/02/11(水) 03:54:41.50

スマポあった。同じく10000を10回。

new 0.00696283003770957 100
shared_ptr 0.039324851409757 564.782584046715

生ポインタとboostのshared_ptrね。
下が自作のリンク方式とカリカリにチューンした参照カウント方式のスマートポインタ。

link 0.0273835524999122 393.281932082318
count 0.0157994938635595 226.911956460117

これも、安全をとるなら生より多少遅くてもboostで十分と思う。
自作のスマポは労力の割にはねぇ。

**名前は開発中のものです。** · 2015/02/11(水) 04:10:32.63

書き忘れてた。>>304はゲームに近いように
10000まで{ 4, 10, 20, 100, 208, 501 }のサイズを巡回して確保していってる。

>>310は同じオブジェクトをずーっと生成してる。
こうするとnewがなぜか結構速いんだけど、その状態で対決してみたかったので。

**名前は開発中のものです。** · 2015/02/11(水) 08:00:15.92

んーなんか車輪の再発明がどんどん無駄になってくのな
必要な機能が既存のコードにあるなら、わざわざ作る必要は無い、みたいな

**名前は開発中のものです。** · 2015/02/11(水) 08:08:59.24

自分は今は自作コンパクションを使ってるけど、これも誰かの作ったコードを流用した方が早い時代が来るのかな？

**名前は開発中のものです。** · 2015/02/11(水) 08:40:48.37

>>308
MTフレームワークの例
http://www.4gamer.net/specials/3de/lost_planet/lost_planet_04.shtml

**名前は開発中のものです。** · 2015/02/11(水) 13:02:10.23

>>314
これの詳細を知ってるが、レンダリングはPCだとGPU処理だから、マルチスレッドとは別で非同期でしょ？
それ以外は先程書いた通り
因みにこのフレームワークは自動変数(スタック)以外はメモリは静的に持ってるよ

**名前は開発中のものです。** · 2015/02/11(水) 13:10:49.29

ガチな将棋AIとか作ることになったらやっぱりCPUスレッド数のスレッド作って読みを分散するんじゃなかろうか

**名前は開発中のものです。** · 2015/02/11(水) 13:40:34.62

どうせなら複数マシンに分散させるべき

**名前は開発中のものです。** · 2015/02/11(水) 14:57:37.67

そもそもメモリ管理なんて個人でやるものじゃないよ
せいぜいオブジェクトプールのように局所的なところで使ったほうがいい
自作アロケータを使ってみたい気持ちはわかるんだけどねぇ

**名前は開発中のものです。** · 2015/02/11(水) 15:06:24.20

>>308
シングルスレッドでパフォーマンス十分なら要らないんじゃない？
その場合アロケーター自作しようとする理由すら解らなくなるけど。

レンダリングスレッドを分けるってのは比較的簡単だからよく使われてる方法だね。
グラフィックスのAPIが全て非同期という訳でもないし、呼ぶ事自体比較的コストが高いものもあるドローコールとか
あとGPUが全てやってくれるわけでもない。
影とかモデルの持ってるマテリアルによってはマルチパスレンダリングが必要になるしね
それら含めて一つの独立したスレッドでレンダリングを行うって事
どこまでやるかはそれぞれのゲームエンジンの実装次第だけど

**名前は開発中のものです。** · 2015/02/11(水) 20:31:12.70

PS3なんかはは汎用コアが貧弱でマルチスレッド使わないとまともに動かないらしいけど
PCはターボブーストなんかもあるし処理分割しなくてもそれなりに動くのかね
ゲームで重い処理って言ったらAIとか物理演算とか？
それらやらなきゃコア使い切る事もなさそう

**名前は開発中のものです。** · 2015/02/11(水) 22:28:39.42

自分の場合、（作ったのはC#とXNAだったけど）

・更新
非同期・4体のキャラの思考ルーチンをマルチスレッドで（他のキャラの状態は前フレームのものを利用）。
同期・同時に行う必要のある判定類。
非同期・4体のキャラのアニメーション演算(*)
↓
・描画（スキップされることがある）
非同期・キャラの描画コマンド発行（ただし、4体それぞれに(*)を同期）。(**)
同期
非同期・背景などの描画。
↓
・更新
※未了のタスクがあればいったん待機して、最初と同じ。

ということはやっていた。じつはXNAは(**)が異様に重くなるというハンデ持ちで、
(*)はC++だろうと当然重いはずだから、パフォーマンス上がると思うよ。

**名前は開発中のものです。** · 2015/02/11(水) 22:33:55.73

連投悪い。

というか、マルチコアのCPUなのにシングルで動作させてるって、同人ならともかく
商用ゲームだとハードを全然使いこなせていないんじゃないの。

仮にPS3相当かそれ以上のハードで、シングルで楽々動くゲームがあるとしたら、
それは「CPUスゲー！」じゃなくて「CPUを遊ばせている未熟なプログラム」
もしくは「絵的にボリューム不足」「敢えてシンプル路線のゲームにしただけ」だと思う。

**名前は開発中のものです。** · 2015/02/11(水) 23:00:37.92

妖精左「マルチスレッド！！」
妖精右「マルチタスク！！」
俺「じっそうできればいいから･･･」
部長「ま　だ　か　は　や　く　し　ろ　。」

**名前は開発中のものです。** · 2015/02/12(木) 00:02:20.82

>>322
C#なんて全然ハード生かせないだろC++で作れよ

**名前は開発中のものです。** · 2015/02/12(木) 00:29:15.74

C++至上主義の時代はもう終わった

**名前は開発中のものです。** · 2015/02/12(木) 00:32:29.34

まだだ！まだ終わらんよ！

**名前は開発中のものです。** · 2015/02/12(木) 02:23:42.32

さっき始まったばかりですよ

**名前は開発中のものです。** · 2015/02/12(木) 02:30:04.64

>>322
たしかにC#だと、ネイティヴDirectX呼び出す時点でカーネル切替が発生し、ボトルネックになる
（ただ一方、GCはちょっと工夫すればシーン切替時以外は抑制できる）。

まあC++が最強という事実は揺るがないし、だからここを覗きに来てるんだけど
今まで作った資産をそっくり移植するのは全部1人開発だと工数的に厳し過ぎるんよ。
自分はあくまでゲームを完成させるのが主眼なもんで。

**名前は開発中のものです。** · 2015/02/12(木) 02:30:45.99

>>324だった。

**名前は開発中のものです。** · 2015/02/12(木) 09:37:50.92

>>328
> 仮にPS3相当かそれ以上のハードで、シングルで楽々動くゲームがあるとしたら、
> それは「CPUスゲー！」じゃなくて「CPUを遊ばせている未熟なプログラム」
> もしくは「絵的にボリューム不足」「敢えてシンプル路線のゲームにしただけ」だと思う。

こんなこと言う人間が

> 自分はあくまでゲームを完成させるのが主眼なもんで。

なんてよく言えるな

**名前は開発中のものです。** · 2015/02/12(木) 09:58:41.94

Unityの台頭とC++erの更なる没落

**名前は開発中のものです。** · 2015/02/12(木) 10:00:56.62

社員さん、ステマ乙

**名前は開発中のものです。** · 2015/02/12(木) 10:16:24.93

世界は使いやすい道具の前にひれ伏す
これが分からない奴は一生地を這う

**名前は開発中のものです。** · 2015/02/12(木) 10:44:14.01

Unityあつかいづらいから自分でライブラリ作ったわｗｗｗ

**名前は開発中のものです。** · 2015/02/12(木) 12:11:18.44

アホか。

みなが同じ道具を使ったら、それを売って儲ける奴の小作農になるだけ。
これが分からない人こそ

＞一生地を這う

**名前は開発中のものです。** · 2015/02/12(木) 12:13:54.04

>>330
>>322はあくまで>>320に対する客観的な指摘。
それと「自分はあくまでゲームを完成させるのが主眼なもんで」は別問題だよ。

**名前は開発中のものです。** · 2015/02/12(木) 13:25:06.24

実際PS3の初期タイトルは酷いの結構あったな
アイデアファクトリーとか

**名前は開発中のものです。** · 2015/02/12(木) 15:23:29.14

作るものに応じて道具を選べない人が一生地を這うのでは

各処理をどんだけ細切れにしても結局全部処理しないと次には進めず、
しかも実は単一の処理は積み重ねても大して時間はかかっておらず、
単なるスレッドの立て損にしかなっていないんならマルチスレッドなんか不要
商業だからだのなんだのと適当な言い訳をしても、
実際は目に付くよさそうに見えるものに振り回されているキョロ充
まずは作りやすい方法で実装してテストして、ダメだったら作り直せばいいじゃん

**名前は開発中のものです。** · 2015/02/12(木) 17:28:07.56

Unityの社員ってステマのノルマがあるみたい

**名前は開発中のものです。** · 2015/02/12(木) 17:41:44.09

スレッドのが実装しやすい処理もあると思うの

**名前は開発中のものです。** · 2015/02/12(木) 19:41:03.02

うにちゃんは次期主力ゲームエンジンの座を狙っているからね、仕方ないね

何が悲しくてわざわざ柔軟な使い方のできる言語投げ捨ててゲームエンジンなんぞに…
PHPやらJAVAやらに行った方がマシ

**名前は開発中のものです。** · 2015/02/12(木) 20:21:56.36

そんなに自信があるのなら、自分たちでゲーム機を出せばいいのに
彼らの夢は、所詮は砂上の楼閣なんかね

**名前は開発中のものです。** · 2015/02/12(木) 20:26:40.79

このスレってレベル低いよな