|
|
2020/1/18(Sat) 16:46:10|NO.89278
> hsp3utf.asは、GUI用のランタイムなのでそちらが優先されることになります。
了解です
個人的にプロンプトを多用していて
クリップボードから文字列を取って来て使ってるので
HSPでも作れるかを試させて貰ったんですが
仕様との事で、作成された時にでも移植させて貰います
何分
クリップボードからの取得だけはCUIで出来てるんですが
GUIが優先される処理を使わねば
文字列として使えませんでしたから
では
|
|
2020/1/18(Sat) 23:38:11|NO.89284
おにたまさん、ありがとうございます。
setreq命令による、フォント表示の切り替え、確認致しました。
「3.5」や「3.51」で作ったものでも、「setreq SYSREQ_USEGPBFONT,1」を書き加えるだけで、
「HSP3.6β2」でも、変らず表示されました。また、「HSP3.6β2」でならば、「font」命令の前で、
この命令で表示方法を指定すれば、その箇所その箇所で使い分けも出来ました。
日本語表示や太字/斜体にしたいところだけ「0」指定、それ以外は「1」指定、これでも十分
フォントの表現の幅が広がります。
「◎○〇●□■◇◆△▲▽▼⊿∴∵☆★彡←→↑↓⇒⇔↔≠≒.....」等のような記号から
「℃㍍粁㎞糎㎝粍㎜㎡㌶頁㌻瓩kgKg㌘瓱㎎㍑竓㏄斗.....」まで使えるのは、嬉しい限りです。
|
|
2020/1/20(Mon) 21:14:15|NO.89297
#packopt name "テスト1.2.3."
#packopt version "version.txt"
を実行すると
[ERROR] No.10
実行ファイルが見つかりません
Enterキーを押してください
とエラーがでるみたいです。
|
|
2020/1/21(Tue) 21:09:42|NO.89313
以前からですが、モジュール名とモジュール関数の引数の変数名が同じだと
変数の内容が正しくなりません。
自分の付けたモジュール名ならまだわかりますが、裏で付けられるm-だと
わからないので、せめてコンパイルエラーになると嬉しいです。
test "abc"
stop
#module
#deffunc test str m0
mes "["+m0+"]←正しい値[abc]が出ない"
return
#global
|
|
2020/1/22(Wed) 00:21:14|NO.89317
HSP3dish利用時に、以前はwindows用にウィンドウ位置を移動させるために
#include "hsp3dish.as"
buffer 1: picload "ball.png"
screen 0,,,,200,200
redraw 0
gcopy 1
redraw 1
のように、screen命令でウィンドウ位置を変更できていたのですが、
本β版で実行した場合、gcopy実行時に「パラメータの値が異常です」というエラーがでます。
screenではなくgsel 0の場合は動きました。
screen 0はダメでした。
デスクトップ全体のサイズが取得できるようになり、ウィンドウの中央寄せがしたかった層からの
需要が高いと思われますので、確認していただけると幸いです。
|
|
2020/1/23(Thu) 01:45:15|NO.89322
初めまして、いつもHSPを楽しく使用させていただいてます。
1)Window10->ディスプレイ設定->拡大縮小とレイアウトで100%以外を設定していると
screen 命令で作られるウインドウサイズが 標準とdish使用時で異なる
※100%だと一緒のサイズになります。
※こちらは仕様でしょうか?iniで指定していたときは一緒だったので気になりました。
2)dish使用時、gmode 6でブレンド率が反映されない
;#include "hsp3dish.as"; 使うととブレンド率が反映されない
screen 0,400,300
repeat
redraw 1: await 16: redraw 0: color 255,255,255: boxf
gmode 1: color 128,128,128: grect 200,200,0,200,200
color 255,0,0
gmode 5,,,t: grect 100,100,0,200,200
gmode 6,,,t: grect 300,100,0,200,200
t++: t\=255
loop
|
|
2020/1/23(Thu) 23:58:53|NO.89328
>kouさん
HSPの仕様ではなく、Windowsの仕様だと思いますよ。
HSPが高DPIに対応していないため、スケーリングされているだけかと。
|
|
2020/1/24(Fri) 12:28:58|NO.89330
>ゆうやんさん
ご指摘ありがとうございます。Windowsの仕様なのですね。
理解いたしました。
解凍した3.6β2フォルダの"hsp3dish.exe"のプロパティで、
高DPI設定が"高いDPIスケール動作をアプリケーションで上書きする"設定になってました。
チェックを外しましたら、標準でもdishでも同じウインドウサイズになりました。
以前のバージョンも確認したら、チェックが外れてましたので、
私がいつの間にか外していたのかもしれません。。。
原因が分り助かりました。
|
|
2020/1/27(Mon) 01:59:04|NO.89346
確認も兼ねた報告です
以下の処理を実行しても
Windowの背景色が「真っ白」なのですが
本来なら何色が表示されてるんですか?
3.51と3.6b2の両方で確認しました
希望として、DOSの様に「真っ黒」にしたくて
色々弄ってました
#include "hgimg3.as"
screen 0,640,480,0
hgini
clscolor $80
|
|
2020/1/27(Mon) 04:43:25|NO.89347
>HUNTERさん
描画が抜けてますね。
RとGが0なので、暗めの青色になります。
#include "hgimg3.as"
screen 0,640,480,0
hgini
clscolor $80
hgdraw
hgsync 10
|
|
2020/1/27(Mon) 13:14:16|NO.89348
いつものことながら、「hgimg4」についてです。
「gpbconv.exe」がバージョンアップされ、うれしく思いますが、どうも、変換がうまくいきません。
「3.6β1」付属のものでなら変換できる「fbx」ファイルが、今回のものでは、うんともすんとも
反応がありません。空白のログファイルが出来ただけでした。これで、3Dデータモデルの制作が
やりやすくなると思ったのですが。
「HSP3.6 新機能ハイライト」での解説は、簡単な紹介に終わっていて、実際のところどうやれば
いいのか、戸惑います。
「3.6β1」の時の「Unityとの連携」での、詳しい解説同様、初心者でも分かりやすい具体的な解説を
お願いできると助かります。基本的なモデルを例とした、簡便かつ具体的な使い方が知りたいです。
前のバージョンで、「Unityとの連携」でより複雑なアニメーションが使えるようになったことは、確かに
良いことと思いますが、以前から「gpbconv.exe」で躓くことの多かったものとしては、今度こそとの思いが
強いです。
これだけでどうにかなる訳でないのは、承知ですが。
|
|
2020/1/27(Mon) 14:27:44|NO.89349
あらやさん
> 描画が抜けてますね。
> RとGが0なので、暗めの青色になります。
有難う御座います
やっと確認出来ました
尚、Bugではない為
今回の分は消そうかと考えていますが
如何しましょうか?
では
|
|
2020/1/27(Mon) 19:35:36|NO.89351
「hsp3info」でリツイートされている、K-sさんが、
>6β2のHGIMG4のサンプル buffer.hsp で文字表示がおかしい
と、おっしゃっています。
HGIMG4の他のサンプルはどうかと、見てみましたが、表示はおかしくありません。
そこで、わざと
>font ""
を書き加えてみると、他のサンプルは、どれもみな文字サイズが小さくなります。
>font "",12
となっている、感じの大きさです。
そこで、「buffer.hsp」に
>font "",12
と、やってみると、書き加える前同様のおかしな表示になりますが、
「12」を「60」にしてみると、フォントの種類はちがいますが、
>setreq SYSREQ_USEGPBFONT,1
とした時とほぼ同じ大きさになりました。
|
|
2020/1/27(Mon) 23:01:32|NO.89352
>HUNTERさん
>Bugではない為
>今回の分は消そうかと考えていますが
>如何しましょうか?
あくまでも私個人の意見です。
確かにバグではなくこちらのスレッドの主旨とは違う内容でしたが、
『hgimg3の使い方が少々分かりにくい』という一種の報告・要望として
受け取ることも出来ますので消す必要はないかと。
ただ、今後は新規でスレッドを作成するなりして
一度どこか間違えていないか確認してから
バグだった場合にこちらで報告するという形を取ると良いと思います。
最後に、この私の意見もスレッドとは関係のない話になってしまい失礼いたしました。
|
|
2020/1/28(Tue) 21:16:33|NO.89355
β2版についての色々なご報告とご意見ありがとうございます。
HGIMG4のフォントについていくつか不具合の報告を頂いていますので、今後対応していきたいと考えています。
HGIMG3の報告など、不具合と直接関係ない場合でも書き込みは残しておいていただければ幸いです。
>さか さん
モジュール名とモジュール関数の引数の変数名につきまして、ご報告ありがとうございます。
今後のバージョンで何か対応したいと思います。
>Tsuyoshi さん
HSP3Dishでのscreen命令は、他のバッファも含めてウインドウ設定を初期化してしまうため、
頻繁に実行することは想定していませんので、screen命令の位置やサイズは最初に設定してから、他のバッファへ画像を読み込むなどの対応をしてもらえればと思います。
>アキアキノヒロロ さん
「gpbconv.exe」は新しいものになっていますが、fbxを変換するためのコマンドラインツール「gameplay-encoder.exe」は
β1から変更しておらず、出力される.gpbファイルの仕様にも変更はありません。
(gpbconv.exeは、内部でgameplay-encoder.exeを実行して変換しています)
なので何らかの理由でgameplay-encoder.exeが動作していないと思われます。
たとえば、sample/hgimg4/fbx/high_school_girl.fbxを変換した場合でも失敗するでしょうか。
現状まだまだ不親切な部分が多いので、詳しい解説については、今後のバージョンでも拡充していきたいと思います。
|
|
2020/1/29(Wed) 11:01:01|NO.89356
「gpbconv.exe」の件について、ご報告致します。
どうも、ダウンロードした「HSP」の展開先が関係しているようです。
「C」や「デスクトップ」に、そのまま解凍した「hsp36beta」付属の「gpbconv.exe」だと、変換に
成功しました。しかし、「β1」と区別しやすいように「hsp36beta」のフォルダ名を「hsp36b2=[01-18]」
に書換えたり、あるいは、「hsp36b2=[01-18]」という名前のフォルダに展開したりしたものでは、変換に
失敗しました。自分の場合は、これらにあたります。
「high_school_girl.fbx」だけでなく、「β1」の「gpbconv.exe」で変換できていた自前の「fbx」も
成功しました。ただし、「high_school_girl.fbx」では、「tga」を「png」に画像変換し、「material」を
手直ししました。「material」は、「gpbconv.exe」から書換えられました。
「hsp36beta」のフォルダのパスが関係しているんでしょうか。
お騒がせしました。
|
|
2020/1/29(Wed) 19:43:18|NO.89362
またバージョンアップですか、ありがとうございます。
2020年ということなので今年HSPにも革命が訪れるのでしょうか!!
...それは置いといて、前から気になっていたのですが、
HSP3.6からaxobjでエラーが発生して設置されません。
エラーダイアログすら表示されず、強制終了。どうにかなりませんかね...?(^^;
|
|
2020/1/29(Wed) 23:17:27|NO.89363
>アキアキノヒロロ さん
ご報告ありがとうございます。
ディレクトリ名やfbxのファイル名も含めて、スペースや特殊な記号が入っていると正しく処理されない可能性があります。改善していければと思います。
>Ponyo さん
HSP3.51で正しくaxobj命令が動作していなかったのを、HSP3.6βでは修正していました。
どのようなコードでエラーになるのか教えて頂けると助かります。
sample/comobj/web.hspなどでもだめでしょうか。
|
|
2020/1/30(Thu) 00:26:11|NO.89365
既に開発完了している「hgimg3」についての要望です。
直接描画命令であるhgrotate命令ですが、奇数サイズのコピーが出来ないのが不便です。
ゲームの使用例で言えば、エネルギーゲージやHPゲージなど、
1ドット単位でコピーサイズが変わるものは、奇数サイズのコピーが出来ないと大変不便です。
出来ましたら、grotate命令と同様に奇数サイズのコピーが出来るようにして頂きたいです。
もう1点、Windows10環境では、一部のDirectX8 APIが正常に動作しないとの事で、
垂直同期が正常に取れない状態です。
海外のサイトにある「DX8 to DX9 convertor」というプロキシDLLを導入すれば一応解決
するのですが、可能であれば導入せずにHSP3側で対応して頂けるとありがたいです。
垂直同期に関しては、DirectX8 APIを使用せずにDirectX9 APIを使用すれば解決するのでは
ないかと思うのですが、ご検討頂けると幸いです。
|
|
2020/1/30(Thu) 07:40:47|NO.89367
お返事ありがとうございます。
>sample/comobj/web.hspなどでもだめでしょうか。
はい。エラーメッセージが表示されず、強制終了してしまいます。
これは私のPCがおかしいのですかね...(^^;
詳しい原因はこちらからでは不明です。
|
|
2020/1/30(Thu) 07:49:34|NO.89368
再ダウンロードをしたら直りました。原因は不明ですが。
ご迷惑をおかけして申し訳ございません(^^;
|
|
2020/1/31(Fri) 00:41:15|NO.89377
stickキーの新機能拝見しました。
少し気になったのですが、ZXC…ときて「V」キーまで入れることはできなかったのでしょうか?
ZXCVキーで1セットと、なんとなくそう思っていたので気になりました。
|
|
2020/1/31(Fri) 11:33:18|NO.89378
>HGIMG4のフォントについていくつか不具合の報告を頂いていますので
ということなので、すでにどなたかが報告されていることかも知れませんが、
>mes ""
の実行結果が「β1」までと違います。これまでは、これで1行分空いて、行送りが出来たのですが、
「β2」では、
>mes " "
としないと、行送りになりません。分かっていれば、それほど困ることではありませんが、以前の
プログラムを移行させようとして、これに引っかかって、手直ししないといけない場合があります。
|
|
2020/2/1(Sat) 18:20:07|NO.89385
要望としては mmstat をhsp3dish関係なくいつでも使用できるようにしてほしいです。
> ※再生中フラグはHSP3Dish環境でのみ利用できます
dmmstat をいちいち使わなければならないので少しめんどくさいです...(+_+)
あ、ついでに言うと dmm系 の命令を使うとエラー発生時に応答なしになってしまいます。
2つしかありませんが、
・mmstatの仕様を変更
・dmm系を使うと応答なしになる問題
が実現されるとありがたいです(・∀・)
よろしくお願いします。
|
|
2020/2/1(Sat) 19:43:45|NO.89388
原因がわからないので、報告しても意味ないかなー?と思いましたが一応報告しておきます。
自分のプログラムをhsp36beta2で実行して、色々操作
してみたら、変なエラーダイアログが表示されました。
#Error 42 in line 494 (***.hsp)
-->*
(ファイル名は隠しておきました)
その42エラーをerror.htmで調べてみても、エラーコードは41までしかなく、
まさに"謎のエラー"状態となっています。
で、"*"という文字と、プログラムの494行あたりを見る限り、ラベルが原因かな?
と思いましたが、別のラベルは正常に動いているので、原因は不明です。
ちなみにHSP3.5ならエラーはでません。
(エラーが出たタイミング)
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1436375969
こちらのページで出ているモジュールを使用したモーダルダイアログを"OK"buttonで
閉じようとした時
自分からはこれしか言えません。
|
|
2020/2/2(Sun) 15:26:10|NO.89402
おにたま様
以前、screen命令を使うとgcopyが使えないと書き込み、screenは他のバッファをリセットすると
回答いただきましたが、3.6新機能ハイライトの「13.HSP3Dishのスクリーンサイズ変更について」
に載っていました...
3.51の時はリセットされなかったため、勘違いしておりました。
読み込み不足で申し訳ございません。
|
|
2020/2/2(Sun) 18:37:44|NO.89403
不具合ではなく要望ですが、エディタに関してお願いがあります。
現在のエディタは多重起動防止されています。
同じバージョンの場合はそれでも構わないのですが、
別のバージョンで比較したいという時に少々不便に感じるので
バージョンごとにミューテックス名(多重起動防止していると思われる箇所)を
変えていただけないでしょうか?
例えば、下記のようにバージョンを付けていただければと思います。
// hsed_config.h(現在)
#define MUTEX_NAME "HSPEditor3_Mutex" // Name of Mutex object
// バージョンを付けるように変更
#define MUTEX_NAME "HSPEditor36b2_Mutex" // Name of Mutex object
それから、これは個人の好みもあると思いますが
エディタで行番号をクリックした時にその行の先頭から末尾まで選択されますが、
末尾の後に改行があった場合には改行も選択範囲に含まれると助かります。
どちらも細かい要望ですが、可能であればよろしくお願いいたします。
|
|
2020/2/2(Sun) 21:38:49|NO.89405
「hgimg4」も「β1」「β2」と、改良が進んでいますが、その魅力の一つである物理挙動は、
「立方体」を除いて、その不自然さが残念でなりません。色々と代替の方法を探って、しのいで
いますが、せめて「球体」も「立方体」同様な扱いができるとうれしいです。特にその初期位置
設定が、「x=0」「z=0」でないと、おかしな動きになってしまうのは、厄介で困っています。
「x=0」「z=0」以外に設定したくとも、「gppbind」命令後には「setpos」で移動できない、その
前で「x=0」「z=0」にすると、物理挙動が変になる。
あと、物理設定命令の「gppset」「gppapply」のヘルプの解説がわかりずらいことも、その利用
の進まない原因になっているように思います。もう少し具体的な説明があると、それらをうまく
使って、今ある問題の解決につながる方法も見出されるようにも思うんですが。
この「物理」まわりは、大変な設定であろうことは、この問題が長い間手付かず状態に近いこと
から分かります。その物理エンジン「Bullet」自体の特性とかもあろうかとも思いますが。
|
|
2020/2/3(Mon) 08:20:02|NO.89409
すいません。前のスレでの「物理挙動」で
>「gppbind」命令後には「setpos」で移動できない、その前で「x=0」「z=0」にすると、
>物理挙動が変になる。
の、『その前で「x=0」「z=0」にすると』は、
>その前で「x=0」「z=0」以外にすると
でした。
|
|
2020/2/7(Fri) 08:43:34|NO.89430
「gpbconv.exe」の件について、ご報告致します。
「hsp3info」でリツイートされている、redさんが、
>モデル自体は表示はできるようになった。ただ、モデルが真っ白で....
と、おっしゃっています。「hsp」のバージョンはわかりませんが、「Blender」からのモデルのようです。
自分も色々やってみて、何となく不安を感じています。前にも書きましたが、以前「Blender」で作った
もので変換に成功したモデルは、今回の「gpbconv.exe」でも成功していますが、あらたに「Blender」で
作ったモデルはどうもうまくいきません。「Blender」も以前成功したバージョンを使いましたが、変換は
ダメ。全く何も出来ませんでした。
込み入ったモデルはヤメにして、基本的なもので確認してみようと、立方体に一つの画像を貼り付けた
だけのものを以前のバージョンの「Blender」で作ってやってみましたが、やはり変換出来ません。
試しに、「hsp3.5」付属の「gpbconv.exe」で変換してみると、しっかり成功し、「hsp3.5」のエディタでも、
「hsp36β2」のエディタでも再現できました。で、いつからダメになったのかと思い、「hsp3.51」付属のもので
やってみると、全く何も出来ませんでした。「hsp3.51」以降に組み込まれた「gameplay-encoder.exe」の
特性でしょうか。
また、これは少し問題が違うかも知れませんが、「.gpb」と「.material」のディレクトリも扱いが違うよう
です。「hsp3.5」エディタまでだと、「.gpb」と「.material」を「res」の外、「.hsp」スクリプトと同じ階層に置くと、
画像は「res」に置いても、同階層に置いても、画像反映はされませんが(もちろん「.material」はそれに応じて
書き換えたものにしました)、黒い立方体は表示されました。しかし、同じことを「hsp3.51」「hsp36β2」の
エディタで実行すると、立方体すら表示されません。なのに、不思議とエラーにはなりません。
ついでと言っては何ですが、次のことはどのエディタからでもそうですが、「.gpb」と「.material」、マッピングの
画像ファイルをそろって「res」フォルダに入れた場合、「.material」では画像ファイル path で、「res/」を記述しても
しなくても、きちんと表示されます。さらに、「res/」について言えば、今回の「gpbconv.exe」によってできる
「.material」では、画像ファイル path が「res/」に書換えられてできてきます。以前の「gpbconv.exe」でできる
「.material」では、画像ファイル path が絶対パスになっていました。「sample/hgimg4/fbx/high_school_girl.fbx」を
以前のもので変換すると、実際、「..\..\..\..\..\Program Files (x86)\Metaseq31\body.tga」です。ということは、
今回の「gpbconv.exe」では、これを「res/body.tga」に編集書換えをしていることのようです。「hgimg4」を
「hsp3dish」の上位互換とする以上、「res/」は当然なのでしょう。ただ、もちろん、この書換えらえた通りの
ディレクトリに、画像を移して、かつ「.png」にしなければなりませんが。
基本的な立方体、以前のものなら変換に成功するのに、今回のものでは、うまくいかない。
どういう訳でしょうか。困ってしまいます。

| |
|
2020/2/7(Fri) 17:54:34|NO.89431
物理エンジンの「Bullet」にしても、fbx変換の「gameplay-encoder.exe」にしても、外部の
ツールソフトはそれらとのすり合わせにご苦労されることと思います。
情報も乏しく、もう少し集まれば、解決への道筋も見えてくるように思うのですが。
そのためにも、試験的にもこれらの利用者が増えてほしいです。私のようなものは、ただただ、
あれこれとやってみることしかできない、知識のないものです。
|
|
2020/2/9(Sun) 21:59:22|NO.89453
SDK機能のHSED_GETCARETPOS改修してもらったついでに
hsed_gettextの最後の1文字取得できないのも改修して
もらえたら嬉しいです。
oncmdはフリーズしなくなったように思います。
|
|
2020/2/10(Mon) 21:45:12|NO.89462
こんばんわ。
自分、去年くらいに買ったwinタブレットをサブマシンっぽく使ってるんですけど
HSPのエディタが、あんまり対応してないっぽいっす
背景色が黒か白しか選べなくて、Ctrl+Vを押してもペーストになりません
機種はDiginnosデジノス DG-D10IW3SLi3
スペックは
Win10 Pro 64ビット
CPU Atom x5-Z8350
メモリ4G
ストレージ64GBeMMC
です
ちょっと最新版でも試してみます
|
|
2020/2/10(Mon) 22:07:53|NO.89464
こんばんわ
最新版では治ってました
旧版を試しなおそうと思ったところ
配色を変更してないのに緑になってました
黒と白しか変更出来なかったのは
基本、2行しか表示してくれなかったからかもしれません
わかりにくいのでエディタの配色変更のとことか
選択候補の行を増やして欲しいです
ちなみにサブでもメインでも
背景色を深緑に選択すると背景色は水色になりました
|
|
2020/2/10(Mon) 22:23:38|NO.89467
こんばんわ
再度3.51インストールしなおしましたがちゃんと動きますね
最近、Ctrlキーが調子悪くてキーボード新調しましたので
壊れてたのは僕のキーボードかもしれません
一応、背景色だけ一通りデバッグしてみたところ
紫とマゼンダがすごい似た色か同じ色ですね
配色の要望としまして
gVIMのように複数の配色を設定したいです
自分gVIMでは青、紺、深緑らへんを
飽きてきたら、配色を変更しています
|
|
2020/2/10(Mon) 22:33:17|NO.89469
スレッドの話題と少し離れてしまいすみません。
OpenHSPのほうの36b2タグだとWindows版Dishがビルドできないようなのですが何かすべきこと変わったのでしょうか?
Visual Studio 2017で見ているのですがどうもabsが解決できないみたいです。
と思ってもう一度見てみたらOpenHSPのリポジトリ自体が表示されていない様子。
確認お願いします。
|
|
2020/2/10(Mon) 22:39:00|NO.89470
こんばんわ。
文字色をデバッグしてみると
文字色も深緑は水色になってました
自分、紺色が好きなので候補に紺色も欲しいっす
ユーザー定義すればいいっちゃいいんですが
|
|
2020/2/12(Wed) 21:29:20|NO.89482
>GENKI さん
もともとstick命令の拡張は、html5版の独自拡張だったものを取り込んだ形になります。
確かに4ボタンの方がジョイスティック等の対応には向いていますね。
次回の更新では検討したいと思います。
>京浜東北・根岸線 さん
ご報告ありがとうございます。
原因はちょっとわかりませんが、再現できるスクリプトがあれば調査したいと思います。
>アキアキノヒロロ さん
gpbconv.exeから呼び出されるgameplay-encoder.exeについては、
3.5付属のものと、3.51以降のものでは大きく違いがあります。
もし、3.6βで正しく変換されないモデルがあるようでしたら、fbxファイルを
サポートの方までメール(hsp@onionsoft.net)で送付頂けるでしょうか。こちらで調査させて頂きます。
物理挙動については、こちらでもサンプルや解説などもっと必要だと感じています。
色々試して頂き感謝致します。
>tds12 さん
ご報告ありがとうございます。
absのエラーってどこのソースでしょうか。こちらの更新ミスかもしれません。
OpenHSPのリポジトリは、現在Tracのアップデートを行っていてweb上から正しく表示できていませんでした。
SVN自体は動作していると思われます。
https://dev.onionsoft.net/svn/openhsp/
>Ponyo さん
>あらや さん
>さか さん
>Y_repeat さん
ご報告と要望ありがとうございます。検討させて頂きます。
|
|
2020/2/14(Fri) 15:02:23|NO.89484
「fbx」のファイル形式については、以前、おにたまさんが、こう言っておられます。
>FBXは非常に柔軟なファイル形式であるため、各ツールごとに出力される内容に差異があり、それが
>より難解なものにしていると思います。
>FBXはあくまでもツール上で管理されている要素(頂点の座標や、UV、テクスチャ画像ファイル名など)を
>出力するもので、その情報を3Dモデルとして構築する方法はツールごとに異なっています。
2019年7月30日、「Blender」2.80 が公開され、最新は、2.81a (2019年12月06日)。特に、2.7 以前とは、様子が
がらりと変わっているようです。最近になって、これを知っては、この最新のものを使って、結果を見てみないと
ダメだと思えたので、今、2.81a に取り組んでいます。操作方法も画面構成も、一新されているので、またまた
四苦八苦ですが、「fbx」出力等に関して分かってきたなら、またご報告させていただこうと思います。
「Blender」にこだわるのはおかしいかも知れませんが、あれだけの機能を持ったものがフリーで使えるのは、
非常に大きいです。プログラミングは何とかできても、3Dの素材を思うように作れずにいる「HSP」ユーザーは
大勢いるはずです。「Blender」からの利用がもっと進めば、きっとその壁も少しは低くなるように思うのですが。
|
|
2020/2/17(Mon) 12:58:37|NO.89497
最新版「Blender」2.81a は、今までとはガラリと変わっているので、実験的に色々やれるようになるまでには、
時間がかかりそうです。で、現段階で言えることは、と 振り返ってみました。
ーー 「3.6β1」付属の「gpbconv.exe」で変換できていたものも、今回のものでも無事変換できた ーー
と、以前ご報告しましたが、これはどうも
ーー 「3.5」付属の「gpbconv.exe」で変換できていたもの ーー だったようです。
そしてこれはもとをたどると、
ーー 「Blender」2.60a から出力した「fbx」 ーー だったようです。また、
ーー この「fbx」は、(ASCⅡ)であって、(Binary)ではない ーー ので、(Binary)にしたものも、試みると、
「Blender」2.60a 出力の「fbx」(ASCⅡ) でも (Binary)
→ 「HSP」3.5 付属の「gpbconv.exe」 変換が可能
これは確かなところです。
一方、(ASCⅡ) (Binary) どちらの「fbx」を「HSP」3.6β2 付属の「gpbconv.exe」で変換しようとしても、
全く反応なしです。
なのに、「HSP」3.5 付属の「gpbconv.exe」でも変換可能な、「sample/hgimg4/fbx/high_school_girl.fbx」は、
「HSP」3.6β2 付属の「gpbconv.exe」でも変換が可能であることは、確認できています。
あらたに「Blender」2.60a 出力の基本的な箱の「fbx」を作って、これを「HSP」3.6β2 付属のもので変換
しようとすると、(ASCⅡ) (Binary)のどちらもできなかったのも、事実です。これが分かりません。
「Blender」2.60a 出力の「fbx」と「high_school_girl.fbx」は、形式が違うのか。
ーー 「high_school_girl.fbx」は、2014年(更新日時)に作られたものらしく ーー さらにこれは、
「Blender」2.81aで「fbx」入力しようとすると、
「Version 6100 unsupported, must be 7100 or later」となってしまうことから、
ーー 「high_school_girl.fbx」は、「fbx」Version 6100 だ ーー と言うことになります。
一方、「Blender」2.60a 出力の「fbx」で、(Binary)にしたものは、「Blender」2.81aで「fbx」入力できたので、
あきらかに形式が違います。(ただし、入力できても、サイズは1/100ぐらいになっているようです。)
これらのことから、
ーー 「fbx」Version 6100 (Binary) は、「HSP」3.6β2 付属「gpbconv.exe」で変換できる ーー
ーー 形式不明だが、「Blender」2.60a 出力「fbx」(Binary)は、「HSP」3.5 付属「gpbconv.exe」で変換できる ーー
頭が混乱して、これが正確かどうか、自信がありませんが、以上ご報告致します。
追伸).
あと、パスの扱いも関係しているように思います。「high_school_girl.fbx」も、別のところにコピーした
ものでは、「HSP」3.6β2 付属「gpbconv.exe」で変換できなくなるのです。

| |
|
2020/2/17(Mon) 17:58:32|NO.89498
コピーした「high_school_girl.fbx」が「変換できなくなる」と追伸しましたが、
これは、どうも、おにたまさんご指摘の
>ディレクトリ名やfbxのファイル名も含めて、スペースや特殊な記号が入っていると
>正しく処理されない可能性があります。
に、引っかかったもので、これに抵触しないかたちで、コピーしたものなら、
「HSP」3.6β2 付属の「gpbconv.exe」で変換できました。
お詫びして、訂正致します。
「fbx」の形式については、専門的なことは分からず、目にできる情報も少なくて、
やっと探せたのは、大分古い次のサイトぐらいでした。このサイトで紹介されている
リンクは、ほとんどが切れていました。
「FBXファイルフォーマットについて」
http://shinjuwankougeki.web.fc2.com/fbx/fbx.html
|
|
2020/2/19(Wed) 09:21:10|NO.89512
#HSP script preprocessor ver3.6beta2 / onion software 1997-2020(c)
#Use file [hspdef.as]
#HSP code generator ver3.6beta2 / onion software 1997-2020(c)
(1699576) : error 25 : 命令として定義できない名前です (1699576行目)
-->
というエラーが出ます
localを付けた#deffuncか#defcfuncで名前が重複すると出るようです
#module
#defcfunc local f
#defcfunc local f
#global
エラーメッセージで検索すると
某掲示板で2015年にすでに報告されていました
|
|
2020/2/21(Fri) 13:39:11|NO.89525
度々のことで申し訳ありません。「GPBConverter」と「Blender」についてです。
ふと思い付きました。最新版「Blender」に、「.fbx」ファイル(=Ver 7.3)をインポートし、
それを fbxエクスポートしてみたらどうかと。
やってみると、出てきた fbxファイルは、Ver 7.4になっていました。
これを「hsp3.6β2」付属の「GPBConverter」にかけてみると、見事に成功致しました。
まだ、はっきりしない面が多々あり、ここでは、報告にとどめ、別にスレを立てたいと
思います。
|
|
2020/3/2(Mon) 08:53:56|NO.89604
いつも楽しく利用させて頂いております。
今回、新しくcelbitmap命令が追加されまして、さっそく取り入れてみました。
その際に気になった現象が3点ほどありましたので、報告致します。
・変数に格納する値はARGB形式ですが、android上では異なる色が表示されました。
調べたところ、android上ではABGR(RとBを逆にする)の順番で値を格納することで正常動作しました。
なお、windows上では正常動作しました。
・windows上におきまして、buffer命令時に、縦・横のサイズを2^nのサイズ(1,2,4,8,16,32,64,128,256,512,1024等)以外を指定した場合に、表示されない、あるいはredraw 0を実行した際にアプリケーションが落ちる等の挙動が確認されました。
これは、android上では未確認です。
・android上におきまして、バックグラウンド動作から復帰した際に画像が表示されない現象が発生します。
なお、プログラム上で再度celbitmap命令を実行されるようにすれば表示されます。
これらの現象は、以下の環境にて発生しました。
windows:GPD pocket
android:pixel 3a
これらの現象はどれもプログラム上でのフォローが可能ですが、もし機種由来ではない現象で修正が可能ならばと思い、投稿致しました。
以上、よろしくお願い申し上げます。
|
|
2020/3/3(Tue) 22:44:21|NO.89613
HGIMG3で、32bitのWAVファイルをdmmloadするとエラーもなく落ちます。
24bitは試していません。
|
|
2020/3/4(Wed) 06:51:20|NO.89614
「GPB converter」と「Blender」について、再々度のスレです。
3D素材「たまねちゃん」の改変、改造ができる道筋がどうにか掴め、
「GPB converter」ver.0.6 での変換、その「GPB」ファイルの 「HSP」3.6β2 での利用が可能となる
データとしての「Blender」のファイルが出来ました。
この件につきまして、ここでは、これを最後とし、私の別のスレ
「GPBコンバーターでの変換(3.6β2付)」
で、追ってご報告したいと思います。
|
|
2020/3/18(Wed) 21:00:54|NO.89746
エディタのバグでしょうか?
「検索」の「文字列の置換」で
「検索する文字列」に適当な文字列を指定し
「置換後の文字列」に空文字列を指定して
「置換して次に」を実行します
その直後「元に戻す」を実行すると
置換された文字列が現在のカーソルの位置に復元されます
ふつうは置換が行われた位置に復元されるものと思うのですが
いかがでしょうか
|
|
2020/4/12(Sun) 16:26:02|NO.90075
別スレッドを立てておりましたが、どうもbeta2に固有の症状のようですのでこちらに報告させて頂きます。
HGIMG4にて、screen_offscreenオプションで作成したレンダリングバッファ経由でメインスクリーンに2D描画すると、スクリーンのX,Y各中央付近が歪むようです。
レンダリングバッファをひとつ経由するたびに1px程度膨らんでいる模様?
言葉だと解りづらいですが、↓のようになりました。
https://imgur.com/Vy8rILE
|
|
2020/5/24(Sun) 22:47:42|NO.90630
こんにちは。
・groll命令が壊れたようです。スクロール量に制限がかからなくなってます。
sample/basic/groll.hsp
・getpath関数での小文字化で期待する結果が返らないことがあります。
#include "hsp3utf.as" ; UTF-8
mes getpath("ezinput/数学関数/一定範囲内の実数を返す(関数).aht", 16)
・私のPCでは、次のコードが『動作を停止』してしまいます。
#include "hsp3_64.as" ; このランタイムのみ発生。
#module hogemo
#deffunc hogefu label hogela
gosub hogela ; ラベル型の変数やパラメ経由が怪しい感じ。
gosub *piyolabel@ ; 直書きでは問題起きない。
return
#global
mes "runtime = " + __runtime__ ; この出力を消すだけで解決!?
hogefu *piyolabel
stop
*piyolabel
mes "piyopiyo"
return
・objinfo関数を64bitランタイムで使う場合にはタイプの補正が必要です。
せめてマクロのobjinfo_bmscrとobjinfo_hwndぐらいは対応できませんか。
#include "hsp3_64.as"
chkbox "dummy", hogeva
mes objinfo_bmscr(0) ; 不定値(データ構造アライメントによる)
mes objinfo_hwnd(0) ; ここが void *bm;
mes objinfo(0, 4) ; ここが HWND hCld;
・#moduleのヘルプ(.hsファイル)に
『"モジュール名"は、複数のモジュールを名前で区分けする時につけることのできる名前で、モジュール名が同じもの同士は、変数名やラベル名を共有します。』
とありますが私の解釈ではコンパイルが通りません。
#module hogemo
#global
#module hogemo
#global
・sortvalのヘルプにて%prm部分の表記がおかしいです。
どうぞよろしくお願いいたします。
|
|
2020/5/25(Mon) 02:07:55|NO.90631
|
|
2020/5/26(Tue) 00:31:26|NO.90644
>衣日和 さん
多くの不具合、ご指摘ありがとうございます。
次のバージョンでは修正したいと思います。
#moduleの問題については、ちょっと検討したいと思います。
|
|
2020/6/3(Wed) 12:42:05|NO.90684
こんにちは。
HSPスクリプトエディタの[編集]の[最終行に移動]が機能していないようです。
それと要望になってしまいますが、[指定行に移動]で最終行より大きい値を入力した場合は、便宜上、最終行へ移動するようにしてほしいです。
|
|
2020/6/4(Thu) 07:54:04|NO.90690
HSPを楽しく使わせてもらっています。
HSP3.6β2にしたら不安定になりました。
"Bg.png"(256*256にしました)を用意し次のスクリプトを実行すると
2回に一回ぐらい"qdraw"の所でエラーが出ます。
"hsp3dish.as"+"obaq.as"が原因なのか"celload"が原因なのかよくわかりません。
以前のバージョンではエラーが出ませんでした。
#include "hsp3dish.as"
#include "obaq.as"
;
; とても単純なサンプル
;
celload "Bg.png", 2
screen 0,640,480 ; ウィンドウ初期化
qreset ; OBAQの初期化
qaddpoly my, 3, 96,20,0 ; 三角形を追加
*main
; メインループ
;
redraw 0 ; 画面の更新を開始
color 0,0,0:boxf ; 画面をクリア
qexec ; OBAQによるオブジェクトの更新
qdraw ; オブジェクトの描画
redraw 1 ; 画面の更新を終了
await 12 ; 一定時間待つ
goto *main
|
|
2020/6/14(Sun) 17:03:52|NO.90775
こんにちは。
3.6で追加されたcelbitmap命令ですが、hsp3dishでは動くものの
HGIMG4では正常に動作しないようです。
HDLにあるサンプルコードのincludeをhgimg4.asに変えたところ、
celbitmap対象バッファが配列で置き換えられていないことを確認しました。
//includeを"hgimg4.as"~setcls CLSMODE_SOLID, $FFFFFFに変えると
//celbitmap対象バッファが黒一色になっている
;#include "hsp3dish.as"
#include "hgimg4.as"
gpreset
setcls CLSMODE_SOLID, $FFFFFF
buffer 2,256,256,screen_offscreen
gsel 0
dim bitmap,256*256
repeat 256*256
bitmap(cnt)=$ff00ffff
loop
celbitmap 2,bitmap
*main
redraw 0
pos 0,0
celput 2
redraw 1
await 1000/30
goto *main
|
|
2020/7/1(Wed) 22:27:47|NO.90894
以下を実行すると、test2でaaとbbが同じ999になります。
test2内だけ見るとあれ?と思うのですが、これはtest1でaaを使用しtest2
の引数aaとbbがアドレス渡しで同じになるためです。
しかし、これはエラーにしてほしいです。
test1でbbを使用すると出る「パラメータ引数名は使用されてます」エラー
と同様のことだと思うのですが。
少し長い関数をいくつも作っていて、このエラーが出たのですが原因に気づ
くのに時間がかかりました。
まあ、全ての関数を#module~#globalで全部分ければ良いのですが。。
test1
stop
#module
#deffunc test1
aa = 111: test2 aa
return
#deffunc test2 var bb
aa = 0: bb = 999
mes strf( "aa[%d][%x]", aa, varptr( aa ) )
mes strf( "bb[%d][%x]", bb, varptr( bb ) )
return
#global
|
|
2020/7/1(Wed) 23:20:45|NO.90895
>>90894
aaをローカル変数にするのはダメなんだろうか?って思いました。
モジュール内で同じ変数名を再利用するのは、事故の元と思っていて、
やるのであれば、local変数を使用するものだと思ってました。(自分だけ?)
test1
stop
#module
#deffunc test1 \
local aa
aa = 111: test2 aa
return
#deffunc test2 var bb, \
local aa
aa = 0: bb = 999
mes strf( "aa[%d][%x]", aa, varptr( aa ) )
mes strf( "bb[%d][%x]", bb, varptr( bb ) )
return
#global
|
|
2020/7/3(Fri) 02:51:35|NO.90896
ちょっと訂正すると、エラーではなく、エラーにならなかったので不具合の原因究明
に時間がかかりました。
TOMATOさん、ご意見ありがとうございます。
local使用はその通りです。回避策はありますが使い勝手なんですよ。
実際、localって使います?
自分は1つ2つのlocal書くのなら違う変数名にするし、たくさんあるなら関数毎に
moduleで分けます。まして関数内で使用する全変数をlocalで書く人っているので
しょうか。言い過ぎならすみません。。
今回は、意識なくつい良く使う変数名を引数にしてしまいました。
仕事ではc言語やC#なんかを使用するのですが、その他の一般的な言語は関数内の
変数は通常ローカル扱いなので、そもそも関数にmodule宣言するのも煩わしいです。
まあここらへんはマイコンのbasicが起源でmoduleは後付けなので仕方ないのだろう
なとは思います。
ん?あと、\で次の行って、deffuncでは使えるのですね。
aa=1,2, \
3 とかはできないですがどういうときに\使えるのでしょうか。
|
|
2020/7/3(Fri) 18:08:45|NO.90898
私の場合、同モジュール内の複数の関数で変数の内容を共有したり、
モジュール関数とグローバル関数を使い分けたりしてるので、現状のまま一律
「関数はすべてモジュール関数扱い」
「関数内の変数はすべてローカル変数扱い(関数終了と同時に破棄される)」
という変更をされてしまうと厳しいですね。
もしこういう変更がなされる場合は、
「この変数はモジュール内では共有する」「この変数は関数内でのみ有効」
「この変数はモジュールも含めた全体で共有する」などといった形で
変数のスコープをあらかじめ宣言できるようになってほしいです。
>実際、localって使います?
私はたとえば「文字列の処理」など関数内で大きいサイズの変数を一時使用する時、
その変数を関数終了と同時に破棄してメモリ解放するために
localを使うことが多いです。
>\で次の行って、deffuncでは使えるのですね。
>aa=1,2, \
>3 とかはできないですがどういうときに\使えるのでしょうか。
マニュアルを読んだ限り、この表記はプリプロセッサ命令(#から始まる命令)
でのみ有効なようです。
|
|
2020/7/3(Fri) 21:38:02|NO.90900
開発お疲れ様です。
HSP3Dishですが、データファイル(data.dpm)が認識されません。
プロジェクトフォルダのassetsフォルダに入れれば問題ありません。
|
|
2020/7/4(Sat) 21:45:50|NO.90903
開発お疲れ様です。長らく使用してきた3.5b5からちょっとアップグレードしようかと
使用してみたのはいいのですが、作っていたandroidアプリが実機ビルドでフリーズします。
SDK等は3.5で問題なく使えていたものを移行し、プロジェクトは新規で作り直しました。
原因を調べていったところ、以下のソースで再現されました。
全角をmesするとアウトっぽいです。
#include "hsp3dish.as"
repeat
redraw 0
color:boxf
color 255,255,255:pos 0,0:mes"あ"
redraw 1
await 16
loop
|
|
2020/7/4(Sat) 22:21:34|NO.90904
気になったのでこちらでもプロジェクトを新規作成したうえで、少し動きを加えたコードで検証してみましたが特にフリーズは無かったです。
#include "hsp3dish.as"
repeat
redraw 0
color : boxf
color 255, 255, 255 : pos rnd(300), rnd(300) : mes "あ"
redraw 1
await 16
loop
|
|
2020/7/4(Sat) 23:04:02|NO.90905
検証ありがとうございます。固まりませんか…
ちなみに自分は
jdk1.8.0_251
sdk25.2.5
ndk-r14b
apache-ant-1.9.15
を設定し、Helper ver1.74でビルド。デバッグビルドが1300kBくらいの容量に
なるのが気になりますがそれは置いときます。
Nexus7(2013)_4.4.2とXperia SO-02J_6.0.1で同様のフリーズに見舞われましたが
いわゆるおま環であるのならば、おとなしく3.5に戻します。
|
|
2020/7/5(Sun) 00:25:50|NO.90906
>しまくろねこ さん
ご報告ありがとうございます。
新しいandroid OS上でのdata.dpmの扱い、まだ修正されていません。
OSのセキュリティによるものなので、こちらも時間が取れたら少し調べてみたいと思います。
>撃 さん
ご報告ありがとうございます。
フリーズしているというのは、黒い画面のままということでしょうか。
アプリが動作しているかどうか確認したいところです。
こちらではちょっと再現できないのですが、生成されたapkを見させて頂いても宜しいですか?
|
|
2020/7/5(Sun) 01:33:41|NO.90907
更新お疲れ様です
以前私が報告させていただいたエディタ関連の不具合はまだ手付かずな状態なのでしょうか…
最新版のエディタでコードを書いていると気まぐれでエディタが突然落ちる現象が発生しており運用に少々不安を感じている今日この頃です;
(3.5の頃のエディタでは半数の問題は発生せず落ちることもないため、修正のご予定がない場合は個人的には3.5のエディタを標準にしてほしい気持ちですがいかがでしょうか…)
さて、今程新機能ハイライトを確認させていただき驚いたのですが、
>6.コールバックルーチンについて
>いままで、HSP3の中で発生していた割り込み、モジュール型変数のコンストラクタ、デストラクタなどを総称して 「コールバックルーチン」と定義し、従来よりも厳格に管理されます。
この修正によって私がこれまで開発したスクリプトからかなりの互換性が失われてしまい、ツール系は全滅しています。(エラーで動作しません)
これまで通常はstopで動作を停止していて、onclick等で処理を着火するようなシステムが組めましたが、今後はこのようなスクリプトをどのように組めば良いのでしょうか?(HSPではstopを使うべきではない?)
この問題を避けるためイベントの呼び出しをgotoで書くという手も検討してみましたが、これですとどこかでループ処理をしている時にイベントが発生した場合そちらの処理が放棄されてしまいます。
この3.6b3以降の仕様に合わせるためには常時メインループでコールバックイベントを逆に監視しながらコールバック発生時にメインループで対応する処理をするような複雑な書き方をする必要があるのでしょうか…(本末転倒?)
過去作品の大幅な修正が必要になるため何らかの対応をしていただきたいところですが…この問題は何とかならないでしょうか。
ご検討よろしくお願いいたします。
|
|
2020/7/5(Sun) 09:30:47|NO.90908
運営様、お手数おかけします。以下のソースで
3.5と3.6でビルドしたapkをあげておきます。
#include "hsp3dish.as"
repeat
redraw 0
color:boxf
color 255,255,255:pos 0,0:mes"count:"+cnt
pos 0,counter+20
if counter/120:mes"全角":else:mes"hankaku"
redraw 1
counter++:counter\=240
await 16
loop
https://dotup.org/uploda/dotup.org2192237.zip.html
3.6版はやはり全角表示手前で停止します。
備考
・センサーを使用にチェックしてビルドしている(必要)
・フォント関係ではノーマルWin10と異なる点として、Meiryo UIも大っきらい!!を適用。
|
|
2020/7/5(Sun) 12:36:17|NO.90909
>撃 さん
ご返信ありがとうございます。apkの方も確認させて頂きました。
No.90908で提示頂いたスクリプトだとこちらで作成しても停止しますね。
ちょっと内部動作を調べてみたいと思います。
>Drip さん
ご指摘ありがとうございます。
コールバックルーチンですが、過去に動作しているスクリプトが動作しなくなるような
仕様にする意図ではないことをご理解頂ければと思います。
あいまいな動作で仕様が確定しなかった部分を明確にしたもので、
こちらの想定していない利用の方法があれば対応していきたいところです。
その上で、割り込み(サブルーチン)処理の中でstopにより動作を停止する
処理がどのような構造のものか、お聞きしてもいいでしょうか。
onclick gosub *ok
stop
*ok
mes "OK"
return
上のような構造で、*okの先でstop命令で停止するということでしょうか?
return命令ではだめでしょうか。
エディタ関連の不具合については、申し訳ありません。
根幹に係わる機能については、まだ手がついていないため、今後また時間を取って改修していきたいと考えています。
|
|
2020/7/5(Sun) 13:50:26|NO.90910
おにたまさん
ご返信有難うございます。
エディタの修正に関してコンボボックスの長さや文字の色分け漏れなどが根幹に関わる問題というのがかなり意外でした…申し訳ありません。
もしかなりご無理をされてこのような機能を搭載されていらっしゃるのでしたら今後のメンテナンスもより困難になってきそうでちょっと不安ですね…;
問題が改善されることを祈っております。(ただ修正がどうしても難しい場合は旧バージョンに戻す事も選択肢の1つに入れていただければ幸いです;)
>コールバックルーチンですが
>上のような構造で、*okの先でstop命令で停止するということでしょうか?
>return命令ではだめでしょうか。
正しく意図が伝わらなかったようで申し訳ありません。
stopするというのはサブルーチンでの話ではなくイベント着火前の状態のことです。
以下は急ごしらえかつかなり簡素化した例となりますが、ツール系のソフトにおいて私は以下のように書くことが多く、onclick命令登場時からこのような形で書いていたと記憶しております。
この他にもoncmdでメニューバーのメッセージを拾ってサブルーチンに飛び処理を振り分け、テストプレイを呼び出したりするような使い方は別段特殊な使い方ではないと認識しておりました。
//★マウスで障害物を描いてテストボタンでスキャンラインテストをするだけのサンプル
onclick gosub *draw //マウスクリック時の動作登録
objsize 150,40:font msgothic,20,1:pos ginfo_winx-160,ginfo_winy-50:objmode 2 //ボタン装飾
button gosub "動作テスト",*test //動作テストボタンの登録
stop
*draw //障害物を描画する処理
if cx:dialog "動作テスト中です!\n中断はESCキーです":return //動作テスト中は処理しない
pos mousex,mousey //カレントポジションをマウス座標に移動
ky=256 //kyにマウス入力情報を手動代入
while ky&768 //kyからマウス情報が抜けると処理終了
stick ky,768 //マウスの状態を監視
color:line mousex,mousey //障害物を描画する
await 16 //アイドル
wend
return
*test //動作テストをする処理
objenable 0,0 //テストボタングレーアウト
cx=0 //スキャンラインのX座標
hsv+=32 //スキャンラインの色
while cx<ginfo_winx //スキャンラインが右端に来たら処理終了
stick ky:if ky&128:_break //処理の中断
repeat ginfo_winy //縦方向に障害物があるかスキャン
cy=cnt //検査Y座標を更新
pget cx,cy:if ginfo_r+ginfo_g+ginfo_b=0:break //障害物を発見したらループを抜ける
loop
hsvcolor hsv\192,255,255:line cx,0,cx,cy-1 //障害物まで線を引く
cx++ //検査X座標を移動
title "テスト中..."+(cx*100/ginfo_winx)+"% 完了 / ESCで中断" //状態を表示
await 16 //アイドル
wend
objenable 0,1
title "テストを終了しました" //テストボタン復帰
cx=0 //スキャンラインのX座標リセット
return
このようなプログラムを大きく改変することなく(すなわち1つの処理に対して着火用サブルーチン・中身用サブルーチン・監視ループ…などと分散することなく)
通常時はstopでプログラムを止めた状態で単一の処理を着火するにはHSP3.6b3からはどのように書くのが良いのでしょうか。
どうぞよろしくお願いいたします。

| |
|
2020/7/5(Sun) 20:46:24|NO.90915
Drip様こんばんは
oncmdの仕様が変わったとのことで試してみました。
Error42 コールバック云々とエラーが出ました。HSPでは割り込みサブルーチンにコールバックの名がついたようですね。
そこでoncmdを置き換えるnaznyark様のhpi_exprogctrl.hpiのoncmd2を使い
onclick gosub *draw //マウスクリック時の動作登録
の部分を
#include "hpi_exprogctrl.hsp"
#define WM_LBUTTONDOWN 0x00000201
oncmd2 gosub *draw, LBUTTONDOWN
と置き換えてみました。3.4 3.51と同様の動作になりエラーが出ることはありませんでした。
わざわざ置き換えるのも大変かとは思いますが一つの対処の在り方ということで…。
こちらの
naznyarkのガラクタ置き場様からダウンロードできますのでお試しください。
http://hp.vector.co.jp/authors/VA043120
|
|
2020/7/5(Sun) 20:49:24|NO.90916
すみませんタイプミスのまま書き込んでしまいました。
#define WM_LBUTTONDOWN 0x00000201
oncmd2 gosub *draw, LBUTTONDOWN
こちらでした。
#define WM_LBUTTONDOWN 0x00000201
oncmd2 gosub *draw, WM_LBUTTONDOWN
|
|
2020/7/5(Sun) 23:43:41|NO.90919
>Drip さん
ご返信ありがとうございます。
イベントを使ったスクリプトのご提示ありがとうございます。
まず基本的な方針として、新しいバージョンで以前のスクリプトを動かすために
大きな改変が必要になるような仕様変更は、(メジャーアップデート以外では)できる限り避けたいと考えています。
割り込み処理の中でフレーム処理をすることは、
こちらではあまり想定していなかったので大変参考になりました。
先に説明させて頂きますが、コールバックルーチンで制限を行っている理由は大きく2つあります。
onclick gosub *clicktest
stop
*clicktest
mes "SUBLEV"+sublev
repeat
wait 10
loop
return
上のようなプログラムを書いた場合、割り込みの中でさらに割り込みが発生して
サブルーチンのネスト(sublev)が深くなってしまい、最悪の場合エラーとなります。
もちろん仕組みをわかっている人が書くぶんには問題ないのですが、
ネストの問題はなかなか発見が難しく、意図せず発生したとして原因が分かり難いものになってしまいます。
waitやstopといったフレームをコントロールを行う命令は、メインループの中に書くことで
割り込み処理の複雑さをある程度シンプルにして安全性を確保したいという意図がありました。
No.90910でご提示頂いたスクリプトで言えば、*drawのサブルーチンは、メインとして
書いた上で、メイン側の処理をモード値などの値で振り分けておいて、
割り込みのサブルーチンからモード値をコントロールするようなイメージです。
(これは状態遷移、ステートマシンと呼ばれるイベント処理では一般的な手法になります。)
もう1つの理由は、HSP3.6b3で導入されたレイヤーオブジェクトと、標準スプライトの
コールバックをサポートするためです。
これらの新しい機能は、HSPのフレーム描画処理中にスクリプトの処理を入れることができ、
自由度が高くなる反面、1フレーム内で完了しなければならない命令内で、
waitやstopを実行することが難しいといった部分があります。
先にも書いた通り、既存のスクリプトが動かなくなる形での修正は本来の意図ではありません。
こちらから、このようなスタイルで書いて欲しいという推奨はできますが、
それぞれのユーザーが作成した過去のスクリプトについて手法を否定するつもりはありませんし、
過去のスクリプトの動作に大きく影響することは避けたいと思っています。
今回、ご意見を頂いて検討した上で、onkey,onexit,onerror,oncmd,onclick命令による
割り込みについては、影響が多岐にわたるということでコールバックルーチンの
制限から除外し、制限がかかるものは以下の状況のみとする形に修正する方向で考えさせて頂きます。
・#deffunc命令で定義されるクリーンアップ命令の実行時
・モジュール型変数のコンストラクタ、デストラクタ実行時
・配置オブジェクト(objlayer)によるユーザー割り込み
・es_setgosub命令によるスプライト表示割り込み(HSP3Dish)
ご心配とお手数をおかけして申し訳ありませんでした。
こちらのスレッドで反応を頂き感謝致します。
引き続き、β版での動作について検証とご意見を頂けると嬉しいです。

| |
|
2020/7/7(Tue) 18:07:58|NO.90933
HSPがVisual Basicのように、GUIのみをマウスで操作し、
その後、スクリプトを書くといった感じになるといいです。
|
|
2020/7/7(Tue) 18:32:29|NO.90934
HSP3.6β3 試してみました。
mes 命令のオプションで1(改行しない)を指定したときに、
「表示した文字の右側にカレントポジションが移動」しなくなっています。
HSP3Dishにした場合は機能するので、PC版の方の修正をお願いします。
;↓Dishだとちゃんと機能する。
;#include "hsp3dish.as"
pos 50,0
mes "abc",1: mes "=",1 : mes "1"
mes "def",1: mes "=",1 : mes "2"
redraw 1 //Dish描画
あと、これは個人的な感想ですが、
オプション 1を指定開始したときにx座標を記憶しておいて、
0に戻したときにx座標をそこまで戻す仕様の方が使いやすいのにな~
とは思います。
(でも、互換が失われるから対応はしなくても良いです。)
// イメージはこんな感じです。
// ※screenをまたいだとき等は考慮されていない。
#include "hsp3dish.as"
#module
#undef mes
#deffunc mes str w, int p
if ( flg!(p&1) ) && ( (p&1)=1 ) :cx = ginfo_cx
mes@hsp w,p
if ( flg!(p&1) ) && ( (p&1)=0 ) :pos cx
flg = (p&1)
return
#global
pos 50,0
mes "abc",1: mes "=",1 : mes "1"
mes "def",1: mes "=",1 : mes "2"
redraw 1 //Dish描画
|
|
2020/7/7(Tue) 23:10:10|NO.90935
β3楽しみです。
○mes命令の改善で、割と煩雑だった描画(段組みや縁取り)から解放されて幸せです。
・オプション+1の件、今度は改行で終わる文字列なら動作するみたいです。
・コンパクト版ランタイムが以前の動作のままだと思うのですが。
・縁取りで幅を指定すると隙間ができて読み難い気がするのですが如何でしょうか。
;#include "hsp3dish.as"
;#runtime "hsp3c" ; 今回の改良から適用外?(β2までの動作っぽい)
screen 0, 640, 480, 0, 20, 20 ; 同じ位置に出してALT+TABで切り替える。
chdir dir_exe + "\\aht" ; とりあえず改行で終わる手ごろな文字列を2つ用意。
dirlist filename, "*.*", 1 : filesize = "" : notesel filename
repeat stat
noteget stemp, cnt : exist stemp : filesize += "" + strsize + " byte\n"
loop
redraw 0
color 211, 211, 255 ; 半分、白い。
repeat 480 / 28 : boxf 0, cnt * 28, 639, cnt * 28 + 13 : loop
rgbcolor 0x4040f0 : objcolor 240, 128, 128
font msgothic, 14 : mes "Runtime is " + __runtime__
font msmincho, 28, , 2
mes "改 が い た の 字 の う …", 1 ; こんな遊びに需要は無い。
mes " 行 な だ 文 列 よ だ "
mes "縁取りに幅があるとかえって読み難い", 4
font msgothic, 14 : pos 14, 70 ; 改行で終わる文字列の出力。
mes filename, 1 : mes " ", 1 : mes filesize ; 段組みめっちゃ簡単\(≧▽≦)/
mes "出力サイズ:" + ginfo_mesx + "x" + ginfo_mesy ; hsp3とdishで位置・値に違い。
redraw 1
○レイヤーオブジェクトを64bitで試しました。redraw命令周りの割り込みでエラー出ませんか?
#include "hsp3_64.as" ; このランタのみ。
mes "レイヤーオブジェクトを配置する"
layerobj 240, 40, 3, *hogela, 130
mes "配置完了、再描画スイッチをオフる"
redraw 0
mes "この描画はオンにするまで出力できない"
redraw 1
mes "お疲れ様でした"
stop
*hogela
mes " -> レイヤーオブジェクトの割り込み発生"
if lparam == 1 {
opos = objinfo(wparam, 5 + hspstat / 0x40000 \ 2 * 3)
size = objinfo(wparam, 6 + hspstat / 0x40000 \ 2 * 3)
mes " ・オブジェクトが配置されました"
mes " ・pos : " + opos \ 65536 + " , " + opos / 65536
mes " ・size: " + size \ 65536 + " x " + size / 65536
}
return
○エディタ上でF7(とんでもスクリプト+F5)を押したときの結果レポートですが、未初期化~やエラー内容が英語表示に。
どうぞよろしくお願いいたします。

| |
|
2020/7/7(Tue) 23:10:39|NO.90936
hsp36beta3を試させていただきましたが、mes命令の新しいオプションの縁取り文字で、font命令で幅を2以上に設定した場合に文字が分散するようですがこれは仕様通り(意図した動作)なのでしょうか。
この縁取りというのが恐らく同じ文字を先に上下左右に幅分ずらして描画される仕様だと思いますが、これでは幅が2以上で「縁取り」とは言い難い結果になるため、仮に仕様通りだとしても修正をお願いしたいです。
pos 50, 50
font MSgothic, 16, 0, 2
mes "HSP36beta3", 4
pos 50, 100
color 255, 0, 0
font "Meiryo UI", 20, 1, 5
mes "HSP36beta3", 4
|
|
2020/7/9(Thu) 22:13:39|NO.90949
β3の先行ダウンロード版につきまして、色々なご意見とご報告ありがとうございます。
こちらで気付かなかった不具合でお手数をおかけしました。
以下の項目を修正させて頂きました。
・on~系の割り込み処理をコールバックルーチンの制限から除外
・android版HSP3Dishでmes,printで全角を使用した際に止まってしまう不具合を修正
・標準ランタイムのmes,print命令でカレントポジションの移動がおかしかった不具合を修正
・コンパクト版ランタイム(hsp3c)が以前の動作のままだったのを修正
・縁取り、影付き文字の描画で幅が2以上の時の表示を修正
・64bitランタイム(hsp3_64)でレイヤーオブジェクトが正しく動作しない不具合を修正
・コンパイラdll(hspcmp.dll)が英語版になっていたのを修正
以下のURLから修正版を先行してダウンロード頂けます。
大きな問題がなければ、今後公開に向けて準備したいと思います。
https://www.onionsoft.net/hsp/file/hsp36b3_200709.zip
|
|
2020/7/10(Fri) 02:27:50|NO.90950
お疲れ様です。
誤検出だとは思いますが、上記展開後に Avast で hsp3cl.hrt が
Win32:Evo-gen [Susp] に感染していると怒られます。
おにたまさんへメールも投げましたので、ご確認をお願いいたします。
|
|
2020/7/10(Fri) 06:48:20|NO.90951
試しにzipファイルの状態でスキャンしてみました。
hsp3cl.exe も同様に怒られます。
|
|
2020/7/10(Fri) 19:25:26|NO.90954
>>窓月ららさん
当方のカスペルスキーではzip・展開後のhsp3cl.hrt&exeともにウイルス判定は出なかったので、恐らくAvast側の誤検知かと思われます。
|
|
2020/7/10(Fri) 21:38:46|NO.90958
開発お疲れ様です。
「hsp36b3_200709.zip」で下記を実行すると、Windows上だと2回目の表示で自動で落ちます。
Android上だと異常な動きになり、これもまた落ちます。
mes命令の代わりに自作の文字画像モジュールを使うと正常に動作します。
mes命令の不具合と思われます。
#cmpopt varinit 1 ;未初期化変数のチェック
#include "hsp3dish.as"
screen 0, 480, 800
#module
#const FALSE 0
#const TRUE 1
plat_form = PLATFORM_WINDOWS
getreq plat_form, SYSREQ_PLATFORM
#defcfunc dstr_mid str buff, int start_index, int get_length
sdim in_buff, strlen(buff)
c_cd = 0
count_index = 0
set_index = 0
plus_index = 0
index_flg = FALSE
get_index = 0
in_buff = buff
len_buff = strlen(in_buff)
if start_index == -1 {
sdim re_buff, 3, len_buff
} else {
sdim re_buff, 3, get_length
}
repeat len_buff
if set_index >= len_buff : break
c_cd = peek(in_buff, set_index)
switch plat_form
case PLATFORM_WINDOWS
if c_cd <= 127 {
plus_index = 1
} else {
if c_cd >= 253 {
plus_index = 1
} else {
if c_cd >= 224 {
if c_cd <= 252 : plus_index = 2
} else {
if c_cd >= 161 {
if c_cd <= 223 : plus_index = 1
} else {
if c_cd >= 129 : plus_index = 2
}
}
}
}
swbreak
case PLATFORM_IOS
case PLATFORM_ANDROID
default
if c_cd <= 127 {
plus_index = 1
} else {
if c_cd >= 224 {
if c_cd <= 239 : plus_index = 3
} else {
if c_cd >= 192 {
if c_cd <= 223 : plus_index = 2
}
}
}
swbreak
swend
if start_index == -1 {
index_flg = TRUE
} else {
if cnt >= start_index {
if get_index < get_length {
index_flg = TRUE
} else {
break
}
get_index++
}
}
if index_flg {
re_buff(count_index) = strmid(in_buff, set_index, plus_index)
count_index++
}
set_index + plus_index
loop
join_buff = ""
loop_length = get_length
if loop_length > count_index : loop_length = count_index
switch start_index
case -1
repeat loop_length
c = count_index - loop_length + cnt
join_buff + re_buff(c)
loop
swbreak
default
repeat loop_length
join_buff + re_buff(cnt)
loop
swbreak
swend
in_buff = ""
sdim in_buff, 1
sdim re_buff, 1, 1
return join_buff
;-----------------------------------------------------
#defcfunc dstr_len str buff
sdim in_buff, strlen(buff)
c_cd = 0
count_index = 0
set_index = 0
in_buff = buff
len_buff = strlen(in_buff)
repeat len_buff
if set_index >= len_buff : break
c_cd = peek(in_buff, set_index)
switch plat_form
case PLATFORM_WINDOWS
if c_cd <= 127 {
plus_index = 1
} else {
if c_cd >= 253 {
plus_index = 1
} else {
if c_cd >= 224 {
if c_cd <= 252 : plus_index = 2
} else {
if c_cd >= 161 {
if c_cd <= 223 : plus_index = 1
} else {
if c_cd >= 129 : plus_index = 2
}
}
}
}
swbreak
case PLATFORM_IOS
case PLATFORM_ANDROID
default
if c_cd <= 127 {
plus_index = 1
} else {
if c_cd >= 224 {
if c_cd <= 239 : plus_index = 3
} else {
if c_cd >= 192 {
if c_cd <= 223 : plus_index = 2
}
}
}
swbreak
swend
count_index++
set_index + plus_index
loop
in_buff = ""
sdim in_buff, 1
return count_index
#global
;--------------------------------------------------------------
; 表示
;--------------------------------------------------------------
buff = "銀河鉄道の夜\n\n宮沢賢治\n\n"
buff += " 一 午後の授業\n\n"
buff += "「ではみなさんは、そういうふうに川だと言(い)われたり、乳(ちち\n"
buff += ")の流(なが)れたあとだと言(い)われたりしていた、このぼんやり\n"
buff += "と白いものがほんとうは何かご承知(しょうち)ですか」先生は、黒板\n"
buff += "(こくばん)につるした大きな黒い星座(せいざ)の図の、上から下へ\n"
buff += "白くけぶった銀河帯(ぎんがたい)のようなところを指(さ)しながら、\n"
buff += "みんなに問(と)いをかけました。\n"
buff += "\n カムパネルラが手をあげました。それから四、五人手をあげました。\n"
buff += "ジョバンニも手をあげようとして、急(いそ)いでそのままやめました。\n"
buff += "たしかにあれがみんな星だと、いつか雑誌(ざっし)で読んだのでした\n"
buff += "が、このごろはジョバンニはまるで毎日教室でもねむく、本を読むひま\n"
buff += "も読む本もないので、なんだかどんなこともよくわからないという気持\n"
buff += "(きも)ちがするのでした。\n"
buff += " ところが先生は早くもそれを見つけたのでした。\n"
buff += "「ジョバンニさん。あなたはわかっているのでしょう」"
len = dstr_len(buff)
put_cnt = 0
font "", 14
repeat
put_cnt++
repeat len
redraw 0
color 0, 200, 255 : boxf
color 0, 0, 0
moji = dstr_mid(buff, 0, cnt + 1)
pos 200, 0 : mes str(put_cnt) + "回目"
pos 0, 0 : mes moji
redraw 1
await 1000 / 60
loop
loop

| |
|
2020/7/11(Sat) 00:47:05|NO.90960
>窓月らら さん
Avastでの検知につきまして、ご報告ありがとうございます。
他のアンチウイルスソフトでは検出されないので、誤検知と思われますが、
心配な場合は落ち着くまで該当ファイルは除外してご使用下さい。
>しまくろねこ さん
ご報告ありがとうございます。
フォントキャッシュに不具合があり落ちていました。
日本語の表示について、色々検証して頂きとても助かります。
とり急ぎ、フォントキャッシュの不具合修正と、HSP3CLがAvastで誤検知されるのを
避けるために別なコンパイラを通したものに差し替えました。
以下のURLから修正版を先行してダウンロード頂けます。
https://www.onionsoft.net/hsp/file/hsp36b3_200711.zip
|
|
2020/7/11(Sat) 11:32:25|NO.90962
#packopt name "1.0."
#packopt version "hoge.txt"
これを「実行ファイル自動作成」すると、
[ERROR] No.10
実行ファイルが見つかりません
Enterキーを押してください
と出た後、「1.0」と「1.0.exe」のファイルが作成されます。
hoge.txtには、なにも書いていません。
2行目のバージョンリソース設定をなくすと、
エラーは出なくなりますが、「1.0」というファイルは変わらず出ます。
実行ファイル名の、末尾のピリオドを外すと、
「1.exe」という名前で作成されてしまいます。
どうやら、バージョン3.5からある挙動のようで、
3.5では、エラーは出ませんでしたが、他は同じような挙動でした。
3.51では、エラー文にスクリプトのパスが表示されること以外、同じような挙動でした。
3.6β2では、全く同じ挙動でした。
変にエラーが出たり、無駄なファイルが出るのは面倒なので、修正の検討をお願いします。
(名前に"1.0"を指定しても、しっかり"1.0.exe"が作成され、"1.0"というファイルは作成されない。というのが個人的な理想です)
|
|
2020/7/11(Sat) 22:37:56|NO.90967
対応、お疲れ様です。
hsed_gettextの対応、確認しました。どうもまだ不安定なようです。
以下のソースはhsed_gettextで取得した内容を表示繰り返すソース
です。
実行中にHSPエディタを閉じて画面終了し、再度HSPエディタでソース
実行すると、画面が終了したり、テキスト内容が取得できないことが
自分の環境では100%起きます。
しばらくすると正常に動いたりするので、メモリの解放などメモリ関
連が上手く行ってないのではと思います。
#include "hsedsdk.as"
*@
wait 20
hsed_getwnd MAIN_HWND, HGW_MAIN: if stat != 0: dialog "end": end ; HSPエディタを終了したら終わり
sdim txt, 1000
; 編集中のテキストを取得
hsed_gettext txt, 0
cls
title ""+tabid+" "+footyId+" len["+len+"]"
mes txt
goto *@b
よろしくお願いします。
|
|
2020/7/12(Sun) 09:17:13|NO.90974
おにたまさん
ご対応有難うございます。おかげさまで一先ず私のスクリプトはエラーせず動作するようになりました。
以前この掲示板で稀にモジュールでメインループを処理されていらっしゃる方を見かけた記憶がありますので、今回の仕様変更は一定の波紋を呼ぶかもしれませんね。
>上のようなプログラムを書いた場合、割り込みの中でさらに割り込みが発生して
>サブルーチンのネスト(sublev)が深くなってしまい、最悪の場合エラーとなります。
これを懸念するとなるともはやgosub自体が危険という考え方になってしまうような気もするのですが、on系のgosubは通常のgosubとは違うのでしょうか…今回on系の命令をコールバックルーチンの制限から除外してくださいましたが、以前窓月ららさんが報告されていたNO.90631の不具合はいずれも改善していないようです。
これは根本的な修正が難しいのでしょうか…この不具合を回避するためにかなり昔からend:endと書く癖をつけるようにして個人的に対応してはいたのですが、ちょっと不安な回避方法なのでon系のgosubの利用に安心し切れない面はあります。
以下はちょっと余談になります。
>No.90910でご提示頂いたスクリプトで言えば、*drawのサブルーチンは、メインとして
>書いた上で、メイン側の処理をモード値などの値で振り分けておいて、
>割り込みのサブルーチンからモード値をコントロールするようなイメージです。
>(これは状態遷移、ステートマシンと呼ばれるイベント処理では一般的な手法になります。)
はい、この書き方こそ先に述べた「HSPではstopすべきではない?」…という話に繋がるのですが、画面は停止しているように見えて常時監視ループを行うようなスクリプトは、かつてHSP2の頃に見られた書き方のようです。
HSP2製のツール作品は何もしていないように見えて裏でawait 15が常時走っているものが多く、CPUを100%占有する仕様になっており、私も不本意ながら半ば割り切ってそのように書いていた記憶があります。
HSP3で追加されたon系の命令によって不毛な監視にリソースを割かないスタイリッシュな書き方ができるようになり、多くの利用者から歓迎されたように思えます。
常時stopしておりイベントを受け取って個々のメインループにgosubするような書き方はJavaScriptで一般的な、例えばmousedownイベントでsetInterval(メインループ)を着火しmouseupイベントでメインループを破棄する…というような書き方になると思います。
このイメージを持ってHSP3で作品開発をされる方は自然とonclick gosubの先にメインループを作成したり、更にはモジュール内でメインループを作成されることにも躊躇がないかもしれませんね。

| |
|
2020/7/12(Sun) 09:36:28|NO.90978
そういえば以前報告させていただいたステータスバーの問題も一部未解決のようです。
以下のスクリプトでエラーが発生します。
#include "mod_stbar.as"
stbar_ini
screen 3,400,300:stbar_text "テストです"
見たところ未定義の配列への参照が原因のようですので、mod_stbar.as内のstbar_bye, stbar_text, stbar_resizeの3つの命令の各最初の行
act=ginfo_sel
の箇所を以下のように修正することでこの不具合は一先ず沈黙する気がします。
act=ginfo_sel:if length(sthwnd)<=act:return
(迂闊にact=ginfo_selを検索して全部置換しないでください。そうするとstbar_ini命令が機能しなくなります。)
また、なかなか無いケースかもしれませんが、ステータスバーモジュールの構造上、stbar_ini命令を使用したときのscreenのIDが巨大な数値の場合、大量の配列が無駄に確保されてしまうことは一点留意する必要があるかもしれません。
“stbar_ini命令を利用する際、巨大な数値のウィンドウIDが選択されているような場合、内部的に大量にメモリを消費する恐れ(約ID*4バイト)があることに注意してください。”
などの但し書きがどこかにあれば良いかもしれません。(ただ他のモジュールでも日常的に使用されているアルゴリズムの場合、統一も大変ですのでもはやあえてここで注意する必要はないかもしれませんが…)
|
|
2020/7/14(Tue) 20:29:12|NO.90984
>しまくろねこ さん
検証ありがとうございます。
「getreq plat_form, SYSREQ_PLATFORM」の部分がmodule内なので
実行されていない気がします。
PLATFORM_ANDROIDで実行した限りは動作していると思われますがどうでしょうか。
>さか さん
検証ありがとうございます。
こちらではちょっと再現できていないのですが、
hsed_gettext命令で指定するIDが0に固定されているので、
存在しないIDの情報を取得している可能性があります。
hsed_getactfootyidで取得したIDでも不安定になるでしょうか。
>こいる さん
ご報告ありがとうございます。
実行ファイル自動作成の部分は、β2から変更していないため
今後のバージョンで動作を確認していきたいと思います。
>Drip さん
ご指摘とご報告ありがとうございます。
>on系のgosubは通常のgosubとは違うのでしょうか…
>今回on系の命令をコールバックルーチンの制限から除外してくださいましたが、
>以前窓月ららさんが報告されていたNO.90631の不具合はいずれも
>改善していないようです。
on系のgosubと通常のgosubに違いがあると言うよりも、
on系のサブルーチン内でwaitやstop実行中に割り込みが発生した場合、
自分自身を再度呼び出す再帰のような状態を意識せずに作ってしまう可能性があるという意味で
例を挙げさせて頂きました。gosubでも、自分自身を呼び出したり、gotoで
抜けてしまったりという危険性はありますが、割り込みの場合は気付きにくいのではないかと考えています。
もちろん既に動作しているスクリプトを否定するつもりはありませんし、
書き方が間違っているという認識ではありませんが、初めてon系のサブルーチンを
書く方に向けてはwaitやstopは推奨しないという立場での話です。
NO.90631の不具合については、根本的な修正が難しいわけではありませんが、
他に影響する部分が大きいのでまだ保留しています。
こちらもいずれ、修正させて頂きたいと思います。
>画面は停止しているように見えて常時監視ループを行うようなスクリプトは、
>かつてHSP2の頃に見られた書き方のようです。
>HSP2製のツール作品は何もしていないように見えて裏でawait 15が
>常時走っているものが多く、CPUを100%占有する仕様になっており、
>私も不本意ながら半ば割り切ってそのように書いていた記憶があります。
HSP2でこういった懸念を産んでしまったのは申し訳なく思います。
また、on系の命令の方が即時に実行されるというイメージがあることも理解できます。
ただ、他の方にも誤解のないように書いておきますと、今のHSP3でCPUスレッドを100%使用するのは
await 0のように極めて短い時間待ちを発生させた時だけで、1/60秒、1/30秒単位で
簡単な条件を判断するだけであれば、現在のWindows10が動作するPCの環境下では、
ほとんど問題にならない程度の負荷であると認識しています。
JavaScriptのsetIntervalが挙がっていますが、実はHSP3でもonintervalのような形で
一定時間ごとに呼び出す割り込みを実装したいと考えているところでした。
メインループという言葉の認識がおそらく違っているのではないかと思うのですが、
私はJavaScriptにはメインループというものは存在せず、決められた条件(イベント)で
呼び出されるサブルーチンだけで作るものと考えています。
メインループは、JavaScript内部で動いていて状況に応じて決められたサブルーチンを
呼び出す形になっているのが、イベント駆動の基本だと思われます。
(JavaScriptのsetIntervalは実行されるサブルーチンを登録するだけで、もともとのサブルーチンはreturnで終了します)
それに対してHSP3は、awaitやwait、stopという命令そのものがメインループの核に
なっていて、この命令の実行時にon系の割り込み呼び出しを行っています。
これらの命令は、メインタスクに処理を戻すだけで割り込みはシステムの共通なタスクで行っているものと考えがちですが、
実際には、awaitやwait、stop命令の中で必要に応じて割り込み先へgosub命令が実行されています。
つまりこれらの命令を起点にして1段深いサブルーチンができてしまうわけで、
いわゆる割り込みの再入ということになってしまいます。
そこがJavaScriptと大きく異なる点であり、逆に言えば呼び出しの順番が明確で
自由度が高い点という見方もできます。
ですので、gosubでサブルーチンを呼び出すこと自体は問題なく、割り込みの
サブルーチンとして定義された割り込みの中でメインループとなる命令を書くことが、
割り込みの重複を産む可能性があり、動作の予測が難しいので一般的には避けた方が
無難であるという趣旨であることをご理解頂けると嬉しいです。
mod_stbarモジュールについてのご報告もありがとうございます。
対応できそうならば、β3版に反映させたいと思います。

| |
|
2020/7/14(Tue) 21:19:28|NO.90985
>「getreq plat_form, SYSREQ_PLATFORM」の部分がmodule内なので実行されていない気がします。
おっしゃる通りでした。
Androidでも正常に動作しました。
すみませんでした。
|
|
2020/7/14(Tue) 23:12:29|NO.90986
mes関連が実機で正常に動作するようになりました、ありがとうございます。
win版の挙動もandroidに準じた動作となり、以前見えた表示ずれなども解消されています。
現時点でアプリのほかの部分に不具合は見られませんのでこれなら
環境を移してもだいじょうぶかなと思いました。
|
|
2020/7/15(Wed) 00:32:13|NO.90987
hsp36b3_200711.zip を解凍してAvastでスキャンしてみましたー。
検出はなくなりました。ご対応ありがとうございます。
引き続き開発よろしくお願いいたします。
|
|