HSPを少しずつ進める。

何事も放置すると、忘れたり、鈍ったりするわけで。
少しずつでもHSPのプロジェクトを完成に近づけなければ。

そもそも、何を作るかすら決まっていないけどな！

さて、今日の目標は、１０年前には無かった（はず）module機能についてだ。
追記：過去のソースコードに、#module が記述されていた。ただ、それだけで、modfuncなどは使ってなかった模様。

とりあえず、インスタンスを作り、モジュール関数をコールし、
いわゆる、セッターやゲッターの動作も確認できた。

一通りやった(つもり）なので、早速実践。
ゲームには必須である、画面のフェードイン/アウトアウト機能をmoduleで作ってみる。

基本は、過去に deffunc で作ったものをコピペ…する予定だったが、
目に余るコードだったため（笑）、１から作り直す。

とはいえ、ゲームプログラマなら、
簡単なフェードシステムのコード書くのに30分も掛からないはずだ。

というわけで、出来たものを実行っと。

　う　ご　か　な　い　！

いや、そんなはずは。
ちまちまとミスはあったが、そんなレベルではない、何かが違う。

試しに module外のメインループに移すと、きちんとフェードしている。
ということは、moduleが独立空間であるがゆえに、何かしらの障害が発生しているということだ。

さて、なんだろうか？
もしかして、module内では、gsel や gcopy などが使えない？
ありえそうだが、マニュアルには、そういうことは、一切書いてない。
さらに、付属のサンプルでは、思いっきり、moduleの中で、gcopyしてる。

まったくわからん！

が、独立空間という観点で見たときの問題が、もう１つあるじゃないか！

ゲーム作りの鉄則として、後から変更がありそうな部分は、define で一括で変更できるようにする。
Windowsのゲームだと、画面サイズなどが真っ先に定義される。
今回も、
#define screenW = 1280
#define screenH = 720
と定義している。
が、定義している箇所は、当然、#globalだ。

module内の gcopyは、

gcopy 1,0,0,screenW,screenH
になっている。

全くエラーは出てないが、これが悪いんじゃね？
というわけで、変更。

gcopy 1,0,0,screenW@,screenH@

ビンゴ！うまく表示されたわ。
うーむ、module内で全く定義せずに使用している変数は、
エラーを出さず、0として使われてるようだな。

マニュアルでは、module内から globalを参照するのは推奨しないとされている。
スクリーンのサイズを取得する変数や関数があるだろうか？

…あった。

画面の描画エリアXサイズ
ginfo_winx
画面の描画エリアYサイズ
ginfo_winy

定数をこちらに置き換えて、動作することを確認。
ま、なければ、セッターで画面サイズ渡せば良いだけか。

こういうのが、やってて面白いところだな。

追記：
#define の後に、global をつけることで、全module対象になるんだと！

#define global screenW 1280

これが正解の書き方ということだな。

再びHSPを始めたんだが。

過去に、HSPを使って商品を２つ作ってリリースしたことがある。
2006年頃、もう１０年以上前だから、HSP1.0だろうか？
もっともメインじゃなくて付録的な位置づけの作品だったが。

一応そのソースを持ってきたが、現在の HSP3.5では、互換性が無かった。
当たり前だが。

まあ、色々便利になっているし、サンプルやドキュメントが格段に整備されているので、過去に触れていたということもあるが、１０分程度で画面は表示できた。

module 辺りを中心にいじってみる。
うまく使えば、オブジェクトっぽいものが表現できると思われるが…。

module内に作成した関数、modfunc にアクセスする方法が
module関連のドキュメントで全く触れられてないのが残念すぎる。

モジュール変数とかコンストラクタとか、
だいたい一定のルールの記述方法なのだが、なぜモジュール関数(modfunc)だけ、

val = funcname(modVal)

という方式にしたんだ…。
ルールに従ったら、

val = funcname@modVal
val = funcname modVal

辺りが妥当なところじゃないか？
せっかく module関連をまとめたドキュメントが用意されてるのに、
これ説明しないでどうするよ…。

結局、moduleのサンプルコード見て探し出したが、
初見殺し過ぎる…。