| 【 Making「ActBarrier」その２ 】 |
|---|
| Home | PC-6001mkII | Program | etc |
| 2017/02/28：コリジョンその１ |
|
敵、オプション、自機のコリジョンについて考える。 敵と、オプション＋自機のコリジョン処理回数は、単純に見て敵数32×4＝96回が必要となる。ここを何とかして簡略化して、速度を稼ぎたいところだ。 そうだ、自機とオプション用のコリジョンテーブルを作ろう。 以下のように自機とオプションの座標(左上部分)を中心にした範囲のビットを立てたコリジョンテーブルを、X方向とY方向のそれぞれで作成する。
この場合、X方向とY方向の判定結果をAND演算した結果である黄と青のオプションに当たっている事になる。
敵の大きさが全て同じの場合のみ成り立つという大きな制限はあるが、割と良さげな気がする。試しにこの考え方で作ってみるかな、後日にでも。 |
| 2017/03/01：オプション |
|
次はオプションを表示するための処理を作成する。 HSP版の処理内容を踏襲し、自機のトレース領域(256バイト)を確保し、自機が移動するたびに移動前の自機の位置をトレース領域に記録させていく。 このトレース情報を元に5個前、10個前、15個前の自機位置をオプションの座標にして、表示を行う。さて、いざ表示！
|
| 2017/03/04：パーティクルその１ |
|
表示上、もう一つの重要な要素であるパーティクルの処理に移る。 パーティクルの情報はY,X座標とY,X移動方向の4バイトでいいかな。表示時間も入れて5バイトにしようと思ったが、HSP版でも表示時間の制限を入れてないし、なにより5バイトは中途半端なので4バイト構成でいく。 管理領域は256バイトに抑えたいので、逆算で64個までのパーティクルを表示可能にする...予定。 とはいえ、64個のパーティクルを表示したらどこまで遅くなるかを確かめたい。とりあえずパーティクルの初期化と表示部のみ作成して実行する。
|
| 2017/03/05：パーティクルその２ |
|
とりあえず処理速度は棚上げしておいて、パーティクルの移動処理を作成する。 HSP版では、パーティクルの移動方向に毎回乱数を使っていたが、P6版で都度乱数を使うと遅くなりそうな気がする。 ここはひとつ割り切ろう。パーティクルの管理番号毎に移動方向を固定にし、パーティクル出現の度に管理番号をカウントアップするようにする。 パーティクルの管理数は256/4バイトで64。という事で、32方向のデータを作成し、32方向×2セットをパーティクル管理領域の移動方向部分にあらかじめ割り当てる事にする。 さて32方向の決め方だが、まずは中央から±3ドットの範囲から候補となる方向を選ぶ。このれらを8つの区画に分け、管理番号毎に3/8区画ずつずらしながら番号を割り振っていく。ざっとこんな感じかな。
|
| 2017/03/05〜07：コリジョンその２ |
|
2/28に考えていたコリジョン処理を実装し、オプションまたは自機が敵と当たったらパーティクルを出すようにする。 当たったかどうかが視認できるようになったので、動かすと楽しい。
このあと、少しだけパーティクル処理を高速化したが、最大でほぼ29割り込みだった。うむむ、目標のおよそ1.5倍の遅さか…。 |
| 2017/03/11：乱数 |
|
さて、次は乱数だ。 乱数というと、前回の乱数値に中途半端な数を掛けて余りを取るといったイメージがある。マシン語で掛け算はコストが高いので、何か別の方法がないか探してみる。 Webを探して目に留まったのは、「和田維作のホームページ」の「良い乱数・悪い乱数」だった。これによると、UNIXのrandom( )は足し算だけで乱数値が求まるとの事。え、掛け算が要らないの？ ただ、乱数値は4バイト(0〜4,294,967,295)の範囲になる模様。Z80だと4バイトの計算は面倒なので、せめて2バイト(0〜65,535)にしたい。乱数値の範囲を2バイトに縮小しても乱数っぽくなるかはわからないが、とりあえず処理を作ってみる。 軽く乱数値を確認した限りでは、値がばらけているように見える。とりあえずこれで進めてみるか。 |
| その１ | Making「ActBarrier」 | その３ |