フルーツフィールドの勝手移植第二段。 M5 Stack に BLEキーボードをつないだら、何か、アクション性のあるものも作ってみたくなりました。 でないと、キーボードにオートリピートをつける動機づけができないので。

そんなわけで、アクション性、というほどのものではないが、パズルは程よい題材だということで、フルーツフィールドを移植することに。

PC-6001mkII版に使った、PC-8001版のキャラクターをベースにしたものを今回も流用することに。 ただし、PC-6001mkII版は、PC-6001mkIIのVRAMに合わせたデータ構造にしてしまったので、これを逆に汎用の形に戻して、改めてRGB332 ¹⁾にすることに。

ハイハイスクールアドベンチャー経験から、スプライトが使えるといってばかばか使っているとあっという間にメモリを使い切ってしまうので最初から8bppで、しかも、8×8のキャラクターを16×16に引き伸ばして表示する方向でさらにメモリをケチることに。

音は、本格的なサウンドドライバーを作ったりしないで、単純に割り込みの中で、M5.Speaker.tone() を使って適当に鳴らすだけにします。 この割り込みを使うのも今回のテーマの一つです。

あとは、BLEキーボードハンドラに、オートリピートを持たせること。

とりあえず、コンストラクションモードは省いて、したがって、コンストラクションデータの保存と読込もとりあえずは省いていくことにします。

以下、実装にあたってのあれこれを書き綴ります。

M5 Stack/M5 Core2 は 320×240 の 16bppの画面を持っているので、160×100 の PC-8001 由来のゲームを移植するのには不足はありません。

方針のところにも書いたように、キャラクターは8×8でM5GFX のスプライトとして保持します。 描画するときに、いずれかの段階で16×16にストレッチすることにします。 ストレッチのコストはありますが、メモリをけちるのはこの環境では大切です。

キャラクタを16×16で表示することにすると、ゲームマップは 16×10キャラクター構成なので、256×160 pixels の画面領域を占有します。

一応、M5 ATOM + 外部液晶(240×240)も視野に入れているので、拡大縮小は必須でもあります。

なお、タイトルロゴは、PC-8001版からの流用ではなく、Google Geminiに作らせたものを使っています。

M5Stackにせよ、なんにせよ、スクリーンショットを撮る機能は搭載されていないので、スクリーンショットが欲しかったら、それをプログラムに組み込むしかない。

めんどくさいファイル形式はコードがデカくなるだけなので、BMP形式で出力するものとする。 めんどくさいからパレットも省略して²⁾、M5.Displayの表示している16bppの画像をがさっと書き出す。 大したことないだろうと思ったら、ちょっとだけめんどくさかった。

BMP形式のファイルは、ファイルヘッダ＋情報ヘッダ＋パレット情報＋画像データという構成になっている。 なので、ヘッダをつけてやればBMP形式ファイルの出来上がりである。 そう。キモはヘッダなのだ。

ヘッダの構成は次のようになっているらしい。

ファイルヘッダ

情報ヘッダ