> Notice there’s a lot of pixels here that don’t map to any segments, 30% that will never be displayed.<p>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.<p>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.<p>[1] <a href="http://i1.wp.com/www.plingboot.com/wp-content/uploads/2017/02/cubez.jpg" rel="nofollow">http://i1.wp.com/www.plingboot.com/wp-content/uploads/2017/0...</a><p>[2] <a href="http://aa-project.sourceforge.net/aalib/" rel="nofollow">http://aa-project.sourceforge.net/aalib/</a>
This is ever so slightly thread-hijacking but I've been wondering something slightly related for a while now: what's the downright cheapest way to get into really really big LED matrixes? Like the kind used for signs (of various sizes; let's say I'm referring to around <2ft sq).<p>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 (?).<p>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. *<p>(* 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.)
<i>Now, I wonder if I can get an old calculator to play the accompanying 4 track MOD?</i><p>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.<p>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:<p><pre><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;</code></pre>
There was an art project done a few years ago using 7-segment displays and animations, looked quite cool too:<p><a href="http://hackaday.com/2013/11/21/7-segment-display-matrix-visualizes-more-than-numbers/" rel="nofollow">http://hackaday.com/2013/11/21/7-segment-display-matrix-visu...</a>
It's amusing but a bit underwhelming, he's simply mapping a grid of pixels to segments, he's not taking the shape and orientation of the segments into account at all.