openMSX 19.0 用 wxCatapult との違い

主なところは概要に記しましたが、今少しの補足をここで致します。

修正

• Windows でディスクやカートリッジのイメージファイルを指定するコンボボックスから Enter を入力すると有無を言わさず終了する(クラッシュ動作にすらならない)、という変なバグがあったのですが、コードの整理や wxWidgets の更新などでいつの間にか発生しなくなりました。
• wxCommandEvent 以外 のイベントを受け取るハンドラは (wxEvent::)Skip(); を呼び出さなければいけない、というのが原則です。守られていない部分を修正しました。
• イベントハンドラを定義するマクロそのものが間違っていて、信頼できない挙動を起こす部分がありました。
• 終了時に Visual Studio 2022 上で報告されていたメモリリークはおそらく全部修正しました。が、大量に出てくる wil::ResultException はどうしたらいいんでしょうね?
• メディア交換ボタンのポップアップメニューが変なところに出てくる不具合は修正しました。

起動補助

openMSX の半自動検索

openMSX の場所を指定するに当たり、ざっくりとではありますが場所の候補を探せるようになりました。

ポータブル動作対応

現状 Windows 限定かつ openMSX 20.0 時点での暫定仕様に対応という条件ですが、コマンドラインオプション /C<ファイル名.ini> と /A (--config <ファイル名.ini>, --adjecent) の併用により、szmCt と openMSX の設定をシステムファイルに依存しない任意の位置に保存できるようになりました。openMSX の設定は szmCt の設定ファイル(.ini) があるフォルダに置くようになります。

この動作は [Feature] Portability: change persistent data and savestates location [sf#224] #248 に記された環境変数 USER_PROFILE および OPENMSX_USER_DATA の指定によるものです。

呼び出し先の開発補助

openMSX をソースコードからビルドして、まだ make install されていない状態の実行ファイルが動かせるように、自動的に share ディレクトリを構成する内部動作を付けました。必要に応じてそのプロセス限定で環境変数 OPENMSX_SYSTEM_DATA も書き換えます。

macOS では make staticbindist でインストーラまでできてしまうため、この機能は未対応です。

操作一般

• GUI の大きな変更はないのですが、メニューはわかりにくかったので再構成しました。
• 一部に過ぎませんが、諸設定や映像設定で多くの連動項目を追加いたしました。
• 諸設定や映像設定にある初期化系のボタンは動作内容を変更しました。
• 諸設定
  • Caps lock キーとかなキーのエミュレーションボタンが付きました。これはキー入力の模倣でしかないので MSX 側が割込禁止などでキースキャンができない状態の時は反応しません。
  • 連射装置にもスライダーの横に数値入力欄が付きました。
• 映像設定
  • チェックを外すのが初期設定になるようチェックボックスの記載と動作を一部反転させました。
• 状態表示
  • 表示階級ごとの色設定ができるようになりました。
  • 任意時の全消しボタン・接続時消去メニュー・送信/受信内容の表示メニュー・追記の一時停止ボタンがつきました。
  • openMSX のコマンドを入力する欄がつきました。これは openMSX のコンソール入力に相当する機能です。
• 初回起動などで(任意で)行う模倣設定の全検査を高速化しました。CPUのコア数-1倍くらいになると思います。
  • さすがに openMSX 本体内蔵品の数倍程度は時間がかかります。
  • 動作環境によってはチェックしそこねたり妙なダイアログが出たりするようです。

IPSメニューの表面化

ROM や DISK に対するパッチメニューがあったので戻してみましたが、何か問題が出るかもしれません。

開発環境

• wxWidgets が CMake に対応しているため、本作もこれに合わせて CMake 前提の設計になりました。
• 従来の autoconf/automake による多環境構築っぽいものは configure スクリプトが存在しないなどよくわからない点があったので削除しました。
  • Windows と macOS 以外では CMake が Makefile を作る形になります。
• wxWidgets は 3.0 以降、非Unicodeビルドを非推奨にしています。szmCt でもあえて対応する理由がないので build 可能かどうかは見ていません。
• Windows における 32bit ビルドは現状可能なようですが、こちらも今日ではあまりやる意味がないので表向きには対応しません。
• catapult では libxml の古い方の SAX を使っており、最新版の libxml ではメモリリークの原因になっていたこと、改めて SAX2 側に対応するのも手間がかかりそうだったので自分で省力版 SAX パーサを自作しました。この結果 libxml を使わなくなりました。
• catapult では自前で .wxg ファイルを .xrc ファイルにして実行時に読み込ませる形を取っていましたが、szmCt では実行可能ファイルに含まれるようになりました。またリポジトリは .wxg と .xrc の両方を管理しています。.wxg ファイルを wxGrade で編集し、そちらで .xrc ファイルも出力する運用を前提としています。

openMSX 本体との通信に関して

openMSX catapult 19.0 では二つの目的で wxThread を使っていました。szmCt でも途中までは std::thread に移行しつつこれを継承・改善していました。

ところが wxExecute や wxProcess などを使えば wxWidgets 側がだいたいのことを行ってくれるようで、模倣設定の全検査では高速化した上で記述量を減らしています。

他方、通常起動時における通信ではこの手法は使えませんでした。openMSX 本体からの受信は wxTimer でしか監視する方法がなかったからです。これでは余計な負荷が掛かるか、szmCt の応答が不自然に遅くなるかの二択になってしまいます。そこでこちらは catapult と同じ方法を改良の上で使い続けています。

ただしおそらくすべての Linux で非ASCII文字の環境変数に対して正しく動作しないことがわかりました。このため wxExecute を使う場合でも少々回りくどいことをしています。これはポータブル起動やopenMSX開発フォルダを対象とする場合に意味を持ちます。