Wrote a pair of texture atlas modules. AtlasB uses a binary tree packing algorithm to fit rectangles into square layouts. AtlasQ uses a quadtree to place and remove sub-textures with power-of-two dimensions within a larger texture. AtlasB is intended to create texture atlases offline (or on-demand) which are then fed to AtlasQ at run time.
Revised ProdUI’s skinning system:
Previously, the skinning apparatus itself was separate from widgets and the UI core. You could theoretically replace all skinning code without touching other parts of the codebase. In practice, this falls apart with widgets that are more graphically complex. The low-level skinning implementations — skinners — are now part of the widget definitions, not part of the skinning instance (which should be as close to 100% data as possible).
In the default skinning system, all widget render functions used love.graphics shapes and (ignoring fonts) no textures. This allowed for easy scaling of visual elements without introducing artifacts. However, the basic shape functions incur more overhead when drawing complex forms out of polygons and polylines (which, for every call, have to be passed through the Lua C stack as numbers and turned into a temporary mesh). It finally became a performance issue when I implemented some small icons using those functions. (Yep, dumb idea.) I redrew most of the skinning system’s art as SVG files, and wrote a command line tool to assemble it as a scaled spritesheet. I’m currently using Inkscape for both drawing and exporting (to PNG).
Burned some time trying to make a vector graphics format for ProdUI. I was able to render some test graphics to a canvas, but I couldn’t get from there to full integration with the skinning system, let alone decide on a file format. Integration of a subset of SVG (maybe lovector) is also an option.
