HSPTV!掲示板

64ビット版ソフトを作るHSPへ、本格的に移行を初めて欲しいです！
下位互換性も大事だとは思いますが、HSPで作ったソフトを将来まで動かすことを考えた時、
そろそろ64ビットメインにした方がいいかと思います！
32ビット版アプリを作っても、はたしていつまで動くだろうか…と最近気になるようになりました。
ホビープログラマ界ではまだまだ32ビットは現役ですが
(というよりAMD64の仕様がめんどくさいので32ビットの方が楽)、
マイクロソフトのサポートや、マイクロソフトのリファレンスがもう64ビット中心になってきました。

HSP2とか3はそのまま残しといて、HSP4とかにして64ビット中心にするのはどうでしょう。
とにかくHSPもまだまだ長くつづいてほしいです。

私も64ビットになって欲しいですねー。
32ビットだとメモリ制限とか、現況と合わなさすぎな部分があるので。

過去のプラグイン類が使えなくなっちゃうのはあるので、互換性を重視するHSPにとっては難しいのかもだけれど。
出遅れすぎって言っても怒られない時代まで行っちゃってると思うのです。

hsp3_64仕様だと、intとポインターが32bitから、intが32bitでポインターが64bitになるので
インタプリタ側だけじゃなくてスクリプト側も対応が必要そうです。

intとは別にint64とfloat型追加して、dupptrやpeekやuselibやcfuncではint64を使ってというのは試作してみていて
C/C++を書きなれてる身としては普通なんですがスクリプト言語的なシンプルさは遠のきますね。
https://github.com/zakki/OpenHSP-fork/commits/ffi-types/

ポインタの扱いが変わるので全体的に仕組みの書き換えが必要になる部分なので
結構大変だと思われますが、私もそろそろちゃんと対応して頂けたほうがいいとは思ってます。
LongLongな変数も標準では無いんで、外部APIの64bit値がそのまま受け取れない問題もあります。

ですが、32bitとの互換性も維持してほしいと思っています。
HSP4では恐らくここに対応してくると予想しているのですが、
ネイティブコードに対応の予定があると聞いたので、
コンパイラで対応するんじゃないかと思っていたりします。

ただ、手軽にrunさせるためのインタープリタも捨てがたいですよね。

最新の説明書(スクリプトエディタでF1)の「HSP3 概要」をご覧ください。
以下引用します。

> HSP3.8
> HSP3.7で導入できなかった機能や不具合については、引き続きアップデート版を更新していきます。今後導入する予定として検討されている機能は、以下の通りです。(この順番で行われるということではありません。)

> HSP4
> HSP2が登場したのが1997年、HSP3はその8年後になりますが、時代の変化とともに次の世代に繋げることができればと考えています。 プログラミングに求められている状況も変わってきています。HSPの手軽さを継承した上で、ある程度互換性をカットして使いやすいものを、この先ロードマップとして発表していければと思っています。
> 現在検討しているのは、完全なUTF-8、64bit対応、コード自動解析と学習機能、VMの刷新(llvmなど)、ネイティブコンパイル(JIT)などになります。

No.104001とかほかスレッドのNO.104003は生成AIのスパムですね…
それをきっかけで盛り上がっているようなので複雑ですが

ほんとだwww リンクは気にしてませんでした。

めっちゃ前の書き込みへ　皆さんレスありがとうございます！

スクリプトの仕様が複雑になっちまったら大変ですけどとりあえず待ちます！

ゲーム作ろうとして開発環境をいろいろ見てますが、
自分で作ったライブラリ→3Dのモデルファイル読み込みが無理(.x形式は古いし、.xを吐けるモデリングソフトも減ってきたし、glTF2.0は読み込みがムズイ)
Unity→プロジェクトを開いたりバックアップとりにくい。有名なのにバグリやすい
godot→作りにくい、バージョンアップしまくりで保守しにくい
HSP→3Dやりにくい
なのでそれぞれ難しいところがあります。

便利に思っている人もいるでしょうけど、個人的にはC++をいじって仕様が変わっていくのやめてほしいですｗ
それはC#とかスクリプト言語とかよそでやってくれｗ

とにかく作りやすさではHSPが一番上だと思ってます。
最近PCがさびれていってる感がありますがHSPも脱落せずに続いてほしいです。

> iemon さん
>64ビット版ソフトを作るHSPへ、本格的に移行を初めて欲しいです！

私も64bit化に賛成です。

HSPの64bit化は「使えるメモリが増える」という効果以上に、心理的にHSPの古臭いマイナスイメージを払拭する普及効果が期待できます。
また、最新の64bit環境に以降することにより「将来においても安心してHSPを使える」という宣伝効果もあるでしょう。
ただし、64bit化以降の際には、32bit版ユーザーに配慮し、移行しやすい仕組みが不可欠です。

コレは私の勝手な推測なんですが

HSP4（仮）で32ビット対応を切って
Windows10 64ビット以降対応、UTF-8専用
dish系等もこの辺りを軸にして継承

(※HSP3.7x(?)系の上位互換もありがたいですが
作業量的に問題があるのと、考えずに64ビット/UTF-8
が扱えると言うメリットは失われる)

↑のdll等を整備する当分の間はHSP3.7x(?)と併用する形で
移行期間を設けてHSPは動いていくのかなと
（例えるならHSP2とHSP3の時の様に）

上にも引用で書きましたが、
その方向みたいなので安心して待ってます♪
コンパイラで32/64bit両立できると思いますよ。
HSP3Dish Android とかそうなってますから。
問題はdllとの互換性とかですかねー。

>>便利に思っている人もいるでしょうけど、個人的にはC++をいじって仕様が変わっていくのやめてほしいですｗ

ちなみにこれはC++20とかの規格の事です。
Micorosoft公式のAPIとかがスマートポインタとかになって
だんだんメモリ管理がガベージコレクションぽくなっていったりしていくのがイヤですｗ
メモリ管理自分でやりたいからC++とか古い言語使ってるのに…

>>HSP4
よりシンプルになるなら、HSP4では中身をバリバリ一新してくださってもよいです。

ゲーム用の3Dモデルファイルは悩みのタネですが、microsoftが.xの代わり(サンプル用というか)
として出した.cmoファイルは結構シンプルな構造で良かったです。
https://github.com/microsoft/DirectXTK/blob/main/Src/ModelLoadCMO.cpp
自分は実際に使うところまでやっていないので、メッシュデフォームとかできるかどうかはわかりません。
.cmoはvisual studioで.fbxから変換して作るという…

>>3D
開発労力がぢこくですが、
ゲーム用のポリゴンデータって結局、
1・自前でレンダリングする
2・それに合わせた3Dファイルフォーマットを自前で作成する
3・「1・」を使って「2.」のファイルフォーマットを作れる3Dモデリングソフトを自前で作る
てやるしかない…
しかし一度ここまでやれば、ずっと使えそうなのは良いです

ちょっと趣旨からずれてしまいますが、個人的には(さらなる)Linux対応をしてほしいなぁと。

最近Windowsに追加された Smart App Controlっていう機能が問題で、
・デジタル署名がないexeの実行をすべて阻止
・解除には管理者権限が必要
・解除するとWindowsを再インストールしないとONに戻せない

というものがあって...。

PCは自由にバイナリを動かせてこそということを踏まえると、今後はプログラミングの主役はLinuxに移るんじゃないかなぁと思ってます。

できればフォント内蔵の.AppImageにビルドできたらいいなぁ

補足
プログラミングの主役は -> 人による趣味プログラミングの主役は

以前、書いていたやつをv3.7ベースに更新しました。
たぶんこのまま次期64ビット版に入ることはなくて実験的な扱いですが、ドックフード食べる人は試してみてください。

現状は、uselibの返り値でint64を扱いたい場合は、#funcで定義してstat64を見る必要があって、#cfuncでの返り値はint32のままです。
また配列長や文字列長はint32のままなので、単一変数は依然32bit制限が残ります。
hsp3.exeでint64変数は扱えなくして、hsp3_64.exeだけにするならstat64新設じゃなくてstatやcfuncの64ビット化もありかなと思います。

変更点
* int64型を追加
* ポインタやハンドルのシステム変数をint64に変更
* 64ビットのstat64システム変数を追加
* int64型に変換するためのint64()関数を追加
* varptr, dupptr, hwnd, hinstance, hdc, wparam, lparam をint64に変更
* hsp3_64で外部dll呼び出しをlibffi実装に変更

制限
* 既存プラグインと互換性がない
* HSPCTX, HSP3TYPEINFO, IRQDAT のレイアウトが変わる
* HSPVAR_FLAG_USERDEF, HSPVAR_FLAG_MAX が変わる
* hspcmpでint64リテラル非対応で、int64("12345678901234567890")のように文字列経由が必要

ソース: https://github.com/onitama/OpenHSP/compare/master...zakki:int64-hsp64?expand=1
バイナリ: https://github.com/zakki/OpenHSP-fork/actions/runs/23340468032