ゲームプログラミング相談室【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描画をタスク自身が行うとは考えにくい。
タスクというレベルにまで到達しているなら、
「描画専門タスクに描画を依頼する」
という方式になっていると思う。
描画されるものとしての飛行機と、
アプリ内でのオブジェクトとしての飛行機を、
区別することが肝要だと思う。
0175名前は開発中のものです。
03/01/30 02:17ID:BqRtFvdb2方向リスト処理ですよね。この場合、私の質問は、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そのページの概念は処理順が安定している内部処理に絞られた物なので、
描画には向かないです。つーか勝手に用語用法決められても(汗
描画系で言ったら、
フレーム毎に「TCBアドレス+カメラ距離のセット」のリストを作成し、
距離基準にソーティングした後、リストを順になめて描画をする
様な処理が必要です。(実際にはマルチパスレンダやらなにやらで、優先度
の基準は色々追加されていく)
0177名前は開発中のものです。
03/01/30 02:26ID:BqRtFvdb「飛行機作るときに、a1 に a2 へのポインタかませば良いんじゃないの?」
っていうのは、飛行機を構成する疑似タスクがたくさんになってくると、メモリ領域の中身が
ポインタだけで埋まっちゃう・・・とか思ったので、使わないんじゃないかなとおもいました。
0179デフォルトの名無しさん
03/01/30 03:38ID:dIfJNfqdnewpointの位置
「ここから先は敵タスク」みたいな目印用のタスクを何個か加えて、
それのポインタをグローバルで持たせてる。
それ使って大雑把にサーチした後に細かく見てる感じでやってるけど… 他に良い方法あるのかな
情報の共有
基本的に、子が親のポインタを持つのみ。
親から子に何かさせたい時は、親が自分のフラグを変えて、子がそれを見に行く。
子同士で何かさせたい時は、子が親のフラグを変えて、他の子がそれを見に行く。
補足
タスクの移動は、タスクを管理している側で操作したほうがいいと思う。
自分で移動するとnextが変わっちゃうので、他タスクがスキップされたり2回処理されてしまう。
情報の共有は、親は自分が参照されているかどうか、調べる必要があるかも。
子が持っているポインタが開放されたタスクを指していることがないように。
0180>>169
03/01/30 03:47ID:Lo8nF9w1「3D描画エンジン(仮名)」というような割合高機能なクラス(もしくは関数群)を作って、
それに描画を依頼する形で考えると良いのでは。
1.各物体オブジェクト(タスク)は、「3D描画エンジン」に指定位置での指定3Dモデルの
描画を依頼する。
2.「3D描画エンジン」は、それらの情報(位置、方向+モデル)を総合してソートなどして
描画順などを決め、一気に描画する。
つまり、描画順は各物体オブジェクト(タスク)にとっては知ったこっちゃねぇと。
描画エンジンが面倒みてくれるよと。こゆわけです。
だから描画順によってリストを移動などしなくて良いのです。
0181名前は開発中のものです。
03/01/30 07:34ID:xfHNFz6rタスクは結局ステートを変更するだけに過ぎない。
0182171
03/01/30 13:02ID:BqRtFvdb>情報の共有
子同士で何かするときのイメージなんだけど、親を掲示板に見なして、
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あぼーん
NGNG0185名前は開発中のものです。
03/01/30 21:45ID:L8+k5MAr破滅的な状態を回避するには有効だと思う。
0186名前は開発中のものです。
03/01/31 10:15ID:6VWpyBYm0187名前は開発中のものです。
03/01/31 11:35ID:4bR+Vd+qCGIはサーバ&クライアントの関係を用いて
データのやり取りとりを行いデータの読み出しや書き込みをしていますよね?
ではGAMEではどのようにしてセーブをおこなったりしているのですか?
ゲームボーイやファミコンの本体にサーバとクライアントの機能が
備わっているとは思えないのですが…。
どのような仕組みで保存(セーブ)をしているのでしょか?
0188名前は開発中のものです。
03/01/31 11:37ID:6ynLwhZoGAMEって例えば?
0189名前は開発中のものです。
03/01/31 11:40ID:4bR+Vd+qドラクエでもなんでもデータセーブ機能がついているゲーム。
サーバ&クライアントの関係を使わないとしたら
どのようにして保存をするのですか?
どのような言語で書かれたプログラムを使うのかとかおしえてください。
あとできればその理論が知りたいです。
0190名前は開発中のものです。
03/01/31 11:40ID:H1fkys7Oマルチうぜぇ
消えろ
0191名前は開発中のものです。
03/01/31 11:41ID:NYWMKE8k0192名前は開発中のものです。
03/01/31 11:45ID:4bR+Vd+qこの時間では書込みが少ないと思いマルチにしてしまいました。
おしえてください。。。
0193名前は開発中のものです。
03/01/31 11:50ID:Oks/Mlfbそのような abuse 行為は善意に支えられたネットワークにとって
最大の敵であることを知りなさい。
恥知らず。
0194名前は開発中のものです。
03/01/31 11:57ID:yMAewiuoそれも一度や二度ではなく。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:nYsHWhwS0198あぼーん
NGNG0199名前は開発中のものです。
03/01/31 19:18ID:qsXaXa9vGame Programming Gems以外に何か参考になる図書はありませんでしょうか?
よろしくお願いします。
0200416 ◆quHoSW/FCI
03/01/31 19:49ID:2OuKlzSK認識がヘン。
CGIやネットゲームのようなサーバ&クライアントの関係がある環境でも、
それは単に、サーバ側にデータを保存させているか、クライアント側に保存させて
いるかの設定の違いに過ぎない(CGIやとクラ側保存は・・・クッキーがあるか)。
データ保存が可能な環境と、保存命令があれば可能。サーバ&クライアントの
関係はぜんぜん関係無い。
0201名前は開発中のものです。
03/01/31 21:13ID:2op7A3hN限定的な環境でちょこっとかじっただけなんでしょ。
一生懸命説明しても無駄だと思う。
0202名前は開発中のものです。
03/01/31 22:13ID:2ZzIvraxずっとその例示を引きずるのは頭悪いな
0203名前は開発中のものです。
03/01/31 23:02ID:vCqXldk60204名前は開発中のものです。
03/01/31 23:36ID:qsXaXa9vインベーダーゲームみたいな2Dの簡単なソフトです。主にシューティングを中心に作りたいです。
0205名前は開発中のものです。
03/01/31 23:51ID:B3NC8eT4ゲームプログラミング遊びのレシピ―アルゴリズムとデータ構造
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ありがとうございます。参考になりました。
0207あぼーん
NGNG0208名前は開発中のものです。
03/02/02 16:57ID:6i0/vwvmまずどのようなものを勉強すればいいのでしょうか。
キーワードとかってあります?
0209名前は開発中のものです。
03/02/02 17:02ID:9DYxK8loどうもイメージ沸かない・・・
0210名前は開発中のものです。
03/02/02 17:05ID:fhT0wplm階層構造,ローカル座標系
IK,FK
ここまでは3Dでもいっしょ
2Dなら画像の回転も必要かな
0211名前は開発中のものです。
03/02/02 17:11ID:zcwy9VYW手足にそれぞれ黒い棒がついてて、関節がおかしな方向に平気で曲がる紙人形。
0212名前は開発中のものです。
03/02/02 17:12ID:zcwy9VYW「多関節キャラによる格闘ゲームを作るスレ」その2
http://pc2.2ch.net/test/read.cgi/gamedev/1015771528/l50
0213名前は開発中のものです。
03/02/02 19:02ID:DGXzuX3G0214名前は開発中のものです。
03/02/02 19:32ID:t6/9t4TG0215名前は開発中のものです。
03/02/02 19:59ID:DGXzuX3G0216名前は開発中のものです。
03/02/02 23:29ID:ngVInDbvFK(フォワードキネマティクス)の方が簡単だから
IKよりFKをやってみては?
0217名前は開発中のものです。
03/02/03 07:46ID:JqqWIodKB宗(v += a)な私には、フレーム処理を 5ms 毎に実行して、それを V-Sync で描画するぐらいしか想像がつかないんだけどー。
0218名前は開発中のものです。
03/02/03 08:53ID:0/huq5OJリフレッシュレートに関する論争
http://matsuzak.pobox.ne.jp/directx/faq/refresh-rate.html
0219あぼーん
NGNG0220名前は開発中のものです。
03/02/06 00:54ID:2WnqR6mARPGの主人公がマップ上を歩くときに、手足が動いたりするのですが、
タイマーをかけて、stateを1,2,3,4,1,2,...って変えていって、
stateの値ごとに描画を変えるのがいいですか?
それだと、アニメーションが複雑になると、プログラムも汚くなるのですが、
もっと見やすくていい方法ってないですか?
0221名前は開発中のものです。
03/02/06 01:11ID:yacnI+6dアニメーションデータを表すデータ構造を作れ。
そしてそれを解釈して描画するプログラムを作れ。
これなら、アニメーションが複雑になってもプログラムに影響は無いぞ。
さらに、アニメーションデータを編集するツールを作るともっといい。
0222あぼーん
NGNG0223名前は開発中のものです。
03/02/07 00:53ID:WYEzYilN>もっと見やすくていい方法ってないですか?
きちっとした設計できれいにコーディングをする
いやマジです
関数とか構造体とかクラスってわかります?
0224名前は開発中のものです。
03/02/08 23:35ID:B2NmrZjg状態遷移のクラスを作って、定期的にそいつから
アニメーションパターンの数字を取得するようにする。
描画するときは、その数値に対応した絵を表示させるだけ。
0225名前は開発中のものです。
03/02/08 23:49ID:He/KRUT1すいません。想像しづらいのですが、
クラスのインターフェースを書いてもらえますか?
0226名前は開発中のものです。
03/02/09 00:43ID:EKddfl4f甘えるなゴルァ
「有限状態オートマトン」で検索するか、
"Game Programming Gems 1" の 「3.1 有限状態マシンクラス」を読んでくれ。
(全然難しい内容ではないが、まあ、一応)
0227名前は開発中のものです。
03/02/09 00:45ID:yUWb7xod0228名前は開発中のものです。
03/02/09 01:09ID:gYbNlh+mttp://210.143.102.80/upload/source/d/0685.txt
0229あぼーん
NGNG0230名前は開発中のものです。
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あぼーん
NGNG0234あぼーん
NGNG0235名前は開発中のものです。
03/02/10 17:15ID:xlyrLNILDirectShowでも、DirectSoundでも、MCFでも、プログラム上で制御は可能だが…。
0236名前は開発中のものです。
03/02/10 17:25ID:VY6anJSfマルチウゼー
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/LtHSPでは無理かな?
プログラム上の制御って、どんな項目で検索したらいいでしょうか?
0238名前は開発中のものです。
03/02/10 21:04ID:pyEAMejp処理落ちとコマ落ちについても >>218 のリンク先に
書いてるから読んでみ。
0239名前は開発中のものです。
03/02/10 22:04ID:n899aQqE>>235が十分なくらいキーワードだしてるよ。
MCI(MCFは間違いだよな?)、DirectSound、DirectShow
HSPはよく知らないが、
MCIはWindowsAPI、DirectSound、DirectShowはCOMが扱えれば大丈夫。
HSPがそれらを扱うのが難しい言語ならば、
他の人が作ったライブラリを使う手もある。
# HSPといえどもDLLぐらい使えるだろ?
0240名前は開発中のものです。
03/02/10 22:09ID:n899aQqEこんな方法もあるようだ。
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マジで氏んでくれ。
0242235
03/02/11 00:32ID:OEwInXkJ何やってんだ、俺。
0243名前は開発中のものです。
03/03/02 11:58ID:1UsFLoT70244名前は開発中のものです。
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遅レスだけど。
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画像にかけた、縮尺を移動量にもかける。
上下が左右の50%なんだろ?
じゃあ、移動量も50%でいいじゃん。
つーか、それ
クォータービュー風表示で、内部がトップビューって言うか?
一瞬意味が分らなかった。
0248あぼーん
NGNG0249245
03/03/08 03:30ID:AeESF41/お返事有り難う御座います。
内部でのベクトルも表示時には四十五度回転しているため、
それではうまくいかないのです……。
(内部的に下にすすめが表示上は左下に、右に進めば右下に進んでいるように見えます)
内部のマスは正方形ですが、表示時は菱形なので移動量がおかしくみえるということなのですが……。
0250名前は開発中のものです。
03/03/08 04:03ID:Qzt+JfAGその処理だと、クォータービューって言わないじゃん。
つまり、クォータービューって斜め見下ろし型でしょ?
君の言ってる移動処理は、トップビューでただ45度回転してるだけだよ。
それでは、描画と移動処理が噛合う訳が無いよ。
普通は、トップビューと同じ処理で、横長の菱形MAPchipやなんかを
用意してキャラをMAPchipより手前にずらして立たせて
完全2D処理で、擬似クォータービュー見たくするもんだが…
ベクトルとか言ってるなら、それは3D処理が必要。
つまり、菱形を潰して描画してるだけなのだろうが
それって普通に見た場合(3D視点)、奥行きがあって
斜めに見下ろしてるから左右は広く、手前と奥で縮まる訳だ。
君の言ってる事を解析すると、移動処理は2次元ベクトルを平面で45度回転しただけ。
MAPchip描画は上下に潰しただけ。しかし、そのMAPchipは見た目には奥行きがあって斜めに見た様に見える。
その噛み合わせが不自然って訳だ。当然かな。
解決策として、大道は移動ベクトルと描画用MAPchipに同じ3D処理をする。
もう一つは、その処理を止めて違う処理に変える。
そんな感じじゃない?
0251あぼーん
NGNG0252名前は開発中のものです。
03/03/08 04:10ID:tiy6mV84すると、君のプログラムでは、正方形が出来上がるわけだ。
ところが現実には円になることが期待される。
君のプログラムは、内部的には「円を正方形で近似している」んですよ。
そのまま表示すれば、移動方向によって速度に変化が生じるのは当たり前。
対策は、内部のプログラムを書き直して円を円として扱うようにするか、
あるいは円を八角形で近似するように書き直すか、
グラフィックを表示するときに縮尺を変えて正方形を円に近くなるようにごまかすか、
そんなものしか考えようがないでしょう。
0253252
03/03/08 04:12ID:tiy6mV84無視してください。
0254名前は開発中のものです。
03/03/08 04:32ID:Qzt+JfAG君の描画処理って45度回転して上下に潰すっていてるよね?
その言ってる正方形ってのがMAPなんだろうが、
移動ベクトルにも同じ処理してないじゃん。
上下に潰すって事は、Y軸方向にスケールをかけてる訳だ。
そのY軸方向のスケールを、移動ベクトルにもかけてるか?
つまり、移動ベクトルはX成分はそのままで
Y成分が縮まる(上下に潰れる)ってやれば整合性が取れるじゃん。
…そうじゃ無いってなら言ってる意味がもう分らないよ…
0255名前は開発中のものです。
03/03/08 06:00ID:MKbGXKwx0256245
03/03/08 09:51ID:AeESF41/真面目にレスいただき、ありがとうございます。
意味がわからない面も多々あり、申し訳ありません。
画像は用意したいと思うのですが、よかったらどうかお待ちください。
マップ自体は見た目上だけクォータービューで、
(画像は潰しておらず、べた表示です)
キャラクタの表示する座標だけを描画時にマップの端を軸に45度回転させて、
上下に半分潰すことでクォータービュー風(移動)にみせています。
要するに内部的に上に進めば
表示座標上は(45度/2の傾斜がついた)左上に進んでいることになるわけで、
内部のY軸方向のスケールと、
描画時のY軸方向のスケールは45度/2ずれているわけです。
なので内部的にY軸だけに補正をかけると、
描画時にはX成分にも影響を与える訳です。
勿論、内部的には円を近似した移動値で書かれているのですが、
その、円の移動値(−X-Y)〜(+X+Y)のスケールだけが
描画時には半分に潰されてしまっているわけなのです。
よって、内部的には正円ではなく、楕円に進む必要があるのか、と考えています。
すこし妙な感じがするのですが。
0257245
03/03/08 10:29ID:AeESF41/http://www.geocities.co.jp/SiliconValley-PaloAlto/7551/topview.jpg
な感じです。
マップの描画などは全く視野に入れません。
0258名前は開発中のものです。
03/03/08 11:16ID:tiy6mV84そりゃああた、パースを考慮に入れてないからっす。
普通の二次元画像を斜めにして単純に潰すと、絵としておかしくなる。
だから、その絵としておかしいMAPの上で正しくキャラを動かしても絵としてはおかしくなる。
この世には遠近法というものがあって、遠くのものは小さく、近くのものは大きく見えるのが世界の常識です。
実際には遠近法を考慮しなくてもそれなりに綺麗に見えるものなのですが、
奥行きが深い場合はちょっと不自然に見えます。
0259名前は開発中のものです。
03/03/08 11:18ID:Qzt+JfAGやっぱり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と同じだった…
さらに読み返すと、楕円に進む と同じようなこと言ってる気もする。
0262245
03/03/08 11:54ID:9W7WzJNL>>255
パースは一応理解しているのですが、
2Dとして不自然でないように取り入れるにはどうしたらいいのかと思いまして。
>>256様
そうですね、内部的なベクトルの大きさは同じです。
でも、見た目上の(プレイしている側からしてみれば)違っているように見えてしまいますよね。
これを正したいと思ったのです。
>>260、>>261
そうですね、中身が移動量が異なると気持ち悪いと思います。
そして、見た目上も正しいと思うのですが
クォータビューなゲームで
上下と左右の移動量が違う(ように見える)と何だか変な感じを受けたりしませんか?
これをうまく解決したい、と思ったのですが……。
うまく言えなくてもうしわけないです。
0263名前は開発中のものです。
03/03/08 13:03ID:HkNGp/2bヘンには感じないと思う。そう印象付けるような画面構成にするといい。
車の後ろから見るレースゲームで、等間隔にオブジェクトを配置したり
等間隔に地面に模様をつけるのは、走ってるという感覚を引き出すための
基本テクニックだったりする。のっぺりしてると速度感が沸かないのよ。
クオータービューについてもそういう工夫があっていいんじゃないかなあ。
0264あぼーん
NGNG0265416 ◆quHoSW/FCI
03/03/08 16:20ID:s3TXU6Pqもしかして、トップビューで言うところの斜め移動をさせてない? トップの
上下左右はクォーターでは斜め45度だが、トップでの斜めはクォーターでは
真横とかになるよね。
移動がマス方式のクォータービューでは斜め移動はそう見える。A列車3、4で
列車が真横に移動するのと、斜めではえらく差があるように。
0266あぼーん
NGNG0267あぼーん
NGNG0268名前は開発中のものです。
03/03/13 14:53ID:x1k2yze2描画周りは一通り出来たのですが、ここで疑問が・・・
キャラが動いたときの描画なのですが、
既に配置済みの背景の中を、ビュー行列を変えて移動させるのと
ビュー行列据え置きで、キャラ周りの背景を移動するたびに配置換えする
一般にどちらが良いのでしょうか?
前者の方が簡単そうにみえ、今はそちらなのですが、
MatrixのFLOATで補えないくらい広いマップとかは、どうなるのかなどと考え出したら・・・。
お馬鹿な質問ですが、よろしければマジレスいただけると嬉しいです。
0269あぼーん
NGNG0270名前は開発中のものです。
03/03/13 22:12ID:M64nHos+Ys3って横から見たような画面構成だっけ?
PC88やPC98はマップチップを組み合わせて画面を構成してたと思うけど、
(つまり後者)それほど難しくないよ。
0271名前は開発中のものです。
03/03/14 00:05ID:1VLZD/pCレスありがとうございます。やはり後者でしたか_| ̄|○
PC88やPC98ではと言うことですが、今はあまりこういう手法は用いないのでしょうか?
しかし、やはり効率的な描画方法っていうのは、今も昔も変わらなそうですね。
画面は仰るとおり、横から見たようなのです。
私はこれとリンクの冒険が大好きで・・・。どっちも一般にはアレですが・・・。
0272名前は開発中のものです。
03/03/14 00:06ID:1VLZD/pCスクリプト荒らし来ちゃうかな・・・。
0273名前は開発中のものです。
03/03/14 01:24ID:41+v9X+WGBとかのBG面があるゲーム機は今でもそんな感じ。
背景がモデルならば仕様次第な気もするけど、似たような事をやらなくも無い。
■ このスレッドは過去ログ倉庫に格納されています