2006/02/13(月)HSPを使う理由

はてブ数 2006/02/13 08:29 プログラミング::HSP3つーさ

自分がHSPを使う理由ってなんだろうなぁと。
デジリナを作りながら思ったことを書いていたのですが、
今は公開する意味がない気がしています。読みたい人のみ続きをどうぞ。

自分の中で、「HSPを使うことで得られるメリット」が薄れてきているというか……。
ゲーム作りを目的とするならいい気がしますが、
どうも自分が作るようなツール系アプリには不向きかなぁ、なんて思ってたのです。

wait命令とメインループ

デジリナではwaitやawaitは一切使っていません。

HSPには時間待ち命令である wait があります。
アイドル時には、「*メインループ」とかそういうラベルを作って、
waitをサンドイッチの具にグルグル回すのが(HSPユーザの中では)一般的であり、
wait命令を作った作者の用途もそんなところでしょう。

しがない1つのアプリが、アイドル時間中に何かを監視するループを回したところで、
システムにはほとんど影響がないでしょうが……
自分にはそれは「気持ち悪い」と感じられてしまうのです。
Cを使ったことがなければ疑問にも思わなかったのでしょうが。。

メインループという考え方が嫌です。
アイドル時間にwait命令でダラダラループを回すのがどうも気持ち悪くて嫌です。
何かに対応する必要があるのなら、しかるべきメッセージに対応する方向で組みます。

……現実を見ろと言われそうです。

やっぱりAPIが呼びにくい

結局細かいことやるならAPIを自分で呼ぶことになるわけです。

プロトタイプをいちいち宣言しなくちゃならんのが面倒くさいです。
だからと言って、あらかじめ全部定義したヘッダを取り込むと、
使ってない関数までリンクしてEXEが太ります。
HSPではDLLはすべて「明示的リンク」です。
なので、関数ごとにそれを読むコードがだらだらと増えてしまうのです。
速度に関してどうこう思いませんが、あからさまに無駄で気持ち悪いです。

……やっぱり現実を見ろと言われそうです。

動作が遅い

やっぱちょっと遅いかな。

どうしても速度が要るときはマシン語組むですね。
デジリナでは UTF8 <-> Shift-JIS モジュールを作りました。
マシン語でやろうかどうか迷いましたが、結局どろどろdefineスクリにしました。
その際deffuncはオーバーヘッドがキツいのでナシです。
まぁ、動作速度と安全性はトレードオフなので仕方ないですかね。

メリットについても考えてみる。

勝手に窓を作ってくれる。
ウィンドウクラスを登録する必要も各種ハンドルを管理する必要もありません。

変数に関してもメモリの管理が比較的楽。
何でも格納できたり(型変換が容易)、配列が自動的に拡張されたり。
ただ、全部グローバルスコープなのが頭痛い……
# globalなdeffuncで対応できないこともないけど。

画面描画も比較的楽。
オフスクリーンバッファが簡単に作れて、
そこに描いておけば勝手に更新してくれます。

文字列処理も割と楽。
処理用のバッファを自分で確保する必要がないとこがイイっちゃいい。

プラグインで機能拡張できますが、
できたら、プラグインは使いたくないです。

自分がプラグインを使いたくないわけ

これはあくまで個人的な事由なのですが。

「たった数KBのDLLファイルが増える」のも、なんか嫌なのかも知れませんが、
多くの場合、そのプラグインが行き届いてない場合に弄れないからです。
先日hspinetのFTPをパッシブモードにできねーかという質問がラウンジでありました。
できません。できないからプラグインはダメなんです。
たとえば、MIDI再生プラグインがあっても、
MIDIOUTデバイスのハンドルが取得できて、自分でグリグリできにゃダメなんです。
HSPを拡張するためのプラグインが拡張性に乏しいというパラドクス。

だから、例え動作が遅くても、自分で弄れるソースとして提供されるモジュールが好きです。
タイムクリティカルな仕事はモジュールにマシン語を組み込みます。
全体的に見たとき、DLLに分離する意図がよくわからなくなってしまうのです。
人が作ったモノと自分が作ったモノを混同するのがよくないんでしょうか。

ゲームでのデータファイルのあり方

少し話がスレますが。

逆に、「データ」をなんでもかんでもEXEにパックするのもあまり気が進みません。
10MBのEXEより 100KBのEXE + 9.9MBのデータアーカイブ……
……やっぱりこれも微妙ですね。
データファイルも、pic.pak bgm.pak、なんて分けましょうか。
んで、ヘッダに「オフセット」「サイズ」「ファイル名」だけ書いて、
だーっとファイルを連結するだけにしときましょうか。

「そんなんじゃ簡単にリソースを取り出されてしまうではないか」
と思われるかもしれませんが、私はそれでいい、むしろその方がいいと思います。

絵もシナリオも書けない自分が言うのも難ですが、
リソースを暗号化して保護することで「得られるメリット」が思いつかないのです。
というのは、たとえばゲーム音楽を創作のBGMにしたいなんてことよくあると思います。
リソースが簡単に取り出せたら、そういうことも簡単にしてもらえるのです。
だからといってpakしないのはだらしがなく見えるので……
そう、建前的にpakしておくのがいいなぁと思います。

その方がユーザさんにはより楽しんでもらえると思うのです。
BGMを聴いてもらえた方がいいじゃないですか？
作中の一枚絵を壁紙にして眺めてもらえた方がいいじゃないですか？
ただしお金の話が絡む場合は必ずしもこれが当てはまるとは限らないと思います。
ユーザさんの良識に任せられるとき、のみですけど。

あぁ、そうか。

なんで、自分が「HSPってどうもなぁ……」と思ってるのか。

プラグイン使いたくないわけを書いてて気づきました。
確かに表面的にはイロイロ楽ちんなHSPですが、
ちょっと深いところに入ろうと思ったときに遠回りになるんですよ。
Win32APIで使われる大きめの構造体のポインタがlparamで飛んできたときなど、
序数を調べるのに必死です。これが非生産的でとてもしんどいです。
たぶん、そんなことやってる自分に厭気がさしたのかなと。

その点ヘッダファイルが用意されてるCは楽だな、と。

いあ、こんなことダラダラ書いたところで、
やっぱり何にもならないと思うんですけどね。
次のプログラムもHSPで書き始めたらHSPで書いちゃうだろうので。

デジリナに限った話でいえば、
ツールというよりモジュールを作ってみたかったので、これはこれでいいんですが、
それのサンプル用にフロントエンドを書いたら、これがなかなか上手くできていたので。。

かゆいとこには手が届かなくても、
メモリアクセスはお世辞にも速いとは言えないけれど、
文字列処理、描画処理の手軽さのメリットは、結構大きいかなぁ。
結論としては、HSPでツールもイイかもしれませんね。

ただメインループが必要なプログラミングスタイルは断固反対ですω

コメント（2件）