MSX追懐記

さて、今回はLaboratoryテーマ��25「SCREEN2のグラフィックをFONTデータにして扱いたい」その�B、最終回です。
前回のツール、「SC2toFNT」でFONT化したSCREEN2画像をFONTで表示するサンプルです。

画面全部にFONTをズラーっと並べて表示して、上中下段にFONTデータを登録するだけです。


「CNVPRT.BAS」【ダウンロード】

分割保存されたFONT「.FNT」ファイルのファイル名（「ALPHA1.FNT」の場合「ALPHA」）を入力すると、上段、中段、下段の3ファイルを読み、元のSCREEN2の画像を表示します。
但し、FONTなので自由に横移動などは可能です。
普段は、1つのFONTデータを上中下段すべてに登録するのですが、SCREEN1.5の仕組みが分かると、上段ステータス表示用FONT、中段ゲームFONT、下段メッセージ用文字FONTと分ける等、色々できると思います。

サンプルデータとして、上段「ALPHA1.FNT」、中段「ALPHA2.FNT」、下段「ALPHA3.FNT」が同梱してあります。

さて、今回はLaboratoryテーマ��25「SCREEN2のグラフィックをFONTデータにして扱いたい」その�Aです。
いつものテーマ説明は前回終わっているので、いきなり本題です。

SCREEN2の画像データをFONTに変換するサンプルプログラムです。

「SC2toFNT.BAS」【ダウンロード】

SCREEN2「.SC2」画像ファイルのファイル名（「ALPHA.SC2」の場合「ALPHA」）を入力すると、上段、中段、下段の3ファイルに分けて「.FNT」ファイルを作成します。（上段「ALPHA1.FNT」、中段「ALPHA2.FNT」、下段「ALPHA3.FNT」）

難しい事は何もしていません。
サンプルデータとして、「ALPHA.SC2」が同梱してあります。

今回は、Laboratoryテーマ��25「SCREEN2のグラフィックをFONTデータにして扱いたい」その�@です。
初回はテーマに挙げるに至った理由です。

アドベンチャーゲーム等のグラフィック主体のゲームを作る時、MSX1ではSCREEN2を利用することが多いと思います。

画像出典: 『Tagoo』　ZARTH　MSX1版
https://msx.jpn.org/tagoo/s_check.cgi?LINE=482

SCREEN2はMSX1では、フルグラフィック（横256ドット×縦192ドット、16色）を扱える唯一のモードとなります。
ただ、横8ドット毎2色と、独特な仕様で、色の滲みを抑えるためテクニックが必要になります。
また、SCREEN2上で文字を表示させるときはFONTが使えないため、標準のFONTになります。

そこで、SCREEN2の綺麗なグラフィックを、SCREEN1のように簡単に扱えると言う事で、普段使われているのがSCREEN1.5と呼ばれるモード。
表面上はSCREEN1ですが、VRAM上はSCREEN2と言う便利なモードです。
これを利用することで、SCREEN2の綺麗さでFONTが扱えます。

MSXは全部で256種のキャラクタがFONTとして扱えます。（2023年7月16日記事参照「Laboratoryテーマ��15「任意サイズのFONTキャラクタを指定座標に表示させたい」）
それをズラーっと画面に並べると256種÷横32列＝縦8行しか並びません。

そこで、それを縦に3つ並べると、縦8行×3＝縦24行で横32列×縦24行と、MSXの画面サイズになります。

SCREEN1.5でFONTが上中下段で別のキャラクタが設定できるのはこういう理由です。

しかしながら、SCREEN1.5ではグラフィックツールで絵が描けないため、「FONT EDITOR」でキャラクタを作成する必要があります。
しかし8×8ドットのFONTで全画面分描くのはまず無理です。
出回っているFONTを描くツールを探しても16×16ドットが多いかな？
そう言った理由から、今回のLaboratoryテーマとなりました。

SCREEN2のデータをFONTデータに変換できるツールがあれば、WindowsのグラフィックツールでMSX1の16色で絵を描いて、「BMP to MSX」等でMSX1のSCREEN2へコンバート。
コンバートしたSCREEN2画像を、ツールを使ってFONT化。
これが出来れば、背景やボスキャラなど、大きなキャラクタの作成が非常に楽になります。

そろそろ「ゲーム制作」カテゴリで制作中の3Dロールプレイングゲームの敵グラフィックに取り掛かる必要があるため、Windowsで絵が描けるのは凄い効率アップです。

今回も、「ゲーム製作」で制作中の3Dダンジョンロールプレイングゲームに関連するテーマを1つ追加します。
そろそろ、3Dダンジョンロールプレイングゲームに出現する敵グラフィックを描く事を考える必要がありますが、なんとか楽に描ける方法はないか検討した結果、SCREEN2で描いた絵をそのままFONTとして扱えれば簡単ではないか？と考えました。
Laboratoryのテーマに挙げ、SCREEN2のVRAM構成の説明も併せて考えたいと思います。


SCREEN2のグラフィックをFONTデータとしてSCREEN1.5で扱えれば、いちいち方眼紙にグラフィック描いてそれをツールでFONTファイル化する手間が省けるので、キャラクタ作成が捗ると思います。

専門学校の夏休みも終わり新学期が始まった頃、遂にツール集の製作に乗り出しました。
理由は簡単。
一番は当然、自分がキャラクタ作成するのに、方眼紙に描いてそれをDATA文化するのが面倒になったため。
二番は、複数人で1本のゲーム製作をする事が増え、キャラクタデータの作成・変更を皆に見せながらするためです。
実際何人かには操作を覚えてもらい、直接作ってももらいました。

ただ、最初の方のバージョンは機能も少なく、MSX1相当の機能しか持ち合わせていませんでした。
まぁ、MSX1相当のゲームしか製作していなかったので事足りてましたが…。
今残っている一番古いバージョンの「SPRITE EDITOR」と、「FONT EDITOR」です。

「SPRITE EDITOR Ver.1.2」　単色SPRITEのみです。

「FONT EDITOR Ver.1.2」　こちらも機能最低限
共にVer.1.2です。
開発初版のVer1.0は1989年でしたが、このVer.1.2は既に1990年になってます。
かろうじて実用レベルになったのがこのバージョンです。
なのに「SPRITE EDITOR」はまだ2枚重ねすら実装していません。
操作はジョイスティックと、キーボードの併用で、使い難いです。
動かしてみようと思ったけど、全く分かりませんでした。
ここからよく今の機能まで上がったと感心しますね。
後にマウス購入してマウス操作専用になったのがVer.2.0です。

このツール集の製作によって、キャラクタデータの製作が飛躍的に効率化したと同時に、ツール集自体のバージョンアップに時間を取られ、ゲーム製作は停滞するという不毛な時期でもありました。
やっぱり一人ではできる事に限度がありますね。

「ゲーム製作」カテゴリの、3D描画の5エリア分割した際のエリア表記�@〜�Dを、描画ワークの表記�@〜�Gとダブって判り難いので、ローマ数字の�T〜�X表記に変更しました。（2023年9月9日記事参照「【ゲーム制作】3Dダンジョンロールプレイングゲーム　第13回」）



それに伴い、下記過去記事も同様に変更しました。
・2023年6月8日記事「【ゲーム制作】3Dダンジョンロールプレイングゲーム　第3回」
・2023年6月10日記事「【ゲーム制作】3Dダンジョンロールプレイングゲーム　第4回」
・2023年8月17日記事「【ゲーム制作】3Dダンジョンロールプレイングゲーム　第10回」

「ダウンロード」に追加で新規公開したゲームやツール、サンプルの記事へのリンク追加、「Laboratory」テーマメニューの公開分記事へのリンク追加。

それ以外は、画像の貼り直しや、記事の誤記の修正程度です。

3Dダンジョンロールプレイングゲーム第13回目です。
今回は遂に、3D表示のプログラミングに挑戦します。
前々々回（【ゲーム制作】3Dダンジョンロールプレイングゲーム　第10回）に書いたロジック通りに、前回設定した表示ワークの地形を描画します。
これはもう簡単。
条件に従って表示ロジックを記述していくだけです。


気を付けなければいけないのは一カ所だけ。


正面�Dに壁があった時、�Vだけでなく、その両サイド�Uと�Wの壁も描画し、�T描画のロジックへ飛ぶくらいですね。
壁の描画はLaboratoryテーマ��15「任意サイズのFONTキャラクタを指定座標に表示させたい」のサブルーチンで描画します。


前回同様各向きで描画してみました。





期待通りの動きです、問題なしですね。
マウスが使えなかった時に、とりあえずで作成したFONTなのでチープです。

では、次回は描画が非常にチープなのでもう少し（ほんの少し）見栄え良くしてみます。

専門学校の夏休みは短い…。
2週間くらいしかなかったと記憶しています。
私の兄が大学生で、夏休みが2ヶ月以上あったので「大学って何しに行ってるんだろう？」と思ってました。（兄だけかと思いますが…。）

その短い夏休みを、購入したMSX2+の機能検証に費やしました。
CPU的な違いはないので、その他の機能強化となります。

まずは追加機能。
「HB-F1XDJ」だけになりますが、FM音源が内蔵されています。
音色が綺麗。
次に漢字ROMが内蔵されています。
んー、漢字表示ですがMSXの解像度では文字が大きくなりすぎてやっぱり使いづらい。
小さくするとインターレースになり、ブレるし…。
あと、スピードコントロールと、連射機能が付いています。
ゲームプレイではお世話になりました。

次にグラフィック関係。
やはり、特筆すべきはSCREEN12の自然画モード。
YJK方式により19,268色の同時発色が可能で、とても綺麗でした。
…が、それだけ。
元々グラフィックデータのフロッピーディスクからの読み込みに時間が掛かるところ、圧縮掛けてるので展開に更に時間が掛かる。
しかも、1画面に必要なVRAM容量は128KB（2画面）。
2DDのフロッピーディスクしかないMSX2+では容量的にも扱いにくく、コンパイルの「真・魔王ゴルベリアス」のようにオープニング、エンディングくらいでしか使えない…。

画像出典: 『電撃オンライン』　真・魔王ゴルベリアス　MSX2+版
https://dengekionline.com/articles/96649/
本編を自然画モードで作ったら、フロッピーディスク何枚組のゲームになるんだろう…。
他にはハードウェア横スクロールの実装！
ただ、これも後にコナミの「スペースマンボウ」のようなSETADJUSTの応用による1ドット横スクロールがMSX2で実現されてからは、MSX2+だけの特徴ではなくなりました。

画像出典: 『GameFAQS』　スペースマンボウ　MSX2版
https://gamefaqs.gamespot.com/msx/917251-space-manbow/images?pid=917251&img=6

と言う訳で、特にMSX2+だからこれが出来る！と言うのもなく、結局そのまま今まで通りのゲーム作りとなりました。

連続バグ報告でスイマセン…。
Laboratoryテーマ��21「指定座標に指定サイズのメッセージウィンドウを開きたい」その�@のロジック中にバグを発見しました。

「3Dロールプレイングゲーム」の制作中、プレイヤー移動用にジョイスティック入力処理追加したとたんに暴走しました。（フリーズ）
キーボード操作では、問題ありません。
原因は、ジョイスティックのボタン操作判定用のBIOS「GTTRIG」（&H00D8）。
メッセージ表示速度調整用の時間稼ぎループをBレジスタでループさせていて、そのループ中にボタン判定（WAIT飛ばし）しているため、Bレジスタの内容が壊れフリーズしたものと思われます。
「MSXテクニカルハンドブック」には、「GTTRIG」の使用レジスタは「AF」のみとなっているので、これを信じて他レジスタの退避していなかったのですが、よく考えたらジョイスティックを使うとなぜかBレジスタが壊れるんです。
このことは経験則で知っていたのですが、あまりに久しぶりだったので「MSXテクニカルハンドブック」を信じてしまいました…。
と、言う事で「GTTRIG」使う際には必要ならBレジスタを退避しなければなりません。（調べてないけど他のレジスタも？）
うーん、ブランクって怖いですね…。

2023年8月29日の記事、Laboratoryテーマ��21「指定座標に指定サイズのメッセージウィンドウを開きたい」その�@を再度改訂しました。
（サンプル自体はキーボード入力固定なので問題はありませんが、バグ有ロジック放置するのも嫌なので…。）

サンプルプログラムの再ダウンロードをお願いします。
ご迷惑おかけし申し訳ありません。
…ん？今回は私のせいなのか…？

3Dダンジョンロールプレイングゲーム第12回目です。
随分久しぶりになってしまいました。
Laboratoryテーマ��23「コマンドを選択肢メニューを開いて、選択したい」のサンプル作りにてこずっておりまして、時間だけが過ぎていく…。
まぁ、おかげで「MSX回顧録」、だいぶ進めることが出来ましたが…。

さて、今回は3D表示のプログラミングに挑戦します。
前々々回（【ゲーム制作】3Dダンジョンロールプレイングゲーム　第9回）で考えたロジック通り、�@〜�Gの表示ワークへセットするプログラムを作ります。
これ、BASICの配列変数を使えれば簡単にできるんですが、マシン語にはそんな便利な機能はありません。

ただ、考え方は配列変数の考え方がそのまま使えます。
BASICですと、配列変数にマップデータを代入（MAP(21,21)）し、自機のX座標、Y座標をそれぞれ変数X、Yとすると、X、Ｙを起点に、調べたい座標位置に加減算をします。

例えば、上向きの場合、�@＝MAP(X-1,Y-2)、�A＝MAP(X,Y-2)…と言った感じです。
簡単ですね。
それをマシン語で実現するためには、この加減算値でデータベースを作成します。（8ワーク×4方向×X/Y＝64バイト）

XとYの加減算値は-2〜2の5つしかないので、容量節約のためにBレジスタ上4桁をX加減算値、下4桁をY加減算値とします。
これで、容量を半分に削れました。（8ワーク×4方向＝32バイト）
先ほどの加減算値のルール通り変換しました。

データベース登録完了したら、向きにより自動でデータベースアドレスを算出し、データベースから加減算値を取得し、マップデータから地形データを読んでワークに設定するマシン語サブルーチンを作ります。

&HC370からは、Bレジスタに加減算値を代入しコールすると、マップデータ上の自分の位置＋加減算値のアドレスを計算し、Aレジスタにその座標のキャラクタコードが返されるルーチンです。
&HC3B8は、向きによってデータベースアドレスを算出し、データベースを読んで8つ分ワークへ地形データを設定するルーチンです。

各向きで読み込んだキャラクタコードを表示してみました。

期待通りの動きです、問題なしですね。

では、次回は3D表示のプログラミングです。