How can I upload the icons to the OSD?
Opened this issue · 5 comments
Hello
I see there are some icons on the osd. But I don't see them. Instead I see signs.
Is there a bin version with icons?
Thanks
TobiasBales/PlayuavOSDConfigurator#12
The presence of icons in the Configurator is an ambition, and not actually implemented in the firmware. Tobias added them to the configurator, but nobody has actually done any equivalent work in the firmware, although it definitely could be done.
Tobias and I have talked about it, and as I remember it we roughly agreed the icons shouldn't be shown until they actually work. That said, nobody (including me) has done much to fix it either way.
In the meantime, it is definitely confusing. I had already made a few contributions to the code base before I fully understood what was (not) going on with the icons.
Oh, and sorry to take so long to get back to you!
Thanks... It is confusing and also impossible to move around all the data as in the original editor. Thanks got I had it set up with the original one and with the Chrome app there is only trial end error to make corrections to the vision. I suggest either remove them from the preview or implement them.
What is the problem of implementing them?? I can try and make the icons with some graphical editor, but somebody should put them in the code. There is a nice font char editor for the minim osd. Is it possible to make it there and give you the icons to implement in playuavosd?
I believe the icons are only part of the preview being inaccurate, although that's just an impression, not a firm opinion. I do agree that we'd want to fix icons (by either remove from Configurator or adding them to Firmware) it before trying to make the Configurator preview 100% WYSIWIG.
The problem with implementing the icons is just that we need a developer to sit down and do it. I have spent most of my time so far on the project fixing bugs, which has been what the product needed most up to now. I have another small batch of bugs getting ready to be released right now (Imperial display & a bogus Warning message), for example. For me this has been the most frustrating part of the project - I can see the massive potential of the hardware, but there's no point in implementing the complex and exotic features I envision if the basics don't work correctly. People need the basics working solidly, and after that we can add the cool stuff.
But, to attempt to answer your question instead of complain, what are the technical issues involved?
I would need to take a few hours to really dig into it, and I haven't done that yet. But here's what I think after about 30 minutes looking into it. This could be incomplete/wrong:
We are graphical of course, so we don't have the same limitations that MinimOSD has - we aren't limited to a particular hardware font with a limited number of characters. We have multiple fonts already, and could have more. Fonts are stored in an array structure started evidently by SuperOSD (https://code.google.com/archive/p/super-osd/source/default/source), and then built on top of by BrainFPV/Taulabs (https://github.com/BrainFPV/TauLabs), which itself has now forked off in at least two different directions. All this makes it somewhat hard to get straight what is going on.
I do know that fonts are stored as binary arrays as part of the code, and then indexed during the string-drawing routines. I believe it should be possible to add icons to these font arrays, regardless of how many characters are already there, but I want to stress I haven't done enough research to really know. The confusion here is because the SuperOSD code mentions a limit of 256 chars, but that's nearly the oldest code in the project, and I'm hoping that's not true, or fixable if true. I am sure we can use multiple fonts per string if we have to, it would just be far, far easier to use a single font since that's how the whole firmware is set up to date.
Tobias has already added a font-editor to the Configurator: Click on the "hamburger" (the three horizontal line icon) at the top left of the Configurator panel. You'll be able to choose the "pixler" editor, which we could use to at least give us the icon data we want. Once we have a workflow in place, that is definitely somewhere the developers could use help - in the production of of these icons and their binary strings (for example, like this: 0x38, 0x7c, 0xfe, 0xfe, 0xfe, 0x7c, 0x38, 0x38, 0x7c, 0xfe, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0).
A million dollar solution would allow the end-user to edit these icons, then either insert them into the firmware binaries before flashing or upload them into the EEPROM, so that icons could be customized completely by the end user. I am not signing up for this work personally, but that's the clear end-game for this effort.
I am sorry I can't get to this immediately. But it's a perfectly valid complaint and I agree needs a lot of work. It's highly misleading and confusing as-is.
Sample of partial work done already on Pixler:
I will dig in the code and see if I can manage something.