Hi Matt, guys, Can you confirm FONT_BIT_DIRECTION feature isn't implemented yet ? I can't find anything related to its usage.
I've committed some more modifications: - Nokia 3310 controller already deals with auto-wrap, according to datasheet. Defining FONT_AUTO_WRAP while using glcd_nokia_3310.jal library isn't allowed (error message). - I've renamed lcd_back_color to lcd_background_color, make it lowercase when it's variable (same for lcd_pen_color). Need more tests. - I've implemented lcd_background_color in nokia 3310, unifying print_char() and print_char_i() procedure to lcd_write_char() - I've added some color constants to constants_jallib.jal (within - I've update KS0108 library: previous lcd_write_char() renamed to ks0108_write_char(), it uses internal font table, for minimal fontprint. Added lcd_write_char(), honoring font library usage. Using 5x7 font (same as internal font table), overhead is currently something like: -- before [...] Code area: 3134 of 32768 used (bytes) Data area: 90 of 928 used Software stack available: 838 bytes Hardware stack depth 2 of 31 -- after [...] Code area: 3284 of 32768 used (bytes) Data area: 96 of 928 used Software stack available: 832 bytes Hardware stack depth 2 of 31 Not tested though... We may ask Joep if he can test this when API is getting more stable. Next steps I can see: - define an offset to deal with font containing letter (font table index = 32 + char) or just sprite (font table index = 0 + "char") - nokia 3310 tests regarding font usage. - documentation about font API in general. - clean Suggestions: - don't you think all char related stuff (eg. definition of lcd'put) should go to glcd_font ? I think it can help to separating char-based and pixel-based stuff, and match user need (you may just want to use char stuff, not pixel stuff). Cheers, Seb 2011/2/21 mattschinkel <[email protected]> > > but, since one byte corresponds to one pixel column (or row, depending on > > FONT_BIT_DIRECTIO, right ?), if your char is 5 pixel width, it'll need 5 > > bytes. > > Not nesessarily. 8x12 will need 12 bytes per character, 12x8 will need > 16 bytes per character and have some wasted bits, if bit order is the > same. 12 must go in to 2 bytes and "x8", so 2x1 bytes = 16. > > 5x7 font must have wasted bits somewhere, although 5x7 and 7x5 would > both contain the same number of bytes per character since it does not > cross any 8 bit boundary. > > It is important to think about weird sized fonts, like 9x17. again, > full explanation in glcd_font. > > please keep the bytes per character constant since we will have > different number of characters per set. > > > No, the reference position is what moved. From this position will occur > next printing. > > Your write_pixel procedure should only write one pixel and not > continue. This other feature lcd_gotoxy(x,y) is not alike other > glcd's. It would be faster however. This still sounds similar to my > glcd_address_set(x1,y1,x2,y2), except that yours would wrap at the end > of the screen instead of at x2. When you get to drawing lines etc, we > will have to stick with something similar to all lcd's, which so far > is only write_pixel. When there is a general font procedure in > glcd_common, it will need to use write_pixel. anyways, we'll continue > with fonts for now. > > > have a look at 18f4550_nokia_3310_udf.jal. It declares a user defined > > font (UDF), there are only 5 chars, which are actually some kind of > sprites. > > The writers of the first font libs have assumed only printable > characters would be used. I'm sure we will have some fonts with small > images, that font may or may not start at offset 32. How much does it > matter? You can add a offset if you wish. > > Matt. > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jallib?hl=en. > > -- Sébastien Lelong http://www.sirloon.net http://sirbot.org -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
