class LayersConfig

All my DS tools share the same “GUI engine”, but all somehow have custom requirement on what the hardware compositing engine — the “layers” system — should do.

Yet, so far, they do that by peek/poke-like custom lines of code hacking into the video registers of the Nintendo DS. Because the hardware is so elegant, I had no real appeal to hide it between an abstraction layer, but now I run into issues where console can’t be read anymore.

So let’s try to make it more structured. Capturing all code that access the layers control register into one class would be nice. I think that class — let it be “LayersConfig” — could be associated with *Windows classes that define the different “modes” of the application. Switching between the drawing-on-grid and the Palette-edition of the Sprite Editor implies changing the active window. Same for swapping between files picking and map editing of LEDS or swapping between downloads and playtesting in RunME.

I think I should stop trying to optimize which character is updated on such window switches and consider that there should be a clearscreen followed by a full repaint, if that’s not yet the case. That could make Window::clearscreen an interesting place to do tricks like letting only some part of the console show through, for instance.