Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[durian]

Does any one have the baseline value (number of pixels from the bottom of the bitmap to the font's baseline) for each of the BT817/8 built-in fonts? I'd like to use that information to better align different size fonts.

mike

[durian]

I decided to try and determine the baselines myself, at runtime. Using the font metrics, I could multiply the line stride by the font height to determine how many bytes are in each character's bitmap. Then I could jump to the end of a bitmap and read each row from the bottom to the top until I detected a non-zero pixel. That would be the baseline. Since the line stride tells me how many bytes are in each line, it seemed easy enough to do. After testing, this method does work for a custom font I uploaded in L4 format. However, it doesn't work for built-in fonts. Or at least it doesn't work for font 31. I haven't checked the others yet.

The problem is the font format. Despite the BT817/8 datasheet saying font 31 is an L4 format font, the metrics block says it is COMPRESSED_RGBA_ASTC_8x8_KHR. The datasheet also says the line stride should be 18, but the metrics say it is a whopping 80 bytes per line!

Now I don't know what to do. Perhaps I'm reading the wrong metrics block, but all the other values seem reasonable.

What is the meaning of line stride in an ASTC compressed font? Can I use it to determine the start of each row of the bitmap? Or is it only useful when multiplying against the font height to determine the size of each character?

Is there a way I can extract a single line from the bitmap so I can determine if any pixels are set without decompressing the entire character? Or if the entire character must be decompressed, can I use the BT817/8 to decompress it into RAM_G where I can then examine it row, by row?

Or better yet, can someone provide the baseline metrics for all the ROM fonts and I can hard code those values into my program and only runtime-calculate the baselines for my custom fonts.

Thanks,
mike

[BRT Community]

Hi,

We'll check with our R&D team about the internal fonts and will post an update soon,

Best Regards, BRT Community

[durian]

Thanks!

In the meantime, I noticed the CMD_SNAPSHOT2 command. I'm going to try rendering a character ('1' since it is a "flat" character like 'x' and will have a well defined baseline) and then using CMD_SNAPSHOT2 to copy it to RAM_G where I can analyze it.

mike

[durian]

Using CMD_SNAPSHOT2 to copy the rendered font to RAM_G and then analyzing it worked. Waiting to ensure the font was rendered and then waiting for it to get copied to RAM_G was a bit tricky. I ended up checking the INT_SWAP flag in REG_INT_FLAGS to tell when the frame had been rendered after drawing the bitmap and then again after the call to CMD_SNAPSHOT2. Perhaps that is overkill and there is a better way to check when the steps are complete.

For anyone who found this thread and needs the baseline information, here is what I calculated for the ROM fonts. The baseline is in pixels from the bottom of the bitmap. I also calculated the cap height as the distance from the bottom of the bitmap to the top of "flat" capital letters. Perhaps it should be calculated from the baseline. You can adjust these numbers as needed. In both cases, I used '1' as the reference glyph since it is flat (and is present in some reduced character set fonts I use).

Font #	Baseline	Cap Height
16	1	8
17	0	8
18	4	14
19	0	16
20	2	10
21	3	4
22	4	16
23	4	17
24	5	23
25	7	31
26	3	14
27	4	17
28	5	20
29	5	23
30	7	30
31	10	41
32	12	51
33	17	69
34	22	89

mike

[durian]

I have revised the way I handle the snapshot timing. I'll mention it here in case anyone else needs to do something similar.

I no longer check the INT_SWAP flag prior to issuing the CMD_SNAPSHOT2 command. It does not appear to be necessary. I think the snapshot action blocks itself until the new frame is ready.

I also no longer check the INT_SWAP flag to determine when the snapshot is complete. I don't think this was a reliable way to determine when the snapshot was complete. Displaying a new frame and the snapshot completing are two different things they really aren't coupled together. Instead, I write 0xffffffff to some area of RAM_G prior to calling CMD_SNAPSHOT2. Then, immediately after issuing CMD_SNAPSHOT2, I issue a CMD_MEMZERO for that same RAM_G address. So, as soon as the snapshot completes, the coprocessor will clear the memory address. My MCU then polls the memory address until it reads zero. At that point it knows the snapshot has completed and it can safely analyze the rendered glyph (now in RAM_G).

mike