I was looking at a lot of graphic tiles sets and such. If you done anything with new 2D engines (especially top-down), you’ll notice that a map will reference objects instead of tiles. PCs and such and limited to square tiles. Basically the objects are composited/overlaid on top of the map.
Normally, you hard-composite all these kinds of stuffs into regular tiles on these older system. This wastes a lot of space in rom, and eats up vram. For system that have more than 1 BG layer, you kind of do a half process and let the system composite the layers in realtime (saves on vram and rom). Not only does the PCE not have this, it also lacks flipping modes for tiles (instead, it got more subpalettes – only so many bits can fit into a tilemap entry).
My game scrolls screen-to-screen. This lends to the advantage that I could do real time compositing for a full frame before the screen starts to load. This would allows more unique looking detail (less pattern-y), and it wouldn’t stress the cpu since nothing is going on during screen scroll and a full frame or two is pretty decent amount of time to throw at this. There is a down side; I ~do~ scroll between screens instead of just snapping to the next. This means I need room for two screens of unique tiles. I do not have enough room for that. The compromise would be: use a base set of tiles for the ‘area’, but allow a two small buffers for unique tiles for the screen. Two buffers, because I still need to scroll between the two.
An example would be field grass. The grass would be the base, and I could overlay other objects on top – small rocks, or different patterns of flowers, unique edge transitions into other material, etc. The grass could take up 4-5 colors and the rest of the color slots in the 16 color pool would be set for the composite material. This is where the PCE’s huge amount of subpalettes comes in. You could probably apply this idea to actually scrolling maps, but the implementation is more complex, but still do able.