HSPTV!掲示板

https://www.hsp.tv/play/pforum.php?mode=all&num=103595
↑スレッドが長くなったので、仕切りなおしてみました。

こちらのスレッドではGPU支援系ライブラリを標準命令の延長として活用できないか
前向きに探っていければなぁと思います。

新スレおめでとうございまーす♪
私もどちらかといえば2D派でHSP3Dishなどを使っていますので
気が向いたらなにかを書こうと思ってます。

とりあえずHSP3Dish/HGIMG4向けに作成した去年のコンテスト受賞作を貼ります。
https://dev.onionsoft.net/seed/info.ax?id=2522
これは将来的には自分でも使ってゲームを開発するために作成したもんです。
いまはドットエディタを開発しています。

とりあえず標準命令のみで構成された自作のプログラムをHGIMG4.asに移植させつつ
変換のポイントなんか書いていければいいなぁ。途中で折れるかもしれないけどｗ

さて早速ですが、HSP3DISHを使うかHGIMG4を使うかの選択肢です。
自分の場合bufferで確保した領域にboxfで矩形を描画（画面塗りつぶし）しているので、
Dishを使用するといきなりエラーが出ましたｗ
おさらいですが、Dishはbuffer領域はほぼROMと同様の扱いなので、読み込みは出来ても
VRAMの書き換えができません。gselでスクリーン0以外を指定して描画命令を使用したいなら
HGIMG4一択です。

ここまでで実行エラーは解消され、プログラム自体は動作するようになりました。
ただしゲーム画面が表示されずに白画面点滅という状態になっていますorz

次に続く(;´･ω･)

redraw 0 〜 redraw 1で挟むの必須なのでここは間違えないようにします。
redraw 1 しないと画面に表示されません。

>>NO.103664

ありがとうございます。

とりあえず自分が現行使用しているグラフィック系命令は、

screen
buffer
picload
cls
boxf
gcopy
gzoom
grotate
gsquare

これくらいですが、前述の通り画面が白黒点滅していますｗ

https://www.onionsoft.net/hsp/v36/doclib/support_cmds.txt
※ 全コマンドは互換有り

redraw命令で囲んだりはhspdxfixを使用していたころからの癖でやってるので作法は
合ってるはずですが、何かの命令が標準コマンドと違う動作をしてるんでしょうねぇー

テストプログラム書いてみました

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

;#include "HGIMG4.as"
;gpreset

screen 0, 512, 512, screen_fixedsize
buffer 1, 128, 128

gsel 1 : picload "128x128.bmp"

repeat
redraw 0
gsel 0 : pos 0, 0
gzoom 512, 512, 1, 0, 0, 128, 128
redraw 1
await 10
loop

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

128x128のBMPを読み込んで、512x512に拡大表示します。
上の2行のコメントを外すとHGIMG4で動作しますが、
例の画面の点滅が始まります。

コレですねー。
原因わかりませんが、コマンドの仕様変更というよりお作法の問題な気がします。
誰か原因わかります？ｗ

HGIMG4では「redraw 0」を入れると画面がクリアされますが(マニュアルに記載あり)、
その後の「gsel 0」の個所で「redraw 1」と同等の処理が入っているようですね。
なので白く点滅してしまうと。

改善するにはrepeat命令内にあるredraw 0とgsel 0の位置を逆にすれば解決しますが、
提示してあるサンプルの場合はループ中にアクティブなウィンドウを変えてないので、
repeatの前にgsel 0を移動するだけで良い気がしますね。

#include "HGIMG4.as"

gpreset

screen 0, 512, 512, screen_fixedsize
buffer 1, 128, 128

gsel 1 : picload "128x128.bmp"
gsel 0;11行目のgselをここに移動
repeat
redraw 0
pos 0, 0
gzoom 512, 512, 1, 0, 0, 128, 128
redraw 1
await 10
loop

関係ないのですが、ソースコードは「＜pre＞」と「＜/pre＞」(＜＞は半角で)で囲むと良いですよ。

これ、前に自分も、自分の友達もハマったんですけど（笑）
名無しさんの言うように、redraw 0 の前にgsel 0いれないとちらつきます

内部解像度と表示解像度が違うケースを考慮してソースを改変してみました。
一旦バッファに加工した画像を準備しておいて、それをフリップフロップ（厳密には違うが）
して表示する感じにしてみました。
実際今自分が作成しているプログラムは概ねこんな構造です。

;#include "HGIMG4.as"
;gpreset

screen	0, 	512, 512, screen_fixedsize	
buffer  1,  128, 128	;BMP
buffer  2,	512, 512	;FLIP

gsel 1 : picload "128x128.bmp"

repeat
	;表示用の画像をFLIPバッファに作成
	gsel 2	: pos 0, 0	: cls
	gcopy 1, 0, 0, 128, 128	;画像編集処理

	;表示解像度に拡大
	gsel 0	: pos 0, 0
	redraw 0
	gzoom 512, 512, 2, 0, 0, 128, 128
	redraw 1
	await 10
loop

gselとredrawの位置も考慮してみましたが、HGIMG4を有効にすると今度は点滅どころか
真っ白になりましたね。なんでやねーん(;´･ω･)

真っ白になる理由はバッファ2番へのgcopyが正しく行えていないからですね。
buffer 1に対してはpicloadを行うので画像の読み込みが正しく行えてるわけですが、
基本的にそれ以外のバッファに対する書き込みは

buffer  2,	512, 512,screen_offscreen

のように4つ目のパラメータに「screen_offscreen」を入れてやる必要があるんですよね。 https://www.onionsoft.net/hsp/v36/doclib/hgimg4.html#RENDERBUFFER

あーすいません忘れてましたｗ
これで動作しますね。

ってぇ事は、従来のプログラムをHGIMG4で動作させたい場合、最終的に表示させたい解像度の
bufferをscreen_offscreenオプション込みで準備しておいて、一旦そこにコピーしておいてから

	gsel 0	: pos 0, 0
	redraw 0
	gzoom 512, 512, 2, 0, 0, 128, 128
	redraw 1

で表示させれば概ね互換が取れそうな気がしますね。
後程試してみます。

はい、ダメでした。
前のスレッドでも書いてますが、picloadでエラーが出ます。

単純にbuffer命令で作成した画面にpicloadする場合は問題ありませんが、
screen_offscreenオプションを使用すると、

「#Error21 --> サポートされない機能を選択しました」

が表示されます。
試しにimgload命令(mod_img.as)を使用してみたら、mod_img内部で同様の
エラーが発生しますので、やはり何らかの仕様変更だと思うのですが…

うーん、一旦普通のbufferにpicloadしてからscreen_offscreenにgcopyしてみました。
エラーはでなくなりましたが、うまくいかないですねぇ。
相変わらず白黒画面点滅ですorz

白黒画面点滅が再現できません。実行したのは以下のスクリプト。

;#include "HGIMG4.as"
;gpreset

screen	0, 	512, 512, screen_fixedsize	
buffer  1,  128, 128	;picload
buffer  2,	512, 512,screen_offscreen		;FLIP

gsel 1 : picload "tamane16.bmp"
gmode 0
repeat
	;表示用の画像をFLIPバッファに作成
	gsel 2	: pos 0, 0;	: cls
	gcopy 1, 0, 0, 128, 128	;画像編集処理

	;表示解像度に拡大
	gsel 0	: pos 0, 0
	redraw 0
	gzoom 512, 512, 2, 0, 0, 128, 128
	redraw 1
	await 10
loop

手元で問題が再現できないと解決は難しいかもです。

> picload "tamane16.bmp"
問題解決には、コピペだけで問題が再現できるスクリプトが望ましいです。
ということで、hsptvフォルダの画像です。

> gsel 2 : pos 0, 0; : cls
特にgmodeの指定がないということは、gmode 0 なので画面クリア不要。
clsは過剰な処置で負荷が上がっちゃうので、もしやるとしたら boxf での塗りつぶし。

> 「#Error21 --> サポートされない機能を選択しました」
「gcopy命令でパレットモード時に半透明コピーを実行しようとした場合など、機能としてサポートされない設定が行なわれている場合に表示されます。 」（error.htmより）
エラーが出ている行が何処なのか教えてくれないのでわかりませんがgzoomかな？
提示された「概ね」の中に肝心の原因が含まれていないようです。

とりあえずエラー２１が出るサンプルがコチラ

#include "HGIMG4.as"
gpreset

screen 0, 640, 480
buffer  1,  128, 128, screen_offscreen	;BMP

gsel 1 : picload "128x128.bmp"

bmpファイルもうｐしときます
https://xgf.nu/RS2Eg

そして現在画面が白黒しているのはコレが原因ですね。
上２行を外せばちゃんと表示されます。

#include "HGIMG4.as"
gpreset

screen  0,  640, 480, 0
buffer  1,  640, 480
buffer  2,  640, 480, screen_offscreen

repeat
	gsel 1 : color rnd(255), rnd(255), rnd(255) : boxf

	gsel 2 : gcopy 1, 0, 0, 640, 480

	gsel 0	: pos 0, 0
	redraw 0
	gcopy 2, 0, 0, 640, 480
	redraw 1
	await 10
loop

やはり、buffer命令でscreen_offscreenを使用しているものと使用していないもの間の通信
（おそらくメインメモリとGPU上のVRAMとの通信）はサポートされてない感じですかね？
やはり何らかの手段でGPU-VRAM上に直接picload出来ないと先に進まない感じですねー

>103680
picloadを行う場合は「screen_offscreen」は不要です。

>103681
boxfやgcopy等を行う場合は「screen_offscreen」が必要です。

それらをまとめて恐らく行いたいのであろう事を実現したのが
103679(GENKIさん)のスクリプトだと思うのですが...

どうでもいいですが、自分の環境(HSP3.6)にはtamane16.bmpがありませんでした。
この辺のファイルを触ったことは無いので、どこかで削除されたのか追加されたんですかね。

>>NO.103682

ありがとうございます。
実際のところ、NO.103679のスクリプトとNO.103681のスクリプトは、
やってる内容がほぼ同等だと思うのです。

違う個所は唯一元画像が固定のBMPではなく毎フレームリアルタイム作成だというところですが。
結構この現象のキモの部分だと思うので、このスクリプトのダメなところを指摘頂ければ
一発解決な気がするんですが・・・

これで動いたっぽい・・・理屈は不明

#include "HGIMG4.as"
 gpreset 0

screen  0,  640, 480, 0
buffer  2,  640, 480, screen_offscreen
buffer  3,  640, 480, screen_offscreen
randomize

repeat

	gsel 2 : color rnd(255), rnd(255), rnd(255) : boxf

	gsel 3 : gcopy 2, 0, 0, 640, 480

	gsel 0	: pos 0, 0
	redraw 0
	gcopy 3, 0, 0, 640, 480
	redraw 1
	await 10
	
loop

それは画像のソース(buffer2)をscreen_offscreenで作成したからですねー
それだと後からpicloadに対応出来ないのでダメっすねー(;´･ω･)

>> 名無しさん NO.103682
> どうでもいいですが、自分の環境(HSP3.6)にはtamane16.bmpがありませんでした。
HSP3.7以降のどこかで追加されました。HSP3.6には付属していません。
ごめんなさい普段は3.7ばかり使っているので気が付きませんでした。

>> hkrさん NO.103681
> gsel 1 : color rnd(255), rnd(255), rnd(255) : boxf
実際には描画が行われていません。
HGIMG4を使用する場合、screen_offscreenが設定されていないオフスクリーンへの描画はできません。（HGIMG4プログラミングガイド 39.レンダリングバッファ）
何も描画されていないウィンドウをgcopyするので白い画面が表示されるわけです。
NO.103679のスクリプトの場合、ID1に画像が読み込めているのでやっていることは同じではありません。

>> hkrさん NO.103680
ありがとうございます。エラーが確認できました。
screen_offscreenを指定したウィンドウへはpicloadが使用できないようですね。なんでだろう。
マニュアル探してみましたが、使用できないという説明は見当たりませんでした。
その代わり、celloadならscreen_offscreenが指定されていても使用できるようです。こんな感じで書き換えるといいようです。

gsel 1 : picload "128x128.bmp"
↓
celload "128x128.bmp", 1

HGIMG4ではcelloadを積極的に使ってねということなんでしょうかね。

>> 熱帯夜さん NO.103686
boxfでの描画先をscreen_offscreenのウィンドウにしたのでちゃんと書き込みができるようになっています。

おぉ、ありがとうございます！celloadなんて命令初めて知りましたｗ
picloadとの違いは、バッファを明示的に指定しての画像読み込みなんですね。
後程試してみるです〜

あ、すいません、追記です。

>>screen_offscreenを指定したウィンドウへはpicloadが使用できないようですね。なんでだろう。

Dishのコマンドリファレンスを見るとpicload命令は非対応になってるんで、
もしかしてその仕様を引き摺っている可能性も…？

Dishのコマンドリファレンス…そういえばそういうのもあったんでした。忘れてた。
support_cmds.txtのこの記述かな。picloadもcelloadも記述がありますね。

> HSP3Dish非互換コマンド
> (これらの命令はデバイスにより異なる仕様が含まれています)
> picload ,sys|func
> celload ,sys|func

「HGIMG4プログラミングガイド 13. 初期化と描画の方法」には次のような記述があります。
> これらのルールは、HSP3Dishと同様です。 2D描画に使用可能な描画命令と仕様についても、基本的にHSP3Dishと同じになっています。

ということで、HGIMG4有無で挙動が変わるのは、ご指摘通りHSP3Dishの仕様の影響なんでしょうね。

基本的なことですが
HSP3Dish/HGIMG4 を使用する場合は原則最新β版をお試しください。
ほとんどこれの更新なんで・・・
うちのところでは 3.6 はもはや使い物になりません。

とりあえず3.7β入れてきましたよっと。

んでcelloadでテストプログラムあっさり動きましたｗ
今から実プログラムで検証してみるっすー

うーむ、とりあえず白画面が黒画面に変化はしたが、何も表示されない…

現行プログラムは

buffer間の画像加工処理
↓
redraw 0
メインスクリーンにgcopy
redraw 1
↓
await

という流れなのですが、もしかして

redraw 0
↓
buffer間の画像加工処理
↓
メインスクリーンにgcopy
redraw 1
↓
await

じゃないと正常動作しないんですかね？
今から試してみますけど…

ダメでした。変わりありませんでした。
まーだ何処か標準命令と違う挙動をするコマンドが隠れてそうですねーorz

・・・ってここまで書いて気が付いたのですが、たしかredraw 0の前に
メインスクリーンのgselとpos 0, 0をやってからgcopy→redraw 1がお作法でしたよね？
って事は流れ的に↑のチャートは上で正解って事になる・・・のかな？

なんとなく白黒点滅の原因が見つかりました・・・

#include "HGIMG4.as"
 gpreset 0

screen  0,  640, 480, 0
for i, 1, 16
	buffer  i,  640, 480, screen_offscreen
	gsel i
	color 0, 0, 0	: boxf	;???
next
randomize

repeat
	gsel 2 : color rnd(255), rnd(255), rnd(255) : boxf

	gsel 3 : gcopy 2, 0, 0, 640, 480

	gsel 0	: pos 0, 0
	redraw 0
	gcopy 3, 0, 0, 640, 480
	redraw 1
	await 10
loop

８行目、バッファを黒塗り初期化しているのですが、これをやると画面が点滅を始めます。
ちなみにこの行をclsに変更すると点滅は収まります。
boxfはDishでもサポートされてるコマンドなんですが…これは…まだ何かお作法が?

あともう一つ、まだサンプルソースは作っていませんが、
gmode2の透過色コピーが正常動作していないですねー。

調べたらDishでgmodeは非互換指定されているのですが、
HGIMG4では代わりにどうやるんですかね？透過色付きコピー。

透過については素材画像のpngの段階でアルファチャンネルで指定します。
そのまま反映されます。gmode 2 でも中間値の透明がそのまま反映です。

という事は、従来gmode2の透過色指定（RGBすべて0）は使用できない、
画像素材は全部作り直しという事ですかね？(;´･ω･)

手元のプログラムで確認したのは、画像データではなくcls 4で初期化したうえで
boxfで市松模様を描いたものなのですが、本来透過するはずの部分が
灰色（？）で埋められてますね。

もしかしたら、↑で書いたboxf問題（screen_offscreen宣言したbufferに
boxfで描画するとバッファが死ぬ）の影響かもしれませんが。

> 画像素材は全部作り直しという事ですかね？(;´･ω･)
そうです。
逆に1px単位で半透明もできるんで自由度maxになると思いますが・・・

とりあえず実験セットを作ってみましたｗ
ダウンロードはこちら→ https://xgf.nu/1acf6

ってなわけで、確かにスプライトをpngで作ると抜けますねぇ。

さて、問題はこのケース

#define	SCR_MAIN	0
#define	SCR_MIX		1
#define	SCR_BG		2
#define	SCR_SPR		3
#define	SCR_SUB		4
#define	FALSE		0
#define	TRUE		1

#include "HGIMG4.as"

	gpreset 0

	screen  SCR_MAIN,	480, 	240, 	screen_fixedsize
	buffer	SCR_MIX,	240,	120,	screen_offscreen
	buffer	SCR_BG,		240,	120,	screen_offscreen
	buffer	SCR_SPR,	288,	240,	screen_offscreen
	buffer	SCR_SUB,	288,	240,	screen_offscreen

	;BG読み込み
	switch 0	;0:BMP	1:PNG
		case 0	: celload strf("%s\\BG.bmp", dir_cur), SCR_BG	: swbreak
		case 1	: celload strf("%s\\BG.png", dir_cur), SCR_BG	: swbreak
	swend

	;SPRITE読み込み
	switch 1	;0:BMP	1:PNG
		case 0	: celload strf("%s\\SPRITE.bmp", dir_cur), SCR_SPR	: swbreak
		case 1	: celload strf("%s\\SPRITE.png", dir_cur), SCR_SPR	: swbreak
	swend

	;MIX作成
	gsel SCR_SUB	: cls 4
	gmode 2	: pos  0,  0	: gcopy SCR_SPR, 000, 000, 135, 096	;SPR 
	gmode 2	: pos 64,  8	: gcopy SCR_SPR, 151, 000, 279, 096	;SPR 
	
	gsel SCR_MIX
	gmode 0	: pos  0,  0	: gcopy SCR_BG,	0, 0, 240, 120		;BG
	gmode 2	: pos  0,  0	: gcopy SCR_SUB,	0, 0, 240, 120	;SUB

	;VIEW
	gsel SCR_MAIN	: pos 0, 0
	redraw	FALSE
	gzoom 480, 240, SCR_MIX, 0, 0, 240, 120
	redraw	TRUE
	await 10
	dialog "STOP"
end

一旦別画面にスプライト同士を合成しておいて、最終的にBGと重ねると
透過が抜けませんねぇ。
bufferをclsやらboxf以外の手段で、何らかの透過属性を持った状態に初期化しないと
どうにもならないような気がしますねぇ・・・

早速ですが、全面透過色のblank画像を作成してSCR_SUBに読み込んでみました。
これならbufferが何らかの透過属性を持つか・・・？

celload strf("%s\\BLANK.png", dir_cur), SCR_SUB

結果ですが、SCR_SUBがROM化してしまいスプライトが重ねられなくなりましたｗ
なんかもうこの辺はDishの挙動ですねー。

話題はさかのぼりますが・・・こんなんスか

bufferまでredrowかます必要があるとは・・・

#include "HGIMG4.as"

 	gpreset 0
	setcls 0 :;おまじない
	screen  0,  640, 480, 0
repeat 16,1
	
	buffer  cnt,  640, 480, screen_offscreen
	redraw 0
	color cnt, cnt, cnt
	boxf 0,0,640,480	:;???
	redraw 1
	;await 50

loop
	
randomize

repeat
	setcls 0
	gsel 2
	color rnd(255), rnd(255), rnd(255)
	boxf

	gsel 3
	gcopy 2, 0, 0, 640, 480

	gsel 0	: pos 0, 0
	redraw 0
	gcopy 3, 0, 0, 640, 480
	redraw 1
	await 20
loop

うぉ！
↑見て慌てて3DTESTもredraw増やしたりしてみましたｗ
とりあえずbuffer確保時はredrawで描画停止した方が良いことは確認できました！

さらに試しにgcopy命令１個づつredrawで丁寧に囲んだり、全体一括で括ったりしてみましたが、
透過の問題は解決出来ませんでした。
でも、redrawで囲む位置で色々と挙動が変わりますねーこれ危ないねー

自分のいじった感じですが、最初は表示screenに干渉する場合のみredraw停めれば
良いかと思ったのですが、やはりbuffer同士の作業でも描画停めた方が良さげですねー

うおー！！ついにbuffer同士の透過合成に成功しました！！！
やはりbufferを予め透過色で埋める必要がありました。

#define	SCR_MAIN	0
#define	SCR_MIX		1
#define	SCR_BG		2
#define	SCR_SPR		3
#define	SCR_SUB		4
#define	FALSE		0
#define	TRUE		1

#include "HGIMG4.as"

	gpreset 0
	setcls 1

;	redraw FALSE
	screen  SCR_MAIN,	480, 	240, 	screen_fixedsize
	buffer	SCR_MIX,	240,	120,	screen_offscreen
	buffer	SCR_BG,		240,	120,	screen_offscreen
	buffer	SCR_SPR,	288,	240,	screen_offscreen
	buffer	SCR_SUB,	240,	120,	screen_offscreen

	;BG読み込み
	switch 0	;0:BMP	1:PNG
		case 0	: celload strf("%s\\BG.bmp", dir_cur), SCR_BG	: swbreak
		case 1	: celload strf("%s\\BG.png", dir_cur), SCR_BG	: swbreak
	swend

	;SPRITE読み込み
	switch 1	;0:BMP	1:PNG
		case 0	: celload strf("%s\\SPRITE.bmp", dir_cur), SCR_SPR	: swbreak
		case 1	: celload strf("%s\\SPRITE.png", dir_cur), SCR_SPR	: swbreak
	swend
;	redraw TRUE


	;MIX作成
	redraw FALSE
	gsel SCR_SUB	: cls 4
	gmode 0	: pos  0,  0	: gzoom 240, 120, SCR_SPR, 0, 0, 1, 1	;ここがキモ！！！
	gmode 2	: pos  0,  0	: gcopy SCR_SPR, 000, 000, 135, 096	;SPR 
	gmode 2	: pos 64,  8	: gcopy SCR_SPR, 151, 000, 279, 096	;SPR 
	
	gsel SCR_MIX
	gmode 0	: pos  0,  0	: gcopy SCR_BG,	0, 0, 240, 120		;BG
	gmode 2	: pos  0,  0	: gcopy SCR_SUB,	0, 0, 240, 120	;SUB
	redraw TRUE
	await 0
	
	;VIEW
	gsel SCR_MAIN	: pos 0, 0
	redraw	FALSE
	gzoom 480, 240, SCR_MIX, 0, 0, 240, 120
	redraw	TRUE
	await 10
	dialog "STOP"
end

キモはソース内に書いておきましたｗ
PNGで読み込んだスプライトデータの透明な部分だけを取り出して、
gmode0＆gzoomで合成用バッファ全体に拡大コピーしておけば、
そこが透過属性を持つみたいで以降そこにスプライトを重ねても
ちゃんと動作するみたいです。

・・・なんか裏技っぽいので、本当はbuffer初期化時に透過属性を持たせる
何らかの初期化方法が存在してもおかしくないと思うんですけど・・・

「HSP標準命令で作成した2DゲームをHDIMG4を使ってGPUに対応させる際の、現時点でのまとめ」

１）buffer命令には「screen_offscreen」オプションを付ける
２）その際、buffer命令をredraw 0 〜 redraw1で囲む（boxf命令エラー対策）
３）画像データの読み込みはpicloadからcelload命令に変更する
４）透過コピーさせたい画像データは全てPNG形式で保存する
５）その際、グラフィックツール等で従来RGB0:0:0の透過色指定部分を
　　透明属性に変換する必要がある
６）画像合成につかうbufferは、予め透過属性を持ったデータで初期化する必要がある
　　現時点では、スプライトデータの透過属性の部分をgmode 0→gzoom命令で
　　合成用バッファ全体に拡大コピーすれば初期化可能

こんな感じですかね？

うーむ、今↑を元にいろいろ試してますが、全然うまくいきません。
テスト環境ではうまくいっていたのですが、やはりboxf命令を使うと、
何かの拍子にgsel中のbufferを超えて関係ないbufferまで内容を破壊するみたいですね。
もうboxfはダメかなー。

・・・これはもう一旦標準bufferでboxf描いたのをalSaveFileでpngで保存して、
改めてscreen_offscreenに読み込んでからgsquareで台形転送するくらいしか
対処法が思い浮かばないんですが・・・orz
いっそのことHGIMG4の3D系の命令でプリミティブなポリゴン描画する命令とか
無いですかね？ｗ

今気が付いたのですが、

  gsel 1 : gmode 0
  gcopy xxxx
　　　〜
  gsel 1 : gmode 1
  gcopy xxxx

png読み込み(ROM化)していない同じバッファに対して、途中でgmodeを切り替えると
見事に内容が破壊されるっぽいですね。全然気が付かなかったorz
内臓機能ではこんな挙動しないんで、これも仕様変更っぽいですねー

うーん、今度はgsquare命令がマトモに動作しませんねー。
もうテクスチャがガッタガタで使い物になりません・・・

なんかもう折れましたorz

結論から言うと、標準命令のみで作ったゲームをHSPDISH/HGIMG4に移植するのは困難。
ぶっちゃけ頭から作り直した方が速い、くらいの謎仕様のオンパレード。
特にbuffer間の透過コピーが超難関で、様々なきっかけで簡単にbuffer内部が破壊される
のには参りました。

昔はVBよりもHSPの方がDirectX系の描画が楽ちんでこっちに引っ越してきたのに、
HSPDXからHGIMG4に移行したらこんな酷い仕様だとは、
これならさっさとCに変換して脱出したほうが楽そうだなぁorz

Fin.

素直に celload で読み込んで、celdivでサイズ指定して、celputで描画ではダメなんでしょうか。
celput なら拡大と回転の機能を標準で持っているので、これまでのようにgzoomとgsquareを駆使する必要はありません。
celputは、HGIMG4を使うと回転時もきれいに描画されます。

//　redrawの処理

redraw 0

//---描画系処理全般

await 0  //これが無いとredraw 0とredraw 1の間にエスケープ出来ない

redraw 1  //これで描画

await 10  //ここでFPSらしきものを挟む

こうじゃ無いと、描画の間中バッテンボタンが利かない仕組みに
なってしまいます。await 0はひたすら挟んで下さい。小まめに。

〉NO.103730

gsquareを使いたい理由ですが、スペースハリアーの地面の描画ですね
現在市松模様を台形転送して再現してるのですが、スプライト機能で再現できますかね？

あとgzoomを使ってる理由は前スレを参照いただけると(´・ω・｀)
このスレッドの目的は標準命令でつくったゲームの高速化ですから、
スプライト機能の使用はスレ違いですねー