最新の20件
2020-04-07 2018-12-11 2017-09-13 2017-09-12 2017-09-05
  • Total:223/Today:1

NO.77661 †

  • screen命令での新規画面生成は、

Macやモバイルではかなり苦しいので、

その辺りの仕様は、お手柔らかにお願いします。

（第一パラメーターを廃止あるいは非推奨に・・・）

syscolorやsysfontの互換性も悩ませるところです。

システム依存の色やフォントの違いは、許容範囲だと助かります。

mouse命令は便利ですが悪用されると面倒な命令なので、非推奨の方向で・・・。

getkeyやstick命令は、

デスクトップとモバイルでの互換性が気になります。

最近はマルチタップも普通になってきたので、

その辺りをどうするかも。

あとモバイルは基本的にファイルへのアクセスをある程度制限をしてるので、

notesaveやbsaveやbmpsave、

bloadやnoteloadやmmloadやpicloadなどファイルアクセス系の、

扱い方も気になるところです。

run命令もファイルアクセスの関係で少し不安の残る命令です。

widthはOpenGLで実現しようとすると少しやっかいな命令です。

on...系命令はlparamやwparamに与えられる値の互換性が気になります。

line命令やmes命令でのアンチエイリアシングを許容するか、

あるいはアンチエイリアシングなしを強制するのか気になります。

mmloadやpicloadで扱える形式も環境に依存しそうなので、

その辺りの仕様もあるといいかな、と思います。

  • dolphilia氏　2016/12/20(Tue) 11:22:32
↑

NO.77671 †

  • dolphiliaさん、ありがとうございます！

私自身は技術的な知見が浅いので、ご意見伺えて幸甚です。

おかげさまで一気に具体的な方向へ話が進んだようです。

ご要望の事項ですが、さしあたりで検討してみますと

＞ screen命令

screen 0,640,480

TinyHSPでは第一パラメータは0番しか指定できません。

（簡便さだけでなく、ウィンドウGUIのない環境に対する仕様でもある）

screen 1 とか 2 とか 0 以外にしたときの挙動は、

　①buffer 1 とか buffer 2 とかと同義にするのか？

　②screen 0 と同義にするのがいいのか？

　③エラーとするのか？

などいろいろと考えられますが、個人的には①がHSPらしく

第一パラメータも削らずに済むのでベターかと思います。

screen命令自体を書かなかった場合は暗黙の画面サイズが設定されるようにするなど

さしさわりのない仕様は通常のHSP準拠でよいと思っています。

なのでTinyHSPのソースは通常のHSP上でほぼそのまま動かせるものと想定しています。

（逆は難しい場合が多いでしょうが）

＞ システム依存の色やフォントの違い

システム依存部分は表示が異なってもOKと考えてます。

例えば実行したときに表示される色やフォントが各環境で異なったとしても

同等(あるいは最も類似する)の機能が呼び出されているのであれば

それでかまわないと考えています。

＞ mmloadやpicloadで扱える形式

扱える画像は bmp,png,jpg 音声は wav,mp3 のみにする。

＞ mouse命令

少なくとも Tiny の仕様はマルチタップなどは不要、最小限のマウス操作と

それに合わせたタッチ操作ができればよいのではないでしょうか。

＞ getkeyやstick命令

アルファベット、カーソルキー、ESC, BS, Shift キーなど

代表的なキーコードだけ各環境で合わせるようなイメージでおります。

例）Android のキーイベント

https://developer.android.com/reference/android/view/KeyEvent.html

＞ ファイルへのアクセス

フルパスの指定はもちろん可能とし、ファイル名のみ指定した際の

ディレクトリが各環境で同義になればいいかなーと思っています。

例えばWindowsならexeや実行ソースのあるカレントパス。

AndroidならSDカードに tinyhsp/files なんて読み書き可能なディレクトリを

作成しておいてカレントパスとするなど。

＞ width

削っちゃっていいかもしれません(^_^)

以上、答え切れてないと思いますが、皆さんの要望・見解も頂けると助かります。

  • kikeroga氏　2016/12/21(Wed) 15:58:09
↑

NO.77672 †

  • このtinyhspは、どの環境でもソースが同じということは、

Javaのように仮想マシンを用意する形になるのですか？

また、axファイルやdpmファイルはhsp準拠にしますか？

  • kanamaru氏　2016/12/21(Wed) 17:13:56
↑

NO.77687 †

  • kanamaruさん、コメントありがとうございます(^_^)

＞ Javaのように仮想マシンを用意する形になるのですか？

仮想マシンと呼ぶかはともかく、環境ごとにランタイムエンジンを用意するかたちになると思います。

＞ また、axファイルやdpmファイルはhsp準拠にしますか？

準拠でいけるような気はしてます。

ただ、細かいところで「ここはどうする？」「こんなときどうする？」という

シーンが環境ごとにあるかと思いますので、そのあたりを皆さんと出し合って

あれこれ検討出来たらと思っています。

  • kikeroga氏　2016/12/22(Thu) 09:43:13
↑

NO.77689 †

  • ご回答ありがとうございます。

少しでも助けになればと思い、再びコメントします。

  • 開発環境について質問・提案します。

TinyHSPは開発環境を包含するでしょうか。それともエンジンのみの実装となりますか。

包含するとしたらエディター、ヘルプマネージャー、HSPTV、デモ、Peasエディター、その他ヘルパーツールなどどこまでをサポートするでしょうか。

エディターを含めるとすれば、その機能についての具体的な仕様があればいいなとも思います。

  • 当スレッドの現時点までのまとめを作りました。

PDF:

http://hsp.dolphilia.com/tinyhsp/tinyhsp_20161222.pdf

DOCX:

http://hsp.dolphilia.com/tinyhsp/tinyhsp_20161222.docx

Markdown:

http://hsp.dolphilia.com/tinyhsp/tinyhsp_20161222.md

自由に追加編集等していただければと思います。

  • dolphilia氏　2016/12/22(Thu) 14:23:08
↑

NO.77734 †

  • sakuraさん、一覧の追加更新ありがとうございます！

Linux版の命令を分かる範囲で追加させていただきました。

http://hsp.dolphilia.com/tinyhsp/hsp_commnd_20161227_10e.zip

Linux版でマクロ等を使うには、

以下のファイルを明示的にインクルードする必要があるかもしれません。

  • hsp3util.as
  • hspdef.as
  • hspmath.as
  • kikerogaさん、コメントありがとうございます！

LinuxのWineについてはわかりませんが、

Macを使っているHSPユーザーさんによると、

"macOS 用の Wine は ... 現時点での最新の 1.9.23 から遡ること 1.9.9 まで、HSP が利用している API がうまく動いてくれないようなのです。"

http://www.sharkpp.net/blog/2016/12/01/hsp-advent-calendar-2016-1st-day.html

とのことです。

同時に、Wineを使って開発をしていらっしゃるようなので、

Wineの実用性は十分あるように感じています。

以前にMac版HSPを公開した時、

HSPの「Linux版も作って欲しい」という声があったので、

ネイティブで動作するLinux版HSPの需要はあると思います。

  • TinyHSPの命令について、

もう少し詳しく検討したいと思っています。

  • 省く方向で考えている命令
  • mouse マウスカーソルの表示位置指定
  • width ウィンドウの表示サイズ・表示位置の指定
  • run 指定したHSPのAXファイルに制御を移す

以上の命令は一覧から省く方向でいこうと思っていますが、いかがでしょうか。

  • 再考したい命令
  • #cmd 拡張キーワードの登録
  • cnvwtos UnicodeからShiftJISに変換
  • cnvstow ShiftJISからUnicodeに変換
  • mref 特殊なメモリを変数に割り当て
  • dupptr ポインタからクローン変数を作成
  • palette, palcolor パレット設定
  • onclick, oncmd, onerror, onexit, onkey 割り込み

以上の命令は特殊な命令・移植の難しそうな命令なので、

TinyHSPに加えるか再検討していただきたいのですが、いかがでしょう。

on...系命令は、hsp3dishには一部含まれていないようですが、

とても便利な命令なので、悩むところです。

  • 加えても良いような気のする命令
  • setease, getease, geteasef

これらの命令は移植が容易だと思われるので、

念のため、再検討をお願いしたいと思っています。

  • これはWeb版HSPに詳しい方にお伺いしたい点なのですが、

emscriptenはOS固有のAPI、例えばWin32APIなどは動くのでしょうか。

OpenHSPからJSに移植する上でのポイントや難所はあるでしょうか。

WebAssembly?は実用的でしょうか。

教えていただけると、とても助けになります。

  • dolphilia氏　2016/12/27(Tue) 16:48:11
↑

NO.77751 †

  • dolphiliaさん、誠にありがとうございます。

今にも開発に取り掛かってくれそうな勢いを感じます(^_^)

実はTiny BASICの精神を受け継ぎたいという多少懐古な想いもあって

RUN命令はあまり明確な理由もなく残したい気持ちがあったりするんですが、

この命令を省きたい理由って何でしょうか？

各環境でネイティブ動作するユーザ実行ファイルを作るわけではないので

RUN命令の実装が難しい印象はないのですが、ご教示いただけると幸いです。

また、すべての変数を初期化して、制御を完全に別のプログラムに移すという

RUNを代用できる命令って他にはなかったと思いますが、必要性はないでしょうか？

省くことに反対しているわけではないです、念の為(^_^)

それ以外は個人的には異論なしです。

mouse, width 他、特殊な命令・移植の難しそうな（環境依存するような）命令は

そもそもTinyHSPの方針にそぐわないので省いちゃってよかろうと思います。

"Tiny"の目的からいえば命令数が減るのは美点でもあると思いますし、、、

ちなみに palette, palcolor って、あまり必要性ないんですかね？

setease, getease, geteasef については各環境で動かすのが容易なのでしたら

あったほうがもちろん良いと考えます。

on...系命令など、なかなか決めかねる要検討の命令があれば、

開発の妨げにならないよう、さしあたりは仕様上"保留"として実装せずに

進めていってもよいのでは？と思っています。

他の皆さんはどうお考えでしょうか？

以上、よろしくお願い致します。

  • kikeroga氏　2016/12/29(Thu) 12:26:55
↑

NO.77762 †

  • 資料を更新しました。

ダウンロード

↓

http://hspnext.com/download/hsp_commnd_20161230_11.zip

dolphiliaさん、Linux版の○付更新、ありがとうございます。

kikerogaさん、10年ぶりぐらいお久しぶりです。

資料を整理していて思ったのですが、HSP3Dishやコンパクト版(hsp3c)と変わらなく

なっていくのではないと思うのは、私だけでしょうか?

環境依存が少なく、移植性に優れ、ソースコードレベルで完全互換・・・・

何かもっとインパクトのあるメリットやアイデアが必要のような気がします。

命令中心に絞っていくと既存のものと変わらなく、帯に短したすきに長しのように感じます。

また、WindowsAPI呼び出しがあると互換性維持の面での検討が必要と思います。

  • sakura氏　2016/12/30(Fri) 13:13:59