C/C++ゲーム製作総合スレッド Part7

1 ：名前は開発中のものです。：2015/01/11(日) 10:19:31.85 ID:RDQlUyF+.net

ゲーム製作における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/

311 ：名前は開発中のものです。：2015/02/11(水) 03:54:41.50 ID:0cWu/C1d.net

スマポあった。同じく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で十分と思う。
自作のスマポは労力の割にはねぇ。

312 ：名前は開発中のものです。：2015/02/11(水) 04:10:32.63 ID:0cWu/C1d.net

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

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

313 ：名前は開発中のものです。：2015/02/11(水) 08:00:15.92 ID:JqfHYvpf.net

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

314 ：名前は開発中のものです。：2015/02/11(水) 08:08:59.24 ID:JqfHYvpf.net

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

315 ：名前は開発中のものです。：2015/02/11(水) 08:40:48.37 ID:45+5SbHz.net

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

316 ：名前は開発中のものです。：2015/02/11(水) 13:02:10.23 ID:tga+SBCo.net

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

317 ：名前は開発中のものです。：2015/02/11(水) 13:10:49.29 ID:vZk9YDm5.net

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

318 ：名前は開発中のものです。：2015/02/11(水) 13:40:34.62 ID:sOoti607.net

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

319 ：名前は開発中のものです。：2015/02/11(水) 14:57:37.67 ID:/JcbXeo3.net

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

320 ：名前は開発中のものです。：2015/02/11(水) 15:06:24.20 ID:rJC6nJDr.net

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

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