I'd like to create a small 2D rendering library targeted at ESP32 or similar very constrained MCUs. Any suggestions on approaches to use/avoid? Code size, memory usage above all.
Conversation
Replying to
Less for esp32 and more depends on the particular display in use, usually over SPI. 565 16 bit color is common
1
It depends what you want to render in 2D. Sprites? Resizable sprites? Rotating sprites? Vector lines? Smooth fonts? They're all very different bits of code. And I'd certainly start with just a library of rendering routines rather than building "an engine"
1
Definitely not an engine. Really only vectors/bezier curves, with solid/gradient/pattern brushes. No sprites, and probably no font rendering from the glyph curves.
1
1
Well then you will be making friends with Mr. Brezenham then :-) The trickiest part is usually getting sub-pixel accuracy working. It's a pain, but the image quality is important. 8 bits of sub-pixel precision is usually a good balance.
1
2
Hmm Bresenham? Or edge list/scanline (what’s the actual name of this)? I don’t see how I’d do filled paths with Bresenham but admittedly
1
Ah, well if you'd said filled paths... yeah, lots of options there. Yeah, "edge list" or "span buffer" is probably what you're after. You use Bresenham (or similar) to generate the span edge, then fill them with patterns.
1
2
...but I've not done any work in the 2D vector art/filled path world, so that's about all I know, sorry. Two maybe relevant things I know of are:
acegikmo.com/shapes/ by
and
sluglibrary.com
Yeah I’m in the same boat. It’s odd, I feel like I understand 3D waaaaaay better than 2D. Even though I suppose 3D ultimately decomposes into 2D :)
My willpower to do this goes up and down, I get annoyed at fiddly math. Give me large scale systems problems any day
The problem with both of those is they’re both targeted at rendering 2D with 3D hardware efficiently