IntyBASIC Swapping DATA in/out of GRAM?

[First Spear]

Hey all. I have used up all of my GRAM tiles making a title screen. The first few lines of the program, generated by IntyColor, look like this:

 

REM stub for showing image, only for 160x96 bitmaps
MODE 0,11,11,11,11
WAIT
DEFINE 0,16,DataScreenTitle_bitmaps_0
WAIT
DEFINE 16,16,DataScreenTitle_bitmaps_1
WAIT
DEFINE 32,16,DataScreenTitle_bitmaps_2
WAIT
DEFINE 48,15,DataScreenTitle_bitmaps_3
WAIT
SCREEN DataScreenTitle_cards
loop:
GOTO loop


' 63 bitmaps
DataScreenTitle_bitmaps_0:

 

 

Now I need to wipe the screen clean and use a different set of tiles for a different part of the game.

 

The IntyBASIC manual states

 

Label can be also an 16-bits array for dynamically defined GRAM.

DIM #graphic(4)

DEFINE 0,1,#graphic

 

 

 

So I am sure it is possible to clear the screen, swap out the GRAM for a different set of tiles, but I don't know how the syntax works. Can anyone point me to a sample that shows how to swap DATA<->GRAM?

 

Thanks.

 

 

[Kiwi]

I think
cls
wait
define 0,16,NewTiles
wait
define 16,16,NewTiles2
wait
define 32,16,NewTiles3
wait
define 48,16,NewTiles4

is what you want.

 

It'll just overwrite the GRAM data.

[freewheel]

Yup. Just re-define the GRAM whenever you like. The only real caveat is that you need 5 WAITs to handle it all, so it's a bit clunky if you're doing it in the middle of the action. But just "draw a screen, clear it, draw another"? DEFINEx4 again and you're all good. Heck, you can even change between FGBG and Color Stack mode if you want, within the same game.

 

You can get clever with it too, by re-defining a subset of GRAM. Say you only want to change 8 cards? Just DEFINE accordingly (remembering the start pointer and index value of course). I DEFINE literally dozens of times in a game, depending on need.

 

The use of a 16-bit array is pretty wasteful considering how few 16-bit variables you get. Instead, I find myself doing things like this:

 

ON value GOSUB define_card_set_1,define_card_set_2,define_card_set_3....

 

and each define_card_set_X PROC has the appropriate DEFINE statements in it. Yeah it's a lot of jumping about in code but it's pretty slick and the WAITs after every DEFINE is what slows things down anyway. You're not really wasting cycles with all the GOSUBing in this case.