フルーツフィールドの勝手移植第二段。 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形式ファイルの出来上がりである。 そう。キモはヘッダなのだ。

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

ファイルヘッダ

情報ヘッダ

定義はシンプルだし、大してめんどくさくなさそうだけれど、いくつか注意しないといけないポイントがある。

ESP32は Little Endianである。 なんで、'BM'という文字コードを格納しようとして、bfType = ('B' « 8) | 'M'; とかすると、'MB'の順に格納されてしまう。 0x424d としても同じこと。

定義にそって、uint16_t bfType とするより、uint8_t bfType[2] として、'B', 'M'の順に格納する方がいいかもしれない。

昔からそうだけれど、CPUがメモリーにアクセスするとき、アラインメントに沿っていないとアクセスが遅くなったり、場合によっては、取り出しが分割されたりするので、気の利いたコンパイラだと、構造体の定義は、いい感じにアラインメントされるように処理される。

すると、ヘッダのデータが狙った場所に出てこなくなる。

なので、構造体を使ってヘッダーを作成するなら、ヘッダーを詰めて配置するようにコンパイラに指示しなければならない。 attribute³⁾ は詰めて配置しろという指示になる。 大体が、組込みプロセッサであるESP32の場合、デフォルトがこっちでいいんじゃないかという気もするんだが。

    struct __attribute__((__packed__)) BMP_File_Header {
        uint16_t bfType;
        uint32_t bfSize;
        uint16_t bfReserved1, bfReserved2;
        uint32_t bfOffBits;
    };

    struct __attribute__((__packed__)) BMP_Info_Header {
        uint32_t biSize;
        uint32_t biWidth;
        uint32_t biHeight;
        uint16_t biPlanes;
        uint16_t biBitCount;
        uint32_t biCompression;
        uint32_t biSizeImage;
        uint32_t biXPixPerMeter;
        uint32_t biYPixPerMeter;
        uint32_t biClrUsed;
        uint32_t biClrImportant;
    };

なんで、こんなことを書いているかというと、まさにこれがゆえに、作成されたBMPファイルは「サポートされない形式」っていわれてしまったのだから。

これはスクリーンショットと直接関係はないのだけれど、ファイル名を自動的に生成できるようにしておいた方が、多分便利。 RTCが入っていれば、yyyymmdd_hhmmss とかを入れておけば、一秒以内に立て続けにスクショされない限りはユニークなファイル名が補償できるが、M5StackにRTCがつながっているかどうかわからない。 というか、多分使われていないだろう。

スクショを撮る関数はファイル名を受け付けるようにしておくが、なかったら、screenshot_0000.bmp から始めて、9999まで10000枚の画像を保存できるようにしておこう.

4桁にしたことに深い意味はない。 5桁や6桁が良ければそのようにプログラムを改変すればいいだろう。

char ScreenShot::_filename[PATH_MAX] = "/screenshot_0000.bmp";

const char *
ScreenShot::get_next_filename()
{
    char num[5];
    strncpy(num, strchr(_filename, '_') + 1, 4);
    int n = strtol(num, nullptr, 0);
    while (SD.exists(_filename))
    {
      if (++n > 9999) n = 0;
      snprintf(num, 5, "%04d", n);
      strncpy(strchr(_filename, '_') + 1, num, 4);
    }
    return _filename;
}