おちゃめくらぶ掲示板 - 1659321896

1224：御茶目菜子：2012/07/30(月) 23:11:36: 日経ソフトウェア9月号に関して気になったこと
日経ソフトウェアの9月号を買ってきたにょ。
今回のプチコン講座はGRPによる「マリオカート風のレースゲーム」が掲載されているという
ことで少し期待していたにょ。
まず最初にGRPによるスクロール、パレット書き換え、基本的な当たり判定の方法の記載が
があり、それを元にしてレースゲームを作っているにょ。
これは私が書いたプチコン講座では第7回と第6回に相当する内容にょ。

　第6回　疑似3Dゲームを作ろう（レースゲーム編）
　http://ww5.tiki.ne.jp/~ochame/petitcom/p006.htm
　第7回　グラフィック面（GRP）をスクロールさせよう
　http://ww5.tiki.ne.jp/~ochame/petitcom/p007.htm

まぁさすがにページ数の関係でスクロールに関してはGCOPYの使い方を少し書いてあるくらいで
私の講座ほどは無駄に長くはないけどね（笑）

さて、期待のマリオカート風レースゲームというサンプルゲーム「道路ランナー」を見ると
ぱっと見た感じでは私が作った「PETIT RUN」によく似ているにょ。
というのも自キャラが車ではなく人間（デフォキャラの「男の子」）だからにょ。
これは私がPETIT RUNにおいてそのキャラを使った理由と同じくデフォでスプライトキャラに
車のデータがないというものみたいなので単なる偶然の一致だと思うにょ。
人間キャラを走らせるレースゲームというのも私のPETIT RUNが元祖というわけでもなく
コンシューマゲームでもいくつか存在しているし、プチコンゲームでもえぬおう氏が作った
「メイジラン」とかもあるため偶然の一致はただ「男の子」のキャラを使っているということ
くらいにょ。

肝心の内容だけど私の講座では第2回でスプライトの基本的な拡大縮小方法について書いており、
第5回でそれを使った疑似3Dゲーム（スキーゲーム編）を書いているため第6回の講座の
レースゲーム編はその続きという位置づけになっているにょ。
そのため違和感のない拡大縮小を追求しているにょ。
それは「距離が2倍離れていれば表示サイズは半分になる」というものにょ。
あくまで基本的なものだけどこれをちゃんと行っていれば視点変更を行っても少なくとも
進行方向に対しては表示の違和感は無くなるにょ。
日経ソフトウェアのプチコン講座では私とは別の方法で遠くのものは小さくなるように
しているにょ。
なぜ、二次関数でそれが表現可能なのかということを端折っているのも気になったけどそれ
よりも気になったのは次の2つにょ。

　(1)これが本当に世界一シンプルなのか
　(2)カーブの消失点が画面の中央でいいのか

(1)この講座では「おそらく世界一シンプルな3D描画エンジン」と記述されているにょ。
そして、結論を見ると「今回のような3D表示では、できるだけ処理を簡略化して処理の
負担を減らしてみましたが、それでも画面の更新はあまり速くありません。この辺は
ソフトウェアだけによる3D表現の能力的な限界でしょうか。」と記述されているにょ。
実際にプログラムを実行してみるとmikIIでさえ7fps程度しかでないためかなり重いもの
には間違いないにょ。

このプログラムの処理を簡単に書くとまずは縦スクロールするコースを生成してそれを
GSPOITで読み取りリアルタイムに拡大縮小しているにょ。
これに回転機能を加えれば本当にマリオカートのようなゲームは作れるとはいえ、この
ゲームにおいて言えばこの処理は最適化されたものとは言い難いにょ。
というのもこのゲームで描画しているのは道幅が固定の道路とセンターラインだけと
なっているからね。
これを縦11分割で拡大縮小を行うことで疑似3D表示を行っているのだけど進行方向は
固定で拡大率も固定であるためGSPOITでわざわざ読み取らなくてもすべて演算で道幅や
センターラインの座標は求めることが可能にょ。（ループ回数は11回で良い）

これが「速度は遅いけど汎用性を重視した描画エンジン」と記述しているならば特に気に
することは無かったのだろうけどループ回数を1/50に減らして同じように表示する方法が
ある（ループ回数に反比例して速くなるわけではないけど60fpsは余裕で出せるようになる）
ためにこれが限界とはとても思えないにょ。（演算で表示座標を求めている私の「PETIT
RUN」はこの「道路ランナー」のループ回数11回よりも高精細となる21回のループにも
関わらず初代で60fps以上、mkIIで80fps以上の速度が出ている）

(2)レースゲームでは非常に重要なのがカーブの描画方法にょ。
そのため私も第6回の講座では冒頭からそれについて詳しく書いているにょ。
これは別に難しいものではなくカーブの場合は少しずつずらしていきその積算によって
表現が可能になるということにょ。
つまり、基準点からずらす関係上カーブの消失点は画面中央にはないということにょ。
もちろんこれは絶対にないというわけではなく視点切り替えが可能なゲームでカーブの
終点に視点を向けた場合のみ消失点が画面中央になるにょ。
この道路ランナーの場合は消失点が無限遠が中央に存在しているため常にその方向に
向かって進行しているのならば間違いとは言えないにょ。
ただし、道に沿って進行していないため直線をまっすぐ走ったらコースアウトになって
しまうにょ。

なぜ、そのような理不尽なことが起きてしまうかというと下記のように図で示せば
一目瞭然にょ。
http://ww5.tiki.ne.jp/~ochame/test/curve.png
上記の基本に忠実にカーブに合わせて消失点をずらした表示方法をとっている（A）の方法は
コースデータ通りにハンドルを切ればきちんと曲がれるのに対して消失点を中央に固定して
いる（B)の方法は本来のコースデータで用意されたカーブに対して逆方向にハンドルを
切らないと曲がることができない場合が発生してしまうにょ。
これが中間地点Bで曲率が変わらずAB間、BC間が一定の場合は表示方法（A）では右に向かった
道路となっているためハンドルを右に切り続ける必要があるけど表示方法（B)では画面上は
完全な直線道路にも関わらず徐々にコースからそれていくことになるにょ。（これは70行を
RX1=1にすれば簡単に分かる）
これが視点切り替えが可能だったり、マリオカートのように回転機能が搭載でたまたま
カーブの先が画面中央になっていたら右カーブなのに左にハンドルを切らなければならない
という事態が発生することもあるけど進行方向が固定のゲームでは（B)の方法は間違った
ものといえるにょ。

以上主に気になった点として2つのことに関して書いたけど(1)の方はこのゲームの場合は
さらに良い方法があるという程度なので間違いではない（ただし、これが「限界」という
点に関してのみ間違い）なのに対して(2)の方は明確に間違いであるため修正を期待したい
ところにょ。（これは制作者自らが仕様として掲げているのもなのでバグではなくその仕様が
間違いだといえる）