ご質問は解決したとのことですが、お節介ながらいくつかアドバイス可能な点を見つけました。
・ループによる最適化
ロード画面の描画ですが、同じような処理が並ぶ場合はループで一括処理した方が効率的です。
screen 0,800,600
gmode 0, 800,600
repeat 8
repeat 19, 1
gcopy cnt, 0, 0, 800, 600
await 70
loop
loop
boxf
wait 300
この手の最適化は見た目がすっきりするだけではなく、
使用メモリや生成される実行ファイルサイズを節約することができます。
・必要な領域だけ描画する
ロード時のアニメーションはプログレスバーだけなので、
部分的なgcopyで間に合わせれば描画の負担が減り、画像データも大幅に削減できます。
・等倍のスクリ−ンバッファを用意しておく
元の画像サイズのまま等倍でスクリーンを描画するバッファを用意しておき
必要なときにそこから解像度を変更してスクリーンに複写するようにしておくと
gomibako.bmpなど個々の解像度変更後サイズを計算する手間が無くなります。
現在の方法だと予め用意された画像全てが同じサイズでないと伸縮がおかしくなりますよね。
・マジックナンバーの非推奨
クライアントサイズ(解像度)を示す800,600のような何度も出てくる数値は
マジックナンバーと呼ばれプログラムの保守性(管理しやすさ)を低下させることが多いので
変数に格納したり#defineや#const等のプリプロセッサレベルで定義しておいた方が無難です。
それに連なって各画像のbufferIDも#enum等で定義しておくと番号の管理が不要になります。
・*startmune → おそらくmenuのミス。
私は現在自作のプログラム言語を考案中なのですが、
こういったエラー処理の分岐には普通はif文を使うところ、
このソースにおける*NO/*OKのような書き方はgoto部を言語が指導してくれれば
実用的なものになるかもしれないとの新たなアイデアのヒントになりました。
色んな言語を渡り歩いているとこういう発想には中々至らないものです。余談ですが。