16:10:55|NO.77515詳細は以下資料を参照ください。TinyHSPの提案_20161208.ziphttp://ux.getuploader.com/kikerogaupl/download/66/TinyHSP%E3%81%AE%E6%8F%90%E6%A1%88_20161208.zipこんなHSPあればいいなという単純な思い付きであり、願望なのですが賛同・協力いただける方がいれば嬉しいです。発信をと思い、書き込みました。気長に進めていければと思っています。現状のHSPが既にWin、iOS&Android、Web(JS)といくつかの環境の上で動いているので、TinyHSPがHSP自体とどれくらい差異があって、コンパクトである利点がどれぐらいあるのか、の熱量がちょっと図りかねるところがありました。言いつつ、クリーンなHSPがあると嬉しいことは個人的には多分にあると思ったので、興味あります!私自身あんまり技術力ないので、開発にどれくらい貢献できるかは謎ですが、ひとまず話は聞いてみたいです。13:18:17|NO.775663kさん、コメントありがとうございます。現状既にWin、iOS&Android、Web(JS)といくつかの環境でHSPがありHSPの知識は各環境で開発する際には十分に活かせると思います。移植にはそれぞれの環境に合わせた修正が必要になりますよね。選ばない)を実現したいと思っています。資料にあるTiny命令だけでプログラムを組んだとしても各環境で完全に同じ動作はしないと思っていて、そこを合わせるのがTinyHSPになるかなぁと。Tinyという名称にも由来しますが、命令数をしぼって少なくするのも憶えやすそうとか、印象も実装も軽いとか、利点ととらえてます。コンパクトである利点がどれぐらいなのかは私自身も検討できてないですが個人的な想いが発端なので、こういうものが好きな人たちで楽しみながら進められたら良いなと考えてます。00:04:35|NO.77572興味深い提案をありがとうございます。ランタイムのバリエーションなどで色々と仕様が増えているHSPにおいて、複数プラットフォームで共通の仕様で動作する(クリーンな)形を目指すのは良いことだと思います。広げた風呂敷を畳むような感じでしょうか。現在、HSP3Dishもありますが、開発環境も含めた形で方向性が見えるといいなと感じています。広げた風呂敷を畳むような感じ言われて初めて気づきました。ような感じはありますね。ご意見いただいて、あとは作るだけ、くらいまで仕様のイメージが固まるといいなと思ってます。15:14:32|NO.77638一からソースを書くということでしょうか?それともOpenHSPの派生になるのでしょうか?OpenHSPからの派生になると、実装が楽というわけにはいかないと思います。言語仕様が多少変わることも含めてTinyHSPということでしょうか?どちらにしても協力したいと思います。11:06:38|NO.77644tds12さん、コメントありがとうございます。それともOpenHSPの派生になるのでしょうか?個人的にはOpenHSPのソースから改修したほうが既に知見をお持ちの方が多いこともあり、メリットが多いんじゃないかなーとは思ってます。OpenHSPからの派生になると、実装が楽というわけにはいかないと思います。仕様、ソースとも新たに作る部分は出てきますね。言語仕様が多少変わることも含めてTinyHSPということでしょうか?ご認識の通りです。どちらにしても協力したいと思います。ありがとうございます。21:04:02|NO.77646面白そうなご提案だなあと思って見ていました。何ができるかは謎ですが、手伝えそうなことがあればお手伝いしたいなと思っています。メリットが多いんじゃないかなーとは思ってます。横からで申し訳ないのですが、個人的には1から書いた方がよりコンパクト・クリーンになって何かとやりやすいんじゃないかなと思います。あと、個人的にはプラットフォーム間の互換性の他にも、本家より小さい分実行速度も速いみたいな+αがあるとさらに魅力的かなと思いました。10:37:02|NO.77660undef32さん、コメントありがとうございます。ソースについてはTinyHSPの仕様を前提にベストなやり方ができるといいですね。書き方についてはそんなにこだわっていません。コンパクト・クリーンなソースなら見易さ、理解のしやすさも手伝って、移植もメンテもやりやすくなるでしょう。早い、軽い、というのは魅力の一つでもありますね。TinyHSPの特徴(メリット)を維持するには下記2点を厳守することが大切だと思っています。・絶対!機能拡張しない(...守れるのか?)・異機種間の互換性重視(ソース/中間言語レベル)ご興味がある方には思い付きでも、ただのご賛同でもかまわないので、どんどんコメントください。アイデアや留意することなど、何でも出し尽くさないと良い仕様にならないと思いますので。11:22:32|NO.77661少しでも助けになればと思い、コメントします。Mac版HSPを作った際の、OpenHSPのLinux版からコンパイラとエンジンを分離したソースが残っていました。コンパイラ:https://github.com/dolphilia/hspcmp-macosx/tree/master/01_start/srcエンジン:https://github.com/dolphilia/hsp3cl-macosx/tree/master/01_start/hsp3cl(コンパイラはこのままmakeすればOKで、エンジンの方はmakefileを書き直す必要があります)ほとんどの命令・関数が、hsp3gr.cpp(描画系)hsp3int.cpp(関数など)で定義されています。----仕様の方、拝見しました。オブジェクト制御命令はごっそり削ったんですね。これなら実装はかなり容易なはずです!描画部分はHSP3DishのようにOpenGLでいけるので、モバイル対応もすんなりいけそうです。(あるいはHSP3DishがTinyHSPに準拠しているとも言えなくもないですね)---以下は要望です:screen命令での新規画面生成は、Macやモバイルではかなり苦しいので、その辺りの仕様は、お手柔らかにお願いします。(第一パラメーターを廃止あるいは非推奨に・・・)syscolorやsysfontの互換性も悩ませるところです。システム依存の色やフォントの違いは、許容範囲だと助かります。mouse命令は便利ですが悪用されると面倒な命令なので、非推奨の方向で・・・。getkeyやstick命令は、デスクトップとモバイルでの互換性が気になります。最近はマルチタップも普通になってきたので、その辺りをどうするかも。扱い方も気になるところです。run命令もファイルアクセスの関係で少し不安の残る命令です。widthはOpenGLで実現しようとすると少しやっかいな命令です。on...系命令はlparamやwparamに与えられる値の互換性が気になります。line命令やmes命令でのアンチエイリアシングを許容するか、あるいはアンチエイリアシングなしを強制するのか気になります。mmloadやpicloadで扱える形式も環境に依存しそうなので、その辺りの仕様もあるといいかな、と思います。15:58:09|NO.77671dolphiliaさん、ありがとうございます!私自身は技術的な知見が浅いので、ご意見伺えて幸甚です。おかげさまで一気に具体的な方向へ話が進んだようです。0,640,480TinyHSPでは第一パラメータは0番しか指定できません。同義にするのがいいのか?�エラーとするのか?などいろいろと考えられますが、個人的には�がHSPらしく第一パラメータも削らずに済むのでベターかと思います。screen命令自体を書かなかった場合は暗黙の画面サイズが設定されるようにするなどさしさわりのない仕様は通常のHSP準拠でよいと思っています。TinyHSPのソースは通常のHSP上でほぼそのまま動かせるものと想定しています。システム依存の色やフォントの違いシステム依存部分は表示が異なってもOKと考えてます。実行したときに表示される色やフォントが各環境で異なったとしても同等(あるいは最も類似する)の機能が呼び出されているのであればそれでかまわないと考えています。仕様はマルチタップなどは不要、最小限のマウス操作とそれに合わせたタッチ操作ができればよいのではないでしょうか。キーなど代表的なキーコードだけ各環境で合わせるようなイメージでおります。ファイルへのアクセスフルパスの指定はもちろん可能とし、ファイル名のみ指定した際のディレクトリが各環境で同義になればいいかなーと思っています。Windowsならexeや実行ソースのあるカレントパス。なんて読み書き可能なディレクトリを作成しておいてカレントパスとするなど。width削っちゃっていいかもしれません(^_^)以上、答え切れてないと思いますが、皆さんの要望・見解も頂けると助かります。Javaのように仮想マシンを用意する形になるのですか?仮想マシンと呼ぶかはともかく、環境ごとにランタイムエンジンを用意するかたちになると思います。axファイルやdpmファイルはhsp準拠にしますか?準拠でいけるような気はしてます。細かいところで「ここはどうする?」「こんなときどうする?」というシーンが環境ごとにあるかと思いますので、そのあたりを皆さんと出し合ってあれこれ検討出来たらと思っています。14:23:08|NO.77689ご回答ありがとうございます。助けになればと思い、再びコメントします。----開発環境について質問・提案します。TinyHSPは開発環境を包含するでしょうか。それともエンジンのみの実装となりますか。包含するとしたらエディター、ヘルプマネージャー、HSPTV、デモ、Peasエディター、その他ヘルパーツールなどどこまでをサポートするでしょうか。エディターを含めるとすれば、その機能についての具体的な仕様があればいいなとも思います。----当スレッドの現時点までのまとめを作りました。PDF:http://hsp.dolphilia.com/tinyhsp/tinyhsp_20161222.pdfDOCX:http://hsp.dolphilia.com/tinyhsp/tinyhsp_20161222.docxMarkdown:http://hsp.dolphilia.com/tinyhsp/tinyhsp_20161222.md自由に追加編集等していただければと思います。01:51:17|NO.77690dolphiliaさん、ありがとうございます!以下、あくまで私の考えですが。TinyHSPは開発環境を包含するでしょうか。あればオールインワンで親切ですが、特に開発環境を包含する必要はないと考えます。エンジンのみの実装、あるいはコンパイラとエンジンのみでよろしいかと。TinyHSPであることの仕様は最低限(コンパイラとエンジン)でよいと思います。マルチプラットフォームへの展開をできるだけ楽に、簡潔にするという思惑もあるのですが、コンパイラとエンジン以外の部分については、作っても作らなくてもかまわない。そのあたりの充実不実は、実際に個々の環境で開発する方々に委ねていいと思ってます。個人的に、専用エディタやヘルプなどはもちろんそろっていたほうが、ビギナーが始めるときのお手軽さは増すとは思いますし、HSPらしいなーとも思います(^_^)がそれはそれ、プログラミングの環境を充実させるのは仕様とは別のお話かなと。「HSPランタイム別命令一覧」を作成して見ました。自由に編集して、加筆・修正して利用して下さい。Console版(hspcl)とLinux版はドキュメントを探し切れなかったので未完成です。どなたか、埋めてくれませんか?Excelとpdf化したzipファイルを下記に置いてあります。18:29:38|NO.77699すみません(@@;少し、見直したら抜けがあったので追記しました。対応命令の印付けも不完全ですので、仕上げにご協力願います。19:48:38|NO.77700kikerogaさん、ご回答ありがとうございます。http://hsp.dolphilia.com/tinyhsp/tinyhsp_matome_20161224.zipさっそくまとめに反映させました。----sakuraさん、すばらしい貢献です!HSPランタイム別命令一覧、さっそく差替版を使わせていただきました。引き続き、自由に編集して、加筆・修正して利用していただければと思います。22:54:06|NO.77708dolphiliaさん利用して頂いて、ありがとうございます。完全なドキュメントが少ないので、まだまだ、メンテが必要です。22:41:23|NO.77723console版に○印を付けて見ました。Linux版は、OpenHSPのソースを見て見ると2004年6月から更新されていないのですね。Wineで動かせるという記事を見たので、今後はLinux専用のランタイムというよりWineやVimの環境を利用するのがよいのかなぁと思います。11:57:56|NO.77728sakuraさん、dolphiliaさん、諸々ありがとうございます。