Petitverse

GRP3とかの空いた場所にフォントを描いておいて1文字ずつGCOPY

しかしそれだと文字の色が変えられないので、
配列にGSAVEしてからFORで1ドットずつ調べて色を書き換えてGLOAD

しかしそれだと遅すぎるので、
16bitでGSAVEしてから長さ65536の配列をパレットとして使ってGLOAD
(RGBA5551で白が色コード65535になるので、配列の65535番目を表示したい色にする)

メモリ消費を少しでも減らしたいなら、
フォントを黒(RGBA5551で色コードが 1 になる)で描いておいて
パレットの配列を長さ2にすればok

まあそれでもGPUTCHRより遅くて画面がちらつくので、
なんとかしてください(雑
使ってないGRP面に画面を描画して、完了したら表示を切り替えるとか。


いや、それよりも1文字を4つに分けてFONTDEFしてGPUTCHRした方が速そうか?

>あまさとしおんさん
漢字ライブラリのデータ、生成したいですがやり方が分かりません。
どこかに書いてありましたっけ?

しかし、漢字ライブラリも結局パレット配列を使ったGLOADなので、やってることは同じではないでしょうか?
漢字ライブラリを使わなくてもできるなら使わないほうがいいのでは。
しいて言うならフォントデータが圧縮されて配列に入っているのでGSAVE分の時間が短縮できるぐらいでしょうか。
でも圧縮されたフォントデータを展開(FORで1ドットずつやってる)するのとGRP面からGSAVEして取得するのとどっちが速いんですかね?
私は後者の方が速い気がしますが。

なるほど、結構単純ですね。
ありがとうございます、試してみます。

漢字を16ドットで全部書く気にはならないので、
漢字は漢字ライブラリのフォントで表示しようと思ったんですが、
漢字ライブラリにある16ドットで太字のフォントが道玄坂16と兜町16しかなく、
どちらもおもちフォントのひらがなやカタカナに合わなかったので、
パソコンでM+の16ドット(12pt)のフォントを画像に変換して漢字ライブラリに入れようと思ってます。
他にいい案ありますかね。

(画像は「おもちの」がおもちフォント、「日常」がM+の12pt)

ttf→漢字ライブラリデータの変換プログラムを作って、
M+の12ptを変換してPetitModemで転送しました。
結果
えぇ...

血 下 の 傑 宣
ど う し て こ う な っ た

ちゃんと16x16で出力してるはずなんだけど...
utf-8のエンコードで何か引っかかったか?
出力データの長さが奇数になってるから明らかにどこかの出力ミスってる

Pythonが出力するデータのエンコード前の文字数は合ってるので、
やっぱりutf-8のエンコードに問題がありそう。
前回の文字反転を修正したときに、サロゲートペア(U+D800〜U+DFFF)はエンコードできないってエラーが出てたので、
オプション付けて無理やりエンコードさせたのが良くなかったのかも

試しに U+D800 1文字のtxtファイルをpythonで作ってみると、
中身は ED A0 80 の3バイト。
デコードすると U+D800 に戻る。
Notepad++は非対応らしく xED xA0 x80 の3文字扱い。
これをLZSSLIBでpztに圧縮して、txtに戻すと、
EF BF BD EF BF BD の6バイトになった。
(ちなみにデコードすると U+FFFD U+FFFD で、これは認識できない文字を置き換えるのに使うコード)

つまり、U+D800〜U+DFFFも改行やダブルクォーテーションと同じように
CHR$で置き換える必要があるということですね。

フォントサイズが12だと小さすぎたので16にしました。
他のソフトだと12ptでちょうど16x16だったんですけど、
プログラムによってフォントサイズの単位が違うんですかね。

問題点
1. 文字によって太さが違う
これは仕方ないと思いますが。

2. 文字によって上下に1ドットずれてる
(上の画像のハンガリー舞曲第5番が一番目立つ)
PythonのPillowというライブラリで画像に変換してるのですが、
その時点で既にずれてるのでこれはライブラリが怪しい。
でもここはPythonの掲示板じゃないのでここで言っても仕方ない気がする。

3. 漢字ライブラリが重すぎる
オートが月下の決戦をフルコンボできなくなりました。


最初はおもちフォントを16ドットにするだけのはずだったのになんか面倒なことになってきました。(今更)

>もしかして演奏中も毎フレーム描画してるんですか？
>漢字ライブラリ重すぎてオートのフルコンボできないって明らかに設計がおかしい
プログラムを見たところ、
クリアゲージの右の方の「餅」の文字を毎フレーム
右上の曲名を2秒に1回
描画しているようです。
曲名の描画は、メドレーモードの「○曲目」の表示を2秒に1回切り替えるルーチンに入ってたんですが、
曲名の表示はその時変わるわけではないので、何度も描画する意味はないと思います。
また「餅」の文字は、スコアによって色を変えるだけのようなので、
スプライトとして表示してSPCOLORで変えればいいと思います。

でも曲名を1回描画した程度でそんなに重くならない気がするんですが。
おもちつき実行中に(プログラムは停止してGCLSとSPCLRしました)
GKNJPRINT 100,100,"月下の決戦"
にかかる時間を計ったら、58msもかかっていました。
一方おもちつきを実行していない状態で
(漢字ライブラリの初期化まででプログラムを停止)
GKNJPRINT 100,100,"月下の決戦"
を実行すると、4msでした。
メモリの使用量が漢字ライブラリの速度に影響するのかと思ったんですが、
配列変数を大量に定義してFREEMEMを40000ぐらいにしても、相変わらず4msでした。

ちなみにおもちつき実行中(漢字ライブラリあり)のFREEMEMを調べたら3MBくらいでした。
MMLを全部配列に入れていて、それでメモリを消費するようです。
試しに「恋色マスタースパーク3」(117777Bytes)と「東方靈異伝メドレー」(81168Bytes)を追加したところ、
なぜか漢字ライブラリの動作が明らかに軽くなって、
月下の決戦をフルコンボできるようになりました。
この2曲を削除したらまたフルコンボできなくなりました。
プチコン3号のメモリ管理どうなってるんですかね。