> > What is the purpose of lcd_gotoxy(x,y) in glcd_nokia_3310? > it moves to position (x,y), where x & y being pixels number. for 3310, > screen is 84x48, so x can be 0 to 83 and y can be 0 to 47.
what moves to that position? the font? > > glcd_address_set(x1,y1,x2,y2). > > do you mean a line ? isn't it the purpose of lcd_line(x1,y1,x2,y2) ? > > why ? I'm not sure you'll gain memory because encoding may require lots of > memory using this method. well, this can be done later anyway. Let's forget > about this for now, if you're ok. No, this is not for drawing a line, it is for drawing an image or to fill some space at x1,y1,x2,y2. It is much faster then drawing pixel by pixel. On a large LCD like mine, you notice speed. Anyways, we will put it asside for now. > > but maybe FONT_BIT_DIRECTION should be added to this list. > > I wanted to ask about this parameter. I'm not sure to understand what it is, > or at least why it is font-specific. Can you explain more ? Sure... read my many comments glcd_font.jal. It is the order of bits in each character, and how it should be printed to the screen. A 6x8 text will have a different bit order then 8x12 to save space and speed. If I ordered bits in 8x12 the same way 6x8 is, I would waste these resources. 8 bits fits in a byte nicely, but 12 doesn't. > > I'm not sure what FONT_5X7_BPC is, I assume it is bytes per character. > > why not name it FONT_5X7_BYTES_PER_CHARACTER? > > Yes, it is "byte per character", and it could be named as you suggest. It > could also be removed completely, because, AFAIK, byte per char is font's > width. Am I wrong ? If not, we should remove this parameter and strictly use > FONT_*_WIDTH. No, bytes per character is not it's width. It is actually now many bytes a character takes. It could be removed if we assume font sets have the same number of characters. bytes per character = (font array count) / (# of characters) If you want, you can make a constant for each font named number_of_characters then calculate bytes per character from that as a new constant. not sure what is best. Here's a example from 8x12. the character "!" is 6 bytes, and so are all others in that font. 0x00, 0x00, 0x00, 0x2f, 0x00, 0x00, -- ! > > You will see a old lcd_line() procedure in glcd_common.jal, this proc > > did not work for me and was therefore replaced. Could you please test > > this new proc? > > As I said, I prefer to focus primarily on char-based stuff, and let all > these pixel-based procedure for a second step. For now, I need to finish > migrating nokia 3310 API. For instance, I don't even have a lcd_write_char() > procedure. I tried to migrate it, but it seems this GLCD doesn't behave like > yours, or like KS1108. I mean, when I print a char (using current > print_char()), it seems the cursor automagically move to next position. So > when I'm using pseudo-variable lcd'put, defined in glcd_common.jal, it gets > confuse because your lcd'put takes care of wrapping and positioning cursor > for next character printing. I need to dig further, I didn't have a chance > to give a look at 3310 controller's datasheet... Take care of font bit order and how it should get printed to the screen. 5x7 is much different then 8x12. again, study my notes in glcd_font.jal. 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.
