Skip to content

Conversation

@ndrnmnk1
Copy link

WBMP (Wireless bitmap) is a very old image format designed for feature phones. It works almost exactly as your .raw, except FFmpeg and many more multimedia converters support it. This would simplify making icons significantly, but require editing every icon that's already there

@echo-lalia
Copy link
Owner

I like this idea! But, since the WBMP format is so close to the RAW format we're using, I think it might make more sense to add support for WBMP in addition to RAW (and the width/height could be made optional if the file is WBMP).

@ndrnmnk1
Copy link
Author

That's a great idea! I made it so that launcher prefers WBMP one, but if it's not found, reverts to .raw. Now it can display bitmaps, but some of them render incorrectly - for example, 32x32, 48x48, 128x128 and 256x256 work perfectly, but 116x116, 114x127, 115x128, 116x128 show diagonal shift. I think the issue is in lib/display/displaycore.py, specifically in _bitmap function. I'm too scared to touch it, so i'll just leave it as-is

@echo-lalia
Copy link
Owner

The viper display methods are kinda huge and daunting so I don't blame you. I haven't checked but I'm guessing the issue appears when the width isn't a multiple of 8bits.

I'm currently a bit preoccupied with trying to finish adding RP2 support for MicroHydra, but when I've got a bit of time, I'll try to find the source of the issue you describe, and merge your changes in 😁 thank you!

@ndrnmnk1
Copy link
Author

ndrnmnk1 commented Oct 26, 2025

Nevermind, turns out WBMP is byte-alligned, and fix was a single line of code; now bitmaps work flawlessly.

I wanted to make another pull request with Ukrainian language and font fix, but GitHub doesn't let me do so for some reason, sorry! I've downscaled all non-ascii symbols twice (except Japanese/Chinese/Korean ones) so Ukrainian text renders correctly.

I found 2 bugs related to translations:

  • if i add Ukrainian to files.py or getapps.py, launcher starts crashing with ESP_ERR_NO_MEM
  • characters like ä, ö, ü, å and their uppercase versions render as some other random characters
  • letters like Ukrainian і and ї leave artifacts (their dots on top are the reason)

I think about moving translations to separate files(for example, lang/en_settings.py, lang/files_zh.py) and storing them as dictionaries to consume less RAM and fix the first issue. May i do this?

@echo-lalia
Copy link
Owner

Yeah I had figured the current translation system would cause issues at some point. I think I may need to figure out some kind of complete overhaul for it. Probably, the translations will need to be loaded from a file, that way only one language needs to be loaded at a time.
(I'm not certain how I'd like that to work exactly. I think it might make sense to re-format all the built in apps in a folder structure, add a translation sub-folder, and rework the i18n module to scan a given folder for a relevant language file, and import it dynamically)

Im a little bit confused about what you mean by "I've downscaled all non-ascii symbols twice", but I can see from the files that you've added a utility to check whether or not a character is square, and I think that's a really good idea!

That all said, I do think I gotta focus on one thing at a time, for my own sanity, haha. I'm not sure why GitHub won't let you make two pull requests. Have you already tried putting the translation changes into a separate branch, and then submitting a pull request from that branch?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants