Yes... I have experience of palette and True Colour and also Alpha channel and Z buffer.
I have most of these and using most with PIC 18F4550 / 16F877 and KS0108 Mono Library: I would call the items (all draw one pixel wide in on or off ink, to allow erase/animation) (I'd not bother with XOR mode drawing as it looks terrible) PlotPixel DrawOrthLine DrawLine -- any angle DrawBox -- only orthogonal uses DrawOrthLine DrawRect -- uses DrawLine, so can draw rectangle any angle DrawPoly -- less useful DrawCircle -- radius and x.y of centre DrawButton -- location, width, height. DrawBox with a drop shadow. Show a physical Keypad map or be a touch key DrawStyledLine -- width, dash/dot style also Versions where a parameter is line width of border and Fill ink is specified. DrawFillBox -- only orthogonal uses DrawOrthLine DrawFillRect -- uses DrawLine, so can draw rectangle any angle DrawFillPoly -- less useful DrawFillCircle -- radius and x.y of centre Higher level objects have multiple procedures: Clock vertical bar with optional graticules -- use for meters, progress bars, VU, signal level etc. Horizontal bar with optional graticules X,Y Plot Graph. Can plot in real time (repeated calls in loop/ interuppt) or an array. Line, points or Bar style I also use by default 6 x 8 grid with 5x7 font but have control characters and command: Commands: goto XY -- not Row, Col! on current character spacing/line spacing grid! line spacing (to fit text in buttons) character spacing Control Characters: Double Size (2x2 pixels for each font dot, i.e. 10x16), Bold, Underline, Normal For efficiency, the basic library "ink" is a on/off a palette based display uses byte ink and a separate Palette procedure A true colour (RGB) or high colour (16bit) uses either R, G and B ink as byte, or if you want to be neat, use an array of 5 bytes, R, G, B, Alpha and Z Alpha is transparency, and Z is one of 256 layers. from foreground to background. So really on/off mono displays need different library to colour for efficency. A grey scale display is same as palette based (single byte ink) except there is no palette procedure. I've also simulated grey scale on the on/off display by dither pattern (hercules display on PC) and 256 colour on a 16 colour EGA. There is not a lot you can do with the slug death CGA (four colour or maybe four other colour, it's better in higher res mono!). Clock: Changing the X & Y location by constant is no Code/CPU overhead. Changing X & Y at run time is about 24 adds I think, every second. Scale at run time is needing a lookup table of 15 sin values (you can use it for 0 to 360 and Cos ) and suitably accurate arithmetic to calculate the 60 ends of second hand 60 ends of minute hand 12 to 48 ends of hour hand 12 hour markers 60 minute/second markers. The co-ordinates are calculated for a given radius on spreadsheet right now, and the spread sheet can have the whole statement with numbers filled in so you just copy / paste the entire MinuteHand etc... It's R* cos(theta) and R * sin (theta) . But of course you only need a multiply and 15 sin values in a table to do all 60 positions. I suppose at Init time you would calculate all the positions. That would be a lot of RAM. Or write them to EEPROM and read that to plot hand. Or do 8 adds and two multiplies for each hand every second... -- 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.
