BRT Community

Come and register in our Next Webinar on 20 May 2026 @ 3pm UK time.

Bridgetek Webinar | From Design to Device – Showcasing EVE Capabilities

Register Now

Hi Rudolph,

Yes the webinar is being recorded, we will post here and also send you the link.


thank you

BRT Community Admin

🚀 Just 1 Day Left – Bridgetek Webinar!

Traditional MCUs can't keep up with today's graphics demands — leaving developers stuck with complex code, slow performance, and limited user experiences.

✨ Discover how EVE (Embedded Video Engine) changes the game:

- Integrated graphics power for faster workflows
- Less coding, quicker time‑to‑market
- Smooth, engaging interfaces across industries

From smart appliances to industrial systems, EVE helps you break free from MCU limits and design the future of embedded UI.

📅 15 April 2026 
🕒 3PM GMT / 9AM CST / 10AM EST

Link : https://42bmw.share.hsforms.com/24P6cvmRSRXiyttQhXDfvPw

Hello, will this be made available later? Like on your Youtube channel?

Traditional MCUs often hit their limits when faced with today's demanding graphics and touch requirements. Complex code, sluggish performance, and limited user experiences can hold back innovation.

Join our upcoming Bridgetek webinar to discover how EVE (Embedded Video Engine) transforms development:

Simplify design workflows with powerful integrated graphics capabilities.

Reduce code complexity and accelerate time-to-market.

Deliver smoother, more engaging user experiences across applications.

Whether you're building smart appliances, industrial interfaces, or next-gen IoT devices, EVE helps you move beyond the constraints of traditional MCUs.

👉 Reserve your spot today and see how Bridgetek EVE can design seamless interfaces - moving beyond MCU limitations.



LIMITED SEATS! REGISTER NOW

I am just getting "Error: Invalid value for '-c' / '--command'" when adding -cw 1 0 0 0

Hello Redolph,

Can i ask what the command line output was when attempting to use the the -cw option?

Best Regards,
BRT Community

Excellent, a viable workaround and a fix incoming then. 
I just went with the ASTC 4x4 for now, I should be pretty much done with the UI and still have not filled half of RAM-G.
Interesting that ASTC has no direct support for grey textures.
I tried to use the -cw" option from astcenc.exe, but eab_tools does not accept it.

Hello Rudolph,

Tank you for your post.

After internal review, we have identified that the difference in font rendering quality is related to the BITMAP_SWIZZLE setting used in different EAB versions.

In EAB v2.13/v4.0.1, the swizzle setting was:
BITMAP_SWIZZLE(ONE, ONE, ONE, RED)

In newer versions (e.g., v4.1.x / v4.2), the default is:
BITMAP_SWIZZLE(RED, GREEN, BLUE, ALPHA)

This difference can affect how the ASTC font bitmap channels are interpreted, which may result in the washed-out appearance.

If you would like to reproduce the same visual result as v4.0.1/v2.13, you can manually add:
BITMAP_SWIZZLE(ONE, ONE, ONE, RED)

before CMD_TEXT() or other font drawing commands.

If RAM_G space allows, R&D also recommends using a higher-quality ASTC format such as ASTC 5x5 to improve rendering quality.

The next version of EAB scheduled for release will reset to the previous BITMAP_SWIZZLE configuration for conversions.

Best Regards,
BRT Community

I am working on a project and needed a font, mostly for extra characters, but I also modified Roboto to have a dot in the zero.
Anyways, I noticed artifacts in the font. I am always using "exhaustive" and in "auto" the output log shows the format is ASTC_8x8.
As I did not recall having seen this before, I went back thru the EAB versions I have.
4.1.0 - exact same binary
4.0.1 - result is different, quality is better
2.13 - best quality with the same settings

Taking fotos from the display is not the best option and so I also used ESE to verify this - only to find that the result in ESE is different than on the display.

As a last step I set the mode to 4x4 which improved the quality even more. With this I do not see a difference between EAB 2.13 and 4.2.0 - the .glyph files are not the same though.
I have plenty of RAM-G left in this project, using a 136kiB .glyph file instead of a 43kiB .glyph file does not affect me for this project - but that is practially no compression.

I tried ASTC 6x6 with EAB 4.2.0 and the result is still good while the .glyph file went down to 57kiB. There are artifacts though if you look for them.

Looks like there is an issue with the EAB 4.x font converter, getting this level of artifacts on 8x8 is not what I am used to.
And I am also using a 792x792 image in the project that I converted to ASTX 8x8 with EAB 4.2.0. And there are almost no artifacts on it.

The command lines are:

eab_tools pre82x font -f extended -i ../Roboto-Subset_mod.ttf -o .../Font -s 26 -E ASTC -b 8x8 -e exhaustive -d 0 -R -u .../Fonts/!CharMap_UTF8_min.txt -S

eab_tools font -f extended -i .../Roboto-Subset_mod.ttf -o .../Font -s 26 -E ASTC -b 8x8 -e exhaustive -d 0 -x ".../EVE Asset Builder2/tools/astcenc.exe" -R -p -u .../Fonts/!CharMap_UTF8_min.txt -w

Ok, there is a small difference, EAB 4.2.0 uses the option "-S" and the end and EAB 2.13 has "-w", this appear to be options for eab_tools, "-w" does not seem to exist for eab_tools from 2.13 though.