MSX追懐記

3Dダンジョンロールプレイングゲーム　第31回目です。

さて、今回は「IN」を組んでいきます。
前回フローにした通り「宿屋」は、ほぼメッセージデータで賄えます。
簡単です。


次に、スクリプトの命令「IN」を組んでいきます。
�@所持金が足らなければ、飛び先へ。
�A所持金を減らす。
�B体力・魔力回復。


�C画面暗転


次回からは、残りのスクリプトを組んでいきます。

3Dダンジョンロールプレイングゲーム　第30回目です。

さて、前回のメインのメッセージウィンドウが所持金表示ウィンドウになってしまう不具合を解消するために、メッセージデータの組み込み制御コードに「|」（&H7C）を追加しました。

680〜700行にあった「イベントアドレス検索」と、「メッセージアドレス検索」をサブルーチン化し外へ出す事で、この領域を確保し組み込み制御コード「|」（&H7C）処理追加。

外へ出した「イベントアドレス検索」と、「メッセージアドレス検索」サブルーチン

この制御コードは、メッセージを表示後、キー入力待ちせず、すぐにスクリプトを実行するコマンドです。
メッセージデータを「|」だけにすると、メッセージ表示なしでスクリプトを実行します。


これで、新たにメッセージウィンドウを開き直してから、メッセージ表示することで不具合を解消できました。

うーん、「YN」命令でメインウィンドウのサイズを記録しなければ済むかとも思ったのですが、今度は別の場所に不具合出そうだったので、今回はこれでいきます。
検証に充てている時間もそう多く取れないし…。

大きなバグが出たら開発諦めそう…。

次回からは、「IN」命令を組んでいきます。

3Dダンジョンロールプレイングゲーム　第29回目です。

さて、「INn」を組む予定だったのですが、フローに抜けを発見。
所持金が足りない時の「おかねがたりません。」です。

また、お金を使うので、所持金表示が必要です。
スクリプトで所持金が表示できないので、急遽、新命令「GP」（Gold Print）を作成しました。
宿屋に入った時に所持金を表示します。


フロー書き直しました。


さて、ここで問題が発生。
所持金表示した直後に「YN」命令を実行すると、メインのメッセージウィンドウが所持金表示ウィンドウになってしまう事が判明。
それ以降のメッセージを所持金表示ウィンドウに表示しようとしておかしくなる不具合が発生してしまいました。


不具合の修正も含め、どの修正方法が最適か現在検討中。

皆さんはMSXの実機を使っているのでしょうか？
私はBlueMSXを使っていますが、エミュレータは他にもいろいろありますよね？

時々、WebMSXも使っているのですが、どうも使い辛い…。
第一に、プログラムを開発していてWebMSXを終了する時に、「Save Disk Image」でディスクイメージを保存しなければならない。
それを保存し忘れてWebMSXを終了してしまうと、そこまでに開発した分がなくなってしまう…。
あぁぁ…。
何回やった事か…。
ただ、プレイするには手頃なので重宝します。

現状、私は制作はBlueMSX、プレイはWebMSXとなっています。
今のところ、他のエミュレーターは触っていません。

実は専門学校に、MSXでプログラミングできる仲間がいました。
今まで、MSX仲間と言っても、プログラミングを教え合える仲間はいませんでした。

ただ、私と違って完全なMSX2ユーザーでした。
それでも、「なぜそんな不便な機能（MSX1）使ってるの？」と言いながらも、私がMSX1が好きだと言う事を理解してくれていました。
因みに以前に書いた、「ドラクエ」の処理の仕方でヘルプを求めてきたのが彼です。（2023年5月20日記事参照「3Dダンジョンロールプレイングゲーム」）

しかし彼は、マシン語やプログラミングの知識もあり、ゲームも大好きなのですが、自分でゲーム制作することはしませんでした。
難題なロジックや、困難な処理の仕組みを解析して、それをプログラミングして再現させる事を趣味としていました。
ですので、プログラミングレベルは非常に高かったと思います。
比較がゲームと、ロジックなので出来ませんが…。

ただ、彼は非常にゲームが好きで、バイト代をほぼゲームに突っ込んでいました。
私もそれを借りてプレイするようになり、徐々にプレイヤー側に片足突っ込み始めました…。

制作中の3Dロールプレイングゲームですが、今までBlueMSXのMSX2+環境で開発しておりました。

特にそれで困らないのでそうしていたのですが、ふと「本当にMSX1環境で動作するのかな？」と思ってしまいました。

そこで、MSX1環境に設定し、起動。

…動かん！
え？　なんで？
MSX2の機能使ってないよ！？

慌てて調べてみると…、使ってました…。

SCREEN1.5にするロジックと一緒に、SPRITEモードを2にするロジックが入っていました。（SPRITEモード2はMSX2の機能です。）
そらダメだ…。


SCREEN1.5にするロジックだけ残して再起動！

おぉ！　今度はちゃんと動作しました。

MSX1
んー？　なんか、色合いが違うなぁ…。

MSX2+
MSX1の方が色が薄い…。
何の違いなんだろう？
まぁ、とりあえずMSX1環境で問題なく動作することが確認できました。
このままこの環境で制作続けます。

3Dダンジョンロールプレイングゲーム　第28回目です。

さて、今回はスクリプトの命令「IN」を組んでいきます。
「INn」で宿屋となります。

前回の「IS」に比べれば、とんでもなく簡単です。
前回同様フローを書いてみました。

ほぼメッセージデータで組めます。
「IN」のスクリプト処理は、所持金減らして、体力・魔力を回復して、画面の暗転処理するだけです。
状態異常の毒はアイテムか魔法でないと消せません。

画面の暗転処理は、ちょっと凝ってみます。
上下から暗転するパターンで、偶数列は上から、奇数列は下から1FONT単位で黒く画面を消していくことにします。

次回は、実際に「IN」を組み込んでいきます。

3Dダンジョンロールプレイングゲーム　第27回目です。

さて、今回もスクリプトの命令「IS」を組んでいきます。
前回「買い」を組みましたので、「売り」を組んでいきます。

「買い」同様、いくつかのサブルーチンが必要です。
�@所持アイテム�ｂｩら、そのアイテムデータの先頭アドレスを検索するサブルーチン。
「買い」の�@と同じ。

�A所持アイテム格納エリア（16バイト）が空かチェックするルーチン。（空ならエラー。）

コメントのKWは「KEY WAIT」、GPは「GOLD PRINT」のサブルーチンです。

�B選択された所持アイテムの格納エリアのアドレスを検索するサブルーチン。

今作は所持アイテム数が16個と少ないので、並び替えしない。
そのため、所持アイテム格納エリアの空きを飛ばして検索する必要有り。
どういう事か具体的に説明します。

格納エリアに上図のように入っていたとして、3個目のアイテム��20を使うとします。

すると、3個目の格納エリアが空きます。
この時、アイテム��22は、アイテムとしては3個目になりますが、格納エリアは4個目となります。
並び替えしないと、格納エリアの空きを飛ばして個数カウントしないと、正常なアイテムを選べません。
因みに、この時アイテム��21を手に入れると、格納エリアの一番若い空き場所である3個目に格納されます。


�Cアイテム名と売値を一緒に表示するサブルーチン。

コメントのISは「ITEM SEARCH」、VPは「VARIABLE PRINT」です。
売値は買値の半額（/2）となります。

�D所持金額を表示するサブルーチン。
「買い」の�Bと同じ。

�E標準メッセージウィンドウを表示し、メッセージを表示するサブルーチン。（標準サブルーチンとして利用。）
「買い」の�Cと同じ。

�F重要アイテム、若しくは装備中アイテムかチェックするルーチン。（重要アイテム、装備中アイテムならエラー。）

アイテム�ｂﾌ8ビット中先頭1ビット目を重要品フラグ、先頭から2ビット目を装備中フラグとします。

どちらかでも立っていれば、売れない（捨てられない）事にします。
アイテム種類は6ビットなので、最大31種類作成可能。（今作は23種類。）
アイテム種類を32種類以上作りたければ、アイテム格納ワークと同数のアイテム情報ワークを用意します。
これがあれば、下6ビットで同じアイテムを複数持っている時に、1つの格納エリアで31個まで持たせるといった事が出来ます。



�G所持品格納エリアからアイテム�ｂ�削除し、所持金を増やすルーチン。

コメントのPSは�B「POSSESSION SEARCH」、ISは「ITEM SEARCH」、KWは「KEY WAIT」です。

メッセージです。







次回は、「IN」を組んでいきます。

とにかく公私共々忙しいです…。

帰宅も遅いし、帰ってきてからプログラミングする意欲がわかないくらい疲れてる…。
そのため、なかなか「売り」側が完成しない。

久しぶりにがっつりロジック組んでるせいか、マシン語の暴走が多い…。
先日の上限オーバーにすぐ気づかなかったのも、普段から暴走させまくってたので、今回もそうだろうと考えてしまったのもあります。
暴走の理由の大半は、やはり「PUSH」と「POP」。
非常に便利な命令ですが、制約が厳しい。
制約を守らないと、すぐ暴走・リセットします。

主な制約は、
制約�@　PUSHで退避した分だけPOPで戻さなければいけない。
制約�A　PUSHした内容をCALL命令で飛んだ先でPOPしてはいけない。
まぁ、理屈が分かっていれば当然なんですけどね。

今回の「店屋」のように、条件が多く、ジャンプ命令を多用するロジックになると、どうしても飛んだ先で「POP」の回数が合わなくて暴走するという、今更な初心者的な事を繰り返しています…。

「技術資料」カテゴリに、「ハンドアセンブル方法」と「MSXメモリマップ」を追加しました。

上記に併せて、2023年6月1日記事「ハンドアセンブル」に、サンプルプログラム掲載。

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