-
- いいね！213
S.F.
@SFPGMR
これがそのアフターバーナーの基板のスペックらしいんだけど。1987/7リリースかあ。まあそれくらいの時期ですわ。確かに。CPUは日立の68000のカスタム版かあ。。 segaretro.org/Sega_X_Board
2020-06-06 07:28:18
S.F.
@SFPGMR
こういうCPUのカスタム化というのも大手メーカーではわりと普通にやってた気もする。私が制作に参加したゲームもCPUは6809のクローンの日立の6309というCPUのさらにカスタム版だった。主にこれはコピー・プロテクトの意味合いが大きかったらしい。
2020-06-06 08:01:47
S.F.
@SFPGMR
日立の6309というCPUはクロック周波数が3MHzで、6809のCMOS版という位置づけ。カスタム命令も入っている。でもまあ「高速な6809」という位置づけで使ってたわね。
2020-06-06 08:03:26
S.F.
@SFPGMR
最初のころのカスタムＣＰＵというのはインストラクションのバイナリコードを１：１で置換するような感じだったと思う。そうすればＲＯＭを吸い出しただけではコピーできないものね。ＣＰＵのクローンも作らないといけないから。
2020-06-06 08:07:15
S.F.
@SFPGMR
これにクロック・アップとかMMUとかを付加するような感じで徐々に拡張されていったかもしれんね。私のころはカスタムＣＰＵのデバッガがなかったので、最後の最後まで6309（ICE)で作って、マスターを作るときにカスタムCPUのバイナリに置換する感じだったね。
2020-06-06 08:09:40
S.F.
@SFPGMR
X Boardのスペック見てるけどやっぱりすごいわ。まずCPU。68000と日立の68000クローンのデュアルだよね。クロック12.5Mhzかあ。
2020-06-06 08:19:59
S.F.
@SFPGMR
サウンドCPUはZ80。当時のゲーム基板って、サウンドは別CPUでZ80でドライブってのが多かったのかなぁ。私が関わってたゲームも大半はそうでしたな。
2020-06-06 08:22:09
S.F.
@SFPGMR
オーディオはYM2151とDA（サンプリング音源）ですな。当時としては普通の構成っぽく見えるけど、DAのチャンネル数がすごいな。16CHですよ。これ。16ポリっちゅうことですわな。あっても2CHぐらいが普通だったよなあ。
2020-06-06 08:25:03
S.F.
@SFPGMR
つまり一時ワークやスタック用しかメモリは確保してなくて、プログラム本体はすべてROMに置くんだよね。よってPCのゲームなどでよく見られた、プログラムの自己書き換えなどのテクニックは使えない。使わんでもいいけどね（笑）。
2020-06-06 08:31:52
S.F.
@SFPGMR
RAMはトータルで802KBだけど、大半はスプライトのフレームバッファ用メモリなんだな。デュアルだとすると裏で書いてフリップする感じなのかな。
2020-06-06 08:35:37
S.F.
@SFPGMR
時代を感じさせるのはピクセル数だよな。320×224pixelだもんね。解像度上げるとメモリが半端なく必要になるからね。メモリが高価だったのもあるだろうし、この辺が妥協点だったんだろうな。当時の。
2020-06-06 08:41:38
S.F.
@SFPGMR
カラーパレットも9万色かあ。1つのカラーパレットが15ビットRGBと1ビットがシャドウ＆ハイライトってなってるね。RGBが5ビットずつということか。パレットカラー方式も当時普通だったね。表示されるピクセルは指定したパレット番号でパレットデータを呼び出してその色を表示する仕組み。
2020-06-06 08:47:10
S.F.
@SFPGMR
ただ15ビットカラーだというのがすごいね。でも1つのスプライトに使用できるのはそのうちの16個になるんだね。そうするとスプライトピクセルのビット数は4になるのかね。多分スプライト制御用のメモリでパレットのバンク指定するんだろうな。。
2020-06-06 08:49:04
S.F.
@SFPGMR
このスプライト拡大縮小機能というのがちょっと曲者でね。制作に参加した基板は拡大縮小の中心が左上隅なんだよね。そして右下に向かって拡大する。
2020-06-06 09:08:28
S.F.
@SFPGMR
これ結構めんどくさいので補正せずそのまま使用したりしてるゲームも実際存在する。沙羅曼蛇のブドウみたいなキャラがそうだと思う。これよく見ると弾が当たると右下に向かって拡大していく。 youtu.be/KRlJmqT9bLU?t=…
2020-06-06 09:13:04
S.F.
@SFPGMR
そして当たり判定の矩形もそれに合わせて拡縮する必要もあって。おそらくそれを省略してるゲームも多いと思う。もともと当たり判定って、ピクセル単位ではやってなくて矩形でやってるのでそもそもいい加減なんだよね（笑）
2020-06-06 09:14:59
S.F.
@SFPGMR
で厳密にやりすぎるとプレイヤーの感覚的に違和感を感じたり、ゲームが面白くなくなってしまうことも多いので、程よい感じで手を抜くのがプロではないかと（笑）
2020-06-06 09:20:38
S.F.
@SFPGMR
しかし私はこの補正に無謀にもチャレンジした。しかしアルゴリズムがバグっていて拡縮に応じた補正ができてなく、妙な感じに拡縮されるようになってしまった（笑）。今だとなんとなく原因がわかるんだけど、当時は原因究明する時間がなくてそのままリリースしてしまった（笑）。
2020-06-06 09:23:47
S.F.
@SFPGMR
当たり判定ですごいなと思ったのはやっぱりこのゲーム。R-TYPEもそうだったからプログラマーのスキルが高いんだと思う。当たったときのあたりマーク（跳ね返りとか爆発とか）の位置とかが絶妙。ここまで行くと死ぬんだなあというぎりぎりのところが弾を打つことでわかる。 youtu.be/9-uWyJ54NBM
2020-06-06 09:29:28