トップページgamedev
392コメント151KB

ゲームプログラミング相談室【Part5】

■ このスレッドは過去ログ倉庫に格納されています
0001名前は開発中のものです。02/11/04 20:41ID:a1Mhmm8N
ゲームプログラミング全般の質問スレッド。
扱う話題のダイナミックレンジはやや広め。包容力高め。
他の初心者質問スレとの棲み分けを探りつつ
これからもマターリと活用しておくれ。
 
■前スレ
【Part4】http://game.2ch.net/test/read.cgi/gamedev/1005040025/
■旧スレ(プログラム技術板)
【Part1】http://piza.2ch.net/tech/kako/969/969984472.html
【Part2】http://pc.2ch.net/tech/kako/985/985540361.html
【Part3】http://pc.2ch.net/tech/kako/1002/10028/1002894129.html
■関連スレなど
>>2-5
0174名前は開発中のものです。03/01/30 00:37ID:L8+k5MAr
>>171
描画をタスク自身が行うとは考えにくい。
タスクというレベルにまで到達しているなら、
「描画専門タスクに描画を依頼する」
という方式になっていると思う。

描画されるものとしての飛行機と、
アプリ内でのオブジェクトとしての飛行機を、
区別することが肝要だと思う。
0175名前は開発中のものです。03/01/30 02:17ID:BqRtFvdb
>>173
2方向リスト処理ですよね。この場合、私の質問は、STLで書いちゃうと
std::list<task *> tasklist;
tasklist.remove(this);
tasklist.insert(newpoint, this);
の newpoint の位置をどうやってチェックしてるんですか?っていう意味だったのです。
listの先頭から全部なめていくのかなー・・・、それとも別の頭いいやり方があるのかな〜と。

情報の共有というのは、もし飛行機が
struct 飛行機 {
 actor * a1, * a2;
}
で構成されるものだとして、a2 はどうやって a1 の中の変更した情報をチェックするのだろーとか考えてました。
いちいち new 飛行機 とかすると、(速度的な面で)疑似タスク使ってる意味がありませんよね?

>>174
なるほどです。
描画されるものとしての飛行機っていうのは、単純に飛行機のスプライトとか3Dモデルとかでいいですか?
0176名前は開発中のものです。03/01/30 02:20ID:ZJQj5onM
>>171
そのページの概念は処理順が安定している内部処理に絞られた物なので、
描画には向かないです。つーか勝手に用語用法決められても(汗

描画系で言ったら、

フレーム毎に「TCBアドレス+カメラ距離のセット」のリストを作成し、
距離基準にソーティングした後、リストを順になめて描画をする

様な処理が必要です。(実際にはマルチパスレンダやらなにやらで、優先度
の基準は色々追加されていく)
0177名前は開発中のものです。03/01/30 02:26ID:BqRtFvdb
あ、情報共有のところ、修正って言うか追加です。

「飛行機作るときに、a1 に a2 へのポインタかませば良いんじゃないの?」
っていうのは、飛行機を構成する疑似タスクがたくさんになってくると、メモリ領域の中身が
ポインタだけで埋まっちゃう・・・とか思ったので、使わないんじゃないかなとおもいました。
017817103/01/30 03:30ID:BqRtFvdb
>>176 なるほどです。めもめも。

#これで書けたら、うれしなっとプチ
0179デフォルトの名無しさん03/01/30 03:38ID:dIfJNfqd
私は new 飛行機 でやってる人なので、参考になるかわからんけど…

newpointの位置
「ここから先は敵タスク」みたいな目印用のタスクを何個か加えて、
それのポインタをグローバルで持たせてる。
それ使って大雑把にサーチした後に細かく見てる感じでやってるけど… 他に良い方法あるのかな

情報の共有
基本的に、子が親のポインタを持つのみ。
親から子に何かさせたい時は、親が自分のフラグを変えて、子がそれを見に行く。
子同士で何かさせたい時は、子が親のフラグを変えて、他の子がそれを見に行く。

補足
タスクの移動は、タスクを管理している側で操作したほうがいいと思う。
自分で移動するとnextが変わっちゃうので、他タスクがスキップされたり2回処理されてしまう。
情報の共有は、親は自分が参照されているかどうか、調べる必要があるかも。
子が持っているポインタが開放されたタスクを指していることがないように。
0180>>16903/01/30 03:47ID:Lo8nF9w1
3Dの場合、半透明部分は後で描画しないといけないとか、細かい処理があるので、
「3D描画エンジン(仮名)」というような割合高機能なクラス(もしくは関数群)を作って、
それに描画を依頼する形で考えると良いのでは。

1.各物体オブジェクト(タスク)は、「3D描画エンジン」に指定位置での指定3Dモデルの
  描画を依頼する。
2.「3D描画エンジン」は、それらの情報(位置、方向+モデル)を総合してソートなどして
  描画順などを決め、一気に描画する。

つまり、描画順は各物体オブジェクト(タスク)にとっては知ったこっちゃねぇと。
描画エンジンが面倒みてくれるよと。こゆわけです。
だから描画順によってリストを移動などしなくて良いのです。
0181名前は開発中のものです。03/01/30 07:34ID:xfHNFz6r
WM_PAINTで一気に描画するWindowsの基本と一緒だね。
タスクは結局ステートを変更するだけに過ぎない。
018217103/01/30 13:02ID:BqRtFvdb
>>179
>情報の共有
子同士で何かするときのイメージなんだけど、親を掲示板に見なして、
A「なんかすっぜ」
B「おー」

B「おれはやったぜ」

A「そかりょかーい」
B「うぃ」

みたいな感じでいいのかな?

タスクの移動に関して「nextが変わっちゃう」問題は、タスクを取ってきたときに
nextを保存しておくのはダメですか?

>>180
なるほどです。
0183名前は開発中のものです。03/01/30 14:45ID:U9i8fY1r
>情報の共有
俺は、ポインタに1クッションおく「ハンドル」を使ってる。
Windowsのウインドウハンドル(HWND)なんかと概念は同じ。
ポインタを直接持たずに、ハンドルからポインタを得る。

安全だけど、面倒くさい。

参考URL
http://www2.tky.3web.ne.jp/~yosshin/memo/000213.html
0184あぼーんNGNG
あぼーん
0185名前は開発中のものです。03/01/30 21:45ID:L8+k5MAr
>>183
破滅的な状態を回避するには有効だと思う。
0186名前は開発中のものです。03/01/31 10:15ID:6VWpyBYm
要するにMVCモデルとかDocument-Viewモデルというやつだな。
0187名前は開発中のものです。03/01/31 11:35ID:4bR+Vd+q
すみません質問です。
CGIはサーバ&クライアントの関係を用いて
データのやり取りとりを行いデータの読み出しや書き込みをしていますよね?

ではGAMEではどのようにしてセーブをおこなったりしているのですか?
ゲームボーイやファミコンの本体にサーバとクライアントの機能が
備わっているとは思えないのですが…。
どのような仕組みで保存(セーブ)をしているのでしょか?


0188名前は開発中のものです。03/01/31 11:37ID:6ynLwhZo
いやすべてがクライアント/サーバ型じゃないから。
GAMEって例えば?
0189名前は開発中のものです。03/01/31 11:40ID:4bR+Vd+q
どんなゲームでもいいんですが
ドラクエでもなんでもデータセーブ機能がついているゲーム。

サーバ&クライアントの関係を使わないとしたら
どのようにして保存をするのですか?

どのような言語で書かれたプログラムを使うのかとかおしえてください。
あとできればその理論が知りたいです。
0190名前は開発中のものです。03/01/31 11:40ID:H1fkys7O
>>187
マルチうぜぇ
消えろ
0191名前は開発中のものです。03/01/31 11:41ID:NYWMKE8k
マルチポストじゃなければ答えてあげたのにね……残念。
0192名前は開発中のものです。03/01/31 11:45ID:4bR+Vd+q
すみません。
この時間では書込みが少ないと思いマルチにしてしまいました。

おしえてください。。。
0193名前は開発中のものです。03/01/31 11:50ID:Oks/Mlfb
答えてあげたいけど、マルチポストは大嫌い。
そのような abuse 行為は善意に支えられたネットワークにとって
最大の敵であることを知りなさい。

恥知らず。
0194名前は開発中のものです。03/01/31 11:57ID:yMAewiuo
あのさ、マルチポストってだけならば別にわるいことって、ネチケットのFAQで読んだことがあるよ。
それも一度や二度ではなく。URLなんか覚えてないけどね。

ただし、質問者がマルチポストした先の答えをまとめて、
全ての回答者にこれこれこーなりました、ありがとーと言って回るならばっておまけ付き。
0195名前は開発中のものです。03/01/31 12:07ID:Q0GDcsqu
メモリカードとかに記録してるんだろ?
なんでサーバ・クライアントの話が出てくるのか分からないんだけども
0196名前は開発中のものです。03/01/31 12:46ID:yMAewiuo
>どんなゲームでもいいんですがドラクエでもなんでもデータセーブ機能がついているゲーム。

んっとさー、おーざっぱに答えるから嘘ついてるかもだよ。

コンピューターっていうのは CPU と メモリ とそれらをつなぐバスっていうのが最低限の要素なんだよね。

ファミコンっていうのは、メモリをつけてないコンピュータを売りつけて、
遊ぶためにはメモリ(ROMカセット)を買ってくださいって仕組みだったんだよ。

で、ROMカセットの中に RAM も入れて、電池で連続起動しておけばセーブシステムのいっちょあがり。
0197名前は開発中のものです。03/01/31 13:30ID:nYsHWhwS
連投規制で書き込めないと見た。
0198あぼーんNGNG
あぼーん
0199名前は開発中のものです。03/01/31 19:18ID:qsXaXa9v
Cを中心に簡単なゲームを作りたいと考えているのですが、
Game Programming Gems以外に何か参考になる図書はありませんでしょうか?
よろしくお願いします。
0200416 ◆quHoSW/FCI 03/01/31 19:49ID:2OuKlzSK
>>187
 認識がヘン。

 CGIやネットゲームのようなサーバ&クライアントの関係がある環境でも、
それは単に、サーバ側にデータを保存させているか、クライアント側に保存させて
いるかの設定の違いに過ぎない(CGIやとクラ側保存は・・・クッキーがあるか)。

 データ保存が可能な環境と、保存命令があれば可能。サーバ&クライアントの
関係はぜんぜん関係無い。
0201名前は開発中のものです。03/01/31 21:13ID:2op7A3hN
というか要するに187は、CGI…というかPerl辺りを
限定的な環境でちょこっとかじっただけなんでしょ。
一生懸命説明しても無駄だと思う。
0202名前は開発中のものです。03/01/31 22:13ID:2ZzIvrax
最初は実体を例示しないとわからないのは仕方ないけど
ずっとその例示を引きずるのは頭悪いな
0203名前は開発中のものです。03/01/31 23:02ID:vCqXldk6
>>199 簡単な、どんなゲームを作りたいの?
0204名前は開発中のものです。03/01/31 23:36ID:qsXaXa9v
>>203
インベーダーゲームみたいな2Dの簡単なソフトです。主にシューティングを中心に作りたいです。
0205名前は開発中のものです。03/01/31 23:51ID:B3NC8eT4
>>199
ゲームプログラミング遊びのレシピ―アルゴリズムとデータ構造
http://www.cmagazine.jp/books/recipe/
http://www.amazon.co.jp/exec/obidos/ASIN/4797316535/ref=pd_bxgy_text_1/t/249-7245941-5470719
は、どーでしょうか。

本屋さんでよく見かけるので、立ち読みしやすいと思う。
C++Builder&Delphiなのでそのままでは使いにくいけど、
日本語での解説部分はアルゴリズムの参考にはなるかと。
0206名前は開発中のものです。03/02/01 00:33ID:JG1cEAZ6
>>205
ありがとうございます。参考になりました。
0207あぼーんNGNG
あぼーん
0208名前は開発中のものです。03/02/02 16:57ID:6i0/vwvm
2Dで、人間の関節などを動かせるようにしたいのですが、
まずどのようなものを勉強すればいいのでしょうか。

キーワードとかってあります?
0209名前は開発中のものです。03/02/02 17:02ID:9DYxK8lo
2Dで?
どうもイメージ沸かない・・・
0210名前は開発中のものです。03/02/02 17:05ID:fhT0wplm
>>208
階層構造,ローカル座標系
IK,FK
ここまでは3Dでもいっしょ
2Dなら画像の回転も必要かな
0211名前は開発中のものです。03/02/02 17:11ID:zcwy9VYW
2Dで関節っていうと、幼稚園児向けの番組で動かしてる人形を思い出す……。
手足にそれぞれ黒い棒がついてて、関節がおかしな方向に平気で曲がる紙人形。
0212名前は開発中のものです。03/02/02 17:12ID:zcwy9VYW
あとはこれか
「多関節キャラによる格闘ゲームを作るスレ」その2
http://pc2.2ch.net/test/read.cgi/gamedev/1015771528/l50
0213名前は開発中のものです。03/02/02 19:02ID:DGXzuX3G
IK,FK を検索エンジンで調べるためのキーワードをおしえれ。
0214名前は開発中のものです。03/02/02 19:32ID:t6/9t4TG
インバースキネマティクス
0215名前は開発中のものです。03/02/02 19:59ID:DGXzuX3G
ありがとぅょ
0216名前は開発中のものです。03/02/02 23:29ID:ngVInDbv
>>215
FK(フォワードキネマティクス)の方が簡単だから
IKよりFKをやってみては?
0217名前は開発中のものです。03/02/03 07:46ID:JqqWIodK
えーと、PALスレとか、リフレッシュレートスレでいわれてる、不定間隔なフレーム処理の補間ってどうやるんですか?

B宗(v += a)な私には、フレーム処理を 5ms 毎に実行して、それを V-Sync で描画するぐらいしか想像がつかないんだけどー。
0218名前は開発中のものです。03/02/03 08:53ID:0/huq5OJ
>>217
リフレッシュレートに関する論争
http://matsuzak.pobox.ne.jp/directx/faq/refresh-rate.html
0219あぼーんNGNG
あぼーん
0220名前は開発中のものです。03/02/06 00:54ID:2WnqR6mA
2Dゲームを作るときに、アニメーション画像って、どうやって管理しますか?
RPGの主人公がマップ上を歩くときに、手足が動いたりするのですが、
タイマーをかけて、stateを1,2,3,4,1,2,...って変えていって、
stateの値ごとに描画を変えるのがいいですか?

それだと、アニメーションが複雑になると、プログラムも汚くなるのですが、
もっと見やすくていい方法ってないですか?
0221名前は開発中のものです。03/02/06 01:11ID:yacnI+6d
>>220
アニメーションデータを表すデータ構造を作れ。
そしてそれを解釈して描画するプログラムを作れ。

これなら、アニメーションが複雑になってもプログラムに影響は無いぞ。
さらに、アニメーションデータを編集するツールを作るともっといい。
0222あぼーんNGNG
あぼーん
0223名前は開発中のものです。03/02/07 00:53ID:WYEzYilN
>>220
>もっと見やすくていい方法ってないですか?
きちっとした設計できれいにコーディングをする
いやマジです
関数とか構造体とかクラスってわかります?
0224名前は開発中のものです。03/02/08 23:35ID:B2NmrZjg
>>220
状態遷移のクラスを作って、定期的にそいつから
アニメーションパターンの数字を取得するようにする。
描画するときは、その数値に対応した絵を表示させるだけ。
0225名前は開発中のものです。03/02/08 23:49ID:He/KRUT1
>>224
すいません。想像しづらいのですが、
クラスのインターフェースを書いてもらえますか?
0226名前は開発中のものです。03/02/09 00:43ID:EKddfl4f
>>225
甘えるなゴルァ

「有限状態オートマトン」で検索するか、
"Game Programming Gems 1" の 「3.1 有限状態マシンクラス」を読んでくれ。
(全然難しい内容ではないが、まあ、一応)
0227名前は開発中のものです。03/02/09 00:45ID:yUWb7xod
何回か作り直してればそのうちマトモな形になるよ
0228名前は開発中のものです。03/02/09 01:09ID:gYbNlh+m
>>225
ttp://210.143.102.80/upload/source/d/0685.txt
0229あぼーんNGNG
あぼーん
0230名前は開発中のものです。03/02/10 16:24ID:FAmepXpS
処理落ち率の計算の仕方を教えてください。
フレームを飛ばさないのに、処理落ちするって、どういうことですか?
処理は落ちてないんじゃないですか?
0231ぽぷり03/02/10 16:27ID:6VC5i/Lt
最初からココで聞いたらよかったかな。
あと2箇所に書き込んだマルチだが良かったら質問よろしく頼みます

いまFF4のパクリ作ってるんだけど戦闘の曲を.wmaで作った。

で、これをループでエンドレスで流すわけだが
そのまま初めのフレーズ(ダダダダ、ダダダダ・・・・)に戻ってしまう。

この曲は1分54秒まであるんだが
俺としては0:00から1:54まで流した後
ループは0:00からではなく00:53あたりからにしたい。

どうしたらいいかな?誰か賢い奴教えてくれ。

流れとしては・・・・

戦闘開始(音楽スタート)
0:00→1:54→0:53→1:54→0:53→・・・・・戦闘終了(音楽終了)

っていう感じにしたいです


0232デフォルトの名無しさん03/02/10 16:28ID:sFeXOrcI
ゲームで時間のかかる処理をしていると画面の
キャラクターの移動などがズルッズルッと遅くなる。
これが処理落ちしているという状態。
時間内に処理が終わらないのを「落ち」といっているのでしょう。
この場合処理はとばしていません。

パソコンでよく見られるのが、処理が重いときに処理をスキップする
やつです。画面の更新がなめらかでなくなってカクカクして見えます。
0233あぼーんNGNG
あぼーん
0234あぼーんNGNG
あぼーん
0235名前は開発中のものです。03/02/10 17:15ID:xlyrLNIL
>>231
DirectShowでも、DirectSoundでも、MCFでも、プログラム上で制御は可能だが…。
0236名前は開発中のものです。03/02/10 17:25ID:VY6anJSf
>>231
マルチウゼー

http://pc2.2ch.net/test/read.cgi/gamedev/1028183728/60
http://pc2.2ch.net/test/read.cgi/gamedev/1035601681/922
0237ぽぷり03/02/10 20:03ID:6VC5i/Lt
>>235
HSPでは無理かな?
プログラム上の制御って、どんな項目で検索したらいいでしょうか?
0238名前は開発中のものです。03/02/10 21:04ID:pyEAMejp
>>230
処理落ちとコマ落ちについても >>218 のリンク先に
書いてるから読んでみ。
0239名前は開発中のものです。03/02/10 22:04ID:n899aQqE
>>237
>>235が十分なくらいキーワードだしてるよ。
MCI(MCFは間違いだよな?)、DirectSound、DirectShow
HSPはよく知らないが、
MCIはWindowsAPI、DirectSound、DirectShowはCOMが扱えれば大丈夫。
HSPがそれらを扱うのが難しい言語ならば、
他の人が作ったライブラリを使う手もある。
# HSPといえどもDLLぐらい使えるだろ?
0240名前は開発中のものです。03/02/10 22:09ID:n899aQqE
>>237
こんな方法もあるようだ。
http://www.google.co.jp/search?hl=ja&inlang=ja&ie=Shift_JIS&q=HSP+DirectShow+%83%8B%81%5B%83v%95%94%8D%C4%90%B6&lr=
0241名前は開発中のものです。03/02/10 23:15ID:+EgLsXBk
>>237
マジで氏んでくれ。
024223503/02/11 00:32ID:OEwInXkJ
MCFは間違い。
何やってんだ、俺。
0243名前は開発中のものです。03/03/02 11:58ID:1UsFLoT7
保守sage
0244名前は開発中のものです。03/03/04 22:15ID:QU9Qm2YP
敵の弾で曲がるレーザー系のを作って見たいのですが、
雰囲気としては一度敵機の近くでゆっくり動き、目標に向かって
早い曲線を描こうと思っています。おそらくゆっくり部分と狙撃部分の
2つのルーチンを使用するかとおもいますが、問題が2つほどありまして、
1)曲線が目標位置によってイビツになる。
2)レーザー表現を座標引き渡しで20個ほど丸オブジェクトを使用
  したので、処理が遅い。
何か良い方法はないのでしょうか?
0245名前は開発中のものです。03/03/08 01:35ID:AeESF41/
見た目だけクォータビューで、内部的にはトップビューなゲームを制作中なのですが、
座標を四十五度回転させてから上下半分に潰して表示している為に、見た目上上下の移動が遅く、左右の移動が早く見えてしまいます。
こういう場合、みなさんどうしていますか?
0246デフォルトの名無しさん03/03/08 01:52ID:omw6bur7
>>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);
とかやってみる。符号とか間違ってるかも。
よく状況がわからないけど、変化量が急に変わらないようにすればいいんじゃないかな。
2)
直線で繋ぐとか。
0247名前は開発中のものです。03/03/08 01:58ID:Qzt+JfAG
>>245
画像にかけた、縮尺を移動量にもかける。
上下が左右の50%なんだろ?
じゃあ、移動量も50%でいいじゃん。

つーか、それ
クォータービュー風表示で、内部がトップビューって言うか?
一瞬意味が分らなかった。
0248あぼーんNGNG
あぼーん
024924503/03/08 03:30ID:AeESF41/
>>247
お返事有り難う御座います。
内部でのベクトルも表示時には四十五度回転しているため、
それではうまくいかないのです……。
(内部的に下にすすめが表示上は左下に、右に進めば右下に進んでいるように見えます)
内部のマスは正方形ですが、表示時は菱形なので移動量がおかしくみえるということなのですが……。
0250名前は開発中のものです。03/03/08 04:03ID:Qzt+JfAG
>>249
その処理だと、クォータービューって言わないじゃん。
つまり、クォータービューって斜め見下ろし型でしょ?
君の言ってる移動処理は、トップビューでただ45度回転してるだけだよ。
それでは、描画と移動処理が噛合う訳が無いよ。

普通は、トップビューと同じ処理で、横長の菱形MAPchipやなんかを
用意してキャラをMAPchipより手前にずらして立たせて
完全2D処理で、擬似クォータービュー見たくするもんだが…

ベクトルとか言ってるなら、それは3D処理が必要。
つまり、菱形を潰して描画してるだけなのだろうが
それって普通に見た場合(3D視点)、奥行きがあって
斜めに見下ろしてるから左右は広く、手前と奥で縮まる訳だ。

君の言ってる事を解析すると、移動処理は2次元ベクトルを平面で45度回転しただけ。
MAPchip描画は上下に潰しただけ。しかし、そのMAPchipは見た目には奥行きがあって斜めに見た様に見える。
その噛み合わせが不自然って訳だ。当然かな。

解決策として、大道は移動ベクトルと描画用MAPchipに同じ3D処理をする。
もう一つは、その処理を止めて違う処理に変える。
そんな感じじゃない?
0251あぼーんNGNG
あぼーん
0252名前は開発中のものです。03/03/08 04:10ID:tiy6mV84
すべての方向に対して、同じ時間で移動できる場所に点を打ってその点を補完して線にする。
すると、君のプログラムでは、正方形が出来上がるわけだ。
ところが現実には円になることが期待される。

君のプログラムは、内部的には「円を正方形で近似している」んですよ。
そのまま表示すれば、移動方向によって速度に変化が生じるのは当たり前。
対策は、内部のプログラムを書き直して円を円として扱うようにするか、
あるいは円を八角形で近似するように書き直すか、
グラフィックを表示するときに縮尺を変えて正方形を円に近くなるようにごまかすか、
そんなものしか考えようがないでしょう。
025325203/03/08 04:12ID:tiy6mV84
ごめん勘違い。
無視してください。
0254名前は開発中のものです。03/03/08 04:32ID:Qzt+JfAG
ん?やっぱさ247で言ってる通りでいいじゃんか。
君の描画処理って45度回転して上下に潰すっていてるよね?
その言ってる正方形ってのがMAPなんだろうが、
移動ベクトルにも同じ処理してないじゃん。
上下に潰すって事は、Y軸方向にスケールをかけてる訳だ。
そのY軸方向のスケールを、移動ベクトルにもかけてるか?
つまり、移動ベクトルはX成分はそのままで
Y成分が縮まる(上下に潰れる)ってやれば整合性が取れるじゃん。

…そうじゃ無いってなら言ってる意味がもう分らないよ…
0255名前は開発中のものです。03/03/08 06:00ID:MKbGXKwx
画像が欲しいとこではある
025624503/03/08 09:51ID:AeESF41/
>>250-255
真面目にレスいただき、ありがとうございます。
意味がわからない面も多々あり、申し訳ありません。
画像は用意したいと思うのですが、よかったらどうかお待ちください。
マップ自体は見た目上だけクォータービューで、
(画像は潰しておらず、べた表示です)
キャラクタの表示する座標だけを描画時にマップの端を軸に45度回転させて、
上下に半分潰すことでクォータービュー風(移動)にみせています。
要するに内部的に上に進めば
表示座標上は(45度/2の傾斜がついた)左上に進んでいることになるわけで、

内部のY軸方向のスケールと、
描画時のY軸方向のスケールは45度/2ずれているわけです。
なので内部的にY軸だけに補正をかけると、
描画時にはX成分にも影響を与える訳です。

勿論、内部的には円を近似した移動値で書かれているのですが、
その、円の移動値(−X-Y)〜(+X+Y)のスケールだけが
描画時には半分に潰されてしまっているわけなのです。

よって、内部的には正円ではなく、楕円に進む必要があるのか、と考えています。
すこし妙な感じがするのですが。







025724503/03/08 10:29ID:AeESF41/
ちなみにイメージ図は
http://www.geocities.co.jp/SiliconValley-PaloAlto/7551/topview.jpg
な感じです。
マップの描画などは全く視野に入れません。
0258名前は開発中のものです。03/03/08 11:16ID:tiy6mV84
>>257
そりゃああた、パースを考慮に入れてないからっす。

普通の二次元画像を斜めにして単純に潰すと、絵としておかしくなる。
だから、その絵としておかしいMAPの上で正しくキャラを動かしても絵としてはおかしくなる。
この世には遠近法というものがあって、遠くのものは小さく、近くのものは大きく見えるのが世界の常識です。
実際には遠近法を考慮しなくてもそれなりに綺麗に見えるものなのですが、
奥行きが深い場合はちょっと不自然に見えます。
0259名前は開発中のものです。03/03/08 11:18ID:Qzt+JfAG
>>257
やっぱり247と254で言ってる通りじゃんよ。

で、君の言ってる事が意味が通って無い。
まず、最後に潰そうが何しても、移動量ベクトルの”大きさ”は
四方向で”同じ”だ。差なんて無いじゃん。

つまりベクトルで言うと
上(0, 1)
右(1, 0)
下(0, -1)
左(-1, 0)
が、45度回転して(-PI/4)
上(-0.7071, 0.7071)
右(0.7071, 0.7071)
下(0.7071, -0.7071)
左(-0.7071, -0.7071)
で最後にYにスケール(Y:1/2)をかけるても
上(-0.7071, 0.3535)
右(0.7071, 0.3535)
下(0.7071, -0.3535)
左(-0.7071, -0.3535)
って四方向は、”方向”が違うだけで”大きさ”は同じだが?

…ベクトルって言い出したのは、君の方なので
ベクトル自体は扱えるよな?
0260名前は開発中のものです。03/03/08 11:24ID:HkNGp/2b
斜め上から正射影で見た状態やね

>>245
>見た目上上下の移動が遅く、左右の移動が早く見えてしまいます

上下と左右の見た目スケールが違うんだから、
そう見えてしかるべきなんでは?

見た目で同じスピードにすると、
実マップ上での移動速度がヘンになる(軸により偏りがでる)けど
それでいいのかな。
0261デフォルトの名無しさん03/03/08 11:38ID:omw6bur7
表示の座標から見て、「上下」と「左右」の移動に差が出るってことは、
内部の座標から見て、「上下左右」と「斜め」の移動に差がある。
…あってるのかわからんけど。

それなら、内部座標から見た「斜め」方向への移動を減らせばいい。
なんか、気持ち悪いけど。

リロードしたら>>260と同じだった…
さらに読み返すと、楕円に進む と同じようなこと言ってる気もする。
026224503/03/08 11:54ID:9W7WzJNL
皆様レス有り難うございます。
>>255
パースは一応理解しているのですが、
2Dとして不自然でないように取り入れるにはどうしたらいいのかと思いまして。

>>256
そうですね、内部的なベクトルの大きさは同じです。
でも、見た目上の(プレイしている側からしてみれば)違っているように見えてしまいますよね。
これを正したいと思ったのです。

>>260>>261
そうですね、中身が移動量が異なると気持ち悪いと思います。
そして、見た目上も正しいと思うのですが
クォータビューなゲームで
上下と左右の移動量が違う(ように見える)と何だか変な感じを受けたりしませんか?

これをうまく解決したい、と思ったのですが……。
うまく言えなくてもうしわけないです。
0263名前は開発中のものです。03/03/08 13:03ID:HkNGp/2b
うーん、画面がしっかり傾いているように見えれば、
ヘンには感じないと思う。そう印象付けるような画面構成にするといい。

車の後ろから見るレースゲームで、等間隔にオブジェクトを配置したり
等間隔に地面に模様をつけるのは、走ってるという感覚を引き出すための
基本テクニックだったりする。のっぺりしてると速度感が沸かないのよ。

クオータービューについてもそういう工夫があっていいんじゃないかなあ。
0264あぼーんNGNG
あぼーん
0265416 ◆quHoSW/FCI 03/03/08 16:20ID:s3TXU6Pq
>>262
 もしかして、トップビューで言うところの斜め移動をさせてない? トップの
上下左右はクォーターでは斜め45度だが、トップでの斜めはクォーターでは
真横とかになるよね。
 移動がマス方式のクォータービューでは斜め移動はそう見える。A列車3、4で
列車が真横に移動するのと、斜めではえらく差があるように。
0266あぼーんNGNG
あぼーん
0267あぼーんNGNG
あぼーん
0268名前は開発中のものです。03/03/13 14:53ID:x1k2yze2
春休みとDirectX8を利用して、Ys3っぽいべたなアクションゲームを作ってます。
描画周りは一通り出来たのですが、ここで疑問が・・・

キャラが動いたときの描画なのですが、
既に配置済みの背景の中を、ビュー行列を変えて移動させるのと
ビュー行列据え置きで、キャラ周りの背景を移動するたびに配置換えする

一般にどちらが良いのでしょうか?
前者の方が簡単そうにみえ、今はそちらなのですが、
MatrixのFLOATで補えないくらい広いマップとかは、どうなるのかなどと考え出したら・・・。

お馬鹿な質問ですが、よろしければマジレスいただけると嬉しいです。
0269あぼーんNGNG
あぼーん
0270名前は開発中のものです。03/03/13 22:12ID:M64nHos+
>>268
Ys3って横から見たような画面構成だっけ?

PC88やPC98はマップチップを組み合わせて画面を構成してたと思うけど、
(つまり後者)それほど難しくないよ。
0271名前は開発中のものです。03/03/14 00:05ID:1VLZD/pC
>>270
レスありがとうございます。やはり後者でしたか_| ̄|○

PC88やPC98ではと言うことですが、今はあまりこういう手法は用いないのでしょうか?
しかし、やはり効率的な描画方法っていうのは、今も昔も変わらなそうですね。

画面は仰るとおり、横から見たようなのです。
私はこれとリンクの冒険が大好きで・・・。どっちも一般にはアレですが・・・。
0272名前は開発中のものです。03/03/14 00:06ID:1VLZD/pC
すいません、あげてしまった・・・。
スクリプト荒らし来ちゃうかな・・・。
0273名前は開発中のものです。03/03/14 01:24ID:41+v9X+W
>>271
GBとかのBG面があるゲーム機は今でもそんな感じ。
背景がモデルならば仕様次第な気もするけど、似たような事をやらなくも無い。
■ このスレッドは過去ログ倉庫に格納されています