Fascinating! Two secret Internal Rom Fonts!

ClemensClemens Posts: 234
edited 2008-02-17 - 17:20:28 in Propeller 1
While playing with my Dogm-LCD-Display and the driver DeSilva made for it, I managed to find a cool way to scale down the internal rom font to a reasonable size.
This could also be interesting for other·people who need smaller fonts·and need to save memory -·and maybe even for Parallax. (the Font for Prop2 could probably be further optimized for good scalability...) - so I thought I'll share·this in an extra-thread not in the dogm-workshop.

Scaling down the rom-font is no big deal you may say, just skip every other line and column or use every third. But if you just do that,·the font·doesn't look very readable.
I found out that it looks best if you use lines 1,4,6,9,11,14,17,20,22,25,27,28,31
Don't ask me why, I just tried it out until it looked best.
With the columns it's slightly more complicated: if you take every third column, starting from the second column you get a nice·6 x 12 pixel font, if you take every·other column starting from the second column you get a beautiful bold 8x12 font. - Except some characters that have to be treated differently:
With the normal font characters "kKf*.R€▶◀>:;,t" should start from the third column and for the bold font characters "14IilYZ7VT" should start from the first column.

I know this sounds confusing, but it can all be done in a few lines of spin and really saves a lot of memory if you need it.

I also know, it would have been nicer if I could have·demonstrated this with the TV_text object, so you could all see the font on TV-screen,·but implementing it there is far beyond my skills, I'm afraid...


....well here goes another thread that I'm really not sure it's a good idea to start it... I hope someone shares my fascination about this... ;-)

Attached are the spin-files based on deSilva's driver for the dogm-display.


  • stevenmess2004stevenmess2004 Posts: 1,102
    edited 2008-02-13 - 21:38:43
    No problem with starting a new thread. This could be useful for several things. Should the display in the first picture read 6x12?
  • ClemensClemens Posts: 234
    edited 2008-02-13 - 21:43:16
    Right, haha, that was the hidden mistake to check if someone looks at it smile.gif
  • BeanBean Posts: 7,967
    edited 2008-02-13 - 22:10:04
    Nice job. I too tried using every other row/column and like you say "it don't look good".


    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  • RaymanRayman Posts: 9,210
    edited 2008-02-13 - 23:12:06
    Nice! Might be good for this Nokia display I have... The 6x12 font looks like it could be trimmed down to 6x9 or 6x10 for common characters maybe...
    Prop Info and Apps: http://www.rayslogic.com/
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,194
    edited 2008-02-13 - 23:45:39

    Very nice, indeed!

    With TV output, since there are several gray levels available, it might be interesting to see what can be accomplished at lower resolutions with anti-aliasing. For example, by examining a 2x2 "super pixel" in the original font and counting the bright pixels within, one could assign it an intermedtiate intensity level. This might result in something that's still readable and pleasing to the eye ... or it could end up looking like total mush.

    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • deSilvadeSilva Posts: 2,967
    edited 2008-02-13 - 23:58:08
    Phil, you don't have "several gray levels" within one tile smile.gif
    The problem with using this font is that the standard TV driver trickyly uses 4-colour mode, which in turn was the reason to interleave the characters in ROM in the first place.

    Clemenses glyphs however can be used as "pix" with (modified) GRAPHICS

    Using them with a tiled driver will need special modifications inside TV or VGA.

    Not that using those fonts with the DOGM display is easy. Obviously you could have 5 lines on it rather than 4. But as its internal addressing is arranged around 8 pixel lines it is extreme awkward to put 2 logical lines into 3 physical.

    It might be best to simulate a full bitmap memory, swapping to the display. As it is B/W only this will not take so much memory (1 kByte). This need not even bind a COG as it can be done "on demand" from the main COG.

    Post Edited (deSilva) : 2/14/2008 12:08:12 AM GMT
  • stevenmess2004stevenmess2004 Posts: 1,102
    edited 2008-02-14 - 00:03:06
    deSilva, it would be interesting to choose the colors for graphics as a 2 bit grayscale and then try the anti-aliased idea.
  • deSilvadeSilva Posts: 2,967
    edited 2008-02-14 - 00:10:21
    @Steven: One can try.. It's tricky.. When collapsing 2x2 pixels you need all 4 grays (black, d'gray, lt'gray, white)

    @Clemens: Was ich noch sagen wollte: Eine geniale Leistung, das ausget
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,194
    edited 2008-02-14 - 00:35:30
    Five gray levels would be optimal, of course, but four (i.e. "several" smile.gif ) would have to be enough, doubling up on one of the counts:

    ····0 pixels => black
    ····1 pixel => dk gray
    ····2 pixels => med gray
    ····3,4 pixels => white

    My gut tells me, though, that effective anti-aliasing is more complicated than just counting dots in each super pixel. The states of neighboring pixels might have to be considered, too. At some point, the computational burden will become too great to accomplish between WAITVIDs or during horizontal blanking.

    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • stevenmess2004stevenmess2004 Posts: 1,102
    edited 2008-02-14 - 00:48:41
    If we are using a bitmap driver we can either pre-calculate them or do it in the graphics driver which don't have to worry about WAITVIDs smile.gif

    Sorry for the slight thread hijack smile.gif
  • deSilvadeSilva Posts: 2,967
    edited 2008-02-14 - 00:59:36
    Phil, you have to distinguish between tiled drivers and bitmap drivers.
    With bitmap drivers you have no problem at all. The simplest down-sampling is just integrating the collapsed pixels. There are more complex filters, of course. This is an offline process

    With tiled drivers it will become extremely more tricky. I share your concern that there will be not enough time for the needed processing.
  • stevenmess2004stevenmess2004 Posts: 1,102
    edited 2008-02-14 - 01:15:19
    So we are waiting for the encode instruction in the prop2 smile.gif Hopefully they will do a new version of the current Prop with the two new instructions and maybe some of the other improvements.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,194
    edited 2008-02-14 - 03:41:59
    deSilva said...
    Phil, you have to distinguish between tiled drivers and bitmap drivers. With bitmap drivers you have no problem at all.
    Quite true, which makes the character ("tiled") drivers the only ones tricky enough to be any fun — right? Besides, the potential RAM savings alone could make the effort worthwhile.

    But first things first: a PC simulation would be the easiest way to tell if this line of thought is even worth pursuing. Who knows? An anti-aliased Propeller font might look like total crap.

    Of course, none of this is meant to diminish Clemens' superb results; and I fear that my idle conjecture has caused his thread to be hijacked. In point of fact, his discovery of how to sample and downsize the Propeller font in two-color mode is quite striking, very possibly mooting any reasons for anti-aliasing to begin with. I suggest we give him his thread back and take up any further discussion under a new heading.

    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • deSilvadeSilva Posts: 2,967
    edited 2008-02-14 - 09:07:38
    Phil, I and everyone agrees that Clemens' finding is, well, "important". There had been a reason for putting the hi-res font in the ROM.. It takes most of the space there. People working with other micros know that loading fonts is dull, time taking, and space consuming.... There are in fact reasons to use proportional fonts or special faces for games. But 99% of the users just want a fast, no-nonsense, readable font. This now comes close to reality.

    Clemens choose the title of this thread quite general, as he sure is aware of this significance far beyond using it in his (and my) little "toy".

    To apply it to TV there are two steps:

    (1) calculate whether it is possible to down-sample the characters "on the fly". (Which comes close to TRYING it). This will no longer be compatible with a general bitmap mode of the driver. There could be advantages for using 2-color mode for this!

    (2) By using the power of 4-color mode (which is NOT utilized at the moment other than sorting out the character interleave) a smoothed grayscaled (it will work for any hue BTW) presentation is possible.

    (3) As I doupt the feasibility in the available timeslot, a precomputed font can be dynamically constructed (WRT (1) or (2)) This will take 256*9 bytes for the 6x12 monochrome font by Clemens , and 256*32 bytes for an 8x16 antialised font by Phil. Incompatible changes in TV are still needed for both cases!

    Post Edited (deSilva) : 2/14/2008 9:24:20 AM GMT
  • ClemensClemens Posts: 234
    edited 2008-02-14 - 09:13:05
    @ Phil, stevenmess2004: Nonono, please stay! :-)
    I like my threads being hijacked, no problem there!

    And besides thoughts on an antialiased font is not so OT in this thread.
    I·was actually·trying to get greyscales for antialiasing on the little display by PWMing some pixels, but the refresh rate for the whole screen is not fast enough of course.

    @ deSilva: Yes something like a screen buffer would be very nice also for getting button-type borders around words to make a good looking touch screen interface (which is my long-term intention) and for graphic display in general.
    But I'm doing this step by step and I'm glad the driver is so comprehendable for me right now. - Which doesn't mean I wouldn't appreciate further enhancements of the driver ... ;-)
    You seem to be involved in quite a lot of projects right now, so no problem if you don't have a "free cog" for this one right now. LOL.
    Danke für's Kompliment.


    Post Edited (Clemens) : 2/14/2008 3:08:52 PM GMT
  • stevenmess2004stevenmess2004 Posts: 1,102
    edited 2008-02-14 - 10:34:34
    I wonder if I could add an antialiased pixel sprite command to the graphics driver? I guess it would need to read a few longs, count the number of bits in a certain area and then write them out. There are a few longs left in the cog anyone got any ideas for an algrothim? Would you just count the number of bits in a 2x2 square or would you do something more complicated?

    Post Edited (stevenmess2004) : 2/14/2008 10:41:47 AM GMT
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,194
    edited 2008-02-15 - 20:50:31
    Clemens, thanks for the invitation to stay!

    Attached is an image containing several downsampled (half-scale) renderings of the Propeller font using various strategies. The TV output is capable of six gray levels, ranging from 0 (black) to 5 (white). Each block of four pixels in the original dark-on-light font can have a count ranging from 0 (all dark pixels) to 4 (all light pixels). Each strategy is identified by a series of integers (e.g. 5 5 0 0 0). This series represents a mapping from the pixel count in each block to an intensity level. So "5 5 0 0 0" means, "If the block contained 0 or 1 light pixels ( i.e. 3 or 4 dark pixels), assign a brightness level of 5 (white); otherwise, assign 0 (black)." All the renderings invert the font thus from dark-on-light to light-on-dark.

    I'll leave it for the readers to judge which looks best.

    768 x 675 - 25K
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • deSilvadeSilva Posts: 2,967
    edited 2008-02-15 - 21:00:57
    Phil, this looks well! I understand you are not using Clemens' tricky extraction receipe but take just every 2x2 sub-matrix.
    Using the luma value is cute, as the chroma can stay as given by the tiling; this is the abvantage when working directly in the driver. (but never use sync level 0! It should be 1 to 5, not 0 to 5)

    The "Gretchen question" as we call it German: How long does it take to add the luma values and to extract the bits???
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,194
    edited 2008-02-15 - 21:12:58

    The six luma values I cited do not include the sync value (-2 on my scale) or "blacker than black" (-1 on my scale). Also I'm not sure what you mean by, "... the chroma can stay as given by the tiling ...". The grayscale values are just eight-bit color specs that happen to have their chroma bit set to zero. There's nothing otherwise special about them, and they can intermingle freely with chroma-modulated colors in the same tile.

    As to the Gretchen question: I haven't got a clue! smile.gif ... yet


    Post Edited (Phil Pilgrim (PhiPi)) : 2/15/2008 9:18:58 PM GMT
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,194
    edited 2008-02-15 - 21:26:57
    Come to think of it, there's no reason to sample the font horizontally. This can be managed just by halving the clocks-per-pixel value in VSCL. Vertically, it's a different story, of course. But the problem is reduced from counting four pixels in a 2x2 box to counting two pixels in a 1x2 strip. And that might be accomplished by some clever Boolean manipulation. The Gretchen question is still very much open, though.


    Addendum: The attached image is rendered by using the font's full resolution horizontally and sampling vertically by ORing adjacent lines together.

    Post Edited (Phil Pilgrim (PhiPi)) : 2/15/2008 9:47:10 PM GMT
    768 x 384 - 7K
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • ClemensClemens Posts: 234
    edited 2008-02-17 - 10:22:18
    Wow, the downsamled font looks really nice.
    But it's not half scale, is it? I'm counting 24*12 pixels, which is 3/4 of the original 32*16.

    Or am I getting something wrong?
  • stevenmess2004stevenmess2004 Posts: 1,102
    edited 2008-02-17 - 10:39:29
    Phil, would you be able to get assembly code for this to fit in around 30-50 longs? If you can than I could probably fit it into the graphics driver.
  • deSilvadeSilva Posts: 2,967
    edited 2008-02-17 - 12:38:50
    This will give him the spurs... Wow, 50 longs! In fact that MIGHT suffice....

    But note there is a strict 4 color model in GRAPHICS. When needing "shades" (B,ltG, dkG,W) then thta's it for the whole screen, more or less. Looks like a case for a very special application, as TV_TYPEWRITER....
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,194
    edited 2008-02-17 - 16:11:21
    The latest font isn't downsampled horizontally. The idea was that, instead of downsampling on the fly, one could simply double the horzontal pixel rate, thereby squeezing twice as many characters in. Vertically, it's downsampled by ORing adjacent lines, but I've doubled those lines to preserve the aspect ratio in the image. They woudlnt be doubled onscreen.

    I now have my doubts that this method could be as easily implemented as I thought. The TV.spin driver, upon which TV_text.spin depends, will not run at the necessary pixel rate. So modifying it to produce characters on the fly seesm less feasible now. That leaves the graphics driver approach. 30-50 longs? Hmm.

    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • deSilvadeSilva Posts: 2,967
    edited 2008-02-17 - 16:45:26
    My TV reference are low cost monitors with QVGA layout (320 x 234 physical pixels). 40x20 characters is max. They will look considerably better with grayscale! Using chroma values will conterfight this due to the limited number of color pulses...
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,194
    edited 2008-02-17 - 17:20:28

    You bring up a good point. No analog TVs — nor even most black-and-white monnitors — have the necessary horizontal frequency response to handle an 80-character line of text. And with a color monitor, the fine detail would cause color fringing, even without chroma modulation. This windmill may not be worth tilting at, after all.

    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Hi, friends!
    Sorry for disturbing your but I have a little bit to add to the topic subject.

    1-st of all, the Parallax font is looking really nice!
    The only problem was to obtain parallax-derived fonts (with sizes of 08x16, 12x24 etc.).
    My dream was to obtain a set of raster Parallax fonts to be able to show attactive messages on a different OLED I2C/SPI displays.
    After the web diving I recognized that a) I'm not alone and b) there is no parallax-derived fonts publicly available.

    Well, I have spent several hours being importing varying sizes of Parallax ttf-font and rasterizing it by available means.
    One of these is TheDotFactory (http://http://www.eran.io/the-dot-factory-an-lcd-font-and-image-generator/).
    Good program with a lot of options! But I couldn't realize how to declare MY requirements BEFORE the program handles a font.
    (for example, I would like to declare how the data in "*.c" is generated - as bytes, as words or as unsigned longs, but there is now such an option there).
    etc., etc., etc...

    Nevertheless, I could not find neither a set of variable-sized rasterized parallax-like fonts nor could I found a free-of-charge tools to make the job easy.

    Okay, I have done it!

    Now I have beatiful 08x16 raster font and about ideal 12x24 parallax-based raster font.

    I did spent a part of my soul in both of it and now I'd like to share with you the result.

    No special format is used - the fonts are in plain text format.
    Anybody is free to have it's own parser to make it's code to convert the fonts to an appropriate layout.

    Please see the files attached and be free to get in touch with me in case of any questions.
  • I made this program to generate fonts for Prop projects:

    You might find it useful...
    Prop Info and Apps: http://www.rayslogic.com/
  • The downsampling is nice but not very practical for video, as video drivers don't have time to do the conversion character by character in the kernal. About the best use of this for that would be to reuse a PASM image that had been cogstarted by downsampling the ROM font into the now-unused Hub RAM.
Sign In or Register to comment.