149.HSPでゲームを作ろう：培養臼（BAIOUS） その26

ラストはおまけ。
↓のエントリーで書いた、ポーズ機能を作り直した話を少々。
coro3.hatenablog.jp

この時の実現方法は、ポーズキーを押したら、gosubでポーズルーチンに飛ばし、無限ループにして、次にポーズキーが押されるまで、元の処理にreturnしないというものだった。
いろいろと情報を見てると、この方法は一部ヤバかった。
無限ループにしたときは、await命令を入れてないとだめというルールがあったのだ。

ただし、そのために1つだけHSPのスクリプトを作る上で約束事があります。 HSPでは「キーを押さないと進まないなどの無限にループになる可能性のある部分では、 必ずwaitかawait命令を入れる必要がある」という約束事を覚えておいてください。

HSP3プログラミングマニュアルより

で、いくらポーズ機能を告知していなくても、このままヤバいものを公開しておくのも嫌なので、ポーズ機能を作り直すことにした。
今のルーチンへ単純にawait 5とかを入れるだけでも良かったが、この方法だと、redrawができないので、新たに何か表示を付け加えられない。
そこでもう少しいろいろ調べたら、スプライトの描画を行うes_drawには、処理を保留するフラグの引数があった。

値     マクロ名          内容
―――――――――――――――――――――――――――――
  0  ESDRAW_NORMAL        すべての処理を実行する
  1  ESDRAW_NOMOVE        移動処理を保留する
  2  ESDRAW_NOANIM        アニメーションを保留する
  4  ESDRAW_NOCALLBACK    コールバックルーチンを保留する
  8  ESDRAW_NODISP        表示を保留する
 16  ESDRAW_NOSORT        ソートを保留する

es_drawのヘルプより

複数の処理を保留したければ、HSP3ではお約束の通り、足した数を指定すればよい。
今回、ポーズ機能で使用したのは、1の移動処理保留と、2のアニメーションの保留。
なので、引数には3を指定すれば、その間、スプライトは表示されるけど、es_adirの自動移動は停止するし、もともとアニメパターンで定義していたスプライトは、アニメーションを停止できた。

こんな感じ。

es_draw ,,(pauseflg=1)*3,0,10000 ;スプライト描画

ポーズボタンを押したら、pauseflgを1にする。1になっていれば、論理式が成立して3を、通常の状態なら0を処理保留フラグとして指定する。
あとはポーズ中に移動を受け付けないようにしたり、ゲーム内カウンタがintの最大値を超えないように、カウンタリセットの処理を加えた。
何より、redraw 0～redraw 1の処理を行うので、ポーズ中は、画面内に「PAUSE」の文字を点滅表示できるようになったので、わかりやすくなった。

培養臼の作成に関するエントリーは、いったんこれで終了。
次からは、次作に向けての準備などについて書いて行こうと思う。

148.HSPでゲームを作ろう：培養臼（BAIOUS） その25

前回の続き。
ということで、自ウィンドウがアクティブじゃないときにキースキャンをしないフラグ設定すれば終わりじゃん！と思ったら、getkeyにそんなフラグはないのね…（できるなら誰か教えて偉い人w）

幸い、アクティブなウィンドウIDを取得することができ、HSP以外のウィンドウがアクティブ=自ウィンドウが非アクティブかは、-1が返ってくるか否かで判定できることがわかった。なので、アクティブウィンドウIDを調べて、0以上のときだけJStick命令を実行すればよさげ。
いちいちアクティブウィンドウIDを調べるコードを書かなきゃだめかと思って調べると、「hspdef.as」をインクルードしておけば、ginfo_actと書けば、現在のウィンドウIDが分かるらしい。便利。

ということで、培養臼のソースに組み込み始めたのだが、ふとこの処理をこれから先作るプログラムにもやらなきゃダメなのかと思った。正直避けたい。
「PAD設定さん」は、幸いソースも公開されている。そこで、JStick命令内で使用しているgetkeyを、非アクティブウィンドウ時は取得しないように処理を加えることにした。

これで、非アクティブウィンドウ時は、キー操作を受け付けなくできた。
と、安心していたら、ジョイスティック操作はまだ受け付ける…
どうやら、ジョイスティックの操作を取得する処理部分も、ウィンドウのアクティブ状態に関わらずすべて受け付けるらしい。

ということで潔くJStick命令の冒頭で、非アクティブウィンドウならそのままreturnするようにした。
培養臼で試す限りは、問題なさそうなので、これで対処を終了した。
新しいPCとかに移行したり、バージョンアップしたときは注意が必要だな。

147.HSPでゲームを作ろう：培養臼（BAIOUS） その24

コンティニューとステージ練習機能を追加したところで、コンテストは締切になった。
今年は複数の方からの評価とコメントをいただけた。ありがたい。

基本的に遊んだ感想や、改善点についてだったのだが、気になったのが、非アクティブウィンドウ時にもキー操作を受け付けるというもの。ツイートもしてたやつ。

コメントで指摘のあった、非アクティブウィンドウでもキー操作を受け付ける問題。気になってたんだけど、そんな風に設定した覚えがなかった。#HSP3 #培養臼

— CORO3 (@Coro3_Coro3) 2022年11月9日

原因は、getkey命令だった。
こいつが非アクティブウィンドウ時でも、キー入力を受け付けてしまっていた。今まで作っていたゲームウォッチ再現シリーズでも、Windows対応するときにgetkeyを使っていたので、見事に該当。
こっちはandroidでのタッチ操作がメインで作っていたので、まったく気にしていなかった。

培養臼はWindowsで遊ぶので、非アクティブウィンドウ時はキー入力を受け付けないようにしたかった。
でも、getkeyは基本的に使ってないのよね。キー入力を行っているのはstick命令だったはず。そして、stick命令で非アクティブウィンドウ時にも入力を受け付けるには、明示的に引数で書かなきゃならなかった。そんなの書いたことないしｗ。ここで「PAD設定さん」のJStick命令を使っているのを思い出した。
JStickをStickに書き換えたら、非アクティブウィンドウ時のキー操作は受け付けてなかった。

じゃあ、Stick命令に戻せばと思われたかもしれないが、それだとせっかくのジョイスティック対応ができないし、キーコンフィグも追加したいので、このまま使いたい。
さて、どうしようか。

さらばATOK

昔のパソコンは、日本語の入力をするのがすごく面倒だった。
今みたいに文章で入力するのではなく、漢字変換は一文字ずつの単漢字変換だった。
ワープロソフトを購入すれば、連文節変換という今の変換方式に近いものになったが、普段のプログラミングで日本語入力は至極面倒だった。

そんな時に出会ったのが、日本語入力ソフト「ATOK」。ジャストシステムという会社のワープロソフト「一太郎」に付属していたものを、単独で買えるようになった。こいつが当時の日本語入力の環境を一気に改善してくれた。
PC-9801で、2ドライブのFDDがあれば、1枚目にMS-DOSとATOK、2枚目に辞書ディスクをセットすれば、（当時の感覚で）自由に日本語入力ができた！

就職してからは、PC-9801ではなく、Macを使うことになった。MacOSの日本語入力は「ことえり」というシステム。ATOKには遠く及ばない変換効率にイライラしていた。MacOS版のATOKが登場したときは飛びついた。

Windowsになっても標準のMS-IMEがあまりよくなく、ATOKを購入して使っていた。
さらに、Android版が登場した時も、ベータ版から使ってきた。

そんなATOK信者な私だったが、MS-IMEの性能もよくなってきたので、Window版の購入コストが高くなるということで、使用をやめた。（日本語キー入力の設定だけは、ATOKにしている）
Andorid版は、ずっと使ってきたが、最近変換効率が極端に落ちた。サブスクリプション版しか更新されないことになったのだ。
地名とか名前変換にも強かったはずなのに、ことごとく変換できず、これだけなら我慢できるものの、ATOKの特長だった、文脈解析による変換がほぼ機能しなくなった。

Googleの「Gboard」は癖があるものの、変換自体はATOKよりマシだったので、乗り換えることにした。
こうして、30年近く使ってきたソフトと、お別れすることになった。
これだけ長い間付き合ってきたソフトだっただけに、最後は残念な別れ方ではあるのだが、今までありがとうと言いたい。