[過去ﾛｸﾞ] ゲームプログラミング相談室【Part5】 (970ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
231(1): ぽぷり 03/02/10 16:27 ID:6VC5i/Lt(1/2) AAS
最初からココで聞いたらよかったかな。
あと２箇所に書き込んだマルチだが良かったら質問よろしく頼みます
いまFF4のパクリ作ってるんだけど戦闘の曲を.wmaで作った。
で、これをループでエンドレスで流すわけだが
そのまま初めのフレーズ（ダダダダ、ダダダダ・・・・）に戻ってしまう。
この曲は1分54秒まであるんだが
俺としては０：００から１：５４まで流した後
省6
232: デフォルトの名無しさん 03/02/10 16:28 ID:sFeXOrcI(1) AAS
ゲームで時間のかかる処理をしていると画面の
キャラクターの移動などがズルッズルッと遅くなる。
これが処理落ちしているという状態。
時間内に処理が終わらないのを「落ち」といっているのでしょう。
この場合処理はとばしていません。
パソコンでよく見られるのが、処理が重いときに処理をスキップする
やつです。画面の更新がなめらかでなくなってカクカクして見えます。
233: あぼーん [あぼーん] あぼーん AAS
あぼーん
234: あぼーん [あぼーん] あぼーん AAS
あぼーん
235(3): 03/02/10 17:15 ID:xlyrLNIL(1) AAS
＞＞２３１
ＤｉｒｅｃｔＳｈｏｗでも、ＤｉｒｅｃｔＳｏｕｎｄでも、ＭＣＦでも、プログラム上で制御は可能だが…。
236: 03/02/10 17:25 ID:VY6anJSf(1) AAS
>>231
ﾏﾙﾁｳｾﾞｰ
2chｽﾚ:gamedev
2chｽﾚ:gamedev
237(3): ぽぷり 03/02/10 20:03 ID:6VC5i/Lt(2/2) AAS
>>235
ＨＳＰでは無理かな？
プログラム上の制御って、どんな項目で検索したらいいでしょうか？
238: 03/02/10 21:04 ID:pyEAMejp(1) AAS
>>230
処理落ちとコマ落ちについても >>218 のリンク先に
書いてるから読んでみ。
239: 03/02/10 22:04 ID:n899aQqE(1/2) AAS
>>237
>>235が十分なくらいキーワードだしてるよ。
MCI(MCFは間違いだよな？)、DirectSound、DirectShow
HSPはよく知らないが、
MCIはWindowsAPI、DirectSound、DirectShowはCOMが扱えれば大丈夫。
HSPがそれらを扱うのが難しい言語ならば、
他の人が作ったライブラリを使う手もある。
省1
240: 03/02/10 22:09 ID:n899aQqE(2/2) AAS
>>237
こんな方法もあるようだ。
外部ﾘﾝｸ:www.google.co.jp
241: 03/02/10 23:15 ID:+EgLsXBk(1) AAS
>>237
マジで氏んでくれ。
242: 235 03/02/11 00:32 ID:OEwInXkJ(1) AAS
ＭＣＦは間違い。
何やってんだ、俺。
243: 03/03/02 11:58 ID:1UsFLoT7(1) AAS
保守sage
244(1): 03/03/04 22:15 ID:QU9Qm2YP(1) AAS
敵の弾で曲がるレーザー系のを作って見たいのですが、
雰囲気としては一度敵機の近くでゆっくり動き、目標に向かって
早い曲線を描こうと思っています。おそらくゆっくり部分と狙撃部分の
２つのルーチンを使用するかとおもいますが、問題が２つほどありまして、
１）曲線が目標位置によってイビツになる。
２）レーザー表現を座標引き渡しで２０個ほど丸オブジェクトを使用
したので、処理が遅い。
省1
245(6): 03/03/08 01:35 ID:AeESF41/(1/4) AAS
見た目だけクォータビューで、内部的にはトップビューなゲームを制作中なのですが、
座標を四十五度回転させてから上下半分に潰して表示している為に、見た目上上下の移動が遅く、左右の移動が早く見えてしまいます。
こういう場合、みなさんどうしていますか？
246: デフォルトの名無しさん 03/03/08 01:52 ID:omw6bur7(1/2) AAS
>>244
遅レスだけど。
1)
float f = atan2(目標とのyの差, 目標とのxの差) - (現在の進行方向);
while (f<-3.14) f += 3.14*2;
while (f>3.14) f -= 3.14*2;
(新たな進行方向) = (現在の進行方向) + f*(曲がり具合0.0〜1.0);
省4
247(1): 03/03/08 01:58 ID:Qzt+JfAG(1/4) AAS
>>245
画像にかけた、縮尺を移動量にもかける。
上下が左右の50%なんだろ？
じゃあ、移動量も50%でいいじゃん。
つーか、それ
クォータービュー風表示で、内部がトップビューって言うか？
一瞬意味が分らなかった。
248: あぼーん [あぼーん] あぼーん AAS
あぼーん
249(1): 245 03/03/08 03:30 ID:AeESF41/(2/4) AAS
>>247
お返事有り難う御座います。
内部でのベクトルも表示時には四十五度回転しているため、
それではうまくいかないのです……。
（内部的に下にすすめが表示上は左下に、右に進めば右下に進んでいるように見えます）
内部のマスは正方形ですが、表示時は菱形なので移動量がおかしくみえるということなのですが……。
250(1): 03/03/08 04:03 ID:Qzt+JfAG(2/4) AAS
>>249
その処理だと、クォータービューって言わないじゃん。
つまり、クォータービューって斜め見下ろし型でしょ？
君の言ってる移動処理は、トップビューでただ45度回転してるだけだよ。
それでは、描画と移動処理が噛合う訳が無いよ。
普通は、トップビューと同じ処理で、横長の菱形MAPchipやなんかを
用意してキャラをMAPchipより手前にずらして立たせて
省11
251(1): あぼーん [あぼーん] あぼーん AAS
あぼーん
252(2): 03/03/08 04:10 ID:tiy6mV84(1/3) AAS
すべての方向に対して、同じ時間で移動できる場所に点を打ってその点を補完して線にする。
すると、君のプログラムでは、正方形が出来上がるわけだ。
ところが現実には円になることが期待される。
君のプログラムは、内部的には「円を正方形で近似している」んですよ。
そのまま表示すれば、移動方向によって速度に変化が生じるのは当たり前。
対策は、内部のプログラムを書き直して円を円として扱うようにするか、
あるいは円を八角形で近似するように書き直すか、
省2
253(1): 252 03/03/08 04:12 ID:tiy6mV84(2/3) AAS
ごめん勘違い。
無視してください。
254(1): 03/03/08 04:32 ID:Qzt+JfAG(3/4) AAS
ん？やっぱさ247で言ってる通りでいいじゃんか。
君の描画処理って45度回転して上下に潰すっていてるよね？
その言ってる正方形ってのがMAPなんだろうが、
移動ベクトルにも同じ処理してないじゃん。
上下に潰すって事は、Y軸方向にスケールをかけてる訳だ。
そのY軸方向のスケールを、移動ベクトルにもかけてるか？
つまり、移動ベクトルはX成分はそのままで
省2
255(2): 03/03/08 06:00 ID:MKbGXKwx(1) AAS
画像が欲しいとこではある
256(1): 245 03/03/08 09:51 ID:AeESF41/(3/4) AAS
>>250-255
真面目にレスいただき、ありがとうございます。
意味がわからない面も多々あり、申し訳ありません。
画像は用意したいと思うのですが、よかったらどうかお待ちください。
マップ自体は見た目上だけクォータービューで、
（画像は潰しておらず、べた表示です）
キャラクタの表示する座標だけを描画時にマップの端を軸に４５度回転させて、
省12
257(2): 245 03/03/08 10:29 ID:AeESF41/(4/4) AAS
ちなみにイメージ図は
画像ﾘﾝｸ[jpg]:www.geocities.co.jp
な感じです。
マップの描画などは全く視野に入れません。
258: 03/03/08 11:16 ID:tiy6mV84(3/3) AAS
>>257
そりゃああた、パースを考慮に入れてないからっす。
普通の二次元画像を斜めにして単純に潰すと、絵としておかしくなる。
だから、その絵としておかしいMAPの上で正しくキャラを動かしても絵としてはおかしくなる。
この世には遠近法というものがあって、遠くのものは小さく、近くのものは大きく見えるのが世界の常識です。
実際には遠近法を考慮しなくてもそれなりに綺麗に見えるものなのですが、
奥行きが深い場合はちょっと不自然に見えます。
259: 03/03/08 11:18 ID:Qzt+JfAG(4/4) AAS
>>257
やっぱり247と254で言ってる通りじゃんよ。
で、君の言ってる事が意味が通って無い。
まず、最後に潰そうが何しても、移動量ベクトルの”大きさ”は
四方向で”同じ”だ。差なんて無いじゃん。
つまりベクトルで言うと
上(0, 1)
省16
260(2): 03/03/08 11:24 ID:HkNGp/2b(1/2) AAS
斜め上から正射影で見た状態やね
>>245
>見た目上上下の移動が遅く、左右の移動が早く見えてしまいます
上下と左右の見た目スケールが違うんだから、
そう見えてしかるべきなんでは？
見た目で同じスピードにすると、
実マップ上での移動速度がヘンになる(軸により偏りがでる)けど
省1
261(1): デフォルトの名無しさん 03/03/08 11:38 ID:omw6bur7(2/2) AAS
表示の座標から見て、「上下」と「左右」の移動に差が出るってことは、
内部の座標から見て、「上下左右」と「斜め」の移動に差がある。
…あってるのかわからんけど。
それなら、内部座標から見た「斜め」方向への移動を減らせばいい。
なんか、気持ち悪いけど。
リロードしたら>>260と同じだった…
さらに読み返すと、楕円に進む と同じようなこと言ってる気もする。
262(1): 245 03/03/08 11:54 ID:9W7WzJNL(1) AAS
皆様レス有り難うございます。
>>255
パースは一応理解しているのですが、
２Ｄとして不自然でないように取り入れるにはどうしたらいいのかと思いまして。
>>256様
そうですね、内部的なベクトルの大きさは同じです。
でも、見た目上の（プレイしている側からしてみれば）違っているように見えてしまいますよね。
省8
263: 03/03/08 13:03 ID:HkNGp/2b(2/2) AAS
うーん、画面がしっかり傾いているように見えれば、
ヘンには感じないと思う。そう印象付けるような画面構成にするといい。
車の後ろから見るレースゲームで、等間隔にオブジェクトを配置したり
等間隔に地面に模様をつけるのは、走ってるという感覚を引き出すための
基本テクニックだったりする。のっぺりしてると速度感が沸かないのよ。
クオータービューについてもそういう工夫があっていいんじゃないかなあ。
264: あぼーん [あぼーん] あぼーん AAS
あぼーん
265: 416 ◆quHoSW/FCI 03/03/08 16:20 ID:s3TXU6Pq(1) AAS
>>262
もしかして、トップビューで言うところの斜め移動をさせてない？ トップの
上下左右はクォーターでは斜め45度だが、トップでの斜めはクォーターでは
真横とかになるよね。
移動がマス方式のクォータービューでは斜め移動はそう見える。A列車3、4で
列車が真横に移動するのと、斜めではえらく差があるように。
266: あぼーん [あぼーん] あぼーん AAS
あぼーん
267: あぼーん [あぼーん] あぼーん AAS
あぼーん
268(1): 03/03/13 14:53 ID:x1k2yze2(1) AAS
春休みとDirectX8を利用して、Ys3っぽいべたなアクションゲームを作ってます。
描画周りは一通り出来たのですが、ここで疑問が・・・
キャラが動いたときの描画なのですが、
既に配置済みの背景の中を、ビュー行列を変えて移動させるのと
ビュー行列据え置きで、キャラ周りの背景を移動するたびに配置換えする
一般にどちらが良いのでしょうか？
前者の方が簡単そうにみえ、今はそちらなのですが、
省2
269: あぼーん [あぼーん] あぼーん AAS
あぼーん
270(1): 03/03/13 22:12 ID:M64nHos+(1) AAS
>>268
Ys3って横から見たような画面構成だっけ？
PC88やPC98はマップチップを組み合わせて画面を構成してたと思うけど、
（つまり後者）それほど難しくないよ。
271(1): 03/03/14 00:05 ID:1VLZD/pC(1/2) AAS
>>270
レスありがとうございます。やはり後者でしたか＿|￣|○
PC88やPC98ではと言うことですが、今はあまりこういう手法は用いないのでしょうか？
しかし、やはり効率的な描画方法っていうのは、今も昔も変わらなそうですね。
画面は仰るとおり、横から見たようなのです。
私はこれとリンクの冒険が大好きで・・・。どっちも一般にはアレですが・・・。
272: 03/03/14 00:06 ID:1VLZD/pC(2/2) AAS
すいません、あげてしまった・・・。
スクリプト荒らし来ちゃうかな・・・。
273: 03/03/14 01:24 ID:41+v9X+W(1) AAS
>>271
ＧＢとかのＢＧ面があるゲーム機は今でもそんな感じ。
背景がモデルならば仕様次第な気もするけど、似たような事をやらなくも無い。
274: あぼーん [あぼーん] あぼーん AAS
あぼーん
275: 03/03/14 03:08 ID:MgAhF4Kv(1) AAS
外部ﾘﾝｸ[html]:www.asahi.com
によると、ＰＳ３はプロセッサ72個を使用するらしい。
ＰＳ２のcoreとVU0,VU1の三つでも、効率の良い並列プログラムは
難しいのに、72個ものプロセッサを使いこなせるプログラマは
果たして存在するのか？
276: 名無し募集中。。。 03/03/14 05:14 ID:fXoEalJM(1) AAS
１個だけでゲームの処理を担当。
もう一つで効果音などのサウンドを担当。
残りはすべてポリゴンの座標計算
277: あぼーん [あぼーん] あぼーん AAS
あぼーん
278: あぼーん [あぼーん] あぼーん AAS
あぼーん
279(1): 03/03/15 03:20 ID:i28WpAET(1) AAS
1タスクに1個のプロセッサでいいんじゃないの？
280(1): 03/03/15 11:30 ID:dtuvcX+v(1/3) AAS
３角形のポリゴンと、直線の交差判定をするC++の関数を誰か作ってください。
bool func( Vector p1, Vector p2, Vector p3, Vector l1, Vector l2);
こんなかたちで、p1,p2,p3がポリゴンの頂点、l1,l2が直線の両端座標です。
Vectorは構造体かクラスで、x,y,zの座標を持っています。
交差してたらtrue、してなかったらfalseを返すというものです。
お願いします。
281: 03/03/15 12:13 ID:CBUe4G93(1) AAS
>>279
プロセッサ間の同期処理だけでほとんどのCPU時間が消費されそうな予感
並行処理できるならハナっからそういう単位で仕事をする
高速なプロセッサに分けてくれたほうがマシと思う
>>280
アルゴリズムを書いてくれたら、関数を書くよ。
できるだけ詳しく頼む。
282(3): 03/03/15 12:39 ID:FEgToVwJ(1/2) AAS
3Dの座標をスクリーンの座標(0-639,0-479)に対応させたいんですが
どうすればいいですか？
カメラを移動させて試行錯誤しておおまかには合ってきたのですが
どうしても左上が(0,0)、右下が(639,479)にビシっとあってくれません
283: ひよこ名無しさん 03/03/15 12:41 ID:5k0LvKxN(1) AAS
(,,ﾟДﾟ)外部ﾘﾝｸ[html]:www.geocities.co.jp
284(1): 03/03/15 13:17 ID:dtuvcX+v(2/3) AAS
>>282
はじめから２ｄスプライト使えばいいのでは・・・
DirectXでテクスチャ貼って使うなら
柔軟な頂点定義でトランスフォーム済み頂点を持つの定義して
ポリゴン２つ作って貼ればいいのでは？
285(1): 03/03/15 14:42 ID:P8D5lOXq(1) AAS
>>282
昔Ｃマガでそれを実現する記事があった。
外部ﾘﾝｸ[html]:www.cmagazine.jp
俺はこれを参考にしたよ。
286: 03/03/15 18:02 ID:FEgToVwJ(2/2) AAS
>>284
>>285
ありがとうございますっ！！
2Dスプライトを3Dオブジェクトに置き換えたかったんです
説明不足ｽﾏｿ
Cマガジン持ってたので解決できそうです
やりたいことがほぼそのまま載ってました
省1
287(1): 03/03/15 18:02 ID:G8v9XCRO(1) AAS
AA省
288(1): 03/03/15 18:37 ID:dtuvcX+v(3/3) AAS
>>287は２ｃｈ初心者？こんな古いＡＡどっから持ち出したんだ
289: あぼーん [あぼーん] あぼーん AAS
あぼーん
290(1): 03/03/16 08:39 ID:fbjaAIcC(1) AAS
>>288はゲ製作技術初心者？こんなAAにいまどき反応しだして
291: 03/03/16 09:24 ID:zCeAM5Bb(1) AAS
>>290
オレも全く同じ事思ったが、
スクリプト荒らしを擁護してるように思えたから、書き込みは控えてたよ( ´∀｀)
292(2): 03/03/16 10:04 ID:SkJQDRqn(1) AAS
クドリャみたいなブレードとショットを使うＳＴＧつくってるんですが
ブレードの衝突判定がうまくできません。
普通に判定すると連続ヒットになるので
当たったキャラに無敵時間をつくったらショットがすり抜けてしまいました。
ブレード判定外へ敵をヒットバックさせれば解消できるんですが
それだとブレードコンボ(連続技)が表現できない…
仕方ないので最初に戻ってブレード攻撃力を低く設定し直したら
省3
293(1): 03/03/16 10:21 ID:rJlwcwid(1) AAS
> 無敵時間を
これをブレード？への判定無効フラグにすればいいんじゃなかろうか。
294(1): 03/03/16 12:05 ID:SUE/S+f7(1) AAS
外部ﾘﾝｸ:www.kmkz.jp
のNonameSTGを参考に
295: 03/03/16 16:18 ID:FATlrtEb(1) AAS
AA省
296: 03/03/16 16:52 ID:KY0wD066(1) AAS
>>282
方法１）
D3DXSPRITEを使う。
方法２）
TLVertexを使う。D3DFVF_XYZRHWが含まれてる奴ね。
ヘルプに詳しく書いてあるから読んでみれ。
297: 292 03/03/16 18:15 ID:uI5iL2i7(1) AAS
>293
即レスありがとうゴザイマス（´Д｀;）ヾ
ＳＴＧしかつくった事がなかったので
ブレード→自機を追従するレーザー、多段＆複数ヒット
ショット→当たると消える、多段ヒットしない
としか認識してませんですた。
つーか…漏れｱﾌｫｹﾃｰｲ(；´Д`)
省5
298: あぼーん [あぼーん] あぼーん AAS
あぼーん
299: 03/03/17 06:06 ID:my0aeB3m(1) AAS
>>292
ブレードとショットで別々の無敵タイマーを持てば良いんじゃないの？
で、それぞれで無敵タイマーが無敵無効の状態の時のみ当たる事にして、
当たったら無敵タイマーセット。
300: 03/03/19 18:36 ID:GS4b6rrW(1) AAS
AA省
301: 03/03/24 12:16 ID:mmzhvCyj(1) AAS
攻撃中は複数の敵に当たるが、同じ敵には1度しかあたらない、
なんて仕様が来たことがあったな(なぎはらうっぽい動作で)
その時は、当たった敵をリストに追加して判定してたけど。
302: 03/03/25 01:44 ID:geV3sJ5n(1/2) AAS
あるゲームで見たホーミングレーザーが非常に綺麗だったので
目標につくっているのですが
どうも自分のはあまり綺麗になりません。
どんな風にやってるのでしょう？
これです。
外部ﾘﾝｸ[lzh]:forgamedev.zombie.jp
303: 追記 03/03/25 01:53 ID:geV3sJ5n(2/2) AAS
ホーミングレーザーの誘導の仕方とかではなく
アンチエイリアスがかったようにラインがとても綺麗な
ところをいってます。
304: 03/03/25 02:42 ID:aCstEDxO(1) AAS
トライアングルストリップはそのためにある。
305: あぼーん [あぼーん] あぼーん AAS
あぼーん
306: 03/03/25 06:35 ID:w7OmxNqv(1) AAS
ええっ！やだ、そんなエッチなこと・・・
307: 03/03/25 12:21 ID:to5h5iKv(1/2) AAS
一応いっとくとあるゲームってのは、
｢らじおぞんで｣というwindowsで動くフリーの2Dシューティングです。
308: 03/03/25 12:58 ID:to5h5iKv(2/2) AAS
通った位置を記憶したあとの、考えられる過程がしりたいです。
309: 03/03/25 13:21 ID:gZec8/NN(1) AAS
格闘ゲーム作ってみようかと思っているんですが、VRAMが６４０＊４８０が一枚の場合、
AプレイヤーとBプレイヤーと背景で３等分しているんでしょうか？
それとも背景は若干小さくしているとか？
たとえば、SNKの格闘ゲームはどのような配分なんでしょうか？（ちょっと前の画廊とかサムスピとか）
僕が考えているのは３２０＊３２０が２枚でAとBプレイヤーのキャラパターンを格納し、
残りの１６０＊６４０に背景を置くという感じなんですが、キャラパターン用のスペースは出来るだけ多くとりたいし、
背景用はそれほどでもないので、。
310: あぼーん [あぼーん] あぼーん AAS
あぼーん
311(2): 03/03/25 13:33 ID:c6oq96BT(1) AAS
>>311
本気でいってるの？
上下前次1-新書関写板覧索設栞歴
あと 659 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.034s