HSPTV!掲示板

スレッド一覧 | 新規書き込み | 新着一覧 | 使い方 | 過去ログ

未解決

解決

停止

削除要請


	2025 0703	hkr	2Dのゲームを作る	26

hkr

2025/7/3(Thu) 20:41:27|NO.103595

現在HSPの標準命令のみで2Dのゲームを作成しています。
スプライト周りも自作描画ルーチン（gcopy,gzoom,grotate）を使用して描画しています。
一通り完成してDirectXに対応させようとしましたが、どのライブラリを使っていいのか見当もつきません。
とりあえずHSPDXFIXを使えばそのまま移行できるか？と思いましたが、es_ini命令でいきなり「外部DLLの呼び出しに失敗しました」
ちなみにHSPDXFIXは昔使ったことがあるのですが、当時動作していたプログラムも久々に起動したら同じエラーで全滅していました。
次にHSPDISHを使おうとしたらgcopy,gzoomはなんとかなってもgrotate命令の移行先がない状況です。
とりあえずHSPDSFIXが動けばどうにかなりそうな気がするのですがもう時代遅れの空気も漂ってるし…

現状2Dゲームに関して、今時の環境でどうやって動かしているのでしょうか？

この記事に返信する

へびぃ

2025/7/3(Thu) 21:25:21|NO.103597

わたしも2Dゲームをいろいろ作ってますが、昨今のPCだと基本能力が高いので標準命令だけでも色々出来ちゃいますよね。

自作描画で作ったのならDXに移行する意味がよくわからないですが、DXじゃないけどDishでもスプライトの回転は可能ですよ。
es_setrotで出来ます。

”標準スプライト”としての概要はこちらをご覧くださいませ↓
https://www.onionsoft.net/hsp/v36/doclib/sprite.html

hkr

2025/7/3(Thu) 21:32:50|NO.103598

ありがとうございます。
前述の通り現状で描画エンジンが完成してしまっているので、
スプライト命令を使い始めるとほぼ作り直しになってしまうので避けていたんですよねー。
あと内部的にスプライトと背景を同列に扱っているのもスプライト命令を使いたくない原因です。
HSPDX系ならcopyもzoomも頭にES_を付けるだけ（？）でコンバート出来そうなふいんきだったのですが、
まさかrotate命令のみハブられているとは…

hkr

2025/7/3(Thu) 21:42:31|NO.103599

ちなみになんでDXに移行しようとしているのかというと、まー厳密には違いますが
アフターバーナーII並みのオブジェクトをgrotate等で表示させるとやはり重いからですｗ
１０年前とかと違って今時のPCで2D表示だけでゲームを作る場合、CPUパワーででごり押すのと
GPUで描画するのではあまり差はないもんでしょうか？
とりあえず「スプライト制御機能」には全く期待していないのですが、多少なりと速くなれば
いいなぁくらいの感覚だったのですが、ここ数日HSP.TVのページを解決策を求めて色々探して
みたのですが、とにかく古いドキュメントが未更新でずーっと残ったままになってて、
公式ライブラリの何が使えて何が現状使えないのか分からず困ってました。
これだと「ご新規さん」のとっかかりもかなり厳しいかもしれませんね…

名無し

2025/7/3(Thu) 21:55:19|NO.103600

>とりあえずHSPDXFIXを使えばそのまま移行できるか？と思いましたが、es_ini命令でいきなり「外部DLLの呼び出しに失敗しました」
これ、前に同じような質問を見た気がして調べて見たところ、
https://www.hsp.tv/play/pforum.php?mode=pastwch&num=92351
こちらが見つかりました。これと同じ原因だったりしませんか？
既にご自身で調べていてこちらも確認済みかもしれませんが...。

hkr

2025/7/3(Thu) 22:26:50|NO.103601

ありがとうございます。動作しました！
アーカイブのlzhに入ってたドキュメントを読んでMSVCR71.dll をC:\Windows\System32に
入れてはいたのですが、これ、HSPのフォルダにもコピーしておかないと動作しないんですね…

あと、先ほどのスレッドにDishはHSPDXの上位互換的な書かれ方をしていたのですが、
それなら最初からそっち使えよ！との葛藤があったり…
DishやHGIMG系との命令の互換表とか・・・
も、公式サイトのどこかを探せば存在するのでしょうか？(;´･ω･)

2025/7/3(Thu) 22:35:15|NO.103602

基本DirectX使ってはないです
やりようとジャンル次第かと

https://youtu.be/b200WiM15LM

hkr

2025/7/3(Thu) 22:51:56|NO.103603

ありがとうございます。

やっぱりそうですかねー？
一応今昔作ったプログラム（hspext.as DirectDraw系）を動かしてみたのですが、
スクリーン初期化命令が動作しませんねー

そもそもWin11にDirectDrawが入っていないのが原因だと思うのですが、
Win10時代だと「もう古いから使うの辞めない？どうしてもってなら入れるけど…」
とダイアログが表示されて自動インストールされたと思うのですが、Win11のこのご時世、
既にこの機能削除されてるんですかね？ｗ

TOMATO

2025/7/4(Fri) 07:43:54|NO.103604

>アーカイブのlzhに入ってたドキュメントを読んでMSVCR71.dll をC:\Windows\System32に
>入れてはいたのですが、これ、HSPのフォルダにもコピーしておかないと動作しないんですね…

64bit版WindowsでHSPが32bit版の場合は
C:\Windows\SysWOW64
にDLLを置かないとダメかと思います。

64bit版Windowsの場合、C:\Windows\System32は64bit用DLLの置き場なので。
（名前が紛らわしいけど）

hkr

2025/7/4(Fri) 21:10:44|NO.103605

あーそれでしたか・・・orz

一応ライブラリ動作はしましたので解決にしておきます！
ですが…今回の件での自分の見解は
「現在のWindows11の環境で2Dのゲームを作る場合、
処理速度を稼ぐ一点に置いてGPU支援系のライブラリを使用するのは
ほぼメリットがない」
という結論でしたorz

窓月らら

2025/7/4(Fri) 21:34:24|NO.103606

解決済ですが、個人的にはGPU支援は2Dでもメリットはあると感じる部分ではあるのですが
現在の最新版(HSP 3.7RC1)であれば、HSP3Dishなどを使うことで自動的にDirectX対応になって
高速描画することが可能ですのでお試しください。
ただし・・・現状ではオフスクリーンバッファが無いなどの違いはあります。
HGIMG3からは標準ランタイムに内蔵される形になって、現在ではHGIMG4/HSP3Dishは外部DLLが
不要でDirectX/OpenGLが使えるのでご検討されてみるといいと思います。

窓月らら

2025/7/4(Fri) 21:44:15|NO.103607

ちなみに HSP3Dish でも grotate はサポートされておりますので移植は可能だと思われます。
試せばわかりますが、grotate で重たくなったりも特に感じないと思います。

hkr

2025/7/5(Sat) 07:58:25|NO.103608

ありがとうございます。

とりあえずHSP3DISHのマニュアルでも見てみようと思ったのですが…

https://www.onionsoft.net/hsp/v35/doclib/hsp3dish_prog.htm

この自分の喋りたい項目だけ喋る、いわゆる「早口で喋るオタク」状態のドキュメント
は新参にはかなり厳しい気がしますねー
なんのとっかかりもないままイキナリボタンの解説されたり…

それじゃぁコマンドリファレンスを検索・・・したらサポートページに戻ってくるし、
とりあえずコマンド一覧を見ようと思ったらリンク先が

https://www.onionsoft.net/hsp/v33/doclib/support_cmds.txt

・・・これは・・・書籍を買わなきゃならんのでしょうか・・・？
それとも実は別の場所にもうちょっと理解しやすい公式ドキュメントが存在する？？？( ;∀;)

hkr

2025/7/5(Sat) 08:25:52|NO.103609

すいません、スレッドのタイトルとは多少離れるかもしれませんが…

今回HSP標準命令からのステップアップを試そうとして感じた事なのですが、
「HSP3標準命令でゲームを作る」から「HGIMG3/4/Dish系に移行する」の
流れが不明瞭すぎて、実際に検索すると袋小路に入りまくるのです。

こちらは単純に「gcopy」「gzoom」「grotate」の3点だけ使えれば（厳密にはscreen,bufferも）
なにも困らないのですが、ほとんどのドキュメントは3D表示命令/スプライト管理命令が
氾濫していて取捨選択のとっかかりも出来ない状態です。
もちろん当初から「HGIMG3/4/Dish」ありきで開発を始めればよいのでしょうが、順当な流れとして
最初は「HSP標準命令のみ」でゲームを作成しているので、キャラクタもすべて自前管理しています
なので、後からこの「ファミリーベーシックのスプライト」みたいな半自動制御に移行するのは
厳しい感じです。

ソシャゲの「最先端はどんどん先鋭化していくけど新参には厳しい世界」という感覚でしょうか…

2025/7/5(Sat) 10:29:52|NO.103610

レトロ風なら何もいらないかも

へびぃ

2025/7/5(Sat) 10:35:09|NO.103611

あぁ、すごく共感しますｗ

わたしも色々試した結果、2Dゲーム制作は、基本的に標準命令だけで行くっていう方向になってしまいました。

3Dやスプライトなど、公式ドキュメントとか見ると、超簡単ですごいの出来るじゃん♪って思うけど、実際は、大部分が未実装だったり、仕様に制限がありすぎたりでほぼ使えなかったりしますから。
おにたまさんが1人で制作されているので、無理があるのはすごく理解できますけど、裾野を広げすぎて、結果どれも中途半端（未完成）になってしまってる感があるかなと思います。

まぁ、わたしはN88BASIC時代の老害なので、HSP3が好きだから良いんですけど、若い世代の方だとたぶん無理ってなっちゃうと思う。。。

hkr

2025/7/5(Sat) 19:13:19|NO.103612

しょうがない、ライブラリは古いけどHSPDXFIXでなんとかしようと作り始めましたが、
gsquare命令に相当するes_コマンドが存在しなくて頓挫しましたorz
結局最初からライブラリありきで作成しない事には…

BASICコンパイラで速くする…みたいにはうまくいかないもんですねorz

名無し

2025/7/5(Sat) 22:16:34|NO.103615

>「HSP3標準命令でゲームを作る」から「HGIMG3/4/Dish系に移行する」

#include "HGIMG4.as"

を最初に記入するだけ！
挙動が違ったり使えない命令があったり使えるようになる命令があったりはするものの、「移行する」のみであれば基本これだけで大丈夫だと思います。とりあえず細かいことは気にせず試しに記入してF5キーで実行してみてはどうでしょうか？恐らくbufferへの描画が上手くいかなくて躓くと思うのですが、その時はその時で上手くいかない命令等がどうなっているのか、 F1キーのヘルプだったり、マニュアルだったりでページ内検索かけて調べればなんとかなります。何とかならない時はGoogle検索で。 >後からこの「ファミリーベーシックのスプライト」みたいな半自動制御に移行するのは厳しい感じです。確かに3D表示だったりスプライトだったり便利な機能が多く実装されていますが、特別無理に移行する必要は一切ないです。その気が向いた時に新しくHGIMG4用などの機能を調べて使うものとして、エラーが出たり問題がある訳では無いのであればgcopy等の実装でもいいと思います。

窓月らら

2025/7/5(Sat) 22:34:14|NO.103616

ちょっと宣伝みたいになりますが、
テキスト描画エンジン miecat msgcnv (メッセージこんぶ)
というもんをうちは開発して公開しているのですが
https://miecat.com/hsp/
これはHSP3Dishです。1文字が1スプライトみたいなもんです。
文章だとすごい数のオブジェクト(スプライトに相当)を描画する必要がでてきますが
デモを見て頂ければわかりますが、これだけ表示してもCPU負荷は15%程度(当方の環境)です。
マウスホイールをぐりぐりやってみてください。。
この数倍は描画できるということですから、DirectXを使った方ができる事は広がります。
まずは小さいテストコードを書いてみればそこまで難しい話ではないと思います。
公式マニュアルも説明があちこちに点在しているため把握が大変かもしれませんが
ひとつひとつ試していけると思いますよ・・・。

HSP3Dish上での grotate の使い方は標準(GDI)と同じはずです。

BASICコンパイラといえば、べーしっ君ですね。そのむかしお世話になりました。

名無し

2025/7/5(Sat) 22:38:19|NO.103617

>103615
改行入れてたはずが何故か全ての改行が消えている・・・
とてつもなく読みにくいですがご容赦を。

hkr

2025/7/5(Sat) 23:00:36|NO.103618

ありがとうございます。

散々好き放題書いたので、一応作成中のを思い切って晒します('ω')
https://x.com/i/status/1940030375562289561

当方のプログラムはdmmplay命令を使うためだけにHGIMG3を利用しているのですが、
タスクマネージャで確認すると現状CPU消費15%、GPU消費0%、WAITを0にしても24FPS以上
出ない状況です。これをなんとかしたかったのですが、HGIMG4をインクルードするだけで
効果が出るのでしょうか？

とりあえずこの画面を描画するのにbufferを50枚ほど使用しているので
DISHとは相当相性悪いような気はしますｗ

hkr

2025/7/6(Sun) 17:32:31|NO.103622

>>NO.103615

今dmm系命令を外してhgimg4.asをIncludeしてみました。
ある意味予想通りでしたが、真っ白いウィンドウが表示されて何も描画されませんｗ

>>恐らくbufferへの描画が上手くいかなくて躓くと思うのですが、
>>その時はその時で上手くいかない命令等がどうなっているのか、

エラー表示が全くないのがタチ悪いですねー
画面豆腐ですが内部的には動作している模様。
前述の通りですが、マニュアルを読んでも

https://www.onionsoft.net/hsp/v36/doclib/hgimg4.html#USAGE

解説が３Ｄ拡張に関してばかりなので、標準命令の何がどのような影響を受けて
なぜソースをいじってないのに今まで表示されていたものが表示されないのか
さっぱり理解が追い付かない状況です。
F1でHELP見ろと言われても、その先でまず何を検索すればよいやらヒントすら無いのでとっかかりが…

ってここらへんも前述の通りですね。
Dishが発表された直後から使い始めて順番にバージョンを上げてきた人にとっては余裕でしょうけど、
いきなり始めるにはちょっと意味不明ですねー(;´･ω･)

名無し

2025/7/6(Sun) 21:41:49|NO.103624

ソースコードを見ているわけでは無いので、
どこをどう直せばいいと直接指摘できるわけでは無いのですよね。

>なぜソースをいじってないのに今まで表示されていたものが表示されないのか
自分も比較的最近HGIMG4を試してみた方で、仰るように分かりにくいなと思う事が多々ある訳ですが、
自分で調べてやっていくしかないですね。
上手く動作しないときの原因の切り分けと調査ができないと難しいように思います。

通常のHSPとHGIMG4等で同じ命令でも仕様が変わったりしている以上、
上手くいかない動作は新しくその部分のみ切り出した短いスクリプトを用意して動作を確認し、
上手く動作してない命令が分かればGoogleで調べるなりすると。

参考までに、自分が画像表示に躓いた時動作確認するために使ったテスト用のスクリプトを。

	#include "hgimg4.as"


	buffer 1,,,screen_offscreen
	picload "画像ファイルのパス"
	
	gsel 0
	gcopy 1,0,0,999,999

#includeをコメントアウトすれば普通に表示されますが...。HGIMG4使い初めに躓いたのがこれでした。
hkrさん同様既に作りこんだスクリプトがあったものの、
画像表示が行えていなかった事から、画像表示をするだけのスクリプトを書いたものです。

このコード、エラーが出る原因はbufferのscreen_offscreenの記載が余計なんですよね。
この件は調べても結局わからなかったので自分であれやこれやとスクリプトを弄りまくって
結果的に分かったものです。こういう作業を自分でやれないと難しいんだろうなと思ってます。
ついでに上のスクリプトは最後にredraw命令を入れる必要がありますね。
これについてはマニュアルにしっかり記載がありました。
https://www.onionsoft.net/hsp/v37/doclib/hgimg4.html#INITALIZE

hkr

2025/7/6(Sun) 23:37:15|NO.103626

ありがとうございます。
たしかに、自分もマニュアルにしたがいbufferに
screen_offscreen
を追加しましたが、同様にpicloadのエラーで挫折しましたね。
当然Picloadのヘルプには何も記載無いですし、
hgimg4のドキュメントにも...自分の検索が間違っていなければ
Picloadに関する記述は無かったとおもいます。

窓月らら

2025/7/6(Sun) 23:50:12|NO.103627

2Dならば HSP3Dish でいいと思いますがね。
HGIMG4と互換性はありますが、若干Dishのほうが速いと感じます。

Dishの場合 buffer はあくまで素材ロード先であって、bufferの書き換えはできません。
というところが標準との違いです。
まずは最小限のコードで試していけばいいと思います。

窓月らら

2025/7/7(Mon) 02:28:40|NO.103628

その昔はハードウェアにスプライト機能があったわけですが
これをソフトでやるかハードでやるかの違いだけであって
いまは全部ソフトでメモリ間転送しているだけです。(gcopy gzoom grotate)

で、疑似3Dであればほぼすべてがスプライトみたいなもんですから
HSP3Dishに置き換えは容易だとうちは感じます。
書き換え可能なオフスクリーンはありませんが、毎フレーム描画すればいいだけです。
一見効率悪い方法なのですが、これが意外と重たくならないので
これでもいいわけです・・・。

余裕で60FPSで数千個のスプライト(オブジェクト)まで描画できるはずです。
1000個程度までであれば、いまの環境では余裕でいけると思われます。

hkr

2025/7/7(Mon) 06:53:45|NO.103629

ありがとうございます。

今作成中なのは NO.103618 の通りなのですが、
あれ実はスプライトの拡大縮小ではなく画面の奥行きを全て
レイヤーで管理していて、全レイヤーを一旦等倍で作成し、
つぎに画面の奥に向かって縮小しながら合成し、最終的に
表示解像度に拡大して画面表示しています。

これがbuffer同士の合成が必要な理由で、
dish向きでは無いと書いた理由です(´・ω・｀)

NO.103595への返信

初めて利用する方は、HSP3掲示板の使い方をお読みください。
不要部分の多い長いスクリプトの投稿はご遠慮ください。
書き込みは自動改行されません。適度に改行を入れてください。
スクリプトは小文字の<pre>～</pre>で囲むと見やすく表示できます。

削除用パスワード

解決したら質問者本人がここをチェックしてください。


エラー発生時、再送信すると二重送信になることがあります。回答が得られたら、お礼書き込み時に[解決]チェックしてください。 SPAM防止のためURLから始まる文章は投稿できません。 SPAM防止のため英文字のみの本文を投稿することはできません。