HSPTV!掲示板

立てましたー！
表題のとおり、HSP3Dishについての情報を黙々と書いていくスレです。関係ありそうな内容なら何でもどうぞ。

不具合や要望等は、下記スレへのフィードバックも合わせてお願いいたします。
https://hsp.tv/play/pforum.php?mode=all&num=94865

とりあえず上記スレでも書いたのですが、Android10以降において、ダイアログボタンのスタイルがおかしくなるケースがあります。一旦はビルドの問題だと判断したのですが、再び発生する場合がある様子でした。
アプリを切り替えるとスタイルは正常になるみたいです。なのでスタイル指定にコケる場合がある、という印象です。
Yes/Noについては今のところは問題なく、OKだけです。なので思いきってOKボタンを消すことで回避は可能です。
引き続き検証してみます。

報告時は、動作環境についても、詳細に
書いてもらった方が、良いと思います。
(※通常のWindows版でも同じですが。)

最近、mes 命令で、Win版Dishのみ発現。
描画フォント関係からか、実機Android端末上
では、動作に問題なし...と言うケースも
ありましたので。

Yes/Noボタンも同じだー。なんだろー？
Android 12ね。
しかし、リリース済のCoinFZでは起きない、何故だ！
同じ環境でビルドしてるんですがね。
というわけで、検証中です。
HSP3.6正式版、dh1.77

上記問題は一旦諦めてOKボタン非表示に改造して対応します。

前々からあるのですが、HSP3Dish Android版において mmload命令でのwav読み込みに失敗する？ことが希にあるようです。
エラーにはならず、音が鳴らないことで気づきます。アプリを再起動すれば直りますが、再現性はなくランダムです。

mes命令によるテキスト描画の不具合。
Androidの特定の端末(手持ちでは TM75A FireHD等)にて文字列が白く塗りつぶされてしまう事があります。再現性はランダムで、印象からはキャッシュの段階で描画に失敗してる感じです。gcopy等でも似た不具合が過去にありました。

初期のHSP3Dishからあった問題で、HSP3.6b2で(恐らくたまたま)改善していたのが、3.6b3で再び悪化したというものです。3.6b3でmesの最適化が行われたので、それが原因かもしれません。
なので、うちのところでは3.6b2で止めざるをえないアプリがいくつかあります。mesを利用していないアプリだけ最新を適用です。

これについては何回かおにたまさんにも報告してるのですが、再現する端末をお持ちでないとのことで改善されない問題です。原因がこちらでわかれば報告いたします。

AdMobによる収益化について。
いい時代になりました、昔だったらシェアウェアにするくらいしかありませんでした。しかもあれはそう簡単には支払ってくれませんw それでも数名は買ってくれましたが…

過去ログを読み直したところ、住所の公開がネックになりAdMobを諦めてる方がいました。これはPlayストアのデベロッパーの所在地のことでしょうが、番地まで書かずとも大丈夫です。市まででいいです、、私はこれで何も言われませんし、収益の振込もきています。

ユーザーは無料でアプリを使え、デベロッパーはモチベーションの維持や開発PCの費用程度にはなるので、とても良い仕組みだと思います。
・・・億円だって目指せますよ？♪

実装ルールだけ厳守しましょう。
アプリのコンテンツに重なっていないか、ユーザーの誤操作を期待したような配置になってないか等です。万一Googleから警告がきたら修正対応すればいいだけです。私もコンテンツに重なってるで2回ほど対応しています(リリース時点ではルールに明記されてなかった項目)。なので、HSP公式の対応を待ってる暇はないので、広告表示の調整程度は理解しておく必要はあります。

ついでなので、マニュアルに載ってないtipsっぽいものもいろいろ勝手に書いていきます。自分のサイトでやってもきっと誰も見ないんで。

超基礎的なこれ。かならずループのどこかに置くこれです。

await 16	// だいたい60FPS

とか

c++
await 17-(c\3=0)	// 60FPS

Windowsの場合はawaitのタイマーが正確なのが大前提ですが await 17-(c\3=0) とすることで計算上は正確に60FPSにできます。
ですが、Androidの場合は await 16 で問題ないです。同期とってくれるんで。もちろん上記のやつでも結果は同じですが、特にやる意味はなかったです。

AndroidManifest.xml について。
マニュアルに詳細は書いてないような気がしますが、HSP3Dish Android版でアプリをリリースする際には必ず編集が必要です。必須ですがあまりちゃんと書いてないので、HSP以外のサイトなどを検索して参考にします。

例として、私の「いろぷち」の AndroidManifest.xml を晒します。

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.miecat.iroputi.free"
      android:versionCode="9"
      android:versionName="3.1.0">
    <uses-sdk android:minSdkVersion="14"
              android:targetSdkVersion="31" />
    <supports-screens android:smallScreens="true"  
                      android:normalScreens="true"  
                      android:largeScreens="true"  
                      android:xlargeScreens="true"
                      android:anyDensity="true" />
    <application android:label="@string/app_name" android:icon="@drawable/ic_launcher">
        <uses-library android:name="org.apache.http.legacy" android:required="false"/>
        <meta-data android:name="com.google.android.gms.version"
            android:value="@integer/google_play_services_version"/>
        <activity android:name="com.google.android.gms.ads.AdActivity"
            android:theme="@android:style/Theme.Translucent"
            android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize"/>
        <activity android:name="tv.hsp.HspActivity"
                  android:exported="true"
                  android:screenOrientation="portrait"
                  android:theme="@android:style/Theme.Black.NoTitleBar.Fullscreen"
                  android:label="@string/app_name">
            <meta-data android:name="android.app.lib_name"
                    android:value="iroputi_free" />
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
	<uses-feature android:name="android.hardware.vibrate" android:required="false" />
	<uses-permission android:name="android.permission.VIBRATE"/>
	<uses-permission android:name="android.permission.INTERNET"/>
	<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
</manifest>

標準状態と違うところを比較してみてください。


package="xxx"

パッケージ名（内部名）です。dhで設定している項目です。
絶対に世に出ている他のアプリと重ならない名前にする必要があります。またアプリを更新し続ける限り変更できない部分なので最初によく考えて決めます。
いちおうルールとして、自分のサイト（ドメイン）から名前をつけることが推奨されています。例えば私ならば miecat.com というドメインを持っているので、反対から記述して com.miecat.appname というようにします。(他人のドメインを勝手に使ってはいけません)
何も指定せずにdhでプロジェクトを作成すると hsp20220212.test1 というように日付とプロジェクト名から名前がついてます。このままでもいいならこれでもリリースできますが、他人と絶対にかぶらないという点では不安な状態です。リリースでは変えましょう。


android:versionCode="1"
android:versionName="x.xx">

versionCode は内部的な数値で、更新の度に必ず 2,3,4... とプラスしていく必要があります。必ずしも+1である必要はありません。
versionName はAndroidのアプリ情報のところで表示されるバージョン番号です。間違えてもインストールも動作もしますが、忘れずに更新します。


<uses-sdk android:minSdkVersion="14"
android:targetSdkVersion="31" />

minSdkVersion は最少ターゲットAPI。14ならばAndroid 4.0からインストール可能になります。個人的に14にしてますが、18でもいいです。それぞれの考えで。
targetSdkVersion はターゲットとするAPIですが、通常は最新に合わせます。そうしないとPlayストアの仕様上登録ができません。野良アプリなら自由ですが、実質野良アプリはほとんどインストールして貰えない状態です。
また targetSdkVersion と実際にビルドで使用したビルドツールのAPIは必ずしも合わせる必要はありません。HSP3Dishではそんなの実際は必要ないんで。うちはまだAPI-21です。ただしデバッグは入念に。


<supports-screens

これはだいぶ古い文献を元に個人的には入れてますが、必須ではないかもしれません。いちおう入れてます。


<activity android:name="tv.hsp.HspActivity"
android:exported="true"

android:exported はAPI-31から必須になった部分です。これがないとPlayストアで拒否されます。
これは元々記述がなければ true で設定されていた項目だそうです。明示が必要になっただけです。


android:theme="@android:style/Theme.Black.NoTitleBar.Fullscreen"

ここをいじるとステータスバーを表示したままとか起動時の色とかいじれます。ググって試してください。


<uses-feature android:name="android.hardware.vibrate" android:required="false" />

私が提案して公式に取り入れられた部分ですが、これはバイブレーションが非搭載の端末でも必須ではないよ、と明示してる部分です。Playストアの検索結果に影響するらしいので入れました。


<uses-permission

必要な権限の宣言をしている部分です。
標準状態では自分のアプリで使わない部分まで宣言されてますので、不要な部分は削ります。削らなくても動きますが、余計な宣言のためにインストールを許可しないユーザーが増えるだけです。
上記「いろぷち」の例では
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
が不要なので削除しています。各項目の意味はググればわかります。
AdMob広告を貼ってる方は、INTERNET と ACCESS_NETWORK_STATE は必要です。削ると広告でません。

AdMobについて。マニュアル(ヘルプ)に書いてない気がすること。
「HSP3Dish android(NDK)版プログラミングガイド」には

devcontrol "AdMob",0 // AdMobを有効にする(バナー)
devcontrol "AdMob",16 // インタースティシャル広告を表示する

との説明はありますが、以下の説明がないです。

devcontrol "AdMob",-1 // AdMobを無効（非表示）にする

とても重要な情報だと思うのですが、抜け落ちています。だいぶ前にも掲示板で書いた気がするのですが。マニュアルに記載頂ければと思います。
そしてこの非表示は「AdMobを表示しているアプリでend命令で閉じるとAndroidがエラーを返す事がある」という問題があって、それの対処に使えます。過去ログにも書いてあります。
このエラーに対処するには以下のようにします。何かタイミング的な問題みたいなのです。

devcontrol "AdMob",-1	// AdMobを無効
await 100
end

上記のend命令による不具合には長い間悩まされてました。Android 5あたりからあったので。改善策を見つけて適用したら、インストール数もじわじわあがってきています。以前はこの不具合が理由でアンインストール祭りだったんでしょう。

収益もじわじわあがってます。やはり、小さな不具合でも原因を追求することは大事です。

>3.6 beta3
>[HSP3Dish] アプリケーション終了処理時の不正なアクセスを修正

上記end命令ってもしかしてこれと関係あるんですかねぇ？ いずれにしろ私は念のために対処を入れたままにしますけど…

>3.6 beta2
>[HSP3Dish][android] 一部の機種でダイアログの改行コード文字が表示される不具合を修正

これについては私が指摘してあったやつだと思いますが、修正入ってたんですね。。自前のやつ外します。


別スレで独自スケーリングについて触れましたが、こちらのスレで後日サンプルを用意するつもりです。
それと、celbitmapってAndroid版で使えるようにならないんですかねー。これができれば、スケーリング問題については一気に解決するんじゃないですか？ バック画面に相当する処理ができないのが全ての問題点なので。
・・・とか思ったんですが、説明みると重たそうだからだめそうｗ

dishはhgimg4と比べていかがでしょう？
開発の中心はすでにdishのほうに移っているようですが

dishが先に出てhgimg4が後発だったと思いますが、dishは2D向け、hgimg4は3D向けという位置付けです。ですが、この用途に限定せず自分の目的に合うか試してみるのがいいでしょうね。
まだ個人的にはhgimg4はあまり試せてないので比較評価はできませんが、hgimg4にも魅力的な機能があるので試していきたいと考えています。

dishの独自スケーリングについてお待たせしていますが、ここにコードを貼って説明するより、ひとつのサンプルパッケージにしたほうが理解が早いと考えて作成しています。もう少し待ってねw
サンプルの動画はこちらに貼りました。
https://twitter.com/miecat_can/status/1494074385355141121

dishは2D向けですか？
でも3Dのゲーム動いてますけど。

その3Dゲームがどんなものかわかりませんが、疑似3Dでしょうか？
当然ながら、2D処理だけで3Dなゲームを作ることは可能です。

HGIMG4はHSP3Dishから派生したものです、念のため。

HSP3Dish のスケーリング問題に終止符を打ちます。
これは、HSP3Dish において、独自スケーリングを行うサンプルプログラムです。

HSP3Dish Android版をある程度いじった人ならば必ずぶち当たるであろう問題として、スケーリングによる描画品質があります。

現状の仕様上、バック画面（バッファ）に相当する機能が使えないか限定的なため、バック画面に描画してから一気に拡大コピーといったことができません。このため、オブジェクト（コピー）要素ごとに拡大縮小をしてスケーリングは実現されています。
ですが、拡大率が割り切れないと計算誤差の結果、パターン間に隙間ができたり歪んだりといった問題が発生します。たまたま割り切れたことで発現しない端末もあると思いますが、あらゆる解像度やアスペクト比の端末がある以上、偶然を期待した実装では問題があります。
理想は整数倍で拡大することですが、これに限定すると多くの端末で画面サイズより縮小した表示しか実現できなくなってしまいます。
そこでいろいろ試した結果が、0.25倍単位で拡大または縮小するということでした。

補間を使った場合の不具合については対策機能として hgio_uvfix(1) がありますが、正直苦肉の策でしかなく品質に問題があります。

詳しい解説はソースをご覧ください。
キャラクタについては、スプライトやオブジェクト等の呼び方がありますが、オブジェクトで統一させて頂きました。
また、このサンプルにはスケーリング以外にも以下のtipsを含めました。

・スワイプとタップの判定（によるスクロール）
・ビットマップフォントの実装
・描画深度（見下ろし視点によるオブジェクトの重なり）
・スキャンラインの実装

ダウンロードは下記から。readme.txt をお読みください。
http はこちら
http://miecat.com/soft/arc/scaling_sample_100.zip
https はこちら
https://miecat.com/soft/arc/scaling_sample_100.zip

このサンプルは、今年のHSPプログラムコンテストに出品する予定です。

viewcalc命令、今更思い出してこれに viewcalc vptype_2d,dm,dm というように倍率指定するだけでよかったのでは？ と思って比較してみたのですが、うちの方法のが結果はよかったです。比較してみてください。特に低解像度な端末では歪み具合が顕著に違います。

うちのは gzoom のコピーサイズに倍率かけてるだけなんですけどね。

私がtipsを書いていくスレになっちゃったけど、それでもいいですｗ
HSP3Dishではやはりダメなんだー！と思って去ってしまう人が１人でも減ればそれでいいです。無償でここまでの環境を提供頂いているので、これがうちなりのHSPに対しての恩返しです。
HSP3Dish は初期からいじってたので、もう8年以上の付き合いかもしれません。個人的にここ5年くらいは寄り道してたので半分停止していましたが、また活動復活です。
とりあえずあと4つは書くネタを用意してあるんで、よろしくです。

というわけで、今回は要望はしてあるものの、まだサポートされない機能を自分で実装してしまう方法を１つ。
過去ログでも説明してあるのですが、改めて書いておきます。

対象はAndroid版です。
ナビゲーションのバックキーでアプリを終了しますよね？ このときに何らかの処理をしたいと思いませんか。例えばいま開いてる画面を１つ戻る、ファイルにデータを保存する等です。
HSP3.6 beta2よりWindows版では onexit が追加されましたが、まだWindows環境だけです。Androidでは使えません。
そこで、HspActivity.java を自分で書き換えることでこれを実現します。
ググるとわかりますが、HspActivity.java を書き換えれば不足してる部分はある程度自分で何とかなるので、現状に不満がある方は調べてみてください。そしていい方法が見つかったらフィードバック頂けますと幸いです。

私のアプリ「いろぷち」で使用しているコードを元に説明します。
HspActivity.java に以下を追加します。

	// 戻るキーを判定（独自追加）
	@Override
	public boolean dispatchKeyEvent(KeyEvent event) {
		if (event.getKeyCode() == KeyEvent.KEYCODE_BACK) {	// バックキー
			if (event.getAction() == KeyEvent.ACTION_UP) {
				nativepoke( 0, -0x100 );		// stat に終了コードを送る
				return true;
			}
		}
		return super.dispatchKeyEvent(event);
	}

HSP側には以下のように書きます。

	await 16
	if stat=-0x100 { dialog "バックキーが押されました。" }

nativepoke( 0, -0x100 ); で指定した値が await の戻り値として取得できるようになります。これを利用して処理を行います。この方法で Android 4から12 まで動作を確認できています。

同様の方法でホームキー等も取得可能かと思い試したのですが、割り込みのタイミングの問題なのか取得できたりできなかったりしますので使えませんでした。ここは今後の課題です。
上記の実用例として、私の「いろぷち」があるので動作確認用にどうぞ（宣伝）。
https://play.google.com/store/apps/details?id=com.miecat.iroputi.free

上記補足。
HSP側で判定を入れなかった場合は、バックキー無効化と同じになります。アプリがバックキーで閉じなくなるので、この目的でも使えます。

独自スケーリング、サンプルソースにはモジュール化は各自でやってとか書いてましたが、私のほうでモジュール化することにしました。しばらくお待ちください♪

>窓月らら さん

以下スレ内容よりこちらに書かせてて頂きます。

https://hsp.tv/play/pforum.php?mode=all&num=94865#95420
https://hsp.tv/play/pforum.php?mode=all&num=94865#95423


参考になるサンプルスクリプトの制作ありがとうございます。

サンプルスクリプトの説明文を読ませて頂いて前スレで取り上げていた
「隙間」と「歪み」について理解しました。

ただ、現行サンプルでもウィンドウサイズの変更にて症状を確認できました。
（Dish/Winで確認）

hsp3dish.iniの wx,wyを変更（以下は端数での縦サイズ例）
wx=387
wy=791

-----
■「隙間」の確認
207行目のカラーを黄色に変更（分かりやすくするため）

color 255,255: boxf 0,0,sw,ady // 背景塗り潰し（空色）

210行目のセル拡大サイズを１減らす（隙間の変化を見せるため）

w=dxy(127) // 画面にコピーするサイズ

実行後、画面をドラッグすることにより黄色の隙間が出たり消えたりします（1px重ね？）


「隙間」対策はフレームバッファ（画面バッファ）があれば解決するのですが・・。
Dishへの実装の技術的困難さについてはよく分かっていませんが、
8bitPC時代にでもあるような機能がないのはとてもつらいですね。

これはフレームバッファへのセット処理と同様に
画面座標系（px）で描画を統一することで回避できます。

サンプルのタイル描画では gzoom で wとpx指定しているのに対して
locateで毎回位置をスケーリング処理しているため隙間（＆重ね？）が起きています。
ここは xyの描画位置増加を wと一致させる必要があります。

ただしスケーリングと異なり タイル数分 xyの ±誤差が発生します。
これについては描画起点や描画タイル数に応じて誤差を吸収する必要があります。


-----
■「歪み」の確認
209行目を p=2で固定（このセルが一番歪みがわかるため）

p=2 // 10秒ごとにパターンを切り替える

ドラッグすることによりレンガ模様に三角影が出たりラインが出たりと歪みます。


「歪み」対策は液晶画面の拡縮処理ならではの問題なのでドット絵のディザやジャギーを
活かしたアプリやゲームでなければアンチエイリアス(gfilter)に頼るしかありません。

207行目の color の後に gfilter 1を追加

color 255,255: boxf 0,0,sw,ady // 背景塗り潰し（空色）
gfilter 1

219行目の loop の後に gfilter 0を追加

loop
gfilter 0

これで歪みは消えますが、Dishの gfilterには外周1px問題があるため外周が透過されます。
これについてはタイル画像のようなセルの場合、説明文195行目で書かれた対応をするしかありません。

>隣接する同じ色で塗り潰す等です。そしてプログラムのほうでは周囲1pxは
>使わない領域として gzoom 等でコピーします。


サンプルについて質問ですが、私の環境で scanline（走査線）処理によるライン描画によって
画面上にモアレが発生しています。黃色バックで表示したところ横線が顕著に見られました。

コメントにはモアレ回避とありますが、この処理はどのような場合に効果がありますか？


>HSP3Dishではやはりダメなんだー！と思って去ってしまう人が１人でも減ればそれでいいです。

日は浅いですが、HSP3Dish/NDKを使っていて共感できます。
私も微力ながらフィードバックしている感じです。

ただ、どうしても正しい処理とは別に、Dish不具合や未サポートのための対策スクリプトを
Win版やNDK版などによって別に組む必要があるという点は、説明も明示化もされておらず、
言語のクセとも言えませんし、それを理解していない人が利用を断念しても仕方ないかなと
思っています。

この状況が早く改善していくと良いのですけどね。

>zezenana さん

ざっくりレスします。
まず、このサンプルは「Android向け」ですｗ Windows向けではありません。
そして、127は割り切れない値を自ら指定していますし、極端に小さな値を入れれば計算誤差を自ら発生させますから、歪んだり穴が開くのは当然です。その指定サイズが間違いです。

サンプルをビルドしてAndroidで試してみてください。そちらで評価くださいませ。
少なくとも私のところでは４機種すべてで問題ない範囲で描画できております。

スキャンラインについても同様で、これは Windows向けには調整しておりません。
hsp3dish.ini でモアレが起きない設定にしてあるだけです。
ソースと画像パターンを見ればわかりますが、最大640px分までしか用意してないため一致しない環境はありえるのですが、そういう環境では gfilter 2 の効果で目立たなくなるようになっています。

只今モジュール化が終わりまして、説明書を書いてます。

gfilter 使用の場合については、ソースに詳細を書いてありますので今一度お読みください。
まず、周知のとおりですがパターン画像のほうを工夫しておくのが大前提になります。私がサンプルで用意したパターンは gfilter を使用しない用ですので、これを使ってテストしても不具合はでます。

サンプルをいじらず、そのままビルドしてAndroidでお試しください。
当然ながらコピーサイズを変則的なものにすれば歪みます。パターン画像が想定しているサイズを指定しなければ意味はありません。

HSP3Dishの特にAndroid版の状況については当初よりハードル高めです。これでもだいぶよくなったのですが、まだまだ不足していて初心者向けとは言えませんが、これはある程度は仕方ないかなと思います。
ビルド環境をセットアップして不足を自力でなんとかできる人向けです。

よくあるパターン画像のサイズとして、8x8 16x16 32x32 64x64 など、8の倍数が選択されますが、これは昔の名残ではあるのですがコンピュータが扱いやすいのでこのサイズになっているわけです。

私の方法で 0.25倍単位にしてる理由はここにあります。以下を計算すれば直ぐにわかります。

例えば 32x32 のパターンだったとします。
32x1.25=40 32x1.50=48 32x1.75=56
となり、いずれも小数点以下は発生しません。こういうことです。

これが 127 となりますと
127x1.25=158.75 127x1.50=190.5 127.1.75=222.25
となり、誤差が発生します。
ですから、画像コピー結果が歪んだり1px穴が開いたりします。

ビルド環境については、近いうちに
現在のaab生成に合わせた物を
しまくろねこ さんが、自身のHPで
解説してくれる...みたいです。

ここに辿りつければ、かなり楽になる
のではないかと。便利なツールの類も
公開してますし。


iOS 用の開発は、さらにキツい。
(※私は、金銭面、技術面でも絶対ムリ)
HSP3.xのM1への対応が不明。
(※Twitterでは、超上級者の方が動作成功した様ですが...
いずれにせよ、Mac本体が必要)、アップルへの年会費 と専門書籍
↑ コレが、Android並みにならないと、割が合わない。

...ハードルが高すぎて、この掲示板で
約半年見てるが、3人位かな？...うち2人は
偶然覗きに見えたイノビアさん、zakki さん
といった具合で。解説サイト等も皆無に等しい。

Android版のビルド環境ですが、最新HSP3.7b1ではだいぶ楽になっていて、JDKとコマンドラインツールを適切にセットアップさえできれば、あとは初回セットアップで自動的にダウンロードしてくれるようになったので、ハードルは下がりました。
ただし、GBレベルのダウンロードをしますのでmvno等でインターネット回線を使ってる人はパケット量に注意は必要です。

文面が分かりにくく混乱させたようですみません。

ドットを見やすくするための修正を書いたのが混乱の原因でして、
高dpiや色差のドット変化が目視で確認出来れば修正は一切不要です。

スクリプトは付属exe が画面サイズ固定のため利用しました。
DM値を小数にするため hsp3dish.ini を変更し適用しています。
NDKビルド後 768x1024(HD)などの端末やAVDでもOKです。

独自スケーリングモジュールを公開します。HSP3Dish Android版向けです。
先に公開したサンプルをモジュール化して gcopy gzoom grotate の互換命令を追加したものになります。
readme.txt をお読みください。

描画スケーリング モジュール for HSP3Dish
Version 1.1

http はこちら
http://miecat.com/soft/arc/mod_scaling_101.zip
https はこちら
https://miecat.com/soft/arc/mod_scaling_101.zip

こちらを今年のHSPプログラムコンテストに出品する予定です。
先に公開したサンプルは削除しましたのでリンク切れになっています。


>zezenana さん

いえいえ、おかげで説明書に追記すべきことがわかりましたので良かったです。この説明は必要でした。

訂正。
>初期のHSP3Dishからあった問題で、HSP3.6b2で(恐らくたまたま)改善していたのが、3.6b3で再び悪化したというものです。3.6b3でmesの最適化が行われたので、それが原因かもしれません。

これは、問題ないのは HSP3.6b1 でした。b2 は問題がでます。
プロジェクトのファイル名等が変更されたタイミングですね。。

Android版についてです。
おにたまさんのスレで、恐らくAndroid 10以降ではJava側とHSP側で画面高さに違いがある点について触れましたが、暫定的ながら、dialogを拡張改造することで取得する方法を書いておきます。
これを利用すると、Java側のステータスをHSP側で取得して利用することができます。
実行端末がジェスチャーナビゲーションバーか、従来のナビゲーションバーかが、取得結果から判定可能になるかと思われます。
Android 10〜向けに必要な処理で、Android 9までは不要だと思われます。

まずはJava側をこんなふうに改造します。
HspActivity.java のソースで dispDialog を検索して該当部分を探して書き換えます。
Build.VERSION.SDK_INT を使うためには import android.os.Build; の追記が必要です。

    public int dispDialog( String msg1, String msg2, int type ) {
	if ( type >= 128 ) return getJavaStat( type );	// 独自
	if ( type >= 4 ) return -1;
	if (( type & 2 ) > 0 ) {
		return ui_dispDialogYN( msg1, msg2, type );
	}
	return ui_dispDialog( msg1, msg2, type );
    }

	// 独自
	// Java側で取得した情報をdialogのstatに送る
	public int getJavaStat( int type ) {
		final int addtype;
		addtype = type;

		this.runOnUiThread( new Runnable()
		{
	        @Override
	        public void run()
		        {
				// 画面の高さを取得
				// ジェスチャーナビ(Android 10 以降)な端末ではHSP側と一致しない
				if ( addtype == 128 ) {
					WindowManager windowmanager = (WindowManager)getSystemService(WINDOW_SERVICE);
					Display disp = windowmanager.getDefaultDisplay();
					nativepoke(0, disp.getHeight());
				}
				// APIバージョンを取得
				
				if ( addtype == 129 ) {
					// OSバージョン(例えば Android 12)によっては変数に入れないと取得できない
					int apiver = Build.VERSION.SDK_INT;
					nativepoke(0, apiver);
				}
			}
		});
		return 0;
	}

HSP側のテスト。

#include "hsp3dish.as"

dialog "",128: java_sh=stat		// Java側の高さを取得
dialog "",129: java_apiver=stat	// APIバージョンを取得

strmes ="Java\ndisp.getHeight: "+java_sh+"\nAPI-"+java_apiver+"\n\n"
strmes+="HSP\nginfo_winy: "+ginfo_winy+"\n"
dialog strmes,0,"getJavaStat test"
end

テストの過程でわかったのですが、ビルドが通ってもAndroidバージョンによって動作しなかったりしますので、実機でのテストは必須です。

上記の「APIバージョンを取得」ですが、正しく動かない端末がありそうです。原因は不明。
とりあえず、SHV39(Android 9) Pixel6pro(Android 12)では動作し、Pixel6(Android 12)で取得できない（0が入ってくる）のを確認。ただし、お友達にテストしてもらってるので誤報等はありえます。

Androidバージョンの取得についてはHSP側にも方法が用意されているので、そちらを使えばいいですね。今回のはテストのついでですので。

nativepoke(0, disp.getHeight()); については今のところ問題なく取得できています。

えー。上記の「APIバージョンを取得」ですが、問題なかったと思われた端末でも、取得できたりできなかったりする場合があることを確認。
じゃあ変数に入れないといけないのも誤報ですねこれはｗ
またしてもこのパターンか・・・と。恐らくはタイミングの問題で、もしかしたらHSP側でawaitの後だったら取得できるとか、そんなパターンの可能性はあり。
いずれにしても今回問題になってる部分には関係ないので保留します。

上記なんとなくわかりました。
どうやらHSP側の呼び出しの順番が影響していて、連続だと2番目からコケることがある。
以下のようにすると、今度は高さ取得のほうがコケるようになります。

// 連続呼び出しすると2つ目以降が正しく取得できない場合があるので注意！
dialog "",129: java_apiver=stat	// APIバージョンを取得
dialog "",128: java_sh=stat		// Java側の高さを取得

まあ、暫定なんで・・・1つ取得できれば使えます。

上記の方法は Android 4.0.4 では取得できたりできなかったりしました。
いまのところ問題ないのを確認したのは Android 9,12 です。
今回のは Android 10以降のための対策なので問題はないですが、エラー対策として stat=0 が入ってきた場合は ginfo_winy の値に置き換えるようにしています。

こちらが実装例になります。
https://twitter.com/miecat_can/status/1497504463388491777

devinfoi とか devinfo とかありますが、マニュアルに詳しいことがなく使い方が不明です。
公式サンプルが欲しいですね。

hgimg4って64ビット機でしか動かないんですかね？
というのも取得できるopenGLが64ビット版しかないようなのです。

OpenGL 32bit版もありますよ？
旧バージョンの対応なども確認されてみてください。

乱入してすみません。

ウチの場合、7の32ビット、hsp3.6であれば
hgimg4のサンプルは動いてますが。
私が、思いついたのは、この事位でしょうか？
間違い／勘違いなら、申し訳ないです。

OpenGL 32bit版 で検索。
検索結果の中にありました。

https://docs.microsoft.com/ja-jp/troubleshoot/windows-server/performance/compatibility-limitations-32-bit-programs-64-bit-system

窓月ららさんどうも
32ビット版は手動で設定しないといけないようで面倒
なので放置
64ビット機でまた試してみようかと思います。

Playストアですが、データセーフティの対応が必要になっています。現在は猶予期間です。
プライバシーポリシーのページも必要になりますので、用意してない方は作成ください。

Google Play Console の左メニューの一番下の「アプリのコンテンツ」で設定します。

データセーフティについては、私は以下を参考にさせて頂きました。ありがとうございます。

【GooglePlay】データセーフティの記述例 | ゲーム制作の骨(Tips)
https://www.zkn0hr.com/google-play-firebase-admob-data-safety-example/

一旦作ったらcsvでエクスポートすれば、すべてのアプリに適用できます。
(同じ条件ならば、ですが)

上記のデータセーフティとプライバシーポリシーですが、すべて審査通ったので補足します。

データセーフティについて、上記の参考サイトの
アプリのアクティビティ＞ページビュー、アプリ内のタップ
これは項目が現在は無いようなので
アプリのアクティビティ＞その他の操作
のほうだけ適用でいけてます。

もちろんこれはAdMob広告を貼ってる場合の例です。
ただし「分析」のほうについては自分で実装してなくてもグーグル側で勝手に入ってるものなので、いちおう入れておいたほうがいい項目な気はします。

プライバシーポリシーについては以前は必須ではなく長年うちは作ってなくても何も言われてないのですが、12歳未満が使う可能性があるアプリでは必須になってる様子だったので作りました。多くはたぶんレーティング 3+ だと思うので必要です。

そんな企業みたいに長々としてガチガチのやつじゃなくても、個人情報についての方針を書いておけばいいだけです。
私のアプリの場合はコンテンツでは個人情報を扱わないので、主に広告について書いてます。
参考までにうちのを貼っておきますが、たったこれだけです。
https://store.miecat.com/privacypolicy.html

アプリのコンテンツの部分はすべて申告しておいたほうが無難です。
データセーフティについては今後申告の有無でバッジがついたりつかなかったりするらしいので、マーケティング上も必要です。

超基礎的なことですが、マニュアルに無いんで書いておきます。
例によってAndroid版ですが、アイコンについて。

dhでプロジェクトを作ると resフォルダの中にアイコンファイルがあります。
標準では以下のフォルダがそれです。

drawable-ldpi
drawable-mdpi
drawable-hdpi
drawable-xhdpi

いずれのフォルダにも、サイズ別に ic_launcher.png というファイルがあります。これがアイコンです。
なんでサイズ別に用意しないとならないんだ、めんどくせえ！ と思ったりもしますが、Androidの仕様です仕方ありません。
しかし本当にめんどくさかったら、上記4つのフォルダを削除して drawable というフォルダを作成し、そこに192x192のアイコンを入れるだけでも一応動きます。小さいアイコンは Android のほうで作ってくれて表示はされます。ただし表示品質があまりよくないです。

また、HSP3Dish標準のアイコンはかなり初期の時代のままです。いまの新しい環境では192x192まで必要です（必須ではないけど、無いとフルサイズで表示されません）。

というわけで、私のところでは以下のサイズを用意しています。Android 4 のときからこれでした。

フォルダ名　アイコンのサイズ（解像度）
drawable-ldpi　　36x36
drawable-mdpi　　48x48
drawable-hdpi　　72x72
drawable-xhdpi　 96x96
drawable-xxhdpi　144x144
drawable-xxxhdpi 192x192

Android 7.1 から丸型アイコンがデフォになりました。よって、基本的には丸型で、周囲を透過のpngで作成します。丸型に影をうっすらつけておくと吉。
Playストアの登録で512x512アイコンも必要なので、512x512くらいで作成して、縮小で作成するのが吉。

続いて、同じくresフォルダに values というフォルダがあり、この中に strings.xml というファイルがあります。これがアプリ名を記述するファイルです。

<string name="app_name">xxx</string>

という部分の xxx を書き換えます。

言語別に表示を変えたい場合は、フォルダを作ってその中に strings.xml を入れます。

例)
values-en フォルダ → 英語
values-ja フォルダ → 日本語

元々ある values フォルダは英語でいいです。その他の言語環境で使われます。

丁度いいスレが有ったのでここに書いてみます。

hsp3dish.asを有効にすると、boxfのサイズが右下1ドット分足りなくなる現象は皆さんどのように解決していますか？

;#include "hsp3dish.as"
redraw 0
	color 255
	boxf
	color
	pset 10, 8
	boxf 10,10, 11, 11
	line 10,13, 11, 13
	
	pos 0, 100
	gzoom 200, 200, 0, 0,0, 20, 20
redraw 1

それともこれはWindows上でのみ発生する現象なんでしょうか。



Dishにまだなれてなくてgzoomもろくに使いこなせてない…。

> GENKI　様 (NO.95633)
　hsp3dish.jsでも発生します。ちゃんと座標指定したはずなのに、画面切り替え時に1ライン残ってたことから発覚したことなので。
　結局右下座標を+1しました。

> GENKIさん

ほんとだ、dishでは1px右と下が少ない。
ただこれはWindows版だけですね。Androidでは問題になってません。

あとline命令にも挙動の違いがあるんです、WindowsとAndroidで。
これはだいぶ前から把握してたんですが、調整すればいいだけなんでいいかーという感じです。
いちおう、おにたまさんに報告しておいて頂ければと思います。
https://hsp.tv/play/pforum.php?mode=all&num=94865

↑のスレで報告上がってるcircle命令が塗り潰ししかできないのも初期からありました。
個人的に使わないので放置してました。。

js版でもありましたか。
Androidでは1px残るようなこともないので大丈夫なはずですが、
細かい違いがあるんで #ifdef とかを使いパラメータを分けてたりしました。
mesのポジションも少し前まで全く違いましたからね（いまも微妙には違う）。

余談？

今朝、Twitter で見て、boxf 命令の代わりに
gradf 命令で、p6、p7に、同色使って描画。
p3、p4で、直接サイズ指定する為か
Win／Dishとも、問題ないらしい？です。
(※Android実機は不明)

ただ、パラメータ指定が面倒、
多分、処理が重くなりますので
1ドット分、計算した方が楽かなと。

動作報告ありがとうございます。
Windows上で1ドット調整して作った後にAndroidに持っていくと逆にはみ出しちゃうんですね。知らないと頭抱えそう。

この問題について調べてみると、2014年からすでに報告が上がっていました。
http://hsp.tv/play/pforum.php?mode=pastwch&num=61865

流石に何年も前の話なのでもう解決してるかな？と思って質問してみたのですが、解決してなかったのか。
もうこれは変更されない仕様とと考えていい気がしてきました。仕様なら仕様でマニュアルに書いてほしいですね。


> 細かい違いがあるんで #ifdef とかを使いパラメータを分けてたりしました。

なるほど影響がある命令は直接使わずに、マクロなどの置き換えでの利用をするようにすると手軽に解決できそうですね。

上記の boxf の違いですが、私が使用してる用途だとWindowsでもAndroidでもあまり問題が無かったため気づかなかったようです。
例えば私の場合は背景塗り潰しに使うことが多いのですが

color: boxf 0,0,ginfo_winx,ginfo_winy

これは黒で画面全体を塗り潰すわけですが、WindowsでもAndroidでも問題はでません。
dish無効のWindowsでは逆に画面外1pxまで塗り潰されてると思います。

いずれにしろシステムのバグですから、おにたまさんの対応を待ちます。

これは考え方でどちらがいいのかって問題も少々ありますねぇ。
例えばスクリーンサイズ 640x480 だった場合に

color: boxf 0,0,640,480

とすれば全画面が黒で塗り潰されるわけですが、Windowsのほうでは厳密には

color: boxf 0,0,640-1,480-1

が正しいわけです。でも結果的にはどちらも同じで問題になることはありません。
しかしやはり「指定した座標まで含む」のほうが正しい動作だと思われます。いままでWindowsのほうの実装はずっとそうでしたので、dishだけ-1になってるわけですからね。

うちが試した限りではAndroidで問題にはなっていませんが、じつは-1になってるのかもしれません。
最近はかなり高解像度な環境で動かしてるため、1pxくらいの違いを見落としてるだけかもしれませんので、すみませんが必要な方は検証ください。

それと、dish環境だとAndroidでスケーリングをした場合の直接描画命令は、実行端末解像度基準になる点に注意が必要です。
特に line 命令はその端末の解像度基準の線になります。なので私は boxf ですべてやってます。斜め線には対応できませんが。

いま改めて検証したら、Androidでも同じみたいです。
そういえば、うちの CoinFZ for Android で boxf を使ってスクロールバーを描画してる部分があるのですが、縦のみ+1しないと位置が合いません。そういうことだったのかー！ 謎が解けました。

修正されたらされたでソースを手直ししないとならなくなりますが、そこは仕方なしです。

tips追加しておきます。Android版です。

mmload mmplay で効果音や音楽を再生しますが、この素材ファイルについて。

まず、効果音、BGM共に冒頭に 0.01〜0.015秒程度の無音を入れておかないと、端末によっては正しく再生されないことがあります。
これは端末によるとしか言えません。HSP3Dishのせいではなく、端末側の仕様です。
例えば省電力化のために、音が鳴っていないときにはミュート（アンプの給電停止等）されている端末があります。何かが再生されるとこれが解除されるのですが、この解除にかかる時間が端末によりマチマチなのです。
よって、冒頭に少し余裕を入れておかないと頭が切れて再生されます。
短すぎる効果音などは再生されない（ように聞こえる）場合もあります。

こういうのは、複数の端末でテストしてみないと気づきません。

0.01秒というのは 10ms に相当します。
60FPSの1フレームは約 16.66ms なので、それ以下に収まりますから遅延はほとんど感じません。

また、同じ効果音を連続で再生、例えばショット音などがこれですが、同じIDを連続で再生しようとしてもうまく再生されない端末が結構あります。
ですので、複数のID（例えば3つとか4つとか）に登録して、同じIDで再生されない工夫が必要です。
ただし現状の制限として mmload は30個までしか登録できませんので注意です。マニュアルにも記載があります。

端末のミュートを発動しないための工夫。
電力は多少食うでしょうが、10秒程度の無音のmp3を常に再生しておけば発動しません。無音ですから、32kbpsでエンコードしておけば問題ありません。
でもミュートと関係なしに冒頭が切れる端末もありましたので、やはりwav mp3側の工夫は必要です。

dialogを改造してJava側の画面高さを取得するやつの実装例です。
こんなことが可能になります。(Android 10以降)
この処理ができるまで、広告サイズも一致しない環境がありました。公式に取得できるようになって欲しいです。
https://twitter.com/miecat_can/status/1501423649059868672

ちなみに、ginfo_winyの動作としては正常だと思います。ナビバーの下まで描画できて表示はできるので(Android 10〜)。
なので、今後対策が公式に入るのであれば、ナビバーの高さ取得だけでいいと考えます。

よくわからんけど追加が必要っぽい事項について。
AndroidManifest.xml についてです、つまりAndroid版でAdMobを使用する場合ですが

android:name= "com.google.android.gms.ads.APPLICATION_ID"
android:value= "ca-app-pub-xxx"/>

まず上記のようにアプリIDの追加が必要になってます。HSP3.7b1では書いてあるはずですが、自分のアプリIDに書き換えが必要です。

<uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

次にこれですが、どうやらこれがないと4/1以降何か動作に変更が起こる可能性。
ですが、グーグルの暗号みたいな説明を読み解くとこれは他の場所で既に宣言されている可能性ともあります。だからもしかして追記しなくてもいけるかもしれませんが、追記してあっても不都合は無いと判断してうちは入れました。
問題なくビルドも通ります。

ポリシーが日々変更されてるので地味に対応が必要です。
各自ご精査ください。何かわかったら教えてくれると助かります。

広告IDについてはこちらなど
https://support.google.com/googleplay/android-developer/answer/6048248?hl=ja

つまり、ユーザーが広告をブロックできる？と思ったのですが、Android13以降はパーミッションで宣言しないとデフォでブロックされる？という認識です。
OSが更新されるたびに毎回いろいろあります。

AdMobについてです。
4/1以降なにか変わるらしいことは書きましたが、いまのところうちのアプリでは問題はなさそうです。
半分勘で入れた対策が生きてるのか取り越し苦労だったのかわかりませんが。

で、うちは新しいグーグルポリシーに対応するために広告は上部に変更したわけですが、収益は下がるかな？と思ってたのですが、いまのところ大きな影響はなさそうです。

便乗しますがmesでの表示も実機だと6p下がって表示されますよね。
そういう仕様かとおもって作ってますけど。
みなさんどうなんでしょうか

>きせんさん
その問題前々からですが、Android側の搭載フォントにより
変わってしまうのです。なので仕方ないので私のアプリでは
ユーザーが調整できる機能を用意しています。(CoinFZ)
6pとのことですが、他の機種では違うことがあります。

トピ違いで恐縮ですが、ららさんの作成されたアプリで、
タップ位置が違う！といった状況や報告はありますか？

グーグルコンソールでレビュー見ている限り、
おなじアンドロイドのバージョン（アンドロイド9）な筈なのですが
タップ位置がずれてる！という報告があるのです。
機種ごとに違うとなると、ほぼどうしようもないんですが、

フォントのようにユーザーで調整する方法はあるとはおもうのですが、
mousex や　ginfo()に、機種で差があると、ほぼお手上げです。

他の方もどうなんでしょう。

>きせんさん

タップ位置のずれについては今のところ報告はありません。
私の場合、公開しているものは全て独自スケーリングなので自前計算です。
なのでずれることはありません（入念に確認しております）。
もしかしたらHSP3Dishのスケーリングに不具合でもあるんでしょうか？

独自スケーリングについてはこのスレの No.95536 でサンプルを
公開しているとおりです。

ちなみに私は mtinfo のほうで取得しています。
mousex,mousey は使っておりません。

>窓月ららさん

私もmtinfoをつかっているのもあります。マルチタップだとこちらですよね。
おなじアプリで、おなじアンドロイドのバージョンで、挙動が違う気がします。
不具合の機種でないと再現できないか、試しようがないのでよくわからないのです。
mtinfoに変えてみます。

>きせんさん

機種固有の不具合もあるので、
その端末が手元にないとわからないんですよね。

私が何回も指摘しているmes文字が塗りつぶされる不具合も
おにたまさん環境では確認できないので放置されております。
具体的な機種名も提示してるのですが、
さすがにコストかけてまで用意するのも限界がありますから、
仕方なしです。

部外者な上、話の流れを無視して、申し訳ないです。

Android 絡みの話は、ここで質問させて頂くのが
一番良いかな？と思いまして。

(※私自身は現状、PC、ネット環境が
ないので、どうしようもないですが
情報だけは知って置きたいです。)

現時点では、日本での対応等が不明ですが
下記について、どうお考えでしょうか？

Amazon Appstore経由でWindows 11に
Androidアプリをインストール、実行する。

個人的に、Windows11自体は
あまり使いたくないのが本音ですが
そろそろ、hsp3dishにも情報収集と対応準備等が
必要ではないかと。

https://www.lifehacker.jp/amp/2203your-windows-11-pc-can-finally-run-some-android-apps/

>zrs90(5さい)さん

Windows11上のAndroidアプリの動作については、現時点ではサポート外で構わないという考えです。MSが危機感あらわにしてこっちでも動くよ！と言ってるだけの機能です。元々スマホ向けにデザインされたアプリをWindowsで使う意味がわかりませんし、動作せずともサポート外で通します。

ここから毎度のこととはいえMSのブレにイライラしてるららちゃんの方針。
個人的にはWindows11は導入しないという方針になってます。周囲でも10に戻す動きがあります。10で止めます。10が最後のWindowsとアナウンスしておいて他のOSを意識してナンバリングアップしてるOSに興味は無いのです。タダでもいりません。

愚痴ついでに書きますと、個人的にはWindows向けにリリースしたものについても
Windows Me,Vista,8.x,11 についてはサポート対象外ですといいたくなります。
上記すべて個人的にはスルーしているバージョンです。内容を見た上でスルーしています。
OSが足かせになってはいけないのです。わざわざ改悪に付き合うことはしません。

現時点のWindows11 の評価は
私個人も、ほぼ同じです。
(※ここまでは、さすがに書きませんが...)

Windows11 上で動く現在出回っている
Androidエミュの要求動作スペックが
私の想定以上で...Androidナメてました。
(※ MSの実機動作版は知りませんが
blenderの3dcg製作環境とほぼ同等)
↑
コレを先に調べていたら、今回の質問自体
しませんでした。

ご返信して頂き、ありがとうございました。

devinfo a,"locale"

この命令文も面白そうですね。

>きせんさん

その命令まだ試してないのですが、それを使えばアプリ内メッセージを変えられますよね。
日本語環境以外は英語をデフォにするなど。

上のほうでやや脱線してWindowsについて書きましたが、
個人的にスルーしたバージョンももちろんアプリはサポートしています。
さすがに9x系はノーチェックなので2000〜にしてますが。

以前書いたPlayストアのデータセーフティの件がきてると思います。
うっかり放置してると気づかないかもしれないので、アプリを登録してる方は
Google Play Console を確認しにいったほうがいいです。

きせんさんご報告のタッチ位置がずれることがある件ですが、
Android 9とのことでしたが機種名は不明なんでしょうか？
もしわかりましたら情報としてシェア頂ければ幸いです。

問題が発生する機種が手元にないことには検証できないわけですが、
とりあえず私の憶測を可能性として書きます。
検証ポイントとしてお読み頂ければと思います。

原因としては以下があると思います
1. HSP3Dishのスケーリングの不具合（新しい環境に対応していない？）
2. その機種固有の不具合（対応不可）

まず1ですが、AdMobの対応過程で
HSPコード側のginfo_winyとHspActivity.java側のdisp_heightに違う値が
入ってくる環境があることがわかっています。(Android 11,12 の Pixel3/6 で確認)
この2つは本来一致しなければなりません。
Android 10以降のジェスチャーナビ環境だけだという認識なのですが、
もしかしたらAndroid 9でもこの問題が起きる環境があるのかもしれませんし、
問題なのは標準スケーリングがどちらの値を元に処理しているかです。
表示と座標の計算にそれぞれズレがある値を参照していた場合は、ズレが起きる可能性はありえます。
実際は問題が起きる機種で検証しないとわかりませんが、
とにかく、現状では潜在的にこういう不一致問題があります。

2はどうしようもないので、サポート外にするしかありません。

個人的には英語向け、中国向けの方がユーザーが多い理論ですので、
その場合ディフォルトで使っている言語を選択する場合にはよさそうでした。

実機ですと、devinfo a,"locale"　で　jpnと表示されました。



機種名は
Samsung Galaxy S8 Android バージョン: Android 9（SDK 28）ではＮＧ
Sony Xperia XZ2　Android バージョン: Android 9（SDK 28）でもＮＧ
Huawei P20 Pro　Android バージョン: Android 9（SDK 28）では問題なし（ぽい

マルチタップを必要としなかったので mousexを使っていましたが、
ゲーム画面の余白の関係でズレるようです。全画面表示なら問題なさそうですが、
推測だけで検証していません。

mtinfo文ですと、描画しない範囲でも上手に取得しているように見えましたので、
androidですとほぼ mtinfo文が必須な感じです。


ちなみにミリタイムまで取得した時間制限みたいなのをやろうと思ってやっていますが
gettime(7)で取得すると、PC上では3桁取得しますが、実機では2桁でした。

あとベータ版でそのままビルドすると標準状態でも
ナビゲーションバーの上に広告が表示されるようになってました。

>きせんさん

情報ありがとうございます。
ロケーションについては今後活用しようと思ってます。

>ゲーム画面の余白の関係でズレるようです

ああ、センタリングが正しくない可能性ですねこれは。
やはり処理に使用している縦サイズに差異がある問題が原因かもしれません。
もしこれだとしたらdishのバグです。

私の場合ですと自前でginfo_winy基準なので、差異は起こりません。

>あとベータ版でそのままビルドすると標準状態でも
>ナビゲーションバーの上に広告が表示されるようになってました。

はい、そうなります。
なので自分でなんとかするしかありませんでした。

新しい環境で想定外の状態がいくつかあり、公式もまだ対応できてないのです。
フィードバックしつつ、対応を待つか自前で対応するしかありません。

書き忘れ。
ミリ秒でしたら、getreq t,SYSREQ_TIMER を使えばAndroid上では高精度なタイマーが使えますね。
私などはこれをBGMのループ処理やアプリのタスクが停止していた時間の判定等に利用していますが、
かなり高精度なのでほぼズレません。(Windowsみたいに精度があやしいこともなさそうです)

>窓月ららさん

ほんとだ（笑
getreq t,SYSREQ_TIMER
これ使ったほうが楽ですね

以下Googleからのお知らせそのまま引用
ターゲットAPIは上げざるをえないので対応が必要です。

Console に導入される新しい広告 ID 申告フォーム
2022年6月14日 17:00

7 月以降、アプリで広告 ID を使用する場合は Google Play Console で Google にお知らせいただく必要があります。これにより、広告 ID がゼロにリセットされる危険性がリリースで生じた場合に、有益なフィードバックを Google から受け取ることができます。Android 13 をターゲットとするリリースを作成する場合は、広告 ID の申告フォームに必ずご記入ください。

API レベル 33（Android 13）以降をターゲットとし、広告 ID を使用するアプリについては、そのアプリの AndroidManifest.xml に標準の権限 com.google.android.gms.permission.AD_ID を追加する必要があります。これにより、広告 ID がゼロに設定されることを防ぎます。マニフェスト ファイルで権限を宣言していない場合、またはライブラリ マニフェストで宣言した権限を含めないようにした SDK を使用する場合、広告や分析のユースケースに影響することがあります。

dish 関連の質問はこちらで良いでしょうか？
自動スケーリング前の画面の縦横サイズを知る方法ってわかりますでしょうか？

以下のコードを Windows 上で実行すると
ginfo_dispx が 1920 である事を得る事ができたのですが
Android スマホでは正しく取得できませんでした。

また
\jni\main.cpp の
hgio_autoscale( 0 ); をコメントアウトした状態で
自動スケーリングを OFF しても、正しい値は取得できませんでした。

#include "hsp3dish.as"
color 255,0,0 // 文字列の色
mes "ginfo_sizex "+ginfo_sizex // ウィンドウ全体のXサイズ
mes "ginfo_dispx "+ginfo_dispx // デスクトップ全体のXサイズ
mes "ginfo_sx "+ginfo_sx // 画面の初期化Xサイズ
mes "ginfo_winx "+ginfo_winx // 画面の描画エリアXサイズ
redraw 1

おはようございます。

気になったので私も試してみました。


\jni\main.cpp の

; hgio_view
; hgio_scale
; hgio_autoscale

を全てコメントアウトして

UMiDIGI A3 PRO（720x1512）で

#include "hsp3dish.as"

repeat
	redraw 0
	color 255, 255, 255 : boxf
	color 255, 0, 0				// 文字列の色
	pos 0, 0

	mes "ginfo_sizex "	+ginfo_sizex	// ウィンドウ全体のXサイズ
	mes "ginfo_dispx "	+ginfo_dispx	// デスクトップ全体のXサイズ
	mes "ginfo_sx "		+ginfo_sx	// 画面の初期化Xサイズ
	mes "ginfo_winx "	+ginfo_winx	// 画面の描画エリアXサイズ

	mes "\n"

	mes "ginfo_sizey "	+ginfo_sizey	// ウィンドウ全体のYサイズ
	mes "ginfo_dispy "	+ginfo_dispy	// デスクトップ全体のYサイズ
	mes "ginfo_sy "		+ginfo_sy	// 画面の初期化Yサイズ
	mes "ginfo_winy "	+ginfo_winy	// 画面の描画エリアYサイズ

	redraw 1
	await 16
loop

をAndroid上で実行してみました。

結果は、

ginfo_sizex 0
ginfo_dispx 720
ginfo_sx 720
ginfo_winx 720

ginfo_sizey 0
ginfo_dispy 1344
ginfo_sy 1344
ginfo_winy 1344

でした。
Yサイズはステータスバーとナビゲーションバーがあるためか若干小さめになっていました。

また

\jni\main.cpp の

hgio_view

だけ 480x800 にして
上記ソースをAndroidで実行すると、結果は

ginfo_sizex 0
ginfo_dispx 480
ginfo_sx 480
ginfo_winx 480

ginfo_sizey 0
ginfo_dispy 800
ginfo_sy 800
ginfo_winy 800

でした。

Yサイズはステータスバーとナビゲーションバーの存在に影響されませんでした。

最後に、

\jni\main.cpp の

hgio_view

だけ 720x1512 にして
上記ソースをAndroidで実行すると、結果は

ginfo_sizex ？	（ステータスバーに隠れて見えない）
ginfo_dispx ？	（ステータスバーに隠れて見えない）
ginfo_sx ？	（ステータスバーに隠れて見えない）
ginfo_winx 720	（ステータスバーに一部隠れているがなんとか見える）

ginfo_sizey 0
ginfo_dispy 1512
ginfo_sy 1512
ginfo_winy 1512

でした。

Android上の画面サイズ取得は、「hgio_view」に左右されるみたいですね。

ああ、すいません訂正です。

コメントアウトは

; hgio_view
; hgio_scale
; hgio_autoscale

じゃなくて

// hgio_view
// hgio_scale
// hgio_autoscale

でした。

スケーリング前の画面サイズは私は内部解像度と呼んでるのですが
これはプログラマが任意で指定するものですから、
それがスケーリング前サイズではないでしょうか。
hsp3dish.ini でプログラマが指定したサイズがそれです。

つまり定数ですからginfoで取得する必要はないと思われます。
私のリリースしたAndroidアプリでも定数として処理しています。

ご回答、ありがとうございました。

しまくろねこさん

＞ UMiDIGI A3 PRO（720x1512）で

上記デバイスに対し
720 や 1344 の数値を取得できたとの事でしたが

私の環境で試した所
1280x800 であると思われる Android デバイスに対し
hgio_view hgio_scale hgio_autoscale の３箇所をコメントアウトして
試しましたが

320x480
しか得る事ができませんでした。

窓月ららさん

＞ これはプログラマが任意で指定するものですから、
＞ それがスケーリング前サイズではないでしょうか。
＞ hsp3dish.ini でプログラマが指定したサイズがそれです。

教えていただき、ありがとうございました。

私のしたかった事としては、
・ドットバイドット (勝手にスケーリングされない状態)
かつ
・X 方向、Y 方向ともに最大値
の状態でアプリを起動し、
多くの情報量を表示できるアプリが作れないか、
と思った次第です。

引き続き、なにか情報がありましたら教えて頂きたいです。
よろしくお願いします。

>はじめ さん

このスレのだいぶ上のほうになってますが、NO.95536 に
私の独自スケーリングのモジュール＆サンプルを公開してあります。
これはdishのスケーリングなしの状態で起動してから、
元々のサイズを元にどんな解像度やアスペクト比がきても
ドットを崩さずにスケーリングできるようにしたものです。
詳しくは添付説明書に書きました。

描画スケーリング モジュール for HSP3Dish
Version 1.1

http はこちら
http://miecat.com/soft/arc/mod_scaling_101.zip
https はこちら
https://miecat.com/soft/arc/mod_scaling_101.zip

> ・ドットバイドット (勝手にスケーリングされない状態)
> かつ
> ・X 方向、Y 方向ともに最大値
> の状態でアプリを起動し、
> 多くの情報量を表示できるアプリが作れないか、
> と思った次第です。

これは可能です。
ただし、独自でスケーリングする必要があります。
私の CoinFZ が近いかもしれません。
(どんなアス比がきても空白なく表示できます)
CoinFZ for Android
https://play.google.com/store/apps/details?id=com.miecat.coinfz

ちなみに、、、
ドットバイドットで実行時の解像度が高ければその分レイアウトを広くとる等の処理は可能ですが、
最近のスマホの5インチ程度の画面サイズで2K4K解像度でこれをやってしまうと小さくて何も見えなくなると思われるので、やはりスケーリングは必要です。
PC環境であれば画面が広いという認識で書けるんですけどね。

まためんどーなことを言い出しました。
------------------
Android 13 をターゲットとするアプリをリリースする場合は、広告 ID の申告を完了する必要があります

この申告は、Google Play Console で安全保護対策を提供するために使用します。Android 13 をターゲットとするリリースを作成する場合は、広告 ID の申告フォームに必ずご記入ください。
API レベル 33（Android 13）以降をターゲットとし、広告 ID を使用するアプリについては、そのアプリの AndroidManifest.xml で標準の権限 com.google.android.gms.permission.AD_ID を宣言する必要があります。これにより、広告 ID がゼロに設定されることを防ぎます。マニフェスト ファイルでこの権限を宣言していない場合、またはライブラリ マニフェストにこの権限が含まれない SDK を使用する場合、広告や分析のユースケースに影響することがあります。


参考：
https://support.google.com/googleplay/android-developer/answer/6048248


ポリシーに関する要件
Google Play デベロッパー プログラム ポリシーに基づき、Google Play にアップロードするすべてのアップデートと新しいアプリは、広告目的の場合にデバイス ID ではなく広告 ID を使用することが必要になります。


最悪です。すこしいろいろと試してみます。

ADmobを使っているなら大丈夫そうです。
標準状態でビルドした「App Bundle」ファイルの権限に
com.google.android.gms.permission.AD_ID　が宣言されています。

参考：
PisukeCode - Web開発まとめ
【Android開発】”Declare your Ad ID permission” への対処法
https://pisuke-code.com/android-declare-ad-id-permission/


あとは広告IDを収集しているという文言をプライバシーポリシーに追加してみる。

参考：
Web備忘録
Android 広告 ID の使用ポリシー違反でアプリが削除されたので対応する
https://webbibouroku.com/Blog/Article/android-privacy-policy

基本的には「申告」と「プライバシーポリシー」の変更ですが
これだけ行ってみて様子を見てみます。

しまくろねこさんの意見残してくれたらよかったのに（笑

データ セーフティでの記入参考：
くものすさん
https://kingmo.jp/kumonos/tips-googleplayconsole-datasafety-admob/

admob自動的に収集されるユーザープロパティ：
https://support.google.com/admob/answer/9755590?hl=ja


アプリは対象になる種類のユーザーデータを収集または共有しますか？　はい
アプリで収集するユーザーデータはすべて、転送時に暗号化されますか？　はい
自分のデータの削除をリクエストする方法をユーザーに提供していますか？　いいえ

（ドコモのアプリのポリシーあたりには広告ＩＤのリセット、拒否の方法を載せてるのもありました）

お客様のアプリは （略）の認証を認定ラボから受けていますか？　いいえ

-------------------------
位置情報-おおよその現在地 チェック　　国のデータを取得している
個人情報-その他の情報　（性別を取得しているようです
アプリの情報、パフォーマンス-
　　クラッシュログ、診断情報　（チェックする
　　その他のアプリのパフォーマンス データ（チェックする　しなくてもよい？
デバイスまたはその他の ID　（チェックする

------------
・収集と共有（チェック
・一時的に処理
・データ収集は必須
・分析、広告、不正防止　（共有のほうも
-----

ゆるく申請するよりは厳しく申請した方がよさそうですが、
こんな感じでどううなんでしょうか。これで申請してみます。

>きせんさん

消してしまってすみません。
もしかしたら関係ないかと思って消しました。

一応、念のため今開発してるゲームには起動時にプライバシーポリシーを表示するようにしました。


https://support.google.com/googleplay/android-developer/answer/10144311

ポリシー ＞ センタープライバシー、詐欺、デバイスの不正使用 ＞ ユーザーデータ

ユーザーデータ

〜省略〜

認識しやすい開示と同意の要件

〜省略〜

データの収集、使用、共有について、アプリ内で開示する必要があります。アプリ内での開示に関する要件は次のとおりです。

・アプリ内で開示すること。アプリの説明文やウェブサイトでの開示だけでは不十分です。
・アプリの通常使用時に表示すること。表示するのにメニューや設定に移動する必要のある開示方法では不十分です。
・アクセスまたは収集するデータの種類について説明すること。
・データをどのように使用、共有するかについて説明すること。
・掲載場所を、プライバシー ポリシーや利用規約のみとしないこと。
・個人情報や機密情報の収集に関係のない他の開示の中に掲載しないこと。

AdMob いろいろ面倒なことになってますよね。
APIが古いままだとマニュフェストに記載しておいてもダメでしたー。
強制的に最新版にするようにGoogleが誘導してるんですよ。
しかし諸事情で上げられないケースもあるんで、新しいAPIに合わせて
ソースを大幅に修正しなくてはならないケースもありそうです。

次のアップデートでは強制的に最新版のHSPを使うしかなさそう。
うちは諸事情で旧バージョンを使う必要があったんで見直さないとならない。

プライバシーポリシーですが、広告についてはグーグルのページへのリンクを貼って
そちらを読んでくださいで済ましてますｗ
あとは、うちのアプリでは特に個人情報の収集や利用はしていないので
その旨を記載しているだけで済ましてます。

データセーフティは上のほうで書いたとおりやってあります。

なんかグーグルから対応できてないよー？みたいなメールはきてたんですが、
Google Play Console で最新版の権限を見ると

com.google.android.gms.permission.AD_ID

あります。うちは自分で手動で書いたんですが。
問題ないのかなー？ そもそもまだAPI-33をターゲットにしていないので
必須の作業ではなさそうなんですが。
いまのところ、Android 9〜12では広告も表示されてますし、
収益も一時期よりは低下してますが入ってきています。
(テレワークが増えると収益が上がるんで、それの関係かもしれない)

プライバシーポリシーについては初回起動時にアプリ内で表示して
同意を得たほうがよさそうな感じですね。
次回リリース時にうちも実装しようと思います。

アプリでも参照や画面開いたときにＯＫ押すパターンになるんですかね。
私も次回あたりからアプリでも表示できるように変更します。

この問題ってadmobがユーザー情報をぬかなきゃ問題ない話なのがウケますよね
admobを使うから、admobのためにやってる行動ですよね。


収益も一時期よりは低下してますが」ってありますけど、
ほとんど使用者変わっていないのに、5月くらいから7〜8割くらいに急激に減ってます。

減った状態で安定してます（笑

やはり5月あたりから減りましたよね。全く同じです。
疑うときりがないんですが、
収益低下も操作してるだけなんじゃないのー？ と思ったりしちゃいます。

仕様コロコロ変えすぎなんですよ。しかも押し付けが酷い。
本来こんなことに振り回されるのは本質じゃないと思うんですがね。
そろそろあの会社も天狗になってきたように感じます。

４つほどデータセーフティと13対応の変更をしたのですが二日前から売上が戻りました。
今回の件が原因かどうかの判断は難しいですが。

うちはアプリ側は何もいじってないですが、
うちもここ数日はちょくちょく戻ってます。
クレームでもきてなんか設定変えたかな？（妄想です）
たまに一気に入ってくるように見えることがあるので
よくわからないんですよねこれ。

上記で一時的に回復したように見えたんですが、やはり同じみたいｗ
アプリ更新は関係あると思われます、更新するとアクセス増えるんで。
…恐らく収益目的のアプリではマーケティング的には特に更新ネタが
なくても更新することでアクセス稼ごうとしてると思います。
(更新しないアプリは金を渡さない仕組みだな。

Android 13について動作確認できたので一応報告。
特にアプリ更新はしていませんが、AdMobも表示されてます。
ただ、正常に報酬に反映されてるのかは確証ない。

他スレで報告してきたダイアログがおかしい場合がある件については
なんかしらんけど13では直ってます。
OSの不具合だったのかな。

ベータ版になってからビルドするまでのファイル構成など
自動でダウンロードしてくれて大分簡単になったのですが、
アプリをandroidへ送り、実機で起動したとき、
起動するまでに、画面が黒いまま待たされる時間って結構ながくないですか？

どこで時間がかかっているのか、検証したところ、
最短でLoading表示しても、プログラムが始まる以前での処理で
時間がかかっていることが判明しました。

みなさんのアプリは大丈夫ですか？
私のビルドするファイル構成の違いなのでしょうか。

ＷＥＢ上での、動作速度がＰＣ上と同期するようになれば、うれしいのですが・・・

> きせんさん

こんにちは。

3.7β4で開発していますが、実機(Android 9, 13)で起動させていますが、起動するまでの時間はまったくかかっていません。
Androidホームでアイコンをタップしたら直ぐにアプリが起動します。

>しまくろねこ(本物)さん

こんにちは。
ありがとうございます。
javaは何をお使いですか？

少な目のプログラムだと起動が速いですね。
どこに問題があるのかな。少し調べてみます。

> きせんさん
> javaは何をお使いですか？

https://www.oracle.com/java/technologies/javase/jdk17-archive-downloads.html
の
JDK 17.0.2
を使ってます。

私自身のアプリですが、

■PIYOKO DEFENSE（AABファイルサイズ：約42MB）
　https://play.google.com/store/apps/details?id=com.simakuroneko.piyoko_defense

■ミニマムぼうけん（AABファイルサイズ：約23MB）
　https://play.google.com/store/apps/details?id=com.simakuroneko.minibou_2

の規模で起動は一瞬です。


> 少な目のプログラムだと起動が速いですね。

プログラム先頭などで初期化処理等で大量のループ処理をしているとかはないですか？

>しまくろねこ(本物)さん

ありがとうございます。

#include "hsp3dish.as"
	color 0,0,0 : boxf
	color 250,250,250
	pos ginfo(26)/2-50,ginfo(27)/2
	mes "LOADING"
	redraw 1 : redraw 0

↑上記でも起動に（LOADNIGが表示されるまで）時間がかかるんですよね。
もちろん既存のプログラムの前に追加してみてですけど。

redraw 0 の位置がちょっとおかしいので、勝手に手直しさせてもらいました。
下記ソースでAndroid実機で動かしてみましたが、起動して"LOADING"表示、ダイアログ表示されるのは一瞬でした。

#include "hsp3dish.as"
	redraw 0
	color 0, 0, 0 : boxf
	color 250, 250, 250
	pos ginfo(26) / 2 - 50, ginfo(27) / 2
	mes "LOADING"
	redraw 1
	dialog "OK"

上記ソース以外でもAndroid実機で起動からプログラム開始まで時間のかかるソースってありますか？

>しまくろねこ(本物)さん

ありがとうございます。
redraw　0　でも、実行されるたびに実機では、
描画されるような動作かありましたので、
不具合防止のためそうしています。

調べてみます。

Android実機ですが、結構「その環境でしか起こらない」ような不具合に遭遇しますので
最低でも2台、違うAndroidバージョンの端末を用意してテストすることをおすすめします。
コストかかりますが、中古スマホなんて4000円ですよ。。（私のメインこれですし）

なので、おにたまさんに報告しても、おにたまさん環境で再現しないまま放置されてるのもあります。

起動時に時間がかかるのは、もしかしたらアンチウイルスのスキャンかもしれませんし（DishアプリだけというならDishの問題かもしれませんが）。
私の環境でも以前の古い端末では起動にそこそこ時間がかかってましたが、いまは一瞬ですね。Android 9 ですが。

>窓月ららさん

ありがとうございます。
私も念のため、古い機種でもテストをしています。
正直な話「おなじソースのプログラムをビルド」して、
ベータ以前のビルドと、ベータ版でビルドした場合とで
起動まで時間がかかっているのです。

>起動時に時間がかかるのは、もしかしたらアンチウイルスのスキャンかもしれませんし
これは可能性として高そうです。一回目の起動はあきらかに起動が遅いです。

いずれにしても、LOADINGでredraw 1で表示される以前までに時間がかかっています。


ちなみに実機での　redraw 0　の処理おかしくないですか？
redraw 1 : redraw 0　と並べることで不具合消してますけど。
ベータでは違うのかな？
同じ処理で回避しているのでベータでおかしい処理なのかは分かりませんけど。

ソース用意してみます

やはりredrawの処理がおかしい気がします。

#include "hsp3dish.as"

	dialog "ok"

	_phcount++		;phase1====
	color $ff,$00,$00	:	boxf
	gosub *sub01
	redraw 0
	wait 100

	_phcount++		;phase2====
	color $00,$00,$ff	:	boxf
	gosub *sub01
	redraw 1
	wait 100

	redraw 0
	_phcount++		;phase3====
	color $00,$ff,$00	:	boxf
	gosub *sub01
	redraw 0
	wait 100

	_phcount++		;phase4====
	color $ff,$00,$00	:	boxf
	gosub *sub01
	redraw 1 : redraw 0
	wait 100

	_phcount++		;phase5====
	color $ff,$ff,$00	:	boxf
	gosub *sub01
	wait 100

	_phcount++		;phase6====
	color $ff,$00,$ff	:	boxf
	gosub *sub01
	redraw 1
	wait 100
	stop
	
*sub01
	pos ginfo(26)/2-50,ginfo(27)/2	:	color $ff,$ff,$ff : mes "phase "+_phcount
	return

フェーズ１はディフォルト、フェーズ３は表示されてはいけない処理のはずです。
フェーズ５は表示されません。
redraw 0　を実行した時に、”描画してから描画しない処理”になっています。
「redraw 1 : redraw 0」という記述にしないと描画してチラつきますので注意が必要です。

> きせんさん
> フェーズ３は表示されてはいけない処理のはずです。
> フェーズ５は表示されません。

確かにフェーズ３はredraw 0で画面更新停止中のはずなのに表示されてますね。
どうもredraw 0を実行してそれ以降でまだredraw 0を実行されるとredraw 1扱いになるみたいな感じですね。（下記テストソース）
「HSP3.7に向けたβテストについてのお願い(続)」スレに報告することを望みます。

// ----------------------------------------------------
// redraw 1が無いのに表示されてしまうテストソース
// ----------------------------------------------------
#include "hsp3dish.as"

	setcls CLSMODE_SOLID, $000000

	redraw 0

	color 255, 0, 0
	pos 0, 0
	mes "12345"

	redraw 0 //この行をコメントアウトすると"12345"は表示されない

	stop

ちなみにNO.97568のテストソースはAndroid(13)実機で一瞬で起動されましたのでご報告を。

>しまくろねこさん

ありがとうございます。

#include "hsp3dish.as"
	;========================================
	;sample\game\　の　cardbg.png を使います
	;========================================
	sdim _mes,256
	_mes="LOADING"	:	gosub *sub01
	
	repeat 50
		_count=ginfo_newid
		celload "cardbg.png",_count
	loop
	_mes="LOADING."	:	gosub *sub01

	dialog "ok"

	_mes="ok"	:	gosub *sub01
	stop

*sub01
	color $00,$00,$00 : boxf
	color $ff,$ff,$ff
	pos ginfo(26)/2-50,ginfo(27)/2
	mes ""+_mes
	redraw 1 : redraw 0

	return

50枚のcardbg.pngを読みこんでみましたが、この状態でもLOADNIGが表示されるのは一瞬ですか？
私の実機では黒い画面が2秒ほど表示されてから、LOADINGが表示されます。

> きせんさん
> 50枚のcardbg.pngを読みこんでみましたが、この状態でもLOADNIGが表示されるのは一瞬ですか？
> 私の実機では黒い画面が2秒ほど表示されてから、LOADINGが表示されます。

Android実機で試してみましたが、起動直後すぐに最初の１回だけ"LOADING"の文字が一瞬見えましたが、２回目以降は"LOADING"の文字が表示されませんでした。（redraw 1→0の順で処理しているので）
それでもAndroid実機でも"LOADING"の文字は起動後に一瞬で表示されます。

ちなみに私のAndroid実機にはアンチウィルスアプリは入れていません。

>しまくろねこさん

ありがとうございます。
２回目の"LOADING"はすぐダイアログになりますので解らないですね。
ありがとうございました。すこし構成ファイルなどをみてみます。

すこし気になっていましたが、ディスプレイサイズより
大きいウィンドウサイズでプログラムを起動すると、
画像の表示が狂っているような気がします。
このあたりの不具合がアンドロイドでの座標狂いの原因なのでしょうか。

うまく動くソースができるかな？

ディスプレーサイズ内にウィンドウ収まる範囲であれば問題はおこりませんが、
ディスプレーサイズより大きいと表示が歪みます。

#include "hsp3dish.as"
	;==========================
	;hsp3dish.ini を用意します。
	;wx=600
	;wy=600	;ディスプレーサイズより大きくする
	;==========================

	redraw 0
	dim _point,10
	_point(1)=100
	_point(2)=100
	_point(3)=ginfo(26)/2
	_point(4)=ginfo(27)/2

*main01
	gosub *sub01	;タッチ位置を取得する
	
	color $00,$00,$00	:	boxf

	color $ff,$ff,$ff
	line _point(1),_point(2),_point(3),_point(4)
	pos _point(1),_point(2)	:	mes ""+_point(1)+","+_point(2)	;終点
	pos _point(3),_point(4)	:	mes ""+_point(3)+","+_point(4)	;始点

	;ドラッグ位置
	line _mtinfodata(1)-5,_mtinfodata(2)-5,_mtinfodata(1)+5,_mtinfodata(2)+5
	line _mtinfodata(1)+5,_mtinfodata(2)-5,_mtinfodata(1)-5,_mtinfodata(2)+5
	pos _mtinfodata(1),_mtinfodata(2)	:	 mes ""+_mtinfodata(1)+","+_mtinfodata(2)

	pos 0,0	:	mes "mousepos("+mousex+","+mousey+")="+_mtinfodata(1)+","+_mtinfodata(2)
	wait 1
	redraw 1:redraw 0
	goto *main01
	
*sub01
	dim _mtinfodata,5
	mtlist _mtlistid
	mtinfo _touch
	_mtinfodata(1)=_touch(1)	;x位置
	_mtinfodata(2)=_touch(2)	;y位置
	return

wy=600を1500や2000などにしてみてください。ディスプレーサイズより大きければOKです。

>きせんさん
本当ですね。画面全体が歪んでますね。

私は viewcalc 命令で画面サイズに自動的に合うようにリサイズするようにしています。

#include "hsp3dish.as"

#const SCREEN_WIDTH_SIZE				720
#const SCREEN_HEIGHT_SIZE				1280
#const SCREEN_HEIGHT_MINUS				140

#module
;---------- zoomxy(元の横大きさ, 元の縦大きさ, 変更したい横大きさ)
#defcfunc zoomxy int moto_x, int moto_y, int henkou_x

	return (henkou_x * 1000 / moto_x) * moto_y / 1000

;---------- zoomyx(元の横大きさ, 元の縦大きさ, 変更したい縦大きさ)
#defcfunc zoomyx int moto_x, int moto_y, int henkou_y

	return (henkou_y * 1000 / moto_y) * moto_x / 1000

#global


	plat_form = PLATFORM_WINDOWS
	getreq plat_form, SYSREQ_PLATFORM

	if plat_form == PLATFORM_WINDOWS {

		if ginfo_dispx > ginfo_dispy {
			display_size = ginfo_dispx - SCREEN_HEIGHT_MINUS
		} else {
			display_size = ginfo_dispy - SCREEN_HEIGHT_MINUS
		}

		window_size_width			= SCREEN_WIDTH_SIZE
		window_size_height			= SCREEN_HEIGHT_SIZE
		window_size_change_width	= display_size
		window_size_y				= zoomxy(window_size_width, window_size_height, window_size_change_width)
		window_size_x				= zoomyx(window_size_width, window_size_height, window_size_y)

		if window_size_y > ginfo_dispy {
			display_size			= ginfo_dispy - SCREEN_HEIGHT_MINUS
			window_size_change_h	= display_size
			window_size_x			= zoomyx(window_size_width, window_size_height, window_size_change_h)
			window_size_y			= zoomxy(window_size_width, window_size_height, window_size_x)
		}

		screen 0, window_size_x, window_size_y, 0, (ginfo_dispx - window_size_x) / 2, (ginfo_dispy - window_size_y) / 2 - 25
		scale_x	= double(window_size_x) / double(window_size_width)
		scale_y	= double(window_size_y) / double(window_size_height)

		viewcalc vptype_2d, scale_x, scale_y
	}

>しまくろねこさん

これはいいですね。
ディスプレーが小さくてもアンドロイドアプリのテストができそうです。

けど歪みがandroid実機でのタップしたポイントになるのか、ならないのかがまだ解りません。
ポイント指定の、計算ミスなら改善可能ですが、歪みがでるとお手上げです。

歪みの特性と傾向を特定して修正するしかありません。



HSPが悪いわけでは100%ないと理解した上で書けば、

windowsでうまく動いても、androidのバージョンと画面サイズで
windows上でテストしたようにうまくいくか解らないですよね。
多様性のandroid上でかつ、機種やandroidのバージョンで、
ここ部分まで画面サイズに入るの？ってこともありますし。


16:9 あたりの画面に合わせて作り、autoscaleするか、
21:9 あたりの画面に合わせて作り、16:9まで圧縮するか、

21:9　で作って、横固定にして、16:9の範囲のみ使うか←　個人的にはこれがベストな気がします

> きせんさん

NO.97579のソースは、あくまでWindows上だけで動作するソースです。Android上では動作しません。
例えば、ウィンドウの幅:720, ウィンドウの高さ:1280 としてアプリを開発しようとしたときに、PCの解像度が 1920x1080 などの時、ウィンドウの高さが足りない場合、このソースのではウィンドウの高さを 1080 - 140 = 940 にしてウィンドウを表示します。
また、 viewcalc 命令でソース内で記述する pos 命令/その他描画命令等は自動的に自動拡大縮小されて処理されます。 タップされた位置も同様です。
なので特に意識することなく、アプリを開発できます。

> けど歪みがandroid実機でのタップしたポイントになるのか、ならないのかがまだ解りません。
> ポイント指定の、計算ミスなら改善可能ですが、歪みがでるとお手上げです。

viewcalc 命令で自動拡大縮小するのでウィンドウ内の表示は多少歪みは発生します。

> 16:9 あたりの画面に合わせて作り、autoscaleするか、
> 21:9 あたりの画面に合わせて作り、16:9まで圧縮するか、

これは個人差があるのでなんとも言えません。
私の場合は、単純にWindows上の画面比率で開発したものをそのままAndroidではautoscaleしています。
表示される画像等に少々の歪みが発生することもありますが、ゲームの出来や操作性に影響があるわけではないので、あまり気にしていません。

また、窓月ららさんが出しているスケーリングモジュールを出しているのでこちらを参考にしてみてはいかがでしょうか？

> 独自スケーリングモジュールを公開します。HSP3Dish Android版向けです。
> 先に公開したサンプルをモジュール化して gcopy gzoom grotate の互換命令を追加したものになります。
> readme.txt をお読みください。
>
> 描画スケーリング モジュール for HSP3Dish
> Version 1.1
>
> http はこちら
> http://miecat.com/soft/arc/mod_scaling_101.zip
> https はこちら
> https://miecat.com/soft/arc/mod_scaling_101.zip
>
> こちらを今年のHSPプログラムコンテストに出品する予定です。
> 先に公開したサンプルは削除しましたのでリンク切れになっています。

>しまくろねこさん

ありがとうございます。

NO.97579のソースだとウィンドウサイズが拡大されるだけになってしまうので修正しました。
指定したウィンドウサイズが解像度未満の場合はそのままにしました。

あ、あと名前が「しまくろねこ(本物)」になっていなかったので修正です。

//---------------------------------------------------------------------------------------------------------
// ディスプレイの解像度よりも、指定したウィンドウサイズのほうが大きい場合、ウィンドウサイズを自動調整する
// ディスプレイの解像度よりも、指定したウィンドウサイズのほうが小さい場合、ウィンドウサイズはそのまま
//---------------------------------------------------------------------------------------------------------

#include "hsp3dish.as"

#const SCREEN_WIDTH_SIZE	800 ; ウィンドウの横サイズ
#const SCREEN_HEIGHT_SIZE	480 ; ウィンドウの縦サイズ
#const SCREEN_HEIGHT_MINUS	140 ; ウィンドウサイズを自動調節で大きくした場合、タイトルバー等分をマイナスする

#module
;---------- zoomxy(元の横大きさ, 元の縦大きさ, 変更したい横大きさ)
#defcfunc zoomxy int moto_x, int moto_y, int henkou_x

	return (henkou_x * 1000 / moto_x) * moto_y / 1000

;---------- zoomyx(元の横大きさ, 元の縦大きさ, 変更したい縦大きさ)
#defcfunc zoomyx int moto_x, int moto_y, int henkou_y

	return (henkou_y * 1000 / moto_y) * moto_x / 1000

#global


	plat_form = PLATFORM_WINDOWS
	getreq plat_form, SYSREQ_PLATFORM

	if plat_form == PLATFORM_WINDOWS {

		if (ginfo_dispx < SCREEN_WIDTH_SIZE) || (ginfo_dispy < SCREEN_HEIGHT_SIZE) {
			; ディスプレイの解像度よりも、指定したウィンドウサイズのほうが大きい場合、ウィンドウサイズを自動調整する
			if ginfo_dispx > ginfo_dispy {
				display_size = ginfo_dispx - SCREEN_HEIGHT_MINUS
			} else {
				display_size = ginfo_dispy - SCREEN_HEIGHT_MINUS
			}

			window_size_width		= SCREEN_WIDTH_SIZE
			window_size_height		= SCREEN_HEIGHT_SIZE
			window_size_change_width	= display_size
			window_size_y			= zoomxy(window_size_width, window_size_height, window_size_change_width)
			window_size_x			= zoomyx(window_size_width, window_size_height, window_size_y)

			if window_size_y > ginfo_dispy {
				display_size		= ginfo_dispy - SCREEN_HEIGHT_MINUS
				window_size_change_h	= display_size
				window_size_x		= zoomyx(window_size_width, window_size_height, window_size_change_h)
				window_size_y		= zoomxy(window_size_width, window_size_height, window_size_x)
			}

			screen 0, window_size_x, window_size_y, 0, (ginfo_dispx - window_size_x) / 2, (ginfo_dispy - window_size_y) / 2
			scale_x	= double(window_size_x) / double(window_size_width)
			scale_y	= double(window_size_y) / double(window_size_height)

			viewcalc vptype_2d, scale_x, scale_y
	
		} else {
			; ディスプレイの解像度よりも、指定したウィンドウサイズのほうが小さい場合、ウィンドウサイズはそのまま
			screen 0, SCREEN_WIDTH_SIZE, SCREEN_HEIGHT_SIZE, 0, (ginfo_dispx / 2) - (SCREEN_WIDTH_SIZE / 2), (ginfo_dispy / 2) - (SCREEN_HEIGHT_SIZE / 2)

		}

	}

>しまくろねこ(本物)さん

私の持ち運びできるサブパソコンだと、ディスプレーが小さいので
このプログラムは本当に助かりますね。たまにwindowsの画面の設定で横にしていたので（笑

#include　するだけで使えるモジュールも共有できたら、
他の方もandroidアプリを作成するキッカケになるかもしれませんね。

私もある程度、システム的な動きのものを共有化していますが、

やはり、

マルチタップ　mtlist系命令の10点程度のポイントの把握
マルチタップ、2点間の前と後のズーム
ドラッグして離した時のスクロール幅（勢いによって大きく動く）

この部分をモジュール化するだけでも、
androidでのアプリ開発の敷居がかなり下がる気がします。

> きせんさん
> #include　するだけで使えるモジュールも共有できたら、
> 他の方もandroidアプリを作成するキッカケになるかもしれませんね。

言われてモジュール化してもいいのかと思いました。
毎回、ゲームを作る際にコピペして使いまわしてましたので気が付きませんでした。


> マルチタップ　mtlist系命令の10点程度のポイントの把握
> マルチタップ、2点間の前と後のズーム
> ドラッグして離した時のスクロール幅（勢いによって大きく動く）
>
> この部分をモジュール化するだけでも、
> androidでのアプリ開発の敷居がかなり下がる気がします。

Dish向けのタップ等取得モジュールで「mod_smart.as」というのを公開しているのですが、ピンチイン/アウトを取得する機能はつけています。
「マルチタップ　mtlist系命令の10点程度のポイントの把握」については標準機能(mtinfo命令)ですでにあるのでモジュール化するべきか迷います。
「ドラッグして離した時のスクロール幅（勢いによって大きく動く）」については、過去のバージョンの「mod_smart.as」についていた機能ですが、スマホと完全に同じ動作を取得できないため泣く泣く機能を削除しました。

>しまくろねこ(本物)さん

(mtinfo命令)でも、タップ指分の処理は必要です。
サンプルがかなり良いです。私もほぼコピーですが、
モジュール化したほうが解りやすいです。

個人的にはタップを続けた場合はスクロール、
すぐに離した場合、且つ、タップ位置からのズレが±10ていどでタップ判定しています。

離した時の勢いでスクロールする部分はつくってありますが、
他の人にみせるほど整理してないですね。

ピンチイン/アウト私もつけていますが、上手にやらないと
（指でタップした二点の中心にして）ズームイン、アウトしないとそれっぽくないんですよね。
画像の拡大幅も違和感あるようだといけないので。

>しまくろねこ(本物)さん

NO.97597のモジュールですが、
元のスクリーンサイズが500, 変更後が 250に変更された前提で話をすると、

変更後ディフォルトのboxfで塗りつぶすと、
新しく変更されたスクリーンサイズ、すなわち250で塗りつぶそうとしますが、
座標自体は元の大きいサイズで考えていますので、
boxf 0,0,250,250 で塗りつぶしたことになり、変更された画面での500ではなく、
250までしか塗られないことになります。ginfoなどでの取得したサイズも同様です。

解っていれば回避できることではありますが。

> きせんさん

スクリーン自動縮小を今モジュール化していますが、viewcalc命令が適用されると、boxfの値省略が効かないみたいなんですね。
下記で確認できると思います。

#include "hsp3dish.as"

;-----------------------------------------------------
; 
; HSP3.x Dish用スクリーンモジュール「mod_screen.as」
;
; Windows版のDishで有効です
;
; ディスプレイの解像度よりも、指定したウィンドウサイズのほうが大きい場合、ウィンドウサイズを自動調整する
; ディスプレイの解像度よりも、指定したウィンドウサイズのほうが小さい場合、ウィンドウサイズはそのまま
;
; Ver 0.1 (※注意：事前に「hsp3dish.as」をインクルードしてください)
;
; By. しまくろねこ
;
; https://sites.google.com/site/simakuroneko/
; http://simakuroneko.bbs.fc2.com/
; simakuroneko@gmail.com
;
;-----------------------------------------------------
#ifndef __MOD_SCREEN__
#define __MOD_SCREEN__


#module mod_screen

;----------------------------------------------------- 
; zoomxy(元の横大きさ, 元の縦大きさ, 変更したい横大きさ)
;----------------------------------------------------- 
#defcfunc local zoomxy int moto_x, int moto_y, int henkou_x

	return (henkou_x * 1000 / moto_x) * moto_y / 1000

;----------------------------------------------------- 
; zoomyx(元の横大きさ, 元の縦大きさ, 変更したい縦大きさ)
;----------------------------------------------------- 
#defcfunc local zoomyx int moto_x, int moto_y, int henkou_y

	return (henkou_y * 1000 / moto_y) * moto_x / 1000

;----------------------------------------------------- 
; screen_resize ウィンドウの横サイズ, ウィンドウの縦サイズ, ウィンドウサイズを自動縮小された場合に横にマイナスする値, ウィンドウサイズを自動縮小された場合に縦にマイナスする値
;----------------------------------------------------- 
#deffunc screen_resize int screen_width_size, int screen_height_size, int screen_width_minus, int screen_height_minus

	plat_form = PLATFORM_WINDOWS
	getreq plat_form, SYSREQ_PLATFORM

	if plat_form == PLATFORM_WINDOWS {

		if (ginfo_dispx < screen_width_size) || (ginfo_dispy < screen_height_size) {
			; ディスプレイの解像度よりも、指定したウィンドウサイズのほうが大きい場合、ウィンドウサイズを自動縮小する
			window_size_change_width	= ginfo_dispx - screen_width_minus
			window_size_change_height	= ginfo_dispy - screen_height_minus
			window_size_y				= zoomxy@mod_screen(screen_width_size, screen_height_size, window_size_change_width)
			window_size_x				= zoomyx@mod_screen(screen_width_size, screen_height_size, window_size_change_height)
			
			if window_size_x > ginfo_dispx {
				window_size_change_width	= ginfo_dispx - screen_width_minus
				window_size_y				= zoomxy@mod_screen(screen_width_size, screen_height_size, window_size_change_width)
				window_size_x				= zoomyx@mod_screen(screen_width_size, screen_height_size, window_size_y)
			}

			if window_size_y > ginfo_dispy {
				window_size_change_height	= ginfo_dispy - screen_height_minus
				window_size_x				= zoomyx@mod_screen(screen_width_size, screen_height_size, window_size_change_height)
				window_size_y				= zoomxy@mod_screen(screen_width_size, screen_height_size, window_size_x)
			}

			screen 0, window_size_x, window_size_y, 0, (ginfo_dispx - window_size_x) / 2, (ginfo_dispy - window_size_y) / 2
			scale_x	= double(window_size_x) / double(screen_width_size)
			scale_y	= double(window_size_y) / double(screen_height_size)

			; 描画時の座標変換を設定
			viewcalc vptype_2d, scale_x, scale_y
	
		} else {
			; ディスプレイの解像度よりも、指定したウィンドウサイズのほうが小さい場合、ウィンドウサイズはそのまま
			screen 0, screen_width_size, screen_height_size, 0, (ginfo_dispx / 2) - (screen_width_size / 2), (ginfo_dispy / 2) - (screen_height_size / 2)

		}

	}

	return

#global



; 横幅:1080
; 縦幅:2340
; ディスプレイ解像度の横幅よりも指定した横幅(1080)が大きい場合にリサイズされたときに横幅をマイナスする値
; ディスプレイ解像度の縦幅よりも指定した縦幅(2340)が大きい場合にリサイズされたときに縦幅をマイナスする値
screen_resize 1080, 2340, 0, 150

redraw 0
color 0, 0, 255 : boxf
color 255, 0, 0 : circle 0, 0, 1079, 2339
redraw 1

stop

>しまくろねこ(本物)さん

あたらしく生成されたウィンドウサイズは当っていますから、
間違いかと言われれば、処理としては当っている気がします。

scale_xやscale_yを除算するのが早いかもしれません。

スクリーンを作り直さなければOKかな？(screen 0の部分を//する)と、思っていたら、

スクリーンが大きいと歪むのに該当した（笑

> きせんさん

screen 0の部分で、作成したいウィンドウサイズよりも実際のディスプレイサイズが小さい場合、ウィンドウサイズを指定のサイズの縦横の比率を保ったままのスクリーンが作成されます。
で、そのあとでviewcalc命令の部分で上記で作成されたスクリーンの大きさに合わせてスケーリングをするようにしています。
処理としては間違っていないと思います。（多分）

boxfの値を省略して描画すると全領域に描画されないのは、不具合だと思います。

>しまくろねこ(本物)さん

答えの出ないことを書き続けても意味がないのでこれで終わりにしますが、
ウィンドウサイズ(x)があり、xの中に常に縮小されたものが描画される場合、
どれだけ縮小したものを描画しても(x)のウインドウサイズは変わりません。

viewcalcで”描画時の座標変換を設定”してあるサイズを基準(x2)にしても、
ウィンドウサイズ(x)はかわりません。しかし取得した(x)は
描画の時に変換(x2に対するx)されているだけです。

zoomに座標がついているようなもので、座標変換しているだけですから、
処理は正しいように思えます。

ginfo(13)やginfo_winyなどの 画面の描画エリアYサイズを
viewcalcで描画変換した時に、変換後の数字を取得するように要望した方がいいかもしれません。

boxf命令で、(p3,p4)を省略した際に参考にする数字を、ginfo_winy等にしていただければ、
問題は解決するように思えます。

ginfo(12),ginfo(13),ginfo_winx,ginfo_winy　のみの変更です。
おそらく、boxfも改善されるはずです。

> きせんさん

> ginfo(13)やginfo_winyなどの 画面の描画エリアYサイズを
> viewcalcで描画変換した時に、変換後の数字を取得するように要望した方がいいかもしれません。
>
> boxf命令で、(p3,p4)を省略した際に参考にする数字を、ginfo_winy等にしていただければ、
> 問題は解決するように思えます。
>
> ginfo(12),ginfo(13),ginfo_winx,ginfo_winy　のみの変更です。
> おそらく、boxfも改善されるはずです。

簡単にですが報告済みです。
https://hsp.tv/play/pforum.php?mode=all&num=97612

マルチタッチを標準のmtlist/mtinfoからもう少し簡単にしたものをモジュール化(mod_smart.as Ver3.8)しました。
具体的な使い方は以下の通りです。

;--------------------------------------------------------------
; マルチタッチのサンプル
;--------------------------------------------------------------
#include "hsp3dish.as"		;HSP3Dish
#include "mod_smart.as"		;当モジュール

	smart_init

	touch_cnt = 0
	dim touch_info, 4

*main
	
	; 画面クリア
	redraw 0
	color 0, 0, 0 : boxf
	color 255, 255, 255

	; タッチされている数(ポイントID)を取得
	smart_mtcnt touch_cnt

	; タッチ情報を取得
	;
	; touch_info(0)		タッチ状態(1=ON, 0=OFF)
	; touch_info(1)		タッチされたX座標
	; touch_info(2)		タッチされたY座標
	; touch_info(3)		タッチ識別用ID

	; タッチされている数だけ情報を表示
	repeat touch_cnt
		smart_mtget touch_info, cnt
		pos cnt * 50, 0
		mes touch_info(0)
		mes touch_info(1)
		mes touch_info(2)
		mes touch_info(3)
	loop

	redraw 1
	wait 1

	goto *main

>しまくろねこ(本物)さん

コンテスト受賞おめでとうございます（笑）

> きせんさん

どうもありがとうございます。

私も来年がんばろっと

> きせんさん

継続は力なりです。
お互いがんばりましょう。
私も来年また頑張ります。