HSPTV!掲示板

＜まえおき＞

・プログラムは自由。好きなように書けばよくて「正解」というのは無い。
・たくさんのサンプルスクリプトを書くのはたいへんなので使いまわしするのは普通。
　なので、サンプルは必ずしも最良の書き方で最適化されていない。
・書く目的によって、対象読者にあわせて、同じ動作のスクリプトでも書き方、レベル難度が変わる。

といったことがわかった上で、それでも
「良いお手本となるサンプル・スクリプトを書きたい」
と思ったときにどうするべきか、を現在思案中、調査中です。

そこで疑問があります。
HSP3Dishのいちばんさいしょのプログラムで習うのが

*main
	redraw 0
	mes "こんにちは"
	redraw 1
	await 1000/30
	goto *main

このループ構造で、HSP3Dishのプログラムはこれを基本にして開発していきましょう、
という話になっている（公式書籍など）のですが、

【疑問】
「画面内容が常に変化しないゲーム（アクションゲームや3D以外）でも
必ずループをまわしつづけるプログラム構成にしないといけないのかどうか？」
「画面が変化する必要があるときだけ、
redraw 0 と 描画と redraw 1 を含むサブルーチンを一度よべばよいのではないか？」

	redraw 0
	mes "こんにちは"
	redraw 1

のみ実行。

タッチ検知などを取得するメインループはまわしつづける必要があっても、
描画は変化しないなら処理に含めなくてよい気がしますがどうなのか。

なぜ疑問に思うかというと、ほとんどの公式サンプルでも、公式な解説でも、
ループ構造を前提としているため。
（実際にループ構造なし、のスクリプトを書いても問題なく動作しているように見える。
自分の知らない理由がなにかあるのかなと思ってしまう。）


私は現在、HSP3Dish.js（Webアプリ）のサンプルスクリプトを作成しています。
これまではとりあえず雑なモノを書いていましたが、
すこし最新の状況を勉強して、お手本として良質なより丁寧なスクリプトを書きたいと考えています。


現状のHSP公式のやりかたに異論があるわけでなく、
じぶんの理解が正しいのか（ひとに教える記事を書くまえに確認したい）、
じぶんがなにか大きな勘違いをしていないか確かめたいので、
掲示板でご意見を募りたいと思いました。

できたら「はっきりとこうだ」「こういう理由があってメインループ回しつづける構成が基本になっている」
と言える詳しい方やHSP上級者のアドバイスをいただけたらうれしいです。

よろしくお願いいたします。

　他は知りませんがWindowsの場合、ループさせないと最小化してから元に戻すと画面が真っ白になってしまいます。

https://twitter.com/mellkuch/status/1502591060954214400

画面は更新し続けなくてもいいです。負荷軽減にもなると思うので。
例えば私が公開している「いろぷち」なんかはユーザーがタッチしなければ
ほとんど画面変化しないので、変化がないときは画面更新はしていません。

ただし問題がひとつあって、Androidのタスク停止（■ボタン）で引っ込めて
戻した場合に更新しないと画面が真っ黒になってしまいます。
なので、タイマーで監視して一定時間以上停止していたら
タスク停止してから復帰したものとみなして画面の更新を行います。

	// 125ms以上の遅れを感知したら、一時停止からの復帰と判断して再描画

	getreq p,SYSREQ_TIMER		// 判定用にタイマー取得
	if time+125<p { draw=1 }	// 復帰なら描画
	time=p						// 次回判定用に保存

上記は「いろぷち」の判定部分で draw=1 で更新が入るようになっています。
つまり draw=0 であれば画面更新をスキップするように書いてあります。

この対策さえ入れれば、常に redraw 0 〜 redraw 1 を回す必要はありません。

> メルクーフ さん

教えてくれてありがとうございます。まだ最小化のことまで考えていませんでしたので参考になりました。
いま作成したサンプルスクリプトに対処方法をつけてみました。

> 窓月らら さん

教えてくれてありがとうございます。実際アプリ開発されてる方がそう言い切ってくれると説得力があり、
とても参考になります。
Androidの情報と、タイマー監視の具体的な方法も、このスレッドの閲覧者にも参考になるありがたいサンプルです。


自分で単体でうごくサンプルを書いてみました。
私の言いたいことは、こういう構成で Dish プログラムを「お手本となるサンプルスクリプト」
として書いていっても大丈夫かということです。（入門者、初学者の迷惑にならないか。）

公式の解説や おにたま さん が常に「描画も含めたメインループ構造」でサンプルスクリプトを提示するのは、
学習しやすいようにそうしているのか、
それともまだなにか理由（特定の端末や環境で問題がでたりするのか）もうすこし調べたいと思っています。

なにか情報をお持ちの方や、以前どこかでこういう議論があったURLを知ってる方がいたら、書き込みをお願いいたします。

//【描画をメインループ内で行わないサンプルスクリプト】

#include "hsp3dish.as"

//↓起動時に１回だけ実行される処理

	sdim aisatu,100,5			//あいさつ配列
	aisatu(0) = "はじめまして"
	aisatu(1) = "おはようございます"
	aisatu(2) = "こんにちは"
	aisatu(3) = "こんばんは"
	aisatu(4) = "おやすみなさい"

	ainum = 0		//現在のあいさつ番号
	bak_ainum = 0	//あいさつ番号を記憶しておく用

	moto_window_w = ginfo(10)			//起動時のウインドウwサイズ保持
	now_window_w = ginfo(10)			//現在のウインドウwサイズ保持
	title "windowサイズ "+ now_window_w

	gosub *put_now_mes	//さいしょのあいさつを表示する

//↓このままメインループ処理へすすむ
//=========================
//メインループ（なにもしない状態では描画処理はループ内で実行されていない）
*mainloop

	stick key
	if key&256 : goto *touch	//入力チェック

	//ウインドウが最小化されたときの「あいさつ番号」を記憶しておく
	if ginfo(10) < moto_window_w {
		now_window_w = ginfo(10)
		bak_ainum = ainum			//あいさつ番号を記憶しておく
	}

	//ウインドウがもとに戻ったとき、画面が白くならないように一度描画処理を実行
	if ginfo(10) > now_window_w {
		ainum = bak_ainum			//あいさつ番号を記憶しておく
		now_window_w = ginfo(10)
		gosub *put_now_mes	//現在のメッセージを表示
	}

	await 1000/30
	goto *mainloop		//メインループトップに戻る
stop
//=========================
//入力判定
*touch
	gosub *put_next_mes		//次のメッセージを表示
	goto *mainloop
stop
//=========================
//現在のメッセージを表示
*put_now_mes
	gosub *put_draw
return
//=========================
//次のメッセージを表示
*put_next_mes
	ainum++						//あいさつ番号をすすめる
	if ainum > 4 : ainum = 0	//さいごのあいさつなら最初にもどす
	gosub *put_draw
return
//=========================
//メッセージを描画
*put_draw
	redraw 0
	pos 10,100 : mes aisatu(ainum)
	redraw 1
return
//=========================

//  スクリプト内にある stop 命令は 慣習として書いてあるが意味はないので削除してもよい。
//　たぶん今後は削除する作法のほうが良いのかも？

急いで書いたので、あとで間違えに気づいたら、修正したものを
https://junji.jp/net/hsp3/
こちらにあげておきます

Webアプリ化したモノ

http://www.junjisuzuki.jp/test/mainloop_without_draw.html

あめふりてるさんの入力待ちの種類や画面毎に関数作って条件満たすまで関数内でループする
設計が作りやすそうでかっこいいんですが、WindowsとLinux以外の環境で関数内waitが出来ないのが辛い。

https://github.com/AmefuriTell/amayadori/blob/a5ff39165aac7b11b731e3dd37e5da49ecab1ab9/reversi/Reversi.hsp

> zakki さん　

教えてくれてありがとうございます。

古くは 行番号記述のN88-BASIC から 最近のオブジェクト指向言語まで、
その中間ともいえる HSP の記述に対する感じ方はほんとに人それぞれで、
ユーザーの年代によってもだいぶ異なりますよね。

私も repeat でメインループをまわすサンプルをいくつか書いて出していますが、
HSPの「ラベル」は結構特徴となる部分で、スクリプトエディタで一覧もでるので、
一目でメインとわかるラベル名gotoでメインループを書くのがよさそうな気もしています。

（変数に「ラベル型」があるのを忘れてる人も多いかも。）


個人的にはHSPのモジュールを理解してうまく使えるようになったら
HSP中級者だと思います。
同時にHSPを卒業してモダンなオブジェクト指向言語へ興味をすすめる頃合かなという気もします。

参考【公式：HSP3 モジュール機能ガイド】
https://www.onionsoft.net/hsp/v37/doclib/module.htm


HSPの大きな魅力が「かんたん」「わかりやすい」
だと思っているので、システム上必要な処理だけどユーザーが直感的に理解しにくい違和感のでる部分は
隠蔽されるのがよいような気もしています。

> きせん さん

非常に参考になるご意見の書き込み、ありがとうございました。

この掲示板にスレッドを立てたのは、自分の感覚と異なる広い意見をきいてみたかったためであり、
こういうご意見は、自分のアタマのなかをもう一度見直すためのとてもよい材料になります。

私自身、なにか書式に決まりごとや定石があったときは、「まあ、とりあえず、それでやっておこう」
でやって、うごくものを作る、こだわらないやりかたを採用するほうですが、

今回こだわって再確認、意見募集して検討してみたかった理由は、

プログラミングを「教育」という視点でかんがえたとき、

・「論理性や合理性を、自分の頭で考えるちからを育む、のばす」
・「どうして、なぜ、そうなっているんだろう？ と疑問に感じた違和感をだいじにする」

という部分をたいせつにしたほうがよい気がしたからです。
（おとなが小中学生に向けてプログラミング講座みたいなことをするときに、
それに対するこたえを持っていたほうがよいと感じた。）

そのときに、子供たちが一番さいしょに違和感をかんじる可能性がありそうな、
「ループ構造のなかでおなじ命令を繰り返さなけばいけない合理的な理由はあるの？」
という問いについて、HSP3Dish仕様の基本を確認したかった次第です。

私は、アプリ作り、ゲーム作りには、枠にはめられる「ツクール」ではなくて、
フリーハンドで発想ができる「HSP」はとてもよいものだと考えています。
それはきっと子供たちのアタマの発想力を「制限なく」ひろげたり、のばしてあげることができる
夢のある道具になる気がしているからです。

追記：
このスレッドの最初で「詳しい人」「上級者」とか書いてしまいましたが、よくなかったと反省してます。

だれでも、この話題に興味のあるかたは、気軽にご意見書き込んでもらったらうれしいです。

（※解決済みにせず、もうしばらく置いとかせてください。）

>用賀じゅんちゃんおじさん

すみません。あとでやはり伝えべきではないかなあ。
と思って消してしまいました。

よいお手本となる書き方は、誰にでも解りやすい書き方であると思います。
難しい記述をして描画の回数を減らすならば、負荷のすくないwaitで
すくない回数の描画をくりかえしたほうが解りやすいのではないか。
と、いう意見です。

すみません

なぜループにするか、というのもどういう結果になるか。というのもやってみることで経験するのもよいことだと思います。
私も一番最初にボタンを同じ場所にたくさん配置しましたから(笑)

> きせん さん

ありがとうございます。

どういう書き方が簡単でわかりやすい（＝混乱をまねかない）か
まだ自分でも確信をもてないで、思案中であります。

そこにさらに redraw と wait が隠蔽された
『珠音（たまね）ドットフレームワーク(β)』
が登場しましたので、
これもさわってみて、もうちょっと考えてみたいと思っています。

http://hsp.tv/make/tamane_dfw.html

（↑これは常に画面内画像がうごきつづける=描画更新が必要なゲーム用）


> ボタンを同じ場所にたくさん配置

そうなんですよね。初めての人には「HSPのオブジェクト（この呼称も人によっては混乱する）」が
描画画像や文字とは別レイヤ（「ウインドウ」や「UIView」みたいなもの）だと、
自分で実際やってみないとうまくわからないですよね。一度わかれば簡単なんだけど。


私もあんまり「議論のための議論」になりそうな話はしたくないと思うほうですが、
まあ、時には、ほかのひとの意見もきいてみたい気分になりました。
（しかし、丁寧に話そうとするとどうしても長文になって、
「あ、なんかめんどくさそうなひとかも」とか思われがちですよね。。）

ご意見ありがとうございました。一旦、解決とさせて頂きます。