Suggestion: adding a configuration command for "menu.rbf"

[TimJ1970]

Hello. Is it possible to create a color code management command within "menu.rbf" that can be configured in MiSTer.ini to change the MiSTer's two-color scheme? Or at least have the option to use two or three different color themes or any color. Because the only option at the moment is to modify the code inside menu.rbf and recompile it, which isn't feasible for everyone.

[birdybro]

It will still result in using more resources on the FPGA side which is why this typically has not been added. Is there an accessibility reason for wanting a different monochrome color scheme?

[TimJ1970]

I wasn't expecting that response. Does it really take that many resources just to allow changing two colors? Why even ask the question when you can imagine it's simply nicer to let users choose their preferred color, at least for the menu, in addition to the existing wallpaper which surely also consumes resources, right? Why always ask if it's necessary? It's just a bonus for users of the MiSTer, that's all.

[birdybro]

Every request to increase any resources at all in the FPGA side need to be carefully considered. We have cores that use 100% MLAB/M10K and cores that use 100% DSP, so neither of those can increase at all. However this change won't use either of those, it would use logic space (registers). Now we have cores that use 99% logic (Saturn). Every single register added to the framework increases the difficulty for cores to succesfully meet timing closure.

You could add it as an exception in the framework on just the Menu core, but then you are not keeping the framework in sync with the template, which is also undesirable because updating the framework then is more laborious and special care has to be given for little exceptions, versus just copying over a new sys folder.

It's all up to whatever sorgelig wants to do, just trying to manage your expectations about it a little, we are in a heavily constrained environment now with the framework where you pretty much have to resist adding any registers unless it's absolutely necessary to fix something and adding exceptions into the framework on a core-by-core basis is not the right way to do things and comes with technical debt.

Instead of assuming I'm just being rude by asking if it's necessary, assume I have good reasons to ask probing questions based on my experience with the project.

[TimJ1970]

Thank you for replying and sharing your opinion on the matter.
I'm not convinced, but I understand that my request will not be considered...

[MikeS11]

There are a couple of things to consider here, one is the color scheme of the menu which is applied at the sys level, vs the color scheme of the menu core itself.

If it was just the core that was affected the resources are minimal and then it's up to the developer of the core or Alexey in this case to make any suggestions. But the change your asking about here affects the system framework and the appetite for that type of change here is going to be small. I agree it's probably minor in resources but it doesn't provide value across the entire framework.

Just my 2 cents

[sorgelig]

Ok, we are playing the game "describe the item but don't name it"
If you are talking about OSD color, then it's not a traditional way where GPU handles an alpha channel while blending. Here we have no GPU and tint is made by some shifting. Adding option for color may greatly affect the video timings and make video unstable in some cores which is better to avoid.