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/01/17(土) 20:55:17.63

Dictionary<Point, Tile> Mapしか使わん

**名前は開発中のものです。** · 2015/01/17(土) 21:10:19.92

>>41
enum定数でアクセスするのかな？
それにどんな情報を入れるんだろ

**名前は開発中のものです。** · 2015/01/17(土) 21:23:58.77

ベジェとか普通に書いたら多次元配列になるんじゃ…

**名前は開発中のものです。** · 2015/01/17(土) 21:56:16.62

>>41
やりません
コンテナ2つ重ねても無駄に複雑になるだけでしょ

**名前は開発中のものです。** · 2015/01/17(土) 22:50:59.20

>>41
リソースに余裕がある場面では使ってるな
規模が大きくなってくると細かいことまで気にしてられんからこれ使うとラク

**名前は開発中のものです。** · 2015/01/17(土) 22:59:23.12

>>39
テッセレータを使ったらいいのでは？
凹ませたい領域を4頂点の単純なタイルで表現し、それをフィールドに敷き詰めておく。
凹ませるときは、該当するタイルに対しテッセレーション（最大64分割）して、
高さマップを与えてディスプレースメントさせる。

**名前は開発中のものです。** · 2015/01/18(日) 00:08:51.85

>>45
やるぜ？
可変長CSVの読み込みとか

**名前は開発中のものです。** · 2015/01/18(日) 07:49:00.66

長さ不定のに多重vectorはしないかな

**名前は開発中のものです。** · 2015/01/18(日) 12:34:52.67

vector<vector<T>>は便利なときもあるけど、
コピーやトラバースのパフォーマンスがvector<T>に比べて著しく遅いんで、
そちらが重要なときは多少冗長でもvector<T>で扱うようにしてる。

**名前は開発中のものです。** · 2015/01/18(日) 12:40:46.60

vector<vector<T>*>

**名前は開発中のものです。** · 2015/01/18(日) 12:44:37.58

生ポインタ使うならdequeで良いだろ
とは言えないパフォーマンス差があるんだよな…

**名前は開発中のものです。** · 2015/01/18(日) 13:35:03.38

vector<unique_ptr<T>>

**名前は開発中のものです。** · 2015/01/18(日) 14:23:19.06

null_ptr

**名前は開発中のものです。** · 2015/01/18(日) 15:20:17.44

nullptrでは･･･

**名前は開発中のものです。** · 2015/01/18(日) 15:53:55.88

相当昔にC++触って、今と環境がかなり違いそうなのですが、
タスクシステムを実装する時、昔は固定長のメモリを予め確保したうえで、そのメモリを
newすることによって使っていたのですが、今のゲームもこのやり方が主流ですか？
それともスマートポインタ＋std::listでも速度出るのでしょうか？

スマートポインタとやらは、これはやってる事はガベージコレクションですよね？
速度に問題無しということですが、ヒープ領域から自由にnewdeleteして大丈夫なのかと不安になるのですが・・・

**名前は開発中のものです。** · 2015/01/18(日) 16:23:04.34

誰も使ってない

**名前は開発中のものです。** · 2015/01/18(日) 17:19:29.87

>>56
スマートポインタはリソース管理の安全性を高めるだけで、
new、deleteのパフォーマンスを高めるわけではない。
むしろクラス被せる分、オーバーヘッドが嵩む。
現代のハードウェア環境においては、多くの場合そのオーバーヘッドは問題にならないというだけ。

**名前は開発中のものです。** · 2015/01/18(日) 18:04:36.15

手動解放は、車で例えると
タイム短縮のためにわずかなエンジンパワーのロスも許されないプロレーサーや、
オートマはエンジンパワーが完全には伝わらないのでクソ
俺は完璧なギアチェンジ操作ができる（自称含む）のでマニュアルで通すんだって人向け

解放忘れてメモリリーク他の面倒な問題を起こしても泣かないなら全部手動で
それが嫌なら我々が作った処理班にぜひおまかせ下さい！
スマートポインタってそういうもの
shared_ptrやweak_ptr自体の書き忘れや循環参照などは防げないけど

>>54
ga

**名前は開発中のものです。** · 2015/01/18(日) 19:56:46.03

>>56
ここではWindowsならメモリ確保の負荷はそんなに問題にならないとしている

http://marupeke296.com/ALG_No2_TLSFMemoryAllocator.html

スマートポインタはGCってそれどういう意味だよ。
スマートポインタに使っている参照カウントはGCの方式の一つとは言えるが。

http://ja.wikipedia.org/wiki/参照カウント

**名前は開発中のものです。** · 2015/01/18(日) 20:33:19.91

おじさんは2万円前後の安もんの8インチタブ(CPU:Z3735G，RAM:1GB)を
即売会場でデモ機として使う都合で、バッテリー駆動でできるだけ長時間
ヌルヌル動かすために貧乏根性丸出しな組み方しちゃったけど、そういう
変な目的が無ければ自分の好きなようにやればいいと思うんだがな

○○のやり方が大丈夫なのか不安とか意味わかんねぇな。周りキョロって
ねぇで自分で決めた基準動作環境で自分でテストすればいいじゃんと

**名前は開発中のものです。** · 2015/01/19(月) 05:04:21.05

最近は底の方でも1GB
これなら多少雑に使ってもリークさえさせなければ問題ないな

なお512MB以下は爆死する模様
そんな化石がまだあるのかどうかは知らないが

**名前は開発中のものです。** · 2015/01/19(月) 08:44:27.43

全部起動時に読み込みとかやめて！

**名前は開発中のものです。** · 2015/01/19(月) 19:59:00.97

ふははは、貴様のセルを使うかどうかもわからない画像や音楽データで埋めてくれる！

読み込み時間といい、占有領域といい、ロースペにはある種のテロだな…

**名前は開発中のものです。** · 2015/01/19(月) 23:27:21.97

音楽やムービーのストリーム再生以外で、オンメモリでないゲームが作れるって凄いな。
そこまでリソースが用意できないよ。

**名前は開発中のものです。** · 2015/01/20(火) 00:33:47.17

メモリ次第ではあるけど
常駐とブラウザ合わせたら警告食らうくらいのゲームならあるんじゃないの

**名前は開発中のものです。** · 2015/01/20(火) 01:29:50.61

>>65
数年前、(旧)Android Marketに個人でゲーム出した時は機種依存の
バッドノウハウの量に本気で吐き気がしたけど、あれに比べたら
PCゲーは作りやすい思たよ。メモリフットプリント小さくするだけで
おｋなら大したこたないと思える程にAndroidスマホはカオス

(だった。今はどうなってるのか知りません)

**名前は開発中のものです。** · 2015/01/20(火) 10:35:24.77

1080pの画像を一度に100枚読み込めばロード地獄間違いなし
1920*1080*4 /1024/1024 *100 = 791MBぐらい
スマホだとアプリが強制終了するかも

グラフィックの豪華なアプリのModern Combat 5でもメモリは512MBぐらいまでしか使わない

**名前は開発中のものです。** · 2015/01/20(火) 22:05:53.74

圧縮テクスチャ使えば1/5くらいにはなるんじゃね？

**名前は開発中のものです。** · 2015/01/21(水) 16:36:27.53

そういや、Appmethodってどうよ？ちょっと気になってるんだが使ってる奴居る？

**名前は開発中のものです。** · 2015/01/21(水) 22:17:40.75

タスクシステムで組む時、
・タスクリスト２つ用意して移動と描画分ける
・タスクリスト１つに移動も描画も入れる

どっちがいいのでしょうか？個人的には前者にしたいけど・・・

**名前は開発中のものです。** · 2015/01/21(水) 22:19:47.80

前者にしたいのにできない要因を考えるのがよい
「みんながどうやってるか気になる」ってだけなら気にする必要はない

**名前は開発中のものです。** · 2015/01/22(木) 00:52:45.85

タスクシステムはバグった時に大変そうな印象
そりゃあ、バグれば大抵それなりに大変な目に遭うんだけどさ

**名前は開発中のものです。** · 2015/01/22(木) 02:20:52.62

>>68
一般的なアプリは、数MB

**名前は開発中のものです。** · 2015/01/22(木) 07:47:04.58

昔タスクシステムスレあったけど相手の主張への罵詈雑言だらけでいつの間にか消えたなｗ

**名前は開発中のものです。** · 2015/01/22(木) 16:27:46.03

移動と描画両方持ってたほうがスマートだべ

**名前は開発中のものです。** · 2015/01/22(木) 16:50:32.20

>>75
「タスクシステム」っていう名前が何を指すのかがすごく曖昧なのに
それを無視して自分の中の定義を押しつけ合う奴らの隔離スレだったし
消えて当然とも言える

**名前は開発中のものです。** · 2015/01/22(木) 17:35:35.81

まあ個人でゲーム作る分にはどう作ろうが60FPS出てちゃんと動けば勝ちだからなｗ
会社とかで厳密にタスク管理されてるなら覚えなきゃならんのだろうけど。

**名前は開発中のものです。** · 2015/01/22(木) 18:57:21.14

タスクシステムw
馬鹿しか使わん

**名前は開発中のものです。** · 2015/01/22(木) 21:08:37.90

>>79
なんで？

**名前は開発中のものです。** · 2015/01/22(木) 21:13:16.12

>>79
OS上で動くアプリならそうかもな
OS込みとしてならタスクは最適解だろうし、組み込み系で使われてるOSは名前が違うだけて同じ系統のものだよ
現在マイノリティなのは認めるけどな

**名前は開発中のものです。** · 2015/01/22(木) 22:06:24.79

ほーら始まったｗ
スレ立ててそっちでやれｗ

**名前は開発中のものです。** · 2015/01/22(木) 23:18:22.87

たすくしすてむってなあに？
おいしいの？

**名前は開発中のものです。** · 2015/01/22(木) 23:53:50.36

ごめんなさい
反射してしもた

**名前は開発中のものです。** · 2015/01/22(木) 23:56:43.23

だーかーらー、ただのリストに大げさな名前付けんなや

**名前は開発中のものです。** · 2015/01/23(金) 00:49:17.98

http://ja.m.wikipedia.org/wiki/TRONプロジェクト
多少は勉強になるから、読んでみたらどうだろう
これの亜流だよ

**名前は開発中のものです。** · 2015/01/23(金) 01:07:05.72

はじめからほとんど完成しているシステムに、
そのシステムの中枢部に触れないように要素を追加できるような実装を目指すなら有効
つまり、OSやエンジン作るならこれがいいかもしれない
が、そうでなければバグが修正困難だったり無駄な手続きが多いクソ
なんだ実行順って必要になった時にやらせろオラァァ

**名前は開発中のものです。** · 2015/01/23(金) 10:32:52.67

最近はどんな言語でもクロージャやジェネレータ (yield) をサポートするようになってきた。
タスクシステムとは呼ばれないけど、同じ目的には使えるんじゃないの？

描画に関しては、オブジェクトが自前で描画命令を発行するのか、
オブジェクトとは別にスプライトのような構造を用意して、描画はそちらに任せるかの差が大きい気がする。
巷のゲーム向けのフレームワークを見るに、後者のほうが可搬性は優れているんじゃないか？

**名前は開発中のものです。** · 2015/01/23(金) 10:52:38.49

オブジェクトが自前で描画って構造はゲームではあり得なくない？
ポーズ作るだけで一苦労じゃん

**名前は開発中のものです。** · 2015/01/23(金) 16:09:48.65

ネットに転がってるC++のゲームソースしっかりしたのはほとんどタスクシステムっぽいのばっかだから
そういうソースじゃないと読む気がしなくなったっていう(´・ω・｀)

**名前は開発中のものです。** · 2015/01/23(金) 16:29:50.12

単一のタスクだけで動かすと実によく機能するのに、
タスク同士を連動させようとすると途端にギクシャクする辺りが
実にぼっちらしくてよいが、
プログラムにそんなのやらせてどうするんだ

**名前は開発中のものです。** · 2015/01/24(土) 11:10:33.23

>>89
cocos2dとかそんな感じじゃね

**名前は開発中のものです。** · 2015/01/24(土) 13:26:12.19

C++11のstd::asyncってのが便利そうだから使ってみた。
確かに簡単に別スレッドに非同期に仕事をさせられる。
だが、どうも処理結果を受け取ってスレッドを終了するのに膨大なコスト（500msくらい）がかかるようだ。

代わりに、std::threadで常時スレッドを走らせておいて、std::mutexで同期を取りながら
データのやり取りをするようにしたらとてもスムーズに動くようになった。
しかし、std::asyncを使った場合と比べて、煩雑な記述が避けられない。

スレッド終了のコスト高杉。

**名前は開発中のものです。** · 2015/01/24(土) 13:34:42.36

TBBやPPL使っとけ

**名前は開発中のものです。** · 2015/01/24(土) 16:36:58.01

>>93
Windowsの話だよな？

**名前は開発中のものです。** · 2015/01/24(土) 20:09:43.23

C11使っとけ

93 · 2015/01/24(土) 21:51:42.90

>>94
サンクス。
調べてみる。

>>95
そうだよ。

**名前は開発中のものです。** · 2015/01/24(土) 22:06:18.60

1タスクごとにスレッドそのものを開始終了するとコストが高いので
想定するCPUのコア数だけワーカースレッドを用意して
それらにタスクを投げるのが定石じゃないかな。

・キューにタスクがない時はスレッド待機。
・タスクをキューに投げたら全ての待機スレッドを励起。
・いずれかのスレッドがキュー上のタスクを取得して実行、他は再び待機。
・タスクが完了してもスレッド完了せず、次のタスクを確認する。

デザインパターンにあったはず。

**名前は開発中のものです。** · 2015/01/24(土) 22:12:29.49

>>70
居ないのか……ま、いいや

**名前は開発中のものです。** · 2015/01/24(土) 22:16:34.35

スレッドの使い分けは適切に使わないと工数が意味もなく増殖するからな……

**名前は開発中のものです。** · 2015/01/24(土) 22:31:57.37

>>98
勉強になった。
やっぱそういうやり方が常套なのね。
そういや、マルチスレッドのデザインパターンってのがあるって聞いたことがあるな。
調べてみるわ。

**名前は開発中のものです。** · 2015/01/25(日) 21:12:51.89

タスクシステムよりシーン管理の方がよっぽど複雑だと思うの

**名前は開発中のものです。** · 2015/01/25(日) 21:27:30.87

シーンって「タイトル画面とキャラ選択画面とゲームのメインループその他」の意？
それとも「メインループ中の各シーン」のことかな。

>>101
標準テンプレートとか使える程度に技術のある人なら余裕で実装できるよ。

**名前は開発中のものです。** · 2015/01/25(日) 23:16:44.80

シーンったら状態遷移のことではつまり両方

**名前は開発中のものです。** · 2015/01/25(日) 23:53:06.16

>>98
ワーカースレッドが、キューに何もないことを確認して、
眠ろうとしているところに、
キューにタスクが入って、ワーカーに起きるよう指示を出す。
ワーカースレッドはその後寝てしまう。悪いことに全ワーカーが同じ状態。
次のキュー挿入で起きるけど。

なんかこんなこと考えると、こんがらがってきます。

**名前は開発中のものです。** · 2015/01/26(月) 15:41:45.19

>>105
キュー操作そのものにミューテックスで排他かけるから
「寝る」一連の動作と「起こす」一連の動作は複数のスレッドで並行に起こらない。

「寝て大丈夫かキューを確認したらタスクがあるから寝ずに実行」か
「完全に寝る→即座に次のタスクがキューにある状況で起こされる」のどちらか。

.NETだとWait()とPulseAll()、Javaならwait()とnotifyAll()で
簡単に実装できるけど、Win32APIだと少し面倒だった。

まずは上記2つのどちらかを調べて流れを掴んで、
それをC/C++用のAPIで書き表すことを考えてはどうかな。

**名前は開発中のものです。** · 2015/01/26(月) 16:22:24.05

>>106
condition_variable

**名前は開発中のものです。** · 2015/01/26(月) 17:05:42.55

*0.5の乗算と/2の除算
表す物はまったく同じだけど、前者の方が早いんだろうか？

**名前は開発中のものです。** · 2015/01/26(月) 17:06:44.50

/2の除算

**名前は開発中のものです。** · 2015/01/26(月) 17:08:38.36

シフト演算

**名前は開発中のものです。** · 2015/01/26(月) 17:36:32.42

整数ならそもそも結果が違うな
浮動小数ならコンパイラが最適化してくれるだろ

**名前は開発中のものです。** · 2015/01/26(月) 17:48:01.99

2のｎ乗倍しかできないじゃないですかー！やだー！
書き方が悪かったのは認める

**名前は開発中のものです。** · 2015/01/26(月) 18:30:30.51

>>112
浮動少数なら変わらないんじゃ？

**名前は開発中のものです。** · 2015/01/26(月) 21:04:49.69

>>106
Javaや.NETはスレッド簡単に書けるんか。
C++11や今後の新しいC++規格で同じようなライブラリ入れてくんないかな？

**名前は開発中のものです。** · 2015/01/26(月) 21:13:32.54

>>114
すでに >>107 が答えてくれてる。
std::thread, mutex, shared_mutex(=RWLock), condition_variable, async/future
C++11, 14 にて、この手の処理のための部品は揃ったと思われる。
あくまで部品なので、タスクキューなんかは自分で多少は書くことになるとは思うが。

**名前は開発中のものです。** · 2015/01/26(月) 21:19:26.58

#ifndef～#endifの組み合わせと#pragma onceの違いがよく分からない
前者は明確なインクルードガードだけど、後者は？

**名前は開発中のものです。** · 2015/01/26(月) 21:45:22.75

前者はガード以外にも使える
後者はガード専門

**名前は開発中のものです。** · 2015/01/26(月) 21:45:26.06

>>116
一回だけincludeしてねとコンパイラに言う

**名前は開発中のものです。** · 2015/01/26(月) 21:57:36.77

ついでに言うと#pragma onceは非標準

だけど主要コンパイラで実装してないものがないほぼデファクトスタンダード状態

**名前は開発中のものです。** · 2015/01/26(月) 22:06:02.39

>>115
ありがとう！
C++的にはちょうど良い落としどころっぽいね。
使い易くてハイパフォーマンスなスレッド記述をマスターしてやるぜ！

**名前は開発中のものです。** · 2015/01/26(月) 23:14:24.34

なるほど、むしろ#pragma onceがインクルードガード専用なんだな

>>119
マジで！？
VSで最初から書き込まれているプリプロセッサが非標準なのかよ

**名前は開発中のものです。** · 2015/01/27(火) 02:06:38.39

そもそも#pragma自体が、コンパイラ独自実装な機能で使うタグみたいなのじゃなかったっけ
まあ今となっては大抵のコンパイラで使えるみたいよ
http://en.wikipedia.org/wiki/Pragma_once

**名前は開発中のものです。** · 2015/01/27(火) 05:50:27.53

#pragma で始まるものは、互換性がない

**名前は開発中のものです。** · 2015/01/27(火) 09:41:49.82

>>123
リンク先見た？
俺もVCだけの互換の無い機能と思っていたが、互換してないのはIBMの一種(世の中のコンパイラを網羅してるわけではないけど)だけだったよ
標準仕様が～とかよりも便利なモノは取り込まれてくんだと思った

**名前は開発中のものです。** · 2015/01/27(火) 15:08:16.08

まあ#pragma comment(lib, "...")とか、ガチでVC独自の機能もあるし
>>123の考えが自然だと思う

**名前は開発中のものです。** · 2015/01/27(火) 17:35:37.67

C++14の新機能ってラムダ式にautoが使えるくらい？

**名前は開発中のものです。** · 2015/01/27(火) 22:54:28.14

>>125
なぜ comment なのだろう…

**名前は開発中のものです。** · 2015/01/27(火) 23:27:04.08

互換と呼ばれるパクリ・盗用

**名前は開発中のものです。** · 2015/01/27(火) 23:51:44.84

パクりパクられないインタフェースに存在意義は無い

**名前は開発中のものです。** · 2015/01/28(水) 00:13:05.10

ただのガラパゴス仕様だからな…

**名前は開発中のものです。** · 2015/01/28(水) 08:57:20.61

C++は消える運命

**名前は開発中のものです。** · 2015/01/28(水) 10:44:43.26

C++は地盤担当だから消えはしない。見えなくなるだけ。

**名前は開発中のものです。** · 2015/01/28(水) 16:49:43.54

土台のしっかりしている家は頑丈だからな
しかし最近、犬小屋程度の建物にビルのような土台を作ってどうすんだ？
と思うようにもなってきた

**名前は開発中のものです。** · 2015/01/28(水) 17:10:45.12

ウサギ小屋と呼ばれる日本の家をバカにするな！

**名前は開発中のものです。** · 2015/01/28(水) 19:20:53.89

最近ホント、この板でこじつけで日本の風習をバカにする奴が増えたな。

レガシで安定したものはラップして使い回すのが鉄板なのに、
横からうまく吹き込んで全部潰して一から作り直そうとさせる。
それだけ、相手の発展を遅らせることができる。

**名前は開発中のものです。** · 2015/01/28(水) 19:28:52.88

古いからといってバグが無いとは限らないけどな。
特に昔のコードは脆弱性対策が練られてない事が多い

**名前は開発中のものです。** · 2015/01/28(水) 20:15:35.81

FirefoxはJavaScriptの速度がChromeを超えたとか言われている割にもっさりしている感が否めない
後発のChromeの方が速い

**名前は開発中のものです。** · 2015/01/28(水) 20:18:09.19

>>137
感覚でなく実測で。

**名前は開発中のものです。** · 2015/01/28(水) 20:33:36.08

ブラウザの使用感はスクリプトの実行速度だけで決まるわけじゃないからな
読み込み時間の短縮も大事
v8の方がバイトコードを通さず直接マシン語を生成するから読み込み速いんじゃないか

全体の速度はTom's Hardwareが調べていたが
スコアを合計したら何かFirefoxが速いという結論になっているのが理解できなかった
どんな計算をしたのやら
http://www.tomshardware.com/reviews/chrome-27-firefox-21-opera-next,3534.html

古い記事だけど

**名前は開発中のものです。** · 2015/01/28(水) 20:35:32.45

関係ないけど体感速度を速く感じさせるって大事な事だね

Chromeはメモリの使い方や優先順位の割り振りが上手いんじゃないかと

**名前は開発中のものです。** · 2015/01/28(水) 21:30:30.57

chromeはメモリ馬鹿食いするしな
ブラウザしか起動しないならそれでもいいんだが