TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
モナーシュミレーションゲーム作成中
烈風伝ライクな戦国ＳＬＧ作りませんか？
RPGを手軽に作れるソフト
おまいら！バカRPGのネタ出せ！
衝突力
同人ゲームサークルのメンバーを募集します
【ＳＲＰＧ】理想的なダメージ計算
【SB】Shooting Game Builder ver18【STG】
F1チーム運営シム 製作スレ
製作者スレ SRPG Studio 30章
C/C++ゲーム製作総合スレッド Part7
- 1 ：2015/01/11 〜 最終レス ：2017/12/31
- ゲーム製作におけるC/C++全般に関するスレです。
元スレ
DXライブラリ 総合スレッド その18
http://peace.2ch.sc/test/read.cgi/gamedev/1399459468/
前スレ
C/C++ゲーム製作総合スレッド Part1
http://toro.2ch.sc/test/read.cgi/gamedev/1337516528/
C/C++ゲーム製作総合スレッド Part2
http://toro.2ch.sc/test/read.cgi/gamedev/1351015269/
C/C++ゲーム製作総合スレッド Part3
http://toro.2ch.sc/test/read.cgi/gamedev/1357899040/
C/C++ゲーム製作総合スレッド Part4
http://toro.2ch.sc/test/read.cgi/gamedev/1376262450/
C/C++ゲーム製作総合スレッド Part5
http://peace.2ch.sc/test/read.cgi/gamedev/1389798031/
C/C++ゲーム製作総合スレッド Part6
http://peace.2ch.sc/test/read.cgi/gamedev/1404815419/
- 2 ：
- 乙
- 3 ：
- おつん
- 4 ：
- 基本的にゲーム内で使う文章を外に書くメリットはないよな？
で、セーブファイルは専用の構造体を用意して
そこに保存が必要な数値を片っ端からぶっこめばいいんだよな？
なら今のゲームでテキストファイルを使う場面って、
セーブデータ等のテキストデータのエクスポートくらいだと考えていいんだろうか？
- 5 ：
- 文章校正のたびにいちいちコンパイルすんの？
- 6 ：
- 海外のゲームやったことないのかね？
大抵テキストデータは外に置いてあって日本語化Modとか作られてたりする。
日本国内しか相手にしないならそれでも良いと思うけど
- 7 ：
- テキストデータでデータ構造作っておくと色々と便利だよ
テキストエディッタ使えばデータを書き換えられるから、
わざわざ専用エディッタを作らなくてもいいし
- 8 ：
- lua,Squirrelなどを使って、シナリオ・文章などを、
読み込んだりしているんじゃないの？
これらを修正する度に、
コンパイルするのは時間の無駄
- 9 ：
- ウチの会社では、基本的にゲーム内で使う文章は外のツールで作成してるな。
わざわざソース内に置くメリットがむしろ感じられない。誤字修正の度にプログラマが手を入れる必要が出てくるし、ビルドに時間もかかるし、別の言語に移植する際に面倒じゃないか。
あ、あと、文章の問題であればそのツールを開けばいいという、問題の修正箇所を局所化できるというメリットもあるから。
セーブは確かに専用の構造体(というかPODクラス)を用意して必要なデータをぶっこむ、シリアライズして吐き出す形だな。
それらの吐き出す形は結局単純なテキストではなく、何らかの形式に則ったバイナリ(テキストエディタで開いても意味不明な部分が交じるファイル)だけど。
- 10 ：
- プログラマ１人で造るミニゲームとかで、メニュー程度の文章量しかないなら
たしかにハードコーディングのほうが楽ではある
- 11 ：
- >>9
そういう文章ってどうやってプログラム中から識別するの
"会話0001"?
- 12 ：
- 4 ：名前は開発中のものです。：1985/01/12(土) 16:06:35.67 ID:skthRk+e
基本的にゲーム内で使う画像を外に書くメリットはないよな？
で、描画手順は専用の構造体を用意して
そこに開始点・終了点の座標や塗る色の数値を片っ端からぶっこめばいいんだよな？
なら今のゲームで画像ファイルを使う場面って、
画面紹介等の画像のスクショくらいだと考えていいんだろうか？
- 13 ：
- >>11
ユニークな名前で管理するのが面倒な規模なら
ロジックの部分もある程度は外に投げるようになるんでね
- 14 ：
- 画像ファイルでそれやろうって奴はいないだろ…
テキストは定義された物を書き出すだけだからやろうって考える人がいるだけで
あと、MOD作ってもいいよとか多人数でやるよとか
追加含めて大量に書くよってんならテキスト外置きなんだろうけど、
逆に言えばこのどれにも当たらないならいらないかなって
一部でもオープンソースにする気はないって人もいるだろうし
壊せる壁って破壊済み相当の状態で床などに変化するオブジェクトだけど、
これはダメージを与えていくと壊せる物はマップチップ扱いなのかキャラクター扱いなのかよく分からない
キャラクターをマップチップに正確に重ねてチップを隠すんならいけそうだけど、
そうするとマップ情報をキャラクター生成部に送る必要があるんだろうか？
- 15 ：
- >>14
普通に居るけど
Mod作りやすいってことは本編も作りやすいって事がわからんのだろうかね。
あとオープンソースの使い方おかしい
- 16 ：
- それ、一部の場面でレイヤーの代わりに使ったりする物のことを言ってるんだろ？
描画画像を全部内部で0から生成なんかやってたらそのコードだけでものすごい量になっちゃうよ
逆にそれが部品として小さいなら、外に置かなくても組み込んじゃえってのはありだとは思うし
それを実行しているのが一行目ってわけだ
非現実的な案ではあるけど、できるんなら画像の隠蔽は完璧だな
あと、一部ならオープンソースじゃなくてシェアードソースね、おk覚えた
- 17 ：
- お前は勘違いをしている
- 18 ：
- ソース違い
- 19 ：
- たとえ話は
通じなかった時に双方ともに間抜けなことになるのが辛いな
- 20 ：
- スレを流し読みしたが、>>14-16の辺りが話が噛み合ってないよな
これお互いに誤読してるだろ。推測するに大凡の所お前らの間には
目立った意見の食い違いはなさそうだから仲良くしろよな
- 21 ：
- >>14
＞壊せる壁って破壊済み相当の状態で床などに変化するオブジェクトだけど、
＞これはダメージを与えていくと壊せる物はマップチップ扱いなのかキャラクター扱いなのかよく分からない
本来は、昔のゲーム機の仕様(例えばOBJとかBGがあるやつね)の様々な縛り
の中での話なので、今なら好きに定義して自由に作ればいいんじゃねーかな
見当がつかなくて何か参考にしたいんならツクールの類でも触ってみて
内部の仕組みを推測して真似てみたりすればいいんじゃねーかな
＞キャラクターをマップチップに正確に重ねてチップを隠すんならいけそうだけど、
そういう手も当然ありだよね
＞そうするとマップ情報をキャラクター生成部に送る必要があるんだろうか？
どういう機能分割をしてるのかイマイチ分からんけど、座標系の概念が
考慮されてないなら取り入れたほうがいいんじゃねーの
- 22 ：
- え、俺はマップチップもキャラも一緒のオブジェクトなんだけど
お前らわざわざ分けてんの？
- 23 ：
- 車用ピッキングツール 車の鍵を不正に開ける工具
http://www.amazon.co.jp/dp/B00RGI2EU8
- 24 ：
- >>22
舞台装置と役者は似て非なる別物だからよ
>>14みたいなことをやる場合、
当たり判定まではキャラクターと同じでも
HPは持っていない壊せない壁をどう定義するかがな
- 25 ：
- >>24
同じオブジェクトで行けるってことは、似て非なる別物じゃないと思うが
- 26 ：
- 好きなようにすりゃええがな
あんさんの方法を否定してる奴なんて誰もおらん
あんさんは他人を否定したくて仕方ないかも知れないがな！
- 27 ：
- 例えどんな方法でも実現可能だったとしても
複数の手法の中からベストな物を追求するのは良いことである
- 28 ：
- >>26
まぁ、お前にゃ聞いてないがｗ
似て非なる別物の根拠を訪ねただけで、否定したように感じるってのは相当病んでるぞ
- 29 ：
- 当たり判定の範囲をなしを含む特有の定義にして、
一番最初に横たわるキャラクターオブジェクト それがマップ
他のキャラクターとは一部の要素が大きく違う分管理に差が出るし
無駄を承知で分けた方が分かりやすくはなる…かも
- 30 ：
- マップと言えば、マップチップタイプみたいな並びを記憶しておく必要があるマップは、
当然二次元配列を使うとして
たとえば現在の装備一覧のような、
同じ要素を指す数値の並びをしている物の塊も二次元配列にすべきなんだろうか
- 31 ：
- >当然二次元配列を使うとして
？
- 32 ：
- >>30
別にどう作っても良いけどマップも1次元の配列で持っていた方が楽
座標x、yも持たせておけばいい
- 33 ：
- 二次元のビットマップ画像も普通一次元配列で確保するよな。
- 34 ：
- >>30
＞たとえば現在の装備一覧のような(…中略…)二次元配列にすべきなんだろうか
一覧表示にも色々あるけど
要求(される操作)に応じて適切なデータ構造(コンテナ)選ぶものなので
二次元配列でおｋ(な要求)ならそれで作るのが一番いいんじゃねーの
要素数がたかが知れてる場合、配列(std::vector)使ってるからって
何か問題が生じるような事はまずないわけだし
- 35 ：
- 2次元配列でOKなものは1次元配列でOK
わざわざ2次元配列を使うメリットは何も無い
- 36 ：
- シンタックスシュガーでしかないもんねぇ
初心者に教えるなら積極的に使うけど
- 37 ：
- 一次元配列で確保した上で行(or列)先頭にアクセスするための
インデックス(LUT)を用意するような内部実装でも二次元配列
なんであってだな(>>33)
ターゲットも実装も不明ならメリットねぇとは断言できんよ
- 38 ：
- >>36被ったスマン
- 39 ：
- たとえば縦スクロールSTGのマップとかで、
メモリ節約のためにマップを行ごとに細切れにして
表示範囲の上に一行足して下から一行引くような処理をしていたりする場合、
一行ずつ読み込んでるんだという事を示すためにわざとやるとか
試作段階で仕様が固まらなかった時の苦肉の策がそのままになっちゃったとか？
二次配列ってなんかあんまり使い道が浮かばない
- 40 ：
- 3Dでキャラクターが技によって自由に地面の凹凸を操作できるようにしたいんですが
予め頂点を作っておかないとダメでしょうか？
キャラクターがここじゃーって指してる座標に一番近い面の上に
頂点をいい感じに窪ませるように配置して、
もともとあった面と入れ替わるような感じにしたいのですが、
当たり判定やハードウェアレンダリングしたいならやっぱり面倒ですか？
まぁハードウェアレンダリングなんてどうやればいいのかわからないですが
- 41 ：
- 確かにあんまり、というか殆ど多次元配列使わないな
配列へのアクセス部分は、隠蔽する傾向にあるから、アクセス用インデックスが多次元でも、アクセスの内部仕様は１次元配列でやってることが多いな
また配列の次元数を増やすと、後から解読するのが難しくなって、可読性が下がる
だから次元が増える場合は、次元別にクラス定義して、一次元配列のメンバに下位次元を持たせるようにしてるな
そういやD3DMATRIXに2次元配列のメンバあるけど、自分で定義したものじゃないし、そもそもそのメンバって殆どアクセスしないなぁ
- 42 ：
- std::vector<std::vector<int>>とかやるじゃん？
- 43 ：
- Dictionary<Point, Tile> Mapしか使わん
- 44 ：
- >>42
enum定数でアクセスするのかな？
それにどんな情報を入れるんだろ
- 45 ：
- ベジェとか普通に書いたら多次元配列になるんじゃ…
- 46 ：
- >>42
やりません
コンテナ2つ重ねても無駄に複雑になるだけでしょ
- 47 ：
- >>42
リソースに余裕がある場面では使ってるな
規模が大きくなってくると細かいことまで気にしてられんからこれ使うとラク
- 48 ：
- >>40
テッセレータを使ったらいいのでは？
凹ませたい領域を4頂点の単純なタイルで表現し、それをフィールドに敷き詰めておく。
凹ませるときは、該当するタイルに対しテッセレーション（最大64分割）して、
高さマップを与えてディスプレースメントさせる。
- 49 ：
- >>46
やるぜ？
可変長CSVの読み込みとか
- 50 ：
- 長さ不定のに多重vectorはしないかな
- 51 ：
- vector<vector<T>>は便利なときもあるけど、
コピーやトラバースのパフォーマンスがvector<T>に比べて著しく遅いんで、
そちらが重要なときは多少冗長でもvector<T>で扱うようにしてる。
- 52 ：
- vector<vector<T>*>
- 53 ：
- 生ポインタ使うならdequeで良いだろ
とは言えないパフォーマンス差があるんだよな…
- 54 ：
- vector<unique_ptr<T>>
- 55 ：
- null_ptr
- 56 ：
- nullptrでは･･･
- 57 ：
- 相当昔にC++触って、今と環境がかなり違いそうなのですが、
タスクシステムを実装する時、昔は固定長のメモリを予め確保したうえで、そのメモリを
newすることによって使っていたのですが、今のゲームもこのやり方が主流ですか？
それともスマートポインタ＋std::listでも速度出るのでしょうか？
スマートポインタとやらは、これはやってる事はガベージコレクションですよね？
速度に問題無しということですが、ヒープ領域から自由にnewdeleteして大丈夫なのかと不安になるのですが・・・
- 58 ：
- 誰も使ってない
- 59 ：
- >>57
スマートポインタはリソース管理の安全性を高めるだけで、
new、deleteのパフォーマンスを高めるわけではない。
むしろクラス被せる分、オーバーヘッドが嵩む。
現代のハードウェア環境においては、多くの場合そのオーバーヘッドは問題にならないというだけ。
- 60 ：
- 手動解放は、車で例えると
タイム短縮のためにわずかなエンジンパワーのロスも許されないプロレーサーや、
オートマはエンジンパワーが完全には伝わらないのでクソ
俺は完璧なギアチェンジ操作ができる（自称含む）のでマニュアルで通すんだって人向け
解放忘れてメモリリーク他の面倒な問題を起こしても泣かないなら全部手動で
それが嫌なら我々が作った処理班にぜひおまかせ下さい！
スマートポインタってそういうもの
shared_ptrやweak_ptr自体の書き忘れや循環参照などは防げないけど
>>55
ga
- 61 ：
- >>57
ここではWindowsならメモリ確保の負荷はそんなに問題にならないとしている
http://marupeke296.com/ALG_No2_TLSFMemoryAllocator.html
スマートポインタはGCってそれどういう意味だよ。
スマートポインタに使っている参照カウントはGCの方式の一つとは言えるが。
http://ja.wikipedia.org/wiki/参照カウント
- 62 ：
- おじさんは2万円前後の安もんの8インチタブ(CPU:Z3735G，RAM:1GB)を
即売会場でデモ機として使う都合で、バッテリー駆動でできるだけ長時間
ヌルヌル動かすために貧乏根性丸出しな組み方しちゃったけど、そういう
変な目的が無ければ自分の好きなようにやればいいと思うんだがな
○○のやり方が大丈夫なのか不安とか意味わかんねぇな。周りキョロって
ねぇで自分で決めた基準動作環境で自分でテストすればいいじゃんと
- 63 ：
- 最近は底の方でも1GB
これなら多少雑に使ってもリークさえさせなければ問題ないな
なお512MB以下は爆死する模様
そんな化石がまだあるのかどうかは知らないが
- 64 ：
- 全部起動時に読み込みとかやめて！
- 65 ：
- ふははは、貴様のセルを使うかどうかもわからない画像や音楽データで埋めてくれる！
読み込み時間といい、占有領域といい、ロースペにはある種のテロだな…
- 66 ：
- 音楽やムービーのストリーム再生以外で、オンメモリでないゲームが作れるって凄いな。
そこまでリソースが用意できないよ。
- 67 ：
- メモリ次第ではあるけど
常駐とブラウザ合わせたら警告食らうくらいのゲームならあるんじゃないの
- 68 ：
- >>66
数年前、(旧)Android Marketに個人でゲーム出した時は機種依存の
バッドノウハウの量に本気で吐き気がしたけど、あれに比べたら
PCゲーは作りやすい思たよ。メモリフットプリント小さくするだけで
おｋなら大したこたないと思える程にAndroidスマホはカオス
(だった。今はどうなってるのか知りません)
- 69 ：
- 1080pの画像を一度に100枚読み込めばロード地獄間違いなし
1920*1080*4 /1024/1024 *100 = 791MBぐらい
スマホだとアプリが強制終了するかも
グラフィックの豪華なアプリのModern Combat 5でもメモリは512MBぐらいまでしか使わない
- 70 ：
- 圧縮テクスチャ使えば1/5くらいにはなるんじゃね？
- 71 ：
- そういや、Appmethodってどうよ？ちょっと気になってるんだが使ってる奴居る？
- 72 ：
- タスクシステムで組む時、
・タスクリスト２つ用意して移動と描画分ける
・タスクリスト１つに移動も描画も入れる
どっちがいいのでしょうか？個人的には前者にしたいけど・・・
- 73 ：
- 前者にしたいのにできない要因を考えるのがよい
「みんながどうやってるか気になる」ってだけなら気にする必要はない
- 74 ：
- タスクシステムはバグった時に大変そうな印象
そりゃあ、バグれば大抵それなりに大変な目に遭うんだけどさ
- 75 ：
- >>69
一般的なアプリは、数MB
- 76 ：
- 昔タスクシステムスレあったけど相手の主張への罵詈雑言だらけでいつの間にか消えたなｗ
- 77 ：
- 移動と描画両方持ってたほうがスマートだべ
- 78 ：
- >>76
「タスクシステム」っていう名前が何を指すのかがすごく曖昧なのに
それを無視して自分の中の定義を押しつけ合う奴らの隔離スレだったし
消えて当然とも言える
- 79 ：
- まあ個人でゲーム作る分にはどう作ろうが60FPS出てちゃんと動けば勝ちだからなｗ
会社とかで厳密にタスク管理されてるなら覚えなきゃならんのだろうけど。
- 80 ：
- タスクシステムw
馬鹿しか使わん
- 81 ：
- >>80
なんで？
- 82 ：
- >>80
OS上で動くアプリならそうかもな
OS込みとしてならタスクは最適解だろうし、組み込み系で使われてるOSは名前が違うだけて同じ系統のものだよ
現在マイノリティなのは認めるけどな
- 83 ：
- ほーら始まったｗ
スレ立ててそっちでやれｗ
- 84 ：
- たすくしすてむってなあに？
おいしいの？
- 85 ：
- ごめんなさい
反射してしもた
- 86 ：
- だーかーらー、ただのリストに大げさな名前付けんなや
- 87 ：
- http://ja.m.wikipedia.org/wiki/TRONプロジェクト
多少は勉強になるから、読んでみたらどうだろう
これの亜流だよ
- 88 ：
- はじめからほとんど完成しているシステムに、
そのシステムの中枢部に触れないように要素を追加できるような実装を目指すなら有効
つまり、OSやエンジン作るならこれがいいかもしれない
が、そうでなければバグが修正困難だったり無駄な手続きが多いクソ
なんだ実行順って 必要になった時にやらせろオラァァ
- 89 ：
- 最近はどんな言語でもクロージャやジェネレータ (yield) をサポートするようになってきた。
タスクシステムとは呼ばれないけど、同じ目的には使えるんじゃないの？
描画に関しては、オブジェクトが自前で描画命令を発行するのか、
オブジェクトとは別にスプライトのような構造を用意して、描画はそちらに任せるかの差が大きい気がする。
巷のゲーム向けのフレームワークを見るに、後者のほうが可搬性は優れているんじゃないか？
- 90 ：
- オブジェクトが自前で描画って構造はゲームではあり得なくない？
ポーズ作るだけで一苦労じゃん
- 91 ：
- ネットに転がってるC++のゲームソースしっかりしたのはほとんどタスクシステムっぽいのばっかだから
そういうソースじゃないと読む気がしなくなったっていう(´・ω・｀)
- 92 ：
- 単一のタスクだけで動かすと実によく機能するのに、
タスク同士を連動させようとすると途端にギクシャクする辺りが
実にぼっちらしくてよいが、
プログラムにそんなのやらせてどうするんだ
- 93 ：
- >>90
cocos2dとかそんな感じじゃね
- 94 ：
- C++11のstd::asyncってのが便利そうだから使ってみた。
確かに簡単に別スレッドに非同期に仕事をさせられる。
だが、どうも処理結果を受け取ってスレッドを終了するのに膨大なコスト（500msくらい）がかかるようだ。
代わりに、std::threadで常時スレッドを走らせておいて、std::mutexで同期を取りながら
データのやり取りをするようにしたらとてもスムーズに動くようになった。
しかし、std::asyncを使った場合と比べて、煩雑な記述が避けられない。
スレッド終了のコスト高杉。
- 95 ：
- TBBやPPL使っとけ
- 96 ：
- >>94
Windowsの話だよな？
- 97 ：
- C11使っとけ
- 98 ：
- >>95
サンクス。
調べてみる。
>>96
そうだよ。
- 99 ：
- 1タスクごとにスレッドそのものを開始終了するとコストが高いので
想定するCPUのコア数だけワーカースレッドを用意して
それらにタスクを投げるのが定石じゃないかな。
・キューにタスクがない時はスレッド待機。
・タスクをキューに投げたら全ての待機スレッドを励起。
・いずれかのスレッドがキュー上のタスクを取得して実行、他は再び待機。
・タスクが完了してもスレッド完了せず、次のタスクを確認する。
デザインパターンにあったはず。
- 100 ：
- >>71
居ないのか……ま、いいや
100〜のスレッドの続きを読む
【新作】忍者くん、じゃじゃ丸くん【ファミコン版】
2ch版いただきストリート作りませんか？
-RPGツクール総合スレッド＠製作技術（Part15）-
WOLF RPGエディター 質問スレ 其の11
ぜーんぶ素材を借りてゲームを作るすれ
烈風伝ライクな戦国ＳＬＧ作りませんか？
頭の固いプログラマーはゲ製から出てけ！！
ファミスタ'03を作ろう
アクションゲームツクール総合■10
不謹慎ゲームスレ
--------------------
スーパーJチャンネルの引きこもり狩り賛美
Biglobeメッセンジャー
地震関連スレ 限定版 in 地理板
ジャンプ打ち切りサバイバルレースPart3200
真夏の夜の淫夢 [816528813]
0.5ぱちの魅力
宮城の釣り〜釣行90日目（本スレ IDワッチョイ有）
【DB】Dirty Bomb Part26【FPS】
【社会】「新コロナウイルスは痛快な存在」と発言し、謝罪なくTwitterアカウントを削除した小滝ちひろ氏の件で朝日新聞広報がお詫び
サマナーズウォー: Sky Arena 雑談質問スレ60
武蔵坊弁慶
【ふぉぶ】FOB FACTORY part9【フォブ】
【めざまし】 永島優美 Part8【ユミパン】
アーモンド実況25
MVNO】 0SIM by So-net 【史上最弱】 Part38
キャラクターグリーティング！ 60回目のハグ☆
東海気象情報 No.230
可哀想なおじさんを愛で包むスレ
【サッカー】エールディヴィジ今季終了 64年の歴史で初の王者なし【元々特別なOnly1】
パンクラス総合スレッド Part82
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
