Cenários prontos: PAGELOAD e a compressão LZB

1. O problema: 27 KB por tela

Um bitmap SCREEN 5 (256×212, 4 bits por pixel) ocupa cerca de 27 KB de VRAM. Guardar essa imagem literalmente dentro do cartucho consome 27 KB de ROM — e um cartucho MSX "Normal" tem apenas 32 KB. Duas telas cheias já não cabem, nem sobra espaço para o código.

A solução é a mesma dos jogos comerciais: guardar as imagens comprimidas e descomprimir para a VRAM na hora do carregamento. O CrossScript faz isso com o comando PAGELOAD e dois codecs embarcados.

2. PAGELOAD, em uma linha

PAGELOAD nome_do_asset [, pagina] copia um asset preparado pelo Graphics Studio direto para a VRAM da página indicada (0 por padrão). O asset já traz um cabeçalho de 10 bytes que informa dimensões e codec — o runtime detecta automaticamente RLE ou LZB.

USES SCREEN 5, PAGES
SCREEN 5
COLOR 15, 4, 4 : CLS

PAGELOAD titulo         ' descomprime "titulo" para a página 0
INPUT$(1)

A fonte do asset (o rótulo titulo: seguido dos bytes) vem colada logo depois do programa — o snippet exportado pelo Graphics Studio traz tudo pronto, inclusive MEMORY AUTO, MAPPER se necessário (capítulo 26).

3. Dois codecs, uma escolha automática

O Graphics Studio comprime cada imagem com dois algoritmos e embarca o menor:

Você não escolhe — o exportador testa os dois e ativa o que der menor. O comentário emitido junto do asset mostra os dois tamanhos:

' Page "titulo" 256x212  packed=27136B  RLE=23172B  LZB=14509B  codec=LZB  asset=14519B

Nesse exemplo, o LZB baixou a imagem de 27 KB para menos de 15 KB — economia de ~46%, e o programa cabe no cartucho.

4. Um exemplo típico: tela de título e fase

USES SCREEN 5, KEYBOARD, BOBS, PAGES
SCREEN 5
COLOR 15, 4, 4 : CLS

PAGELOAD titulo
INPUT$(1)             ' aguarda uma tecla

CLS
PAGELOAD fase1        ' novo cenário
' ... daqui em diante, gameplay com BOBs sobre a fase ...

Fim: GOTO Fim

Os assets titulo: e fase1: vêm colados no final do arquivo, cada um dentro de um bloco ASM.

5. Convivendo com BOBs e PAGEFLIP

Quando BOB PAGEFLIP ON está ligado, o CrossScript passa a alternar entre as páginas 0 e 1. Se você chamar PAGELOAD depois do PAGEFLIP ON, o runtime detecta e espelha automaticamente o novo fundo para a outra página — o back buffer nunca fica azul.

A ordem preferida (e a mais legível):

1. SCREEN 5 / COLOR / CLS
2. PAGELOAD cenario
3. BOB CREATE ...
4. BOB PAGEFLIP ON
5. loop principal com WAIT

Mas se você trocar 2 e 4, ainda funciona.

6. Ler bytes de assets grandes na Page 3

Um detalhe interno vale saber: como o cartucho ocupa parte da Page 3 do Z80 ($C000–$FFFF) e a runtime precisa dessa mesma faixa para a stack e para o buffer do decoder, o PAGELOAD faz o mapeamento de banco byte a byte — chaveia a Page 3 para o cartucho só o tempo de ler um byte e volta para a RAM antes de qualquer CALL/PUSH.

Você não precisa fazer nada. Basta saber que, mesmo com o asset ocupando o topo do cartucho, o carregamento não pisa na stack.

7. Quando o cartucho ainda não é suficiente

Se, mesmo com LZB, seu projeto passa dos 64 KB (várias fases, música grande, muitos BOBs), o CrossScript liga automaticamente a Mapper ASCII8 e transforma o cartucho em um cartucho paginado de até 512 KB. Isso é assunto do próximo capítulo (22).

8. Resumo do capítulo

• PAGELOAD asset [, pagina] descomprime uma imagem para a VRAM.
• Dois codecs embarcados: RLE (CSX5) para telas chapadas e LZB (CSX6) para cenários ricos.
• O Graphics Studio escolhe o menor automaticamente e emite MEMORY AUTO, MAPPER quando precisa.
• Descompressão custa só o carregamento; em runtime o custo é zero.
• Combina com BOB PAGEFLIP ON sem esforço — o back buffer é reespelhado automaticamente.
• Se estourar 64 KB, entra em cena a Mapper ASCII8 (capítulo 26).