savescreen/restorescreen and RAM charmap

[+Karl G]

The ramcharmap sample for 7800basic loads a level into RAM, displays it with plotmap, and does a savescreen. Then, in the main loop, it is drawn with restorescreen/drawscreen. What confuses me is that the other level can be loaded into RAM as needed, and this is drawn fine without needing to do another plotmap and savescreen first. What exactly is being saved and restored?

 

A related question about RAM-based character maps: if I want to load the tiles dynamically into RAM and display them, how can I do so using multiple palettes like I could have using plotmapfile if I'm not actually getting the data from a map file? Would I maybe load a dummy map containing all of the characters with different palettes I need, plot it, save the screen, and then just load whatever data I want into RAM to replace it on the fly?

[+SmittyB]

Savescreen and restorescreen update the display list entries that are used to tell MARIA what to draw and how.

 

With a tilemap, whether the map is in ROM or RAM, the DL entries tell the system where to look for the data but if that data is changed it doesn't care because it only has to look in the same place. So a new level can be loaded in, but it's still drawing from the same block of data so the instructions on how to do that don't need changing.

 

 

Having different palettes is trickier because the palette is defined by the DL entry so each change of palette in a given zone would require a different object.

Plotmapfile does the work of this for you, but if your map was in RAM you'd find that changing tiles wouldn't change the colours.

 

To change it on the fly you would need a way to determine which palette a given tile should have and reconstruct the DL entries accordingly with a series of plotchars commands. You would need to have some limits in place to avoid trying to draw too many objects; a checkerboard pattern would require too many objects per zone for example.

[+Karl G]

Thanks for the detailed explanation - that makes a lot of sense. For a turn-based game I might not have to worry about using too many CPU cycles when replotting the map though, perhaps? The only penalty would be potentially skipping frames if I use too much CPU time?

[+SmittyB]

You wouldn't have to worry too much about the time it takes to plot the objects, but you do still need to be aware of MARIAs limits of how much it can draw.

MARIA is much better at drawing a small number of large objects and a colourful tilemap is the exact opposite.

 

Another possibility is to draw the tilemap using one of the more colourful modes like 160B and stick to 12 colours in total. That would mean you need double the data for graphics though.

 

You might need to play around with it and find what works for your project and what doesn't.

 

[+Karl G]

Does switching palettes when drawing tiles in a particular zone take extra MARIA rendering time, though, once the display lists are already generated? If my characters all displayed fine when they all used the same palette, then they might not if each used a different palette than the previous one? I guess that's what you meant with your checkerboard example, but it wasn't clear to me if you meant the time needed to change the display lists to use the new palette entries or extra overhead of changing palettes for display lists that are already generated.

[+SmittyB]

Maria has to read the DL entries each time it renders the zone as well as the graphics data so the more objects you have the more overheads there are, and as each palette change requires an extra object it all adds up.

[+TwentySixHundred]

Not sure if it's of any help Karl however i had noticed the same with loading levels in Captain Comic. As they're also loaded into RAM i found there was no need to plot and save the screen after initialization. Switching color pallets on the other hand required an update (pallet update - plot - save).

 

The only work around i had found was to have a codeblock labeled _mainset just before the _mainloop. So after an "x" amount of screens and an pallet update is required then i would loop back to _mainset where the program would update the required pallet colors - plot - savescreen then continue on with the _mainloop.

 

Probably no help as you have noticed this and there is probably better ways to achieve the same thing. Just thought id share my experience and how i went about it.

[+saxmeister]

This is what I love about this group... The sharing of knowledge, the love of the platform, and the kinship. We are all in this together to make our favorite little locomotive go (I think I can... I think I can...).