Unfortunately this problem, the slant (italic) added by the hardware, and the bias introduced from mapping the horizontal lines (A, G) to the "left" pixels only, causes artifacts in the output. A good example is the left side of this[1] image, where the bottom of the 7-seg displaying "F" has a large jump rightward to the "1" below it.
To get around these problems, aalib[2] renders each glyph that it will use, and for each block of pixels to display calculates nearest glyph. This automatically provides anti-aliasing for any shape glyph. As you already have the error (remaining distance to nearest glyph) for each group of pixels, it is also easy to add dithering to distribute the error across the image.
[1] http://i1.wp.com/www.plingboot.com/wp-content/uploads/2017/0...
The major issue I'm completely ignorant of is how to get enough I/O that can drive the LEDs directly - I'm assuming something with lots of direct drive I/O and no intermediary components would be the cheapest way to do it (?).
I understand multiplexing is the only way to survive at scale, but for small displays (say, 5x30 (= 150 LEDs)), what solutions would have enough I/O to drive each LED emitter individually, without scanning? I've always wondered what a truly flickerless LED matrix would look like. *
(* Several years ago I had an odd incident where after using a scientific calculator I'd see weird swirling patterns overlaid on top of whatever I was looking at. The LCD itself was not faulty or damaged, and I couldn't see any flickering at all. Considering LCDs run at 30-100Hz, the whole incident (it stopped after a while, I have some theories as to why) made me curious what a truly DC-driven LED matrix would look like.)
All of the LED driving is taken care of by the module, except for multiplexing the 'lines'. So these work by having drivers for one 'line' or LEDs (or 2 lines on the 32 LED high modules). You shift out the bits to them on a 16 pin plug. My clock as using an STM32F4 chip on a 1Bitsy[4] and was doing 240 FPS. Since these micros can be easily paralleled and synchronized you can drive an arbitrarily large sign by adding about $25 per 16 panels. Feeding them all data is a bit more complicated but not terribly so.
[1] https://www.aliexpress.com/item/3mm-Indoor-SMD0606-rgb-led-d...
[2] https://twitter.com/ChuckMcManis/status/794023527720620032
[3] https://twitter.com/ChuckMcManis/status/794025248203022336
[4] https://1bitsquared.com/collections/embedded-hardware/produc...
Hmm. I wonder what the weatherproofing (particularly heatproofing) on these things is like. I know of a time/temp display high up on a building (probably around 1x1.2m²) that is constantly corrupted, I'm wondering if it's the 40°C days around here (Sydney Australia) that keep hitting it...
It's fascinating watching how QR encoding shifts and changes data - some of the time updates just adjust a few pixels, some of them adjust the whole barcode. I wonder what the source data for each frame was (but not terribly so).
So... if I understand right, these are line-buffered? You send it a line's worth of data, hit "go", and it redraws that line? 240FPS is good, wow.
One question: in the first couple of "ticks" of the second hand on the first clock video, I noticed how there appears to be a minor bit of "LED bleed" where some of the LEDs don't switch off for a couple fractions of a second. Curious, I had a look at the video frames: http://imgur.com/a/EVYB2. Is this an intrinsic problem in the driver system or perhaps a camera or encoding/compression glitch?
Add some music and the demosceners at pouet.net might get interested in seeing it; they have a "wild" category for hardware/exotic demos like this.
I agree with the second comment there about replacing the verbose chain of if-statements with a single expression; my first thought upon seeing that was "this really needs to be simplified"; likewise, the second part with 7 nearly identical lines shifting left and then right by the same amount, then multiplying by 255(?!) can be simplified to a loop; the way it looked with lines for B and C having a slightly-different mask constant is misleading, since it looks like a copy-paste error. Here's an (untested) attempt at simplifying the code:
int yoffs[] = { 0, 1, 3, 4, 3, 1, 2 };
shift = 6 - ((digit&3) << 1);
for(segs=0,i=0;i<7;i++)
segs |= !!(screen_buffer[bx+yoffs[i]][bx] & 1 << shift+(i<1||i>2) ) << 6-i;Revision 2017 has a Wild competition coming up in mid-April as well:
http://hackaday.com/2013/11/21/7-segment-display-matrix-visu...
It would be easy to rework this into a good comment by expressing your point additively rather than as fault-finding. For example, mention "shape and orientation of the segments" as the next thing to take into account and add some information about how one might do that. Then you're helping all of us learn.