I’m actually working on Tixy 2.0, and that’s one of the changes on my to-do list for it. It’ll work on all sizes, and scale. Completely agree with you.
In this case, Tixy itself is hardcoded to 16x16, so there are design decisions here. If I want Tixy patterns to run without change, it needs to be 16x16 units. If I’m willing to rewrite, then it’s easy to say, add “halfSize” as a shortcut to mean 7.5 (aka 50% of the full size) so you can use different size panels. (Keep in mind, Tixy uses minimal chars if possible, 32 was the goal)
sometimes (often) the easy way is hardcoding. Doing it flexibly is more work. So we make it work, at first, and the edge cases like other sizes might or might not get handled. True of any pattern.
I think it’s worth bearing in mind that the objectives of tixy and PB are different. tixy.land is an artificially-constrained code golf environment where you’re mean to admire both the beauty of the patterns and the elegance of the code that generates them. PixelBlaze is a powerful and flexible tool for making patterns in the physical world, but nobody will ever see the code behind them.
If you want to faithfully emulate tixy.land in a physical device, PB isn’t necessarily the best tool because the expression language doesn’t map exactly (as you’ve found). Me, I just want to see the pretty blinkenlights and I don’t care if I have to adapt the functions as I import them.
I think this discussion has clarified in my mind that the approach I’ll take for my tixy panels will be to scale the (x,y) arguments to (0…1) in the PB render function, because very few of the tixy functions actually depend on a specific pixel offset (just the “zooming boxes” and “bitmap text” ones, from memory).