Pages: 1 ... 4 5 [6] 7 8 ... 21   Go Down
Author Topic: GLCD library version 3  (Read 80528 times)
0 Members and 1 Guest are viewing this topic.
UK
Offline Offline
Newbie
*
Karma: 0
Posts: 15
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

BTW, may I have a feature request? For aligning the digits to the right I use my own function in the code: rightAlignment(). Can we do something more sophisticated from the library? Like TextAlignment(uint8_t alignment) and 3 arguments: LEFT, RIGHT, CENTER.

Many thanks

Tony
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2738
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Oh, well. Glad it is working. It's always the simple stuff that trips me up too.

Hey on a side note, I've been playing with the white pixel on blue background glcds a bit lately, and what
do you think about the use of "colors" with that type of display?
Currently BLACK means turn a pixel on and WHITE means turn a pixel OFF.
Was/Is it confusing to have to use BLACK to get pixels to turn "white" on those types of displays?

I was wondering if the library should have some sort of way to reverse the colors to
make it more consistent with those types of displays.
There are several ways to handle something like this.
I'm curious, What are your thoughts about this?

--- bill



Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2738
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

BTW, may I have a feature request? For aligning the digits to the right I use my own function in the code: rightAlignment(). Can we do something more sophisticated from the library? Like TextAlignment(uint8_t alignment) and 3 arguments: LEFT, RIGHT, CENTER.

Many thanks

Tony

I know what you mean. I have had many cases where I wanted to center text.
The general case of aligning text is a bit more complex than it may seem at first.

It could be a mode type setting like you have above and the alignment code could make some assumptions
about vertical positioning when doing future rendering (like the current vertical location,
but then it has to know the left and right bounds, which could be assumed to be the left & right bounds of the current text area.
But then you also have a few potential issues that crop up since alignment has to be based on strings
and the selected font (since each character can potentially have a different width)
so there has to be quite a bit of documentation explaining the behaviors of these modes
when using the existing text functions. Things like how to handle line wrapping or
what happens when next text after this is sent. Does it start a new line or go on the right of this string?
These are just a few of the things that pop up.

I've thought about it several times and never reached a conclusion as to the best way to do this.
My initial thought for ease of use and simplicity was to do something like an enhanced version
of DrawString() where you pass in additional parameters to specify the alignment and the bounds
for the alignment for that specific string. And perhaps a version where instead of a x,y position
you pass in the upper/lower, right/left bounds and the desired alignments. That way
the text can be aligned not only horizontally but vertically as well.

For what you are doing with simple numbers that are going to land in fixed width fields,
I'd recommend using text areas for the values along with printf. The glcd library has support
for printf built in. See the "Printf" function in the documentation and also the BigNums example
sketch for an example of using text areas to update numeric fields on the screen.
The use of a fixed width font along with text areas and printf can make updating those fields quite simple.
i.e. you use printf format capabilities to format the string with leading padding (zeros or spaces)
and then use the text area to hold a text field of the exact size of the numeric data.
Then to update the field you simply write to the text area.

For example once you defined your text area and set the font for it,
to update the value could be as simple as:
(assuming you named the text areas "volts", and "millivolts", used a fixed width font, and created 3x1 character areas for each)

volts.Printf("%3d", voltvalue);
millivolts.Printf("%3d", millivoltvalue);

If you want 0 filled, instead of leading spaces for small numbers,
you would use "%03d" for the format string instead.

Just keep in mind that when using Printf() in glcd that the current printf() support is limited to integers because
in order to get floating point support for the printf functions,
you have to link against a different AVR libC library and the Arduino IDE does not allow setting of any compiler or linker options.


--- bill




Logged

UK
Offline Offline
Newbie
*
Karma: 0
Posts: 15
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yeah it's a bit confusing. If I were you I'd add an extra argument in the GLCD.Init() like uint8_f displayColor. Or if you want to make it more straightforward and far more easy just simply rename the BLACK to ON and the WHITE to OFF so there is no misunderstanding anymore. smiley AFAIK it's still beta version, right?
Logged

Germany
Offline Offline
Edison Member
*
Karma: 137
Posts: 1517
If you believe something is right, you won't see what's wrong (David Straker).
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Isn't "SetDisplayMode" intended for this purpose? I have not tested it, but I would have expected from the docs that BLACK and WHITE have opposite meanings in INVERTED mode.

I looked up my m2tk source and surprisingly I have not used WHITE or BLACK at all. Instead I did all function calls without color argument.

From that perspective I would say:
1. GLCD API would become more complicated if you add an additional color mapping method.
2. At least in my programs BLACK and WHITE are not used, so I would not be affected by that change.

Greetings,  Oliver
Logged

UK
Offline Offline
Newbie
*
Karma: 0
Posts: 15
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hello Oliver,

Isn't "SetDisplayMode" intended for this purpose?

No, that turns on all pixels by default and you write in inverse mode. So you actually turning off pixels by writing.

Quote
From that perspective I would say:
1. GLCD API would become more complicated if you add an additional color mapping method.
2. At least in my programs BLACK and WHITE are not used, so I would not be affected by that change.

1. That is true, that is why I suggested two possible ways to solve this.
2. Yes, but this is library for many users. smiley

However you might be right on the latter as the INVERTED and NON_INVERTED variables could be used for this purpose as well, instead of the BLACK and WHITE.

Bill what do you think? That would be even more straightforward than the ON/OFF. smiley
Logged

UK
Offline Offline
Newbie
*
Karma: 0
Posts: 15
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Bill, as for the TextAlignment() issue I'll think about it. In the early 90s I wrote a complete graphical library for DOS with VESA true color support that used all these functions. It could make texteditors, editboxes, combos, buttons, lists, scrollbars, radiobuttons, etc. I'll think about how I solved the textalignment.
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2738
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Isn't "SetDisplayMode" intended for this purpose? I have not tested it, but I would have expected from the docs that BLACK and WHITE have opposite meanings in INVERTED mode.

I looked up my m2tk source and surprisingly I have not used WHITE or BLACK at all. Instead I did all function calls without color argument.

From that perspective I would say:
1. GLCD API would become more complicated if you add an additional color mapping method.
2. At least in my programs BLACK and WHITE are not used, so I would not be affected by that change.

Greetings,  Oliver

Actually same for me. Up until recently I did most of my testing on black/green displays and
while I had a few white on blue I displays I never really specified colors either. The default is to turn pixels
on for most functions which works quite well as it is black pixels on black/green displays and white pixels
on white/blue displays.
It is only when you start to specify pixel color that things get strange.
In fact is was only as I was doing a function for XBM bitmap support when I ran really ran into the issue.
I was looking at supporting foreground and background colors for the bitmaps (including transparent),
and when testing on a white/blue display, it got very confusing.

Inverted mode doesn't really solve the issue. Yes inverted mode does invert the meaning of white & black
but white pixel type displays are "inverted" naturally. So if you use the inverted option in the API, you end up
with a very bright display with black pixels. While black means black/blue and white means white in this case,
from what I've seen the displays are not normally used in that mode. The normal use for white on blue
displays is for white pixels with a dark background.


My initial thought was not to modify the library API at all but rather to have a settable option in the glcd config
file so that this reversal is done at compile time.
But since there is only a single glcd config file it doesn't allow using the same library on different displays
without having to modify the config file for each display type.
It could also be handled runtime with a parameter to init()
but this is not my preference as it increases the size of the code and slows it down.

Right now I'm trying to get some feedback on how big of deal this is to decide if it is something
that I need to worry about right now.
Since no folks seem to be complaining, I'm assuming it isnt' that big of deal yet.


--- bill



Logged

Germany
Offline Offline
Edison Member
*
Karma: 137
Posts: 1517
If you believe something is right, you won't see what's wrong (David Straker).
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi agentgates

As I said, I have not tested INVERTED mode, but from a short review of the source code, I would say, that the meaning of BLACK and WHITE is swapped (see ReadData and WriteData procedures in the device class).

Quote
Inverted mode doesn't really solve the issue. Yes inverted mode does invert the meaning of white & black but white pixel type displays are "inverted" naturally.
But couldn't you than BLACK the screen and use WHITE to draw Text and Graphics?   

For the alignment: Within m2tklib for GLCDv3, you could use M2_ALIGN (http://code.google.com/p/m2tklib/wiki/elref#ALIGN). But using m2tklib might be a little bit overkill (although i guess it will only add 5-10KB to your program).

Oliver
 
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2738
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Bill, as for the TextAlignment() issue I'll think about it. In the early 90s I wrote a complete graphical library for DOS with VESA true color support that used all these functions. It could make texteditors, editboxes, combos, buttons, lists, scrollbars, radiobuttons, etc. I'll think about how I solved the textalignment.

The glcd text isn't handled like text on most GUI text boxes. The biggest difference is that
the text is rendered directly into glcd memory and then it is essentially "forgotten".
There is no local AVR memory allocated for any of the text on the display.
Text essentially turns into a graphic once it is rendered. So you can't do fancy alignment on the fly as
characters show up. It has to be done all at once so you have to have the full string and all alignment parameters up front.
It also makes it impossible to do things like scroll bars.


I think to provide the ability to align simple text strings, extensions to DrawString() are the way to go.
It is a very easy addition and avoids many of the formatting "gotchyas".

The library already has a StingWidth() function to return the width in pixels. So it is just
a matter of providing a small wrapper to do the math of where to position the first character.

--- bill
« Last Edit: September 03, 2011, 05:29:34 pm by bperrybap » Logged

UK
Offline Offline
Newbie
*
Karma: 0
Posts: 15
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'm aware of these things Bill. It is a simple framebuffer programming, just like directly programming the video card framebuffer in PCs except by using different bitmap layout (depends on the color mode).

Yes, you can make fancy widgets like scrollbars mate, by storing their position values (top, bottom, width, position) in a c++ class and redrawing the changed areas or the whole thing. smiley If I had the demand I could either write a lightweight windowing system with the same technique. Just like old time. smiley
« Last Edit: September 03, 2011, 05:39:59 pm by agentgates » Logged

Germany
Offline Offline
Edison Member
*
Karma: 137
Posts: 1517
If you believe something is right, you won't see what's wrong (David Straker).
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
It also makes it impossible to do things like scroll bars.
I am currently working on scroll bars for m2tklib. So I am sure, next version of m2tklib for GLCDv3 will have scroll bars  smiley-wink

Oliver
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2738
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'm aware of these things Bill. It is a simple framebuffer programming, just like directly programming the video card framebuffer in PCs except by using different bitmap layout (depends on the color mode).

Yes, you can make fancy widgets like scrollbars mate, by storing their position values (top, bottom, width, position) in a c++ class and redrawing the changed areas or the whole thing. smiley If I had the demand I could either write a lightweight windowing system with the same technique. Just like old time. smiley

It isn't always just a matter of programming or techniques.
Believe me, I would much prefer to have used a framebuffer.
A framebuffer would make many things easier. Much easier than what the current library code does.
It would also allow the possibility of many additional new very useful features.
The main issue is RAM. Some of the AVRS only have 1k of RAM.
It is quite difficult to provide high level features without using much RAM so that
the library can function on these limited RAM microcontrollers.

Things get pretty tough when trying to support GLCDs that have larger display memory on them than
the microntroller has RAM. Think of trying to support a 192x64 display
when only having 1k of RAM in the microcontroller.
It is simply not possible to use a framebuffer for that sized display much less have
a framebuffer that is larger than the display memory for things like scroll bar
support.
Even on a m328 which has 2k of RAM consuming 1k for a simple framebuffer for a 128x64 display
might be excessive depending on the users application.
Bump up the display size beyond 128x64 and you rapidly begin to run out of RAM
for a frame buffer.

There are some games you can play if you store the text characters rather than
the full bitmap of the GLCD, but it gets extremely messy and complicated when trying
to intermix graphics and text than can scribble anywhere on the display.

Even the old IBM Monochrome and CGA adapters from back in 1981 had more memory than this. They
also had more memory than the display needed which could be used for additional storage.

My ideal would have been to have enough RAM for two frame buffers.
One for graphics and one for text. Then the two could be combined when drawing
on the physical display so things like text could overlay the graphics and even scroll on top of it.


--- bill
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2738
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi agentgates

As I said, I have not tested INVERTED mode, but from a short review of the source code, I would say, that the meaning of BLACK and WHITE is swapped (see ReadData and WriteData procedures in the device class).

Quote
Inverted mode doesn't really solve the issue. Yes inverted mode does invert the meaning of white & black but white pixel type displays are "inverted" naturally.
But couldn't you than BLACK the screen and use WHITE to draw Text and Graphics?   
 

Actually, that will work. You have to intialize the display as INVERTED, then *always* use colors on all calls.
So things like:
GLCD.ClearScreen(BLACK);
GLCD.SelectFont(System5x7, WHITE);
GLCD.DrawLine(x1,y1,x2,y2, WHITE);
etc..
Yes it works, the only limitation is that you can't eliminate the color parameter for any graphic or font calls.
Maybe this technique is something useful that should be added to the documentation?

--- bill
Logged

UK
Offline Offline
Newbie
*
Karma: 0
Posts: 15
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
The main issue is RAM. Some of the AVRS only have 1k of RAM.

Ah ok, I'm with you now. smiley
Logged

Pages: 1 ... 4 5 [6] 7 8 ... 21   Go Up
Jump to: