Hi Matt, 2011/2/21 mattschinkel <[email protected]>
> I'm not sure if I should talk about this stuff here or in the opened > issue. > I'd like opened issue to track what's have to be done (todo list), so we won't forget any issues/improvements. > > glcd_font_use(), maybe just name it glcd_font(). > 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. > In > stm032qvt-003, there is a procedure named > glcd_address_set(x1,y1,x2,y2). Maybe these are similar in some way. In > stm032qvt-003, this procedure is used for quick printing of pixels > starting at x1,y1 ending at x2,y2. It is faster since you do not need > to specify location of every pixel. do you mean a line ? isn't it the purpose of lcd_line(x1,y1,x2,y2) ? > Later on, a font procedure should > be made with this pixel writing method. > 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. > > As for fonts, I see you have properties for: > _glcd_font_current_id = FONT_5X7 > _glcd_font_current_bpc = FONT_5X7_BPC > _glcd_font_current_width = FONT_5X7_WIDTH > _glcd_font_current_height = FONT_5X7_HEIGHT > > but maybe FONT_BIT_DIRECTION should be added to this list. This will > allow someone to use more then one bit-direction font. Every font > should have this property so a font printing proc can understand it. > 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 ? > > 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. > > I also worry about the font number - FONT_5X7 = 0x01 > Should this go int constants_jallib or font.jal? otherwise we need to > read every font lib to get a number that is not in use (if we add a > font). I know the correct place for it is in each font lib, but it > would make life easy if it is somewhere else. > It could go to glcd_font.jal, but maybe there can troubles about dependencies. To be checked. Else, it could be moved to constant_jallib.jal. I'd just like to avoid putting plenty of mess in this lib... > > 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... I also have to deal with GLCD_COLOR_PEN... Once all of this is done, I'll start working on pixel-based stuff (line, circle, rectangle, etc...) Cheers, Seb -- 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.
