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/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

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

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

描画を別スレッドでやる意味あるのか？
ゲームの処理を終わらせた後じゃないと描画する意味が無いから
メインループ {
1F経過まで待つ
シーンマネージャー処理（ゲーム処理）
シーンマネージャー処理（描画処理）
}

もちろんゲームの処理は中でできるとこだけマルチスレッドにしてもいいけど
こんな感じじゃダメなの？

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

＞描画を別スレッド
自分の場合は描画もゲームスレッドでやってるからそれは何とも言えない。
ただ単純に、
for(int i = 0;i<30;i++){1F経過まで待つ;ゲーム処理;描画処理;}
ってやれると楽そうだな、という発想でゲームスレッドでやってるから。

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

こんな感じ。
//初めのシーン
for(int i = 0;i<30;i++){1F経過まで待つ;ゲーム処理;描画処理;}
//ゲームシーン(breakで抜けるまで続く)
for(;;){1F経過まで待つ;ゲーム処理;描画処理;}
//終了シーン
for(int i = 0;i<30;i++){1F経過まで待つ;ゲーム処理;描画処理;}

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

>>686
sugeee

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

>>686
やっぱり言葉よりコードだな、ようやく言いたいことが分かった。
確かに分かりやすいし書きやすい。
もう少し粒度を小さくしないと、後々大変そうだけどね…

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

どの当たりが楽になったの？

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

簡易的なコルーチンのように使えるはず

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

じゃあコルーチン使えばいいじゃんｗ

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

>>691
？
好きにつかえば？

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

だね

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

データの複製を２つ用意して、計３つ（A、B、C）のデータを
２つのスレッドで構造体のポインタをスワップする方式とか構想したことあるなぁ

Aを描画スレッドが使って、Cをルーチンスレッドが更新、
AとCのスレッド同期待ちを防ぐためにBがあるんだけどメモリ消費３倍の割りに
得るものがほとんどないんだよねｗ

A　←→　B　←→　C

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

描画コマンドをリストに貯めてそいつをダブルバッファとしておけばいいんじゃないの?
DirectX11のマルチスレッド対応も実際には描画してないし

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

垂直同期って具体的にどうやるの？
データから頂点の座標取得したりする描画スレッドとそれ以外のメッセージ処理や更新判定処理スレッドの
二つがあるとして

メインループの中で

更新
判定
描画

ってやってるんだけどちょちょいのちょいで出来るようにならない？
一応オブジェクト指向に則って疎結合を意識してるつもりな設計

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

あ、ごめん、5行目からは現状の話ね

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

OpenGLやDirectX使わないと垂直同期ってとれないんじゃないかな？

**名前は開発中のものです。** · 2013/11/11(月) 00:58:53.66

ちゃんとした垂直同期はDXGIじゃなかったか？
なんちゃって垂直同期は16ms待てばいい

**名前は開発中のものです。** · 2013/11/11(月) 01:43:24.19

DXGIってDirectX10以降か。
それ以前と以降では仕組みが違うんかな。

**名前は開発中のものです。** · 2013/11/11(月) 12:48:03.31

普通にD3D9以前でもできたっぺ
基本フルスクリーンモードでなきゃなんちゃってだけど

**名前は開発中のものです。** · 2013/11/11(月) 16:02:02.14

DirectX9 シェーダプログラミングブックを手にいれたんだけど、ネット見てるとアプリケーションウィザードってのが使えないらしい

これのかわりになるものってありますか？
ちなみにPCはWindows7でDirectX11です。

**名前は開発中のものです。** · 2013/11/11(月) 16:51:39.02

Windows8.1でDirectXが11.2に進化
CPUやメモリへの負荷がさらに軽減され、
超高解像度の大画面などの表示もこれまで以上に快適になりました

**名前は開発中のものです。** · 2013/11/11(月) 16:52:56.35

ほんとかよ(´・ω・`)

**名前は開発中のものです。** · 2013/11/11(月) 18:51:40.86

Windowsが8にしんかした

**名前は開発中のものです。** · 2013/11/11(月) 20:46:10.17

>>702
もしかして VisualStudioのAppWizardの事言ってる？

**名前は開発中のものです。** · 2013/11/11(月) 21:05:44.05

Directx9の時だったかあったかも
最後の方のDirectX9のサンプルを持ってればその中にEmptyProjectってのが代わりにあった
これをそのまま毎回コピペして読み込めばたぶん一緒
最近のVisualStudioなら最初にテンプレートのエクスポートすればコピペしなくて済みそうだ

**名前は開発中のものです。** · 2013/11/11(月) 21:29:01.28

>>707
確かにEmptyProjectってのはありました

テンプレートのエクスポートってのをちょっと詳しく教えてください

**名前は開発中のものです。** · 2013/11/11(月) 21:34:01.50

そもそも必要性がないから無くなったのに、それで何がしたいんだ？

**名前は開発中のものです。** · 2013/11/11(月) 21:36:39.52

VisualStudioのAppWizardの事なら無償のExpress版と有償版で扱い違うから、
テンプレート書き換えの際に注意な。
あと基本的に自己責任

**名前は開発中のものです。** · 2013/11/11(月) 21:37:03.59

>>709
DirectX9 シェーダープログラミングブックではその機能を使って進めてるから、ない場合はどうすればいいのかなと疑問に思っただけ

**名前は開発中のものです。** · 2013/11/11(月) 21:38:00.99

>>709
大体シェーダプログラミングってお題でなんでAppWizard必要なのかってのは
俺もずっと引っ掛かってた

**名前は開発中のものです。** · 2013/11/11(月) 21:40:36.26

>>711
そのお題で言うなら、要点はhlsl書く部分なので、
いつも通りのDirectXコード書いた上で、追加するイメージだよ

**名前は開発中のものです。** · 2013/11/11(月) 22:26:29.70

>>713
なるほどわかりました

丁寧な回答ありがとうございました!

**名前は開発中のものです。** · 2013/11/11(月) 22:32:50.04

DXlibずっと使ってたからわかんないんだけど
3dゲームでモデルファイル読み込むときって自分でバイナリ展開して頂点一個づつメモリ確保しておくの？
それともdorectxにそういう型があるの？

**名前は開発中のものです。** · 2013/11/11(月) 22:55:28.71

>>708
EmptyProjectでもなんでもいいんだけど読み込んでビルドして問題ないようなら
メニューから→ファイル→テンプレートのエクスポートしておくと
新規作成で同じプロジェクトが量産できる

**名前は開発中のものです。** · 2013/11/11(月) 23:00:12.51

>>716
そうなんですか？
めちゃくちゃ便利ですねww
今度使ってみます

**名前は開発中のものです。** · 2013/11/11(月) 23:01:07.66

頂点リストをメッシュに持たせて、フレームで束ねるだけ。
シェーダでは使いやすい構造を自分で定義して使う。

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

>>715
一応D3DXMESH型って言ういわゆる xフォーマットって呼ばれる形式はあるよ。
あるが、都合によっては遠回りだった色々あるので、VertexBufferやIndexBufferに詰めて、カスタムFVFで頂点情報指定して、
自分でDrawしたりする、
でその際、hlslのVertexShaderでは頂点の表示用移動計算したり、PixelShaderではラスタライズする際の色の計算したりする。
そんな感じ。

俺はDirectXとOpenGLの両方でキャラクタコントロール処理書いてるけど、どっちも基本的な考え方と処理方法の方針は同じ。

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

ちなみに必須じゃないけど、一度上に書いたような処理について深く掘り下げて理解しておくと、
例えばAndroidアプリ作るような場合にもほぼそのまま同じ考え方を持っていけるので楽しい。

**名前は開発中のものです。** · 2013/11/20(水) 16:41:23.19

ちょい質問なんだけど、RPGとかのマップチップって例えば100×100のマップで既に
4byte(int) * 100 * 100 = 40Kbyte をメモリ上に展開しちゃうことになると思うんだけど、
そんなにメモリ使っちゃってOKなんかな？
charで節約したりした方がいいのん？

**名前は開発中のものです。** · 2013/11/20(水) 17:02:58.00

40kを気にするほどかつかつな環境で作ってるなら自分で工夫しないと。

それはそれとして、普通8bitで収まる情報量なら聞くまでもなくわざわざ4byteで持たないと思うけど。

**名前は開発中のものです。** · 2013/11/20(水) 18:10:09.38

どうしても足りないときはVRAMの画面外使ったりしてたなｗ
将来的にも、640KBもあれば充分だｗ

**名前は開発中のものです。** · 2013/11/20(水) 18:21:35.83

　　(*ﾟωﾟ )　不安ならメモリ増設すればいいじゃないか
　　つi'"':
　　　`､:_i'

**名前は開発中のものです。** · 2013/11/20(水) 18:28:50.19

今時数十kbyteのメモリーの心配って、どんな環境よ？

**名前は開発中のものです。** · 2013/11/20(水) 18:37:24.78

>>724
お前天才だな

**名前は開発中のものです。** · 2013/11/21(木) 01:41:01.40

よし、16KB拡張RAM挿すか！

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

>>722
ありがとう。レイヤに分けるとけっこう嵩みそうだったから気になったの

**名前は開発中のものです。** · 2013/11/22(金) 11:42:42.36

マップエディタによっては8bitじゃ収まらないものもあるよ

**名前は開発中のものです。** · 2013/11/22(金) 11:45:55.04

クラス使ってると構造体を使う必要性が感じられないんだがいいんだろうか

**名前は開発中のものです。** · 2013/11/22(金) 12:16:45.45

クラスだとmemcpyが使えないからなぁ……

**名前は開発中のものです。** · 2013/11/22(金) 12:18:32.72

c++でのclassとstructは実体がほぼ同じだし
classばっかり使ってても別に問題ないと思うよ

使い分け指針は人によって違ってくるんじゃないかな
俺は、PODでメンバ関数をほとんど持たないものはstructにして
それ以外はclassにしてる

**名前は開発中のものです。** · 2013/11/22(金) 12:19:54.66

thx
アイテムとかはクラスにするか

**名前は開発中のものです。** · 2013/11/22(金) 12:27:03.21

>>731
構造体だって、メンバに仮想関数がいる時点でアウト。
クラスと構造体の違いは、デフォルトの属性だけだ。

**名前は開発中のものです。** · 2013/11/22(金) 12:47:03.52

ファイルアクセスにはよく使う。

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

ファイルアクセスって構造体できるの？
配列でやってるが

セーブデータ類は一旦構造体にまとめてるな

**名前は開発中のものです。** · 2013/11/22(金) 13:14:01.85

それともファイル入出力時に書く魔法の呪文の一部のあれか

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

「グローバル変数は使わない方がいい」と言うので勉強しなおしてるんですが、ずっと頭を悩ませてます。
例えば、いままで下のようにプログラミングしてました。

int loopflg = 1 ;
main() {

}

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

あ、すみません途中送信しちゃいました。
int loopflg = 1;
main (){
while( loopflg) {
//色々処理
}
}

こうしてると、プログラムのどこでもloopflgをオフにすればプログラムを終了させたりする事ができてたのですが、
これをグローバル変数でなくするとしたら、いちいちポインタをloopflgを使うであろう全関数に渡さなくてはいけないって事になるのでしょうか？