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

**名前は開発中のものです。** · 2014/07/08(火) 19:30:19.51

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

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

前スレ
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/

**名前は開発中のものです。** · 2014/11/03(月) 21:22:08.07

よしなよ

**名前は開発中のものです。** · 2014/11/03(月) 21:41:28.69

やめなよー

**名前は開発中のものです。** · 2014/11/03(月) 21:47:10.70

>>484
だからJAVAやってればいいじゃん
君にネイティブ言語はちょっと難しいんじゃないかな

**名前は開発中のものです。** · 2014/11/03(月) 23:31:40.14

ネイティブ言語わろた
継承ひとつ理解できないおつむじゃ諦めたほうがいい
もしくは独自のヘンテコなやり方をしたければ、ここで披露せずに一人でやっていなさい

**名前は開発中のものです。** · 2014/11/03(月) 23:48:43.67

stateパターンって、クラスつくるよりenumのメンバ追加の方が楽でいい。
でもstateパターン作るなら、状態遷移図は別にドキュメントを作る必要があると思う。
テーブルでやる場合はソースだけでもいいが、抜けがないかの確認がしにくい。

階層型の状態遷移はどうやるといいのだろうか。nestが2階層とか決まってたらまだいいけど、
自由に階層作りたいとか。

**名前は開発中のものです。** · 2014/11/03(月) 23:51:38.06

状態遷移はluaのコルーチンとかでやった方がいいのだろうか？
コードも見やすく、変更も動的にできるし。

**名前は開発中のものです。** · 2014/11/04(火) 00:05:07.98

なんで大手が採用してるか考えたら自明の理

**名前は開発中のものです。** · 2014/11/04(火) 00:09:15.45

独り言が激しいな　とりあえず階層型の状態遷移に話の焦点を絞ると、
親階層を子階層から遷移させる手法が考えどころになるだろうね

自分は独自のやり方でやってるけど、一般的にはどういうやりかたが
推奨されて普及しているのかよく分からない

**名前は開発中のものです。** · 2014/11/04(火) 00:40:17.63

コンパイルが待てないほど大きいの作るの？

**名前は開発中のものです。** · 2014/11/04(火) 01:00:57.23

自分のコードは大した量じゃなくても、ライブラリいっぱい使ってるとリビルド数分とか普通にかかる

**名前は開発中のものです。** · 2014/11/04(火) 01:25:54.32

boostのcoroutineとかcontextとかをゲーム製作で使ってる人いる？
興味があるので、できれば試用感を教えてほしいんだけど

**名前は開発中のものです。** · 2014/11/04(火) 02:14:53.36

コンパイルが待てないからスクリプト組み込むとか、
ライブラリいっぱい使うと時間がかかるとか、
なんでアホな話になるかね。

外部データとして扱えることが最大の利点だろうに。
移植のこととか考えてないんかねこの人たちは。

**名前は開発中のものです。** · 2014/11/04(火) 02:17:27.43

趣味だもの

**名前は開発中のものです。** · 2014/11/04(火) 02:33:18.69

ついでに、Luaじゃなくても別にかまわないがスクリプトでコルーチンを実装すると、
シーケンシャルな書き方で >>445 を書けて

GameStart();
ShowPlayer();
ShowEnemy();
BattleStart();

てことで、定型の処理は隠ぺいして保守しやすくスッキリ見通せる。
さらにスクリプトからスクリプトを生成して動的に実行するということも可能になるんで
非常にフレキシブル。

boostのコルーチンは使ったことない。

**名前は開発中のものです。** · 2014/11/04(火) 06:57:09.55

>>496
逆にC++だと移植大変だったりする？
OSのAPI以外でもコードに差って出たりするの

**名前は開発中のものです。** · 2014/11/04(火) 13:13:42.12

コルーチンとかコマンドパターンのベースクラス作れば同じことだし
コンパイル時間云々もDLLにすれば解決するよ

俺的には、Luaはユーザーに自作マップとかMODを作らせるものだと思ってる
洋ゲーだとMODツールキットにLuaがよく使われているしな

**名前は開発中のものです。** · 2014/11/04(火) 20:36:39.38

>>499
C++の中にハードコーディングしたイベントだらけだったら、
コードを把握するのも大変で移植するのに萎えないか？

その点実行部分とスクリプトで明確に分けれるのが大きい。
実行部分は作る人が仕様に沿ってつくるだけだし、どのプラットホームでも共通のスクリプトにできる。

ちなみにLuaはANSI C準拠なんで、C++がダメな環境でもOK。

**名前は開発中のものです。** · 2014/11/04(火) 21:00:59.89

それ移植どうこうとまた別問題じゃね
コード把握するの大変だけど移植するわけじゃないからおｋとはならないでしょ

**名前は開発中のものです。** · 2014/11/04(火) 21:03:11.80

結論先にありきのﾃﾞﾀﾗﾒばかり
移植以前に完成したことないだろ

**名前は開発中のものです。** · 2014/11/04(火) 21:09:55.86

普通にandroidとPCで出してるが、
とりあえず、>>503はどういう方法でゲーム作っているのか書いてから
どこら辺がデタラメか指摘してもらえるかな？

**名前は開発中のものです。** · 2014/11/04(火) 22:19:13.99

ハードコーディングと移植性に何の関係もないことくらい移植したら分かるだろ
見栄を張って嘘をついてもすぐにばれてしまうというこったｗ

**名前は開発中のものです。** · 2014/11/04(火) 22:42:12.25

ステートパターンだけど、
AIの行動パターンを制御する時みたいに、それぞれのステートが
共通の値（現在HPとか）を参照できる状態（ステート固有の値は持たない）で、
実行される処理だけ切り替えたい場合と、
シーンの切り替えみたいに、ステート固有の値を保管してシーンをスタックに詰んで戻ってきたい場合と、
実装方法は>>446で同じだけど、明確に意味が違うとして別クラス（インターフェース）にすべきだよね？

**名前は開発中のものです。** · 2014/11/04(火) 22:46:48.54

何言ってんだ？
外部にスクリプトで記述していたら、本体は機種依存や特殊な部分だけ移植すればいいだろうが。
ハードコーディングなんぞしてたら移植するたびに作り直しじゃないか。

**名前は開発中のものです。** · 2014/11/04(火) 22:48:00.93

>>506
するべきだと思う
じゃないとシーンの制御にAIのオブジェクト渡せるみたいなわけわからん事になる

**名前は開発中のものです。** · 2014/11/04(火) 23:07:53.61

イベントなんかをハードコーディングすると機種依存が発生するって言ってる？

**名前は開発中のものです。** · 2014/11/04(火) 23:17:05.61

極端なたとえ話をすると、エミュを作成する場合で
ゲーム固有のイベントをその汎用的なエミュに組み込むのか？組み込まないだろ？というのとあまり変わらない。

**名前は開発中のものです。** · 2014/11/04(火) 23:18:46.07

もうUnity使えばいいんじゃないかな

**名前は開発中のものです。** · 2014/11/04(火) 23:36:33.23

移植するつもりがあるなら移植を考えたコードにすりゃいいし
別に移植考えないなら考えてないコードでもいいんじゃない？
まぁどっちでも好きな様にすりゃいいんだけど

**名前は開発中のものです。** · 2014/11/04(火) 23:41:58.41

やっとわかったけど
多分大抵の人はスクリプトの用途をもっと限定的なものとして話してると思うわ

**名前は開発中のものです。** · 2014/11/04(火) 23:48:24.99

分かりにくくてスマンかった。ついでに移植で話がそれたのもスマンかった。
要はstateパターンやswitch振り分けのほかにDSLという選択肢を示したかっただけ。

**名前は開発中のものです。** · 2014/11/04(火) 23:50:26.53

もうエンジン部分以外はほとんどスクリプトでいいと思うけどね
処理速度が必要な部分が判明したときだけコードをC++に移すかんじで
FFCCはソース見当たらなかったがほとんどがスクリプトだったと見た記憶がある

http://www.inside-games.jp/article/2009/09/07/37504.html
http://game.watch.impress.co.jp/docs/20080224/ffcc.htm

**名前は開発中のものです。** · 2014/11/04(火) 23:52:06.45

>>507
スクリプトを使うかどうかと何の関係もないのだがｗ
ボロがでるばかりｗｗｗ

**名前は開発中のものです。** · 2014/11/05(水) 00:01:59.05

>>515
まさにそう。使ってるライブラリが開発停止になっても、エンジン部のすげ替えもできるし。

>>516
キミは分からないならもういいよ、独自の路線を走ってくれｗ
たぶん一人だけで開発してるだろうから、いまのままでも特段不便はないだろ。

**名前は開発中のものです。** · 2014/11/05(水) 00:12:09.01

まず、OSやOpenGLのAPIをアプリロジック内にハードコーディングしちゃうアホとか君だけだからね
それと組み込みスクリプト言語を使用することに何の関連性も無いのよ

**名前は開発中のものです。** · 2014/11/05(水) 00:21:14.06

薄いラッパー書いて使ってるが何か？ｗ
で、俺の主張は>>514だが、キミの主張はなんなの？過去発言から意図が見えないのだが？
単に俺に突っかかって来るだけなら、相手しても無駄なので遠慮したいんだが。

**名前は開発中のものです。** · 2014/11/05(水) 00:27:01.07

嘘デタラメを書き散らすウザイやつを笑ってるだけだよ
あまり背伸びをするなよｗ

**名前は開発中のものです。** · 2014/11/05(水) 00:28:29.32

ああ、そうｗ

**名前は開発中のものです。** · 2014/11/05(水) 00:36:27.94

かくしてスクリプト言語を使わないと移植が困難になるとかいう根拠なきトンデモ説が論破され
しったか君が大恥をかいたのであった♪

**名前は開発中のものです。** · 2014/11/05(水) 00:45:38.59

ゲーム自体をスクリプトでつくれば移植するときエンジンを交換するだけで済むって話でしょ
前提が共有できてないのに知ったか吹いてると大恥かくよ

**名前は開発中のものです。** · 2014/11/05(水) 00:50:14.08

ってか、スクリプト使ってる人って多いのかな？
個人で作る小規模ゲームでもよく使われるの？
オールC++の人も多いのかな？

**名前は開発中のものです。** · 2014/11/05(水) 00:55:37.53

交換だけったって結構C++で書き換えるコードもアリそうだけどな

移植先がC++ならOSのAPI叩く部分とエンジン駆動部分を綺麗に分離しとけば、
移植性に関しては大して変わらないようにも思うし、
スクリプトの最大のメリットが移植性とか言われるとやっぱすごい違和感在るわ

つうかゲーム自体をスクリプトで書くならもうすでにこのスレで話す内容じゃないな

**名前は開発中のものです。** · 2014/11/05(水) 00:56:41.89

マルチプラットフォームのエンジンなりラッパーを挟めば何も交換する必要もない
遂にその程度のことも分からなかったID:23olDi5Xが大恥かいたということだね

**名前は開発中のものです。** · 2014/11/05(水) 01:16:22.19

winのしか作る気ないしな
c++だけで何の問題もない

**名前は開発中のものです。** · 2014/11/05(水) 01:19:11.85

自分もC++/Win/DirectXオンリー派。
移植とか気にせんでえーし楽だ。

**名前は開発中のものです。** · 2014/11/05(水) 01:33:14.61

スクリプトは覚えるのめんどくさいかもしれんけど便利だよ
データの分離は常識だけど、それをさらに進めて制御も分離できる
データとそれを使うコードは密接なことも多いから
まるごと分離できると何も考えなくて済むし

**名前は開発中のものです。** · 2014/11/05(水) 02:09:12.31

>>525
いや、>>496 で言ってるように最大の利点はデータとして分離できること。
移植が注目されてるが、質問から思わず伸びたに過ぎない。利点の一つではあるが。
ちなみに>>422は俺ではないが、ほぼ同じ経緯をたどっているね。

特に複数人で開発するときスクリプトはかなり便利。
割と簡単に使えるようにしてから、デザイナーが演出とかいろいろ直接いじったりできる。
※あいつら、結構シビアなんでいちいち要求に応じて、こっちで作業してたらめんどくっさい。

また、前は書き換え専用の実行ファイル持ってたが、
データとしてゲーム部分を持っているのでリリース後、ゲーム中にアップデートすることもできる。
某プロテクトの関係で実行ファイルを書き換えられないので、これ地味に結構良い。

**名前は開発中のものです。** · 2014/11/05(水) 02:22:26.32

>>529
ほんとこれだね

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

なるほど。
覚えとこ。

**名前は開発中のものです。** · 2014/11/05(水) 03:13:21.00

スクリプトってよくわからない。素人で申し訳ないが。

例えばキャラクターの行動を外部データ（テキスト形式）で設定するとして、俺がどうやろうかと考えると
テキストを読み込む→書かれてた文字を判定→それに従ってキャラを設定する
という単なる外部データ読み込み処理になるわけだけど、
これだと特に意識しない限り独自形式でやることになるから、スクリプト言語とか関係なくなる。

んじゃよく聞くスクリプト言語ってのはなんなんだと考えると
誰かが考えたスクリプト言語にしたがって自分で実行プログラムを組んでいる？
しか思いつかないんだが、これだとあまりにも非効率で、一般に広まるとは考えにくい。

んじゃライブラリみたいな形で配布されてるの？　とも思うんだが、それを自分のプログラムに組み込むのって
最初に挙げた、自分の独自形式でテキスト読み込むほうが楽でしかも早くね？　と思ってしまう。　

**名前は開発中のものです。** · 2014/11/05(水) 04:02:31.79

テキスト読んで設定するだけでも立派なスクリプト。
独自だろうが何だろうが、スクリプトを見て処理の流れが一発でわかるとベスト。
ノベルゲーのテキスト処理のスクリプトは想像しやすいんじゃないかな？
これはいくらなんでもハードコーディングはしないでしょ。

ただ、自分で四則演算や変数・関数を実装しようとすると、
テキストの構文解析、意味解析、スタックマシン等を勉強して
yaccやbisonでコンパイラを作る大変な羽目になる。

んで、そんなことせずとも簡単にそういう機能を組み込めるように
LuaやSquirrelがある。それにこの二つはメジャーで、かなり広まってる。

**名前は開発中のものです。** · 2014/11/05(水) 04:45:23.73

BulletMLとか、こういう説明には向いてそうな感じがする

**名前は開発中のものです。** · 2014/11/05(水) 07:24:36.56

テキスト形式のデータ構造とスクリプト言語を同一視するのは、なんだかな
xmlとかをデータ構造と言われると納得できるがスクリプト言語と言われるとなんかモニョる
いや、スクリプト言語をデータ構造として使える事は理解しているし、
データ構造をスクリプト言語の代わりとしては使えない事も理解しているが……

**名前は開発中のものです。** · 2014/11/05(水) 08:24:52.84

ノベルゲームの場合はプログラミング言語としてのスクリプトって言うかまんま台本だな

**名前は開発中のものです。** · 2014/11/05(水) 08:58:45.06

ノベルゲーごときにこんな議論してたのか
通りでスレの流れが理解できんわけだ…

**名前は開発中のものです。** · 2014/11/05(水) 19:54:47.73

>>533
キャラクターの行動を記述できるような表現力のある
実質的にスクリプト言語と呼んで良いようなものを簡単に書けるなら
他の人が作ったものを学習して使う方が面倒に思うのでは
他の人が作ったスクリプト言語を使うにしてもブラックボックスで使うのと
中身を検査して使うのとでは手間が大幅に違う
まだお互いに無意識な認識の違いがかなりあるのではないか

**名前は開発中のものです。** · 2014/11/06(木) 01:14:24.74

外部データの代わりとしてのスクリプト（初期化の時に呼び出すとか）はわかるんだけど
処理としてのスクリプトってのはどういう風に使うかわかんねぇや

例えばDXLibとLuaを使うとする。
DXLibは基本的にシングルスレッドで、ゲームループ中にupdateとdrawを交互に呼び出すっていうのが主流だけど、
そのupdate中にLuaスクリプトを呼ぶとすると、その処理中、ループはそこで止まってることになる。

AIのルーチンとか、ウェイト無しでひたすら処理すればいいやつはそれで良いけど。
コルーチンを駆使するような挙動（※）を記述する場合って、意図したように動かすの難しいよね？
（※四角形を右に３秒かけて30ドット移動させた後に、上に２秒かけて50ドット動かす、など）

コルーチンを２段重ねにして、
obj.move(30, 0, 3000) //xに30ドット、1000ミリ秒
obj.move(0, -50, 2000)

//moveの実装
void move(int x, int y, int time) {
　int frame = time * FPS / 1000;
　float dx = (float)x / frame
　float dy //略
　for(i = 0; i < frame; ++i) {
　　time / FPS
　　this.x += dx;
　　this.y //略
　　yield();
　}
}

こんな感じ？（これじゃズレるけど）

**名前は開発中のものです。** · 2014/11/06(木) 02:25:22.77

最後合わせればそれでもいいんだけど、時間で考えたらいい。
float delta = （now_time - begin_time） / (float)time で 0～1まで変化するので、
x(y) * deltaでその時点での移動量が出るから初期位置に足してやる。
終了条件は1以上になったときで、強制的に初期位置にx(y)を足して処理を抜ける。

**名前は開発中のものです。** · 2014/11/06(木) 03:09:54.65

LuaとC++のデータ橋渡しとか、C++書く側が結構面倒くさそうだな

**名前は開発中のものです。** · 2014/11/06(木) 14:42:03.47

おい、姿勢制御にクォータニオンを使う方法が特許取られてたぞ

特開２０１１－２２０８２５

でググって一番最初のリンク
今更こんなんで特許申請するとか頭おかしいし、なぜ取れるんだろうか…

**名前は開発中のものです。** · 2014/11/06(木) 15:30:14.91

周知の技術って特許にならないんじゃなかったっけ。
ホントにそうなら取り消されるんじゃない？

**名前は開発中のものです。** · 2014/11/06(木) 15:41:51.54

訴えれば取り消せる
訴えなければ取り消されない
ちなみに低額訴訟なら簡単に訴えれる

**名前は開発中のものです。** · 2014/11/06(木) 15:46:35.49

間違えた。低額訴訟じゃなくて少額訴訟だった。
ちなみに3Dゲームに興味の無い俺は訴えないけどな
まあ訴えるなら頑張れ

**名前は開発中のものです。** · 2014/11/06(木) 15:53:35.47

申請者はトヨタ自動車になってて、最初は工業用ロボット制御の事で始まってるが
最終的には一般的なプログラム上での話しになってる
これは酷過ぎるな…

何の価値もないこの申請がトヨタの誰かの業績になってると思うと腹立つな

**名前は開発中のものです。** · 2014/11/06(木) 15:56:19.75

特定の特許申請に対して異議申し立てとか再審請求とか出来るんだろうか？

**名前は開発中のものです。** · 2014/11/06(木) 16:08:27.82

実際は、相手から訴えられない限り特許無効申請なんて誰もしないだろうね

そしてこういう下らない特許は山ほどあって
ゲーム特許訴訟
でググると結構色々あるな

**名前は開発中のものです。** · 2014/11/06(木) 16:13:48.30

訴訟起こされるほど拡散力の強いゲームを作ってみたいもんだね

**名前は開発中のものです。** · 2014/11/06(木) 18:44:11.46

よくわからんがゲ製には関係ないじゃろ

**名前は開発中のものです。** · 2014/11/06(木) 19:53:55.97

特許で思い出したけどコナミだかどっかの
ロード中にミニゲームが遊べる
って特許が12月で切れるんやな

**名前は開発中のものです。** · 2014/11/06(木) 20:31:37.28

実際に訴訟を起こされたら>>550みたいな考えは吹き飛ぶだろう
それも、どこから出てきたのか見当もつかないサブマリン特許みたいな物ならなおさら

**名前は開発中のものです。** · 2014/11/06(木) 21:01:35.08

>>552
ミニゲームだったらナムコだろ
リッジ7のロード中にゼビウスが遊べた時はびびったw

**名前は開発中のものです。** · 2014/11/06(木) 21:11:28.90

なぁ、特許って本当に社会の発展に貢献してるんだろうか･･･？
>>543みたいなゴミ特許が効力あるとか、唖然とするわ･･･。

**名前は開発中のものです。** · 2014/11/06(木) 21:19:10.59

特許を審査するメンバーってちゃんと仕事してるのか考えさせるよな。

審査過程をチェックする機構もあるのか怪しい。

**名前は開発中のものです。** · 2014/11/06(木) 21:25:50.58

永久機関そのままは駄目だけどちょっと表現変えるだけで通るみたいだしな

**名前は開発中のものです。** · 2014/11/06(木) 21:40:44.92

特許の審査ってなにやってるんだろうと考えると、
まず考えられるのは今までに同じ特許がなかった事を調べる、くらいだろう。

次に既知の技術として存在してないかを調べるんだろうけど、
これいちいち調べてられないよな。漏れがでるのはしょうがない。

ネットが発展した現代では、調べるのもかなり容易になってきたのではないかと思うが、
審査官が来る日も来る日もググってると考えるとなにか悲しいものがあるな……。

**名前は開発中のものです。** · 2014/11/06(木) 21:53:29.21

その特許を調べるためのシステムをつくるような話があった気がしたけど頓挫したんだっけ

**名前は開発中のものです。** · 2014/11/06(木) 22:55:27.98

この特許はフィードバック制御が必要だから、
新規性の判断はそこでされたんじゃないの？

**名前は開発中のものです。** · 2014/11/06(木) 23:20:16.77

よし、車輪でも申請してみるか

**名前は開発中のものです。** · 2014/11/06(木) 23:37:08.84

>>541
あーいや、そういう話じゃなくて、
DXLibだとメインループ回ってるから、いくらLuaでコルーチンがあっても
１ループ間の時間に合わせて処理返さないといけないよなって話

**名前は開発中のものです。** · 2014/11/07(金) 00:36:18.17

c++側とlua側ともにもう少し詳しく書いてみ

**名前は開発中のものです。** · 2014/11/07(金) 00:41:45.93

わからんって言ってるのに書いてみとはアスペしかいないのかよ

**名前は開発中のものです。** · 2014/11/07(金) 01:43:20.36

プログラマはアスペ気味の糞が多いからねｗ
そいつらを上手く奴隷として扱えるようになるのが社会の勝ち組。

**名前は開発中のものです。** · 2014/11/07(金) 01:53:01.03

ていうかマルチスレッドで描画てどうやんの？
座標はupdateスレッドでロックしてるし描画するにしてもdrawスレッドでロックしないといけないだろ
メモリを2倍使ってダブルバッファリングで交互にリソースを入れ替えてもいいけど1フレーム遅れるし
要素ごとにロックとアンロックしてたらそっちのほうが処理重いでしょ
モーションブラーとかドロップシャドウみたいな、書き足すようなシェーダとかなら分かるんだけど、ゲームの要素そのものを描画するのにマルチスレッド？ってすごい疑問なんだけど
どんな風にやってるの？

**名前は開発中のものです。** · 2014/11/07(金) 02:53:09.53

俺、マルチスレッドってさっぱりわからんけど
マルチスレッドで描画するのに「１フレーム遅れる」って関係あんの？

**名前は開発中のものです。** · 2014/11/07(金) 03:13:07.36

片方はとにかく更新する
片方はとにかく描画する
ロックアンロックで同期させるならマルチスレッドをやめる

**名前は開発中のものです。** · 2014/11/07(金) 06:56:56.78

マルチスレッドを理解してない奴が多いな、まあ自分もあんまり理解はしてないが
というか、マルチスレッドだけでも本がいっぱい出てるからそれを参考にしたらいいかと

**名前は開発中のものです。** · 2014/11/07(金) 07:32:03.69

マルチスレッドの場合、普通は描画と更新を別々にするわけじゃない
それぞれのスレッドに別々の役割を与えて異なる処理を分担させる事になる
あと、マシンに対する負荷を減らすには同期処理しまくらないと意味がないし
ロックアンロックが重くなると言ってる奴はマルチスレッドを根本から誤解してる
というかとにかく本を読め

**名前は開発中のものです。** · 2014/11/07(金) 07:53:25.81

とにかく1フレームの中に時間は8msぐらいはあるんだ
その中ですべての作業を終わらせる事を考えろ
重い処理は役割分担して複数のスレッドで終わらせばいいし、
軽い処理はわざわざ役割分担する必然性は無いからな

**名前は開発中のものです。** · 2014/11/07(金) 08:07:38.45

120fpsがデフォなのか

**名前は開発中のものです。** · 2014/11/07(金) 08:58:33.47

じゃあ描画要素ごとにロックアンロックして、
もし描画スレッドで更新スレッドがロックしてる描画要素を描画しようとしたらアンロックされるまで待つのか？

**名前は開発中のものです。** · 2014/11/07(金) 09:08:00.46

描画スレッド分けるのは描画中にメインループ止まるの防ぐ為だと思ってたけど
そんな事しなくても並列処理してくれるもんなの？

**名前は開発中のものです。** · 2014/11/07(金) 09:22:31.34

>>570

javaとかだと排他ロックするのすごい重い気がするんだけど
C++だとそんなことないの？

**名前は開発中のものです。** · 2014/11/07(金) 11:15:34.21

ロックすると重くなるんじゃなくてロックの割り当てというかスレッドの割り当てを間違えてるから重くなる
ロックしている間に別のスレッドをフルに動かすのがデフォ

**名前は開発中のものです。** · 2014/11/07(金) 11:42:28.34

描画をマルチスレッドにするには自前の描画コマンド(のようなもの)を作らないと駄目だね
で、コマンドの作成を出来る限りマルチスレッドで行なう
最後にメインスレッドが自前の描画コマンドを解析しつつ各種API(DirectXやOpenGL)を呼び出していく

**名前は開発中のものです。** · 2014/11/07(金) 11:53:44.31

そこでluabindですよ

**名前は開発中のものです。** · 2014/11/07(金) 12:23:40.03

そういや、描画範囲が違う場合は別々のスレッドで別個に書き込み出来るけれども、
描画範囲が重なる場合はこの手段が使えないね

あとスレッドって、何度も起動させて使うよりも、
一度起動させたらロックさせながら使い回す方が処理が早いね

**名前は開発中のものです。** · 2014/11/07(金) 15:24:47.03

ごめん、いまいち分かってないんだけど
今の話ってどのプラットフォームを想定して進行してるの？
DirectX？ OpenGL？ソフトウェア描画？それとも特に規定しない全般？

**名前は開発中のものです。** · 2014/11/07(金) 23:07:57.05

特にしてないはずだけど、DirectXはユーザが多いだけに暗黙な前提にしてる人が多そうなイメージ

**名前は開発中のものです。** · 2014/11/08(土) 10:52:03.60

最近はマルチコアなCPUも珍しくないからなぁ
ウチのタブレットは4コアだ
PCはシングルコアだが
PCはわりと長持ちだらなぁ

**名前は開発中のものです。** · 2014/11/08(土) 11:16:44.54

よく考えたら背景だろうがエフェクトだろうがキャラクターだろうが
カメラの射影行列使いまわすんだからカメラのインスタンスロックしないと危ないよね
で、カメラのアップデートは更新処理するスレッドで回すんだから結局更新スレッドと描画スレッドで占有権を撮り合う形になるから
アンロック待ちが当たり前なのか

**名前は開発中のものです。** · 2014/11/08(土) 11:30:01.41

プログラム内であまり時間を使っていない部分までマルチスレッドにしてもパフォーマンスが落ちるだけ

**名前は開発中のものです。** · 2014/11/08(土) 12:09:00.67

DirectX11のDeffered Contextとか使うとうまくマルチコア化できるんかな
気になってはいるんだけど試せてないんだよな