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

**名前は開発中のものです。** · 2013/08/12(月) NY:AN:NY.AN

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

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

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

**名前は開発中のものです。** · 2013/10/25(金) 02:46:25.90

入力履歴はそのまま記録すればリプレイにも使えるしデバッグにも利用できる。

**名前は開発中のものです。** · 2013/10/25(金) 09:05:50.59

>>583
その監視側が履歴を必要とするはずだから、多分それは遠回りな実装。
具体的にコードパス説明してみ

**名前は開発中のものです。** · 2013/10/25(金) 11:25:43.16

テンプレートとautoってどう使い分けんの？

**名前は開発中のものです。** · 2013/10/25(金) 11:58:14.26

>>586
使い分けるも何もテンプレートとautoは全く別
std::vector< std::map<std::string, int> > map_vec;
こういうのがあったとしてイテレータを取るには
std::vector< std::map<std::string, int> >::iterator i = map_vec.begin();
と長ったらしく書かないといけないが、autoで型推論させると
auto i = map_vec.begin();
でいいわけ

**名前は開発中のものです。** · 2013/10/25(金) 12:06:29.04

>>586
勘違いしてる可能性があるから一応念のため言っておくけど
auto型っていう型がある訳ではないからね

**名前は開発中のものです。** · 2013/10/25(金) 12:51:45.87

吐きそう

**名前は開発中のものです。** · 2013/10/25(金) 12:54:36.09

エラーが？

**名前は開発中のものです。** · 2013/10/25(金) 13:00:27.54

コアかもしれん

**名前は開発中のものです。** · 2013/10/25(金) 21:11:21.10

別にイテレータじゃなく適当なクラスのバッファにならないの？型推論で

void hoge(auto a,auto b);
とかでもいいのかなーと

**名前は開発中のものです。** · 2013/10/25(金) 22:18:46.67

template<class T1, class T2>
void hoge(T1 a, T2 b);

**名前は開発中のものです。** · 2013/10/25(金) 23:24:22.57

>>592
それに近い使い方は戻り値のautoかな
しかし確かに>>593みたいな糖衣構文が来ても悪くないような気もするね
ただ、C++のテンプレートだと特殊化が命みたいなとこもあるからなぁ

**名前は開発中のものです。** · 2013/10/29(火) 21:52:21.38

テンプレートメソッドをオーバーロードしたら自動的に
特殊化扱いになるようにしてくれたら良いのに
思わぬとこで「オーバーロードが曖昧です」とか言われても焦る

**名前は開発中のものです。** · 2013/10/30(水) 08:34:18.07

テンプレートってヘッダに定義書かないとダメなの？
せっかく美しく宣言と定義わけて書いてるのに

**名前は開発中のものです。** · 2013/10/30(水) 08:50:47.21

ファイルを分けるなら、ヘッダ内で定義をincludeすればいいだけ。

**名前は開発中のものです。** · 2013/10/30(水) 09:45:57.87

そういえばそんな宣言無かったっけ？正式採用されなかった気もするが

**名前は開発中のものです。** · 2013/10/30(水) 15:47:31.26

他のコンパイル単位でテンプレートの定義あることに期待して
自分のコンパイル単位ではテンプレートの定義をインクルードしないっていう
キーワードは追加されたけど、ぶっちゃけどういう時に使えばいいのかわからん

**名前は開発中のものです。** · 2013/11/05(火) 22:56:36.90

まあいいさ、そのうち、私の解説サイトで
RPGの作り方を解説してみるさ

そしたら、それほど難しくないことが解かることでしょう

**名前は開発中のものです。** · 2013/11/05(火) 23:48:42.84

私のってポナちゃんの？

**名前は開発中のものです。** · 2013/11/06(水) 00:29:19.16

レスが飛んでると思ったら

**名前は開発中のものです。** · 2013/11/06(水) 01:18:53.76

DXライブラリ総合スレと思って誤爆しているんだろw

ゲーム製作云々より自画自賛の解説サイトの宣伝に夢中で
あれがやりたいだのこれをやってみせるだのと
手を動かさず口だけ妄想と自分語りしか出来ないで
複数のスレッドに目をつけては書き込みするタイミングを伺っている

**名前は開発中のものです。** · 2013/11/06(水) 01:29:00.96

複数のスレっつーか
こことあそこがメインフィールドだと思う

今日(もう昨日か)は文体だけで識別することに成功したから
ようやく俺もゲ製の一員になれたような、そんな気分になれたよ

**名前は開発中のものです。** · 2013/11/07(木) 21:31:07.69

なあ、今作ってるゲームの実行ファイルのサイズって何kバイトぐらい？
俺のは280kほど。ちなみに画像とか音声とかは別にしてある。

**名前は開発中のものです。** · 2013/11/07(木) 22:21:58.37

ランタイムを実行ファイルに組み込むか外に持つかで全然変わる。

**名前は開発中のものです。** · 2013/11/08(金) 08:52:56.12

RPGよりノベルゲームの方が作るのは簡単だよ！
だからまずはノベルゲームの作り方から入ったら？

**名前は開発中のものです。** · 2013/11/08(金) 08:57:49.11

文章書かなきゃならないとか……高難易度すぎるだろ……

**名前は開発中のものです。** · 2013/11/08(金) 10:13:29.89

じゃあアドベンチャーゲームとかｗ

つ～かプログラムの作成難易度はノベルゲーム→アドベンチャーゲーム→RPGなんだがな

**名前は開発中のものです。** · 2013/11/08(金) 11:21:11.70

そういえば、文章の難易度は、RPG→アドベンチャゲームー→ノベルゲームかな？

**名前は開発中のものです。** · 2013/11/08(金) 11:51:10.76

戦闘シーンだけ、あるいは探索シーンだけなら、
他ジャンルと比べてプログラム自体が難しいわけじゃないと思うんだよね。

**名前は開発中のものです。** · 2013/11/08(金) 12:23:58.88

シーンの変更もそれほど難しいとは思わないが？

**名前は開発中のものです。** · 2013/11/08(金) 13:40:12.68

それでふと思ったが、ゲーム製作って言うより完全にプログラミングそのものの領分になるけど、
シーンの管理処理とか、表面的に目立たない屋台骨の部分について最初から自分の中で定番化するような物考えて持ってると、
正直どうとでも応用効くよな。

で初心者の人とか、初心者が開いた入門講座みたいな物コピペしてただ覚えたような人だと
その部分が自分の中で定式化出来ないから「難しい、わからない、思い付かない」になるのかなと。

あくまで一般的な話だけど。

**名前は開発中のものです。** · 2013/11/08(金) 14:24:03.36

>>612
シーンの変更というよりは、ミニゲーム２つ3つ作るようなもんじゃん？
もちろん使い回すコードはあるにしてもさ。

**名前は開発中のものです。** · 2013/11/08(金) 15:08:13.78

それぞれのシーンが難しくないならば、ふたつ作るのもたいして変わらない
一桁の足し算を100回やるのは面倒ではあるけど難しくはならないだろう？

**名前は開発中のものです。** · 2013/11/08(金) 15:08:15.81

ソースに文章書き込むなら簡単だけどスクリプトとか文字列操作熟知してないと難しそう
えんいー

**名前は開発中のものです。** · 2013/11/08(金) 20:11:46.11

スクリプトの作成ってインジェクション対策がめんどくさそう
ある程度適当な文法でもエラー出力作ってなかったら通っちゃうだろうし
外部に置くってなると他人に触らせること前提ってイメージがある

**名前は開発中のものです。** · 2013/11/09(土) 02:42:05.48

他人の作った組み込みスクリプトを使うという方法もある
けれども基本的には、自作する事で得られる様々な知識や知恵の方が大事かと
まあ簡単なノベルゲームやアドベンチャーゲームの一つ二つ作るつもりで挑むべし
つーか、これらのゲームも基本的にはスクリプトを使ってると思った方が良いかと

**名前は開発中のものです。** · 2013/11/09(土) 10:47:13.41

そもそもシーンの変更を扱う方法はスクリプトに限らない。
マルチスレッドを使う方法もあれば、タスクシステムを使う
方法もある。フラグや分岐や関数ポインタでえっちらおっちら
やったっていいし。どの方法にも一長一短がある。どうせ内部で
どんな挙動をしているかは作ったプログラマにしか分からない
んだし、自分の好きなやり方でやるべし。

**名前は開発中のものです。** · 2013/11/09(土) 11:16:02.17

>>613
そういう人たちにはむしろ組み込みスクリプトを教えた方が良いのかもしれんな
組み込みスクリプトを使っている人達には迷惑かもしれんが

**名前は開発中のものです。** · 2013/11/09(土) 11:31:05.04

シーンの変更はオブジェクト指向で実現しようとすると難しいなぁ
主に共有したいデータのやり取りとか

あと、コンソールゲームと違ってループを意識して状態を保存できないといけない
Boostにコルーチンあるけど、自分のに組み込むほどの理解には至れないなー

描画を別スレッドにするのでも良いけど、マウスゲーのように画面と操作（MV）が密接に
関わっているような作りだと、フレムワーク自分で作るのは骨だろうね

**名前は開発中のものです。** · 2013/11/09(土) 11:53:07.42

自前主義からの脱却を

**名前は開発中のものです。** · 2013/11/09(土) 12:59:59.47

シーンごとに別のループを用意するんじゃダメなの？
俺の場合、メインスレッドを用意して、シーンごとに別のループを作ってるが。
この方法の問題点は同期処理関連をおろそかにするとフリーズする事かな？
Windows7以降だとそうでも無いんだが、昔のOSだとOSごとフリーズするので、
デバッグでは苦労した覚えがある。

**名前は開発中のものです。** · 2013/11/09(土) 14:51:11.85

>>621
ごめん、なんか引っ掛かった。

＞シーンの変更はオブジェクト指向で実現しようとすると難しいなぁ
＞主に共有したいデータのやり取りとか

それ、全体としての実装手法の話と、アプリケーション固有の(自分自身の)設計の話が切り別れて無い印象を受けた。
もしかして固定的な何か一つの実装をイメージしてないか？

複数スレッド使う事や全体としてOOの考え方で実装する事と、シーンの変更がしんどいか否かはレイヤの違う話かと。

**名前は開発中のものです。** · 2013/11/09(土) 18:30:15.80

ループは一つにしておけよ・・・

**名前は開発中のものです。** · 2013/11/09(土) 18:34:25.44

ソースが分かりにくくなるから却下

**名前は開発中のものです。** · 2013/11/09(土) 19:32:06.23

一つのメインループの中で、現在設定されてるシーンに対応したイベントと描画処理を呼び出すのではいかんのか

**名前は開発中のものです。** · 2013/11/09(土) 19:34:22.11

例えば、シーンが変わるごとに同じループでフラグ管理とかポインタ関数管理とかやってると、
一度に二重三重のシーン変更処理が入った場合にバグを発生させる可能性が高くなるからな。
シーンごとに別ループで管理しておけば、少なくともそういったバグが出る可能性は無い。

**名前は開発中のものです。** · 2013/11/09(土) 19:41:29.60

昔のOSでフリーズしてる時点でバグが有るんだろｗ

**名前は開発中のものです。** · 2013/11/09(土) 20:03:13.90

スレッドの同期関連のバグとシーン変更関連のバグを同列で扱う馬鹿よりはマシかと

**名前は開発中のものです。** · 2013/11/09(土) 20:22:26.69

昔のOSはちょっと間違えるだけでフリーズしたりブルースクリーンが出たりして大変だったよな

**名前は開発中のものです。** · 2013/11/09(土) 20:53:32.08

MS-DOS時代はフリーズしてもあんまし文句言われなかったのにな

**名前は開発中のものです。** · 2013/11/09(土) 21:08:02.88

DOS時代だって数百万円するのに使えないCADとか不満多かったけど
バックアップするにもドライブ遅いから時間かかるし
一太郎だって安定してた4.3を使い続けたりだとか

**名前は開発中のものです。** · 2013/11/09(土) 21:13:23.84

うーん、そんなに複雑になるものかな？
自分の場合、ゲームのメインループ自体の仕事はFPSの計測と負荷調整だけで、いつシーンが変更されたかなんて気にしなくていいような設計にしてたもんで……

**名前は開発中のものです。** · 2013/11/09(土) 21:27:56.92

でも昔はリセットボタンを手軽に押せたけど今は手軽に押せないじゃん
っていうか、最近リセットボタン使ってないなぁ･･････

**名前は開発中のものです。** · 2013/11/09(土) 22:00:01.21

>>634
RPGで？それは凄いな。バグの解析で頭こんがらがらない？

**名前は開発中のものです。** · 2013/11/09(土) 22:18:31.84

メインループ設けるだけでバグの解析が難しくなる設計ってどうやるんだ

**名前は開発中のものです。** · 2013/11/09(土) 22:34:39.14

岩押したり船やドラゴンに乗ったりNPCを特定動作させたりランダム動作させたり
あと何やったかな？そんな所ですが

**名前は開発中のものです。** · 2013/11/09(土) 22:39:32.94

>>636
俺の場合、最初と次に作ったゲームはシーン毎にループ処理やってたけど、
それ以降はメインループ一本にしたら、管理とか変更とかすげー楽になった。

**名前は開発中のものです。** · 2013/11/09(土) 22:51:18.18

設計の意味知らないんじゃん・・・

**名前は開発中のものです。** · 2013/11/09(土) 22:56:46.28

>>639
ID凄ぇ
なんか、自分とは逆だな。昔はメインループ一本だったのに、今はループを分けて作ってる。
バグを出さない方向に工夫した結果なんだがな。

**名前は開発中のものです。** · 2013/11/09(土) 23:17:49.74

>>640
DQ2とFFを足して割ったようなゲームを作る以上の事は特に考えずに、
その場の思いつきでRPG作ってるからなぁ・・・

**名前は開発中のものです。** · 2013/11/10(日) 00:26:02.25

久々にひどいワナビバカを見たわｗ
アマチュア時代は自分で思いついたことを素晴らしいことだと思わず、
すでに実績のあることを自分のものにすることに力を入れたほうがいいぞ。

**名前は開発中のものです。** · 2013/11/10(日) 00:56:13.82

>>638
メインループとゲームのロジックは、明確に分けるべき。構造化プログラミングすら出来てないんじゃないか？

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

横レスだけど
ヤバイ
何を言ってるのか理解できない
ボクはプログラミング力が低いらしい

メインループ内でシーンマネージャー呼ぶ
シーンマネージャーの中で各シーンの処理を呼ぶ
各シーンの処理の中でそのシーンでやりたいことの処理を呼ぶ

こんな感じじゃダメなの？

**名前は開発中のものです。** · 2013/11/10(日) 01:12:04.49

いいよそれで

**名前は開発中のものです。** · 2013/11/10(日) 04:24:39.77

>>645
普通に考えるとそういう設計になると思う。てか、ドシンプルに最初に書く屋台骨ってそうなると思う。
合ってる。そういう設計プロセスのイメージが出来ない人ってのが、つまり >>613 に書かれてるような、考えと整理の経験が足らない人って事になると思う。

**名前は開発中のものです。** · 2013/11/10(日) 11:41:35.08

メインループを分けるってことはメッセージ処理をあちこちから呼び出すってことが

**名前は開発中のものです。** · 2013/11/10(日) 12:17:49.63

それのどこがわるいんだ？龍神録の講座でもメインループは一つのみ、
複数あったら設計がおかしいとか書いてあるけど、
メッセージ処理とかするのに、わざわざ深いネストから抜けないといけないじゃん。

**名前は開発中のものです。** · 2013/11/10(日) 12:19:33.98

メッセージ処理とやらをシーンがやんの？

**名前は開発中のものです。** · 2013/11/10(日) 12:30:53.34

メッセージ処理をまとめた関数をシーンが自由に呼び出す

**名前は開発中のものです。** · 2013/11/10(日) 12:37:54.22

ゲームのメインループはメインスレッド上に用意し、
メッセージループはDirect3Dのオブジェクト管理をしているが？

**名前は開発中のものです。** · 2013/11/10(日) 12:41:34.36

なんかマルチスレッドとか使ったらすごい複雑になりそう

**名前は開発中のものです。** · 2013/11/10(日) 12:49:18.45

同期処理関連を理解してれば問題無い

**名前は開発中のものです。** · 2013/11/10(日) 13:08:34.27

メッセージループでPeekMessage使うとCPU使用率が100%にならない？
それが嫌だからマルチスレッド使ってる。

**名前は開発中のものです。** · 2013/11/10(日) 13:12:44.88

100％になるのはSleep入れてないからでは？

**名前は開発中のものです。** · 2013/11/10(日) 13:17:53.86

>>651
メッセージ処理とやらをシーンから呼び出す必要があんの？
メッセージ処理って何？

**名前は開発中のものです。** · 2013/11/10(日) 13:20:58.54

メッセージループにSleep入れるとOSの動作が不安定になってただろ？

**名前は開発中のものです。** · 2013/11/10(日) 13:22:25.04

>>657
普通にPeekMessageとかのウィンドウ一連の処理。

**名前は開発中のものです。** · 2013/11/10(日) 13:24:07.25

>>658
いや？不安定になるのは長く入れすぎじゃないか？
むしろSleep(0)として、ほかのスレッドに処理渡さないと逆に不安定になると思うが・・・・

**名前は開発中のものです。** · 2013/11/10(日) 13:27:24.32

>>658
普通ならない。
>>660も言ってるけど、OSと自分の書いてるアプリケーションの関係、つまりメッセージの循環(OSのメッセージポンプ、メッセージディスパッチ)の
立場とか意味わかって書いてたらならないと思う。

**名前は開発中のものです。** · 2013/11/10(日) 13:35:43.16

>>660
昔、PeekMessageにSleep(16)とかやってたなぁ、そういや。
今はGetMessageにタイマースレッドとメインスレッドを組み合わせているから関係ないが。

**名前は開発中のものです。** · 2013/11/10(日) 13:46:45.40

http://codepad.org/Vx38Y7XI

**名前は開発中のものです。** · 2013/11/10(日) 13:55:30.97

↑まずこの土台の中で、抜けてる考えが無い前提の上で、話してるんだよな？

＞今はGetMessageにタイマースレッドとメインスレッドを組み合わせているから

ちょっと引っかかったけど、GetMessageってただ単にOSのメッセージキューからメッセージ引っこ抜いて構造体に詰めてくれるだけ、かつ
取得するまで処理が返らない訳だから、書かれてる内容から察すると、要は別スレッドから OSのメッセージキューにお構いなしにブチ込んで
自分のやりたい処理はウィンドプロシージャへのディスパッチ経由で動かしてるって言う、なんか変に遠回しな方法になってるけど
そこら辺の動作はちゃんと見えてる上で、設計してるか？

**名前は開発中のものです。** · 2013/11/10(日) 14:04:21.67

そこら辺は俺もちょっと気になった。ループがタイマーに依存するから、
常にアイドルイベント発生させて、そっちでやったほうが良いような・・・

**名前は開発中のものです。** · 2013/11/10(日) 14:09:57.12

昔のコードを見るのは久しぶりだな。土台の部分は
while (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
ままだよ？WinProcは最近は全然いじってない。
主にいじるのはメインスレッドだけ。

**名前は開発中のものです。** · 2013/11/10(日) 14:10:22.48

いや、そういえばマルチスレッドか。
メインスレッドはどういう処理を司ってるの？

**名前は開発中のものです。** · 2013/11/10(日) 14:18:19.26

我はメインスレッド
世界を司るものなり

**名前は開発中のものです。** · 2013/11/10(日) 14:19:11.46

>>668
ﾜﾛﾀｗ

**名前は開発中のものです。** · 2013/11/10(日) 14:19:41.06

>>666
自分の設計による実装都合の範疇だから良い悪いを言う話じゃないが、そこに書かれてる動作って基本的に、

「OSと言うプログラム側が行っている、一番大きな、こちらからは見えないレイヤのループの中で、
OS管轄のメッセージキューにメッセージが放り込まれるまで　『待機する』　形式」　なので、

それで要件が間に合うならそれでいいし（例えばOSベンダ提供のAPIを単に利用したユーティリティとか）、そうでないなら違う。
そこの意味と切り分けをした上での選択であれば、普通の処理だよ。

そしてメインスレッドってのは、そのメッセージループを「OSと言うプログラムが、自分のアプリケーションコードを、エントリ関数から実行している最初のスレッド」の事なので

＞主にいじるのはメインスレッドだけ。
↑この言い様と書かれたコードの間に差異があるように見える。

**名前は開発中のものです。** · 2013/11/10(日) 14:28:22.95

メインスレッドでゲームの主な処理全般をやってて、WinProcがレストア対策とかを、
タイマースレッドはこんだけ。
DWORD _DrawTim(LPVOID pParam)
{
while(g_boolTimeLoop)
{
Sleep(DRAW_TIME_WAIT);
SetEvent(m_hMainEvent);
}
PostMessage(g_hWnd,WM_SYSCOMMAND,SC_CLOSE,NULL);
return 0;
}

**名前は開発中のものです。** · 2013/11/10(日) 14:29:39.91

あぁ、もしかして >>666 が言っている　「メインスレッド」　って、いわゆるメインスレッドじゃなくて、
「自分で別に起こした、ゲーム処理用のスレッドの事」　の事か。

で、OS側とのポンプを行うディスパッチは、「本当のメインスレッド側に任せている」　みたいな。
もしもそういう意図で言ってるならいいんじゃねと思うが。多分にエスパーだけど。
用語に齟齬がある感じか？

**名前は開発中のものです。** · 2013/11/10(日) 14:33:41.51

>>672
ああ、そういう事を聞きたかったのか。理解力が無くてすまん。
それで当たってる。

**名前は開発中のものです。** · 2013/11/10(日) 14:35:33.82

把握

**名前は開発中のものです。** · 2013/11/10(日) 14:35:58.59

>>671
＞メインスレッドでゲームの主な処理全般をやってて、WinProcがレストア対策とかを、

入れ違ったけど、>>672 で合ってたようだ。
そしてその様子だと、なんかOS側都合の処理と自分のアプリケーションコードと、切り分けないで行ったり来たり混ぜ込んでるみたいだけど
…　いやそれで問題無いなら別にいいが、エラく遠回りな実行パスになってるなぁとは思うけど。

あと "タイマー" スレッドって言うか、それもしかしてハートビート処理してるんじゃね的な印象受けるが。
いや、いいならいいんだけど。

**名前は開発中のものです。** · 2013/11/10(日) 14:44:09.28

一応念の為、今ここで話してる内容は、単に「その人の都合でそう実装してる」の範疇を今の所出ていないので、
一絡げに良い悪いでぶった切れる訳じゃないって事を一応書いておく。

**名前は開発中のものです。** · 2013/11/10(日) 14:50:50.53

えっと、ハートビート処理っていうのか、これ。
始めはマイクロ秒単位に直すべきかな？とは思ってたんだけど、
なんだか最近はどうでも良くなってね。
多分、苦情も出ないだろうと。

**名前は開発中のものです。** · 2013/11/10(日) 15:18:12.54

いや、本当にハートビートなのか単なるタイマーなのかは、その処理がどういう文脈やアイデンティティを持たされて単位化されたかによるので、
違う使われ方なら違うと思うけど、>>671 のコードだけ見ると、一定速で足並みそろえる為だけに別スレッド起こして
定期的に処理全体の速度決めてるみたいだから、それっぽく見えただけ。　ループ１回のテンポ管理って言うか。

**名前は開発中のものです。** · 2013/11/10(日) 15:40:15.07

>>675
レストア関連の処理を登録型にして、オブジェクトの生成時に自動登録してるから変に思うのかな？

**名前は開発中のものです。** · 2013/11/10(日) 15:46:33.19

>>679
？いや全然そういう事じゃなくて、書いてる通り。
あと、「変」と思ってる訳じゃなくて、これも書いてる通り、エラく遠回りな実行パスになってるなぁって話。

＞ OS側都合の処理と自分のアプリケーションコードと、切り分けないで行ったり来たり混ぜ込んでるみたいだけど

こういう事。OS側都合の処理と、自分側都合のアプリケーション設計のレイヤをキレイに整理して分けないで、あえて混ぜ込んでるのかなと思ったって事。
そう思った理由が、要は別スレッドに分けようがどうしようがいいんだけど、いちいちOS側のメッセージポンプ経由してやりとりしてるように見えたから。

**名前は開発中のものです。** · 2013/11/10(日) 16:03:46.14

あああと、こう言ったらいいか。

OSに対してメッセージを送信したり受信したりって動作は、メッセージキューに対してデータをストアしたり自分で取得したりって言葉に置き換えられて、
で、取得したメッセージデータをディスパッチするなりなんなりしてポンプとやりとりするその繰り返しを、つまりメッセージループと呼ぶ訳だけど、

その動作の正体って、要はこちらのアプリケーションコードがOSと協調して動く為に、
OS側の都合で用意された仕組みな訳で、いわば「ここで動く物ならば、書かねばならない事」な訳だけど、

それはそれ、これはこれって話で、逆にこちらのアプリケーションコード側には当然こちらの処理都合や設計がある訳で、
その両者、つまりOS側都合のコードと、アプリケーションの設計に基づく自分都合のコードと、それらの仲立ちをする部分ってのを
明確に分けないで、常にOS側に寄ってるような書き様に見えた、って事。

でも細かい事を言えば、例えば描画処理やキーやマウスなんかの入力状態の取得は
結局OS側API経由で行う訳だから、その意味では完全に切り分かりはしないんだけど、メッセージポンプそのものを直接操作する部分まで
自分のレイヤに置いてるから、実行パスがなんか長く無いか？　と思うって事。　真面目に書くと長い。

**名前は開発中のものです。** · 2013/11/10(日) 16:49:07.90

この手の話で描画を別スレッドでやるとかの話がよく出るんだけど
具体的にどんなふんにやってるのか、それがよくわからんのよね

メインスレッドはメッセージポンプだけ担当させて
メッセージは別の状態更新スレッドに送って、さらに描画を別スレッドでやる？
1/60秒で処理をやるにしても、正確に処理をまわせるのか？って悩んでるんだけど。

**名前は開発中のものです。** · 2013/11/10(日) 17:00:52.03

ゲームスレッドの中に色々とループ処理を入れて
それぞれのシーンを表現しているけれども、
それに違和感を感じたって事かな？