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

マシン性能におんぶにだっこで、できる改善をやらないのは、プログラマの行動じゃないと思う。

じゃあ全部ハードウェアで実装しろ

改善というのは、できうる限りマシン性能におんぶにだっこさせることなんだが、
それがプログラマの行動じゃ無いというのは、いったいどれだけ愚か者なんだろう？

ハードに頼れない馬鹿なプログラマはクビだ

こいつらってハッカソンとか勉強会に参加してない低能なんだろ？

できる改善というやつも
結局コーディングの手間と実行速度やリソース消費とのバランスだよな。
一概に言えるもんじゃない。

あーよくいるよね、知識だけ溜めこんで実装できない奴

わかる
俺も中二の頃はハッカソンとか勉強会に参加するだけでカッコいいと思ってたよ

C++を知らないゲームプログラマ達
http://d.hatena.ne.jp/alwei/20111008/1318090538

だれこいつ

例えば「この処理はハードがやってくれるからそっちに投げよう」というのはアリだろう。
けど「最近のPC処理能力ならできるだろうからやる必要はない」は相手の状況次第だろう。
相手が対象としてるPCが「最近の」だとは限らないし、作るゲームの規模も不明。

少なくともプログラム技術について語るスレで言うようなことじゃない。

950からの流れでプログラム技術とか言っちゃう人って……

手を抜くための理由以上のモノではないしな

>>925が救われたのかが気になる
スレチだろうけどな

>>950は素直にC使った方がいいんじゃないだろうか
そんなところに拘っても可読性落ちるだけで
プレイヤーには誤差にも感じない程度の差しかでないでしょ

>>959
かっこいいって何？
ハッカソンとかGame Jamにも足運んでるし
CEDECとかにも毎年参加してるし
いろいろな勉強会開いたりしてるよ？
バンナム社員の人と会話とかしてTwitterでも話してるし

ちなみに愛機はMBP(MacBook Pro)使ってるかな
UDKで作ったゲームは東方風のシューティング
あとはUnityとかもやってるしね

あとこう見えてゲームは全くやらないかな(笑）
「ゲーム好き、ゲームヲタク」っていうのはゲーム開発に不要って言われてるからね
普段全くゲームをしない、所詮人が作ったゲーム、自分で作ってやるほうがおもしろいかな
好きなゲームは地球防衛軍、ストリートファイター４
ネトゲは韓国の利益になるからやらないかな

一応できる言語書くね

C,C#,C++,Javascrip(Node.js),Coffeescript,Haskell,Eralng,Go,Scala,Python,Objective-C,OCaml,Scheme,LISP
とか使えるね

あとUnityの本とか全部そろえてるし
今はアンドロイドアプリ作ってるかな
じゃんけんゲームみたいなやつ

ここってプロフェッショナルレベルの人たちが集っていたのか

>>968
「使える」のレベルが低いことが用意に窺い知れる書き込みだな

>>968
はじめて見るのがいくつかあるな
俺もgimpのスクリプト書くのにschemeちょっとやったけど
lisp系の言語ってどういう場面で必要になんの？
やっぱりスクリプト？

lispはemacsの設定で使う場面しか思いつかないな

>>966
可読性が落ちるのは間違いないが、効果は誤差どころじゃないな・・・。
俺が950で挙げた前者は、みんなもやってるよね。

今時のコンパイラなら後者もOKなら、そろそろ観念してVS2012Pro買うかなぁと思ってさ。

プログラミングのスキルは手段であって目的じゃないからな。
自分の作りたいゲームが作れなければ全ては無意味だ。

>>973
すいません、やってないっす…

関数細かく作るから同じメンバに何度もアクセスする箇所があんまりない
ループする箇所はSTLにまとめてイテレーターでやっちゃってるな…

もしかして、俺のコード超遅い？

>>975
いやフレーム毎に収まれば正義ですし、可読性重視でいんでないですかね。

考えてみればExpressならすぐ使えたなと言うわけで、VS2012で試してみました。
うちの環境だと、基底から仮想関数で呼び出した場合に比べ、直で呼び出した場合は、
大体23%くらいの速度で行けるみたい。

最適化オプション色々変えてもあまり変わらず。
最新のコンパイラでも、やっぱり遅いみたいね・・・。

どうでもいいけど2012のUIかっこいいな。メトロというよりレトロだけど。

クラスインスタンスのdelete時に、Pure virtual function callのエラーが出て悩まされた。
純粋仮想関数持ってる親クラスのデストラクタに入ってから、その仮想関数を呼んでいることが原因だった。

deleteなんて自分で書くものじゃないし
デストラクタもなるべく書かないほうが良い

2012ってXPには未対応なんね

>>978
そうなのか？
俺はdeleteもデストラクタも使い放題だぜ。

>>978
気になる。理由は？

boostの参照カウンタ使えばdelete書かなくてもなんとかなる…かも？

>>982
移植の際にコンパイルエラー出たときの対応コストがboostは大きくつく。
ジャンルによってはカウンタ同期のコストが馬鹿にできないこともあるだろうし。

minmalなオレオレsmartptrを作っておくのが一番苦労しない気がする。

#include <iostream>
#include <vector>
#include <string>


int main(){
std::vector<std::string> Strings;
std::vector<int> Vector;
Strings.push_back("1-2-3-4-5");
Strings.push_back("9-7-8");
Strings.push_back("6");

for(unsigned int i = 0; i<Strings.size(); i++){
//VectorにStringsの文字列を正規表現等で格納したい
}


return 0;
}

Stringsに格納した文字列を正規表現で数字だけ取り出してVectorに格納したいのですが
正規表現はどうかけばいいのでしょうか？
Vectorを[1,2,3,4,5,9,7,8,6]といった具合です。
よろしくお願いします。

誰が調べてあげてたもれ

試してないけどboost::regex_grepに\\d+を突っ込むんじゃダメかな

deleteを自分で書くな

std::unique_ptrを使え
ノーコストのスマートポインタだ
スコープから抜けるときに自動的にdeleterを実行してくれる

std::unique_ptrが使えない場面では仕方ないのでstd::shared_ptrを使え
多態が必要なときはstd::shared_ptrじゃないとダメだった気がする

デストラクタを書くのはスマートポインタで自動的に解放できないリソースを扱うクラスのときだけだ
例えば、OpenGLのテクスチャオブジェクトとかな
だがFILEオブジェクトなんかはdeleterにfcloseを指定すればスマートポインタで自動解放可能だ

メンバ変数の解放はメンバ変数のデストラクタに任せて自分で解放しようとするな
抱合した子オブジェクトは親が死んだときに勝手に死ぬし
newしたオブジェクトはスマートポインタに入れとけば勝手に死ぬ

自分でdeleteする必要がある場面なんてまずないだろう

>>984
strtokでググれ

でもさ、
あるクラスをアプリ実行期間中、存続させつつづけて、
ゲーム・ステージの切り替わりのタイミングで、
それが持つ配列型メンバをリサイズする場合なんかには
deleteを使わざるを得ないんじゃないか？
こういうケースは頻繁にあるんだが。
全ステージ配列のサイズは固定とか縛り持たせるわけでもあるまい。

スマートポインタのvectorを使いなさい

あと、いまどき生配列はないな
固定長配列ならstd::array、可変長ならstd::vectorを使いなさい
Visual C++でデバッグモードでコンパイルすれば、範囲外アクセスしたときに例外投げてくれるはずだ

相互に関連していて、deleteでトリガーされるデストラクタの実行順を気にしなきゃいけない時もあるよ。
またブラックボックスな配列ってのは、リサイズ後のメモリアクセス効率性への影響が不安じゃない。

それなりに寿命が短くて、確実に管理できるなら
new/deleteの方が楽よね

>>991 例えばこういう循環参照を持つやつだよね。
struct B;
struct A{ B* b;};
struct B{ A* a;};

こういうときは、生存期間の管理用に一つ使い捨てのクラスを用意して、
struct C{
A a; B b;
C():a(),b(){ a.b = &b; b.a = &a; }; // 循環してるポインタをセット
~C(){} // デストラクタで a と b が 同時に破棄されるようにする。
}; // struct C自体はスタックか std::unique_ptr<C> にまかす。

デストラクタが走るときはコンストラクタと逆の順番だから、循環参照してて
デストラクタの実行順番を気にしないといけないような状態の場合はそれ自体を
struct Cのデストラクタに封じ込めるのはどうだろう。

オブジェクトへの参照を保持していることとオブジェクトを所有していることは別だと思うんだ

例えば木構造でなるべくメモリを局所化したい場合だとこういう感じになると思う

class Node { Node* firstChild; Node* sibling; Node* parent; };
std::vector<Node> vNode;

この場合、Nodeは他のNodeへの参照を持ってるけど、所有しているわけじゃない
所有しているのはvNodeを持つオブジェクトだ

あれこれって>993と同じことじゃね

weak_ptrを使うのだてめえら

class Task {
Task* m_pNext;
Task* m_pPrev;
bool m_Head; //デク先頭フラッグ
bool m_ToBeDeleted; //削除フラッグ
virtual void Exec()=0; //
};

class Filament : public Task { //m_EntryPointにTaskクラスをつなげる。
Task m_EntryPoint; //デク先頭
~Filament() { //親delete時に、連鎖的にdeleteする子の削除フラッグを立てる。
Task* child = m_EntryPoint.m_pNext;
while (!child->m_Head) {
child->m_ToBeDeleted=true;
child = child->m_pNext;
}
};
};

class Fiber : public Filament {...}; //m_EntryPointにFilamentクラスをつなげる。

class Synthesis { Fiber* fibers_active[4]; }; //１次元配列。参照のみ。

class Repository { //シーンの切り替わりで動的に生成・破棄し、インスタンスを必要分だけ保持する。
Task* tasks[1024]; //１次元配列。インスタンスを注入。
Filament* filaments[256]; //１次元配列。インスタンスを注入。
Fiber* fibers[64]; //１次元配列。インスタンスを注入。
};

↑極端な例だが、
Repositoryクラス内で、シーン中、必要なインスタンスしか確保しないという条件の場合、
　まずSynthesisクラス内の要らないfibers_active要素だけ削除フラッグを立てて、
　次にRepositoryクラス内のフラッグが立ったfibers要素をdeleteして、
　次にRepositoryクラス内のフラッグが立ったfilaments要素をdeleteして、
　最後にRepositoryクラス内のフラッグが立ったtasks要素をdeleteする、
っていうのが効率的なんじゃないか？

要は、麗しのタスクシステムなんだが（笑）

>>992
「確実に管理しなければならない」ポイントを減らすためにライブラリ使うんでしょ

お疲れ

そしてさようなら(#ﾟДﾟ)/~~

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。