how to work with font?

nicolad76

Hi,
I need you guys to address me toward the best way to solve my problem.
I have 1 Prop with 3x24FC1025 so 3Mbytes of memory.
The prop is driving a b/w display that only accepts bitmaps (I have to prepare the sequence of 1/0 to be represented on the screen).

When it comes to display pictures it is a piece of cake but now I want to put "words" on the screen.
How do I "create and handle" fonts? I thought to generate a bitmap of the chars and symbols I need, to lead them in one of the eeprom·and then to pull out 1 char at the time to rebuild the·"word" in memory (prop memory!?!?!). I am not sure it is not the best way to do it·since it is slow and the prop·does not have enough mem to support long words or big fonts.

How do professional handle this kind of situation?
One idea would be to have each char generated by a "formula" (is not what they do with true type fonts?) but, still, the formula would be a sequence of "line", "arc" etc...which I would have to translate into 1/0 before sending it to the display...

Any suggestion?
Thanks you guys!!!

Ale

If the display only takes bitmaps, and they do fit in the Prop's memory... you just draw to the bitmap and send it to the display.
If they do not fit, you will have to generate the bitmap "on-the-fly", line by line using whatever font and text you want to display. The VGA _text_ driver in the object exchange does exactly that. (The TV driver also). But they use the prop's internal font and video generation circuitry.

If your display expects say 8 bits of mono bitmap, you can generate line by line laying your text in a "text buffer" say 40 chars by 8 lines and you read char by char generate the bitmap for that part and send it to the display, like those drivers do.

Rayman

Check out my "LCARS Test":

http://forums.parallax.com/showthread.php?p=715508

There I used my 1-bit bitmap app to create a bitmap font.

Then, used a table to index the font and show characters.

Here's a link the the 1-bit bitmap app:

http://www.rayslogic.com/propeller/Programming/1-BitBitmap/1-Bit%20Bitmaps.htm

(PS:· Note:· I'm not a professional programmer!)

Here's the source bitmap:

Mike Green

By the way, 3 x 24FC1025 EEPROMs gives you 3M bits or 384K bytes of memory.

The way bitmap fonts work is that you essentially have a table indexed by the character value and the display row of the character. Each entry in the table consists of the display bits needed for a line / row of a character cell. For a 6 x 8 pixel character cell, you'd have 8 lines of 6 bits each. For simplicity, this would be stored in a byte rather than 6 bits.

The display driver keeps a pointer to the display text buffer and the display line within the character row. It picks up the character and uses that and the line number to look up the 6 bits in the font and copies that to the display, then goes on to the next character.

Post Edited (Mike Green) : 6/5/2008 1:45:24 PM GMT

Agent420

Just curious...· does the eeprom serial access cause any timing problems?· It seems time constraints for producing video are already on the tight side.· You'd have to ensure you have enough cycles available to locate and transfer the font map for each character... would that process require·a cog of it's own to keep up?

nicolad76

Hi guys...yhea... 3M bits...correct...probably I was dreaming of bigger EEPROM [noparse]:)[/noparse]
I believe my problem still remain since the display is 600x800 and char size has to be bige...let's say something around 60x60 and more...
This would make the entaire font to heavy to be loaded at once....
I will give a try to DOL in order to dinamically load/unload the set of chars I need.

Thanks

StefanL38

hello,

so if the characters have a lot of pixel you could define vectorlist of the inner and outer boarder of the character.
And then scanning the characterarea in horizontal lines. Everytime you cross a boarder from outside to inside
of the character you start filling the line. Everytime you cross a boarder from inside to outside you stop filling

still defined per pixel
60x60 pixel = 3600 Pixel / 8 bit/byte = 450 Bytes per character * 128 characters = 57,600 kB
80x80 pixel = 102,4 kB should fit into your EEPROM-memory

a compromise could be:

Creating the font in that size you need it. And then use some kind of an compression-algorithm
The algorithm analizes the character line by line. Then it stores only from X=0 to X = 50 black from X=51 to 70 white etc.
this can be even smaller by just storing the distance. You now each line starts (relative at 0 so it is enough to store 50-black 19.white etc.
and as long as your character does not exceed 128 pixel you could store the information black/white in the MSB

Maybe in summary over all characters it saves memory to to this scanning horizontal and vertical. Compare which direction needs less bytes
and then storing one byte with the scan-direction and then follows the rest. A character like "T" a lot of lines repeat with the same pattern
there could be coded "repeat the last pattern for 50 lines"

I took a a zoomed look at the parallax font. If the character is complicated like a "a" it takes maximum 5 bytes to define one line.
whenever the sum of the distances reach the chararealimit you know end: of this line start new line.

First - very raw estimation: 32KByte / 128 chars = 256 / 5 byte per line = 51 pixels.
In real it will take less memory because of repeating patterns How much this is depends highly on the used font

Anyway if you want to have the font this big and still smoth it will take a lot of memory so the idea about a second prop
just beeing the "graphic-card" is good.

regards

Stefan