Text Library re-write and new fonts

[GoogleCodeExporter]

The current text sketch works, but it is very limited due to memory 
constraints. Current letters are stored as individual points that are moved 
around. A single letter can take up 8-34 bytes each! That eats up the available 
2k of RAM very quickly.

Just putting all the fonts in progmem would help. The fonts will need to be 
stored in bit arrays. They really shouldn't be any larger than 5-9 bytes per 
letter, one for each vertical line. A full ASCI character set shouldn't be more 
than 2k stored in ROM, and that's a full board height font. Though adding a 
single byte at the beginning of each character could allow for each letter to 
have it's own width, and would allow for some kerning.

It would probably be helpful to do the object tracking library first, as that 
would make the font one much easier. Storing and reading to ROM is fairly 
straightforward.

Original issue reported on code.google.com by jaypee4...@gmail.com on 13 Jul 2010 at 3:49

[GoogleCodeExporter]

I was actually thinking about compression a little. We could do something 
simple like having the first 3 bits of the first byte contain the width of the 
char. In that way, a single width char like the letter i, would only take up 1 
byte at 5 lines high.

Basically, after the first three bits, the letter would start. It would then 
count the width, and wrap into the next byte if needed. That would get rid of 
some of the blank space. 0 would stand for full 8 bit width. I doubt that we 
would need anything larger than that, since that is over half of the total 
display width of 14.

Original comment by jaypee4...@gmail.com on 13 Jul 2010 at 4:04

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Should be able to alleviate this up by storing the font in the program memory 
rather than ram. Can use the prog_uchar type. I've got an example here:

http://github.com/cibomahto/LED-display-driver/blob/master/led_display.pde

Original comment by Matt.M...@gmail.com on 18 Jul 2010 at 5:37

[GoogleCodeExporter]

Switched the current font over to program memory in SVN commit 7. This fixes 
the ram problem, but not the font size problem.

Perhaps we could adapt phooky's font generator to work with >8-height fonts?

http://www.nycresistor.com/2010/03/22/march-madness-backlog-microcontroller-pixe
l-font/

Original comment by Matt.M...@gmail.com on 19 Jul 2010 at 6:49

[GoogleCodeExporter]

Here's a first pass at using fonts from the font generator mentioned in comment 
3. Draw90() is not implemented correctly.

Original comment by Matt.M...@gmail.com on 21 Jul 2010 at 8:59

Attachments:

• Font.cpp
• Font.h
• font.cpp
• font.h
• LoL_scroller.pde

[GoogleCodeExporter]

Here is my rewrite of the font library :

http://github.com/guyzmo/LoL-shield-dynamic-banner

it features :
 * dynamic display of text input from serial line (function UpdateTextFromSerial(); in loop())
 * reduced font size (each line is one byte)
 * variable font width (first byte is used to tell the font size)
 * scrolling text to left or right (function ScrollLeft_setup(); or ScrollRight_setup(); in setup() and Scroll(); in loop())
 * font generator (still hacky, because it uses bc+python, but can be improved, so all is done using python) from binary matrix to C code
 * reduced memory footprint and flashcard footprint (with twice as much glyphs for a font)

maybe we could reuse phooky's code for font generation, or compile libcaca's 
fonts to C code (libcaca has already a few fonts already made, it supports 
unicode and generates a rather big C code, with a full descriptor to tell how 
it is built). 

We can also reduce flashcard footprint (and store more fonts) by earning a byte 
for each glyph (instead of doing each glyph an array of uint8 bytes, we can 
collide the lines to maximum 8 bytes + 1 byte of width, using that value for 
memory alignment ; ie a 6 pixel wide font is 9 bytes, a 4 pixels wide font is 6 
bytes). 
Another thing that we can try to win more memory is storing the height of the 
font same way we do with the width (can be useful with lower case glyphs and 
punctuation)...

Original comment by guyz...@gmail.com on 22 Jul 2010 at 1:23

[GoogleCodeExporter]

I realize you guys don't know me from Adam, but I rewrote the fonttest pde so 
that it was both dynamic with the length and a little more comprehensible with 
the variable naming. Feel free to use it or trash it...I thought I'd share.

Original comment by cbehr...@gmail.com on 6 Sep 2010 at 3:40

Attachments:

• fonttest.pde

[GoogleCodeExporter]

Thanks cberens, I'll have a look at it as time allows.

Original comment by thilo.al...@gmail.com on 7 Jan 2012 at 7:57