HSPTV!掲示板

hsp3dishを用いて大規模な画像音声（計1GB以上）を読みこませようと思いました。
所謂一時記憶メモリへの負担が大きくなりそうだと考え、
画像音声の分割ロード、開放を思い立ちましたが開放の仕方が見当たりません。

そこで画像音声とも容量が極端に少ないdummy.png(1KB)とdummy.wav(18KB)を用意し、
同一IDに再読み込みさせることで開放をさせる手段を思いつきました。

以下にサンプルのソースを示します。
この方法は一時記憶メモリの節約に効果があるのでしょうか？

また本筋とは逸れますが、windows版hsp3dishの.oggの再生方法に関しても気になっています。
hsp3dish.asと競合せず.oggを再生する方法があれば教えていただきたく思います。
これに関しては話が大きくなるようでしたら別の投稿で質問させて頂きます。

OSはWindows7、HSPは3.4beta3です。
返答よろしくお願いします。

//*************************************************
#include "hsp3dish.as"

//読み込み
celload "stage1.png",1
mmload "stage1.wav",1

//処理
frame=0
mmplay 1
repeat
	await 16
	frame++
	if( frame > 120 ) : break
	redraw 0
		pos 0,0 : celput 1
		pos 0,0 : mes frame
	redraw 1
loop

//メモリ解放？
celload "dummy.png",1
mmload "dummy.ogg",1

//読み込み
celload "stage2.png",2
mmload "stage2.wav",2

//処理
frame=0
mmplay 2
repeat
	await 16
	frame++
	if( frame > 120 ) : break
	redraw 0
		pos 0,0 : celput 2
		pos 0,0 : mes frame
	redraw 1
loop
//*************************************************

私的な所感に基づく意見なので何の回答にもならないかも知れませんが…

「分割ロード」が全てのリソースを1度に読み込まないという意味でしたら
IDの使い回しで十分な気がします。
単一のファイルを複数回に分けて読み込ませるという意味でしたら
恐らく無理かと思います。

画像は「buffer 1,1,1」等でもメモリ節約はできる筈ですが
あくまでWindows上での話ですので実機での効果の程はわかりません。

mmload/mmplay 命令は「2MB以下の音声(WAV)ファイル」以外は
mmplay 実行毎に(同一ファイルであっても)読み込む仕様のようなので
2MB以下のWAVファイルを数百個読み込む等で無ければ
特に策を講じなくても良いような気がします。

ogg再生に関しては、dish側での対応を心待ちにする以外無さそうです。
外部DLL等は当然弾かれますし、MemFileやMCI命令も使えない為
仮に自前でデコードしても再生させる方法が無いように思えます。

そもそも１GBもの巨大なサイズの画像、音声ファイルを読み込む必要があるなら、
その必要がないよう、もう少しやり方を考えるべきだと思う。
実行環境によってはフリーズしかねない。

OGGファイルの再生については残念ながら"なぜか"実装されていない。
(デコーダはC言語で書かれているから問題無く組み込めるのでは……？)
対応されるまで待つしかないだろう。

返信有難うございます。

申し訳ありません。表記による齟齬が出てしまったようです。
「大規模な画像音声（計1GB以上）」というのは1つの.pngと1つの.wavという意味ではなく、
相当数の.png（平均500KBx400枚=200MB）と相当数の.wav（平均2MBx400音=800MB）
という概算で出した数字です。

更に踏み入った話を致します。
HSPによる音楽ゲームを作成すると過程します。
1曲に付きBGMとして約2分の.wavファイルを用いるとすると約20MBx1=20MB。
BGM箇所によって違うSE（いわゆるキーアサイン音）を平均2秒、100個割り当てると、約2MBx100=200MB。
1曲に付き音声ファイルが概算220MBかかります。
よって4曲程度収録するだけで相当数のメモリを専有するという計算をした次第です。

>>774様
返答ありがとうございます。所感に基づく意見でもいただけると嬉しいです。

「IDの使い回し」に関してはあまり乗り気ではありません。
ソースの部分によって同じIDでも扱うファイルが異なると、
ソースの記述上混乱を招くもとになりかねないと思います。
スマートな解決法が思いつきません。

「画像のメモリ節約」に関しては元ソースの記述方法で出来るようですね。
Win版での制作を考えていますので他プラットフォームに関しては意識していません。

「単一のファイルを複数回に分けて読み込ませる」に関しては話の齟齬だと思われます。
欲を言えばローディング中の画面処理（いわゆるナウローディングのミニ動画）も実装したいところですが、
高望みしすぎですね。

「2MB以下の音声(WAV)ファイル読み込み仕様」に関しては初耳です。情報ありがとうございます。
例を上げた通り仮に音楽ゲームを作るとなると起動時に4曲全てのキーアサイン音を読みこめば、
800MB弱の領域を専有する計算です。
やはり何かしらの対策が必要そうです。

>>check様
返答ありがとうございます。

仰るとおりです。
1GB以上のファイルを扱おうと思った時点で、
使用環境言語の見直しをするべき案件だとは思います。
.wavを.mp3に変更する手段も考えたのですが、
例で上げた通り音楽ゲームを作成しようとすると.mp3の発声遅延が致命的になりそうです。
かといって純粋なHSPですとFPSの問題が出てきてしまうので、
.oggの使用が出来ないことにやきもきしています。

相変わらず所感に基づいてますし、音楽ゲームに対する認識は
BM98辺りで止まってますので見当違いな事を言ってるかも知れません。

とりあえず読み込みは1曲分ずつでいいと思います。
4曲合間無しだとプレイヤーもしんどいです(w

Windows上での音楽ゲームという事でしたら
純粋なHSP+DirectX系プラグインでの開発を強くお奨めします。
mmplayでは「BGM(mid/mp3)・SE(wav)其々1つずつしか再生できない」事。
「再生中の位置を取得できない」事などが理由として挙がります。
外部DLLを扱えればogg再生は勿論、他にも色々やりたい放題です。
DirectSoundには音程を操作する機能(ピッチシフト?)もありますので
ハズレ用のSE辺りならこの辺で賄う事で色々節約になりそうです。
HSP用プラグインのどれなら扱えるかは、すいません存じません。

FPSを問題とされているようですが、dishの描画命令自体DirectXで描画されてるようですので
DirectXによる描画で同様の画面構成なら、同等のFPSを得られるのでは無いかと思います。
1つ問題があるとすれば、pngのαチャンネルをそのまま利用できるものが無かったかも知れません。

「IDの使い回し」は、BGMはID0・キーA用のSEはID1〜3といった感じで
用途でIDを固定するやり方のつもりだったんですが、やっぱりダメですかね…

最後にファイル形式に関してですが、メモリ使用量的にはどれもほぼ同じです。
midやoggのストリーミング再生は別として、
「即時再生可能な状態＝メモリ上にWAV形式で読み込まれた状態」のハズですので。
ご存知でしたらごめんなさい。

774さんの仰るとおり、必ずしも一度に４曲分全てのデータを
メモリ上に読み込んでおく必要はないと思います。

一曲終わったらリザルト（結果表示）画面だったり、次の曲のタイトルを表示する画面など
少しの間はあると思うので、その間に裏で読み込みをさせれば、
プレイヤーを待たせないように読み込んでいけるのではないでしょうか？

このあたりはゲームデザイン次第ですね。

申し訳ありません。返信が遅くなりました。
内容は既に読ませて頂き参考にさせて頂いています。

>>774様
返信ありがとうございます。私もそこまで音楽ゲームに深いわけではありません。

HSP+DirectX系の採用に関してですが、
仰るとおり.pngのαチャンネルをそのまま利用出来ない点が致命的でした。
以前はαチャンネル用のグレースケール画像を用意していたのですが、
手間が掛かりすぎるため挫折してしまいました。
hps3dishで.png透過が遂に実装されたか！と思い意気込んでコードを書いてみたのですが、
音声関係という思わぬ点で問題が……。
.wav再生に関してですがhsp3dishでは多重再生に対応していたと思います。
BGMで使用することは推奨されていませんが、
mp3の遅延を考えるとBGMもwavでの再生を考えています。

IDの再利用に関してですが、音声よりも画像のIDの使い回しに抵抗を感じています。
曲の譜面やアサイン音は別ファイルからの読み込みによる数字のみの管理を、
専用の譜面編集ソフトによる編集で対処すると思います。
（BM98で言う.bmsファイルとbmsエディタのようなものを作成するという形ですね。）
画像系統に関しても同様の管理を出来るとは思いますが、
映像はステージごとに異なるものを使用する予定はありません。
開放を必要とするだけの容量も食わないとは思うのですが、
IDは数字のまま使用しますと混乱の元になるため、
#defineによる文字への置換えを行うように努力しています。
そのために1つのIDに複数の画像を割り当てるとバグの温床になりそうな気がしています。

>>ZAP様
返信ありがとうございます。
私も一度に４曲分全てのデータをメモリ上に読み込んでおく必要はないと思います。
プレイヤーを待たせないように読み込んで行けば大丈夫そうですね。
問題はフリープレイなど「いつゲームが終わるか分からないケース」での読み込みだと思います。
同一IDを用いれば全て解決するのですが、
用いない形式の場合は新たな曲を読み込むたびに「2MB以下の音声(WAV)ファイル」が蓄積していき、
メモリを圧迫していきそうです。

話が逸れてしまいましたがメモリ解放の手段としては、
「dummy.png(1KB)とdummy.wav(18KB)を用意し同一IDに再読み込みさせることでの開放は有効」
「2MB以上の.wavに関しては開放必要なし」
「違う音声や画像を同一IDにアサインすることでメモリ圧迫を軽減する方法が望ましい」
という認識でよろしいでしょうか？

返信よろしくお願いします。

αチャンネル楽ですよね。
HGIMG4に期待したい所ですが、HSPのバッファ自体が24bitなので厳しいかも知れません…

すいません、wav同時再生に関しては適当に試した為勘違いしていたようです。
2MB以上や規格(ビットレートやサンプリングレート)が異なるwavを再生する際に
mmstopが掛かるケースがあるようです。
詳細な条件は解りませんしWMPのバージョンなども影響しているかも知れませんが
2MB以下で規格統一されたものなら問題無さそうですね。

#define使用の際は「global」の付け忘れにご注意下さい。
モジュール内で使おうとして空の変数扱いされる事がよくありますorz

メモリに関しては私も概ねそんな認識です。
ただ「2MB以上の.wavに関しては開放必要なし」は逆に言うと
「必ず読み込み遅延が発生する」事にもなります。
音楽ゲームとしては、処理との同期対策が必要になるかも知れません。

開発がんばって下さい。

>仰るとおり.pngのαチャンネルをそのまま利用出来ない点が致命的でした。
>以前はαチャンネル用のグレースケール画像を用意していたのですが、
>手間が掛かりすぎるため挫折してしまいました。
gmode 7用の画像を動的に作成するスクリプトを利用すればいいのでは。
GDI+を利用した方法なら以下です。

#include "a2d.hsp"
alCreateImageByFile  0,"6.png" ;http://www.micwire.net/hap/ の画像を使用
if stat=-1:dialog "load error":end
screen 0,alGetWidth()*2,alGetHeight()

cmatrix(MAT_R) = 1.0, 0.0, 0.0, 0.0, 0.0
cmatrix(MAT_G) = 0.0, 1.0, 0.0, 0.0, 0.0
cmatrix(MAT_B) = 0.0, 0.0, 1.0, 0.0, 0.0
cmatrix(MAT_A) = 0.0, 0.0, 0.0, 0.0, 1.0
alCopyModeColorMatrix cmatrix ;アルファチャネルを無効にした画像を作成
alCopyImageToScreen 0,0,0,0,alGetWidth(),alGetHeight()

cmatrix(MAT_R) = 0.0, 0.0, 0.0, 1.0, 0.0
cmatrix(MAT_G) = 0.0, 0.0, 0.0, 1.0, 0.0
cmatrix(MAT_B) = 0.0, 0.0, 0.0, 1.0, 0.0
cmatrix(MAT_A) = 0.0, 0.0, 0.0, 0.0, 1.0
alCopyModeColorMatrix cmatrix ; アルファチャネルをグレースケール化した画像を作成

alCopyImageToScreen 0,0,alGetWidth(),0,alGetWidth(),alGetHeight()
alResetCopyMode
redraw 1

メモリ管理について困っているようであれば、そもそもHSPで作成することを見直したほうがいいかもしれない。
もしくは、拡張プラグインで手動で画像・音声のメモリの開放ができるものを探すとか。

HSPはメモリ管理についてはほとんど行わず、
コンパイルの時に全体の変数の数をaxファイルに書き出していたはず。
１つの変数を拡張したり、型を変えたりすることはできても、
自動で使われなくなった変数を開放してくれない。

沢山の返信ありがとうございます。


>>774様
αチャンネル楽です。
HSPのバッファ自体が24bitについては存じ上げません。
興味深い点では有りますが話が逸れそうなので又の機会にお訊きします。

mmstopが掛かるケースに関しては、
"hsp3dish.as"の単体使用では、現状遭遇したことがありません。
2MB以上のwavを多重再生した際に起こる現象かもしれませんね。

#define使用の際は「global」の付け忘れに関しては、私もよくやってしまいます(苦笑)。
HSPがScript言語であることと矛盾が生じますが、
殆どの処理を関数化やカプセル化してしまい#defineでの置き換えも、
#module〜#global内に収めてしまうのも手なのかなと思っています。

.wavの「必ず読み込み遅延が発生する」に関しては、
hsp3dishがDirectXを採用しているため問題になるレベルではないと信用することにしました。
正直自信がありません。

全体的に「やってみないと分からない」点が多すぎますね……。
開発を進めてみて問題点が出次第再び掲示板で質問させて頂きます。


>>spicy様
丁寧な返答ありがとうございます。
申し訳ありません。この掲示板の仕様がよく理解できていません。
文の引用やURLのリンク作成が出来るんですね……。

<blockquote>gmode 7用の画像を動的に作成するスクリプトを利用すればいいのでは。
GDI+を利用した方法なら以下です。</blockquote>

gmode 7の利用は試みたことが有ります。
hspのPluginに関する知識が薄く、GDI+という言葉を初めて耳にしました。
こんな便利なスクリプトがあるとは驚きです。
環境を見なおしてみようと思います。


>>check様
仰るとおりで耳が痛いです……。
そもそもHSPで扱う案件ではないのは重々承知のつもりです。

言い訳をさせていただくのであれば、
初心者が2Dのゲーム作成する際、
VC(VC++)&DXlib以外の選択肢を見つけることが出来ませんでした。
(他プラットフォームの名前を出すことをお許し下さい)
それでも私にはハードルが高い印象です。

HSPは環境構築の手軽さと将来性が素晴らしいと思い選択をしました。
hsp3dishがマルチプラットフォームである点や今後3Dにも対応予定の点を鑑みて、
hsp3dishに注力したい考えです。

この掲示板で話す内容では無いことは自明ですが、
ゲーム制作においてお勧めの環境などあれば教えていただきたい所存です。


返信よろしくお願いします。

>24bit
VRAM直接操作しなければ触れるような場所では無いですね。
現状の画像バッファではRGBの24bitで目一杯なので、α値を保持できるスペースが無いという事です。
DISHは最初からその辺も折り込み済みだった為、αチャンネルを扱えるのかなと勝手に思ってます。

「やってみないと分からない」からこそ、やってみる価値があるのだと思います。
やる前から分かりきってる事をやるのは只の作業ですし
やってみて分かった問題点を如何に解決するかが、プログラミングというゲームの醍醐味ですよ(w

ゲーム製作に重点を置くならゲーム製作用ツールを検討してみるのもいいかも知れません。
利点は、プログラムとしてのシステム面は実行エンジン任せなので、作者はゲームの内容に注力できる点ですね。
欠点は、実行エンジン側で出来る事しか出来ない、新たに言語(仕様)を習得する必要がある点でしょうか。

HSPはやはり手軽さが最大の魅力ですね。加えて大抵の事はどうにかできてしまえる点。
細かい事しようとすれば資料と首っ引きになるのは結局どの言語でも一緒ですし。
(DISHとなるとまだ制約の方が厳しい気もしますが…

>>774様
返信ありがとうございます。

24bitの件大体把握しました。
解りやすい解説助かります。
HGIMG4の設計仕様上RGB各色8bitしか持っておらず、
アルファチャネル用のbitを考慮されていないのではないかという予測ということですね。
何とか32bit設計にしていただきたいですね。

「やってみないと分からない」からこそ、やってみる価値があるに関しては、
心に染み入る言葉でした。
先人の知恵を借りてリスクを回避することも大切ですが、初心を忘れていたようです。
まずはやってみます！

ゲーム製作用ツールを検討の件ですが、
やはりプログラム言語の自由度には敵わない印象です。
あくまで主観的な知識に基づいたお話ですが、
RPG系統限定で制作をするのならば自由度も高く経験蓄積も多い充実したツールが揃っている気がしています。
その他ACT、STGとなると少々無理をしなければ出来ない事が多いと感じています。

HSPはやはり手軽さが最大の魅力だと思います。
出先でもUSBメモリ1つあれば開発が続けられるのはこの言語くらいではないでしょうか？
個人的にはdishの制約には不満を感じていません。
欲を言えば「windows版の全画面化」「windows版の.ogg対応及びループポイント指定」
が出来れば良いのですが……。
要望など何処で出せば良いのでしょうか？



勉強になるお話ばかりで助かっております。
本題とそれすぎた話題ばかりで申し訳ありません。
返答を2-3日お待ちしてから解決済みとさせていただきます。

こんにちは。
本題とずれた話になるのであまり詳しく書きませんが、
HSPでPNGのアルファチャンネルを使いたいというのであれば
HGIMG3でも良いような気がします。
直接描画命令のhgrotateを使えば、標準命令のgrotateとほぼ同じ感覚で描画できます。

#include "hgimg3.as"
    hgsetreq SYSREQ_DEFTIMER,1
    hgsetreq SYSREQ_2DFILTER2,2 ;綺麗に拡大させる
    hgini

    dialog "png",16
    if stat=0:end
    texload2 refstr
    texid=stat

    repeat
    hgdraw
    pos 320,240 ;この座標が中心（左上ではないので注意）
    gmode 2,200,200 ;↓この座標から200x200ドット表示
    hgrotate texid, 0,0, 0, 300,300
                            ;↑表示する大きさ(300なので1.5倍の大きさで表示)
    hgsync
    wait 1
    loop

質問者様ではありませんが、勉強になりました。
HGIMGに関して色々勘違いしていた様です、すいませんm(_　_)m

返信ありがとうございます。
私もいい勉強になりました。

>>A.C様
HGIMG3という手が！ 盲点でした。
名前は知っていましたが知識は薄くhsp3dishを中心に学んでいたため、
HGIMG4の正式リリースを待とうと考えていました。
サンプルを実行させていただきましたが問題無さそうですね。
音声関連も充実していますしマルチプラットフォームを考えなければ、
現状の選択肢としてはベストだと思います。
時間と学習能力を鑑みて検討したいと思います。

ではこれで質問解決とさせて頂きます。
お付き合い頂きありがとうございました！