I organized the code like that because my original plan was to deploy the different displays over the web using websockets and http requests. But I'm still working through some issues with that approach because it's too easy to break things and a bit harder to debug remotely.
As for the grid, I went with black to limit the light blending between squares. I was trying to get a crisp square "pixel" look, which I think the black achieved pretty well. Having a more transparent grid would probably soften the look, which is also nice especially for more ambient displays.
I'm sure I could create a randomly generated flame effect but for that I would probably need to leverage the graphics library. I went with a simpler (to me) approach of mapping the matrix to an almost paint-by-numbers array. I did this because originally I was going to have my kids come up with some pixel art .... yeah they lost interest before I was able to get it in-place. :) While the array method makes it easier to visualize what will be displayed, it's slower for the microcontroller to render.
I did see some of your posts when I was searching around. Very cool stuff. I like the post where you and Gordon discuss the inline C and Graphics approaches. The C stuff is very cool. To be honest, I need to sit with those a bit more and play around. I get it more when dealing with LCDs but I'm not quite putting 2 and 2 together on how the Graphics library works with a 16x16 neopixel matrix to draw some sort of pixel art without having to code up a ton of drawline function calls. I just need to get familiar with it.
Thanks for checking out the project!