09/11/04 19:50:08 WgLSvKP+
複数の敵キャラクタや弾などをどのように管理するか悩んでいます。
URLﾘﾝｸ(msdn.microsoft.com)
ここの「2.5 キャラクタ管理」にあるように、十分な数の構造体配列を用意し、
その中の有効/無効を表すbool値でゲーム上での出現/消去を管理する方式は、
感覚的に分かり易く、メモリリークの問題も起こり難そうに思います。
しかし、その他のコードを調査していると、STLのvectorやlist等を使い、
それらに敵や弾のクラスを格納しているケースもありました。
有効/無効の切替については、Active用のvector（list）、非Active用のvector（list）の
二つを用意しておいて、それらの間を移り替わることで対応していました。
（ゲームループではActive用に登録されたクラスのみ動かす）
どちらの方式にするかを考えてるのですが、
各ノードがクラスで構成されている（オブジェクト指向的な組まれ方がされている）場合は後者で、
そうでない場合はどちらでもよくて、統一的いすべて後者にするといった方針もあるかと思っています。
そのほか、複数のキャラクタ管理について気を付けておいたほうが良いことなどがありましたら、
ご教示願います。
ゲームデザインとしては、各キャラクタグループ相互の関わり合いが多いものになる予定です。
（敵キャラ、自キャラ、弾の衝突判定など）
よろしくお願いします。 m(_ _)m
174:名前は開発中のものです。
09/11/04 21:02:26 K+5ruHbY
とりあえず全てリスト等で実装する。
それで特に問題になることはないから。
175:173
09/11/04 23:05:02 WgLSvKP+
>>174
ありがとうございます！
そうします！
176:名前は開発中のものです。
09/11/04 23:46:15 /Sz4AuHE
intの変数にビット単位で（32個の）フラグを立てる方法があると思うのですが，
32個ブール値を用意するのとの違いはありますか？
177:名前は開発中のものです。
09/11/04 23:49:46 /Sz4AuHE
intというのは例えばです．
ブール値を使う方が短絡な分直感的だし，
別々の変数名を付ける方が分かりやすいように思いました．
178:名前は開発中のものです。
09/11/05 00:22:54 5+rWBuJO
ビット単位でフラグを立てる方法の方が、メモリーの節約にはなる。
まあ、メモリーの節約を気にする必然のある環境は少ないけどな。
179:名前は開発中のものです。
09/11/05 00:26:41 Vo34wPi1
>>177
まあブールのほうが作法としては行儀がいいと思うね。
あとintでもこんな方法で1ビットずつ変数名は付けられる。
struct
{
unsigned int a_flag:1;
unsigned int b_flag:1;
unsigned int c_flag:1;
unsigned int d_flag:1;
unsigned int e_flag:1;
unsigned int f_flag:1;
・・・
180:名前は開発中のものです。
09/11/05 02:28:38 eJ3mIolJ
フラグを初期化したいときにintだと楽かな。
でもフラグが32個を超えると管理が煩雑になりがちｗ
181:名前は開発中のものです。
09/11/05 09:50:10 KI4+w2Dm
それ１ビットずつか
ユニオン使うんじゃないのか
182:名前は開発中のものです。
09/11/05 14:47:55 +rSTg+Ag
>>178
例えばリプレイを実現する場合なんかは、入力情報をintに変換・復元できる。
キーコンフィグを実装すればキー入力とゲームの応答の間に、なんらかしらの管理機構が挟まるからそこら辺で使えるし。
ただ、まぁ無理して使う必要は無い。ビットフィールドな列挙型も同様。
183:名前は開発中のものです。
09/11/05 16:28:19 SNIE/4Rt
某所からの転載
＞3Dゲームの制作ツール、Unityの下位グレードが無料化。
＞PhysXが使えてシェーダーも40種がビルトイン、チュートリアルも完備。
＞総売上が10万ドル以上の法人は除く、という条件付だけど
＞大半の同人サークルは引っかからないだろうから、
＞3Dゲームの頒布を考えているサークルさん、いかがでしょ。
＞
＞Unity Technologies Launches Version 2.6 of Its Platform and Makes Unity Freely Available
＞URLﾘﾝｸ(unity3d.com)
すごくよさそうなんですけど、Unityの本スレってありませんか？
チュートリアルも全部英語なので、日本語での情報がすごく少なく困ってます。
184:182
09/11/06 02:37:08 qMwKFyiY
過ぎた話題だけど安価ミスった。>>176へですな
185:名前は開発中のものです。
09/11/06 13:19:49 hajLFQ96
シビアに高速化をやるときはキャッシュアクセス考慮するのでintに押しこんだりする
186:名前は開発中のものです。
09/11/06 16:37:00 kEmsEn+Q
intは、整数値を扱うときに、一番最適な値にデータ型を割り振ってくれるわけだしね。
とりあえずメモリロスは起きてもタイムロスは回避できるさ。
そして現代のPCならメモリなんて使い放題に近いさ。
187:名前は開発中のものです。
09/11/06 18:14:17 hajLFQ96
逆だよ
キャッシュサイズのこと言ってんだからintでboolの代用すんじゃなくて、intにブール値を詰め込むほうの意味
intにbool詰める・読む際に余計な演算が必要なるが、ここで必要となる論理演算は一般的に高速に処理できる
それよりも昨今のCPUのマルチコアの関係もあって、キャッシュミスヒット時のストールで待たされる時間のロスのほうがはるかに大きくなることがある
フラグ32個をint32個に入れずに1個のintに入れて処理すれば、キャッシュ内に収まりやすくなるので高速化できることがあるって話
188:名前は開発中のものです。
09/11/06 22:12:14 HsspV1xj
おおお、勉強になる･･･
メモリをふんだんに使えるとはいえ、高速化を目指すときはより小さなサイズにしたほうがイイんだね。
189:名前は開発中のものです。
09/11/07 09:17:22 gHawF7bm
そんな小手先の似非最適化をしたって、全体の速度は誤差程度も変わらないよ。
190:名前は開発中のものです。
09/11/07 10:11:51 Orb9rLPQ
効果は入れる前にある程度計算可能で効果が出るところに狙って施す
実際にMTフレームワークなんかでもキャッシュサイズを意識した作りをしてるわけだがそれも否定するのか？
191:名前は開発中のものです。
09/11/07 10:58:18 cV8cW+A4
虎の威を借りる前に、自分でやってみた結果を提示したらどうだ？
これだけパフォーマンスが変わったというのを証明すれば簡単に片がつくだろう。
192:名前は開発中のものです。
09/11/07 11:14:03 Orb9rLPQ
トラの威を借りるな、おまえの自分の成果をだせ
バカですか？
193:名前は開発中のものです。
09/11/07 11:19:22 gHawF7bm
つまり検証も何もしていないというのは理解できたよ。
無いものを無いと証明するのは不可能に近いけど、
ある物をあるというのはそれを見せればいいだけなんだけどね。
194:名前は開発中のものです。
09/11/07 11:21:33 ZbG3kEz7
あのぉ、素朴な疑問なんだけど、
キャッシュヒット率を上げると速くなる
→ メインメモリと同じくらいの容量（数百MB）のキャッシュを積めば、
HDDへのページングが起こらないレベルであれば特に最適化しなくても速くなる
って理論上は合ってる？
言い換えると、
速い・小要領 <- キャッシュ（SRAM） - メインメモリ（DRAM） - HDD -> 遅い・大容量
これのメインメモリをすっ飛ばした構成
速い・小要領 <- キャッシュ（SRAM） - HDD -> 遅い・大容量
まぁ、そんな量のSRAM積んだら、恐ろしい値段になるだろうけどｗ
195:名前は開発中のものです。
09/11/07 11:53:36 Orb9rLPQ
> 無いものを無いと証明するのは不可能
>>187に速くなる根拠があるんだから、その間違いを示せば証明できる さあばんがれ
なんら反証はなく、自分の経験だけで速くならないって言い張ってるだけじゃないよね？
>>194
それだけ大容量ならキャッシュとしてヒットさせる必要は無くて、高速なメインメモリとして使えばいいので当然速くなるだろうね
SRAMの制限まではよく知らないけど、何億もするコンピュータでも全SRAM構成にしないとこをみると、何制限があってできないのかもしれないね
ただ、上にある話題はキャッシュサイズの話しかないけど、CPUがストールする要因はほかにもたくさんあるので、それらも合わせて何とかしないと効果は薄いかも
196:名前は開発中のものです。
09/11/07 12:27:09 gHawF7bm
>>195
＞速くなる根拠がある
これは否定してないよ。
単にフラグをビットで管理したところで、誤差でかき消えてしまう程度しか変わらないといっているんだけど、
ではいったいどの程度のパフォーマンスアップが期待できるというのか明確にしてくれ。
197:名前は開発中のものです。
09/11/07 12:36:18 gHawF7bm
そもそも何を突っ込みたいかというと、最適化云々やCPUの挙動を論じる奴が、
木を見て森を見ず、局所的な部分のみが多少速くなることに悦に入って、
全体でみれば実際は何の役にも立っていないことに気がつかない馬鹿だということ。
ぶっちゃけこれが一番言いたい。
198:名前は開発中のものです。
09/11/07 12:52:58 Orb9rLPQ
＞速くなる根拠がある
>これは否定してないよ。
君が、俺が「何の役にも立っていないことに気がつかない馬鹿」と思うかどうかは、俺にとっては(きっと見てる大部分の人間にとって)どうでもいいことなので、そう思うなら勝手に思ってくれ。
速くなる根拠の部分に何の反証もないなら何の問題もない。
>>187にもあるが、「高速化できることがある」としか言っていなくて、どんな条件でも速くなるとは言っていない。
特定の条件下でパフォーマンスの改善が期待できるとは間違いなく、MTなどの市販製品でも考慮されていることは
そもそも、intにブールを入れるか、intをブールとして使うかの違いについてのレスとしては183
199:名前は開発中のものです。
09/11/07 12:56:32 Orb9rLPQ
すいません、途中で送ってしまった。
下3行は書きかけ
>>187にもあるが、「高速化できることがある」としか言っていなくて、どんな条件でも速くなるとは言っていない。
特定の条件下でパフォーマンスの改善が期待できるとは間違いなく、いろいろな情報からも、MTなどの市販製品でも考慮されていることからも、十分確かと考えていいだろう
そもそも、intにブールを入れるか、intをブールとして使うかの違いについてのレスとしては>>183でなんの問題もない。
200:名前は開発中のものです。
09/11/07 15:58:19 M1hO6X0P
ハードウェア側のことを考えて
32bitの環境なら32bit型をなるべく使うのは結構重要なことなのに
「役に立ってない」と完全否定できる奴はすごいな
201:名前は開発中のものです。
09/11/07 16:12:38 vkeQqaC1
あえてそこまでストイックになる必要がないってだけじゃないの？ 少なくともゲーム製作を語る上では。
お互いに相手の言い分もわかってるだろうに、わざわざ議論始めなくてもいいよ。
202:名前は開発中のものです。
09/11/07 16:25:32 Orb9rLPQ
まあ適材適所で必要なときだけ必要な個所でやればいいと思うよ
最適化ってそういうもんだし
なんにしてもしょうもないやり取りでスレ汚してすまんかった
203:176
09/11/07 23:44:19 Xs7tndnq
レス有難うございました．
>179
自分の勉強不足でしょうか．．．
intサイズの変数が並んでいるように思うのですが，
1ビットずつの命名が実現できているのでしょうか？
>180
>182
boolで構造体を作って，memset, memcpyで操作するのと
違いが出にくいように思いました．
無理して使う必要はない，と言うことであればそれまでなんですが．
>200
個人的にこの言い分がしっくり来ました．
他のいくつかレス頂いた分も，これに終始すると思いますし．
また，潜在的な疑問でしたが，
必要な真偽値がきり良く32個になることなんてまずないから，
シビアに弄ってる一方で，ビットの未使用分が気になっていたので．
有難うございました．
204:名前は開発中のものです。
09/11/07 23:49:19 pD8Hg5wM
> >179
> 自分の勉強不足でしょうか．．．
ビットフィールドだからC言語だね。
205:名前は開発中のものです。
09/11/07 23:53:56 Xs7tndnq
>204
勉強不足でした．．．；ありがとうございます．
206:名前は開発中のものです。
09/11/08 10:28:20 jVF9AtCS
結局何が聞きたかったのかよくわからない質問だったな
207:名前は開発中のものです。
09/11/08 10:56:38 3Syd0d+d
ここで激論を戦わしている人達は、アセンブラを知っているの？
CPUの汎用メモリは数個程度だから、ある変数をメモリにロードしても、
そのメモリに別の変数がロードされたら、またロードし直さないといけない
結局の所、メモリの使われ方は、アセンブラを見ないとわからんよ
マイコンのプログラムなんて1行ずつ、どのメモリを使うか確認しているんだから
208:名前は開発中のものです。
09/11/08 11:11:15 5bB/LHM4
DOS時代とかデバイスドライバ、マルチメディア系の最適化ではなく、
マイコンを例に挙げてくるあたり、頭の悪さを露呈しているのがよく分かる。
209:名前は開発中のものです。
09/11/08 11:24:07 jVF9AtCS
そういえば、64bitになってから拡張された上位分や、MMXやらSSEで増えたレジスタって汎用には使えないのかな
register指定でその辺のも使ってくれれば、結構な数がそろうと思うんだけど
Itaniumでも使えばもっとレジスタ使えるんだろうけど、Itaniumマシンはサーバ以外で使われそうにないし
210:名前は開発中のものです。
09/11/08 11:46:34 ENtK6awO
>MMXやらSSEやらで増えたレジスタ
浮動小数点のレジスタをまんま使用してるんじゃなかったっけ？
211:名前は開発中のものです。
09/11/08 11:48:04 u9PsEAnz
Itaniumを使わなくても、EM64TやAMD64で汎用レジスタの数が増えているんだが、
いったい何を言ってるんだ？
しかも今の時代、コンパイラでregister指定をしても、
逆に無駄が増えるか無視されるかという結果にしかならない。
212:名前は開発中のものです。
09/11/08 12:29:07 jVF9AtCS
>>210
ああ、共通で使ってるんだっけ
なんかそんなのを聞いたことがあったのを思い出したよ
>>211
増えた汎用は汎用で使ってくれればそれでいいんだけど、
Itaniumにすれば汎用レジスタがもっとたくさん増えるだろ？
それだけの話だよ
>しかも今の時代、コンパイラでregister指定をしても、
>逆に無駄が増えるか無視されるかという結果にしかならない
これはよく聞く話だけど、実際どうなるかはコンパイラ依存だよね
無視されるならまだいいと思うけど、無駄が増えるって具体的にどんなコードが吐かれるの？
213:名前は開発中のものです。
09/11/08 12:41:13 BFD52Z6T
PCをターゲットにするのに今時アセンブラなんてあんまし関係ないと思うが。
キャッシュ操作を命令で出来れば早くなりそうだな。
214:名前は開発中のものです。
09/11/08 14:38:24 ENtK6awO
キャッシュは自前で操作したいよな。つ～か一体、どんな状態になってるんだか。
215:名前は開発中のものです。
09/11/08 18:54:01 2FC+r2WV
どこで質問すればいいのか迷った、
というか所謂初心者なのでどう質問すればいいのか上手く説明できませんが質問させてください。
よくある戦略SRPGで、敵(CPU)の行動でこちらの敵に向かわせる際、
川や山、障害物など通れないマス目を避けて進ませる方法が上手く思いつきません。
さすがに大まかすぎて回答してもらうのは難しそうなので、
そういった、AIというのでしょうか、CPUの行動させかたを上手く解説しているところ、
もしくは参考にできるような題材やリンクはありませんでしょうか？
216:名前は開発中のものです。
09/11/08 18:56:42 49+a80li
自分もちょうどそれが気になってたところ･･･
217:名前は開発中のものです。
09/11/08 18:58:32 9QV4n3ah
>>215
URLﾘﾝｸ(www.jyouhoukaiseki.com)
こことか。
218:名前は開発中のものです。
09/11/08 19:02:24 hbP1+XQi
オライリーの「実例で学ぶ ゲームAIプログラミング」という書籍に経路探索が出てたと思う。
とりあえずマンハッタン距離、経路探索くらいのキーワードで調べてみるとか。
219:名前は開発中のものです。
09/11/08 19:07:17 2FC+r2WV
10分も経たないうちに回答してくださってびっくらこいた
>>217-218
ザッと見たところ、どちらも参考にできそうな説明がされておりました。
あとは自分で考えて発展させていけばなんとかなりそうです、どうもありがとうございます。
220:名前は開発中のものです。
09/11/08 19:07:28 hbP1+XQi
抽象的な概念でいえば、グラフ理論を学べばできるようになると思う。
221:名前は開発中のものです。
09/11/10 18:19:12 PeiW8ICh
何だかわからんが、議論の経過は華麗に無視して結論。
・boolean型のフラグは、byteで持つよりbitで持った方が
全ての面で優れています。bitで持つようにしましょう。
操作が煩雑なら、std::bitsetやboost::dynamic_bitsetを使いましょう。
以上終わり。
222:名前は開発中のものです。
09/11/10 18:54:49 m+B8PjQ8
>>221をかいつまんで説明すれば、億万長者が一円玉を拾い上げるのと同じだということ。
腰を曲げるぶんだけ損しているかもしれない。
以上終わり。
223:名前は開発中のものです。
09/11/10 18:56:33 iR0qXcSq
全ての面で～などと簡単に言う人間の言葉は、全ての面で信用ならねぇ
224:名前は開発中のものです。
09/11/10 19:02:45 kkW4R7qN
ゲーム製作でお約束の豆知識
何の判定でもいいが、フレーム単位でするのは御法度である。
何らかの理由でフレームとしての描画が遅れると判定も遅れるからである。
普通は、タイムスライスなどの時間判定で行う。
時間なら、描画が行われていなかろうが何だろうが
時間が来れば強制的に判定するからだ。
これは兼ね合いの面も強いのであまり多用すると処理速度に悪影響を与えるが
よりクリティカルなところでは時間で判定しないとロクなことにならない。
225:名前は開発中のものです。
09/11/10 19:12:03 C6i0KrhP
URLﾘﾝｸ(www.wacharo.net)
ここを参考にしてJAVAでテトリスを作るんですが、
アプレットではなくてアプリケーションで作成したいと思っています。
ですがアプレットとアプリケーションの互換性などが全く分かりません。
作ってからアプリケーションに簡単に変換することができるんでしょうか。
ためしに上記のサイトのレベル１と書かれてる部分からextends Appletなど抜くと
他も使えなくなる部分が出てくるんですが。
アプリケーションでJARファイルにして実行できるようにしたい場合は
他のサイト参考にしたほうがいいんでしょうか？
見ておいたほういいサイトなどあれば紹介お願いします。
226:名前は開発中のものです。
09/11/10 19:26:28 33hrI6K4
VC++で、directX(dxlib)を使っています
リフレッシュレートに左右されぬようFPSを固定する技法を使うと、
等速直線運動しているだけの画像がカクカクとスムーズでない動きをしています
理由は理解しているのですが、明確な解決方法がググってもどこにも載っていません
（移動距離をリフレッシュレートによって変更するという技法はありますが、その他全てを変更するのは無理そうです）
これはつまり、カクカクなのはしょうがないと言うことなのでしょうか。
東方等大手も仕方が無いこととして適当に諦めてるのでしょうか。
それとも、何か解決法（orマシになる方法）などあるのでしょうか。
（dxlibを使っては不可能なのでしょうか）
よろしくお願いします
227:名前は開発中のものです。
09/11/10 19:40:07 iR0qXcSq
>>225
ググったら、こんなのあったけど
URLﾘﾝｸ(wisdom.sakura.ne.jp)
228:名前は開発中のものです。
09/11/10 20:10:08 WSBQhFY6
経過フレーム数ではなくて、経過時間でアニメーションするように変更する。>>226
229:名前は開発中のものです。
09/11/10 20:20:35 33hrI6K4
>>228
ありがとうございます。
すると、ほとんどのゲームソフトはそういった仕様になっているのでしょうか。
自分はカクカクなのが許せないと言うよりは、大多数の手法と同じ手法を用いたいのですが……。
230:名前は開発中のものです。
09/11/10 20:30:16 WSBQhFY6
リフレッシュレートに依存しないとなったら、ほとんどがそうだろ。
231:名前は開発中のものです。
09/11/10 21:55:03 1FCcgIbf
>>215-220
オライリーの「ゲーム開発者のためのAI入門」とその続編の
「実例で学ぶ ゲームAIプログラミング」
ゲーム・プログラマーで、この2冊を読んでいない人はやばいよ。早く読みな
>>225
アプレットはブラウザの中で実行するから、色々と面倒な設定をしないといけない
それを考えれば、アプリケーションの方がずっと簡単
新たにアプリのプロジェクトを立ち上げて、ソースをコピーすればよい
232:名前は開発中のものです。
09/11/10 23:44:40 VPqZVDvF
>>227
正直アプレットとして使う必要が無いので、
アプリケーションでのみの動作を考えたいです。
そしてそのリンクの中身ですら難しいと思えるレベル・・
>>231
それやってみたらpublic void initの中身のsetSizeやらcreatImageやら
よくわからない所がエラーででててMainで未定義です、とエラー文がでます。
initをmainに書き換えても同様のエラーなので構造が分かってないからでしょうか。
丸写しするつもりはないんですが課題の一部なので、
流用する部分が多いかもしれません。
調べてみるとアプレットはinitで定義してアプリはmainという風な理解の仕方と
どこかで見たような気がするんですが。
ocn規制されたのでこの書き込みは代行です。暫く出て来れません。