2001年に発売されたノベルゲーム「秋桜の空に」の話です。
発売当時、動作不安定だったので互換エンジンが２つも作られるという、ちょっと何言っているかよくわからない展開があったそうです。しかも作った方が、PC-8801エミュレータ（X88000）の中の人と、winlove（ラブエスカレーターwindows移植）の中の人という、びっくりな話です！
今でも現存しているとはありがたいですねーソースコード付きのオープンさ最高です。休日においしく召し上がらせていただこうと思います。
quagma.sakura.ne.jp
・Hextris-Advance
GitHub - mk-822/Hextris-Advance: "Hextris" Clone For GBA · GitHub
Ver 0.4は消去後にゲームオーバーになるバグがあるので0.3推奨です
・Damage Report
Damage Report by setsquare, LostImmortal, samwilliamssound, Crazy_Jake
倉庫番風パズル
・洞窟物語GBA
Releases · tilderain/cave-story-gba · GitHub
MD版から移植とか。オルガーニャ聞けるだけでも満足度高いです
リンク先をみるとLorenzooone先生ver lz77を使ってもLz4優位ですね。Lz4の時代きたかも？
LZ4 (DMA) LZ4 LZ77^ Size / kB 226.3 226.3 238.7(+5.5 %) Decompression / ms (mGBA) 282.3 346.1(+22.6 %) 404.6(+43.3 %)
github.com
https://github.com/HorstBaerbel/GBA-demo-framework/blob/45a7650a3420f92ec91964929c2bc04ac0ecfc72/src/compression/lz4_asm.s
aPLibとLz77の比較です。
・GBA上でのフレームカウント総数4000（だいなあいらんタイトル前あたりまで） ・実在するフレームファイル数2006ファイル ・1フレームmode4(180, 20) + 256色パレット ・表示できたフレーム総数 aPLib：2506 Lz77：2777 ・GBFS容量（＋音楽ファイル含む） aPLib：22.5 MB (23,669,200 バイト) Lz77：25.8 MB (27,059,200 バイト)
やっぱりaPlibは重かったなあという印象です。ビット操作の取り出し（？）がARMと相性悪いみたいです。8bit CPU界隈ですとまた違った結果になったかもですねー。ノベルゲームとしては相性いいので今後つかっていくかもしれないです。
追記：
8bit転送なのでパレットデータも一時バッファからの転送になってしまいました。これが結構響いているかもですね。Lz77ならパレットVRAMに直接流し込めるのに。あ、ちなみにエンコード処理はgbalzss.exeより2倍程度かかるので、だいなのバッチ処理ですと倍（！）は覚悟必要です。30分以上！
１日ほっとした後にでてくるアイディア、なんなんでしょうね。orz
・思いついた案その１
mode4はやめよう。mode0の方が180x120（正確にいうと184x120(23x15タイル)）を詰めてリニアに転送できます。以下のコードはなかったことにorz
IWRAM_CODE void Mode4Draw(u16* pImg)
{
SwiLZ77UnCompWrite16bit(pImg, Mode4.buf);
u8 *src = (u8*)Mode4.buf;
u8 *dst = (u8*)Mode4.pBack;
s32 y;
for(y=0; y<120; y++)
{
MemInc(src + y*180, dst + y*240, 180);
}
}・思いついた案その２
・aplibで圧縮してみよう。LZ77より圧縮率はいいらしい。ZX0やLZ4でGBAに最適化されたアセンブリはなさそうなので現状は除外。
https://github.com/emmanuel-marty/apultra/blob/master/asm/ARM7TDMI/aplib_arm.s
雑にだいなのファイルで比較。
7672ファイル gbalzss.exe 44.7 MB (46,927,580 バイト) apultra.exe 39.0 MB (40,942,807 バイト)
5.7MB減は脅威ですね。あとはデコードが重くなければ・・・。strbあるからVRAMに直接流し込めないですね。うーん展開後、前と同じようにmemcpyかなあ・・・。
同期、完璧になりました。
全フレームをGBFS化すると47MBになるので前半と後半に分けてROM化。デコードが重くてスキップしたフレームをログ出力。そのファイルを削除するとあら不思議、30.5MBに収まりましたという話になります・・・。うーん、パタパタアニメでこの理論はいいのだろうか・・・。デコード処理によって1vblankに収まるのと、2vblankかかる2種類があるわけですが、とりあえずmGBAで走らせて確認するという力業で決着しました。
Geminiさんと相談したところ、事後のログを使わないなら、ある程度未使用覚悟でロムに持つしかないよ、とのお返事。いやー無理なんだって。え？一律2vblank固定デコードか、1vblank処理で済んだ場合は1vblank休ませるって？休ませるぐらいならフレーム表示したいよなあ、というところで私の知性の限界とあいなりました。
IrqSetCnt(0);
for(;;)
{
s32 v = IrqGetCnt();
ImgDrawBg(v);
Img2.isUse[v] = true; // あとでまとめてログ出力
VBlankIntrWait();
ImgDrawPal(); // 関数内でmode4 flip
if(v >= 8370)
{
Img.step++;
return;
}
}
