乙。 前スレ埋まってたのか、気付かなかった
6 :
名前は開発中のものです。 :2012/10/25(木) 04:53:51.10 ID:s4jU45SK
4 1-2 3 0-3 2-1-4 ↑上下左右の値を加算すると9方向表現できるぞ! あとはテーブルでもなんでも配列でも定義して合計値に+4すれば0~8の添字が取り出せる!! やべえええええええ!!!!
日本語でおk
クラスのオブジェクトのインスタンス毎に途中で変数を名前付けて確保するってやっぱりmapとかじゃないと無理かね
>>7 面白いけど、どこで使うんだそれ
上下左右からの入力値がある場合に関数ポインタの配列で処理させるとか?
そういう処理が大量にあるゲームってなんかあるかね
>>10 間違ってるのかは知らないけど、キャラクターの移動制御とか
WASDで上下左右斜めを移動させようとする時if文が気持ち悪いからを回避させようと思って考えた
のちの二進数である
二進数だと0〜10にならないか
上下左右4bit分のテーブル用意したほうが解りやすくね それで思い出したけど上と下同時に押された時どうするか迷う 大抵面倒くさいので相殺しちゃうけど、 後から押した方を有効にしてやったほうが操作感よさそう
>上下左右4bit分のテーブル テーブルに使用しない要素ができるのが、なんだかねえ。
16 :
名前は開発中のものです。 :2012/10/27(土) 17:43:29.40 ID:PILDR8EH
ケチ臭いなw
Cプログラマらしいっちゃらしいけどな 無駄の無い方が美しい
現場でしょっちゅうこんな口論して、主導権争いしてるんじゃ?
過疎 m9(^Д^)9mザマァ
>>15 キーボードだと左右同時押しはありえるんじゃない?
同時押してキーボード側の制限あるから厳しい事もあるな
>>7 のアルゴリズムだと反対方向同時押しは押さないのと同等になるな
それはそれで問題無さそうだが
もし何か特別な処理が必要になったら根本から破綻するな
まあ、最適化されたアルゴリズムなんてそんなもんだけど
>>15 使用できない要素はたしかに出来るんだけどね
0-8に変換だったら64bit整数1個で済むし気にならなく無い?
n = (0x0576108734052310LL >> (k << 2)) & 0xf;
24 :
名前は開発中のものです。 :2012/10/27(土) 22:20:47.43 ID:B8sptMGD
>>12 後の3値論理じゃないかな
DB屋さんがクソNULLがとか言ってるのは、まれによくみる光景かと。
そんな性能的に無視できるところで必要以上に最適化する奴はセンスがないんじゃないか
キー入力以外でなんか使い道あればなあw 入力が2値になるからかなり限定的になるが
スマホとかのソフトキーなら、左右同時押しでスピンとか入れるのも楽しそうだ
一瞬俺も謎だったが 0を起点に上下左右で同じ数を足し引きしてるから何となくわかった 左上なら3+1で4と言う風に計算させてキー入力判定できるじゃんてこと(だよな?)
真下と斜め下を区別しないようなときはちょっと面倒かな?
数値の配置変えるだけで良いだろう
>>22 同時押しを定義しておけばいい
想定していない操作は押さないのと同等になるのがメリット
>>23 のアルゴリズムなら同時押しも別に定義できるな
メモリと処理の無駄も特に無さそうだし、応用もききそう
そんな性能要らないところで最適化する奴はセンスないぞ そういうところは何やってるのかが明確に分かるよう読みやすく書くべきだ
センス君乙
レッテル貼り乙
便所の落書きなんかよりコーディングでセンスを発揮できる奴のほうが社会的に有用だぞ
39 :
名前は開発中のものです。 :2012/10/28(日) 16:09:33.74 ID:rrtnkDUA
>>38 レッテル貼ってるのはお前だろ
センスクン
ここでやるなageるなクズども
ttp://blog.ashodnakashian.com/2011/06/the-second-law-of-optimization-abridged/ Premature optimization; Most of us have been there.
And that’s what makes those words very familiar. Words of wisdom, if you will.
We’ve all decided to do a smart trick or two before fleshing out the algorithm and even checking if it compiles,
let alone checking the result, only to be dumbfounded by the output. I can figure it out! we declare… and after half a day,
we’d be damned if we rewrote that stupid function from scratch. No chance, bub.
ID:j5L9gX8T のコーディングまだ?
そりゃ仕事でやるなら効果無いような細かいこと気にしないけど 話のネタまで否定しなくていいのに
馬鹿な奴が
>>7 とか
>>23 みたいな巧妙なトリックを真に受けて真似しかねないからな
1/60秒で1回しか実行されないような実行時間的にほぼ無視できる場所で
こんな最適化するのは無駄どころの話ではない
ぶっちゃけ害悪である
あなたは半年後に同じコードを見て何をやっているのか一瞬で理解できるだろうか
とりあえず話題があればセンスとか無くていいです
1fpsかよw
読み違えたわw
つまんねーやつ。可読性モンスターはこういうの多いよな。 昨今の技術書の影響だろうけどさw
つまらなくて結構 コーディングで笑いを取る必要は全く無い 面白いコードより分かりやすくて効率的なコードを書きましょう
はいはい、先生様。
人格批判やレッテル貼りばかりで詰まらん奴らだな 何か反論できないのか? 実行時間的に無視できる部分を巧妙な手法で最適化することを擁護する意見はないのか?
効率的じゃなくて読みやすいコードのお間違えでは?
ここの連中も、センスなんて言葉でレッテル貼ってるやつに言われたくないと思うぞw
>>52 いや、話してるやつらは最初からわかってやってんじゃないの
>>7 についた最初のレスが「それなんの役に立つの?」だぞ
いいからハードウェア半分触るレベルで最適化してるんでなければ、コンパイラの最適化にまかせてろ
57 :
名前は開発中のものです。 :2012/10/28(日) 16:48:27.57 ID:rrtnkDUA
わからんのだろ? センスってセンス悪いって言いたいだけみただしな。
>>55 >>11-33 あたりを見てると、そうは思えなかったな
書き込んでる奴らには「そんな糞コード書くな糞が」と思ってる奴がとても少なそうで残念だ
だから俺が教えてしんぜようってか? 傲慢な奴めw
60 :
名前は開発中のものです。 :2012/10/28(日) 16:57:15.74 ID:rrtnkDUA
苦笑
61 :
名前は開発中のものです。 :2012/10/28(日) 16:59:55.14 ID:rrtnkDUA
以上。新入社員研修でした。
ディスプレイの前でROMってるお前 そう、お前だ ここまでの流れで分かったと思うけど、便所の落書きを真に受けるなよ 何が正しくて何が間違ってるのかは自分で判断しなさい この書き込みのことも真に受けず自分で判断しなさい
なんか荒れてるなー
これはコードゴルフの流れだな
65 :
名前は開発中のものです。 :2012/10/28(日) 20:12:04.01 ID:TbEep54T
なんか理想のゲーム作ろうとして詰まったから逃避で STLの学習がてらミニゲーム作るつもり それが適当にゴリゴリコード書いただけなのに パラメータをGUIでいじれるようにしたら 自分がハマりまくって目がヤバイ
>>65 面白いゲームってのは案外そういう風に生まれるのかもな
>>45 >>7 や
>>23 は、スコープが非常に限定されているじゃない。
何か後々作業が膨らんでしまう可能性ってあるか?
あの程度を半年後に見てすぐわからなかったら、それこそセンスないぞw
どうして何のメリットもないことをそうまでしてやりたがるのか全く理解できないな どうせ性能には1ミリも影響しないのに無駄な時間かけて最適化()笑とか馬鹿じゃないのか
別に誰も、話題に上っていないスコープも含めて、問題の優先順位の相談してないからwww ところで、 >1/60秒で1回しか実行されない >何のメリットもない >どうせ性能には1ミリも影響しない どうしてそう言い切れるんだ? 思い込み激しいんじゃねえの?w
最適化なんてある程度書けるようになった中級者以降がするべきもので、 初心者がこだわるのは非常に無駄っていうのには同意
最近のコンパイラはますます優秀になってくなぁ・・・ 必要以上の最適化はもう不要な時代なんだろうけど 最適なデータ構造を心がけるクセは早めから意識するといいと思う
>>71 とはいえコンパイラが最適化してくれるのはアセンブラレベルで、アルゴリズムの最適化してくれる訳じゃないし
ボトルネックになりやすい箇所はやっぱり自分で工夫しないといけないんだよな
まあアセンブラレベルの作り込みとか絶対やりたくないけど
家庭用ゲーム機だと結構普通に必要らしいね 特にソニーの奴
例のセンス君はどうせ本読んで囓っただけだろ
マシンパワーが向上した事も理由の一つじゃね? 数パーセントの最適化程度じゃ、大して差はないし
75 :
名前は開発中のものです。 :2012/10/29(月) 12:01:08.46 ID:kMq1Bnep
レベル低いなーお前ら
>>75 なんだかんだでCはそういうのに向いた言語だからなー
スクリプト言語組み込む時代だからなあ
ぶっちゃけCPUの処理能力は余る方向にある 最適化が必要なのはGPUのほうだ ちょっと重い処理をしたら簡単にフレームレートが下がる GPUの処理がスムーズにいくよう工夫するのも重要な最適化だな 視野カリングして見えない物体をGPUに送らないようにするとか 頂点キャッシュが効くようにインデックスを並べ替えるとか
コンシューマだとメモリもよく聞くなあ
マシンパワーの向上って念仏みたいにいってるけど CPUやGPUが性能を発揮できる流れに沿ってることが大前提だな 例えばマルチコアCPUならマルチスレッドを多用すること、 GPUだったら一括描画やカリングだな ハードウェアの特性に逆らったり、設計から生じたボトルネックの重さは マシンパワーの向上では解決できんよ SSE2でバッファコピーの高速化云々みたいな小さい話なら コンパイラの進歩まかせでいいと思うがな
81 :
名前は開発中のものです。 :2012/10/29(月) 23:40:45.73 ID:gi/SrGX8
不毛な争いだなw
そういやシェーダの話ってスレ違いになんのかね?
各ゲームエンジン用のシェーダならそのスレへ、glslならopenglのスレへ hlslならdirectxのスレへ
組み込む場合の直接C++に関わってくる部分はこのスレでも
->commitchanges();の呪文詠唱を忘れて時間喪失
新スレたってたのか
C++のゲーム作りなんて実質テンプレ化されてるから、 ツール使いとそんなに大差が有るわけではない無い。
それでもツール使いの方が絶対数は多いな 人間、新しい事をするのは面倒なんよ
XM/MOD/IT形式の音楽を鳴らせるライブラリってありますか? かつて使い慣れていたので
ぶっちゃけ、お前らC or C++でゲーム作ってる? 作ってるのは仕事で?趣味で? 趣味でやってる人はどれくらいの規模のもん作ってるの? ちなみに俺は趣味で3Dシューティング(パンツァードラグーンみたいなの)作ろうと 思って始めて、エンジンすら完成しないまま放置してたのを最近また進めようと思ってる 多分アーキテクチャを流用してほぼ書き直しすると思うけど みんなどれくらいのモチベーションでやってるのかちょっと知りたいわ
92 :
名前は開発中のものです。 :2012/11/02(金) 23:00:21.22 ID:pvjO2WuT
教えてほしいか? 趣味で世界規模だ
趣味 規模は小さいけど自分の手にあまり気味
エスパー向け質問で悪いんだけど、 シューティングゲームの攻撃判定ってどうやってキャラクターやエンティティが取得してる? 各キャラクターが更新されるたびに攻撃マップとか除いてふるまうの? それとも、すべてのキャラクターやエンティティが更新し終わってから 攻撃判定用のクラス(?)が判定して、各キャラクターやエンティティにフィードバックするの?
何が言いたいのかわかんないけど、普通は毎フレーム1から構築
>>94 >攻撃マップとか除いてふるまう
ってのがよく分らん。
決まったやり方なんてないだろうな。
俺はアクター単位の更新前にやっている。
久しぶりにゲームプログラム戻ってきたけどほんと訳分からんw 勉強し直しだな…
プログラムは自分で作るとして、ゲームの素材ってどうすればいいんだ みんなフリー素材使ったりとかしてるのか? 全部一人で自作しようとして、終わらなくて心が折れそう…
99 :
enpel :2012/11/03(土) 21:27:44.18 ID:bHLe96K0
>>98 自分で作るしかない
みんな3Dエフェクトはどうしてる?
最近だとeffekseerとかbishamonとかは見かける
104 :
名前は開発中のものです。 :2012/11/04(日) 06:39:38.34 ID:YUTURfMs
ゲームの背景に使える素材サイトってある? 写真じゃなくて、アニメの背景のような水彩画っぽいのが いいんだけど、そういう素材って見かけなくて。
エロゲの背景みたいなのならググれば出てくるが
イラストサイトでも回れば
著作権とかライセンスとか気にすると以外とめんどくさい
点A: X,Y,Angle
点B: X,Y
とあった時に、
点AのX=0,Y=0,Angle=0度 とした時の点Bの位置をsqrtを使用せずに求めたいのですが
どうしたらいいでしょうか?
http://codepad.org/u0wX7SBH 自分の頭だとどうしてもsqrtを使っちゃってこうなります。
意味がわからん ベクトルで駄目なのか?
>>109 仮に点Aから見てAngleの方向に点Bがあった場合、
点Bの座標を(0,距離)として表現したい
ビュー変換の関数使うのが一番楽そうだけど
距離で出したいのか だったらsqrtはいるんじゃないのかな
距離は過程で、座標さえだせればいいです。 ややこしくてすいません。
距離分かってんなら三角関数で座標求めるだけじゃないか・・・
x'=(xb-xa)cos-(yb-ya)sin y'=(xb-xa)sin+(yb-ya)cos 二次元なら多分これで出ると思う 変換行列の作り方がパッと出てこないヤバイw ちょっとやってないとすぐ忘れる
あ、回転は-Angle
xbやらybを求めたいのにそれを式の中で使ってどうするんだ
119 :
名前は開発中のものです。 :2012/11/04(日) 21:57:57.68 ID:obDXMYF5
距離がないと位置は出せないだろw
>>108 BからAを引けばおk。
relativeX = B.x - A.x;
relativeY = B.y - A.y;
121 :
名前は開発中のものです。 :2012/11/06(火) 19:53:02.05 ID:eNz//o3J
なんで距離求めて x,yに分解するんだ
画像の通り。 (cosθ, -sinθ)(sinθ, cosθ)と(x, y)の行列の積。回転行列。 >Angleはどこに代入すれば・・・ sin()やcos()に何渡すんだよw
そもそも>108の日本語がワケワカメで何がやりたいのかさっぱりわからん
>116の書いた x'=(xb-xa)cos(-Angle)-(yb-ya)sin(-Angle) y'=(xb-xa)sin(-Angle)+(yb-ya)cos(-Angle) これが正解だろ
>>120 この方法で解決しました!
ありがとうございました。
相対座標求めたいだけだったのかよw
>>128 回転が加わると育ちが悪いせいかどうも遠回りな計算しか・・・
131 :
名前は開発中のものです。 :2012/11/08(木) 06:32:08.18 ID:ELEjlKZe
見下しているつもりのバカの滑稽さがなかなか楽しかった
なんだかんだ言って教えてくれる人がたくさんいるツンデレ空間w
133 :
名前は開発中のものです。 :2012/11/08(木) 11:16:16.68 ID:ELEjlKZe
>>1332 教えている奴の大半がまともにコード読めないアスペか
池沼だったけどな
まあマシンスペック上がってるしこんなんでもいいのか
sqrtはx86の拡張命令セットにあるはずだからそんなにリソース食わないと思う 10年前のコンパイラ使ってるとかなら話は別だが
カンスト時のオーバーフロー対策として範囲チェック付きのintのラッパークラス作って 多方面でintの代わりに使うのって悪手なのかな? チェックしないワケにはいかないから毎回毎回チェック用の関数に通してたけど そんなことするくらいならラップしたほうがいいよね?
>>136 それ演算子オーバーロードして計算する度にチェックしたりすんの?
結構なオーバーヘッドになりそうな気がするが…
一回ベンチマーク取ってみた方がいいと思うけど
あとはオーバーフローする可能性のあるところだけ使うとか
>>137 もちろん単純な計算とかはintと同じような振る舞いができるようにしようと思ったんだけど
思いつきだったから他所の各種フォーマットのこととか考えると一気にめんどくさくなってくるね・・・
多倍長整数クラスみたいなのは自作しないのが鉄則だと思う
ググッてみたが連絡必須な作者ばっかりだな
「任意倍長整数 std::vector」でググッた? しかし、ゲームではスコアぐらいしか使い道が無いような・・・
intがダメならlongを使えばいいじゃない 現実的な時間でカンスト出来なきゃおkでしょ
それを言うならlong longじゃね? longとintじゃ、サイズ一緒だし。
C#やVBとC++じゃ、データサイズ違うしな
さーせんintが16bitと勘違いしてた
少し質問です。 最近のFPSゲームなどはどんな言語、環境、ソフトを使って開発しているのでしょうか?
>>147 ゲームエンジンが主流ですか、Unityなら言語はC++でしょうか?
DXライブラリというものも耳にしますが、あれは何なのですか?
>>148 わかりません
Unityやってます
はいjavasciptでUnityを使います
シューティングゲームみたいなのを作っています
>>145 >さーせんintが16bitと勘違いしてた
16bit機なら間違ってない。
PCのFPSなら、作品数で多いのはudk またはunreal engineかと。やったことあるならロゴはみたことあるよね。 それかc++とdirectXで内製するかかな? dxlibは公式みればわかるけど、directXのラッパーで扱いやすくしてるらしい。2dがメイン? 3Dは一応dxlibでもあるらしいよ。使えるか使うほどのものかは自分で調べてね。 公開されてるゲームエンジンならtorque3dとか、ogre3d(c#とかあるけどどれだけ利用されてるかはしらないな。
>>148 あ、javascirptやってればいいと思います
僕は学校でunityのjavascirptを使ってunityゲームつくってます
あ、そうなんですか
FPSはあれがすきです
ゴーデンアイです
日本のゲームしかわかりません
>>149 >>151 おぉレスありがとうございます、早速いろいろと調べてみます
ちなみに好きなFPSはAVAです
>>153 AVAですか
でもAVAってネトゲですよ
運営のGAMEONは韓国資本です
搾取されてる感じなのでネトゲはあんまり好きじゃないです
(^q^)FPSが大好きです、どうやって作ればいいですか?
C++製の同人ゲーでオススメは?
158 :
名前は開発中のものです。 :2012/11/10(土) 00:51:56.35 ID:c/VcRE9w
CかC++かとかわからんやろ〜
readmeや自サイトに書かれてることは少なくないけどね
DXライブラリ使ってれば大抵C++
同人ゲームならコミケ行って開発者に聞くのが早くね?
バイナリエディタでexeを開いて「C++」で検索すると、「Visual C++ Runtime Library」という文字列が出てきた VC++製のプログラム全部に含まれるみたいだからこれで判別できるな
164 :
デジタルハリウッド@偏差値45 :2012/11/10(土) 09:41:21.35 ID:LnFUWnqt
>>155 Unityがいいですよ
DirectXっていうのは時代遅れです
C++も時代遅れです
Javascriptがブームです
Unity Game Jamっていうサークルがあるのでよかったらきてください
FPS作ってる人もいます
UnityみたいなゲームエンジンもJavascriptで作れる時代なのか・・・ GooogleのV8もJavascriptで書かれてるのかな そのうちJavascriptでOS書いたりデバイスドライバ書いたりできるようになるかな?
まさか時代遅れのC++やさらに古いC言語で書かれてたりしないですよね?
俺はjavascriptで身長伸びて彼女できて宝くじが当たったよ
僕はUnityとjavascript使ってゲーム作ってるよ C++とか時代遅れだよ javascriptの時代だよ
高度な釣り
高度ではないだろ
どこからが釣りなの? >ゲーム製作におけるC/C++全般に関するスレです。 まさかこれ?
???
馬鹿と無知としったかはほっておけ。スルースキルは2chのスキルの中で最も重要
>>174 もともと釣りじゃなかったのか、了解した
C++のnewってどういう意味でしょうか?
newはjavascriptにもあるだろ
javascriptwwwww ブラクラゲームかwwwww
何がおかしいんですか?
初心者でも今時JavaとJavascriptは混同しねーよwww
誰かブラクラゲームに突っ込んでやれよw
余計なJavaScriptはウザいからそういう皮肉かと思った
話題ないみたいだからちょっと質問 透明色含んだビルボード表示するときにvectorに突っ込んで表示順ソートしてるんだけどなんか遅そうな気がする もっと効率的にソートする方法ないかな もしくはzバッファ切った方がいいの?
>>184 3Dシューティングぽいので弾を全部ソートしてるから最大で300くらいかな?
敵増やすと増えるからちょっとあいまいだけど
たった300なら何も問題ない ただ、vectorにはポインタを詰め込むべき vectorはlistと違ってソート時にメモリを直接置換するから、構造体のサイズがそのままネックになる ポインタを詰めれば毎フレーム10000以上の要素をソートしても60fps余裕だよ
vectorの中身をポインタにして比較関数の中でポインタの先参照して比較って感じでいいのかな?
でも「毎フレーム全ソート」って本当に必要? 弾が作られた時にだけ適所にインサートすればいんじゃない?
ソート方法によるけど、STLのマージソートは未ソートの要素が多いほど時間が掛かって、
ソート済の場合ほとんど処理を食わないから毎フレームソート処理してても大して問題ないはず
それに
>>185 は3D空間のオブジェクトのソートをしてるというから、カメラがちょっと動いただけでもソートの必要が出る
ソート関数にかけること自体がソートする必要があるかの判定になってると言ってもいい
>>183 ですが
とりあえずstlのソートでも十分速いと言うことなので安心した
勉強になりました
横。 vectorにポインタを格納するとして、本体はどこに置くの? もちろん状況次第だとは思うけど、別のvectorとか?
ヒープ
newしろ
固定で別の配列にするのが普通だと思う
なら実データをvectorに入れればいいじゃん
シーンの最初と最後に生成、破棄するならauto_ptr使って ポインタだけvectorで管理するのもありなんじゃないかと 思ったんだがどうだろうか
とりあえずauto_ptrとかいうゴミを捨てるんだ
よく考えたらauto_ptr使って元のポインタだけ管理しようとしたら newしてる関数抜けた瞬間deleteされるからダメかw
もうauto_ptr時代遅れなん?
200 :
名前は開発中のものです。 :2012/11/13(火) 23:01:15.07 ID:KobHHPjK
気にせず使ってください^^
auto_ptrってなんですか? どうしてunique_ptrを使わないんですか?
スコープを抜けるときに自動で閉じるファイルポインタとか 例外いつ投げても閉じてくれるので便利ですね? std::unique_ptr<FILE, decltype(&fclose)> fp(fopen("filename", "r"), fclose);
204 :
191 :2012/11/14(水) 00:25:26.13 ID:CmmzPOW9
>>192-194 最初から数が分かってるか、途中で増えるか等に応じて、
普通の配列、配列の動的確保、vectorあたりを使い分けるって感じかな?
vectorで実体まとめるとバッファのリサイズ発生した時にアドレス変わるんじゃない?
そんなの当たり前じゃん。
vectorで実体管理してソートのためにポインタのvector使ったら リサイズ発生した時点で参照変わるからちゃんと動かなくなるよね 最初に確保した分より増えないなら大丈夫だろうけど これ発生したら原因特定めんどくさそう
あー、それもそうか。失敬
>>207 っていうか「Vectorで実体管理」がそもそも意味不明。
ポインタで管理してるならそれだけでいいじゃん。
確かにvectorにポインタいれときゃそれでdelete出来るな 自分でちゃんとdeleteするならそれで十分か
newしたポインタはとりあえずstd::unique_ptrかstd::shared_ptrに入れるべき deleteなんて自分で書いたら負けだぞ デストラクタもハンドル管理クラスみたいなの以外では自分で書いたら負け
それは一般レベルの場合な 我々のように国家機密レベルでやってる場合は違う
何に負けるんだよ 見えない敵と戦う労力こそが一番の無駄
見えない敵というとメモリリークですね まあ、お遊びプログラムならすぐに終了されるので リークしても問題ないのかもしれませんが
shared_ptrはvectorに入れても大丈夫なのか vector<shared_ptr<クラス>>でやっときゃ勝手に消えてくれそうだな
>>211 十行くらいのブロックで、かつ外に出すつもりもないならnew/deleteで書いちゃうなあ
リークするのはお前の脳みそだけにしておけ
うんまぁお前らも一番実感してると思うけど、自分のルールの一貫性を保つことが一番大事だからな もちろん柔軟に対応するのも大事だし柔軟に対応できるような構造にしておくことはもっと大事だが
>>216 ブロックの外に出さないならローカル変数の方がよくない?
可変長だと無理かもしれんけど
生ポインタの場合 A* a = nullptr; B* b = nullptr; try { a = new A(); b = new B(); doSomething(a, b); }catch(...){ if (a) { delete a; } if (b) { delete b; } throw; } delete a; delete b; std::unique_ptrを使う場合 std::unique_ptr<A> a(new A()); std::unique_ptr<B> b(new B()); doSomething(a.get(), b.get()); なぜわざわざ生ポインタを使おうとするのか、理解できない
生ポとは関係ないんだけど、例外処理ってしてる? tryは遅いらしいと何かでみたから基本投げっぱなしスープレックスなんだけど 実際どうなん?
投げっぱなしだとexeが落ちちゃうだろ…(Windowsなら
落ちなかったらバグったまま続いちゃうじゃん?
なんでC++11前提で話してるのか理解できない
C++11じゃないならboostを使えばよろしい
>>222 デバッグで例外が発生したら例外の原因箇所にチェック入れて防ぐように修正してる
基本は例外じゃなくて戻り値で成否を返すような感じ
スマートポインタの名前の長さは C++スタイルキャストを思い出す
ふと思ったんだが、ゲーム・アプリのプレイ期間中に、 同一スコープ内でnewして解放する局面ってあるか? つうか、プレイ期間中じゃなくても、同一スコープ内で newして解放する局面って思いつかないな。 同一スコープ内なら、非ポインタのオブジェクト変数で済ませる。
コンストラクタに引数必須とか?
>>229 変数定義に引数記述してもコンパイル通るよ。
class Test {
public:
Test(int arg);
:
};
int a = rand();
Test ins(a);
>>230 出来るんだ…
考えてみれば出来ない理由もないか
じゃあ
>>203 みたいにポインタ返すけど、後始末は呼び出し側がやらないといけない関数とかかな?
あとはスタックにデカイ領域作りたくないとか?意味があるかはわからんけど
>スタックにデカイ領域作りたくないとか これはあるかもね。 とは言っても具体的な局面が思い浮かばない・・・
スコープ抜けたら勝手に消えるだけがメリットじゃないだろう メンバ変数にしておけば親が死ぬとき勝手に死んでくれるし ていうかスマートポインタ使わないとコンストラクタで例外が発生した時どうするんだ
具体的にどんな例外を想定してるの?
なんでスマートポインタを使うのを躊躇うの? unique_ptrは自動的にdeleter呼んでくれる上に 性能的には生ポと同じコストで使えるんだぞ
なんかこの流れ前にも見たな 今話してるのはunique_ptr使うんだったら普通にautoで変数定義すればよくね? って所だと思うが
なんでC++11やboost前提で話してるのか理解できない
この板的には、まだまだ11前提とするには厳しいかなー?
新しいもの好きなのはいいけど自分がマイノリティなのに気づけよ
>>237 お前は何を言っているんだ
スマートポインタと型推定は全然違う話だぞ
>>239 STLすら厳しそうだ
なぜだか自作ライブラリのほうが優れてるとか勘違いする奴が多いんだよな
>>241 まず話の前提として
>>228 があってそもそもnewする必要なくね?という問題提起があるんすよ
あと型推定ってなんすか
autoには2種類あるから、そこですれ違ってるんじゃない?
ごめん、c++11のautoと勘違いさせたか 俺が言ったのはただの自動変数のことです
>>241 >STLすら厳しそうだ
>なぜだか自作ライブラリのほうが優れてるとか勘違いする奴が多いんだよな
いや、既存ライブラリを使わない病気のじゃなくw
スタックオーバーフローしないならnewする必要はないな でもスマートポインタの使い道ってそれだけじゃないよ? むしろクラスのメンバ変数にこそ使ってほしい デストラクタを自分で書くのはもうやめよう あと、C++11ではautoの意味が変わりました C#のvarみたいに変数の型を推定してくれるので STLのイテレータとか死にそうなくらい長い型名でも for(auto i = v.begin(), e = v.end(); i != e; ++i) { ... } こんな風に書けて超便利な機能です
STLは慣れるまでは内部でどういう処理してるのかわからなくて気持ち悪い部分はあったな
249 :
名前は開発中のものです。 :2012/11/15(木) 22:06:00.91 ID:AHySL0i4
内部のことなんて知らなくていいんだよ 使い方を知ってれば、低能でも使えるのがSTL だからこそ意味がある
コード書き間違えるとたまにSTL内部のコードに誘導される時があるよな 記述ミスったところでエラー検知してくれよと言いたくなる あと気になるのはゲームだからだろうな 静的プログラムなら負荷が発生するパターンなんてどうでもいいけど、 動的プログラムだとそこら辺完全に把握してないと非常に気になる
>>247 >むしろクラスのメンバ変数にこそ使ってほしい
なぜ自動変数ではダメなん?
絵柄と相まって小学生が好きそうなノリだなw
vector配列のvector配列をvector配列で管理する三次元配列って開放する時大本だけ開放しておけばおk?
vector<vector<vector<int> > > か? 実体さえ行方不明にならなければどうとでもなるが newしたものを格納してるならshared_ptrじゃないと危ないかもな
typedef shared_ptr<MapData> MapTip typedef vector<MapTip> Map1D typedef vector<Map1D> Map2D typedef vector<Map2D> Map3D
ポインタじゃなくて実体を格納するなら大丈夫なのか クラスのメンバとしてコンテナ使ってると混乱してくる
別にポインタを格納しても何の問題もねえよ混乱しすぎ Actor* actor = MapTip[0][4][6]; a->Draw(); みたいなアホな事してないなら何の問題もない
混乱してるのはそこじゃねーよ!
>>261 悪い、ちょっと想定がアレな上にアホな事コード(vectorのアドレス保存して云々が正しくアホなコード)も間違ってるというアレっぷり
実体なら問題はないが、個人的にはコピーコストが馬鹿みたいにかさむからshared_ptr推奨したいな
メンバのメンバのメンバの...みたいに順々にデストラクタは働くので、実際にユーザーが使用した型であるvector<vector<vector<T>>>をclearすれば、Tのデストラクタがちゃんとしてるならば処理される
所有権を共有する必要はないのでunique_ptrを使いたいけど ポリモーフィズムに対応してないという弱点のせいでshared_ptrにせざるをえない
ていうかunique_ptrってコピーしても大丈夫なん?
なんのゲーム作ってるのか誰も書かないではないか。
あれ、できるようになってる・・・? 前はva[1] = std::move(b);で怒られてた気がしたんだけど #include <memory> #include <vector> struct A { int val; A(int i):val(i){} }; struct B : public A { B(int i):A(i){} }; int main() { std::vector<std::unique_ptr<A>> va(2); std::unique_ptr<A> a(new A(1)); std::unique_ptr<B> b(new B(2)); va[0] = std::move(a); va[1] = std::move(b); for(auto& i : va) { printf("%d\n", i->val); } }
すみません 質問です 1次元配列で使用可能な要素を前に詰める関数を書きたいのですがどういう方針で行ったら良いでしょうか? 例えば TestArray[8]があって、その関数実行後に |○|○|×|×|○|×|○|×| ↓ |○|○|○|○|×|×|×|×| のようにしたいのです どなたか良いアイデアをお持ちの方よろしくお願いします。
普通にソートじゃだめなん?
安定じゃなくても良いなら for(;;) { 前から×を探す 後から○を探す swap 前と後ろが逆転したらbreak }
>>269 1フレームで10以上呼ぶつもりなので出来るだけ高速な処理をしたいんです。
値の大小が無いだけで、ソートのようなプログラムになることは理解できるんですが・・・。
間つめたいだけじゃないの 普通に先頭から見てってつめればいんじゃない
>>268 std::sort使って、比較関数だけ自前で書く
>>270 std::sortを薦めろや…
ソートだとO(nlogn)になるじゃん 間つめるだけならO(n)ですむ
今時ゲームにその程度の高速化必要か?
そもそもなんでそんなことになるかな 途中の要素を削除するときは末尾の要素とswapしてから削除すれば良いだけだろ
出てるのに加えて使用可能と不可能で別のスタックでも使えばいいとか、色んな方法が考えられるな
>>274 汎用のブツを使うべきだろ、高速化が必要な風にも見えんし
必要ならその時点で書きなおせばいい
>>272 さんの言う通り普通に前から詰めます。ありがとうございました。
パフォーマンスを気にしたら、その分ゲームが完成から遠ざかる気がする 「できるだけ速く」ではなく、 「aaの環境でbbくらい時間がかかるが、ccくらいの時間にしたい」 が明確になるまでは、パフォーマンス気にしないほうがいんじゃね もちろん遅すぎて論外なことをやらない、って前提ありきだけど
昔はSLGを遊ぶ場合、敵の思考モードに入るとそれだけで数分かかったものだよ
数分?
・・・思考中デス・・・ 今じゃパターン総当りでもまったく気にならないからなー いい時代になったもんだ
処理ごとの時間を測れるライブラリみたいのつくっておけばいいのに。 そうすれば、 遅くなりそうなところが、実際は、別のところがネックだったってのが わかるし、変に悩まなくてすむ。
普通に計測プログラム用意したり、処理の途中に時間計測して個別に比較したりするんじゃダメなん
プロファイラぐらい使えよ
俺のプロファイリングによるとこのスレの住人は10代から20代、もしくは30代から40代、50以上の年齢の男性あるいは女性 プログラミング自体には精通しておらず、文法を覚えている程度の初心者と思われるが、必ずしもそうとは言えない
最近は「素人が○○することは考えにくい」って言うんじゃないのか
何らかの形でディレクトリのパスが入ることはあるだろうけど ストレージの種類までは記録されたりせんよ CやDじゃないから、ぐらいの根拠だろう
>>288 自分でコンパイル後のバイナリ確認してみ?
パスは入ることもあるよ。
気になるならバイナリエディタ辺りで消せばいい。
動作に問題はない。
龍神録の館ですら説明してるし
ボタンのクラス作ったんだけど class ButtonにDraw()関数にboolの戻り値つけて押されているか押されてないか判定するのってあり?
混乱するのでナシ 自分でちゃんと把握できるのなら挙動がすべてなのでどう書いてもいいが
ありがとう。ボタンクラスが、出来た! class Button{ POINT CoordUL,CoordDR;//右上、左上座標。 int m_nONButtonTexture;//押された時のテクスチャ番号 int m_nOFFButtonTexture;//押されてない時のテクスチャ番号 XMMATRIX m_Transform;//変形行列 public: void Draw();//画面上に描画。 //コンストラクタ。 Button::Button(int ulX,int ulY,int drX,int drY, int nONButtonTexture,int nOFFButtonTexture); //押されているかどうか。 bool PushCheck(int nMousePosX,int nMouseY); };
C++では多少の粗は速度でカバーする!
まあ適当に作ってもそれなりに速度でるもんな コードに時間かけるよりバグ出さないような 設計、書き方に気を付けた方が幸せになれる jsでブラウザゲームとか作ってみたら遅すぎて泣けてくる
最近の女子小学生はブラウザゲームとか作るのか
遅すぎると逆に萌えるなそれは。
ふええ、こんなにいっぱいしょりできないよお
>>267 これ見てて思ったんだけど、
struct A と struct Bはそれぞれ非仮想の暗黙のデストラクタを持つじゃない。
すると std::vector<std::unique_ptr<A>> va(2) が破棄されるときには Aのデストラクタが呼ばれるよね。
#include <iostream>
#include <memory>
#include <utility>
struct A{
int val;
A(int i):val(i){};
};
struct C{ int dummy; };
struct B : private C,public A { // 多重継承を用いて vtbl の計算を複雑にする。
B(int i):A(i),C(){};
};
int main(int,char*[]){
std::unique_ptr<B> b( new B(10) );
std::cout << "\(^-^)/" << b->val << std::endl;
std::unique_ptr<A> a(nullptr);
a = std::move( b );
return 0;
}
(これは、わざと落ちるようstruct Cを入れて多重継承してみたんだけど、
問題はBのデストラクタは走らないよの部分)
暗黙のデストラクタって気にする?
暗黙のデストラクタって気にする?じゃ意味がつたわんないな。 多分 struct Aの定義は、割と普通にやるとおもう。 じゃあ Bを書いた時点でAを public 継承してるけどAには仮想のデストラクタが用意してないから、 B*をA*にキャストして、それをdelete したらこけるじゃん Aに仮想デストラクタを用意するように お願いするかAの継承をあきらめてメンバで持つようにするか B*を A* にキャストして、delete するのはだめよとココロの中でお願いするか選択肢が出てくると思うんだ。 main 書いてる最中も std::move の時点で、struct Aのデストラクタは、非仮想だから、 unique_ptr<A> の破棄時にstruct Bのデストラクタが呼ばれないなと気がつかないといけない と思うんだけど、正直最初、自分は全部スルーしてた。 暗黙のデストラクタは非仮想であることにみんなどのあたりで気がつくように訓練してる?
継承元になるクラスにはvirtualなデストラクタを付ける、を習慣にするしか…
C++ではAが継承を想定しないなら Aを継承しないのがふつうじゃん? トラブルを避けるためにメンバに持つ。 暗黙のデストラクタが非仮想なのはあたりまえじゃん? 訓練してるってたんに知識の問題のような。
常に全てにvirtual付けてりゃいいんじゃね 最適化の段階で外していけばいいよ
305 :
名前は開発中のものです。 :2012/11/21(水) 02:32:47.54 ID:O0QHrPFm
javaかよw
javaみたいにクラスの継承禁止って出来ないの? と思って調べたらc++11からfinal追加されたのね
小学生の息子にアクションゲームを作ってる所だけど、背景とか音楽が難しいー。誰かファミコンぽいやつ作れる人いないかな。
とりあえずプログラムでウィンドウを画面に出す ↓ 画像を読み込んでウィンドウに表示させる ↓ キー入力を受け付ける処理を作る ↓ キー入力で画像の表示位置を変えたりアニメーションさせたりする ↓ 画像表示のパターンを増やす ↓ 完成
>308 ありがとう。 一応、横スクロール、プレイヤー移動、弾発射まではできてて、今から敵とかダメージ判定とかやるつもり。音楽ないとさみしいなーとか、背景もっと森とかしたいなーとかおもってるけど、雲とかがせいぜいで、、、
ファミコン風背景なんざペイントでグリグリでいいんじゃないの?
何が知ったかなんだよw
>>307 えーと、質問の意味が分らないんだが。
絵や音楽を作るのが難しいと言ってるのか。
プログラムの話しどっちだ?
文体から前者にとれるんだが。前者ならスレ違い。
「風」って言ってるから俺は素材だと理解したわ 風でいいならスプライトや和音の仕様をプログラムで再現する意味はないし
ファミコンはドット絵だからペイントで描くようなもんじゃないだろう
>>315 ルーペで拡大して描くんだろwしらんけどw
ペイントでドット絵描いてる人は今も多いぞ ドット絵なんてアンチエイリアス掛からないツールなら問題ないしな それほどクオリティを求めないファミコン風なら、アンチエイリアスもかけないしペイントで十分
>313 前者です。スレ違いみたいでした。すみません。 背景が難しいていったのはマップチップ作ってそれをループで並べてるんですけど、樹木とか遺跡っぽいのが作るの難しくて。 子供が寝たから今からまた作ります。
>319 ありがとうございます! 曲のほうはこの板の別スレで、リクエストできるスレがあったので、そちらにレスしてみました。 ドット絵は後で調べてみます。 今は、穴に落ちた時やライフゼロのときのゲームオーバーの判定実装してます。
ファミコンっぽくしたいなら、解像度を荒くする、色数を8色以下にする、マップチップのサイズを8*8にする、くらいじゃないのかな。
>>320 ドット絵なら素材じゃだめなんか?
素材サイト回れば一通りそろいそうだが。
>322 前にマップチップで探してみたんですけどRPG 用ぽいのが多くて、とりあえず探すのやめてました。
マウス押された時呼ばれるコールバック関数があるのだけど、 メインループの関数内の処理によってコールバックの内容も変えたい。 どういう設計すればいいの?
コールバック関数を設定しなおすとかすればいいんじゃね?
int f; main() { f=0; f=1; f=2; } コールバック(int f) { switch(f) } こんなんでいいんじゃないの
>>326 やっぱりそうかー。
fに当たる変数はグローバル変数で取ってるから受け渡しは必要ないんだけどやっぱりそうなるか。
main()で配列に関数ポインタ設定して、コールバックのほうで設定されている関数ポインタ配列から自動的に呼び出しとか面倒なこと考えてた。
ありがとう。
敵がマップスクロールに引っ張られてくる、、 実装の仕方がまずいのかなー。プレイヤーはマップの真ん中の座標にきたらマップの描画位置をずらすようにしてる所が悪いんだろうか。
言ってる意味がわからない。
画面が右にスクロールすると、左に進んでた敵の速度が遅くなってしまう。
大きく分けて、2つの実装方法があると思う。 例えば毎フレーム5ドットずつマップスクロールすると仮定した場合、 (1)スクリーン座標 プレイヤーキャラや敵キャラの位置を、画面上の座標として保持する方式。 「カメラ」は固定のまま、「舞台」が移り変わるイメージ。演劇みたいな。 背景はスクロールするが、実質的に固定画面ゲーと同じようなデザインなゲーム向きだろうか。例えばシューティングゲーム等。 プレイヤーキャラ: プレイヤーが操作しなければ座標は変更されない。 敵キャラ: 通常の動作(前進や停止など)に加えて、毎フレーム5ドットずつ加算される。 背景: 毎フレーム5ドットずつ加算される。 カメラ: 動かさない。 (2)ワールド座標 プレイヤーキャラや敵キャラの位置を、マップ全体から見た座標として保持する方式。 「カメラ」が移動して、マップ上の各オブジェクトを映しだす。TVのマラソン中継や競馬中継みたいな。 よって、自動スクロールの場合、プレイヤーが操作しなければプレイヤーキャラも画面外に消えてしまう。 画面上に表示される位置は、(マップ上の座標)-(カメラ座標)で求められる。 広いマップを探索するようなゲーム、スクロールのタイミングや速度がプレイヤーの操作で変わるゲーム向きか。マリオ等。 プレイヤーキャラ: プレイヤーが操作しなければ座標は変更されない。 敵キャラ: 通常の動作(前進や停止など)による変更。 背景: 動かさない。 カメラ: 毎フレーム5ドットずつ加算される。 ……みたいな感じ。
やりたいのは(2)のほうで、マリオとかみたいにプレイヤーが画面中央より左右に進もうとしたら、画面スクロールしようとしてます。 >331の内容見て、また考えてみます。
なら、次の順番で試してみるといいかもしれない。 各オブジェクトを表示するときは、(マップ上の座標)-(カメラ座標)に表示すること。 i. カメラを固定してキャラを動かす。 ii. プレイヤーの操作とは関係なく、カメラが自動的に右方向へスクロールするようにする。 iii. プレイヤーキャラが常に画面の中央に表示されるようにカメラを動かす。 iv. プレイヤーキャラがマップの端に居るときは、カメラが動かないようにする。
スクロールしたら敵ずれるって、スクロールした分敵の座標移動するの忘れてるだけじゃないのか そんな単純な話ではないのか?
>>334 懐かしい! この板が発祥のゲームなんだよな。
>>335 敵を移動するんじゃなくて、カメラを移動するのが王道。
ゲーム内のキャラクターはすべてワールド座標で処理すべし。
>>337 どっちにしろ描画するときに座標変換は必要だし
カメラ移動分の座標さっぴいてやらないとずれるし
パラメータをどう持つかはともかく、処理は必要だし
>>338 カメラ座標変換マトリックスに任せておけ
>>338 描画モジュールとそれ以外のモジュールがゴチャッてなければそこで不整合は起きないだろ
このスレってこういう初心者っぽい質問があるかと思えばたまに異次元みたいなワケわからない話が始まるし 距離感が掴みにくいな
STLのアルゴリズムを使え使えって本に書いてあったから使って見てるけどコンパイルエラーを変なところに飛ばしやがってむかつく
STLのコンパイルエラーメッセージって分かり肉いよね
>>342 中身完全把握しとけって事だよ
言わせんな恥ずかしい
まあ現実的に考えても最低限使い方だけでも完全把握してないとデバッグすら出来ない
なんとなくで使ってるといつか痛い目を見る…っていうか今見てるのか
初心者こそSTL使えという奴もいればこういう奴も居る 困ったもんだな
配列の代わりに使うくらいなら問題ないんだろうけどな
>>344 いや。
実際、STLの配列絡みのエラーの場合、エラーメッセージでなく、
むしろ自分の作業過程を思い出して、
配列やメモリを扱うロジックに思慮不足が無かったかを見直さないと、
訂正すべき個所をなかなか特定できない場合が多いぞ。
他人のコードをハックするには、当然センスが必要になってくるってことさ。
俺は、なるべく難しい問題を、なるべく自分でフルスクラッチすることが上達の早道だと思うね。
勿論、チーム制作で、未熟者にフルスクラッチされたら、たまったもんじゃないがな。
>>337 それは状況によるんじゃないの?
俺は固定マップの時はそうやったけど、
ループマップで、自機周辺でしか当たり判定等の処理をしない、という時は敵を移動させるようにしたぞ。
>>333 今の処理の順序見直してみます。
今日とりあえずそこをなんとかして、形にしようと思ってます。
>>334 後でやってみます。ありがとうございます。
音楽はRetro Music Editorでやってみる?
>>350 インストールして適当に再生してみました。
ファミコンっぽい音が出るwww
ゲームの基本的な流れが出来たら、こっちも触ってみようかな。
すみません。(マップ上の座標)-(カメラ座標)というのはどんなイメージになるんでしょうか。 今、 // マップを描く for( int i = 0 ; i < MAP_DRAW_HEIGHT ; i ++ ) { for( int j = 0 ; j < MAP_DRAW_WIDTH ; j ++ ) { DrawGraph(j * MAP_SIZE + (mapMoveCnt) , i * MAP_SIZE , map[Map1_Data[i][j]] , true); } } って感じでマップ描画してます(DXライブラリ使ってます) mapMoveCntっていうのがマップの描画位置をずらす為に使ってて、 プレイヤーが画面中央に居る且つ、左右に移動した時にmapMoveCntを加減算してました。 これでスクロールをしてたんですけど、カメラを移動するってことはマップを描画する位置をずらすってことでしょうか??
うーんと
そもそも、それ2Dのマップ表示のコード(それもチップ?)だよね?
となるとカメラなんて使ってないでしょ。
>>331 で言うと(1)スクリーン座標
悪いこと言わないから
>>334 のソースDLして研究してみ
ライブラリはSDLだけどDXLIBを2Dで使うならやることは同じだから。
>>352 だね。カメラが移動するってことは、見た目の位置がずれるってこと。
挙げられたソースだと、その mapMoveCnt がまさにカメラの座標に相当すると思う。
正確にいえば、そこに-1を掛けた値だけど。
まあ、単に減算するか、正負反転したものを加算するかだけの違いなので、やってることは同じ。
で、マップチップ以外のもの、「カメラ」が撮影する「舞台」上もの全てに、そのカメラ座標を減算する。
こうすれば、「カメラ」の位置に関わらず、各オブジェクトが画面上あるいは画面外を自由に動くことになる。
ここまで(>333の2番3番に相当)出来れば、あとはカメラをどう動かすかだけの話なので、
問題点をかなり絞り込めるはず。
>>353 あ、カメラって3Dでのことなんですね。すみません。
>>334 で書いてたのを今からDLしてソース見てみます。
>>353 擬似的な「カメラ」と、3Dにおけるカメラをごっちゃにしてる
357 :
356 :2012/11/23(金) 00:18:57.78 ID:GjI1Zcmz
失敬、擬似的というよりは概念としてのカメラと言ったほうが正しいな
>>355 まあ、がんばって、昨日のお子さんに作ってる人かね。
>>356 どっちでもいいよ。
カメラ固定なんだからあまりカメラのことは考えなくていいと思う。
DirectXやOpenGL直に打つなら話は違うけど。
DXLIBを2Dで使うんだし。その辺はDXLIBがくるんでるっしょ。
いやだから、何故3Dにおけるカメラの話を持ち出すのか
>>359 普通は概念だろうがなんだろうが
それをカメラって呼ばないしどうでもいい
いやカメラって呼ぶだろ
>>358 そうです。今、モナーアクションゲームのソース見てます。
今日はこれ見て理解するだけで終わっちゃいそう、、、。
また明日の夜頑張ります。こうして質問に答えてくれる人がいるだけでも
モチベーションが違うきがします。
>>354 さんもありがとうございます。
ワールド座標からスクリーン座標に変換するロジック → カメラ
キャラクターの位置を( X , Y )とする。(ワールド座標) カメラの位置を( CX , CY )とする。 そうすると表示する位置は( X - CX , Y - CY )となる。(スクリーン座標) カメラの位置が( 0 , 0 )の時はワールド座標どおりの位置に表示されるが、 カメラが右に1ずれる( 1 , 0 ) とキャラクターは1左にずれて表示される。 キャラもマップも同じようにしてあれば、カメラ次第でマップのどこでも自由に表示できるようになる。 って事だよね。
平行移動だけじゃなくて回転やスケーリングやせん断やもうなんでもできるよ!
移動、回転、拡縮は行列で出きるとして、せん断ってどういうロジックになるんだ?
普通に行列でできるよ! 基底ベクトルを直交させなければ良いだけだ! 1.0 0.1 0.0 0.0 1.0 0.0 0.0 0.0 1.0
「せん断」って何?
長方形が平行四辺形になるような変形のことだよ!
底の無いダンボールってのはわかりやすい例だよな
シアーの方が通じる気がする
カメラだの行列だの無かったころのゲームだから その方が理解しやすいよって言ってるだけだよ。 まあ、最初からカメラありきで学んだ人はむしろ理解し辛いのか?
>>364 ていうかさぁ。
>>352 のソースみてあげなよDXLIBのDrawGraphってそんな概念関係ないよ。
ただのスクリーン座標に絵を置いてるだけ。
>>360 呼ぶんじゃないの、マの概念なんてみんなバラバラだからね。
そう呼んでる人にはそっちが常識なんだよ。
マ系やプログラム系の板で同じことを言ってるのに
使ってる言葉が違って議論がループなんてザラ
この場合も多分、みんな言いたいことは同じなんだよ。
言葉が違うだけだと思うよ。
>>373 マリオみたいに広いマップを探索するようなゲームだと
スクリーン座標ベースの管理は面倒くさそうだけどなー。
実際、黎明期のPGがどういう考え方で組んでいたかどうかまでは知らないけど。
>>377 なるほど。理解したわ。ちょっと長文になるが。
俺のような古い頃を知ってるマに言わせると、昔のファミコンやスーパーファミコンの頃の
スーパーマリオのようなゲームの、ただのスクロールの実装にカメラとか言いだす方が違和感を感じるんだよ。
すまんな。
あえて、昔の言葉を使えばBG(バックグラウンド)とSpriteが分れば実装できるんだから。
↓DXLIBのこの例も同じようなもの
http://homepage2.nifty.com/natupaji/DxLib/dxprogram.html#N4 ファミコンなら
http://hp.vector.co.jp/authors/VA042397/nes/ppu.html こんな感じか?ちょっと違うけど。流石にネットにもその辺のテクニックは載ってないわ古過ぎてw
(説明し辛いな。文章じゃ無理だわ)
勘違いしないでほしいのは
今のDirectXやOpenGLの世界ではカメラがないと話しにならないのは知ってるよ。
その辺の3D,2Dゲームも作ってるしな。
関係ないが。
VRAMの定義で、それぞれのマが別々のVRAMの概念を言いだして
話がなんだかわからない方向に行ったのを思い出した。
一人は上記のBGやSPRITEのVRAM
一人はPC98やX68Kの頃のパソコンのVRAM
一人はテクスチャやフレームバッファやZバッファ等の載る今のVRAM
そりゃ、話がかみ合うわけがないw
何にしても、>352さんのゲームが完成することを祈るよ。お子さんの為にもな。
スクリーン座標とビュー座標と呼べば良かったのかな? と混ぜっかえしてみる
>>378 なるほど、だから>353の時点でスクリーン座標と言ってたのか。
内部的にはワールド座標ベースで考えて、それを表示用に落とすって考え方自体は
3D以前からあるようには思うけれどね。
スーパーマリオみたいな一方通行で逆進できないシステムならワールド座標はいらないかもね。
382 :
名前は開発中のものです。 :2012/11/23(金) 16:52:57.32 ID:X3Az5vp2
引き算するだけだからPCの性能とか関係ないよw
N88BASICですらビューポートの概念あるよ floatの場合無茶な拡大させると誤差の蓄積が問題になることがあるからその場合は原点近くで処理したいけど
>>382 ワールド座標はマッブが広大になるとメモリーを消費するから、昔のマシンだと厳しいだろ
メモリー1バイトは血の一滴に比例すると言われていた時代もあるし
>>384 ああ。
画面に映ってるかどうか関係なく処理できるメリットを活かしにくいとか、
画面内だけなら符合なし1バイトで座標を保持できるけど、全体を考えると2バイトくらい必要になるとか?
>>385 ああなるほど。
マッブはタイル表示するものだとばっかり考えていたから、その発想は無かったわ。
>>383 そんなもんあったっけ?ってぐぐったらあったようだなw
30年近く前でまったく覚えてないわ。
あの頃、アクションゲームっていうと機械語オンリーだったのもあるけど。
BASICねー。なつかしいけど。インタープリタで8,16BITじゃ遅すぎるもんな。
シミュレーションや くそ遅っそいRPGとかかね。
コンパイラもあったみただけど。使ったこともないわ。
あの頃のコンパイラの吐くコードなんて使いものにならなかったしw
お前らいったいいくつなんだよ…
0xを付けておきたいお年頃かな
現場とか経験したことないとビット積意識する列挙体くらいでしか0x表記したことないな
フラグ処理で0x表記しまくりですが? #defineで隠れてはいるケド
ピチピチの0x20歳です!
ゲーム作ってるなら色管理で0x表記はたまにやるはず
>>394 RGBマクロで0~255しか使わないって人も多いんじゃないかね
命令セットに乗算なんてありませんでしたが、何か?
画面スクロール上手くいきました! プレイヤーも敵キャラも不自然な動作をしなくなりました。 回答していただいたみなさんのおかげです。ありがとうございます。 とりあえずまとも(?)に動くようになったから次は敵の出現タイミングとかを考えます。 プレイヤーがある座標まで来て、対象の敵が表示されていなかったら表示させるみたいな条件で やろうとしてます。うまいこといけばいいけどー。
399 :
ジュナイ :2012/11/24(土) 06:54:32.86 ID:QqV0oVKy
機能の拡張を目的に継承したらダメみたいなの読んだ記憶があるけど、未だに意味がわからない
>>317 もう出てた
機能の拡張なら継承しないで委譲しろって話だろ 継承の設計上の意味が曖昧になるし、遅くなるし、ミスも多くなるから class A : public Base{}; じゃなくて、class A{ Base base; };にしろっていう
オーバヘッドじゃね
403 :
ジュナイ :2012/11/24(土) 08:22:49.66 ID:W4j3QuI9
>>400 継承は完全にIs-aかHas-a関係の場合以外は使わない方がいいってことなのか?
継承の例とか見ると拡張してるようにしか見えないときがあるから疑問だったんだ
なんとなくだけど、わかった気がする
解説ありがとう
ケースバイケースだからどっちが正解ってもんじゃないぞ。 ただ最近の流行はinterfaceをよく使う。 C++だと単なるクラスだけど、Java/ C#をやると interfaceの概念が一番しっくりくる。
C++の場合、virtual関数でもどの関数が呼び出されるのかコンパイル時に分かる場合は virtualの性能ペナルティはないぞ
ソースがごちゃごちゃしてきた気がする、、、。 アイテム(武器とか回復)をマップの途中や、敵を倒した時にランダムで出す仕様にしようと 思っているけど、プレイヤーにも敵にもマップにも影響するからそれぞれにインスタンス生成 をしなければいけないのかなー。いい案がまだ思いつかない。 プレイヤーや敵キャラの移動処理は共通モジュールでやっているけど、それみたいに 共通化したい。
407 :
ジュナイ :2012/11/24(土) 12:20:37.64 ID:fxHMnqZg
>>404 俺の場合、CStringを自作して
それを継承してCStringExを作った
CStringExはCStringの検索機能を追加したもの
>>399 これを読んで問題あるんだなって思ったんだ
ケースバイケースなんだな
あんまり深く考えないことにするよ、ありがとう
>>407 安価の付け方が間違ってるのか何なのか、話の流れが読めない
>>406 それぞれにインスタント生成?なんで?
インスタントは一個でいいでしょ。
ItemManagerなクラス作ってそこで一括管理。
他のクラスはItemManagerへのポインタだけ持ってればいい。
インスタント……?
というか個々にインスタンス生成するのは、よくある手法だよな?
**Managerって命名するのやめろ。マジで。 いやしてもいいけどすすめんな。
413 :
ジュナイ :2012/11/25(日) 05:25:23.73 ID:hEk/IMrv
>>408 >>407 ×399のアンカー
○機能の拡張を目的に継承したらダメ
ふむ、アンカーにしない方がよかったな
ああ、そういうことか。 自分のレスを読んで問題に気づいた、と読めて何が何だか分からんかった
インスタンス作らなかったらどこにパラメータ置いとくんだ?
>>415 機能を曖昧にするのでアンチパターンとされている
>>417 ちなみにそれって出典どこなの?
前に同じような話しあったときにネットで探したんだけど見つけられなかった
個人で開発してるなら自分が分かる名前なら問題ないだろう
>>418 somethingmanagerでググれ
>>419 何をするかわかるなら明確な名前付けが可能なはずで、
それができないなら設計ミスである可能性が高い。
オブジェクト指向は難しいよな 俺はステータスクラスを作る際に能力項目の入った構造体みたいな感じにしか考えてなかったんだが 能力項目はそれぞれクラスとしてインターフェイスから継承させておいて それをmapに型識別子と一緒にプッシュしておけとかなんとか 極めだすとスタート地点がわからなくなるわ
なんとかManageって名前は即ダメとかいう思考停止はどうかと思うがなあ ていうかCharacterクラスとか完全にそのアンチパターンに適合してるわ
面倒くさいときに1,2,3とかExとか付けて終わりとか平気でやるよ?
Win32APIじゃねぇんだから
英語できない人間がほとんどなんだから、明確な英語名がでてこないのが普通だろ。 難しい単語を使うと読めなくなるし。
ぶっちゃけローマ字でやるのが一番効率イイと思うんだよね 外人が混じってるんじゃないなら
ローマ字で名前付けると長くなりがち そしてなによりカッコ悪いという欠点がある
Zittai *zittai = ZittaiKouzyou::Tukuridasu(ZittaiBanngou banngou);
またそうやって極端な例を出す…
xxxManagerって命名はゲーム会社で普通に使うよ。
xxxManagerて設計した時点で設計を疑えという人も居てだな
ただの名前じゃん。 中身は大抵リスト管理。
変なローマ字使うぐらいなら漢字やひらがな使えよ
自作のクラスManagerだらけだわ
漢字やひらがな使えなかった頃をひきずってるんだよ
漢字や平仮名なんて使えんし使わん
defineでは日本語使えるから使う
例えば、リソースをコンテナで管理するようなクラスで、ファイルパス渡すと ポインタ返すようなメソッド持ったヤツはなんて名前つける?
リソースをそれだけで管理するなら、単純にリソースマネージャーあたりにする メソッドの名前はget_ptr_from_pathとか
メソッド名は頭文字大文字式で統一しましょう。 GetPtrFromPath
俺はライブラリ的に使いまわせる関数は頭大文字、 それ以外のローカルだったりクラスのメンバだったりする関数は小文字で統一してるわ
**Managerって設計ミスだったのか。 マップマネージャとユニットマネージャの2クラスをメインに進めていたがこれもダメなのか・・・。 画面操作もマップマネージャとユニットマネージャに振り分けてやらせてるし・・。 ただこれはユーザーインタフェースクラスを新しく作ってそっちに集約しようか考え中だが。
あっちもManager、こっちもManager、だとちょっとマヌケっぽいというただの感想とか、 世の中のクラスの半分くらいは、何かをマネージしてるもんじゃね?っていうツッコミとか、 複数のインスタンスを集めたものなら、collectionって単語があるよっていう指摘とjか、 使う側から見た場合、中身なんてどうでもいいんだから、外側をシンプルな名前にしろよっていうクレームとか、 そのへん色々。 ぶっちゃけ本人が困ってないならどうでもいい。
偉い人が言ってるからとかで真に受けてたらダメだよな Linusとか超アホなこと言ってるし
鵜呑みは危険だが常に最新の情報や環境に気を使うのは大事だろうな 物事が時間の流れで最適化されていくってのは自然の摂理のはずだ というか議論できるレベルの人達って情報どこで集めてる? ネットで情報集めてるとハンガリアン記法は減ってきたけどクラス名の先頭に C付けてるのが未だに散見してどうすりゃいいのかわからなくなってきた
コンソールからviでコーディングしてる人たちにとってはハンガリアンも有用だし? 現存するかは知らんけど
templateで型名とかワケワカメになるのにハンガリアンが使えるのか?
TwitterでC++erフォローするとか…
>>447 Tのプレフィックスはtでいいんでない
使うときはVector<int>ならiVecとか?
どうせゼロから作り直すんだし、 一発目は思いつくままに継承多態、俺式命名でいいんじゃね 1日の時間が重要って場合ならともかく・・・
システムハンガリアンは誰もが否定するところだろうが、 アプリケーションハンガリアンは重要でしょ。 型で切り替えずに、意味レベルで同じ水準で扱う値に同じ接頭辞を付ける。 スクリーン座標にはs、ウィンドウ座標にはwをつける等、 同じ型でも混同しちゃいけないものを混同せずに済むよ。
>>451 普通に名前つけてたら自然にそうなっちゃう気がするんだけどな
まあ、クラスやら構造体でラップしちゃうからプレフィックスって
いうより変数名そのもので区別できるんだけど
>>445 最新の情報に敏感な人って周りの需要が見えてない人ばっかりな印象なんだが
俺の周りのプログラマはみんなそう
>>422 思考停止なんて言い訳するから糞設計になるんだよ
>>453 geekと職業プログラマの最大の違いはそこだろうな
geekは技術力はあるんだが、自分の知識が絶対正しいと思いがちでやたら新しいことやろうとする
職業プログラマは言われたことやるだけだが、その分要求はちゃんと満たす
それは職業プログラマを持ち上げすぎ 出来る人と出来ない人の違いではあるけど
>>455 は極論だけど、仕事に対するスタンスとしてはそんな感じでしょ
サーバ運用でもただのgeekはサーバモンキーとか言われるし
まあ積極的に情報仕入れてそれを活用できる人ってのはまれなんじゃないかな
仕入れた知識すぐ使いたがるモンキーか頭の中化石になってるおっさんのようなのが大半じゃないの
っていうかそれ以外はマなんてやってないで管理職なるでしょ
>>443 > あっちもManager、こっちもManager、だとちょっとマヌケっぽいというただの感想とか、
> そのへん色々。
> ぶっちゃけ本人が困ってないならどうでもいい。
勝手に問題を矮小化してどうでもいいとか。頭が悪すぎる。
"本人が困ってなければどうでもいい"の本人のと、"本人を困らせるコードを推奨するな"の本人は違うだろ。
困ってない本人がこれから困るかもしれない他人に腐った手法を押し付けてる。
うぜぇw
頭のいい人に聞きたいのだが PS3とかWiiとか3DSのゲームソフトを ゲーム会社で制作している人って どうやって各ハードでのゲームプログラミング技術を習得したのだろう ゲーム会社に入社してからソニーか任天堂と契約を結んでいるゲーム会社しか知らない 各ハードの秘密の開発技術などを習得させているのだろうか C言語とかC++とかのプログラム言語でプログラムを組めば ゲームを作るぐらいのことは僕でも知ってるが 各ハード別の開発技術って、それだけの知識だけでは足りないような気がする
例えば3DS用ゲームソフトを3Dモードにすれば 飛び出したような映像表現が可能ですが ああいう技術って単にC言語やC++を習得しただけでは開発出来ないような気がします
↑ 質問なのか、独り言なの意味がわかりません ================ デジタルハリウッド@偏差値45 出席番号5 好きなゲーム東方、格ゲー、地球防衛軍
ハード毎にライブラリが提供されるから、それでゲームを作ることになる ライブラリの仕様を迅速に勉強し身につけられるのもゲームプログラマに必須の条件 例えば、C++やろうと思い立った次の日には基本的なテストプログラムは組めるくらいの習得力がある人じゃないと無理
Unity使えます Javascript使えます 昔からUnityでゲームやってます Unity勉強会にも参加しております Unity関連の本全部持ってます 数学と関数型言語と論理力を磨いています ================ デジタルハリウッド@偏差値45 出席番号5 好きなゲーム東方、格ゲー、地球防衛軍 使える言語 Javascript,C++,PHP 使えるゲームエンジン Unity
>>463 では、例えば任天堂からWii Uが発売されたら
ゲーム会社のプログラマーたちは新しいハードが出る度に
新しい技術を必死に勉強されて習得されてるわけですね
しかも、その技術用の解説本もない中・・・
ホントに頭が下がる思いです
ところで一つ伺いたいのですが WindowsパソコンでPS3並の高画質のHDゲームを開発して それを同人ゲームとして遊んでもらえるようにすることは可能でしょうか? 昔のPCと違って今のPCは、64bit版OSも出てるし グラフィックボードもいいのが出てるから PS3並のゲームを制作してプレイしてもらうことも可能だと思いたい
>>465 提供されたライブラリを理解するのは別に難しくないが、
たまにバグがあるんで、それを治すのに苦労する事はある。
次のアップデートまで待てないから、バグや不都合は
ガンガン治してくよ。
>>465 メーカー毎にapiの設計や命名に癖があるから
同一メーカーの一世代前のハードで経験のある人が中心になるかサポートに入るかする
サンプルも多少は提供される
だから本当に1からということはなかなか無いよ
>>466 PCでFF14とかラストレムナントとか出てるだろ
あとビット数は関係ない
だが、お前くらい無知だと人も付いてこないだろうし作るのは無理だ
発売から6年も経ったコンシューマー機のスペックに幻想を抱いている知能レベルだと、 はっきり言って無理だろうね。 公開されているデータシートすら確認する脳ミソすらないんだから。
インテリジェントシステムズが説明書付きのライブラリ送ってくるからそれみれば馬鹿でもゲーム作れるんだろ
Unityが主流です
市販レベルのゲーム個人作成するとか、性能以前に素材作れなくて挫折するだろ
素材は買えばいい。
>>469 > あとビット数は関係ない
え?そうなの?
昔、任天堂から64が出て話題になったから
bit数によって処理速度が速くなると思ってました
64bit版Windows8Proのパソコンなら4GB以上のメモリーが搭載できるから
10GBのメモリー搭載パソコン対応のWindowsゲームにすれば
処理能力が上がるものだとばかり
そんな大量のメモリなんに使うんだ pS3のメモリってvram含めても512MBじゃなかったか
un
今、2Dアクションゲームを作成していて、インスタンス生成をnewでしてますけど、 ゲームみたいに速度大事な場合はplacement newで生成した方がいいんでしょうか。 まだ短いステージしか作ってないから重くなったりしないけど 敵を増やしたらやっぱり重くなるのかなと思って。
偽装しているけどどう見てもスレ違いです
2Dの時点で重くなりようがないと思った
479だけどすまん、ありゃID:3CO8/3Q2宛だ。リロードしてなかった。
>>478 使わないと思うよ。速度(とメモリ制限)が厳しい時は、最初に必要数確保して使いまわしたり。
メモリのフラグメント化も避けられるし。
もっとも今時のWindows環境なら、ゲームのインスタンスくらいじゃ心配はいらないと思います。
>>480 2Dではよっぽど無茶したり、変な実装してなければ大丈夫なもんなんですか?
とりあえず修正せずに今のままでやってみます。ありがとうございます。
>>481 >使わないと思うよ。速度(とメモリ制限)が厳しい時は、最初に必要数確保して使いまわしたり。
>メモリのフラグメント化も避けられるし。
了解しましたー。今のままの感じでやってみます。ありがとうございました。
初期化するときに必要なメモリ全部確保しとくのが一番楽だよな 趣味で作るゲームは何よりも完成させることが大切だと思う
>>484 ゲーム機ならそれがいいけど、PCのメモリはほぼ無限だから
気にしなくていい。
プログラミングをしないでゲームつくれたらな〜っておもいませんか?
金があれば誰かにプログラミングさせてゲーム作ることもできるんだろうね
格闘ゲームの60FPSの理由をこたえよ
NTSC方式の垂直同期が60Hzだから。
59.94fpsだが・・・
59.94fpsとはどういうことでしょうか? わかりません fpsとはなんですか? よくわかりません
そんな事も分からないから偏差値が45なんだよ
最近は内部FPSが120の格ゲーも多いが
>>493 Unity使えますJavascript使えます
PHP使えます3Dsmaxつかえます
mayaつかえます
技術のない人に言われたくありません
それだけかよw
まあ、文章の書き方が変な時点で、頭が悪そうだというのは十二分に伝わってくる。
167 名前は開発中のものです。 [sage] 2012/11/30(金) 11:13:15.46 ID:MDTtwB01 [1/2]
>>162 デジタルハリウッドの低脳低学歴じゃ無理だ
消えろ
170 名前は開発中のものです。 [sage] 2012/11/30(金) 12:22:00.03 ID:MDTtwB01 [2/2]
>>169 デジタルハリウッドの低脳低学歴じゃ無理だ
消えろ
なにしたいんだこいつ
海外のゲームはマサエッチュー大学がつくるからすごいらしいんですが 日本のゲームがしょぼいのはなぜですか? 僕みたいなデジタルハリウッドしかいないからでしょうかおしえてください
"マサエッチュー大学" に一致する結果は見つかりませんでした
そのキス相手の雅恵さんって誰だよ。
マサエッチューとかww
越中ってすごいんやな
やってやるって
2Dアクションゲームなら300万で作ってやるぞ
結構アクションゲームっぽくなってきた気がするー。敵と当たったときのダメージ判定とか、 敵の出現条件がまだ考え中だけど。 ダメージ判定を共通関数でするかプレイヤークラスか敵クラスでさせるか悩む。
>>505 それグラフィックと音声の作成も含むの?
>>506 後者のどちらでやっても同じ結果になる、かつどちらか一方しか実行されないように
するのが基本なんじゃね?むしろどのポインタどういう風に共有させるか悩んでるわ
>後半、イメージエポック御影社長(左から2番目)を交えトークに拍車がかかります。 >会場からの質問「海外のFPSに日本のFPSが勝つにはどうすればいいと思いますか?」 >御影社長「うーん、海外のFPSはマサチューセッツ大学を首席で卒業したプログラマーとかが作っているので、それを超えるには根本的に開発スタイルを変えないとダメで・・・」 海外のゲームはマサチューセッツ大学がつくるからすごいらしいんですが 日本のゲームがしょぼいのはなぜですか? 僕たちみたいなデジタルハリウッドの低学歴しかいないからでしょうかおしえてください
まぁ東大の主席はゲーム業界にはこないだろうな
>>509 そういう、しょぼいしょぼくないと言う
偏差値相応の善悪二元論的発想はやめなされw
誰か釣りたいならゲハ板にでも行けば?
C++にも関係ないことだし。
海外のほうがゴミゲー率高いけどな 駄ゲーは日本で話題にすらならないから存在を知らないだけ 日本に居て洋ゲーのほうが良作多いなんていうのは、その程度のこともロジカルに考えられない馬鹿 印象に惑わされる奴は視点のぼやけたゲームしかつくれねーよ
映画の話だけど、邦画はなんで洋画に比べて面白くないかっつーと、つまらん映画はわざわざ海を渡ってこないからって話があったな ゲームも同じだよね
だからなに?海外がーとか日本がーより自分がーでしょw
>>513 悪いが全然答えになってないよ
面白くない理由は、つまらんからとか‥‥
さすがに理解力がなさすぎる
デジタルハリウッドにも最低限のモノを作る人間と、 FPSという用語を検索をする程度の脳味噌が無い奴とか色々いるだろう。 日本とかアメリカとかデジハリとかいう区分以前に、人間個人が駄目なら駄目。 クズはどこに行こうがクズ。
デジタルハリウッドが何でどうなんかは知らんが、少なくともFPS作ってるマサチューセッツ云々の奴は、AIの経路探索や動作モーションの自動平滑化とかのアルゴリズムを理解・実装できるやつなんだろ、きっと。 プログラミングできるだけの奴なら高専にもいるが、論文読んで実装できる奴は限られるって話。
>海外のFPSはマサチューセッツ大学を首席で卒業したプログラマーとかが作っている これ工科大学の方か?
ほんといい釣り堀だな。 Unityスレと同じような反応ワロタ
ゲ製板には、デジタルハリウッドの卒業生だらけだから 僕をたたく人はいない!!
>映画の話だけど、邦画はなんで洋画に比べて面白くないかっつーと、つまらん映画はわざわざ海を渡ってこないから 海外は沢山海を渡ってる 日本は少しですね 日本=ゴミが多い、海外には全然渡ってない 海外=ゴミが多い、海外に面白いゲームが沢山わたってる
Yahoo知恵袋を髣髴させる凄まじい天才が光臨してやがるなw 2chでこんな逸材を拝見する羽目になったのは何年ぶりかねぇ
ただの荒らしですがな
>>518 論文読んで実装する程度じゃダメだ
論文書かないが書けるレベルの新しい手法を自分で編み出すレベルじゃないと
>>525 そりゃそうだが、就職考えたらそんな時間もないし、能力持った奴居ないだろ。居たらそれこそ米国行っちゃうし。あっちじゃ給料4倍とかだぞ?
ゲームアルゴリズム系で博士論文とかイケる文化が日本にない上に、大学で研究した成果をゲーム会社が使って云々っていう文化もないのがキツい。
時間がないない言い訳するのは無能だけってばっちゃが言ってた
クサイスレですねほんと
すごいアルゴリズムや手法を編み出すのは就職してからに決まってんだろ 仕事があるから論文書く時間はねーが書けるくらいのネタは自分たちで編み出せないとダメだ 他人の論文を参考にするって言うのはゲーム発売の周期でいうと下手したら1作品遅れになる 論文が形になって出てくるのに1年とかかかるわけだし 著者のチームは色々ノウハウ持ってるわけだから相当先行されてることになるぞ まあでもゲームで重要なグラフィックス分野だと だいたいNVIDIAかAMDから出るので直接競合する形じゃないのはまだ救われてるな
欧米のゲームってそんなにすごいタイトルあったかな? 海外のゲームショーでも話題になってるゲームって ほとんど日本のタイトルなんじゃないかな? スト4とかモンハンとかFFシリーズとか 海外では任天堂のマリオ系のタイトルも人気があるらしいね ポケモンとかも人気あるか なぜか海外ではドラクエシリーズは人気ないらしいが 俺、日本人だし日本だけで人気でも構わないよ
League of Legendsがここ最近で成功したゲームらしいですね わたしはしりませんが わたしは格ゲーの配信とかよくみてますが なんかLoLが凄い人気らしいです Unityで格ゲーとTPSつくりたいです 低脳なのでしょぼいゲームしか作れません
>後半、イメージエポック御影社長(左から2番目)を交えトークに拍車がかかります。 >会場からの質問「海外のFPSに日本のFPSが勝つにはどうすればいいと思いますか?」 >御影社長「うーん、海外のFPSはマサチューセッツ大学を首席で卒業したプログラマーとかが作っているので、それを超えるには根本的に開発スタイルを変えないとダメで・・・」 結論はデジタルハリウッドみたいな低学歴じゃいいゲームはつくれないってことですね ありがとうございました
結論はデジハリにしか入れない程度の努力しかできない奴がまともなゲーム作れないってことだよ 才能でも学歴でもなく、ヤル気の差
>>529 Deferred Renderingは20年前の論文が元ネタだぞ。
お前らC/C++の話しろよ
デジタルハリウッドって本当にクズしかいねーのな
R&D担当するような人は大学から採用するだろう 専門学校は兵隊さんを生産するところだしそんなもんだ
デジハリは専門学校ですら無いんだが。
嵐の活動で評価されるとか不当評価にも程があるだろw
3Dゲームは攻撃に当たり判定持たせるのが面倒だな 武器モデルに判定付けるか、適当に座標でやるか迷う
やたらESPを要求する難読な文章を書く人も面倒だよ
文盲の方ですか
バカにするなぁ!! 夢をもってないやつは生きてる価値なし!!
叶える努力すらまともに出来てないのに何を
子供の頃から勉強でも何でもそつなくこなしてきた俺だが そんな俺が唯一、ものにすることが出来ずに挫折してしまったのが プログラミングだった これまで幾度となくプログラミングには挑戦してきたよ VBにC言語にC++等々・・・ だがいつも毎回、途中で飽きて投げ出してしまうんだよね C言語の入門書を購入して丸々一冊勉強してみたが 出来たことはウィンドウを表示させて文字を表示させて あと色々な計算をさせて・・・と だが俺が求めてることは、そんなつまんないことじゃなくて ゲーム制作なんだよね
必要なのはプログラミング能力じゃない 絶対にゲームを作り上げたいという熱意だ それさえあれば必要なことは調べていける
こういうのを見るといつも思うんだが、 ゲーム制作がしたいなら最初からゲーム制作を学べよと
根本的に、ゲームを作りたいという気持ち自体が貧弱だということが問題だということに気付くべき
RPGツクールでいいじゃん プログラミングなんて出来なくても面白いゲームは作れるっしょ
>>549 とりあえず、ノベルツールかRPGツクールのスクリプトでもやってみ?
ちやほやされながら1から10まで作りたいというのがヲタの理想 なお現実は
自分の世界に篭って浸ろうと思えない時点でそれオタクじゃないな 近年増えたオタクもどきのただの中途半端なゲーム好き
ちやほやされるに越した事は無いが、篭って浸るのって無茶苦茶楽しくね?
仕事やめて部屋に籠りたいとは常々思ってる
学生 「うわヒッキーwww だっせぇえええwwww」 社会人 「ひきこもり…あれはいいものだ…(遠い目)」
>後半、イメージエポック御影社長(左から2番目)を交えトークに拍車がかかります。 >会場からの質問「海外のFPSに日本のFPSが勝つにはどうすればいいと思いますか?」 >御影社長「うーん、海外のFPSはマサチューセッツ大学を首席で卒業したプログラマーとかが作っているので、それを超えるには根本的に開発スタイルを変えないとダメで・・・」 お前らUnityすら使えないクズには無理だろw あきらめろw
マジレスすると実際にUnityにさわる機会あるのなんてプログラマですらないスクリプタだけだよね
562 :
549 :2012/12/05(水) 01:18:51.09 ID:W0pApem4
>>562 頑張ってると思うよ
ただこれならツクールじゃなくて吉里吉里でも使ってノベルにしたほうがいいんじゃないかと思った
イメエポの社長の発言コピペされてるけど何が言いたかったんだろうなこれ
主席で卒業したプログラマー?FPSのプログラムなんぞ中卒ニートでも出来るだろう
演出や脚本って話ならハリウッド映画経験者とかいるので太刀打ち出来ないのは確かだろうけど
>>562 あんたゲ制で見た事あるなw
本気でプログラム勉強したいのなら人のコード読むのが一番早いと思う
id Softwareがゲームのソースいくつか公開してる
DOOM3 ソースとかで検索すれば出てくるよ
すぎなみたくやってどっかで聞いた名前だと思ったらkazukiやポナルポと呼ばれていた人じゃないか こんなところで見かけるとは
>後半、イメージエポック御影社長(左から2番目)を交えトークに拍車がかかります。 >会場からの質問「海外のFPSに日本のFPSが勝つにはどうすればいいと思いますか?」 >御影社長「うーん、海外のFPSはマサチューセッツ大学を首席で卒業したプログラマーとかが作っているので、それを超えるには根本的に開発スタイルを変えないとダメで・・・」 馬鹿には無理
プログラマーって仕様書通りに組むだけの単純作業だろ 誰が組んでも差はバグやロードが多いか少ないかだけでゲーム性には何も影響はない
>>567 その仕様書が「ここに来たら巨大ロボがガーッて現れて、
ドカンドカンって撃ってきて、ビューンってジャンプして
ガガガガって滑る感じにして」っていう
曖昧な口頭リクエストなのが現実。
>>568 そりゃ開発スタイル変えないとダメだなww
プログラマー関係ねぇ
一言にプログラマと言っても色々あるからな 社長が言ってるプログラマは作業者ってより 新しいアーキテクチャやアルゴリズム開発する 研究開発者の事だろうな どっちかって言うとプログラミング以前に 数学の知識が求められる
世の中いくつのゲームがロードとバグでゲーム性を破壊したか・・・
それゲーム性じゃなくて快適性とゲームバランスじゃね
574 :
549 :2012/12/05(水) 12:51:38.89 ID:W0pApem4
>>570 ゲーム会社でゲームを制作してるスタッフは
当然、全員がプログラマーではなくて
音楽だけを担当する人もいれば、鳥山明のようにキャラデザだけやる人もいる
そういう専門分野の人たちはいいとして
ストーリーとか企画とかアイディアだけを考えるスタッフは
プログラムは全く知らない素人だったりするのかな
それとも、そういうスタッフもある程度のプログラミングの知識は持っているものなのだろうか
>>568 ああ、何となく仕様書のイメージが浮かんできた
1枚の用紙に画面を見立てた箱枠が描かれていて
そこに大雑把なキャラや矢印とかが描かれていて、
「こっちにこう移動してきて、そのあと、こんな動きでこんな動作をさせたい」
みたいなことが描かれてるわけですねw
でも、そういう風に書かないと作りたいイメージって伝わらないような気がしますね
昔から良作を生み出してるプランナーはほぼ全員プログラム書ける そういう人は、子供の頃からアイデアを形にする為に色んな創作をしてきたから何でも器用にこなす 今では、ゲーム開発スタッフのうち、優秀なプログラマーが企画に抜擢される場合が多いし
>後半、イメージエポック御影社長(左から2番目)を交えトークに拍車がかかります。 >会場からの質問「海外のFPSに日本のFPSが勝つにはどうすればいいと思いますか?」 >御影社長「うーん、海外のFPSはマサチューセッツ大学を首席で卒業したプログラマーとかが作っているので、それを超えるには根本的に開発スタイルを変えないとダメで・・・」 マサチュッセーツ大学のがんばり>>>馬鹿のがんばり
そもそも開発スタイルでなんとかなるなら学歴とか誰も求めねーっていう
低学歴の即レス(笑) >後半、イメージエポック御影社長(左から2番目)を交えトークに拍車がかかります。 >会場からの質問「海外のFPSに日本のFPSが勝つにはどうすればいいと思いますか?」 >御影社長「うーん、海外のFPSはマサチューセッツ大学を首席で卒業したプログラマーとかが作っているので、それを超えるには根本的に開発スタイルを変えないとダメで・・・」
イメージエポックってどの程度の会社なんだよとググろうとしたらご丁寧にも関連検索ワードにクソゲーって出てきたよ
ところで日本のFPSってどんなんあるの? TPS風のアクションゲームならいっぱいあるけど、FPSってあんまりないよね? 64の007位しか知らんわ
>>545 まぁ、例えば
>>543 が何を迷ってるのか理解できる?
行間を推測したり、表現力の無さを補間すると色々な
可能性が想起できるけど、会話にはならず脳トレで終わる
直接に対面してれば色々聞けるけど、こういうスレだと
それはできないし、結局どういう反応を期待してるのか
謎だよね。独り言なのかな、とは思うけど
スレ違いだ馬鹿ども
>>583 なんで日本語のwikiあるのにわざわざ海外のヤツはるの?
しかし、どんなのあるかもわからんようなもんを膨大な開発費で作られたゲームと比較して
「勝つにはどうしたらいいか」ってそもそも議論としてなりたたないんじゃね
>>584 どうもこの間から流れがおかしい
変なのが住み着いたか
デジタルハリウッドとポナルポという二大キチガイが居る時点で
低学歴へ >後半、イメージエポック御影社長(左から2番目)を交えトークに拍車がかかります。 >会場からの質問「海外のFPSに日本のFPSが勝つにはどうすればいいと思いますか?」 >御影社長「うーん、海外のFPSはマサチューセッツ大学を首席で卒業したプログラマーとかが作っているので、それを超えるには根本的に開発スタイルを変えないとダメで・・・」
だから日本のFPSってなによ? 比較になってねーだろって
ゲーム制作で関数ポインタ使ってます? 僕はあれのメリットが理解しきれずとりあえず使わなくて進めてます。 例えば複数の敵や弾があった場合、名前や引数が同じだけど内容が異なる処理をループで実装したい場合に使ってますか? 実際の使用例とか聞いてみたいです。
>>592 タスクシステム
c++なら関数ポインタ使うような所はポリモーフィズムで対応するんじゃない
>>592 ゲーム系ツールでは使ってるけど、ゲーム制作では使ってないなあ。
アドベンチャーゲームとかでイベントのスクリプトを実装しようとしているのだけど、 例えばmessage('hogehoge')でメッセージを表示するスクリプトだとすると実装は、 1 事前にmessage()関数を用意してスクリプトを直接評価してその関数を呼び出す 2 識別子(message)を取り出して文字列マッチングで処理する どちらの方法が良いだろう
>>592 マルチスレッドのために別スレッドで実行する関数のポインタを渡す
>>595 自作のスクリプト言語?
スクリプト内で色々定義出来るようにするなら後者の方が楽
しないなら前者の方が楽で高速
個人的な意見を言うなら組み込みスクリプト使った方が楽
luaを組み込んで思うように処理速度出なくて死ね
>>592 個人的にはオブジェクト配列はポインタ使ったほうが管理しやすいな。
observerパターンなんかもポインタ使う。
蛇足ながら、無理に使えとは言わんけど、
デザインパターンは一通り目を通して損はしないと思う。
コールバックで関数ポインタ必要でしょ。 Windowsでプログラミングすれば嫌でも必要になるはずだが?
>>595 ごめん質問の意味を曲解してたかも
スクリプトの構文解析をどうするかって話?
>>598 jit版使え
継承階層深くなければv8にも勝る速度を稼げる
>>600 MFCならカプセル化されてるし、そうでなくとも、
関数ポインタなんか意識せずとも書けるでしょ。
VC++はご丁寧にテンプレート吐いてくれるし。
無用なスクリプト化を思い留まる冷静な判断力、って初心者には軽視されがちだよね 技巧に走るのが目的のお勉強趣味なら好きにすればいいけど
今はインターフェースっぽいの使って配列に子クラスのインスタンス詰めて処理してます。 これがポリモーフィズムになるのかな? とりあえず関数ポインタは置いといてやってみます。 関係ないけど昨日循環参照になってしまったみたいでずっとコンパイルできなかった、、
StateMachineのデザパタで必要じゃない?>関数ポインタ ゲームにStateMachineは必須でしょ。
>>607 どの部分に状態遷移を使うか、あるいはどう実装するか次第じゃない?
例えば、タイトル画面 → プレイ画面 → エンディング画面 のような遷移なら、
それぞれの画面ごとにクラス化(共通の親を持つ)して、State/Strategyパターンでもいいかもしれない。
状態遷移表を用意して一括管理するなら、関数ポインタの方が楽かもしれない。
>>608 >有用なスクリプト
横だが、やっぱ作業分担の時じゃね
スクリプトの利点は ・コンパイル不要 ・習得が容易 スクリプトの実装はプログラミングスキルそんなに要らないから分担しやすい 頻繁に調整のかかる部分の実装に使うと効率的に開発出来る 一人で作ってる小さなプログラムだとあんまり役に立たんかもな
StateMachineって初めて聞いた Stateとは違うん?
デザインパターンはsingletonしか覚えてせんでした。 stateパターンも空いた時間に覚えようかな。 さっきちらっと解説ページみたけどじっくりみないと理解できそうになかった。
ステートパターンなんか使わなくてもこれで十分 シーン遷移如きで開発が頓挫するようなことあるかと enum { TITLE, PLAY, ENDING, }; int main(void) { int state = TITLE; switch(state) { case TITLE: title(); break; case PLAY: play(); break; case ENDING: ed(); break; } }
>>614 それじゃステートが変わる瞬間のコーディングがやっかい。
やっぱりStateEnter, StateUpdate, StateExitが欲しくなる。
デザパタが何故存在するのかもう一度良く考えてみて。
趣味で作るコンパクトなゲームなら
>>614 で十分
それなりに大規模だとメンテナンス性を考えてデザインパターンを考慮したほうがいい
覚えたての知識をむやみやたらに使いたがるのはよくあることだが
パターンに限らずまず本当に必要かどうか見極める事が肝要だな
>パターンに限らずまず本当に必要かどうか見極める事が肝要だな たしかにそうですね。とりあえず今のところmainで遷移区分によってタイトル、ステージ1どっちを処理するか判断させてるのでそこの部分はそのままにしようかなとおもいます。 ステージ1作りおわったら↑の実装やデザインパターンをみたあとに必要かどうか考えようかな。
>趣味で作るコンパクトなゲームなら
>>614 で十分
そう思っていた時期が私にもありました・・・
シーン遷移にステートパターン適用しないと開発が行き詰るってどれだけ無能なの
最初の質問から見当違いの方向に話が進むのはこのスレの仕様
作るだけなら単純な実装の方が速い メンテナンスや再利用を考えるならパターンは考慮したほうがいい けど汎用的な設計は単純に作るより時間かかるしスキルもいるから 趣味で作るときに汎用性求めすぎると作ってるうちにしんどくなる 単純設計で作って再利用出来そうなものを自作ライブラリにするのが 現実的
>>615 そのEnterとExitって、要はコンストラクタとデストラクタみたいなやつ?
>>621 一度作ってしまうと、>614と大して変わらない労力でシーン遷移出来ちゃうのよねー
>>622 違うとおも。
一つのクラス内で起こるステート変更かと。
敵キャラが「待ち」から「攻撃」に移るみたいな。
各ステートのEnter関数でアニメーションのリセットしたりする。
Stateは俺も悩むわ ネットで調べると講座用の簡易なのしかないし ガッツリ調べるとゲームから乖離してイメージが掴めん・・・
SLGはstateパターン使わないと軽く詰む。 switch処理だとメンバ変数が大変な事になるしなぁ。
シーン遷移はStateなのかStrategyなのか
シーン遷移なんてstackで十分だよ
>>627 全く別のふるまいになるからストラテジではないんでね
ゲームをプレイヤの操作をインプットとしたステートマシンと考えると
ステートの方がしっくりくる…のかな?
>>後半、イメージエポック御影社長(左から2番目)を交えトークに拍車がかかります。 >>会場からの質問「海外のFPSに日本のFPSが勝つにはどうすればいいと思いますか?」 >>御影社長「うーん、海外のFPSはマサチューセッツ大学を首席で卒業したプログラマーとかが作っているので、それを超えるには根本的に開発スタイルを変えないとダメで・・・」 低学歴へ
ちょっと疑問なんだが、デジハリ名乗りながら低学歴云々ってそれ完全にブーメランだろ なんでわざわざコテつけんの?
歩き動作や弾を撃つときの描画の実装がごちゃごちゃしてきたー。
State/Strategyって 壁.Draw() { 壁->図形.Draw() { /*四角形用の処理*/} } みたいに アクセサが被るのがモヤっとしない?(ここではDraw) もちろん、そこが被ってワンクッションあるからこそ単一継承では難しい複数の機能を 併せ持つということができて多態性の幅が広がるけど、それって継承を使った際における 保守・変更時に整合性が取りやすいって部分を犠牲にして得た対価なだけな気がする
>>634 デザインパターンはあくまでベストプラクティスだから
それにあった処理に対して適用すると効果的ってだけで万能なわけじゃない
ちゃんと前提条件を踏まえて使わないとソース管理が煩雑になるだけ
>>614 仕様によるキリ)
しかし、その部分でこだわり発揮している作品って見たことがないな。
シーン遷移仕様がカオスとか、どんなゲームになるんだろうw
結局C++使いは継承(デザインパターン)使って俺つえーしたいだけだし、 C使いは関数ポインタ使って俺つえーしたいだけだし、 C#,Java使いはジェネリックス使って俺つえーしたいだけだし、 perl使いは無駄にシンプルで解読不能なコード記述して俺つえーしたいだけだし、 要は俺つえーしたいという欲望を捨てない限り救われることはないし、 足るを知り、満足するということを覚えない限り苦悩から逃れることはできぬ
そして一周回って言語を作り始める
>>637 C#の俺つえーはラムダだな。
無くても良くね?感アリアリ。
C++にもlambdaあるし、 std::functionのおかげでdelegateっぽいこともできるし、 signal/slotライブラリを使えばeventのようなことも可能だ
そういや std::mem_fun ってstd::shared_ptr には対応してないの? Boostの方を使うしかないのかな
JoyToKeyについて質問です JoyToKeyを使ったゲームを作ってるんだけど キーの割り当てで汎用的、標準的なパターンてあるのだろうか? (例えばPOVはテンキー、左スティックはマウス、右スティックはカーソルキー、〇ボタンはSキーとか) どこかの有名ゲームサイトで記事等あったら教えて下さい
ちなみにPS3のコントローラーの話です
JoyToKeyってゲーム本体にキーコンフィグが無くても、 プレイヤー側で自由に設定できるようにするソフトだったよね? 単純に、一般的なキー・パッド入力配置を聞いてるわけじゃないの? (もっといえば、C/C++に限った話しでもないし)
水の表現ってどうやってる? 煙とか火はテクスチャはっつけていくつも放射状にするだけでいいのに
>>646 どういう水の表現?
ケースバイケースで色々方法ある。
さざ波や反射はシェーダーで処理するのがベスト。
市販のゲーム見た感じでは単純なのだとテクスチャいくつか重ねたりuv値でアニメーションさせたり 複雑なのだと水面うねったり水底を歪ませたりしてるね 水しぶきはパーティクル、雨は線作って画面に重ねる感じかな? ところで水平線ってどうやって表現すればいいの? でっかいポリゴンにテクスチャ繰り返しで水面作ってるけど もっといい方法ある?
地形を球にすれば、何も考えなくても地平線も水平線も勝手にできる。
PS2のドラクエ5が、そのへん上手かった気がする
簡単な質問なんだけど、一回だけキーを判定する方法ってどうやってる? 前のキーAを取っておく方法だとキーBを押した時にキーAが発動しちゃう
AとBそれぞれ前に押しているかを判定すればいいんじゃないのか
ああ…やっぱりそれぞれ判定する用に配列作るのか パッド使ってるからKey[16]にそれぞれのキー押した時間格納すればいけるかも、ありがとう
普通は1フレーム前の状態を取っておく そうじゃないと 押してない→押した 押した→押してない の判定ができない
654みたいなのが下の下で、1bitだけ確保するというアホすぎる戦術。 普通は押され続けた回数をカウントしておき、押されている限りインクリメントする。 1だったら押された直後と判定できるし、 キーリピートの実装も簡単だ。
何でそんなに、こき下ろすのに気合入ってるんだよw 形になりゃええやん
もしかして時間ってフレーム数の事言ってんじゃね?
時間と前フレーム押したかどうか持っとけば可変でもいけるっつーことですよね それに対して固定前提の処理をどや顔で提示したって突っ込んでるんですかね?
655では時間の保持について言及してないので フレーム固定前提だと思われたってことですよね それに対して時間も持っとけば可変でいけるとか 誰でも分かる当たり前の事をどや顔で提示してるんですかね?
>>662 でも可変だったらインクリメントした値保持する意味なくね?
>>663 経過時間に掛けてインクリメントする値を変えれば良い。
フレーム変化したらその分キー入力呼ばれなくなるんだから特別な処理する必要なくね
「3秒ボタン押したらフォース発射」を考えてみよう。
>>664 状態変化したときの時間保持して現在時間との差分見た方が誤差少ないと思ったけど
数百回程度の加算の誤差なら大したことない?
ていうか加算するやり方は可変フレームレートには向かないよ。 時間と状態をヒストリーに保存するのが吉。
長押しを判断させるのはプロセス側で良いんじゃないか?
>>669 でも入力の履歴は入力管理するインスタンスに持たせたくない?
例えば3秒以上押されてるか確認したい場合はプロセスは入力インスタンスにどのボタンを何秒ホールドしてるか
問い合わせてそれを3と比較する方が処理がスッキリすると思う
>>671 もちろん俺も色々悩んだけど、長押しかどうかの判断をしたいプロセスは
結局のところ「自分のコントロールのためにボタンが押され始めた時刻」を
保持しておかないと後々融通が効かないかなーと判断したのよね
だから押しっぱ時間は入力管理クラスで測るんじゃなくて
専用のカウンタークラスを必要とするプロセスに包含させることにしたよ
こんな事をしてる人って、もしかして俺だけ? BYTE GetKey() { return g_bGetKey; } BYTE GetKeyOn() { return ( g_bGetKey ^ g_bGetKeyBackup ) & g_bGetKey; } BYTE GetKeyOff() { return ( g_bGetKey ^ g_bGetKeyBackup ) & g_bGetKeyBackup; } キー入力の直後を取得する場合は、 if( GetKeyOn() & GET_KEY_BUTTON1 ) ってな感じ。
俺もPC向けだと時間でやらなきゃ駄目だというところに行き着いたよ。 もしかして安定が保証されてる(?)ような専用のゲーム機ではフレームでやっちゃっていいよってことになってるのだろうか?
フレームレートが安定しないような廃スペック要求するゲームを作ってるなんてすごいですね で、画面の更新間隔と内部の処理を同期する必要あるの?
>>673 ぶっちゃけよくわからん
GetKey()は押されているボタン
On()は押された直後のボタン
Off()は離した直後のボタン
がそれぞれビットに入って帰ってくんのかな?
>>675 安定していたとしても固定されてるわけじゃないし、その安定性も誰かが保証してくれるわけでなし
>>677 いいんじゃないかな
でも
~a & b
a & ~b
の方がわかりやすいかな?
stateとか他のデザインパターンについても空いた時間にちょこちょこ読んでるけど まだ理解しきれてないから使わずにとりあえず実装進めている。 後から後からこのプロパティ要るな〜とか、ここの処理は親クラスで実装したほうがいいな とか色々出てくるからやっぱ最初の時に設計固めるのって大事ですね。 こういうケースって結構あります?
>>680 趣味で経験があまりないならまずやってみ
迷走して完成しないのが一番もったいないし、失敗しないとノウハウは身につかない
仕事なら・・・がんがれ
>>675 3Dゲームなら可変フレームレート前提で作るのは常識だろ。
ハードによってパフォーマンス全然違うし、ユーザー側で
イフェクトのオンオフを設定できるからそれでもスピード変わる。
16ビット機時代のゲームはテレビの垂直同期に
合わせてたから、ヨーロッパでPAL用に作られた
ゲームがNTSC機に移植されると微妙にスピードが
速くなったりしてたな。
イフェクトってかっこいいな エフェクトの英語読みか?
>>682 2Dなら固定、3Dなら可変ってイメージがあるな。
あくまでイメージなので根拠はない。
>>682 描画だけ可変にすれば良いんじゃないの?
どうして内部の処理と描画を同期する必要がある?
このスレにゲーム機でゲーム作るような奴がいるとは思えないが
せんせい!かへんふれーむれーとにするとどんないいことがあるんですか?
>>687 そうか、ゲーム会社に勤めるプログラマーは
2chは誰一人やらないのかw
>>688 17msec以上かかる処理や、実際の時間を計測するような処理が使いやすいとか?
>>689 居てもほとんど守秘義務の範囲内でしか書けないから居ないのと同じ。
692 :
名前は開発中のものです。 :2012/12/13(木) 00:25:18.52 ID:hxBRbA/2
それ見たら、Zバッファだけで何の問題も無いようにしか思えないが、 頭は大丈夫か?
zバッファ解除で解決すんのは交差してない時の透明色描画順序だけだわ(訂正)
交差しているテクスチャは分断してあるんだよ
697 :
名前は開発中のものです。 :2012/12/15(土) 12:27:38.78 ID:aCUGFQ4c
>>696 想像で質問してますけど、パフォーマンス大丈夫なんでしょうか?
基本的にZソートで、 交差したら交差した部分を ナイフツール使ったみたいに分断・?
>>698 動かない所なら最初から分断しとけばおk
動くところは交差させないければおk
捻くれたレスのように見えるけど
>>699 を基本にして間違いはない。
>>699 よく理解できてないんだけど、
例えば長方体の長い棒で人を刺した表現をしたかった場合、
本来面が8個で表現できるのに刺されてるところを予め予想して面を分割して増やすの?
クラス内の関数が多いから名前空間つけようと思ったらできないんだな。使えん
よくわからんが、たぶん設計が誤っている
リファクタリングすれば良いんじゃね?
ぐおおおおおおお!! バグがとれねええええええ!! どこでメモリ破壊してるのかわからねええええ!
落ち着け!動くバグは仕様だ!
悪い悪夢はバクだ!
そういう時はメシ食って寝ろ。
可変フレームレートを固定フレームレートより良いとする場合って多いけど 実際そんなに見た目は良くならなくね? 固定60fps>可変60fps=固定30fpsくらいのイメージ 可変fpsでゲーム作ると手間かかるから 結局固定fpsで落ち着いちゃった
711 :
名前は開発中のものです。 :2012/12/18(火) 01:12:23.92 ID:EXioU2qv
まあ固定60fpsでいいよ
>>710 スタートはそれでもいいと思う。
初心者がいきなり可変を扱うのは敷居高い。
可変はゲームスピードが一定になるのがメリットだから 見た目なら固定の方がコマ落ちおきないからキレイでしょ
>>713 可変だって重い処理が起きない限り一定だけどw
重い処理が起きたら一定じゃないじゃん
重い処理が起きたらコマを飛ばすから一定、ってのが可変の売りじゃないの?
描画が間に合わなくて適度の位置にスキップは良いけど 演算処理が重い場合は結局コマ送りにしてやらないと入力が飛んでしまいそう
現実的には60fpsが30fpsに落ちる程度でしょ。 プレイヤーは気付かないよ。 固定フレームだとスピードガタ落ちで丸わかりだけど。
>>718 コマ落ちだと見た目で処理落ちとわかるけど
スローなら演出と思ってくれるかもよ?
なるほど! つまり処理落ちしたら「スロー再生中」と出せばいいのか!
スレ流し読みしたけど 「フレームレートの可変/固定」と「時間刻みの大きさの可変/固定」を ゴッチャにしてる奴がチラホラ混ざってるよね。そこんとこどうなの?
どうでもいい。 さらっと上辺の話ししてるだけだし。
フレームレート=時間刻みの大きさな訳だが 変動量が連続的か離散的かってなら、離散的な可変は固定の延長みたいなもんだと思ってる
3次元のオブジェクトの動きの計算の仕方で悩んでるんですが たとえばガンダムのファンネルの動きでMSの周りを等速円運動させる場合などの 具体的なプログラミング方法を紹介しているようなサイトってありますか? よろしくお願いします
>>724 2次元なら
ファンネルの座標x = ガンダムの座標x+cos(a);
ファンネルの座標y = ガンダムの座標y+sin(a);
としてaを少しずつ増やせばできるともうよ
>>725 忘れ物ですが
つr
二次元の説明してるサイトは結構あるけど三次元で具体的なプログラム書いてあるサイトは見つからんかったな
まあ二次元のが理解できれば応用で三次元もいけるとは思うけど、複雑さが違うから数学苦手だときついかもな
727 :
名前は開発中のものです。 :2012/12/19(水) 20:24:52.47 ID:YtPtOMuR
Matrix使わないなら面倒そうだな
後ろに仰け反った方が弾を避けやすいからな。
どうみてもクォータニオンだろ
730 :
名前は開発中のものです。 :2012/12/19(水) 22:30:33.88 ID:YtPtOMuR
どちらでもできる
速度と加速度で円運動させるという方法もある
Q、 なぜ彼はそのような遅そうな方法を提案するのか A、 頭の回転が遅いから
ディスり芸は身を滅ぼすぞ
遅そうな方法ってどれの事言ってんの? どれも普通に使われる演算に見えるんだが
>>730 悪いとは言ってないよ
俺はそういう奴は下に見る
個人の感想
個人意見だと断りを入れれば 何を言っても良いと思っていそうだな
下層にいる人間ほど上下関係を気にするものだから仕方ないだろ
昔のゲームでよくみるアニメ動画ってどうやって作ってるの? スクリプト組んでその通りに動かすか、After Effect辺りを買ってきて、 動画ファイルを組み込むかで迷ってるんだが。 それとも、他に何か良い方法とかある?
座標算出するのにクォータニオン使うメリットって何かあるの? ジンバルロックは起きないし、座標変換するときに結局行列使うことになる気がするけど
>>738 昔のゲームっていつぐらいの?
具体的にタイトル挙げてくれないと、作り方はいくらでもあるから答えにくいよ。
>>740 今は無きグローディアとか、パチ屋に吸収されたマイクロキャビンとか
個人的には、PC版のエメラルドドラゴンとか、アルシャークとか、 ヴェインドリームUとか、エルムナイトの動画がよく出来てたと 思うんですよね。
まず、アニメーションがどうやって動いて見えるのかそこからみたいだなw
絵を複数描いて切り替えろよ。 何が疑問なのかがさっぱり分からない。
どんな方法が効率良いのかが分からないので、質問しました。 時系列で絵を切り替えるのか、スクリプトで画像を条件分岐して貼り付けるのか、 文字入力との同期はどうするのか、そんな所です。
二十年も前のゲームのアニメーションなんてほとんどが画像切り替えか 小さな画像をそれっぽく動かす(移動)させてるんじぇねーの? つーか、そんな昔のアニメ効果の話をスクリプトだのとか言われてもね。 二十年前にはスクリプトだのそんなもの無かっただろうし。 今のやり方で好きにやればいいよ。
俺はわからないからアドバイスしてあげられないけど 何事も、効率の良い方法が分からないときは効率が悪かろうが自分の考えた方法で とにかく実現させてみないとどのみち理解も成長もできないもんだと思ってシコシコやってるよ
今のアニメはむしろ昔に比べると退化してるものが少なくないからでね? まあ、アグネスとかのエログロ規制のせいもあるんだろうけど。
>>747 スクリプトの歴史の長さを舐めちゃいかんよ。
>>747 は?
そこに上がってるゲームって機械語だぞ。
スクリプトなんて使うかよ。
中間コードってんならまだわかる。
ああそうか。天下無敵のインタプリタ BASIC様を忘れてたわ。 BASICでアニメとか正気の沙汰とは思えないけど。 まったくなかったわけではないわ。 BASICから機械語の描画ルーチン呼び出してるアドベンチャとかあったなそういえばw
AE使えばアニメが作れると思ってるのがなんとも。
こんな初歩的なこともわからないにAE使ったところで同じだろうな。
>>744 ここに書かれてるとおりアニメの初歩から勉強すれば?
>>746 シーン制御とかアセット管理でググればそれなりの答えがあるんじゃねーの?
あんたの短い質問じゃ。ターゲット環境も縛りもわからねーから。
こういう答えになる。すまんね。
シーン(アニメ)が条件で分岐するならスクリプト言語併用が扱いやすんじゃないかとは思う。
>>754 つまり、プログラム技術云々ではなく、まずはアニメーション技術の云々を勉強しろと?
さて、どうしたものか。アニメーションなんて何処で勉強すれば良いんだろ??
作ってるゲームはRPGだけれども、フリダシに戻った気分。
>>739 DirectX前提だけど、
条件判定を手作業で追加してやらないと、ジンバルロック起きるんじゃね?
クォータニオン周りは、座標算出ではなく、変換行列を求めるのが目的じゃないか?
例えば俺は、何らかの物体を、別の球体表面から放射状に延びる様に配置する時に、
変換行列を求めるために利用してるな。
>>758 PCエンジンは比較的新しい方、PC88だのはもっとしょぼいアニメ。
それから、ドット単位というより。
一枚絵の一部分だけ、目なら目、口なら口の部分だけ書き換えるんだよ。
これは、ハードの性能の問題。
8bitCPUが4Mhzとか8Mhzで動いて、VRAMも48KBとかの時代の話だ。
この手法は
むかーしのセル画の頃のアニメに似た手法。
今ならこんなことに気を使わなくても全画面書き換えて60FPSとか余裕でしょ。
そっち使え。
>>739 ゲームで連続的に使うならシンバルロックは致命的だけど。
起きないんならいんじゃね?
俺は、Quaternion使う利点は演算コストだと思ってる。
あと、3DCGソフトの多くがQuaternionを使ってることが多いので再現性が高い。誤差が少ない。
こんなもんかな。
リンクにあるエロゲのE-moteのほうが関心事かもしれん つかこれLive2Dとどう違うんだ
>>762 Live2DはLive2D用のモデル、E-moteは既存のイラストと聞いた。
詳細はシラネ
>>762 Live2Dなるもの知らないんで、チラ見してきた程度の知識で答えると
やってることは似たようなことだけど。
昔:一枚一枚手書き
今:画像を自動生成
くらいのちがいじゃねーの?
ぱっと見はモーフィングとか自由変形みたいだな すごい技術なんだろうけど、違和感ありありでフラッシュアニメみたいだな
>>759 >今ならこんなことに気を使わなくても全画面書き換えて60FPSとか余裕でしょ。
>そっち使え。
絵がデカければデカいほど、描く人が大変だと思うんだな。
昨今のアニメには繊細さが足りないと思うの。
>>767 じゃあ、作画のコスト考えて昔の手法使えばいいじゃない。
別にできないわけじゃないよ。
つーか、今なら3Dモデル作ってモーションやモーフ使って2Dっぽくレンダリングしたほうが
全体的にコストが少ないと思うけど。
>昨今のアニメには繊細さが足りないと思うの。
昨今のアニメはいちいち手書きなんかしてねーYO!
>>761 88で横1ドットスクロールだとか、気合入りすぎ(^^;;;
88は1バイトずれると8ドットお隣りだからなあ。
このタイトル、8MHzの頃だったよね?
それでも2Dドライブ2基&メモリ32KBでよく動かしたもんだ。
>>769 1バイトで8ドットって色の情報はどこにあんの?
RGBの3プレーンの合成
Cを0から勉強して普通の2D縦シュー作れるようになるまでどのくらい時間かかる?
本人のやる気と素質次第。 そもそも「普通の2D縦シュー」ってどんなものだ? 少なくとも、手を動かさない限りは100年かかってもできない。
>>772 大学1年でCを0から学習して19年
今年初めてゲーム1本作り上げた
STGなら竜神録のなんとか見ながら作れば意外とすぐ作れるんじゃない 親切にアルゴリズムの説明からソースまであるみたいだし まあコピペが勉強になるかどうがはわからんけど
>>768 だからガンダムAGEみたいなゴミが出現するのか……
なんか昨今はコストコストで何処の会社もまともに作れないみたいやね。
>>772 縦シューって背景スクロールとかまでやるの?
0から勉強のつもりなら、もっとシンプルなやつから始めた方がいい。
例えばインベーダーの真似とか。
移植でなく勉強のつもりなら全く同じでなくてもよく、例えばUFOなしとかシェルターなしでもいいから
1つゲームを完成させる事を目標にすればCのスキルは自然に上がるはず。
それで物足りなくなったら、新しい事を勉強、もしくは研究するといい。
最初からスクロールだ弾幕だ拡大縮小回転(流石にここまでは考えないか?)だと欲張ると挫折の元。
自機の表示、移動とかは苦労しないけど、敵を出すと苦労する気がする。
更に進んでギャラクシアンの真似くらいのレベルになれば、敵の動きで悩むようになるだろうし。
俺が小学生の時に作った一番最初のゲームは、 UFOが左から右に飛んできて、スペース押すと 砲台から弾発射するって感じだった。 弾が移動中はUFO止まっちゃうみたいなw フレームupdateの概念知らんかったし。 ただ文字が動いただけで大興奮してたなぁ。
>>779 自分が作った通りにコンピュータが動くのが楽しい。
はじめはそんな所から入るんだよな。
今みたいにツクールだのノベルツールだのがある世代には理解出来ないかもしれないが。
最近のツクールはRubyで動かせるらしいから デフォ機能に満足できなくなってプログラム始めてみる人もそれなりにいるんじゃないか ほとんどの人がGUIとの難易度差の壁で挫折するような気もするが
>>781 入門書が無いから、かなり難しいんじゃね?変数やら、ループやら、条件分岐やら、
関数やら、プログラムの素養も無い状態からいきなりスクリプトを組むんだぜ?
俺も昔は、i=i+1が理解出来なかった。
>俺も昔は、i=i+1が理解出来なかった。 ちなみにファミリーBASICの頃な。
>>782 Rubyの入門書なんていくらでもあるが
>>785 彼らに必要なのは、Rubyの入門書じゃなくて、RGSSの入門書だと思うんだ。
微妙な違いだが。内容は、ほとんどRubyの入門書でかまわんけどな。
というか平でRuby叩けるなら自分でライブラリ作れるよね
>>786 出たら出たで値段が高いと言われる悪寒
専門書の値段は一般書籍よりも高いからなぁ……
>>787 作業量を考えると、とてもやる気になれん
凄い時間食うしそれだけ使って自作しても満足な性能にはならんし 人生がもっと長いものならライブラリ自作もいいだろうけど
セーブデータ作るのマジで難しいな、頭痛ええええ
>>791 メモリの領域そのままファイルにしちまえ!
一時的なアドレスをファイルに記録しも何の意味もないだろう。 ストレートにデータだけが密集しているなんてあり得ないし。 本当に頭が悪いな。
msgpackでも使え
795 :
名前は開発中のものです。 :2012/12/26(水) 00:25:08.92 ID:uxJ2SIgl
密集していないなら密集させればいいじゃないw
セーブデータパックという保存したい全てのデータをメンバに持つクラスを作る セーブデータパックのメンバに保存したいデータを代入する セーブデータパックのwrite()関数は自身が持つメンバをファイルに書き込む
セーブデータが増えるごとに、作る必要のないメンバを増やさないといけない糞設計。
ぼくiniファイルに突っ込んでる
>>797 ケチばかりつけてないで自分の実装を書きたまえ
キチガイはNGしとけ
792をネタとして捉えないお前らが怖い
マジレスするまでがネタだって小学校で教わりました!
なんか最近壊れてる人間が多いな コミケ前で気がたってるのか?
ああ、シングルベルで荒れているのか プログラマーって、一人でプログラム組んでいるのが幸せな人種だと思ってたんだが、最近は違うのか
お、嘆きだったのにわざわざネタもアドバイスもサンクス Boost使っても基本的にシリアライズするメンバを手動で記述しないといけないのと やっぱりポインタ関連が辛いわあ
僕はmementoちゃん
嫌味言いたいだけなのか構われたいだけなのか
map<string,Data>にすれば別にメンバ追加とか要らんやろ
セーブデータ読み書きクラスとそこから呼び出す仮想クラスを作る。 セーブに書き込むデータのクラスは全部この仮想クラスを継承してセーブ読み書きクラスに登録する。 セーブ読み書き時に仮想クラスのリストを全部呼び出す。 俺の場合はこうしてる。
仮想クラス(笑) 知的下層民が考えそうなアイデア。かそうだけに。
ゲームプログラマって気持ち悪いの多い印象
2chの利用者って非リア充なイメージ
仮想クラスだと読み取りメソッドがファクトリとくっ付いちゃうよね。仕方ないか
>>792 が完全にネタ扱いされてるけど、メモリプールをそのまま保存するのは普通にありじゃね?
ポインタはメモリプール内への参照なら先頭アドレス持っとけば簡単に再構築できるよね?
>>814 俺も何でネタレス扱いされてるか疑問だった。
もちろん有効な場面とそうでない場面があるのは確かだろうが。
ポインタの再構築用のマップみたいなの作るとして、アドレスの値って ポインタのままじゃなくなんらかの整数型にキャストしといたほうが安全かな?
シリアライザを自作するの?おじさんゲ製板久々だから浦島発言するかもだけど 学習目的でなければboost::serializationとか使ってもいいんじゃないの、って思うよ
エンディアンとかの類って吸収してくれるんだっけ?
>>817 friend指定してポインタ含めてオブジェクト構造まで再生する
って言う仕様が生理的に無理。キモス
820 :
名前は開発中のものです。 :2012/12/27(木) 23:56:35.74 ID:pK5zNzT+
セーブごときで躓いていたらいつまでたっても完成しないよ
複雑に考えすぎ ファミコンとか単にロードに必要なデータを抽出して、 バイナリデータとしてメモリに詰め込んでただけだろ 機能を実現することが目的じゃなくて、 なんかスマートにやらないと駄目だみたいな強迫観念があるよね ゲームを作ることが目的なんじゃないのって思うね
結局スマートにしないと後で苦労するからだよ
>>816 安全かどうかはともかく、計算あるから整数型の方が扱いやすそうだけど
>>821 そんな単純なモンじゃない。ジャンルによって大きく変わると思うけど、
結局、オブジェクト構造の再生で躓くんだと思う。
セーブに凝るより、ゲーム内容に凝れよ だからお前らのゲームはつまんねえんだよ
煽るよりゲーム作れよ
セーブは是非ともクリアしたい課題なんで色々な意見聞けて助かります
凝るってレベルの話じゃないだろ。
ゲ制作技術はワナビーが多すぎなんだよな。
セーブってもピンからキリがあるじゃん。 復活の呪文ってのは、昨今では下の下だよな。 やっぱ、ホットキーでのクイックセーブ&ロードって重要だと思うぜ。 再現するのは難しいがな。
クイックディスクにセーブ&ロード
型推論のautoって使わないほうが良いっていう意見をよく見るけど あれってタイプがラクなだけじゃなくて修正・変更を見越してtypedefを使うときみたいに ちょっとした修正に自動で対処してくれるからかなり良いと思うんだけど、何か致命的な部分とかあるの?
処理が重い&遅くなるんじゃん?
型推論で処理が遅くならんだろ IDEのインテリセンスやコンパイルが遅くなるのはあるだろうな
auto使わないほうがいいって意見は (1)「変数の宣言を見ただけでは型が分からなくなる」 (2)「動的型みたいで嫌い」 って2種類をよく見る印象。 特に後者は、VBのVariant型と混同してる奴がたまにいる。 「そういう考えもある」程度の意見だと思っていいと思うよ。
あれってコンパイル時(プリコンパイル?)に解決すんだよね? なら実行速度は変わらん気がするけど
Visual Studio使ってるならマウスカーソル乗せたら型表示されるんだからガンガンauto使えでFA
2008までしかProライセンスないからauto使ったコード書きにくい 2012のGPUデバッグ欲しいけど高いんだよな
ほぅ…
良かった。autoに調教されすぎて今さらイテレータなんてタイプできない身体にされてしまったからな・・・
孫の孫の孫の・・子のクラスでtemplate使いまくりで ビルド時間中にゲームの腕前が上がりまくり
テンプレートから型を限定して継承したりするとすごいテクニシャンになった気分になる
scalaの本に型推論の使いどころと使わないよう注意する点が 書いてあったけど捨ててしまった
記述性と可読性が両方向上する場面なら使っても文句は言われないと思う ただ単に「型をタイプするのが面倒だったから」って理由が先行してる auto乱用コードも、世間の目に触れさえしなければ文句は言われないと思う 他人に読ませる予定が無い書き捨て作り捨てコードなら(他人にとっての) 可読性なんて気にするだけ無駄とも言えるから好きなようにやればよし
forループのイテレータなんかは、autoの方が読みやすいよね
基本的なことだと思うんだけど、予想外の動きをするので教えて欲しい。 あるインスタンスの関数から、そのインスタンスを消す関数を呼んだあと、どうして元の処理に戻ってこられるんだろうか? てっきりこういうやり方は、戻るべき関数がなくなってしまってエラーが起きるんだと思いながら、(あぁ、これは出来ないんだろうなぁ・・・出来たら楽なのになぁ)と実行してみたら動いてしまった。
呼び出すときに戻り番地をスタックに格納してるから
削除フラグを立ててるだけで実際に削除はされない。
deleteで消えるのはインスタンスに含まれる変数共で関数は消えないだろ
>>847 >てっきりこういうやり方は、戻るべき関数がなくなってしまって
実行コードがインスタンスのデータじゃないので自殺(delete this)しても
消えない。戻り番地についても
>>848 の言う通り
>エラーが起きるんだと思いながら、(あぁ、これは出来ないんだろうなぁ・・・
自殺(delete this)した後にインスタンスのデータにアクセスしなければ
エラー(メモリアクセス違反)は出ない。試しにエラーを出してみたければ
メンバ変数にアクセスするとか仮想関数を呼び出すとか
デバッガでアセンブリ言語レベルでステップ実行すれば動く理由が
手に取るように分かるんじゃないかな。MSのVisualStudioなら
混合モードでステップ実行みたいな
>出来たら楽なのになぁ)と実行してみたら動いてしまった。
自殺(delete this)は一般的な御作法のお話としては非推奨なので
やるなら個人の範囲に留めたほうが無難なんじゃないかな
そもそもRAIIオブジェクト使うから自分でdeleteしなければならない場面なんてほぼない
それでも循環参照は怖い。 包含にはshared_ptr、参照目的の依存関係にはweak_ptrを心がけてるけど ObserverやMediatorあたりは頭が痛い
この板の名前から推測するに インスタンスに自殺(delete this)させたいという願望にありがちな背景事情は 「ゲーム上の死」と「リソース上の死(メモリ解放)」の区別をしていない (or混同してる)場合が多いんじゃないかと いずれにせよリソースレベルの自殺願望というのは何かしら設計に難があるよね
タスク処理だとリストからの削除(ゲーム上の死)と同時にdelate(メモリ開放)することも多いし 自殺じゃないにしろ削除する対象が結果として自分になることはあるかもね。 StatePatternみたいなのは維持(スタック)と退場(再初期化)とメモリ開放の区別が難しいかもしれない
>>848-856 ありがとう。
個人制作なのでまぁ、しばらくこれでやってみて、ちょっと雲行きが怪しくなったら一手間かけてみようと思う。
すっきりしたよ!
敵、弾、エフェクトなどの物体1つを1インスタンスとした場合、 ゲーム上での生成/消滅にあわせてnew/deleteしたいときは多いなあ。 自殺するか、自殺願望フラグを立てて管理クラスからdeleteしてもらうか、 あるいはゲーム上での消滅判定も管理クラス側で全てやってもらうようにするかは設計次第としても。
>>858 今のPCならいちいちnew/deleteしても無問題だけど、
ゲーム制作のセオリーとしては推奨されない。
モバイル機だとその設計はオーバーヘッドが多過ぎ。
使われなくなったインスタンスは未使用フラグを立てて、
また再利用すべし。
>>858 自殺以外のイベントも自分でやるか管理クラスでやるかは悩みどころだよね。
>>859 極端に言えばファクトリが実体をvectorで保持しておいてそれの参照を返すとか?
deleteの代わりにファクトリに返却すると勝手に初期化して再利用するのか
無駄な労力使う奴が馬鹿
>>859 に同意だな。
アクション系アクタをプレイ中にnew/deleteするとか、ぬるすぎるぞw
ヒープ領域のメモリ確保は時間がかかるってのは常識だぞw
業務用アプリじゃあるまいし
でもnew/deleteがオーバーロードされてるかもしれない
当初の流れはデフォルト動作を前提としていたみたいだよ。 メモリ解放とか言いだしていたから。 デフォルトのnew/deleteをプレイ中に実行するとか、 板的にテンションが盛り下がりまくりじゃね?ww 俺は許せねえよ!
そもそもモバイル機の話だったのか?
>>853 シーンの切り替わり(例えばシューティングゲームのステージ間)でもdeleteはせんの?
本物のC++erは可能な限りdeleteしないし、デストラクタも書かない
テクスチャや頂点データのリソースを使い回しているのが前提なら、 newやdeleteを使おうが使うまいが1FPS以内の測定不可能レベルの誤差にしかならない。 ヒープの確保などモバイルでさえ、影響が全く見えないというレベルにしかならない。 こういうところでどや顔でヒープとか言い出すやつは、 脳内リソースで最低限のベンチマークもとっていないアホ。
deleterで解放できない場合は仕方ないので自分で書くしかないが FILEならstd::unique_ptr<FILE, decltype(&fclose)>とかを使えばデストラクタ書かずに済む そのページもスマートポインタ使えるときは使えという風に書いてるように見える
>1FPS以内の測定不可能レベルの誤差 ↑これ非常に誤差がデカイってことだよな?
新年早々、触れちゃいけない子だったかw ヒープのデメリット無視とかあり得んわww
興味あるわー>ヒープのデメリット 確保も解放も0.1ms以下だし 断片化の影響は考えられないメモリあるし
簡単な検証方法 1 足し算を一回させるものと、newとdeleteを一回させるものを用意(断片化させるためにnewを多くしても可) 2 ループで1万回回す 3 命令が削除されないようにコンパイラの最適化は必ず切ること 結果、どちらも早すぎて測定不能 こういう話をするときに、じゃあデメリットの発生するソースを用意しろといっても、 グダグダ言い訳をして絶対に出してこない。 毎度毎度、お決まりのパターンなんだよね。
本当に検証したのならコードを出すべき
>>873 >確保も解放も0.1ms以下だし
60FPSとすれば、上記では利用可能な時間のうち、最悪1/166もの時間が消費されることになるな。
にもかかわらず「ヒープのデメリットに興味あるわ」なんかな
結局時間だけか ゲーム中1f辺りのオブジェクトの生き死になんて多くても10個程度 フレーム落ちしないレベルだからコーディングコストを考えて無視してる 断片化でどんどん重くなるとか全体のヒープメモリが肥大化して他を圧迫するとか そういうデメリットがあるのかと思ったんだが
>>875 手順を書いてあるんだからその程度作れるだろう、恥ずかしいやつだな。
Releaseで最適化を切った状態で、超ナイスタイミングで無い限り0になるはずだ。
#include <Windows.h>
#include <stdio.h>
#pragma comment( lib, "winmm.lib" )
int main()
{
timeBeginPeriod(1);
DWORD t = timeGetTime();
char* c;
int i;
for(i=0;i<10000;i++)
{
c = new char[100];
delete c;
}
t = timeGetTime() - t;
printf("%u",t);
return 0;
}
delete[] c; にし忘れたが、出力コードに変化はなし。
検証したならコードを出せとか、結局このままグダグダ難癖つけて 自分じゃ何一つ根拠を提示しない今後の展開が透けて見えるな
こうやって断片化させても変化なし。 c = new char[rand()%100+1]; new char[rand()%100+1]; delete[] c;
で、こうやってこちらがコードを提示しても、 絶対にヒープのデメリットを示すソースは出ない。 まあ、毎度お馴染み。
おう、お疲れ。 10000回ループさせる試行を100回繰り返した時の平均時間はどうなる?
0~100バイトのデータを1万回 new と delete 繰り返しても1msの間では 測定不能なくらい時間がかからない、って認識で合ってる?とにかくありがたい
>>866 それスマートポインタの類を使えない状況には思えないんだけど
>>883 PCならいんじゃない?
スマホだとメモリ限られてる上に限界超えた時点で
アプリが落ちるっていうクソ仕様だから、ゲーム中に
newするのは危険。必要最大限のヒープを先に確保しとくべし。
結局、ソースは出なかったね。
まあ実際に動かして出た結果が正義だしな ちなみにこれってnewだけ繰り返しても同じ結果になるの? いま開発環境手元にないから調べられないんだけど
>>883 for(j=0;j<100;j++) {
//計測開始
//1万回new/delete
//計測結果出力
}
こうしてみたら測定不能ということはない。
手順は書いたんだがな。
>>888 それじゃ出力命令が重いという実証結果が得られるだけだろう。
単純な測定すら書けないとは、本当に酷いな。
そもそも分解能未満の計測を繰り返す意味ないよね やるなら100万回実行でいいんじゃないの
>>889 は?何言ってるんだ?
for(j=0;j<100;j++) {
//計測開始
DWORD t = timeGetTime();
//1万回new/delete
//計測結果出力
t = timeGetTime() - t;
printf("%u",t);
}
こうするんだよ?
頼むからROMっていてくれないか。
ちなみに
>>888 だと加算に命令を置き換えても出力命令の重さに引っ張られて、結果が変わらない。
せめて測定結果をためておいて、後から出力するようにしないと話にならない。
ちなみに一度に数億回とかやっても実は関数を呼び出す負荷が大きいだけで、
適当な関数を二回呼び出すのと結果は大して変わらない。
アセンブラのソースだせ。こんなに見ても意味ない
>>893 自分でコンパイルして出したらいいだろw
コードがどうのじゃなくて反証あげればいいだけの話っしょ
つーか、ここの奴らの標準コンパイラは何なんだ?
プラットフォームは?
897 :
名前は開発中のものです。 :2013/01/03(木) 10:50:00.33 ID:TASQia0Q
>>895 ないなそんなもの、スマホって言ってみたり貼られてるソースはwindowsだったりばらばら
まあVC++ or gccってところになんじゃないの バージョンはまちまちだと思うけど
>>897 あほくさ
バラバラの環境で性能周りの話しをして何が楽しいのだ?
パソコンだけでもバラバラだってのに
900 :
名前は開発中のものです。 :2013/01/03(木) 10:56:30.15 ID:TASQia0Q
知らんがなww
>>899 普通のプログラムではあり得ないような短時間で局所的に1万回という馬鹿な回数をこなしても、
測定不可能な程度の負荷しかかからないという結果は出せる。
いいたいことがあるのなら、逆に環境が変わることによって、
これが覆る結果を提示すればいいだけの話。
だから「こういう環境だと不都合がある」って提示すればいいだけ その一つとしてモバイルって上がってるし PCでも「こういうときは不都合がある」ってのを提示すればいい 環境がバラバラだから意味ないなんて事はないよ
提示してから言ってくれ。 そもそもソースだけ出して測定結果も出さないことになんか意味あんのか? 環境が違うんだから環境をさらして測定結果出さなきゃ集計もできんでしょ
>>903 測定結果0
何度もやっていれば1が出る可能性はある。
で、人に要求するだけで自分の測定結果は出さないの?
まずは要求する前に自分の手を動かせ。
もう一度いうが、余計はことをぐだぐだ言う前に自分で作ったソースを提示しろ。
>>903 「newとdeleteのオーバーヘッドが無視できる程小さい」って意見に対する反証提示すればいいだけなんじゃないの?
ソースあれば十分な気がするけど
ちなみに俺の環境6コアCPU、Windows、VC++、x64、Releaseビルド(最適化無効)では、
>>891 を走らせた場合、目視平均で10ms程度だ。
最初の1回は0msになるがな。
一方、new/deleteの部分をk++;などのインクリメントに置き換えると、殆ど0ms。
907 :
名前は開発中のものです。 :2013/01/03(木) 11:25:01.81 ID:TASQia0Q
一人痛いのがいるな 正月に嫌なことでもあったのか?落ち着け 明日から仕事だろ?
#include <Windows.h> #include <stdio.h> #include <math.h> #pragma comment( lib, "winmm.lib" ) #define CA {c = new char[100];delete[] c;} #define CA2 CA CA CA CA CA CA CA CA CA CA CA #define CA3 CA2 CA2 CA2 CA2 CA2 CA2 CA2 CA2 CA2 CA2 CA2 #define CA4 CA3 CA3 CA3 CA3 CA3 CA3 CA3 CA3 CA3 CA3 CA3 #define CA5 CA4 CA4 CA4 CA4 CA4 CA4 CA4 CA4 CA4 CA4 CA4 int main() { timeBeginPeriod(1); char* c; int i; for(i=0;i<100;i++) { DWORD t = timeGetTime(); CA5 t = timeGetTime() - t; printf("%u\n",t); } return 0; } ちなみに1万回展開バージョンね 序盤しばらく0で、途中から1使うようになるけど、これはコード領域がでかすぎて、 キャッシュからはみ出しているせいだと推測される。 rand()とか適当な関数に置き換えても同じ動きをする。
ちなみに結果が安定しない場合は、CPUの省電力設定を切ることを推奨。
vaio p(atom)で試してみたけど、15~30だった デスクトップに比べて目に見えるほど遅いってのはちょっと意外かも ちなみにVS2005使った
cの型をクラスにしたら倍時間かかるようになった ちなみにintひとつとなにもしないコンストラクタのクラス これほんとにモバイルで試しても速いのか?
後はヒープを使わずに、使用済みフラグで管理するデータとベンチをとればいいんだけど、 これは後者を推奨する人間が作るべきだろう。 そもそもヒープの利用を禁止するような差が発生するコードが思いつかない。
>>911 最適化を禁止した状態でクラスを作ると無駄な命令が大量に発生するので、
生成される実行ファイルのコードが5倍ぐらいに膨らむ。
1万展開ソースに組み込むと、コンパイルに偉い時間がかかるよ。
案の定デメリットの根拠の提示がなされることはなかったな 聞きかじった知識の口だけ番長なんてこんなもんか
>>914 煽りに参加したいのなら、せめて何かソースなり検証結果なりを出せ。
それじゃやっていることはデメリット野郎と同じだぞ。
そもそもnewをオーバーロードしてメモリプールから取ってくるようにすればデメリット皆無になる木がするんだが
>>916 そういう話をするのは、ベンチマークを取って測定してからにしようねって流れなんだけどさ。
本当にスレからも歴史からも何も学ばないよなあ。
new deleteが遅すぎて開発が破綻した経験のあるやつっているの
>>917 原理的に考えるとそうでしょう?
ヒープを触るのが遅い原因で、メモリプールを使うことでそれを触らないようにしてるなら問題は解消してるよね?
これ以上何のベンチマークを取るというのか
#include <Windows.h> #include <stdio.h> #include <iostream> #pragma comment( lib, "winmm.lib" ) classtest {public:charbuf[40];}; int main() { int i; char* c; //test*c; //int k=0; for (int j=0 ; j<100 ; j++) { timeBeginPeriod(1); DWORD t = timeGetTime(); for(i=0;i<100000;i++) {//1万回ではなく10万回 c = new char[100]; //c = new char[(rand()%32+1)*8];//※ delete [] c; //c= new test(); //delete c; //k++; } t = timeGetTime() - t; printf("%u\n",t); } std::cin >> i; return 0; }
↑を、さっきのと同じ6コアCPU、Windows、VC++、x64、Releaseビルド(最適化無効)で
5〜6ms程度だ。testクラスなら7〜8ms。new/deleteをやめてk++にすると大方0msになる。
つまり1万回ではその1/10程度ということだ。
テストで生成しているオブジェクトの構造が単純であることを加味すると、十分に遅いだろ?
なお※の様に配列の領域のサイズを不規則にしてやると、38〜40msかかる。
ちなみにコンソールアプリを空プロジェクトとして生成して、main.cppを追加して記述している。
確認方法は、デスクトップ環境でexeファイルをダブルクリックにより実行。
>>906 の「目視平均で10ms程度」はいい加減だった。
つまりnewとdeleteとループ処理併せて一組0.00004ms=40ナノ秒 弾幕ゲーのように数フレームごとにオブジェクトの生成や消滅や数十個レベルで起こるとして、 それは使うとまずいレベルなのか? 結局自前で利用の有無をフラグの管理をするにしても、 ヒープからメモリを確保する場合と、利用有無フラグ捜索してポインタを返す場合と、 誤差以上の差が発生するプログラムが全く思いつかない。
PCの場合、例えば平凡なDoug Lea Malloc(の亜種)を使うことについて 処理速度上の問題で難癖を付けるには、意図的に相当に意地悪な(過酷な)状況設定を 引っ張ってくる必要があると思うなぁ 例えば3D視点のゲームで、視覚効果に使う粒子状の短命オブジェクトが盛り盛り 無数に画面上に散りばめられてて、それらが何と一粒一粒馬鹿正直にヒープから メモリ割り当てされてて何の工夫もない線形リストに挿入されてて、毎フレーム 線形リストを馬鹿正直に巡回して一粒一粒更新したり削除即時解放したりとか
座標計算だけならいけそうだが、粒子の描画に処理が持って行かれるだろうね。
描画関数に渡すパーティクル用のデータ構造と明らかに違う状態だから そのセットアップもあるしね。まぁ、いずれにせよ、何でそんな馬鹿な 想定を持ち出すんだと閉口するような話に持っていかないと処理速度上の 問題で横槍いれるのは難しいと思う
>弾幕ゲーのように数フレームごとにオブジェクトの生成や消滅や数十個レベルで起こるとして、 >それは使うとまずいレベルなのか? そういったありきたりの仕様だけを想定するなら、都度new/deleteもあつらえ向きだろうな。 しかし熱望する仕様を満たす可能性を最大化する作法には程遠い。
認めはしたものの悔しいから含みを残す言い方で跡を濁す。 これもいつものパターン。 お疲れ様。
お疲れー、次誰かデザインパターン講座オナシャス
趣味でPCで作ってるならなんでもいいよ。 自分のPCで動けばいいんだから。 でもプロ目指すなら他のプラットフォームに 移植しやすい設計にしとけって話。
>>927 お前誰だよ?w、パターンて何だよ?
認めていないんだが。
仕様の話に向かわせているのはそっちだろ?
俺の時間を返せ。
新年早々、やれやれだぜ
>>930 ヒープの使用が駄目だというのが分かる、自前のフラグ管理とやらのコードを提示すれば解決するよ。
本当に出たら間違いだったと認めるし、非礼を詫びもするよ。
ほら時間がもったいない。
と、こう煽るのもいつものパターンで、絶対に出てこないのもいつものパターン。
だいたい2chにいる人間ならこのパターンは見ているだろう。
ここであきらめの悪い人間のパターンは、コードを提示せずに延々と認めずにいいわけを繰り返すんだよね。
同一人物では無いと思うんだけど、なんでこうも同じテンプレートなんだろう?
お前に礼儀など期待していない。思いあがるな。 同一人物とやらによろしくな。
>>932 私は間違いだと証明されたら認める用意はあるってだけだよ。
でも君は何があろうと絶対に認めるつもりは無いんだろう。
かといって対抗するソースを出すわけでも無く、
認めたくないからいいわけを繰り返す。
最初の方で言った通りのパターンになっただろう?
君は見事にそのテンプレートにはまった人間なんだよ。
これもお決まりパターンなんだけど一応。
断言する、いいわけは出ても絶対に実働するソースは出ない。
説明してることはまともそうなのに、余計な煽り語を入れて損するパターン。
どっかのチャットで二人で話し合ってろよマジ迷惑
ろくに検証しもせずに、脳内ソースで嘘偽りを並べ立ててる人間を見ると すぐにカッとなるのはその通り。 得をすることは無いだろうね。
>>933 ソース出さなきゃ認めないって、ちょっと違うんじゃねえの。
しかもお前の提示したソースの原型は、非常に単純な例だったよな?
実際には継承もあれば包含もある。コンストラクタ・デストラクタも走る。
「想定範囲内の環境で、想定範囲内の仕様が満たせるから正しい」ってのは、
デメリットの及ばない範囲にとどめましょうってしてるだけだろ?
つまりデメリットを認めてデメリットから逃げた仕様に収まってるんだよ。
俺はこういう殺伐とした流れ好きだな。ノスタルジックな香り
こういう俺にもわかるような話なら良いんだけど たまに自分には理解できないようなレベルが高そうな内容でドンパチやられると置いていかれる 勉強のチャンスでもあるから良いんだが
>>937 ほら、ソースを出さずにいいわけパターンでしょ。
なんでそんなに期待通りなんだろう。
これだけ何度も今後の行動を書いてあったのに、
その通りにしか動けない悲しさ。
>>937 >「想定範囲内の環境で、想定範囲内の仕様が満たせるから正しい」ってのは、
>デメリットの及ばない範囲にとどめましょうってしてるだけだろ?
>つまりデメリットを認めてデメリットから逃げた仕様に収まってるんだよ。
PCの場合、そのデメリットが及ぶ状況を引っ張ってくるのは難しいと思うなぁ
特にこのスレの場合、ざーっと流し読みしてみた限り、個人制作の学生さんが
ターゲットぽいし。UEとか重量級のゲームエンジンを使わない古風というか
こじんまりした素朴な組み方してそうなのが多いみたいだし
>>941 逆に言えば個人製作程度のものならそんな意識する必要ないのかな
パッケージで出すならパフォーマンスを最大限出す方法を使わない理由はないんだろうけど
お前らまだやってたのか。 流し読みしたが話もかみ合ってねーし。 ほんと無駄に一日過ごしてしまったな
なんか、正月早々荒れてるなー。 まぁ白味噌のお雑煮でも飲んで落ち着け。
>>944 雑煮が味噌汁とかwww そっちの方が荒れるわ
>>941 重量級のゲームエンジンなんか使ったら、
それこそヒープの確保なんて大海の米一粒になってしまうから、
あえてそういう想定にしたんだけどね。
とりあえず断片化の弊害をひとつ int1億個分の配列用意して添字0~10万までインデントするプログラムと 添字を1000ずつ増やして10万回インデントするプログラムを比べると 断片化したときにどれくらい実行速度おそくなるか見れる かなり極端な例だけどねw
>>945 ほざきやがれ。白味噌こそ至高。超はんなり。
インデント・・・?
かなり極端なインクリメントだけどねw
#include <iostream> class Inner{ public: void delete_self(){ //delete this; //自身をdelete //this = NULL; //自身をNULL(左はエラー) }; }; class A{ public: A(){obj = NULL;}; Inner* obj; }; int main(){ A a; a.obj = new Inner; //delete a.obj; //a.objをdelete //a.obj = NULL; //NULLを代入 a.obj->delete_self(); //a.obj内で自信をdelete,更にNULLを代入したい return 0; } クラスAのメンバInnerクラスをInnnerクラス内部からdeleteしてNULLを代入したいのですが そういったことはできるのでしょうか? できるのであれば記述方法を教えていただきたいです。
>>954 thisは自身のアドレスだから変更出来ないし、仮に出来たとしてもobjの値は変わらないから意味がない
innerに**selfでも定義してobjのアドレス渡せば出来なくもないと思うけど
普通にA内でやればいいんじゃないの?
スマートポインタにしない理由が無い
>>954 まずはメンバ関数名をgedatsu()にするんだ
スマートポインタっていうのは知らなかったです 調べてみますありがとうございました。
961 :
954 :2013/01/06(日) 11:43:32.66 ID:wNZdSJOn
↑
>>949 確かに3ms程度が計測出来た。
>>954 解決したのか。
>Innnerクラス内部からdeleteしてNULLを代入
って意図がよく分らんな。
親の変数を、子が直接いじれるとか、なんというか発想が「次世代型高級言語」だなw
しかし、そもそもその例でも外部からトリガしてるじゃん。
DWMに詳しい方いらっしゃいましたら教えてください。 DwmFlush()にて同期を取っているのですが ウィンドウサイズが一定以上になるといきなり30FPSに落ちてしまいます。 PCの性能的には余裕で60FPS出そうなのですが なぜこのように制限されてしまうのでしょうか?
スマポは自殺したい場合の根本的解決にはならん気がするのだが サンプルソースからはなんで自殺したいのかがわからんから そもそも自殺する必要あるのかもわからんけど
外部からメソッド呼んでるし自殺の意味が無いから管理をスマポに任せろて事だろ
よう分からんけど、難しそう
難しい
sharedとweakで安全に自殺出来ないかね? 自分自身のshared持っといて参照側はweak使うとか
thisをshared_ptrに変換できるクラスを作るには特殊な手順が必要だった気がする
C言語でゲームを作ってみようと思ってるんですが、 おすすめのゲームプログラムの本はありませんか? 私は8年くらい前にプログラムを少しだけやっていたレベルです。 今ではほとんど忘れてしまったので、 もう一度、初めからやろうと思っています。
初めからやるゲームプログラミングの本なんてない。 C言語本からやりなさい。
14歳からはじめるわくわくゲームプログラミング
昔やってたならどうかわからないけど CとC++の区別もわからない状態で「C言語でやる」って言ってるのであれば C++の概要を把握してもう一回どちらの言語でやるか考え直すべきだと思う それとは別の問題で、スキルアップや勉強目的ではないのに プログラミングやろうとするのは止めたほうがいいような気がする。 ただ単にゲームを作りたいだけならエディタを漁ってプログラミングにかける時間を ゲームデザインの勉強に割いたほうが良いと思われる。 その場合、プログラミングするにしても最悪C#にすべき
ゲームプログラミングにもよるからなぁ。 まさかコマンドラインでは満足しないだろうから、 基礎を固めた後にDirectXとか最低でもWindowsSDKとか。 或いはC++/CLIとかUnityとか。 そう考えればルート選択が昔と比べて随分複雑になったなぁ。
975 :
970 :2013/01/08(火) 21:49:19.65 ID:qf9zAEDF
皆さんありがとうございます
>>973 の言った通り、一度言語の概要を把握してから考えて見ます。
私は資格を取るため勉強し、尚且つ趣味で新しく始めようと考えていました。
考えてる時、過去にC言語やってたからそれで行こうと軽い感じで思い今に至りました。
自分が考えてるより難しいこととは思ってもいませんでした。
自殺するという手段にそれほどの合理性というか、価値があるとも思えないんだけど
例えばCOMなんかではそな仕組み上、delete thisは頻出のフレーズだったけど
このスレであがってる自殺したいケースというと、例えば
>>856 あたりかな?
あえて自殺するのは単に美醜の感覚なのかな
実はフレームごとに生成・消去(自殺)するとか、 どういう構造で管理してるのかイマイチよくわからんかったんだが、 オブジェクトをdeque構造で管理しているならあり得るかとも思った。 それとも配列で、入れ替え&ループカウンタずらしでもしてるんかな。 マシン性能に依存したタスクシステムってわけだな。
C言語ってことは組み込み系で働きたいの?
>>975 趣味でやるならCとDXライブラリ使って
>>972 にもでてる本(昔のは誤植が多い)で
とりあえずゲームを作ってみるのがいいと思う
作ってあとで
>>974 の言うようにいろいろある選択肢を選んでもいいし
>>973 のようにエディタを使うでもいいし
難しく考えるとなかなか前に進まず飽きてやめてしまう気がする
足りないと思った所をその都度足していけばいいと思う
>>979 あまり一般に知られてないけど、Unix系の業務インフラかもしれん
982 :
970 :2013/01/09(水) 21:42:18.38 ID:+PQ0+evL
>>959 趣味にしようと思っています。C言語を選んだのは、
昔、本屋でC言語の本を見つけ興味が沸き購入し、
C言語を少しやったからです。
>>980 とりあえず
>>972 の本を読んでみようと思います。
>>982 その本は俺もオススメだけど
ポインタや構造体がわからないレベルなら入門書を買うべきだと思う
ブックオフとか古本屋に200円とか300円とかでC言語の本売ってるよ
おや、こんなところに105円で入手したリッチなカニチャーハン本が。
>>976-978 >>856 のタスク処理ってのはよく知らんので、適当に当てずっぽうで敵とか弾とか
自機みたいなもの、ゲーム内のエンティティをC++で記述する話と推測してみると
恐らくゲーム内での外部入力(押し倒されただの何かぶっかけられただの)に対する
ゲーム内での応答(振る舞い)を記述する部分だと思うんだけど、こういう部分って
自身のメモリ操作とか詳細な手続きにはあんま関心ないと思うんだよね
例えば、自身が生成された時にどのようにメモリを割り当てられたのか
とか、どういうコンテナにどういう目的で自身が格納されたのか、とか
自身が役割を終える時はどういうコンテナから自信を削除するのか、とか
自身が割り当てられてるメモリは自身で開放してから処理返せよな、とか
裏方の仕事に深く関与→外部の仕組みを詳細に知りすぎ(アクセス権が強すぎ)
何でも詳細に記述できる代わりに、機能や責任が交錯・混乱してそうな予感は
するね。もう少し機能分割(責任分担)できるんじゃないかなとは思うね
削除する対象が結果として自分になるとか言ってるし わりと特殊なスタイルなんじゃないかなぁ
>>983 いやぁ、ポインタや構造体を理解するよりまず動くものを作れるようになるほうが
モチベーションは保てると思う。
そこで満足しちゃうと俺みたいに成長しないけど。
989 :
847 :2013/01/10(木) 09:47:57.02 ID:PPN997+E
私の質問がまだ話題に残ってしまってるようなので、軽く事情を説明しといた方がよかったかな。 どういうときに自殺したくなるのかという話なんだけど、リストアップのときに必要になったんだ。 SLGで、世界がいくつかの地方に分割されている。各地方にはたとえば戦士、魔法使い、僧侶なんかの職業の人がいる。 ただしその地方にはある職業の人がいないかもしれないし、100人いるかもしれない。 で、その地方の詳細データを確認しようと思ったときに、各職業毎にまとめて一覧を表示したかった。 もちろん、その地方にその職業の人が何人いるかを確認して、結果を予測してからウィンドウを作り始めてもいいんだけど、それはちょっと気持ち悪い。 だから、とりあえず、「何人いるか知らないし、もしかしたらだれもいないかもしれないけど、適当に作り始めちゃってよ」ということにした。 それで、該当者が誰もいなかった場合にはその欄自体を消したかった。 もっと別な方法はあるだろうけど、該当者が多すぎた場合は新しい小ウィンドウつくって行を分けて表示したりとかの都合上、私の技術力だとちょうどいいレベルの方法だったんだ。
ゲーム内のキャラクターに対応したオブジェクトに処理詰め込んでるような設計だと自殺したいこともあるんじゃないかな 例えば被弾して削除したいときに、被弾の処理をそのオブジェクト自身がしてたらそのまま自分消したいよね でも管理するクラスちゃんと作り込んでたら自殺する場面ってなさそうだな
管理クラスがリストで保持してるアクターの位置を1つずつ更新して 終わったら1つずつ衝突判定して衝突があったら衝突イベントを 衝突イベントキューに予約しておいて全部の判定が終わったら 予約したイベントの中で重複したり無意味になるものを排除してから キューのイベントを1つずつこなしていって消滅するやつがいるなら 消滅フラグをたててキュー内のイベントが全部終わったら消滅フラグが 立ってるやつを消滅させるとすると自殺させる暇がないな
どうでもいいが「自殺したい」とか読むとドキッとするw
俺もビックリした、自キャラがか プログラミング切羽詰まって死にたくなっちゃったのかと
正確には自殺させたいだよな。
それもイジメみたいで嫌だな
クラスのメンバーが自分の子を殺す、とか定番ジョークだよね
で、次スレは? 携帯で立てるのは面倒なんだな
ありがたいにゃあ
1000ならC++が廃れてもう少し普通の人間に扱い易い言語に置き換わる
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。